The HCI Think Tank

Final Thoughts...

2007-12-14T16:41:00.000Z

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

2007-12-14T14:30:00.000Z

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:

View a person on the device.
Find the particular person "Christina Angel."
Find "Christina Angel's" age.
Add Her To Facebook
Find out what course Kate Hulme does.
Find out an event Christine is attending
Change the setting "Give Limited Info"
Find a Person We Met Last Month
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:

Will the users be trying to produce whatever effect the action has?
Will users be able to notice that the correct action is available?
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?
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...

2007-12-14T09:31:00.000Z

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

2007-12-13T23:57:00.000Z

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

2007-12-13T10:28:00.000Z

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

2007-12-12T21:21:00.000Z

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'

2007-12-11T10:02:00.000Z

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

2007-12-10T16:40:00.001Z

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

2007-12-09T15:20:00.000Z

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

2007-12-08T14:18:00.000Z

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.

Personal Evaluation of Paper Prototypes

2007-12-06T19:49:00.000Z

Soon we are aiming to obtain some real life evaluations of a our paper prototypes from our target audience, however having discussed the various prototypes between ourselves we can see some glaring issues that discount some of the existing prototypes we have thought of.

We basically sat down with a number of different devices from Si's gadget box of old and current hardware, to see how the various hardware interfaces actually perform. In one instance we took a jog dial device and imagined how it would perform in a 'wrist-watch' scenario, and so on with a number of other devices until we had a feel for how the interfaces we had designed in the previous post would actually perform.

We also looked at other devices that have tried to pack a lot of functionality into the form factor of a wrist watch. The Brando MP4 watch gives us some clues as to what is possible and feasible and the moment and is available at the mass market for ~£50. Notice how later in the video the five buttons have a loud click action, and how the user has to position their hand to operate the device. Another thing to notice is the text size, which shows how large the text should be for good readability. Which is something we need to keep in mind for designing our final interface.

Our next step is to obtain user feedback on a narrowed down set of paper prototypes... Stay Tuned.

Working on Paper Prototypes

2007-12-04T05:18:00.000Z

We are now working on paper prototypes to hone our ideas to aim towards a final design. Since a key part of the user experience is how the user actually interacts with the watch; we are trying to find an optimum control scheme by creating many designs and gaining user feedback.

This first picture shows a rough hand drawn selection of possible control schemes.

Whilst this second picture illustrates what the final design might look like when computer aided design is used.

After choosing the optimum control scheme we can then go on to looking at the graphical user interface of the watch.

Current prototype state and next steps

2007-12-04T02:34:00.000Z

Our identified screens are as follows:

Find friend, this could be around campus, club or bar
Display time
Pair with another user
Synchronize with users computer
Accept/ignore events
Event alert
Buddy homelist
Settings

From the user feedback and above screens we would now like to concentrate on and collect further feedback on the following:

Physical features
Transitions between screens and
Screen layout for each of the above screens.

Physical features we would like to look at will include research into how similar products have done and how this could be applied to our design. The touch screen and possibly the use of buttons were ones mentioned in the meetup with today with the demonstrators. After this our next priority will be planning out the information containted within each screen in a logical and consistent fashion. The final step will be getting a user to test the prototype out to see if they can perform the required actions.

Prototype feedback

2007-12-01T08:01:00.000Z

Whilst showing and explaining the design prototype I asked my house mates about their thoughts on the following: A student new to University wants to use this as an extension of their social network profile to find other like minded individuals, they would then be presented with invites to events that their new friends are going to.

The following summarises the points raised by my house mates:

Privacy issues and fine grain control over features - alerting a whole group of people when you're going to do something could be a problem, there should be more control over who can be alerted.
Too many friend requests - particularly in a social club setting, could be information overload.
What is the usable range?
Vibrate setting - to alert user when in a loud club.
How will the buttons/user input work?
Possibly marketed as a male/female watch/braclet.

Our comments to the points raised above:

Privacy issues/fine tuning of features
An example of fine tuning the functions could be choosing from a list of people available who you want to go home with rather then having a list that alerted everyone.

Too many friend requests
A large amount of people in a club could present information overload. How do we show this as efficiently as possible to our users? We could filter people out by categories that show up as a setting on the watch or just have a complete list of friends that the user scrolls through.

What is the usable range?
This would be the bluetooth range 10-100m, a fairly good size for a club or 2 within the local area.

Vibrate setting
This is to alert people especially within a club, just like a phone or pager. Although missed out this was a very valid point as clubs can be noisy and distracting and the best chance of a device like this getting your attention in this setting would be through vibration.

