...
Usability Problems Identified during Testing
The largest usability issue we encountered was that all 3 of our users had difficulty discovering the "check words below" button in Task 2 - 2 of the users took a long time until they located and used it, and the third user never found it at all and gave up on the task. During our earlier tests in the paper and computer prototyping stages, however, users didn't have such difficulties locating the buttons or discovering what their functionality was. There were 2 changes that we ascribe to this regression. Firstly, because evaluators had remarked that the label "Allow all words below to be displayed in sentences" was too verbose, we had shortened the label to "Check words below". However, this label has less information scent, because the button itself doesn't say what clicking it actually does, but rather which checkboxes it manipulates; the user has to read the label on the checkboxes, "May be displayed in sentences", in order to understand what the button itself does. The second issue is that we introduced the "Sort by" buttons, again following the advice of our evaluators that items should be sortable via metrics other than just Pinyin. However, because the sort by buttons were immediately above the list of words, then they further separated the "Check words below" button from the "May appear in sentences
" checkboxes that they manipulated.
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.
...