Wednesday, 25 February 2009

Lo-fi Prototype

1.



(click on them for a larger image)

2. My concept is to create a GPS(Global Positioning System) for a mobile phone. This should be able to tell people where they are, what street they are, street names around them and other buildings or landmarks around them. It should also be capable of giving the user directions to certain locations.

3. The man thing that I will be focusing on in the GPS for the lo-fi prototype is the navigation aspect. I will want to make sure that users can easily and quickly find there way around the system without any problems. They should be able to understand what all of the buttons on the phone do, in relation to the display.

The prototype will not focus on any other aspects of the phone and it will no focus on the display side of things. Basic graphics will be used, the users will not be able to do things such as scroll around the map, or be bale to view directions to any places. They will only be able to see a restricted amount of things on a very small map.

4. The users will be asked to;
  • Find the map from the main menu
  • Enter a location for directions
  • Navigate back to the map after entering information
  • Change the display settings so they can see different things on the map
  • Change the general settings
  • Quit the system
These tasks will vary for different users, but the main aim of them is to make sure that they can navigate through the interface easily.

Sunday, 8 February 2009

Block 3 Blog 4 - Design Principles

Lidwell at al's 5 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?


80/20 rule

The 80/20 rule is a princible of design that basically says that 80 percent of the effects of a system are caused by 20 percent of it's variables.

Example

An example of this is a web browser, there are many things you can do in a web browser. A lot of people do not know about most of these things, but the main things that users need are shown in the toolbars at the top, such going back, forward or typing in a URL. These functions represent 20% of the available functions, while there actions represent 80% of he things a user would want or need o do.

Categories

1.
5.


Affordance

Affordance is related to what something is designed to do. One of the examples given talks about door handles. A flat plate is used for pushing and a handle is used for pulling. A door that does this has a better affordance than a door that uses a handle for pushing and pulling.

Example

Laptops afford mobility. Most laptops, especially newer laptops are made so that they can be easilt tranported to other places, and carried with you. So you can work on the go, easily.


Categories
1.
2.
3.
5.


Constraint

A constraint is something that limits what a system can perform. The two basic types of constraints are physical and psychological constraints. Physical constraints control where or how something or part of something can move, while a psychological constraint is something that limits the amount of things people can do by thinking about how people would already perceive things. So this links directly to symbols, mappings and conventions.

Example

One form of a physical constraint would be a wire. I two things are connected by a wire, users know that the two devices could not be used together if the wire was taken away, such as a mouse and computer. The mouse has to stay within a certain distance of the computer for it to work properly.
An example of a pyschological constraint would be a so not disturn sign. This doesn't stop people from doing anything, but if people were to see it outside of an exam hall, they would know they need to keep quiet for obvious reasons.

Categories
2.
3.
5.


Cost-Benefit

The cost-benefit princible talks about only persuing something if it's benefits are equal or greater to it's cost. Basically, if something costs a lot, but isn't very beneficial or useful it has a poor design. If something has a low cost and is beneficial it has a good design. Systems doesn't always have to have a low cost to have a good design though. If something is vital to a system you it wouldn't matter as much if it was expensive. Cost isn't always related to money either, it also includes factors such as effort.

Example

An example of this is the lock switch on the bottom of an iPod. The switch is small not easy to use without tipping the iPod and looking at it. But if you keep your iPod in a small pocket, or somewhere buttons might be pressed accidentally, it stops songs or settings from being changed, which makes it a good design.

Categories

3.
4.
5.


Errors

Errors are things that can go wrong in a system, or performing an action and getting thw wrong result. These usually happen because of human error, but these human errors are usually caused by a design error. Errors can be kept by giving as much feedback as possible, or using things such as confirmation screens.

Systems can also help problems with errors by enabling people to undo errors easily.

Example

Flash Actionscript error, or errors that occur when using any programming or scripting language. When you try to run a program, whatever program you are using, two different things can occur. The prgram either runs, or you are given an error message. The error message usually contains what went wrong. But sometimes the message is hard to understand.

This is good and bad, for someone who is used to using the program, it provides good feedback about what they need to do. For someone who is not familiar with a program it can be confusing and frustraing. Especially if they think everything was alright.

Categories

2.
3.
5.


Five Hat Racks

Five Hat Racks states that there are five ways to organise information. By Category, time, location, alphabet and continuum.

The five hat racks princible states that there is a limited number of ways to organise information, regardless of the application.

Example

An example of this could be for computers. Information about them could be ordered by;
Category - what type of computers they are(laptop, desktop)
Time - How old the computers are, when they were manufactured
Location - Where you are buying them from
Alphabet - All computers sorted alphabetically
Continuum - This could be used for many different things, including price, RAM and many other specifications of computers.

Categories

1.
2.
4.
5.


