 |
« | Week of Jun 22 | < | Individual Entries | > | Week of Jul 6 | » |  |
 |
 |
Patterns and U&SA
patterns, software development, usability
July 05, 2003, 06:00 PM
At the command of my bosses, I'm working on researching the relationships between our U&SA scenarios and the software patterns found in Design Patterns and Pattern-Oriented Software Architecture Volumes 1 and 2. So far, I've gone through Design Patterns and compared the "Applicability" sections where the Gang of Four discuss the conditions under which you may want to use that pattern to the "Responsibilities" we've identified for each scenario and thought out whether the two seem to connect in any meaningful way.
I've found surprisingly many potential relationships between the Gang of Four's patterns and our responsibilities. However, it's difficult to say much that's concrete about these relationships without dictating a particular implementation. The responsibilities alone could be fulfilled by many systems (that's their whole point); the patterns may apply to some of these systems, but others they may just succeed in complicating unnecessarily. This was certainly a problem I encountered with EE; the first architecture I came up with, taken from a book on developing Websphere applications, was far more complex than it had to be for EE's requirements. Even after several refactorings, EE's architecture is probably more complicated than it should be. For this reason, I'm wondering if its possible to give meaningful implementation advice without at least assuming a particular domain, such as Windows desktop applications, web-based applications using J2EE, etc. And even then you run the risk of suggesting solutions for problems the team doesn't have. Since we have neither the expertise nor the desire to pronounce on optimal design strategies in all these possible domains for all possible requirements, maybe its just not possible for U&SA to say much at this level of detail.
On the other hand, it may be useful for developers to have a sense of which patterns may help implement the scenarios and how. This could have several benefits, including:
- Helping the team determine how to implement the scenarios without impacting other important quality attributes, such as modifiability or performance. A fear that the scenarios will negatively impact these other attributes is one of the three main reasons a team may not implement these scenarios (the other two being that they were deemed too expensive or time-consuming to implement and that the team simply did not consider them), so this could be a major boon.
- Saving the developers time in investigating solution options. We've already collected several best-practice solutions in the patterns literature for them, they just need to make these concrete for their system.
- Getting the interface designers' input on what changes, if any, need to be made to the patterns. For instance, some of the patterns don't support returning feedback on the results of an operation (Observer comes to mind). This may be a problem if user feedback on the results of the operation is required to implement the interface design.
All in all, I think this has been a useful (if tedious) investigation so far and is helping us move forward with U&SA. We are planning to publish a paper on the U&SA framework soon, hopefully in CHI and/or ICSE, which is something I've been advocating for awhile since I think we really have come up with something with potential here. Definitely something to look out for, and it'll have Rob's name on it, so you know it's got to be good :).
The Last Straw and a New Itch
internet, personal
July 04, 2003, 02:15 PM
AmphetaDesk has annoyed me for the last time. After having to manually change the localhost port from 4888 to 8888 since it sometimes randomly decides to launch the browser with the wrong port number in OS X, I wanted to see the exact time a couple new weblog entries it harvested were posted on, and of course it does not display this information. So I trashed it, for good. The next news aggregator I use will be Newsable, or my name is not Robin James Adams.
So there.
Email Rob:
How User Research Feeds Future Usability Activities
usability
July 02, 2003, 11:01 PM
Andy commented on my Personas and Open User Research post over on his Blozom News weblog yesterday. He suggests the use of task modeling, which appears to be a technique for expanding the users tasks into specifications for the system responses. Basically he wants to make the line between the Personas and Scenarios that I wove my hands at more explicit.
I think this is a great idea, and it points to the power of having a user research technique such as personas in place. The information on the users' goals and tasks a project collects through this user research feeds in to many "downstream" usability activities that I didn't discuss in my manifesto, such as getting to an actual interface design, testing that design, etc. For example, many usability techniques assume you know what the users' tasks are:
- Think-Aloud Usability Testing, as well as its many less formal variants, usually requires the experimenter to give the participants a standard set of tasks they must attempt to perform with the interface. The experimenter then looks for any problems his users consistently run into and redesigns the interface to prevent them. But if the tasks he's testing aren't tasks his real users want to perform, then usability testing is worthless.
- Cognitive Walkthroughs involve an in-depth analytical test of how well the interface supports certain tasks, down to the level of a series of questions that the analyst must answer about each step in fulfilling the task. But again, this analysis is wasted if the tasks tested aren't tasks real users perform. Moreover, the answers to many questions in cognitive walkthroughs depend on assumptions made about the user which are likely to be incorrect if not backed up by solid empirical research.
- GOMS is another analytical technique that estimates how long it will take an expert user to perform given tasks (and thus tests for efficiency of use rather than learnability or ease of use). But again, its no good to any expert if she can perform tasks she never actually needs to perform blazingly fast.
"Know the user" techniques like persona development form a solid foundation for almost all future usability activities. With personas in place, techniques like task modeling, cognitive walkthroughs, usability testing, etc. provide valuable insights into how the interface should be designed and whether this design is usable for the target audience. Without them, these future activities are compromised since they may rely on faulty assumptions about the users' needs.
Email Rob:
The Design Process
design, processes & methodologies, teaching & learning
June 30, 2003, 04:11 PM
Today was my first day of Communication Design Fundamentals (CDF), the prerequisite studio-based design course for the HCI program here at CMU. We started off the course with an exercise in the design process where the teacher, Karen, gave us a pile of semirandom household implements and asked us to arrange them into an ordering so that someone who walked in the door could understand just by looking at them how they all related to each other. Apparently this is a common exercise for introducing students to the design process.
The design process Karen described goes like this:
- Familiarization, where you work on understanding the domain and what the general relationships between objects in that domain are. For us, this involved figuring out what each implement does (difficult, since there were some weird items. No one got the Fijian cannibal's fork...) and grouping them into some general functional categories.
- Development, where you start to define the general structures and groupings. We divided the "kitchen items" and "art items" into separate areas, organized the kitchen items into a circle and the art items into a grid, and divided into two teams to manage the arrangement of each.
- Refinement, where you start to focus on the nitty-gritty details of the design. This is where we separated out the various piles of items we made into groups separated by whitespace and aggregated by function or appearance.
It struck me as we were going through all this how similiar it was to other design processes I'm familiar with, like the HCI user interface design process and the software system design process. In HCI, you start by studying your users and trying to understand their needs, their desires, their tasks, and their gripes, which is part of familiarizing yourself with the domain. My persona development process for open source software is an example of a technique used at this stage. Next you design the high-level information architecture and rough screen designs for the application, which is equivalent to the development stage. Finally you build higher-fidelity mockups that you can actually run user tests and analytical checks on, the HCI version of the refinement stage. In software development, you frequently familiarize yourself with the technologies (although this stage is often skipped, to the detriment of many projects), develop a high-level architectural design, and then refine this design into detailed class hierarchies and object interactions and finally down to actual source code. And as Karen pointed out for the design process, at each step you frequently must move to the next step to see if your design ideas will work or not. A strict "waterfall" approach to the design problem rarely works.
When we got to organizing the structure of our designs, one group had put items into a basic circular structure, the other had used a grid. Karen pointed out how design decisions such as these can determine the structure of your later decisions. Her off-the-cuff analogy described this as similar to cutting a pie; the first cut you make determines the positioning of all the future cuts. So when you make those early decisions, you need to make sure are careful and have your audience's needs in mind. This is quite similiar to the classic software architecture problem; the architecture of a software system encompasses those decisions made early on that determine what is easy to change and what is difficult. Its interesting to reflect on how much these apparently different design processes have in common.
As we were progressing through this exercise, Matt remarked that this was an example of experiential learning; Karen gave us a specific problem to work on first, then helped us generalize our experience to all of design. She didn't lecture per se, instead she interjected comments and suggestions as they we needed them to help solve the example problem. It was a neat approach; I'm excited about teaching in this style with Matt for our TCinC summer course, which starts tomorrow.
This session is shaping up to be a lot of work, but it looks like it will be interesting work and thus bearable. It's also great to hang with my fellow part-time HCI students who are all in CDF with me (sans Mathilde). I even get to see Neema again regularly, which is a rare treat. Good times all around.
Email Rob:
Personas for End Users
usability, writing & communication
June 29, 2003, 07:59 PM
While plugging away at Newsable's architecture yesterday, I came up with a possible side benefit of the open-source personas strategy that I am attempting to apply to this project.
One problem I frequently encounter while searching for a new piece of software to meet some new need I have is that, although I know what task I need it for, I can't necessarily tell how the features and screenshots shown on a potential application's website will help me accomplish that task. I usually only download or buy software if I know someone who had the same need and is satisfied with how a particular application fulfilled it (this is how I learned of OmniGraffle; my friend Matt was a satisfied customer who talked me into trying it). Otherwise, I frequently have to download the application, install it, and use it for a few days to see if it appears to do everything I want it to. This is a pain in the ass and takes a lot of my time, so I don't generally download a whole lot of new software.
If, on the other hand, the applications' websites had accurate personas online describing the people and tasks they designed the application to support, I might be able to assess how well the application will fit my needs before I download it. If the fictional people described by the application seem to be similar to me with respect to their needs and tasks, I can assume the application has been designed to support my tasks and thus is worth spending the time to check out. This isn't too far from the idea of testimonials or "day in the life" scenarios, which marketing departments have used for ages to try to get consumers to purchase their products.
I have no idea if the average user would be willing to read a persona when making a buying decision, but it doesn't seem much different than reading a product review or a brochure. So perhaps this technique has potential for end users as well as interface designers.
Posted by Dan on June 29, 2003 at 11:15 PM
An interesting thought, but for most commercial products, the number of personae have to be considerably collapsed into a core group of them: like 5-7 if they are going to be truely useful. It would be asking a lot for computer-illiterate Grandma Jean to recognize that computer-illiterate Billy Bob, a "mechanic from West Virginia", is the same persona. I'm pretty sure personae should only be used by the design team.
However, one thing that could be shown is a more task-based or task-flow look at the application. "Do you want to do this? It'll look like this. Then you can do this, and it'll look like this," etc.
Posted by Rob on June 29, 2003 at 11:29 PM
Hi Dan,
You might be right; I was thinking as I wrote the post that the downside of the idea is that personas don't necessarily depict J. Random User with 100% accuracy; as you pointed out the personas do describe different people than the real users (Billy Bob rather than Grandma) and J. Random User may be unable to distinguish between what's "important" (whether the persona's needs with respect to the application are similar) from what isn't.
Maybe the list of scenarios would work better, since it's more like the task-based look at the application you describe. I have a first cut at these for Newsable posted at: http://www.newsable.org/personasBobTasks.php
Email Rob:
Email Rob: