Information and Computer ScienceUC IrvineDavid G. KayInformatics 131

THIRD HOMEWORK

This assignment is longer than the previous ones and it requires coordination with other people; don't wait until after the midterm to think about it.

You will do the main part of this assignment (Part I) with the partner you chose at the end of the previous assignment.

Part I

In the previous assignment, you identified three applications that perform the same function. For this part, pick a single task (e.g., starting a new game, or setting the user preferences, or initiating a chat with someone on the buddy list) that each application performs with mouse or pointer movements. (If there is no common task in your applications that's pointer-based, talk to us right away to work out an alternative.) Try to identify a task that takes four or five different movements, on the average. (This is a rough guideline; don't pick a task that requires a single click in each application and don't pick one that requires a dozen steps, either.) If you have difficulty identifying an appropriate task, send us Email.

(a) Which of the three applications lets the user perform the task most quickly? Consider everything—recognition time, movement time, anything else. Which application makes the task slowest?

(You'll need to decide on the characteristics of the hypothetical user you're talking about here—beginning or experienced, old or young or in between, whatever characteristics are relevant—and keep those assumptions constant throughout.)

Produce illustrations of the steps involved, with the movements marked. Describe and explain your conclusions in at most half a (single-spaced) page (not counting the illustrations).

(b) Use Fitts' Law (P = C1 + C2 (log2(2D/W))) to analyze the speed of performing the task on each system. For each step in the task, measure the distance and the target size and apply the formula. You'll have to make some assumptions and adopt some conventions (Will you use inches, centimeters, or pixels as your unit? What's the user's starting point at the beginning of the task?); just keep those decisions consistent as you analyze the three systems so your results should be valid for comparison purposes, even if the numbers might need some scaling to produce actual times. Don't bother with the constants C1 or C2, either. (If there's some reason that you think your systems aren't comparable in this way, talk to us. It's possible, for example, that the task has a step or two that don't involve pointing, such as text entry. Fitts' law only applies to acquiring a target with a pointer, so you'll have to make some other time estimate for non-pointer steps.)

Show your calculations and analysis (probably a spreadsheet would be best, with a row for each step in the process), keyed to the illustrations in part (a). State clearly what results this analysis produced.

(c) Did your Fitts' Law analysis of part (b) reach the same conclusion as your holistic analysis of part (a) about which application was fastest? Unless the results were identical in every respect, describe and explain the differences. (Half a page is the maximum here.)

(d) Take your best-performing application and redesign the screen(s) for the task you analyzed to make that task even faster. (If you think your winning application is perfect, choose one of the other applications and redesign it to improve it, maintaining consistency with the rest of the original application (i.e., don't just redesign it to look like the winner).)

(d.1) Sketch out your redesign on paper. You and your partner should each walk through the redesign, looking for problems and making improvements. There's nothing to turn in for this part.

(d.2) After you're satisfied with your redesign, decide whether your redesign would be better represented as a low-fidelity prototype or a high-fidelity prototype. If the improvements are mostly about layout and interaction, choose low-fidelity. If they're more about color, typography, detailed illustrations, or fine-tuned arrangement of elements, choose high-fidelity.

You just need to show the new screen(s) and how they link to each other; you don't need to implement the underlying functionality of your redesign. This is a mock-up, not a polished design, so don't spend more than an hour or two putting the redesign mock-up together. When you're done, (a) use File:Export and export to a PDF file; submit that PDF file along with the main electronic document you turn in, and (b) using the Share icon on Mockinbird's toolbar, get a URL for your project and paste that URL into the main document you're submitting; the default sharing settings should allow anyone with the URL to view your prototype.

(d.2b) If you've chosen a high-fidelity prototype, use a WYSIWYG GUI builder (software that lets you place predesigned buttons, menus, scrollbars, and other user interface elements onto a screen design, e.g., Visual Basic, Visual C++, Dreamweaver or FrontPage (for web pages), Interface Builder or RapidWeaver or OmniGraffle (on the Mac)). Some of these tools are available on the ICS lab machines or for free trial download; nobody needs to purchase new software for this part. Even if neither partner is a proficient software user, you should try to learn your way around one of these tools. If you'd like to use Photoshop for this task, you may, but the tools listed above have built-in interface elements like windows, buttons, and so on, while in Photoshop you have to build them from the ground up. You just need to show the new screen(s); you don't need to implement the functionality. This is a mock-up, not a polished design, so don't spend more than an hour or two putting this together.Incorporate your high-fidelity illustrations into the electronic document you turn in.

(d.3) Describe your redesign and explain how it improves the original. (Half a page maximum.)

Combine all your answers into one electronic document and submit it via Checkmate; if you used Mockingbird, also submit your exported PDF file. Just one member of your group should submit the work, but of course both group members' names must appear clearly in the body of the assignment itself.

Part II

Read each of the following. They'll show up in future lectures, later assignments, and/or the final exam:

There's nothing to turn in for this part.

Written by David G. Kay, Winter 2004; using GUI-building tools in assignments was suggested by Alfred Kobsa and Nayla Nassif. Modified by David G. Kay, Summer 2007, Summer 2008, Summer 2010, Summer 2011, Summer 2012, Summer 2013.

David G. Kay, kay@uci.edu