Keyboard - GR3 Paper Prototyping

Briefing

For our user briefing, we used our scenario from GR2 Design, which is copied below.

“Billy is a senior at MIT who had three friends from home come visit for the weekend! They decided after crazy partying Friday night, that on Saturday night they would take it easy, stay in and watch a movie. So Billy and three friends, sat on the couch in Billy’s room, across from the projector screen, to find a movie to watch. Without a wireless keyboard, Billy was required to use an apple remote to login to his Hulu.com account (username and password) and then search for movies.

It’s important his mischievous friends don’t see his password while logging in. Additionally, this agreeable group of friends will likely search for several different movie titles, before agreeing on one they’d like to watch.”

Scenario Tasks

Task 1:

Task 2:

Task 3: This is a picture of task 3 from our second iteration. On our first iteration, the task told users to incorrectly type a letter to simulate making a mistake. For our second iteration, the task did not tell users to mistake, rather during testing, when users were halfway complete with task 3, we told them to “change a letter”. We found users in our first iteration became preoccupied with making a mistake, and our prompting would more closely match an actual error.

Observations/Photos

We successfully conceived and covered all the cases that our users attempted, but our users pointed out very basic actions, which we designed, that they found counter intuitive.

Below are pictures of our first paper prototype with a brief explanation of how we ran it.

Users were given these controls to manipulate.

An important feature of our prototype was indicating focus. In our paper prototype we indicated focus by pointing a big yellow arrow at the focused object. Users were told that in an actual design, this would likely correlate to a highlighted background.

There were a set of onscreen directions that changed depending on “focus”. In our second prototype, we were able to remove some of these instructions and put them directly on our interface.

Users iterated through different character sets (uppercase, lowercase, numbers/punctuation). This is clearly a necessary function, but user testing showed our implementation (hitting “down” from the root node) led to breaking to some internal inconsistencies. After hitting down and cycling through the character sets, users expected to be able to hit the “up” arrow to cycle upwards through the character sets, but this brought them into the box containing previously typed letters. This was something we changed in our second prototype. In our second prototype, hitting down, brought the user into a selection mode, where up or down cycled respectively through the character sets, and a set was only chosen when the user hit “select”. This proved better, but we had to indicate to the user “hit select to choose a character set”. This prevented the accident “up” error, but users found it cumbersome, and one user hadn’t realized they changed modes. This is something we still need to iterate on.

As the user made selections, we added or removed nodes from the tree, and changed focus.

For selecting letters, we tried to implement a paper “focus” using a paper frame around the focused letter.

We designed a modified “autocomplete”, which based on previously typed characters suggested likely values. This could be very helpful, but only if it required few key presses to select. Moreover, it did not fit well with our metaphor of traversing the tree. (See the bottom of GR2, design 2 for a failed attempt!). Users were told to hold “select” to jump to the autocomplete, which worked well; however, returning to the tree was counter intuitive. Users were told to hold “select” to enter and leave the autocomplete, but once in the autocomplete, which was right of the tree, users wanted to hit “left” arrow to return to the tree. We changed this in our second prototype, which worked considerably better.

Some other user feedback from prototype 1

-          If a user was editing their previously typed characters, we required them to delete any previously typed letters, but users found this counter intuitive, and holding the “left” arrow should move them left instead of deleting characters.

-          Didn’t realize entering a space was at the end of punctuation

-          Placing directional arrows on the tree edges

-          Would be good to see the entire keyboard

-          How to support advanced users with memorized keypresses?

-          Why is the initial focus on Q when it is not often selected?