April 2004 Archive
In the London Eye
Several weeks ago I posted a poll asking where you wanted to see me. “In the London Eye” received the most votes.
Shortly after I posted the poll, my parents visited me in London. Not having been to the London Eye yet, I thought it would be a fun thing to do on a Sunday afternoon. This photo of me and Janine was taken by my mother about half way around the Eye.
Yes, Janine is the one that I’ve hinted about before here.
Two Airport Extremes
I just read Adam Greenfield’s rant on the non-ease of use that he encountered when attempting to setup an Airport Extreme network. I also just setup an Airport Extreme network. I wasn’t going to say anything about it, but after reading how disappointed Adam was with the whole process, I thought I would add my own 2 cents.
Adam wanted to use an external antenna with his Airport Base Station, but mistakenly bought the model that doesn’t have an external antenna port.
First of all, it turns out the Dr. Bott antenna is only compatible with AirPort Extreme base stations with an antenna port, a requirement which is noted only in fine print on the product’s box and an affordance which is provided on only the more expensive of the two AirPort Extreme base station models currently offered. Did you know there were two different models available? I sure didn’t. You have to parse the language on Apple’s product page pretty carefully to figure this out, because it’s only obvious in retrospect. And, for what it’s worth, the packaging of the two models is similar enough that when I had presented my selection (the modemless $199 option - why would I need a modem?) to a store clerk and specifically asked him if it was compatible with the antenna, he said yes.
I’m not currently using an external antenna, but I wanted the option to be available in the future so I wanted to buy the model with the extra port. Right after I read “starts at $199” on the Airport homepage, I assumed that there were different models available. Granted, the rest of the Airport homepage isn’t exactly clear about which model contains an antenna port, but the technical specifications page is very clear about it. I proceeded to the specs page and knew exactly which model I needed to buy. Adam proceeded to the store clerk and asked him which model he needed to buy. If I’m going to drop $199 on a hardware purchase, I’m not going to leave my experience up to a store clerk.
Adam’s next point of complaint was with the Airport Setup Assistant.
You’ll recall that Nurri’s (Panther-equipped) laptop had the plain vanilla AirPort card as opposed to the Extreme variety, which is the only excuse I can conceive of for the base station’s manifest failure, even though it’s ostensibly backward-compatible. I set up the base station with, naturally, the AirPort Setup Assistant, configured it to require a password compatible with the 40-bit WEP security offered by 802.11b, and figured we were good to go.
I figured wrong. For the next two hours, I tried to get both machines to automatically recognize the network, and consistently wound up confronted with an error message that the password I had entered was incorrect. After just setting the password. Myself. Multiple times. In fact, I never did get a stable network up and running, for even one of our two boxes.
I also used the Airport Setup Assistant to setup my network, but unlike Adam, I didn’t encounter any problems. It was as simple and straightforward as I expect any Apple product to be. My network differs from Adam’s in that both of my Macs have the plain vanilla Airport card, which by Adam’s logic would only seem to create more problems, but it hasn’t. Both of my Airport Macs are running happily along on my Airport Extreme network.
Adam concludes:
For all you Apple partisans I am sure to hear from: I obviously want them to thrive in the marketplace, every bit as much as you do. A quick “Sunnyvale, we have a problem” calling attention to the places where they could use a little tightening up, is more likely to help them than blandly insisting there’s nothing wrong, don’t you think?
I agree. There is something wrong. There will always be something wrong. And there will always be something right.
CHI 2004
I’ll be in Vienna 26-29 April for CHI 2004. If you’re also going and want to meet up, get in touch. If you’re hiring, I’m graduating in September with an MSc HCI and seeking employment as an interaction designer or usability specialist in London, England. I’ll look forward to seeing you there!
What Are RSS and Atom?
RSS and Atom are formats for syndicating lists of items. Items can be anything and each item typically contains a title, summary and a URL (a link to a webpage).
For more nontechnical information about RSS and Atom, see All About RSS at Fagan Finder. Or more technical information about RSS and Atom, see Mark Pilgrim’s articles on the topics at XML.com.
Design Project Summary
Okay, let’s try this again.
The design project is over, the presentations have been given and the prototype has been bastardized. I was going to post daily summaries of the design project, but upon reconsideration, I have much better things to do with my time and I’m sure you do as well. So instead of daily summaries, I’m going to summarize it all in one go, using my group’s design summary as a basis for discussion. There’s going to be some repeats from the day one summary, but for the readers’ sake I thought it best to have it all in one place. Before I get started, I would like to acknowledge the rest of my team: Sarah Brierley, Sarah Parker and Amrita Lall. Thanks for all your ideas, hard work and laughs over those two weeks.
Research
We needed to understand the aspects of the system in order to analyze existing tasks and identify user needs. We gained this understanding through researching home bars on the web, researching liquor requirements in bar and cocktail manuals, interviews with bars located near hotels (we didn’t have any target users immediately available), and email/telephone interviews with friends who would be in the target market for our home bar system.
Following our user research, we wanted to have a preliminary idea of the different concepts that should be included in the interface in order to guide our design discussions. To accomplish this, we mapped the user concepts that need to be included in the interface through whiteboard and paper drawings.
Finally, we needed a representation of the users and their scenarios in order to guide our future design work. Specifically, we needed to understand the real user motivations and goals for a home bar system. We created personas and scenarios for four key types of users: the party animal, the married couple, the upper crust and the urban socialite.
Task Analysis & Screen Specifications
We began our task analysis to define primary tasks for input to the design stage, helping to ensure that the interface design is derived from user tasks. Our aim was to define the most common tasks across all four of our personas. We used the scenarios written for our respective personas to find the generic tasks and a few other common tasks. Each of these tasks was then fleshed out by using an operational sequence diagram.
Next, we had to decide how users will navigate the system. This provided a framework for defining how the prototype interface may look. The main tasks we previously defined (search, orders, events) were used to describe a framework for interface design and functionality. As part of this process, we used some common tasks and a few edge cases to test our decisions.
We struggled with understanding what constitutes a functional specification over and above our OSDs and Task Analysis. Eventually, we decided that we should strive to understand the entities that we needed to represent in the interface and start to define how the user would navigate through the tasks defined in our task analysis. This was accomplished by creating an Entity Relationship Diagram of our system.
In order to define the input/output levels performed by either the user or the system, we first had to define to requirements for each screen. Illustrating a rough visual representation as to how the screens would look formed the basis of our development of the input/output levels for each screen. We wanted to show how each of the components inter-relates and how the interaction styles work. The ERD formed the basis for this, but only on a low level. High level was achieved by defining and specifying the interactions styles such as navigation, search/browse, how user places an order, etc.
Finally, we realised that some of the navigational features/elements that had been defined during the previous day would need to be altered, as we encountered problems with the existing form.
Prototyping
We began designing the specified screens in PowerPoint based on the whiteboard drawings. We revised the global navigation of our design, replacing “home,” “back” and “forward” with “drink,” “event” “order” and “set-up” buttons which link to all the options in the top level of the navigation hierarchy. This allowed users to get to each of these sections from all screens. The main trade-off is that some links on low level screens took users into another main section of the application, which could be slightly confusing depending on the context.
We printed all the screens currently designed, laid them out, and reviewed them by walking through key scenarios. Next, we checked consistency and navigation links. We fixed several real-estate and layout issues. We also removed the “add to order” screen as we decided it was so similar to the order screen and was unnecessary overcomplicated. The screen designs were iterated and printed.
Testing & Evaluation
The new printed screen designs of the paper prototype were then used in two pilot tests. One with a team member to practice facilitating and to check all test tasks and screens available worked together. A number of initial findings were fed back into the screen design and test designs.
The screens designs were debugged further, incorporating the findings from the pilot tests. Changes and justifications were noted on the slides. The screens were now ready for coding over the weekend. Test scripts were formalised, reviewed and iterated. By the next week, we planned to conduct formal user trials of a working prototype.
The following Monday, Amrita and Sarah Parker tested the system with three different participants, all members of our class. Amrita took notes while Sarah Parker facilitated the test. We received a lot of really fantastic feedback during testing that completly changed the way we thought about the design of the Bar Manager system.
Design Iterations
After summarizing the usability issues that arose during testing, we realized that our system had major navigation problems that we had to resolve. This led us to brainstorm for alternatives to the current Bar Manager navigation. One idea that had been mentioned previously during user testing was basing the navigation around user tasks (“I want to make a drink,” “I want to know what I have”). We all agreed that this would likely improve the usability of the system. So we began to list and prioritize the key user tasks involved.
These user tasks formed the basis for our new navigation and site map, which Sarah Brierley produced. We continued work on the new design which evolved over the next several days.
It was a crazy two weeks, but after it all, I think we were satisfied with our final design. The biggest problem we encountered during the design was navigation. The functionality was there, but getting around our first design - actually using the system - proved to be a bitch. From my perspective, the main reasons for this were lack of user research and generally poor task analysis. We could have done more of these if we actually had real users and more time, but we had neither. So we did what we could and made the most of what we had. And really, isn’t that what design is all about?
← March 2004 | Archives | May 2004 →
