Video-tagging Database
With the recent advent of ultra-mobile personal computers, or netbooks, combined with the ever-increasing storage space available, users are storing larger and larger collections of video on portable devices. They want choice access at a time convenient to them without having to carry cumbersome amounts of storage media. This system will gather information about the user's film collection from IMDb (the Internet Movie Database) and add tags (pieces of data linked to a role, e.g. 'director = Robin Hardy', 'actor = Christopher Lee') to a database . The user can then specify criteria to filter the database.
For example, the user could specify the criteria that:
a) the director is 'Darren Aronofsky';
b) the actor 'Sean Gullette' is in the film;
but that c) the actor 'Hugh Jackman' is not in the film.
and the system would return results from the user's film collection.
The system should also allow the user to display information on and play videos.
Usability of the filter feature
Since this is a complex feature, the prototype and subsequent user-evaluation will focus solely on the interface for specifying filter-criteria and returning results.
The evaluation will be performed using the think-aloud protocol with a post-evaluation questionnaire.
Tasks for the user to perform
For the evaluation, the user will be told that they want to watch a particular film, but they have forgotten the name. They know that the film is directed by Darren Aronofsky, that the actor 'Hugh Jackman' isn't in it -- that was The Fountain -- and that one of the main characters is called 'Marion'.
The users will be asked to think aloud. They will then be presented with a paper representation of the screen and told to find out the name of the film.
Prototype
Questionnaire
The questionnaire has been designed to reduce bias. It aims achieves this by repeating and rewording the same question with the scale of answers switched (e.g., 5 = Agree, 1 = Disagree would be come 1 = Agree, 5 = Disagree). It is viewable online here.
Tuesday, 24 February 2009
Thursday, 29 January 2009
Block 3, Studio 4 | Design Principles
80/20 Rule
Definition
80% of effects generated by a system are caused by 20% of its variables, provided that the variables are influenced by many small and unrelated effects, i.e. large, distributed systems that are used by many people in many different ways.
Example
Microsoft noted that 80% of error were fixed when they fixed the top 20% of reported bugs. - http://www.crn.com/security/18821726
Categories
5: More design time can be put into beneficial features.
Connections to Norman's design principles
Visibility - if the critical 20% of features are more visible than the remaining 80%, total visibility increases.
Affordance
Definition
An affordance is where physical properties of an object suggest a particular use. When the affordance corresponds with the intended use, productivity increases.
Example
It's arguable that now a keyboard, or even the alphabet printed in a grid, invites us to type.
Categories
1: Affordances are all about influencing the way a design is perceived; using affordances to influence the use of the system.
3: If your design suggests its own use, it will be very usable.
5: It is better to design something self-explanatory.
Connections to Norman's design principles
Affordances - however, Lidwell et al also apply it to "abstract contexts (e.g., software interfaces)". They agree with Norman by saying that only physical objects have affordances, but say that the images of the physical objects are said to have perceived affordances.
Constraint
Definition
Constraints provide a method to improve usability of a design by both restricting errors with physical constraints and suggesting intended uses with psychological constraints.
Example
Physical - An ATM cash machine will only give you your money once you have taken your card -minimises the chance of a user leaving their card behind.
Psychological - Coloured buttons on a mobile phone - green means 'start phone call' and red means 'end phone call'.
Categories
3: By restricting the erroneous uses, the intended use is more apparent, i.e. the system is more usable.
Connections to Norman's design principles
Constraints - Norman defines three categories of constraints: physical, cultural and logical. Norman's physical constraints fall within Lidwell et al's 'barriers' category; Lidwell et al also define paths, which redirect unwanted physical motion, and axes, which extend the motion of forces.
Cost-Benefit
Definition
An investment is only worth it if the benefit is equal to or greater than the cost (in terms of money and time).
Example
It wouldn't be worth going to work in the morning if the cost of travelling was greater than the amount in your wage packet.
Categories
3: Adding rarely-used features can over-complicate the design, adding cost to the user.
5: More design time can be put into beneficial features of a system.
Connections to Norman's design principles
Visibility - By weighing up cost and benefit, less useful features can be removed leaving the remaining to be more visible.
Errors
Definition
Lidwell et al put errors into two categories - 'slips' and 'mistakes'. The former, slips, are where the error made is unintentional, i.e. pressing the wrong button accidentally. The latter, mistakes, are where the error is in the person's thought process or planning, i.e. misinterpretation. They recommend using confirmation dialogs, affordances/constraints and allowing forgiveness.
Example
Imagine shredding an important document by mistake and later realising. To allow for forgiveness, you could create a pile during the day for paper 'to be shredded' -- condemned paper -- and shred all of the paper at the end of the day. This is implemented on various computer desktops as a 'recycle bin', 'trash can' or 'waste basket', an affordance that allows forgiveness.
Categories
2: If people can revisit correct their mistakes, next time they will have a better chance of not repeating the mistake.
3: A usable design should reduce errors, or, when errors are made, allow 'undo'; it is usually quicker to correct mistakes inline rather than to start again.
Connections to Norman's design principles
Affordances & Constraints - These are designed to reduce errors.
Five Hat Racks
Definition
The Five Hat Racks principle states that information should be sorted by one of five methods, as appropriate: alphabetical, time, location, continuum, category. The method of sorting can also be used to highlight certain properties of an object.
Example
An index of a book is presented in alphabetical order for when a user is searching for a specific entry, whereas the contents is divided into more general categories.
Categories
1: Users will have a better perception of which information is being presented.
3: The information presented will be more visible and hence more usable.
Connections to Norman's design principles
Visibility - If the information is properly sorted, it will be easier for the user to search for relevant data and hence more visible.
Appendix A - Lidwell et al's five categories
1. How can I influence the way a design is perceived?
2. How can I help people learn from a design?
3. How can I enhance the usability of a design?
4. How can I increase the appeal of a design?
5. How can I make better design decisions?
Definition
80% of effects generated by a system are caused by 20% of its variables, provided that the variables are influenced by many small and unrelated effects, i.e. large, distributed systems that are used by many people in many different ways.
Example
Microsoft noted that 80% of error were fixed when they fixed the top 20% of reported bugs. - http://www.crn.com/security/18821726
Categories
5: More design time can be put into beneficial features.
Connections to Norman's design principles
Visibility - if the critical 20% of features are more visible than the remaining 80%, total visibility increases.
Affordance
Definition
An affordance is where physical properties of an object suggest a particular use. When the affordance corresponds with the intended use, productivity increases.
Example
It's arguable that now a keyboard, or even the alphabet printed in a grid, invites us to type.
Categories
1: Affordances are all about influencing the way a design is perceived; using affordances to influence the use of the system.
3: If your design suggests its own use, it will be very usable.
5: It is better to design something self-explanatory.
Connections to Norman's design principles
Affordances - however, Lidwell et al also apply it to "abstract contexts (e.g., software interfaces)". They agree with Norman by saying that only physical objects have affordances, but say that the images of the physical objects are said to have perceived affordances.
Constraint
Definition
Constraints provide a method to improve usability of a design by both restricting errors with physical constraints and suggesting intended uses with psychological constraints.
Example
Physical - An ATM cash machine will only give you your money once you have taken your card -minimises the chance of a user leaving their card behind.
Psychological - Coloured buttons on a mobile phone - green means 'start phone call' and red means 'end phone call'.
Categories
3: By restricting the erroneous uses, the intended use is more apparent, i.e. the system is more usable.
Connections to Norman's design principles
Constraints - Norman defines three categories of constraints: physical, cultural and logical. Norman's physical constraints fall within Lidwell et al's 'barriers' category; Lidwell et al also define paths, which redirect unwanted physical motion, and axes, which extend the motion of forces.
Cost-Benefit
Definition
An investment is only worth it if the benefit is equal to or greater than the cost (in terms of money and time).
Example
It wouldn't be worth going to work in the morning if the cost of travelling was greater than the amount in your wage packet.
Categories
3: Adding rarely-used features can over-complicate the design, adding cost to the user.
5: More design time can be put into beneficial features of a system.
Connections to Norman's design principles
Visibility - By weighing up cost and benefit, less useful features can be removed leaving the remaining to be more visible.
Errors
Definition
Lidwell et al put errors into two categories - 'slips' and 'mistakes'. The former, slips, are where the error made is unintentional, i.e. pressing the wrong button accidentally. The latter, mistakes, are where the error is in the person's thought process or planning, i.e. misinterpretation. They recommend using confirmation dialogs, affordances/constraints and allowing forgiveness.
Example
Imagine shredding an important document by mistake and later realising. To allow for forgiveness, you could create a pile during the day for paper 'to be shredded' -- condemned paper -- and shred all of the paper at the end of the day. This is implemented on various computer desktops as a 'recycle bin', 'trash can' or 'waste basket', an affordance that allows forgiveness.
Categories
2: If people can revisit correct their mistakes, next time they will have a better chance of not repeating the mistake.
3: A usable design should reduce errors, or, when errors are made, allow 'undo'; it is usually quicker to correct mistakes inline rather than to start again.
Connections to Norman's design principles
Affordances & Constraints - These are designed to reduce errors.
Five Hat Racks
Definition
The Five Hat Racks principle states that information should be sorted by one of five methods, as appropriate: alphabetical, time, location, continuum, category. The method of sorting can also be used to highlight certain properties of an object.
Example
An index of a book is presented in alphabetical order for when a user is searching for a specific entry, whereas the contents is divided into more general categories.
Categories
1: Users will have a better perception of which information is being presented.
3: The information presented will be more visible and hence more usable.
Connections to Norman's design principles
Visibility - If the information is properly sorted, it will be easier for the user to search for relevant data and hence more visible.
Appendix A - Lidwell et al's five categories
1. How can I influence the way a design is perceived?
2. How can I help people learn from a design?
3. How can I enhance the usability of a design?
4. How can I increase the appeal of a design?
5. How can I make better design decisions?
Thursday, 15 January 2009
Block 3, Studio 2 | Applying Qualitative Usability Methods
Problem
Information overload
Selected section of video
0.00 - 0.18
Key to coding system ¹
Using a hierarchical system:
GIVE_INF - Give information
REQ_INF - Request information
CONF_INF - Confirm information
.FLIGHT
.LOC - (Location)
Transcript
Customer: OK, so we could go to Los Angeles -- REQ_INF.LOC
Agent: Yes and that's going to give you more flexibility. CONF_INF.LOC
Customer: -- and then if we wanted we could go from Los Angeles to anywhere else in the States. REQ_INF.LOC
Agent: Yes, CONF_INF.LOC
as long as you're all booked in. ²
Agent: Um, and that's going to give you, obviously, as I say, you can just -- that's going to New Zealand GIVE_INF.FLIGHT
-- so you can stop through the Pacific GIVE_INF.LOC
-- that uses Ansett -- GIVE_INF.FLIGHT
so you can travel around Australia... GIVE_INF.LOC
Graphs of frequencies of utterances
This first graph shows the relation between the amount of information requested on locations and the information recieved. It shows an equal balance which does not suggest any information overload.
This second graph, however, a comparison between the requested and received information on flights, is unbalanced. In fact, the customer did not ask about flights at all during the excerpt. The agent gave 2 utterances concerning flights, where the customer gave none. This imbalance between requested information and received information points to information overload.
¹ Based on examples by John Halloran
² Possibly GIVE_INF.FLIGHT, but depends on conformation from data prior to this excerpt
Information overload
Selected section of video
0.00 - 0.18
Key to coding system ¹
Using a hierarchical system:
GIVE_INF - Give information
REQ_INF - Request information
CONF_INF - Confirm information
.FLIGHT
.LOC - (Location)
Transcript
Customer: OK, so we could go to Los Angeles -- REQ_INF.LOC
Agent: Yes and that's going to give you more flexibility. CONF_INF.LOC
Customer: -- and then if we wanted we could go from Los Angeles to anywhere else in the States. REQ_INF.LOC
Agent: Yes, CONF_INF.LOC
as long as you're all booked in. ²
Agent: Um, and that's going to give you, obviously, as I say, you can just -- that's going to New Zealand GIVE_INF.FLIGHT
-- so you can stop through the Pacific GIVE_INF.LOC
-- that uses Ansett -- GIVE_INF.FLIGHT
so you can travel around Australia... GIVE_INF.LOC
Graphs of frequencies of utterances
This first graph shows the relation between the amount of information requested on locations and the information recieved. It shows an equal balance which does not suggest any information overload.
This second graph, however, a comparison between the requested and received information on flights, is unbalanced. In fact, the customer did not ask about flights at all during the excerpt. The agent gave 2 utterances concerning flights, where the customer gave none. This imbalance between requested information and received information points to information overload.
¹ Based on examples by John Halloran
² Possibly GIVE_INF.FLIGHT, but depends on conformation from data prior to this excerpt
Thursday, 27 November 2008
Studio 9 | Prototyping pervasive computing
What challenges to prototyping does pervasive computing present?
Prototypes can be expensive to develop. One way to overcome this is to use approximation of functions within the prototype.
Experience prototyping, where researchers and designers become actual users helps:
Successes in prototyping pervasive computing
The document details the use of Coordinated Views software to prototype a handheld peer-to-peer communication/orientation system for use during the 'City Chase' race, however, the researchers permitted use of alternative resources. They found that the software was little used. Subsequent to the race, in interviews with the participants, the researchers learned that the system was only really used whilst the participants were stationary (i.e. riding transport). Also, they were able to ascertain that the participants were hesitant to use the system in the rain.
The first Marked-Up Maps prototype worked by attaching RFID tags to the back of a paper map. A user could then hold a PDA up to the front-side of the map and view information about the place they were hovering over. Originally intending to help guide the group of researchers to a conference, the prototype's glitches were not solved and so they were left with one user touring the city alone. Even so, this type of experience prototyping did prove to be in their favour, since the researcher/user was able to overlook problems which were solely due to the prototype's limitations.
Prototypes can be expensive to develop. One way to overcome this is to use approximation of functions within the prototype.
Experience prototyping, where researchers and designers become actual users helps:
- Mitigate the participating researchers' bias toward the technology.
- Designers to distinguish between problems with the prototype and problems with the design.
- Impractical for longer-term uses, since requires 'wizards' behind the scenes controlling the system.
- Only incomplete/rough applications of the system which aren't suitable for end-users.
Successes in prototyping pervasive computing
The document details the use of Coordinated Views software to prototype a handheld peer-to-peer communication/orientation system for use during the 'City Chase' race, however, the researchers permitted use of alternative resources. They found that the software was little used. Subsequent to the race, in interviews with the participants, the researchers learned that the system was only really used whilst the participants were stationary (i.e. riding transport). Also, they were able to ascertain that the participants were hesitant to use the system in the rain.
The first Marked-Up Maps prototype worked by attaching RFID tags to the back of a paper map. A user could then hold a PDA up to the front-side of the map and view information about the place they were hovering over. Originally intending to help guide the group of researchers to a conference, the prototype's glitches were not solved and so they were left with one user touring the city alone. Even so, this type of experience prototyping did prove to be in their favour, since the researcher/user was able to overlook problems which were solely due to the prototype's limitations.
Thursday, 20 November 2008
Studio 8 | Identifying research activities and methods
Research Activities
Four workshops, all videotaped with 'key utterances' transcribed. Also, a school fieldtrip.
Workshop 1 focused mainly on interview -- the curators pointing out key locations and points of interest through the use of a map. This helped to solidify researchers' ideas of requirements for the system.
Workshop 2, consisting of three guided tours of the grounds, in succession, by three different curators. Researchers observing to try to solidify knowledge of requirements even more. Also, video and audio recording were made which could be used with the system.
Workshop 3's main purpose was to convince the curators of the power of the new system; new ideas for tours, i.e. dynamic tours led by the end-user as opposed to static, linear tours led by the curator.
School fieldtrip, again, helped to convince curators of the power of the system. Observations by researchers helped to test the system's capabilities.
Workshop 4 aimed to wrap up the other workshops and further convince curators of how the system can develop. Curators show developed understanding of technology.
In the initial interviews, the research team were confronted with the curators' preconceptions that a tour should be fixed and a lack of understanding of how technology could be applied to change this. To change this, the research team used several prototypes to demonstrate the capabilities. Firstly, reorganising previously recorded audio clips and running a 'Wizard of Oz' prototype. Later on, a practical demonstration involving end-users was used (the school fieldtrip). A video of previous applications of similar technology was also employed, showing the 'Ambient Wood' project.
Through discussion and observation, both in real-time and by analysing recorded video and audio, the team were able to gain a picture of how the tours were currently being led. This, in combination with more discussion, developed into ideas for a ubiquitous system.
All research methods used were qualitative.
Four workshops, all videotaped with 'key utterances' transcribed. Also, a school fieldtrip.
Workshop 1 focused mainly on interview -- the curators pointing out key locations and points of interest through the use of a map. This helped to solidify researchers' ideas of requirements for the system.
Workshop 2, consisting of three guided tours of the grounds, in succession, by three different curators. Researchers observing to try to solidify knowledge of requirements even more. Also, video and audio recording were made which could be used with the system.
Workshop 3's main purpose was to convince the curators of the power of the new system; new ideas for tours, i.e. dynamic tours led by the end-user as opposed to static, linear tours led by the curator.
School fieldtrip, again, helped to convince curators of the power of the system. Observations by researchers helped to test the system's capabilities.
Workshop 4 aimed to wrap up the other workshops and further convince curators of how the system can develop. Curators show developed understanding of technology.
In the initial interviews, the research team were confronted with the curators' preconceptions that a tour should be fixed and a lack of understanding of how technology could be applied to change this. To change this, the research team used several prototypes to demonstrate the capabilities. Firstly, reorganising previously recorded audio clips and running a 'Wizard of Oz' prototype. Later on, a practical demonstration involving end-users was used (the school fieldtrip). A video of previous applications of similar technology was also employed, showing the 'Ambient Wood' project.
Through discussion and observation, both in real-time and by analysing recorded video and audio, the team were able to gain a picture of how the tours were currently being led. This, in combination with more discussion, developed into ideas for a ubiquitous system.
All research methods used were qualitative.
Thursday, 6 November 2008
Studio 6 | Identifying research methods (1): Reading
With respect to usability testing of ubiquitous computing, ethnography entails:
- Testing 'in situ' or 'in the wild', i.e. within the situations which it would be used.
- Gathering of internal evidence, i.e. 'text messages... generated by users in their interactions together', as well as the more traditional external evidence such as observational recording of interactions.
- Can You See Me Now?, which involved online players interacting in a 3D model of the world with performers in the real world using GPS and WiFi technologies. The idea was that the performers had to catch the online characters by interpreting the GPS data.
- Uncle Roy All Around You, following on from the previous game, where the players were both in the streets and online. The goal of the game was to find 'Uncle Roy' by interpreting location-based clues and interacting with performers on the street.
- Savannah, an educational game designed to teach children about lions in the African savannah by overlaying a virtual environment on a school playfield using handheld computers, GPS and WiFi technologies.
- Treasure, where teams of players interact with handheld computers using GPS to pick up virtual coins. However, in order to store the coins, players have to take their handhelds within a WiFi hotspot. If an opposing team gets within their range before they reach the hotspot then their coins can be stolen.
Wednesday, 15 October 2008
Studio 2 | Reading Week 2
1 & 2: The idea of being 'usable-in-life' is that, although something may seem impressive in an abstract situation, i.e. usable-in-itself, the technology should be tested within the context of its everyday use.
3: According to the article, the iPod is designed to be as simple to use as possible, yet responsive in all situations. The paper cites the example of being able to increase the volume of the music whilst the user is jogging as evidence for usability-in-life. 'Excellent mappings' and 'consistency' are cited as reasons for the usability-in-itself of the iPod,
3: According to the article, the iPod is designed to be as simple to use as possible, yet responsive in all situations. The paper cites the example of being able to increase the volume of the music whilst the user is jogging as evidence for usability-in-life. 'Excellent mappings' and 'consistency' are cited as reasons for the usability-in-itself of the iPod,
Subscribe to:
Posts (Atom)