Okular/User Research Profile: Difference between revisions
No edit summary |
*>Bhards |
||
Line 12: | Line 12: | ||
* "Occasional" users, who just need to read a document (for example, linked in a web page, or received via email) | * "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 | * 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) === | ||
Revision as of 11:47, 10 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
- "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)
- 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