How will the buttons/user input work?
One thing the prototype diagram doesn't clearly explain is the use of buttons or user input. Here most of the user input is done through a touch screen. In the case of settings and events we've added scrollbars to display extra data. Without the use of scrollbars this has the potential to be fiddly if not impossible to use due to the limited amount of space available.

Possibly marketed as a watch/braclet for males and females
This was a nice addition (although part of the asthetics) to the look and feel of the device which wasn't initially thought about.

Updating our prototype

2007-12-01T00:11:00.000Z

Taking feedback into consideration we've decided to update our idea by having a look at how other successful products have accomplished similar issues.

So far the two things we have now identified before we do a final evaluation of our prototype are: design patterns and front buttons.

- The application of design patterns.
The drill down design pattern (described during a previous lecture) will provide a simple and effective way of displaying information.

- Front buttons.
Two possible competing ideas that are inspiring us on this are touch screen devices such as the iphone and lg verity versus the traditional button phone. Both make use of limited resources.

- Look of the watch/braclet.

This time the new prototype will be implemented in html, we've put up a flow diagram which link to screenshots here.

Other ideas that we will find inspiration for our idea from:

User walk through:

[do this in html, write script to measure how long it takes a user to do each task then report back with results.]

Student Social Organizer Watch Prototype

2007-11-29T16:04:00.000Z

Here is an image of our paper prototype that we've come up with:

Each of the screens is activated by actions defined below:

Bob is near - when another student with similar interests (clubs, societies, department,course...) comes up close the student is alerted.
Paired - when two students shake hands and have the same device this screen verify's that both students are now friends.
Time - this is shown by default.
Event - lets the student decide if they want to attend an event that one of their friends is attending.
Syncing - the watch updates new friends and obtains groups and events that the student may want to join/attend.
Settings - general watch settings.

An overview of the "Student Social Organizer Watch"

2007-11-29T06:30:00.000Z

From our suvery feedback and initial brainstorm ideas we have decided to create a device to help students organize social events and make friends.

Our idea will take the connectivity of a social network (as these are currently very popular with students) and the familarity of a watch.

Why a watch and not a more feature rich/complex device?

A watch is a familiar device to all students.
Limited resources and simple user interface are perfect for displaying all that we require.
A watch is also convenient to carry around, much more so then a phone.

Choice of social network
Facebook is choosen for the following reasons:

It presents a simple and effective way of getting people to organize an event.
It was the primary communication tool used to inform people about our survey and so most students are already familiar with its features.

So how will this work?
A quick rundown of how the student social organizer watch will work:

The student wears watch which in it's normal state tells the time.
When the student shakes hands with another with the same watch on it transfers the user's info over between both watches. They are then "securely paired". This ensures that both users are identified next time they go past each other.
When the user is at their home computer the devices sync over bluetooth. The app also sends over a list of subscribed events to the watch which are kept in the form of alerts.
Students can then select whether they want to join groups and events that their newly paired up friend(s) are on.

The survey also pointed out the following:

Students find it hard to keep friends together when out.
Students also find it quite hard getting home.

Our solutions:

When a student goes to an event, any friends that are also at that same event will be alerted if within range and kept within a radar, if one person moves out the others are then alerted.
When getting home from an event, the student will be presented with a buddy list which contains available friends within the bluetooth range and at the event. The student will alert their home buddies by selecting a screen and alerting their friends.

Devices taken a step further with cool effects

2007-11-18T22:00:00.000Z

The videos below show examples of popular devices (a mobile phone and games console) that have been extended with interesting results.

Synchronised shaking connects gadgets
From the Youtube's New Scientist channel the following video shows how 2 mobile phones can be linked together by shaking them in synchronization:

There is a paper over here. This could be used to validate users e.g. friends or possibly even to pay for items (events, stuff around uni, books...) in a very simple manner.

The key to working this is using an acceloremeter, so extending this to a keyring or other small item could allow phones and other devices to be paired up with other objects securly. This is probably a good extension of the student friend finding idea.

Tracking Fingers with the Wii Remote
The following video shows how a wii can be modified to produce a Minority Report style interface.

If you haven't seen the film the user interface is pretty much like the ipod touch/iphone when viewing webpages except that the device in the film is a clear pane (like the tv) and is operated by two hands. Other products using touch in an intelligent way include the Microsoft touch table and Adobe wall.

I think students new to university would quite enjoy the idea of operating their tv or other visual device in a more expressive manner.

Lies, Damn Lies, & Statistics.....

2007-11-18T14:57:00.001Z

Well the results from the first survey are in, we managed to get a total of 19 respondents (18 electronic, 1 written) so a big thank you to everybody who took part.

