Final Thoughts...

We are now at the end of HCI project, we thoroughly enjoyed designing our concept and employing HCI principles. On reflection if we were to continue to develop our device based on user feedback we might change or tweak the following aspects:

• We would make the navigation of the device more dependant on recognition as oppose to recall, it was always our original intention to have the heading title for each card to describe whether it was a person, event or society, but unfortunately it took too much room on the screen. Perhaps it should have quickly faded in and out the heading from the top.
• Perhaps we should have used a more conventional method of accessing the information as oppose to the card metaphor. Although users were familiar with it for navigating people, it had it's deficiencies when it came to related people to events and societies, perhaps there was a better way of presenting this information.
  
• We would have added some more location based services, and we would have added ways of displaying user location.
• We would perhaps tweak our button layout to make it more logical based on feedback from our evaluations.

If we were to do whole project again we think we would have selected a medium with less difficulties in displaying information. Although we feel it is an original idea, it does require the user to make special allowances for the watch for instance, for handshake synchronisation it requires it to be worn on the right hand. Although we did make allowance for this in the settings screen. we also often wondered whether the functionality of this device would be better suited on a phone, much like an adaptation of Russell Beales' BlueDate application.

Merry Christmas & Happy New Year!

User Evaluations

About the user evaluations

The user evaluation involved stepping the user through a set of common tasks. Possible evaluation methods include the cognitive walk through and heuristic evaluation.

Using the cognitive approach we explained the scenario, showed the user the prototype and explained that it was split into several sections (actions on the left, screen, buttons on the ride hand side and below the screen). The user was asked to talk about each of the actions that they were doing. The details of both approaches are available in a book written by Russell Beale et al.

The user was given the following list of actions:

• Forward
• Backwards
• Left
• Right
• Add
• Settings
• Flip
• Time
  

And the following set tasks:

1. View a person on the device.
2. Find the particular person "Christina Angel."
3. Find "Christina Angel's" age.
4. Add Her To Facebook
5. Find out what course Kate Hulme does.
6. Find out an event Christine is attending
7. Change the setting "Give Limited Info"
8. Find a Person We Met Last Month
9. Show the time

As the prototype required our intervention we had to process the task in stages.

This was then presented to each user and they were evaluated against the following 4 criteria:

1. Will the users be trying to produce whatever effect the action has?
2. Will users be able to notice that the correct action is available?
3. Once users find the correct action at the interface, will they know that it is the right one for the effect they are trying to produce?
4. After the action is taken, will users understand the feedback they get?

User evaluations
We performed four evaluations in total, two practice runs that we have not displayed the data for, as we felt that, firstly they were already too familiar with our prototype having explored it before, and inevitably the actual process of asking questions and recording results we didn't really get right on these attempts.

