...
Prototype 1 Photos
Image | Description |
|---|---|
| The main page. Barring a login system, this is what the user would see when they first progress to the StudentSearch website. We included the browser in our paper prototype, incase the user decided to try the back, forward, or refresh buttons, so that we could present our warning dialog. This page has a blank search (no courses or skills), a pagination bar of 7 pages, and 8 students randomly sorted (since no search criterion can be applied yet.) |
| The user enters a class to search for and then hits enter, adding that class as a search box on the left. |
| After entering a search term, the Start New Search button becomes usable and the search results begin to update, including the pagination bar shrinking from 7 pages to 2. | |
| After entering more classes, the user tries to enter an OR clause. He hits enter and gets the following result, depicting an OR clause. The search results again update. |
| Afterwards, he clicks on the button to view more student information. Here you can access a student's resume or recommendations (if applicable) and view just some more information about them. |
| This is a user trying to hide a student by clicking the X. It would temporarily remove the student from the search results. By hiding a student, it also adds the undo bar (2nd pic) and shows the "View Hidden Students" button (bottom, next to e-mail.) |
| The user decides to unhide one student, but is unsure which. He views the hidden students page, where the "Restore" button has replaced the X's on the cards so that he can restore them. (A restore all option is also available.) |
| By clicking a student back on the main page, a user selects students. They achieve a green highlight to signify their selection. Once he's done, he will click the "E-mail" button to progress. |
| He'll now attempt to e-mail the students. He has the ability to remove a student from the recipient's list on this page, barring the need to go back. Should the user to decide to go back to add another user, their currently entered body and message will be saved so that they don't have to retype it. (It's very easy to highlight all and delete.) |
| Once ready to start a new search, the user is shown the following confirmation dialog. |
...
Imagine that you are a professor trying to find a qualified student to work in your lab, which produces user interfaces for educators to easily create classroom materials. You would like to be able to see and potentially contact selected students who have taken 6.813 (UI design) and 11.127 (Computer Games and Simulations for Investigation and Education). Because your project is built in Java, you want students who have Java experience, but if they know C++ and Matlab they would also be able work on your project. Your tasks will be to use our user interface to search for qualified students, see more information about they students, and contact the ones you are interested in.
Scenario Tasks
Task 1:
Search for students who have taken both 6.813 and 11.127.
...
Task 7: (optional)
Start a new search
Observations.
Usability problems you discovered from the testing. Describe critical incidents encountered by the users, but don't record users' names. Record these as a series of high-level takeaways, focusing on the usability problems you saw, rather than what each participant did. For instance, you might describe how you had some learnability issues with your prototype, as evidenced by users B and C clicking all of the menus to try to find option X.
Iteration 1
User A:
The first user never seemed to realize the concept of deleting, whether it be a user or a keyword. When he messed up the OR input, he actually just decided to start from scratch and re-enter all the information. In fact, he eventually directly input the phrase from the card to get the intended output. His only variance was the addition of parenthesis. He completely skipped the task of deleting users, because he kept selecting them and couldn't figure out what to do with them. We eventually had him skip the task and continue. He was the only person who experienced any difficulty with this feature.
...
None of our users even attempted to drag and drop the tags together to create an OR. Similarly, they all had extreme difficulties with adding OR inputs.... they just didn't know what the expected behavior was. This indicates a lot of learnability issues with entering requirements.
Some of the affordances people couldn't see like which buttons are clickable (email students/see hidden students probably should not be allowed until they actually do something). Another learnability issue was figuring out how to hide or remove users. The "X" in the upper right of each user card was difficult to see, so we decided that we need to make it more visible and make it's effects more clear. The solution is to remove the "X" and add a "Hide Student" button next to the view profile information. We also are going to remove the bottom left "View Hidden Users" button in favor of moving it up to the upper right next to "Create New Search." This change will move it closer to the "Undo" message that gets shown.
...
It seems that although its getting easier for users to do composite boolean logic there is still some learnability issues with requirements. Perhaps we would benefit from a tutorial at the beginning on how to enter in requirements, or a recommended menu of things you can do (w/ composite boolean logic in the menu). Users seem to prefer personal touches to email and currently adding personal touches is very inefficient, so we may be able to improve our efficiency by having a template template that will enter in each students name individually so that the email can appear personal even though you only have to write it once. We . Some users didn't even see the affordance that you can select multiple students at a time.We could also improve our efficiency by having some sort of tabs system that shows search results in one tab, hidden students in another tab, and selected students in another tab since if there are many search results on many pages it can be difficult to remember which ones are hidden and selected. We should also have some sort of count displayed for hidden students and selected students since users might not want to go over a certain limit.
...