Projects/Okular/User Research Profile - Revision history

Pino: first two use scenarios

2008-04-20T14:31:40Z

first two use scenarios

Pino at 23:01, 17 April 2008

2008-04-17T23:01:56Z

Pino at 22:22, 15 April 2008

2008-04-15T22:22:36Z

Bhards: /* Who is the application for? */

2008-04-10T11:47:29Z

‎Who is the application for?

Pino at 10:44, 10 April 2008

2008-04-10T10:44:51Z

Pino at 23:32, 9 April 2008

2008-04-09T23:32:42Z

Pino at 22:08, 31 March 2008

2008-03-31T22:08:54Z

Pino: copy&paste the template for the user research profile

2008-03-24T22:53:49Z

copy&paste the template for the user research profile

New page

= Okular User Research Profile =

Short summary description of the purpose of the application, who it is for, and what those people can do with it.

== Who is the application for? ==

* List of types (groups) of users
* User groups can be organized based on any type of dimension
* Some groups may be broken down in to sub groups

=== (Who is the application ''not'' for) ===

* Sometimes it is easy to identify who the application is '''not''' for
* This can help keep the scope of the project under control

=== Sample User Profiles ===

User Profile 1: For each group of users identified (or primary groups, or particularly special groups if many groups are defined), write a description of that user's characteristics based on a real user you know.

== What kinds of tasks will they complete ==

* List of common tasks users will complete
* This does not have to be a complete functional specification, but major tasks and specialty tasks should be listed
* Include functionality that is planned but not yet implemented to help keep the future in focus

=== (What kinds of functionality will the application ''not'' support) ===

* List tasks or functionality the application will not address
* Sometimes it is useful to list this unintended functionality to help keep the scope of the application
* For example, a certain functionality may not be implemented because it is out of scope with the primary goals of the project, another application with a different focus does it better, or it is an extreme edge case for a user type which is not primary

=== Sample Use Scenarios and Cases ===

Use Scenario 1: For each task identified (or major tasks, or particularly special tasks if many tasks are defined), write a description of how that user would accomplish the task ''independent'' of how they would complete it within the application.

Use Case 1: If a use scenario has been implemented, include a matching use case which describes how the task use scenario can be completed in the application. There may be branching or multiple ways to complete the task, and this is a good way to document it.

== Environment Conditions & Requirements ==

* List of environmental conditions for the user or the application to consider
* For example, an Internet-capable application would require an Internet connection

@@ Line 13: / Line 13: @@
 * Users who read many documents, that want to track what they read either by "bookmarking" the document, or adding notes
 * Researchers/reviewers, who may perform many annotations for a document, or perhaps a few related documents.
-=== (Who is the application ''not'' for) ===
+=== Who is the application ''not'' for ===
 <blockquote>
@@ Line 61: / Line 61: @@
 Use Case 1: If a use scenario has been implemented, include a matching use case which describes how the task use scenario can be completed in the application.  There may be branching or multiple ways to complete the task, and this is a good way to document it.
 </blockquote>
 == Environment Conditions & Requirements ==

@@ Line 12: / Line 12: @@
 * "Occasional" users, who just need to read a document (for example, linked in a web page, or received via email)
 * Users who read many documents, that want to track what they read either by "bookmarking" the document, or adding notes
+* Researchers/reviewers, who may perform many annotations for a document, or perhaps a few related documents.
 === (Who is the application ''not'' for) ===

@@ Line 10: / Line 10: @@
 * Some groups may be broken down in to sub groups
 </blockquote>
 === (Who is the application ''not'' for) ===
@@ Line 38: / Line 40: @@
 * Print the current document
-=== (What kinds of functionality will the application ''not'' support) ===
+=== What kinds of functionality will the application ''not'' support ===
 * Document editing:
-** Page addition/removals/reordering/permanent rotation/etc
+** page addition/removals/reordering/permanent rotation/etc
 * Better image viewing than a toy image backend (any image viewer will do the job)
 * Document collection management (ala digiKam, Amarok, etc)

@@ Line 19: / Line 19: @@
 * This can help keep the scope of the project under control
 </blockquote>
 === Sample User Profiles ===

@@ Line 25: / Line 25: @@
 User Profile 1: For each group of users identified (or primary groups, or particularly special groups if many groups are defined), write a description of that user's characteristics based on a real user you know.
 </blockquote>
 == What kinds of tasks will they complete ==

@@ Line 1: / Line 1: @@
 = Okular User Research Profile =
-: Short summary description of the purpose of the application, who it is for, and what those people can do with it.
+Okular is a document viewer. It allows people to read documents in the most common formats, and provides some aids to the reading.
-−
-Okular is a document viewer. It allows people to read documents ...
 == Who is the application for? ==
 * List of types (groups) of users
 * User groups can be organized based on any type of dimension
 * Some groups may be broken down in to sub groups
 === (Who is the application ''not'' for) ===
 * Sometimes it is easy to identify who the application is '''not''' for
 * This can help keep the scope of the project under control
 === Sample User Profiles ===
 User Profile 1: For each group of users identified (or primary groups, or particularly special groups if many groups are defined), write a description of that user's characteristics based on a real user you know.
 == What kinds of tasks will they complete ==
 * List of common tasks users will complete
 * This does not have to be a complete functional specification, but major tasks and specialty tasks should be listed
 * Include functionality that is planned but not yet implemented to help keep the future in focus
 === (What kinds of functionality will the application ''not'' support) ===
-* List tasks or functionality the application will not address
+* Document editing:
-* Sometimes it is useful to list this unintended functionality to help keep the scope of the application
+** Page addition/removals/reordering/permanent rotation/etc
-* For example, a certain functionality may not be implemented because it is out of scope with the primary goals of the project, another application with a different focus does it better, or it is an extreme edge case for a user type which is not primary
+* Better image viewing than a toy image backend (any image viewer will do the job)
 === Sample Use Scenarios and Cases ===
 Use Scenario 1: For each task identified (or major tasks, or particularly special tasks if many tasks are defined), write a description of how that user would accomplish the task ''independent'' of how they would complete it within the application.
+<br/><br/>
 Use Case 1: If a use scenario has been implemented, include a matching use case which describes how the task use scenario can be completed in the application.  There may be branching or multiple ways to complete the task, and this is a good way to document it.
 == Environment Conditions & Requirements ==
 * List of environmental conditions for the user or the application to consider
 * For example, an Internet-capable application would require an Internet connection