We then asked two people from computer science that we knew to a lesser extent; Jing Tang, & Ben (from Joe's robotics class) and they were both kind enough to submit to evaluations. The raw data of which is available to download here.

Findings:
On the whole we are pleased with how our users responded to our device prototype, yet we found deficiencies in a number of areas. Although in fairness we were harsh in our evaluations by giving the users the bare minimum of information and explanation to complete the task. The users we chose were completely cold to our concept device, as they were not people we had surveyed for paper prototypes.

On the first task we noted that it was not always clear to the user how to 'activate' the device in a sense to display a person. Ben needed some prompting, while Jing was more happy to press buttons to discover functionality.

On the second task to find a user, having activated the device both users found it easy to navigate to a particular person using up or down, but Jing noted that he had the expectation of alphabetical index, so we could have made the chronological nature clearer.

The third and fifth tasks highlighted quite a big deficiency in our design, as both users immediately went for the left and right buttons as oppose to pressing flip, it was only after having pressed left and right that they thought to press flip. On essentially being asked the same question in a different format Ben again got confused and selected left or right buttons, before hitting flip. Whereas Jing recalled the behaviour and got it correct.

Adding to facebook was simple for both users, to this is obviously very intuitive.

Finding the event Christina was attending was surprisingly simple for Ben, he selected Christina, hit right, then flipped the event. Whereas Jing navigated to the RISA card and assumed this was the event she was attending, and never bothered to flip card without prompting. So this is an obvious deficiency.

Changing the setting was a deliberately difficult question, as the setting mentioned is the odd one out on the particular display, but it is the button that I expect people to use most often. It became obvious to Ben that he needed to press the add button, after he had pressed one of the directional buttons and seen the reaction. Jing exhibited similar behaviour. On this particular setting some extra feedback or an icon could perhaps be helpful however.

The eighth question about finding a person met some time ago was only asked to Jing, but the behaviour was not obvious to him. Unfortunately I think this question is unanswerable with this prototype. This is because the user needs the mouse to navigate the prototype, and to press and hold an on screen button is completely alien to the majority of users.

Fortunately the ninth question of displaying the time was completely apparent at almost all times for both users, although Jing did press this button when asked to find a person he met some time ago, and commented that he expected the button to be a toggle as he had pressed settings and flip and found them both to be toggle. This was a surprise result, but from his point of view it was a logical thing for the device to do.

A 3D Model...

Here is a quick 3D model of the final watch (without strap) to illustrate mainly the layout of the buttons, and their relation to the screen and interface...As you can see all the buttons are easy to reach, and referring back to the discussion of the ipod shuffle, you can see that every button has one function alone and all buttons are clearly labelled. You can see how we have tailored our user interface in the previous post to cater for this.

Our Inteface Design

We have now completed our GUI watch mock up, and it is shown below. It is an interactive Adobe Shockwave movie that should play on any browser, as most have Shockwave installed by default. If this is not the case you can obtain the plug in here.

Please do not be put off by its apparent complexity, this arose as translating the interface for a physical watch into a point and click interface is tricky:

• The cluster of four buttons labelled up, down, left, right form the direction pad and translate into the joystick of the physical device.

• The two buttons labelled add and settings translate into the side buttons of the device.

• The two buttons just below the screen labelled Time and Flip are the two face buttons of the device.

• The buttons on the blue bar on the left hand side are used to simulate external events, like a friend nearby or imminent event.

• Only what is displayed in the white bounded box is the actual display of the device!
  

Ignore the buttons on the blue bar for now and notice/try the following features:

• The time and date are displayed prominently by default.

• Click once on any button of the directional pad: Pressing any button on will take you to the people screen.

• Click on the the up or down button on the direction pad: Notice how the card changes to a different person.

• Click on the flip button: Notice how the card flips over to display further information if available.

• Press the Add button: This would on the actual device add the person to facebook.

• Push Left or Right on the direction pad: This will take you to Societies or Events categories respectively. Again you can flip the card at your leisure.

• Press the time button: This takes you back to the time and date display, from anywhere in the interface, pressing a directional button again takes you back to the card you were looking at before!

• Try pressing and holding the up button (when looking at a persons picture): This will pop up an extra navigation device to take you back to people you met longer ago.

The settings button (Expert Users): Here we have tried to make this screen simultaneously easy to use for novices but quick for experts. It does however change the functionality the user is used to, if you press any one of up ,down, left, right or add you will notice that a check box is changed. This we felt would be the quickest way of disabling syncing in a scenario where the user did not want to share information.


The only alternative we could think of would be a cursor type operation controlled by the joystick, but we felt this would be cumbersome to both novices and experts alike. At least this way once the screen is mastered, the user can set the desired settings as quickly as possible. One other thing to note is that if we needed more settings for customisation e.t.c we could flip the card using the flip button; and add lesser used settings there, though this is not implemented.

External Events: The result of pressing the buttons on the blue par depends upon whether you are at the main time screen, or viewing information. If you are simply viewing the time, pressing these buttons simply changes the date text momentarily, and in real life would perhaps give a discreet notification.


If on the other hand you are viewing information, it gives the information gently over the screen you are viewing, without navigating you away from the screen. The only exception to this is the sync button, because in practise synchronising may change information you are currently looking at, or may take a long time, so it would be better to have the time displayed while this takes place.

Now we must critically evaluate our prototype by gaining feedback from users...

If for any reason you cannot view our interactive prototype you can download a zip package of the standalone version here: [Available Shortly]

Design Issues & Further Inspiration

Now that we are pretty certain of our final hardware design, we have moved on to designing our final watch software user interface. As part of this process we have noticed some intriguing design issues; in earlier posts we discussed features the watch would have as well as the various alerts it would give to user, implementing these features in an intuitive way however we have not thus far discussed.

Function of buttons: It's clear that this is a pretty important part of our design, we had the dilemma of whether to design our GUI to use hard coded buttons or so called 'soft' buttons. Most mobile phone devices have soft buttons, where the function of buttons change according to context and a label describing its function is displayed at the bottom of the screen just above the respective button. After some debate we realised that perhaps this wouldn't be appropriate for such a small screen, and that our focus should be on reserving screen space for the key information we wanted to display. Thus we would have to use hard buttons, and we turned to my ipod shuffle to see if this would be a good solution...

It became clear that we could make a small modification to our joystick prototype; the addition of two side buttons for functions that are used rarely. Whilst still preserving the simplicity of the device, and that we could create the interface without being overly limited. Another lesson we learnt from the ipod shuffle is that every button is clearly marked and serves one purpose only, there is no confusing duplication. Obviously the parallels between our device and the ipod shuffle end here, as we have a screen to deal with, but nonetheless a screen should not be an excuse to make a device more complicated.

Handling Notifications: A previous post described how the watch would alert the user on various external events like a friend entering the vicinity or an imminent party or event, although this would probably be done either audibly or by some kind of haptic feedback, it hadn't previously occurred to us how we would alert the user when they are actually browsing the device for information.

In this particular scenario it would be a usability disaster if the watch was to navigate the user away from the screen they were currently viewing in order to alert them of an event, this lead be to look at the xbox360 model of notifications for inspiration...

In my opinion this is a classic piece of HCI, it appears unobtrusively tells the correct player key information and doesn't in any way interfere with the task at hand. Unfortunately the key to this working is having a large amount of screen space available, something the watch is severely limited with, but it is something we can keep in mind for our design.

Paper Prototype User Feedback

Yesterday and today we surveyed and interviewed 6 potential users of our system - all Birmingham students, at various locations around campus. Each user was showed the card metaphor and asked to rank the control schemes in order of preference from 1 to 4. We encouraged the students to suggest improvements, or point out deficiencies where appropriate, and also got them to try on a paper prototype to get an idea of how functional each control scheme was.

Results & Analysis

Jog Dial and Buttons Comments: could be fragile, chance of accidental activation, digging into their wrists, looking silly.

When scrolling through the card metaphor, users felt that this wasn't the best idea as there was potential for the device to be uncomfortable and catch on the wrist. Users suggested a jog-dial on the front face as oppose to the side.

Buttons Only Comments: simple design, but difficult to understand, impractical for navigating lots of cards.

Although a simple idea, most users thought that repetitively pressing on a button to access friends and events wouldn't be suitable for this watch. They felt that scrolling through a large list could be time consuming, especially as all navigation had to be done in this way.

Scroll & Tap Comments: scrolling like apple devices would be intuitive, maybe with buttons on the front or side instead of tapping, maybe put the scroll bar on a watch edge, for ease of use and to preserve screen space.

This idea was quite polarising in terms of response, although still rated highly overall. Some users could see the the potential for ease of use on par with the recent ipod/iphone devices in that scrolling through large lists of users was feasible. We asked users who responded negatively if they had used touch based devices before, wondering if they had used devices where the touch screen implementation did not live up to the concept. We had some suggestions to improve the idea by replacing the sliders with equivalent jog dials on the face of the watch. It is obvious to us that some people prefer the natural feedback of 'hardware' as oppose to touch screens or track pads.

Joystick & Dual Buttons Comments - Immediate, easily understandable, probably comfortable, avoid too many buttons, left/right maybe difficult - possibly add a dial.

Users thought that scrolling through the vast amount of friends and events would be possible with this design, and selection would be simple. It was clear that this interface was immediate to a large number of our users, thanks to the popularity of Sony Ericsson phones. Even uses who did not rate it as their first device found it to be their second favourite.

The Verdict:

The control schemes we looked at focused on 3 different type of user inputs: jog dials, buttons and touch based scroll bars. As the watch has the potential for displaying relatively large lists of screens, there was a clear affinity for devices that could navigate these lists quickly. Buttons were seen as a key necessity.

Overall the most popular scheme numerically was the joy stick based device, as most users had experience of this and could see themselves scrolling through cards to get to events, select other users and perform actions reliably; much as they do on a mobile phone. We received cautions from our users to use buttons sparingly, but it is becoming clearer now what our final hardware interface will be.

An Example 'Card'

While we decide on the final design for the hardware interface, work has been going into how the UI should be laid out in software, specifically looking at the information we can fit onto a watch screen whilst using the card metaphor. Click on the card below to flip it.

I have designed this initial U.I mock-up with a 160x128 screen resolution in mind, as this is similar to commercially available watches currently available. As you can see, we are limited in the information we are able to display with this metaphor, or indeed with a wrist watch design. Being selective about the kinds of information displayed is a key design issue. The one advantage of the card metaphor however is that it tends to steer us away from scroll bars, and/or scrolling text, which I feel could be incredibly cumbersome on such a small device.

Introducing Our Metaphor

In lectures we looked at metaphors and their use within user interfaces, from this we came up with a simple idea that would enable users to navigate the watch and its content quickly and simply. We call it the card metaphor. It is inspired by the concept of old circular card files offices used to have. Each screen is a virtual card, that can be flipped over to obtain more information, just like you would in the real world.

Users can switch to different cards by scrolling up and down, which is akin to selecting a new card from the file. Left and right could select different kinds of cards, akin to selecting a different card file. Although here we feel the metaphor diverges from the real world.
The advantage of this is that navigation is simple, and tied to a particular control scheme, in further posts we will elaborate on this.

Final Paper Prototypes

Taking lessons learnt from the past two posts we decided to narrow down our paper prototypes into the following simplified designs shown below, we have also made a questionnaire sheet with comments so we can gauge user feedback on our designs.You will note that the jog dial has moved following our evaluation of initial sketches. The other designs are largely unchanged. We have also made cut outs of the designs to place on wrists to get a better impression on how they would function, please excuse my hairy arm!


Now off to solicit user feedback..........

Further Evaluation of Paper Prototypes

After evaluating the gadgets in the previous post and seeing how the various control schemes would work in the context of our initial prototypes, we began to see which control schemes would be feasible and which wouldn't.

The gadgets we looked at had the following control schemes (or mixtures thereof); buttons, joysticks, jog dials and touch screens.

The Ipod Touch is predominantly a touch screen device (it's main unique selling point) and is really prime example of a mass produced finger operated device, so any watch design could take a lot of inspiration from this. Indeed one of our intial sketches has touch scroll bars, and we had initially not ruled out the possibility of a complete touch screen watch.

In operation the device was nice and reasonably intuitive to use (in my opinion as an unfamiliar test subject), yet we did have a few response issues selecting smaller menus such as songs. Using a familiar panagram 'the quick fox jumps over the lazy dog' to test a touch screen keyboard against a mini keyboard of the pocket pc phone we found that typing on the ipod to be more fiddly and error prone then that of the hardware mini keyboard found on the pocket pc phone (even after some training). This leads us to believe that a complete touch screen device or any complex data entry would be impractical at best for a watch with a such a small display.

The other interesting thing to note was that even Apple felt the need to place some buttons on the device; a main 'home' button and a 'hold' button, yet we could see how critical these buttons were for certain key features. Overall we felt that touch interfaces should be limited to tap and scrolling alone.

One of our initial prototype sketches employs a jog dial design, the Sony Clie PDA, it is in my opinion one of the best jog dials I have come across, yet we could instantly see one of the flaws in our jog dial initial prototype; you can't operate buttons on the front and a jog dial on the side without a seriously uncomfortable hand position, so if this design is to be carried forward we need to place buttons on the side. We also realised the potential for accidental movement of a jog dial placed into a watch scenario, so this is something to be taken into account.

The MP4 Watch has a user interface driven entirely by buttons on either side of the device. The video shows how this appears to be reasonable effective for small tasks such as navigation and moving around simple screens but makes browsing a large list of files quite laborious. Our watch (depending on our final user interface) could have a user searching through dozens to hundreds of friends, so this is something to keep in mind.

Another limitation we could see from the youtube video was the apparant difficulty the user had in pressing some of the buttons, this could be laborious for lots of information, but the loud mechanical 'click' of the buttons at least provides good feedback. Perhaps this was a trade off made by the designers to avoid accidental operation. In any buttons are still essential for many devices, so we will continue with button designs whilst keeping limitations in mind.

Other initial sketches employed a track ball and track pad design, which we could see on further reflection are probably not suited to a space constrained watch. Most track pads and track balls are designed for pointing devices which is entirely unsuitable for a small device, and we could imagine would be highly prone to accidental activation.

Our joystick enabled initial sketch is inspired by the Sony Ericsson series of phones; this does serve in our opinion for good interface navigation on small devices, as the phones prove in practice, but we noted that the end user would have to use a 'thumb only' type of grasp to actually operate it, we will have to judge how comfortable this is based on user feedback.