StudentSearch - GR3

Prototype photos

Digital photos of the pieces of your prototype. Show the prototype in interesting states; don't just show a blank window. Although you will iterate your paper prototype during this assignment, the photos only need to show one iteration.

Prototype 1 Photos

Prototype 2 Photos

Briefing

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 2:
Update the search for students who know either Java or C++ and also know MATLAB.

Task 3:
Examine one student’s full profile.

Task 4:
Hide 3 students from the list.

Task 5:
Restore 1 student to the list.

Task 6:
Email 3 students about interview times.

Task 7: (optional)
Start a new search

Observations.

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.

User B:

This user experienced issues figuring out to make an OR.  He eventually figured out that entering the entire phrase worked properly and went with that.  He experienced no issues with hiding users, unlike the previous user.

User C:

This last user has quite a few issues figuring out an OR, and eventually asked us (both computer and observer) for hints.  The hints were limited to things like "how would you say it?"  No other major issues after figuring that out.

Overall Takeaways:

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.

Iteration 2

User A:

Still had some learnability issues and confusion as to how to enter a requirement with an or (Java or C++ and Matlab).  He was till unsure even after looking at the example we included.  He was successfully able to hide 3 students and then restore one of them.  When trying to email students, he didn't see the "email students" button so he tried clicking on their profile card but couldn't find the email button.

User B: 

Understood what we meant by Java or (C++ and Matlab) but accidentally entered in Java or C++ by mistake after looking at the example.  After he hid a student and wanted to reshow them he successfully hit undo and showed the student, but he wondered what would happen if he had wanted to undo multiple "hide student actions", and he didn't really understand the "view hidden students".  He also didn't understand that you could email multiple students at a time; he selected each student individually and then hit email right away to email them and had to unselect them afterwards to email new students.

User C: 

First successful user to enter in composite boolean logic requirements.  When clicking through multiple pages of students he forgot which students were selected on previous pages so he had to scroll through pages unnecessarily.  Went to get a drink of water in the middle of emailing students and mentioned that a save button for your emails would be useful.

Overall Takeaways: 

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.  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.

Prototype iteration

We made several changes when creating our second prototype in response to the user feedback we got for the first prototype.  On the results section which displays the mini student cards, users didn’t understand that the x in the top right corner was so you could get rid of the student card or they didn’t even see it, so we decided to make a hide button that was very visible on the bottom left.  Users had the option of starting a search over, and we had a popup that asked them if they were sure they wanted to start over with the default value set to yes.  We decided to change this for safety reasons to having the default value set to no so that users wouldn’t accidentally press enter and clear the results of their search.  Previously we had a “start new search” button that always appeared, but we decided to make that button invisible until the user actually did at least one search since we didn’t want our users to accidentally click that button while entering in their search parameters and have to start over.

We also made several changes to increase the efficiency and learnability of our interface.  We previously had an email button to email students that was always visible even if no students were selected, but we made that invisible until at least one student was selected so that the user didn’t waste time clicking the email button and would see that the email button becomes visible after selecting a student, implying that all selected students will be emailed.  We also made sure that the “view hidden students” button wasn’t visible until at least one student was hidden so that users didn’t waste time clicking that button or think that there were hidden students initially.  We also added an undo button after the user hides a student so that they can quickly revert any mistake.  We made small changes to the search section such as changing the “requirements:” label to “Enter Requirements” so that it was explicitely clear they should enter their requirements here and we changed the “matches” label that shows students who fit the requirements to “results”.  After the user sends an email to selected students using a popup window we previously had the window just close, but we changed it to have an “email sent” popup to replace the previos popup and fade away after 3 messages in order to improve the feedback of our interface.

The last thing that was an issue was our search language.  It is very important to support both simple boolean searches such as "1.00 or 6.00" and also composite boolean expressions such as "Java or (C++ and Matlab)". We struggled to come up with a good solution, so we decided that the best way is to provide an example.  In the case of the second prototype, we added just a note saying "ex. 6.813 OR 6.831" to show that the implementation exists.  In the actual implementation, this will likely be a "default text" value on the input.  (The value that is there, but is greyed out to signify that it will clear when you click into the field.)  We also will look into ways of making the drag and drop grouping obvious as well.