Now for some analysis. The original list of questions is shown below, along with a chart that gives a condensed summary of the responses received. Students were asked to rate their responses to questions on a five point scale (Very Easy, Easy, Average, Hard, Very Hard) and I took a tally of the number of "Hard" or "Very Hard" responses to identify issues we could target our project at.

Relevant Questions:
Q2) Getting hold of official university information?
Q3) Finding your way around campus?
Q4) Getting hold of course information?
Q5) Getting hold of student union information?
Q6) Find out about the clubs and societies you wanted to join?
Q7) Keeping in touch with your university friends?
Q8) How did you find studying?
Q9) How did you find revising?
Q10) When going out with friends, how easy or difficult was it to choose a venue?
Q11) How easy or difficult was it to organize a night out?
Q12) How easy or difficult was it to keep with your group of friends on a regular night out?
Q13) How did you find getting home?
Q14) How did you find grocery shopping?
Q15) How do you find obtaining university essentials?

Further Experiences:

"The information services (library) site is very useful for academic matters."

"Difficult as university residences are off-campus, so made things a bit harder re: going into town for nights out."

"Finding food was easy, maintaining a healthy lifestyle with no experience of it is difficult."

"It is hard for me to give answers to some of the questions for example about student union. I know there is one but I've never even tried to look for any information about it............."

Comments:

I find the results of the survey quite interesting, as someone who has been at university for a while now I hadn't expected such a skew towards the social aspects of university, but of course for a new student these matters are of utmost importance, long before thoughts of exams, revision and actually doing any work!

We can see that a lot respondents (proportionally speaking) had trouble in form or another on nights out. There also seems to be a difficultly barrier when it comes to obtaining information concerning clubs, societies and the student union.

The subject of revising was a problem to some respondents, but to a lesser extent than perhaps I had initially thought especially considering the majority of respondents listed themselves as either "graduate" or "working" I wondered whether we would see a skew towards this considering revision and exams would be freshest in the minds of these respondents.

We can now ponder these results and their implications on our ideas.

Online survey now up

2007-11-13T09:24:00.000Z

Our survey was placed up last week and so far we've received a handful of responses.

The questions contained are quite simple and should give us an indication of the sort of idea we should be looking at rather then how to design such ideas.

The url for the survey can be found here:
http://www.joe-wong.co.uk/limesurvey/index.php?sid=57814&lang=en

Student communication ideas

2007-11-11T10:05:00.000Z

Student job finder
The student job finder is aimed at helping new students find a job from one source rather then several. For new students most jobs can be placed into 2 main categories: Part time and Voluntary.

Retail provides many part time student jobs mostly due to the ease of getting a job however there are more options open for students. An Example can be tutoring where a student is using their existing skills to earn money.

Voluntary jobs include those where a student would probably want to help out, especially for societies and charities. Both types of jobs can be found on email lists, websites and through word of mouth.

As the number of job sources increases the breadth of the search a student has to do to look for a fitting job can be quite large especially for those students initially arriving at university.

Student friend finder
The aim of the friend finder is to help students find their friends/other like minded people.

The phone a familiar instant communication device is almost common to every student. However the phone usually costs credit/money to make calls and texts and can take a while to find out if everyone is going out. You've also got to have a number for your friend.

The social network profile e.g. facebook, myspace, hi5... are all populated by vast numbers of students even before they come to university. Social networks provide very useful profile information and features such as access to profile 24 hours a day, creating events, groups... The disadvantages of social networks are lack of instant communication and a reliance on an internet connection which is usually a computer at home. Although facebook does have a mobile site, I've not known anyone who interfaces with their site in this way.

The student friend finder device merges the two ideas by using the adhoc ability of a phone's bluetooth connectivity (could also be zigbee/wifi or something else) to find other users running the software and looking up matching bits of information. The friend finder will only alert the user when a successful match has been found e.g. both students are looking for "computer science" students.

They may then each receive a message (this depends on their settings) alerting them about this new user. If the user is already one of their friends then it may just alert them or do nothing.

Disadvantages may include:

Stalking if a user has too much profile information displayed, system could warn user before hand.
Popular users could have too many requests to handle, a cap may be placed on requests within a specific time period.

Drinking and Socialising Ideas.....

2007-11-08T21:06:00.001Z

A lot of the ideas that came out of the initial brainstorming session tended to revolve around drinking and socialising, which as we all know can be a big part of the university experience. Here are some undeveloped ideas that revolve around this particular theme:

