...
As seen with User 2 on Task 3, our interface is inconsistent with the usual browser search functionality. This is of course an artifact of our decision to implement it in Silverlight rather than HTML. Although we can't have the browser search functionality work as expected without rewriting the interface, we could intercept the Ctrl-F shortcut and have it focus the search box, as searching for words is the most likely reason why the user would press Ctrl-F on the interface.
Reflection
Discuss what you learned over the course of the iterative design process. If you did it again, what would you do differently? Focus in this part not on the specific design decisions of your project (which you already discussed in the Design section), but instead on the meta-level decisions about your design process: your risk assessments, your decisions about what features to prototype and which prototype techniques to use, and how you evaluated the results of your observations.
Our design process was flexible, and revisited even our most core assumptions based on observations made in prototyping. For example, one of the decisions we made early in the design process was our model for which sentences would be displayed. Namely, initially we would not display sentences if they didn't have words that the user had selected as being allowed to be displayed; later we would allow sentences containing words the user hadn't selected as being allowed to be displayed, though these sentences would be displayed last, and the novel words would be highlighted - this noticeably reduced the frustration users had in fetching new sentences. Thus, our design process was holistic and considered all elements of the interface as up for revision, avoiding setting any elements of the design into stone.
The paper prototyping stage helped us establish our initial risk assessments and the features to focus our prototyping efforts on - namely, that the main difficulty was conveying to the user our model that sentences would be displayed only if the words they contained were specified as being displayable in sentences, and included the study focus if there was one. Thus, we focused our prototyping efforts mainly on the vocab and textbook selection, and less on logging in, reading and understanding the sentences themselves or contributing sentences, with which users had little difficulty in early prototyping The paper prototyping stage helped us establish our initial risk assessments - namely, that the main difficulty was conveying to the user our model that sentences would be displayed only if the words they contained were specified as being displayable in sentences, and included the study focus if there was one. Thus, we focused our prototyping efforts mainly on the vocab and textbook selection, and less on logging in, reading and understanding the sentences themselves or contributing sentences, with which users had little difficulty in early prototyping stages. Of course, we still did include these tasks in our later user testing stages as well to ensure that no regressions were occurring.
The prototyping techniques we used were initially paper for the paper prototyping stage, due to the ease of use of paper. Because we got our computer prototype in a mostly-working state well before the initial GR4 deadline, we were also able to use computer prototyping often during the implementation stage, asking users to attempt to accomplish a specific task on the interface. Because we were using stock widgets and a WYSIWYG designer for the interface, we were able to iterate quickly even with the computer prototype, making this technique feasible and not costing a great deal of time. Sometimes we would make 2 implementations of the same C# interface with radically different GUIs (particularly in experimenting with the sentence viewer and sidebar), and compare them in tasks side-by-side. Had we been coding in HTML and Javascript, where the lack of decent WYSIWYG designers, lack of code modularity, and high time cost of implementation would have made such experiments prohibitively expensive, we would have been forced to use lower-quality prototyping techniques.
In evaluating the results of our user tests, we asked ourselves two questions: did the user understand the model, and did the user locate the appropriate widget for interacting with it. In the event that a user failed a task, our first goal was to determine which of these was the cause: was our model fundamentally being misunderstood, or was the widget simply placed in a bad location? We did this by asking users questions about our model after we finished the main tasks of the user test - for example, "what does it mean for a word to be the study focus"?
Perhaps one thing we should have focused on more during prototyping was specific labels for items. Because item labels are easy to change after implementation, we focused little on them during early stages of testing. However, though we had intended to revise them in later stages, we often pushed it aside for later, and thus many of the usability issues we encountered were partly related to users misunderstanding the meaning of labelsOur design process was flexible, and revisited even our most core assumptions based on observations made in prototyping. For example, one of the decisions we made early in the design process was our model for which sentences would be displayed. Namely, initially we would not display sentences if they didn't have words that the user had selected as being allowed to be displayed; later we would allow sentences containing words the user hadn't selected as being allowed to be displayed, though these sentences would be displayed last, and the novel words would be highlighted - this noticeably reduced the frustration users had in fetching new sentences. Thus, our design process was holistic and considered all elements of the interface as up for revision, avoiding setting any elements of the design into stone.