Week of Apr 13, 2003

« Week of Apr 6 < Individual Entries > Week of Apr 20 »

Stories as Pictures of the Users

processes & methodologies, usability

April 18, 2003, 01:45 PM

For my work on Usability and Software Architecture, Bonnie and Len want me to design and build a website to help disseminate our technique to professionals. In our meeting last Tuesday, Bonnie asked if I knew who the users are. I said, truthfully, that I didn't really. She replied, "Then you can't design a website."

She suggested I try writing up some personas instead of the more time intensive Contextual Inquiry process she'd taught us in Methods. So I asked Micah, who has read "The Inmates are Running the Asylum" to tell me a little bit about them. I decided Alan Cooper's full process was probably too heavyweight for this task, so I sat down to write up some portraits of our expected users based on my own understanding.

As I've thought about the high-level design of the site, I've expanded these profiles into slightly more extensive "stories of use" that describe the problems my stereotypical users will experience and what they're going to need to solve them. Of course, all I was really doing was recording and making explicit my own understanding of our users (although I've found this in and of itself is valuable); I had no evidence that my assumptions about their needs and problems were correct. So as a start, I've been asking a few of my colleagues who more or less fit the profiles to read over my scenarios and give me feedback on how realistic they seem based on their experiences. I've realized that I'm starting to follow my own Scenario-Based Design process, which makes me want to read Rosson & Carroll's "Usability Engineering" that's been sitting on my shelf since last September.

What's even more interesting about this exercise is that I find it's not just feeding into a website design, but it's giving me a better understanding of the needs of the people who will (hopefully) be using the U&SA technique. If I can sell this idea to Bonnie and Len, then I believe these profiles could be very helpful to us in evolving our understanding of our users and keeping us grounded in reality. If we want to make changes to our technique and one of us says "Wait a minute, Bob isn't going to like that change because..." then I think our discussions could become much more practical and user-focused.

I've really become sold on the power of stories as a means of driving design (and not just design of interfaces). When I first encountered scenario-based design, I'll admit, I thought it was a silly idea ("You expect people to take me seriously when I'm making up stories about people using our system??"). But since then I've seen the pragmatic value and unparalleled communicative power stories possess; people can share your vision of the system when you tell them a story in ways they can't when you just list functional requirements (or even show them screen mockups). Stories keep your thoughts concrete even as you envision that which does not yet exist. I'm beginning to believe that no design team can be effective without them.

Got Something to Say About This?

Email Rob:

OR Post a Comment:

 

Enter the number below into the text box next to it.*


 

* These fields are required. Your email address will not be publicly displayed. Your web address is optional, and will be publicly displayed if provided.

Allowed HTML: a href, strong, em, ul, ol, li, blockquote, dl, dt, dd, dfn, code, q, samp, kbd, var, cite, abbr title, acronym title, sub, sup

MAYA's Marketplace of Mutable Meanings

design, information, internet, software development

April 17, 2003, 12:36 AM

I went to the HCII Seminar Series talk today given by Peter Lucas, the CEO of MAYA Design (which is where Mathilde works nowadays). He talked about Civium, a "vision and architecture for a seamless, distributed public information space".

Civium is a distributed data storage system that implements an information commons through location-transparent persistence. In this sense, it's similiar to Gnutella or Freenet: information can be widely distributed across machines to provide effectively limitless physical storage space and no one machine contains the cannonical representation of one piece of information, so information is much harder to destroy. So in this sense, Civium's not very interesting.

Civium also provides various clients to visualize the information present in the distributed database. Peter demoed a geographic information system (GIS) client that accessed information MAYA obtained from publically available government sources. But I've seen several such systems before, and this one didn't appear to do anything particularly novel (except that it was potentially more extensible, as we'll see). So in this sense, Civium's not very interesting.

What is interesting is the way that Civium handles data semantics and their dissemination. At the core of the system lies VIA, a universal database. VIA isn't entirely relational or object-oriented, but instead is based on three types of entities:

  1. U-forms are sets of attribute name / value pairs with a Universal Unique Identifier (UUID) bound to them. So essentially, they're glorified hashtables that can be uniquely distinguished from all the other glorified hashtables on the network. Note that this is essentially what a RDBMS row is (provided it has a UUID primary key), so U-forms can work similiarly to relational table rows in terms of building more complex data structures using foreign keys, etc.
  2. Shepherds are software agents that push U-forms around from repository to repository (a repository is any physical storage medium connected to VIA) without having to understand the semantic meaning of the U-form content. They take care of the whole "distributed" part of the system.
  3. Roles are the schemata that define the semantic meaning of the data that appears in U-forms. But the neat thing is, Roles are stored in U-forms themselves. So if you need to discover the semantics of data in a U-form you've found, you just need to locate the data's Role U-form from the VIA system. If you want to extend an existing Role, you just need to insert your own U-form into VIA that includes the modifications you need and references the original Role.

Assuming that the semantics of Role U-forms are defined by the system (Peter skipped most of his slides on Roles, unfortunately), then this system essentially implements a "free market of data formats" in which anyone can create new formats or use existing ones, no one has control over a particular format, and market forces can determine which formats become "standards". I don't know of any other systems that provide real architectural support for this concept.

Granted, I have my doubts as to whether this approach would truly be effective in improving computing's recurring "format wars". After all, the browser wars of the ninties between Netscape and Microsoft were a good example of market forces influencing a shared format, HTML, while the relevent standards body, the W3C, stood by and watched, irrelevent. And that was a bad time to be a web developer. But at least in Civium, we wouldn't wind up with one powerful monopoly corporation controlling the format that won out.

Whether market forces, rather than standards committees, are truly the best way to produce consensus on data semantics and representations is a question I'm not prepared to answer. But Civium, if it ever becomes a major force, will certainly put this idea to the test.

Got Something to Say About This?

Email Rob:

OR Post a Comment:

 

Enter the number below into the text box next to it.*


 

* These fields are required. Your email address will not be publicly displayed. Your web address is optional, and will be publicly displayed if provided.

Allowed HTML: a href, strong, em, ul, ol, li, blockquote, dl, dt, dd, dfn, code, q, samp, kbd, var, cite, abbr title, acronym title, sub, sup

Tell Me Why

usability

April 16, 2003, 11:42 AM

I have a quick complaint to register about every desktop interface framework that I've ever used (which includes Windows, Mac OS X, Java's cross-platform Swing, and Linux/KDE).

