WEEK 8: Gesture interfaces, Touch screens and other future challenges of HCI

In this week’s lecture we went through some further challenges for HCI in an opinionated discussion. First we looked at touch screens and gesture interfaces. Whilst they do provide a more natural way of interaction than traditional keyboard and mouse, I would argue that this naturalness is limited. There are only so many movements that can be done to perform functions, which feel natural with touch screens and gesture interfaces (e.g. flicking up to push a page out of the way). After that any extended functionality must be achieved by learning a kind of sign language, no different really to un-natural command shortcuts on keyboards. I guess it might turn out that gesture commands once mastered turn out to be quicker and less prone to error. But really the point is that at the advanced level they aren’t any more natural than a keyboard. Also touch screens need to develop a better feedback before the use with them becomes properly fluid. The Blackberry Storm tried to do it by turning the whole screen into a button that must be pressed to select anything, but surely that defeats the point of a touch screen. I think that this paradigm of interaction may be rather short and will be replaced by something better.

One of the other points of discussion was Bumptop;  a new concept 3D interface, which uses a physics engine to simulate how real documents act and then allows you to manipulate the document objects in certain ways. I guess it’s supposed to make it easier to organize docs. The thing is there are blatantly ways of implementing this sort of functionality using command prompts etc in a normal desktop like "windows". It looks like it would take forever to find things. What’s wrong with a search bar? It’s almost like it’s on a level with just having all your documents scattered across your room in a more or less organized fashion. Computer operating systems are suppose to create solutions to file storage, not replicate clumpy real world ones prone to error. It may be better than having all your documents on the desktop like in picture (a), but who the hell is actually that disorganized. Plus check out vista and apple interfaces and the problem is pretty much sorted with their neat and tidy taskbars and shortcut bars. The one aspect I did like was the making important docs bigger, but this could be done just as easily on a normal desktop by right clicking and left clicking on a function that would call it.  After the lecture I had a debate with a fellow student. He was responding to my point that you can’t be organized in mess. He claimed that people have ways of organizing things in their own mess, and that their mess can make them better at tasks. Well my response to that is that if they see organization, it’s not mess in the first place! Anyway really a rather trivial debate over a subjective matter, but quite amusing nonetheless.

In the seminar we re-designed the Sussex websites in groups. Some took a social networking “Facebook” approach, others a more functional approach. Generally people’s approaches were all quite similar and focused on a practical solution. This is because everyone agreed in large that the site should be informative rather than an area for fun, although many did suggest a social chat function. Our group suggested that since it’s a nightmare to find rooms on campus, it would be beneficial to have a 3D simulated virtual environment of campus that could take you from A to B in a video. Perhaps this could be linked up to student’s ‘Smartphones’. The exercise pointed out that the Sussex websites are very badly designed, and also since our solutions were similar that the course has worked to get us all to think in certain ways.

We also carried out some of our user tests for the Traveline project this week, with more to follow intensively over the next week. This turned out to be a revealing experience. It was alot more complex than we first imagined. We rented a room out in the library and brought our laptops in. After complications installing ‘Teamviewer’ (the software used to view and record user screen data over the internet), amendments to the script, problems with the quality of the “Skype” broadcast, problems with a foreign girl not understanding us, and so and so forth; we managed to get a number of users to successfully complete the tasks we set. This led to some useful data and the experience as a whole served as a step to better organization in later sessions. We realised that the complications (particularly the availability of user participants at set times) and over arching time constraints on the project, meant that we might not be able to hit our user number of 36 with a completely balanced demographic. Nonetheless our sampling will still be demographically led, and we will endeavour to get as many users as possible in order to get the most complete data and find all the problems in the sites. With another session today, hopefully we will learn even more.

WEEK 7: Iterative evaluation

This week we looked at the process of iterative evaluation. The focus was on constant evaluation through all development stages of user centred design. This process is tied in with early ideas being prototyped, tested and evaluated, improved, prototyped some more, evaluated, etc. In doing so the process hopes to increase functionality, usability & user experience, and to debug problems at an early stage as possible. This of course leads to a better product. We were told that in industry most times engineers fail to follow an iterative process. Only evaluating after the product is complete and then shipping the product regardless of the result. This leads to a bad product that suffers from loads of usability issues, produces a bad experience and loses the company profit. I'm amazed that the corporate world can be so irrational at times, but then that’s bureaucratic company politics for you.

 

The iterative evaluation process forms a main part of our Traveline client projects. Earlier in the week our group had another meeting to work out the next set of actions. We needed to work out the requirements in order to focus the user tasks in an appropriate way. After a brain storming session we decided that we would try and build the requirements from the perspective of a Traveline user. What would a user want from the website? They would need to know the travel times in an understandable format, the cost of the journey (this was a big area of debate in the group, but we finally agreed that clearly that if price info was not shown, users would go elsewhere), the reliability and convenience of the travel routes, and finally an encouragement to choose public over private transport. These requirements would form the basis for designing the user tasks. In the next meeting we aim to finalise the scenarios under which users will be tested, which will be conducted using a combination of screen readers and telephone interviews (pre and post task). There was talk in the group today after the seminar that we might look into filming people’s faces using web cams to capture emotions; but I’m not convinced that it will provide particularly useful data given our lack of knowledge in facial expression psychology. Also whilst user experience is important, I believe we should be aiming for a quick and efficient experience over a fun one mostly. People don’t use travel sites for fun, they want info quickly and reliably. Anyway more updates on the project process next blog.

 