Normans Principles
(Visibility, Feedback, Constraints, Mapping, Consistency, Affordance.

The 80/20 Rule links to Visibility and Mapping, since the rule is mostly related to since this rule is about users being able to see the things most. It is related to visibility because these things should be the most visible, and mappings because that is related to where these things will be placed.

Affordance and Constraints are already part of Normans Principles as well. Affordance and constraints can also easily be linked with each other.

Cost-Benefit can be related to mapping and consistency because if functions on a device are placed in poor positions, or an option does not follow the general pattern of everything else within a device then these things may become more of a problem to use than a benefit.

Errors can be linked with all of the principles. Poor visibility, and not being able to see the right things can lead to errors.
Feedback needs to be given when errors occur, and feedback can also prevent errors from occuring in the first place, by explaining what certain functions do.
Constraints can stop users from performing actions that could lead to errors.
Good mapping could also prevent errors while poor mapping could lead to a higher number of errors.
If a device is not consistent errors can easily be made, for example, if two things look like they work in the same way, but don't, errors can easily occur.
If deviceslook like they are used for things which they are not supposed to be used for, they would have a bad affordance. This could also lead to many errors.

Five Hat Racks is related to visibility and feedback because it is related to how people see things, and what they see after selecting certain options.

Thursday, 22 January 2009

Block 3, Blog 3 - Methods Reading

Short Summary of Harry Brignall's Dynamo Paper

  • "The Dynamo system was developed to support multi-user interaction with digital media on a large surface"
  • Two levels of user engagement. Anyone can interact with one, only registered users can use the other level - Carving
  • 'Carven' areas are parts where registered users can create their own areas, and only people they choose can interact with this area.
  • Users can also use parcels, which allow media to be posted and left on the display for 'extended periods of time in an iconified form'.
  • User study - Dynamo was deployed in a common room for 6th form students, because it was a place people regularly socialized between classes
  • Students, at first, mostly used Dynamo to share photo's video's and music, but in the second week it was used for a wider range of things such as parcels.

Qualative data

Page 4 Final paragraph. Lists the different types of user interactions.

Page 7 Paragraphs 3 and 4 under section 6: discussion. These wo paragraphs include comments from students about the Dyanamo system and what was good about it.

Quantative data

Page 4 Paragraph 1(after list). States the number of students that could be involved in the study

Page 5 Figure 5. Shows how many interactions were made with the Dynamo system at specific times during the day.

Qualitative Data represented Quantitatively

Page 5 Figure 6. The graph shows the amount different types of media that was displayed on the Dynamo surface throught the 2 weeks. The qualitative data is the different types of media on the surface, the quantitative data is the number of each of the different types of media that were displayed.

To do this they user a bar chart. They used one bar for each day of the two weeks. Each bar added up to the total of items displayed on the board during that day. Each bar also contained the number of different types of media that were displayed. This helped show which types of media were displayed the most, and which types the students used the least.

Wednesday, 21 January 2009

Block 3 Studio 2 - Applying Qualitive Usability Methods (Parts 1 and 2)

Part 1 - Coding Ethnographic Data

Research Problem: Information Overload

"Er do you have any record of this because it's hard to remember and i'd like to give a copy to my boyfriend"

Customer: Ok so we could go to Los Angeles...
Agent: Yes. And that's going to give you more flexibility
Customer: and then if we wanted we could go from Los Angeles...
Agent: Yes. As long as you're booked in
Customer: ...to anywhere else in the States

Agent: Um and that's gonna give you obviously as I say
you can just - that's going to New Zealand
so you can stop through the Pacific that uses Ansett
so you can travel around Australia Umm


Coding

REQ_INF - Request Information
.LOC Request - Information about Location
CONF_INF - Confirm Information
GIVE_INF - Give Information
.EXP - Explain Information
.LOC - Give Information about location
.FLIGHT - Give information about flight details


Customer: Ok so we could go to Los Angeles...
REQ_INF.LOC
Agent: Yes.
CONF_INF
And that's going to give you more flexibility
GIVE_INF.EXP
Customer: and then if we wanted we could go from Los Angeles...
REQ_INF.LOC
Agent: Yes.
CONF_INF
As long as you're booked in
GIVE_INF.EXP
Customer: ...to anywhere else in the States
REQ_INF.LOC

Agent: Um and that's gonna give you obviously as I say
GIVE_INF.EXP
you can just - that's going to New Zealand
GIVE_INF.LOC
so you can stop through the Pacific that uses Ansett
GIVE_INF.FLIGHT
so you can travel around Australia Umm
GIVE_INF.LOC

Other coding that should be added but is not relevant to this part of the transcript would include;

REQ_INF .FLIGHT
.COST
GIVE_INF.COST


Part 2 - Analysis

Graph 1 - Main Sections

Graph 2 - Requested Information

Graph 3 - Giving Information


The first graph shows that just under 55% of the utterances were information being given. While requesting information came just over 20% with just under 20% being confirmation. The third graph shows that half of the information given is information(which would be around 25% of the total) being explained. This suggests that customers may not understand much or all of the information or that the agent feels that customers will always need the information explaining. Which means that the information being given could be too complex or hard to easily understand.

The second graph shows that all of the utterances requesting information were related to location, which shows that customers may have trouble following what locations they are going to a different times, or where different flights were taking them.

Block 3, Blog 1 - Applying Quantative Usability Methods

The Cashless System at the Ricoh Arena


Above: Cashless card on tray. This is where the card is placed during a transaction.
Below: Video, what happens during a transaction, how long it takes and the current feedback.



Attribute: Feedback

Measuring Concept: Receive requested feedback

Measuring Method: Time taken for feedback to appear and user to read and understand feedback

Now Level: System changes colour when it is safe to remove card from tray, no other feedback such as balance is given.

Worst Case: Balance appears after transaction, but takes too long to appear and too long to read.

Planned Level: Balance appears after transaction, is easily visible and doesn't take long to appear.

Best Case: Balance appears while using card, not just after a transaction. Display shows price before use, price of product purchased, and the remaining balance. The display would update quickly, and be easy to read, and clear after card is removed.


Metrics(Measuring Method)

  • Time taken for feedback to appear
  • Time taken for user to read feedback
  • Time taken for user to understand feedback
  • Time the whole transaction takes
  • Number of problems occurred*
  • Time for problems to be resolved
  • Number of unresolved problems
  • Number of user complaints
  • Average queue time**

*Some problems could include things such as the card not being accepted, the balance not displaying, taking too long to display or not displaying at the right time, and cards not displaying the correct balance.

**This isn't completely relevant to the feedback attrivute, but since the queue time ties in with the main aim of the system it would be helpful to note whether the added feedback is cutting down or adding to queues.