Jump to content

Okular/User Research Profile: Difference between revisions

From KDE Community Wiki
Pino (talk | contribs)
No edit summary
Ochurlaud (talk | contribs)
m 8 revisions imported
 
(6 intermediate revisions by 2 users not shown)
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>
* "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 ===


=== (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>
* Photographers
* Artists


=== 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>
==== Mike ====
Mike is an 28 years old engineering student, currently involved in his PhD.
His research field makes him read lots of documents, that he receives from his professors or find them on the Internet.


== 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.
</blockquote>
==== Use Scenario 1 ====
Mike has an assignment from his professor. After completing it, he has to show a summarised version of it to his professor first (to give him an overview of the work done), and then to the students of the professor's class.
==== Use Scenario 2 ====
Mike is going to attend to a conference related to his research field; luckly the location is not really far from the place where he lives, and a one-hour plane is enough for reaching the location.


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.
Though, due to his work, he will not be able to finish reading all the paper of the conference before leaving, so he wants to print the couple of papers left, and read them on the plane.


== 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>

Latest revision as of 18:20, 11 March 2016

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
  • Photographers
  • Artists

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.

Mike

Mike is an 28 years old engineering student, currently involved in his PhD.

His research field makes him read lots of documents, that he receives from his professors or find them on the Internet.

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.

Use Scenario 1

Mike has an assignment from his professor. After completing it, he has to show a summarised version of it to his professor first (to give him an overview of the work done), and then to the students of the professor's class.

Use Scenario 2

Mike is going to attend to a conference related to his research field; luckly the location is not really far from the place where he lives, and a one-hour plane is enough for reaching the location.

Though, due to his work, he will not be able to finish reading all the paper of the conference before leaving, so he wants to print the couple of papers left, and read them on the plane.

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