With academia aside, I thought seeing as this is a blog I might have a quick rant on the mobile phone upgrade I got a couple of weeks ago; the Nokia N78. I got it because it had internet and mp3 mainly. But the usability is terrible. Firstly the processor is not powerful enough to run the operating system properly, leading to slow feedback times when buttons are pressed and ultimately to a bad experience. Secondly the mp3 software is badly designed. There’s no option anywhere to move quickly between the play/pause screen and other phone functions, meaning that everytime you want to change track you have to navigate through about 5 pages (multiplied by the slow screen loading). To make things worse there isn't a play/pause or skip track button on the phone. So the phone has mp3 functionality, but it’s a nightmare to use and so rates very low on usability. Thirdly the internet is slow and charges you per MB usage. Also with no QWERTY keyboard, typing web addresses is a nightmare. Also the designers put a shortcut key to Vodafone live on the main page which can easily be pushed accidently leading to a connection to the web that charges you. Obviously this can be changed but whys it there in the first place! Just to round it all off, I was excited that it supported GPS. But of course you had to download the software separately (another charge) and then pay a subscription. All in all a bad user experience and the reason why I will be trading it in for a G1 android, which I hear great things about. That’s less money for Nokia due to bad user design!

 

It’s interesting to note that it wasn't till I'd lived with the phone for about a week that I properly noticed all of this and formed my negative opinion. I think you really have to understand what it's like to live with a piece of technology on a day to day basis, before you can form a proper opinion. Maybe this is something user centred designers should seriously take into account in their user testing for certain devices. Jeff Hawkin founder of the company PalmPilot for example carved up a prototype of the first PalmPilot to the dimensions of a real one and carried it around with him to see if he could live with it. This prototyping (as well as others of course) led to an incredibly successful product.

Week 5 & 6: Generating Requirements & Prototyping

We had two lectures this week because of the lack of lecture in the previous week. Since we have now formed our group for the client based presentation, had two meetings and started to come up with a plan for the project, it will be possible now to relate the topics to the project as it develops. In the first part of this blog I will bring the reader up to date with my group's progress in the client project. Then I will come back to relate the project to this week's topics.

After two group meetings we have established a number of issues for the project. I was apointed team leader, which involves liasing with the client, organizing meetings and making sure everyone has access to resources and meeting transcripts. In the first meeting we established that we would test users from a theory neutral perspective, and then make our suggested changes based on test results and a more theoretical backbone. In this way, the user would come first (after all this is user centred design) and our research would not be damaged by our own biases at an early stage. After the first meeting we had all realised the large scope of the project and so organized a further meeting a few days later.

In the second meeting we began planning the project in more depth. The first stage of planning involved working out our user demographic and how to test them. For our project we decided that this would be broken down in to three age classes (18-40, 40-60 & 60+) and two gender sub-classes (male and female). For each of the four websites one user particpant from each of the classes will take part in the user tests, giving a total of 6 users for each website (i.e. a male and female from each of the three age classes) and thus 24 in total over the four sites. This user population should give more than enough data to gain some significant insight into usability issues of the websites, although some might argue it would full short of scientific rigour in terms of statistical significance. Unfortunately time constraints mean we must fall short here, but nonethless the results should be valuable. We have rather cleverly got hold of a screen reader so that we will be able to remotely view our users as they navigate the sites. This will also allow us to do things like record the number of clicks and errors etc. Furthermore since this can be done without us being present in the room with the user it will make it easier to get people to participate and will also allow the tests to run in a more natural fashion (i.e. without one of us peering over the user with a notepad). We will speak to participants over skype or mobile phone and guide them through exercises (details to be decided). Following the exercises we will ask them a few related questions in an informal way so as to gain the greatest insights. We believe people do not respond well to overly structured interviews that contain too many specific questions. We will also organize a specialist focus group with around 10-15 foreign students to find out if there are any culture/language barriers the websites need to address. We ideally wanted to do some disability tests as well, but were told this may be very difficult. However our results should lead us onto somthing we can use to develop the changes we see fit.

To go back to the lectures given today there are a number of relations that can be made between the lecture material and the client based project. We will look into detail of the requirements for the website in the near future. We would like to liase with the client to establish if there are any particular requirements they would like to be addressed. We will also work out more requirements (both functional and non-functional) following user tests. In terms of user profiles, potentially anyone could be a user (all ages and abilities) of the Traveline websites and our demographic is intended to represent this. Our reasoning is that 18-40 year olds are mostly familiar with using the web in everyday life, including potentially making travel plans. This is our first user profile. Our second profile 40-60 year olds generally know how to use the web, but are less likely to widely use it, particularly if the web sites are inaccessible or badly designed. Our third profile 60+ did not grow up with the web, nor to many of them use it to plan their everyday lives. We believe this could change if they were shown the huge benefits it can have, and moreover that the sites they use are designed to take into account their usability issues. Finally our foreign student profile should allow us to look into language/culture barriers. These four user profiles will be explained in more detail when the presentation is given to the client. Following the user tests we should also be able to draw up some scenarios and use case examples to demonstrate usability issues encountered. Hierarchical task analysis should allow a systematic break down of the user tasks set and allow us to evaluate user action with more rigour.

In terms of prototyping, it is difficult to say exactly what we will use at this stage. However so far mockup web pages and functional widgets have been suggested, both of which can be demonstrated to the client in the presentation. Our prototypes will follow from a combination of our user results and some expert knowledge / theoretical backbone. This topic will be discussed again in a later blog when the project is further developed.