Usability Inspection
of the 2nd Video Demo Interface

Hyowon Lee
11 July 1999

This is the usability inspection result I did based on the 10 most common heuristics (see Notes at the bottom), and resultant recommendations. The interface inspected was the 2nd version of our Web video demo system I had designed in June (substituting Ger Quinn’s initial design).

These obvious usability problems should be corrected before doing any user tesing.

  • In online TV schedule, link text should be the title, not the time. Users are focusing on a unique program they want to record, not the time (Speak the user’s language – clicking a title is to more user’s point of view). After all, we are providing this online schedule so that they can browse programmes, not involving them into exact time specification. This is the typical example of user-interface developed by programmer – to the sytsem point of view, it is to get the exact unique time of recording that counts, but the whole point of online TV schedule is to allow users to select program by title. Allow the user to click the program title.
  • In exact time/date page, setting default values to current is very good. But: Start Time should be, say, 5 minutes LATER than current time, so that if you want to record from now, you only have to set End Time (Shortcuts – minimise user action).
  • Need to show what’s already set to be recorded (Simple and natural dialogue – show the current status). How can we show what’s already recorded?

In exact time/date page – show red timeline as it is now.

In online schedule page – any program that overlaps should be highlighted with red mark or shot note "set to be recorded" beside the program title.

If these are done properly, we don’t even need to provide error message saying ‘time overlap’. The basic idea of Error prevention - best way of designing is to allow only what’s available to the users so that there is no way a user can make an error in the first place.
  • Any way to cancelling the record setting? – Conventional idea is that it is better to provide a way of Allowing reversal of user action. User might submit recording by mistake and want to do another recording. Users might want it because recording one program prohibits recording other program at the same time line (and simply clicking Back button of the browser does not undo what you have already requested). But most cases, wrongly requested recording does not matter because in our system the users are not concerned with recording space – recording space is perceived limitless to users). Rather, having a way of reversing the recording request can be more risky because it’s a deleting action (although he can again request recording if what he reversed turns out a wrong action). We don’t want person A to be able to cancel person B’s request. Maybe it’s okay to leave it as it is now.
  • System reaction is too slow. When you click a keyframe, RealPlay window should start playback quicker than it is now. How can we determin user’s video browsing behaviour when the system is not quick enough to grab the realistic user behaviour? I suggest that if we are to find out user’s video browsing behaviour, we use a non-Web based system with very prompt response time.
  • In exact time/date page, ‘No Title’ text in Title blank should be something like ‘(Give any name here)’. When a user comes to this page, it means he wants to record something that doesn’t correspond exact program schedule unit, which means there cannot be a proper Title already set. The term ‘Title’ is confusing because it indicates program title and in this page it doesn’t (Speak the user’s language – confusing terminology problem).
  • Change the button label ‘Submit’ to something else – maybe ‘Complete the setting’ or ‘Done’ or ‘Request recording’…. (Speak the user’s language – what user wants to do is to pre-set recording).
  • In recorded program list, link text should be the title, not the date. Users are focusing on a unique program they want to watch, not the date (Speak the user’s language – clicking a title is more user’s point of view).

Users will want to know the length of each recorded program in the list. Delete month & year – the record list is only for several days so month & year is all the same and not necessary to display. Delete quotation marks for title. Link should be the program title, not the time or date. So the new list format could look like:

 

:

23 JUL 17:30 RTE1 (55min)

KNIGHT RIDER

21 JUL 04:00 CHANNEL4 (1h 15min)

TINY TOON ADVENTURE PART III

20 JUL 13:20 BBC2 (30min)

CORNWALL ECLIPSED

:

(*suggestion - date/time/channel/length : Arial –2,
title: bold Arial –1,
and maybe colour coding some of date/time/channel/length info )

By making fonts like this, the format of one program per 2 lines can be mostly kept and looks more organised (Simple dialogue – "gestalt rules" for human perception). Also a separating lines can be inserted between programmes, if preferred.
  • Somewhere we should mention that recorded programs will be removed in 2 days (or any other number of days that we decide later).

 

For our demonstration purpose, we don’t need to try to make the interface perfect for now. It will be more important to find out major behaviours of users and major changes to make, and later on when things are more concretely designed and implemented we can do more thorough, nitty-gritty inspection.

 

Notes


I keep the following 10 heuristics, and used them for the above evaulation.

There are different sets of heuristics but mostly are similar to each other (eg. Compare Jacob Nielsen’s and Ben Shneiderman’s). I keep my own, but almost same as Nielsen’s, and I note some details to remind me.

Obviously, there are items more frequently identified as problematic than others in our system inspection, and some are not applied at all. For example, ‘Help & Documentation’ support was not considered for this particular inspection, Consistency was considered well kept so was not mentioned in the above inspection, Simple & Natural Dialogue was often found violated thus mentioned frequently.

 

  • SIMPLE AND NATURAL DIALOGUE (match the task, simplify, graphic design & colour, prioritise, etc.)
  • SPEAK THE USER’S LANGUAGE (messages in user’s point of view, metaphor, etc.)
  • MINIMISE USER’S MEMORY LOAD (list terms for browsing, generic commands, etc.)
  • CONSISTENCY
  • INFORMATIVE FEEDBACK
  • REVERSAL OF ACTIONS
  • SHORTCUTS (default values, action history, type-ahead, recently opened files list, etc.)
  • ERROR PREVENTION
  • GOOD ERROR MESSAGES (self-explanatory, specific, constructive, polite, etc.)
  • HELP & DOCUMENTATION