I was recently reading a Word document created by one of my bosses, Len Bass. In this document, he uses a word that is specific to a particular domain (software security) and hence doesn't appear in Word's spelling dictionary. So I wanted to add it. I got the following screen:

WhyCantIAdd.png

Apparently I cannot add this word to the dictionary. I can tell this because the "Add" menu option is grayed out and when I mouse over the menu option, it does not highlight like all the other ones do. So far so good; the system is providing feedback to the user (me) that he cannot perform this action and is preventing him from selecting the erroneous option, which prevents slips and mistakes.

But why can't I add this word? Now there may be a very good reason; maybe I haven't selected an appropriate dictionary, maybe I don't have write access to the dictionary, maybe I'm in the wrong edit mode, or maybe Word has decided that no one would possibly want to add "nonrepudiation" so it has helpfully overridden my judgment to prevent this grevious user error. But here's the problem: I don't know what Word's reason is.

Because I don't know why I can't add this word, I have no way of knowing how I can correct my error. And this is a problem that runs through most every option deselection mechanism I've encountered; there is no toolkit support for the developer to provide this important feedback to the user. The developer can say "sorry, you can't do this" but he can't say why.

Toolkits should provide this support, and developers should use it. Providing a simple tooltip that gave this feedback would be enough, and would save users like me a lot of headaches.

Got Something to Say About This?

Email Rob:

OR Post a Comment:

 

Enter the number below into the text box next to it.*


 

* These fields are required. Your email address will not be publicly displayed. Your web address is optional, and will be publicly displayed if provided.

Allowed HTML: a href, strong, em, ul, ol, li, blockquote, dl, dt, dd, dfn, code, q, samp, kbd, var, cite, abbr title, acronym title, sub, sup

An Affinity for Thinking

personal, processes & methodologies

April 15, 2003, 10:22 PM

As part of my website redesign (which will be coming any day now! Really!) I'm attempting to come up with a good set of categories to help organize the content of this here weblog you're reading. I tried brainstorming a list of my interests and stuff I'm likely to want to post about, but the list quickly grew to unmanagable proportions. So I decided to try a novel exercise: I built an affinity diagram of my (intellectual) life.

LifeAffinity.JPG

For those of you who aren't familiar with the process, to build an affinity diagram you collect a large amount of unstructured information (could be brainstormed ideas, could be problems users are reporting with your product, in my case it was the list of my interests) write each piece down on a separate sticky note, then post the sticky notes to a whiteboard. When you put up a new sticky note, you place it near other sticky notes that it seems "related" to. When all the sticky notes are placed, you look at the mass o' notes and pull out the larger groups and categories that magically appear from your organization process. The magic comes from helping you to translate a complex cognitive task performed on lots of data (pulling together all that information in your head) into a spatial organization task, which we humans are much better at.

In my case, I brainstormed a list of my interests that I might want to post about. Then I augmented this list by scanning the titles of the books on my bookshelf, the lectures I listen to, the bookmarks in my browsers, etc. to pull out any interests I may have overlooked.

I then went to the whiteboard I have at work (had lots of stickies; needed big board) and started affinity diagramming. One discovery I made as I went along was that every time I'd built an affinity diagram in the past, it would inevitably break down into "bucket sorting" before all the stickies were up, meaning that we'd come up with the categories too soon and just start plopping stickies into the appropriate category instead of considering their affinities with other nearby stickies. This time I carefully avoided doing that, and I think I wound up with a more insightful affinity as a result.

Then I stepped back and started drawing categories. There was a lot of overlap between the groups of stickies, which is good; that means my interests are fairly interconnected. I was also encouraged to discover that technology-related interests, although significant, did not dominate the entire affinity. So it appears that I'm not becoming too narrow in my intellectual foci.

Somewhat less encouraging was how disconnected my "charity" interests were from the rest of the diagram. Also, some of my professed interests, such as playing music, martial arts, and eastern religions, didn't appear or only appeared in small, disconnected pockets. I certainly have more developing to do in some areas.

All in all, I'd say this was an interesting exercise; I gained a little bit of a deeper understanding about myself as a result of the process. I may repeat it again in a few years just to see how the landscape of my thoughts has changed.

I'd recommend giving it a shot if you have an hour or two to kill and a pack of spare stickies. Of course, whether it has actually solved my original problem of developing good weblog categories remains to be seen...

Got Something to Say About This?

Email Rob:

OR Post a Comment:

 

Enter the number below into the text box next to it.*


 

* These fields are required. Your email address will not be publicly displayed. Your web address is optional, and will be publicly displayed if provided.

Allowed HTML: a href, strong, em, ul, ol, li, blockquote, dl, dt, dd, dfn, code, q, samp, kbd, var, cite, abbr title, acronym title, sub, sup

CHI Report, Ode to Good Friends

life & times, people, personal

April 13, 2003, 01:22 AM

This entry is private. Forgot the password? Ask the Keymaster!

Got Something to Say About This?

Email Rob: