No Radiohead tonight. BOO

Plasma User Research Profile: A lot of good stuff came out of the Plasma Interviews and the work from Tokamak. I’d like to see more of this written up and discussed in public.

Both the Okular User Research Profile and Gwenview User Research Profile have some good stuff in their profiles. Remember that these profiles grow with the project, and as you expand your scope or add/change functionality, the profiles must be updated to remain useful.

This week, I would like to call on Kopete to begin working on their User Research Profile.

Instant messaging is an activity that nearly every type of user participates in and Kopete is one of the best instant messenger applications out there. But because Kopete has such a broad audience, it makes it that much more important to get all of the user types and use cases/scenarios documented. As always, ping me if you need help getting started.

What is a Use Case?

A use case is a description of how a user might use an application to complete a specific task. Use cases are commonly used in software engineering to help document functionality and how it is used. They can range in the amount of system-specific information from only describing the task to detailed implementation and avenues for completion. This examples describe similar use cases for the print function in Okular, including implementation details and two avenues for completion.

Okular example: Print a PDF document

• John prints a PDF document from the hard drive by opening the file in Okular, and then selecting File -> Print.
• Sara prints a PDF document from the web by opening the file in Okular, and presses Ctrl+P.

What is a Use Scenario?

A use scenario describes the context of a use case — the conditions, motivation, and environment of the task for a particular user. It is important to understand why a user might complete a specific task and how they will complete it in order to create an interface design. Use scenarios are commonly used by designers as a way to understand users’ motivation and tasks in an interface, but good engineering use cases include these extra elements of use scenarios. This example describes different use scenarios for a similar use case (printing) in Okular.

Okular example: Print a PDF document

• John is using a friend’s computer to print a paper he needs for class. He finds the paper on the hard drive and clicks on the icon to open it in Okular, the default PDF document viewer. He has never used Okular before and doesn’t find the Print button on the toolbar. John is not sure if Okular shares the same keyboard shortcuts as other applications, so to be safe, he goes to the File menu and finds the Print option and clicks it to print the document.
• Sara wants a PDF document which is stored on the web. When she clicks on the link, instead of opening in her browser, she is prompted with a dialog to save or open the document. She selects the open document option and specifies Okular as the application to open the PDF document. Sara usually only reads PDF files on the web, and this is the first time a PDF did not open in her web browser, and this is the first time she has ever used Okular. She does not see a Print button on the Okular toolbar and so decides to try Ctrl+P, which is a shortcut she is familiar with using in her web browser’s PDF plugin.

Why do we need both Use Cases and Use Scenarios?

Use cases and scenarios complement each other. They get interesting when you have similar use cases driven from different use scenarios or different use scenarios leading to similar use cases. You want to try and develop use cases and scenarios for as many functions or features and user types as possible. The goal is to make sure the different ways different users try to complete the same tasks do not conflict with each other.

These example use cases and scenarios describe how different users under different conditions might try to print a document in Okular. In particular, notice how the decision to remove the Print button from the toolbar to make the interface more simple and pleasing effects how these sample users might complete their tasks. What might happened if Okular has a number of users who rely on toolbar buttons to assist in completing tasks? Are these types of users familiar with looking through menu items or keyboard shortcuts? At the same time, consider how inexperienced a user must be to not consider looking through an application menu when all else fails. These users are not really a target user type for KDE or Okular, and so changing the design to accommodate them might not be reasonable.

Use cases and scenarios help provide developers with information to make these types of informed decisions. The next time Okular gets a bug report complaining about the Print button not available on the toolbar by default, the project has a reasoning they can cite. (BTW, users who are knowledgeable enough about using bugtracker can probably also figure out how to add the print button to their toolbar.) Also, I am in no way agreeing or disagreeing with Okular’s decision to remove the Print button from the toolbar by default. It was just a really good example.