Projects/Okular/User Research Profile: Difference between revisions

From KDE TechBase
No edit summary
No edit summary
Line 1: Line 1:
= Okular User Research Profile =
= 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? ==
== Who is the application for? ==


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


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


<blockquote>
* Sometimes it is easy to identify who the application is '''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
* This can help keep the scope of the project under control
</blockquote>


=== Sample User Profiles ===
=== Sample User Profiles ===


<blockquote>
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.
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 ==
== What kinds of tasks will they complete ==


<blockquote>
* List of common tasks users will 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
* 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
* Include functionality that is planned but not yet implemented to help keep the future in focus
</blockquote>
* Read a document
* Fullscreen display of the document (e.g., as presentation)
* Really basic document editing:
** fill the form fields
** add annotations on the document
* Print the current document


=== (What kinds of functionality will the application ''not'' support) ===
=== (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)
* Document collection management (ala digiKam, Amarok, etc)


=== Sample Use Scenarios and Cases ===
=== Sample Use Scenarios and Cases ===


<blockquote>
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 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.
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 ==
== Environment Conditions & Requirements ==


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

Revision as of 23:32, 9 April 2008

Okular User Research Profile

Okular is a document viewer. It allows people to read documents in the most common formats, and provides some aids to the reading.

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
  • Read a document
  • Fullscreen display of the document (e.g., as presentation)
  • Really basic document editing:
    • fill the form fields
    • add annotations on the document
  • Print the current document

(What kinds of functionality will the application not support)

  • Document editing:
    • 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)

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
Retrieved from "https://techbase.kde.org/index.php?title=Projects/Okular/User_Research_Profile&oldid=23401"