The "how did I get home?" device: An unfortunate question that I'm sure a large number of students have asked themselves, they key idea behind this would be a watch or pda type device with built in screen and gps, that would record the path and places you visited at the street and pavement level, which could be replayed the next day to illustrate just how drunk you where the night before. However I think the novelty of such an idea would be short lived and not enough to carry a device on it's own, but could be interesting as part of a more comprehensive device.

Party Finder: This was primarily envisaged for people in halls or residence to keep track of where their friends currently are so they can traverse from one party to another. The idea would be some form of social networking phone application with a list of all party goers and which bar or venue they are currently at. So one could check on their phone where all their fellow party finder users are and either join them or get together.

This could also be useful if you are not accepted to a bar and to join some friends and you want to find some other friends to join so that the night is not spoiled.

The liver & wallet saviour: Binge drinking can be a particular hazard for students young or old, and it was proposed that it would be good if there was actually some way of keeping track or the amount of alcohol consumed in order to alert the user when the amount of alcohol consumed had reached unsafe levels.

Maybe an application for a mobile phone or pda where one could chose/enter the drink or round they had purchased, and give an alert when the amount purchased reached dangerous levels.
After thinking about this I realised that the majority of people would not be disciplined or inclined to manually enter the details each time.

This led me to think about a slightly different idea, again involving a watch but requiring some hardware at the point of purchase. The user would wear a watch that would perform the usual functions of a watch, but would have some form of radio frequency tag built in, so that when the user purchases a drink or round at the bar as he/she moves their hand over the bar to hand over the money, the till encodes in the watch the value and number of drinks.

This would serve the following useful purposes:

In groups of drinkers who typically buy rounds it could show whose turn it is to buy the next round, avoiding the typical drinking argument.
The next day it would illustrate how much was being spent on alcohol. Realising that you may have spent £150+ on alchohol that week for example, would be good non-draconian way of reminding people into curbing their drinking.
The user may also realise they have spent too much midway through a night and be encouraged to slow down.
This may aid retailers in telling when people have had too much if the pre-existing value on the watch could be checked before updating.

Either way providing the basic watch functionality is not compromised, and the budget monitoring is unobtrusive, the average student drinker I think would enjoy a way of keeping track of whose round it is, while the spending total gives a "quiet" deterrent to over doing it.

The First Meeting Watch Idea

2007-10-28T20:24:00.001Z

One of the most exciting and daunting aspects of coming to a new university, whether that be as a fresher or as a new or mature student; is meeting new people. The shear number of people you meet in your halls of residence, from your course as well as teaching staff can be difficult to keep track of.

One particularly embarrassing social situation is forgetting the name of an individual you have met before. The first meeting watch aims to tackle this problem by detecting the movement action of a handshake whilst a discrete on board camera takes a video clip with audio of this first meeting.

The user could then replay the clip at their own leisure to remind themselves of the name and identity of the person they have met.

There are some practical obstacles to over come for this to be a feasible idea however:

The fact that most people wear their watch on their left wrist whilst they shake hands with their right.
Issues of camera direction to catch the person being met after the wrist moves back to the side of the body
People do not always shake hands when they first meet, this could be overcome by voice recognition activation upon detecting "nice to meet you" or so on.

Healthy Student Diet Idea

2007-10-21T20:20:00.000+01:00

When coming to University some issues faced by students choosing to cook healthy meals are:

Limited dietary knowledge.
Time consuming.
Little experimentation with new foods.
Cooking without the correct recipe items - and so students stick to simpler recipes.

It is no surprise that fast food is popular amongst students, whether it's after a night out, a microwave meal or from shops on campus. Being bombarded by unhealthy options, little time and a lack of knowledge all provide incentives to eating unhealthy meals.

The Student dietary system is aimed at giving students who wish to change their pattern of eating a chance to do so by providing useful recipes that other students have found useful.

Each recipe will contain simple facts such as how long it takes to prepare, the expected price and nutritional information. Feedback in the form of ratings and comments by other students will help a student make a more informed decision about the recipe.

A monthly schedule of meals(which are basically recipes) will enable students to create a list of ingredients against:

a specific diet (e.g. vegetarian, vegan, meat eater...),
nutritional value of recipes,
or budget.

The grocery list could send a text to the user to save writing out lists or even better - ordered over the internet and delivered at a suitable time.

Brainstorming.....

2007-10-18T21:05:00.000+01:00

From the group discussion on Wednesday 17th October we formed the following brainstorm of all the issues we could think of, for the topic of issues facing students new to university. The first image is our typed up version, and the second is the original one written down in the discussion. Click on either for a larger image, feel free to add comments if there are any issues we may have missed.