DonnaM » 2004 » August

Archive for August, 2004

Human-information interaction

Tuesday, August 31st, 2004

I’ve been spending ridiculous amounts of time lately thinking about the difference between known and unknown information seeking (and all of the grey areas in between).

I think that part of the reason that I spend so much time on this is that I have a usability background, not a LIS background, but the type of IA work that I do (big messy intranets and government websites) is a combination of usability/user-centred and information science.

The usability and user centred field just haven’t come to grips with the idea of exploratory information seeking. Most of the usability/UCD techniques revolve around known tasks. The UCD focus on personas and scenarios, and the usability testing focus on scenarios all assumes that people know what they want. The focus on task analysis is about a known task (I had a long argument with someone recently who suggested that an IA for a site should be done by undertaking a series of hierarchical task analyses. Yeah, right!). This is not unrealistic considering that the background was primarily in task-based software development, not in decision making and information gathering.

And I still think that the LIS field haven’t come to grips with the fact that there are people on the end of their precious content (OK, this is a generalisation as I’m not as deeply involved in this field, but I have been spending *lots* of time reading IS journals and I spend a lot of time with LIS folk). Their focus is on beautifully describing records/pages and making them findable by a search engine.

The most valuable work that we are involved in requires a strong understanding of these two fields, beyond just the surface rhetoric. We need to deeply understand the things that people want to know and the different ways that they approach information, and the difficulty of designing for unknown, impossible to articulate, exploratory information seeking tasks. And we need to deeply know about the behaviours, decision making methods and cognitive capabilities of people.

And you probably expected me to conclude with a way to do this, but I haven’t figured out that yet, except to say that human-computer interaction in this domain is really about human-information interaction (HCI/HII?).

Stay posted as I muse.

A usability problem in my posts

Friday, August 27th, 2004

Over on maadbooks, Kenneth pointed out an interesting usability problem with my posts. I often finish an entry with an ellipsis (…), especially when I have posted something that is a bit vague or when I don’t make a proper conclusion.

RSS readers indicate that there is more to read with an ellipsis, which is sensible as it does indicate ‘more’. So when he reads one of my lazy posts that end like this, he thinks there may be more, goes to check and doesn’t find anything new. Not a good user experience!

I have broken my so, habit. Now its time to break my ellipsis habit and start to write conclusions rather than sentences that drift off. We’ll see how I go.

Designing in the car

Wednesday, August 25th, 2004

I designed a set of alternative home pages for a client site today. But I didn’t design them in the normal way, in front of the computer or at my desk – I designed them in the car, in my head.

I did the first design on the 45 minute drive home from work, and revised it on the 25 minute drive back to university (in between Amber’s endless questions about how everything works). Now that I have done the hard thinking work, all I have to do is do the computer work to document the designs.

Living miles away from everything, with a long stretch of empty highway, is a very good design tool…

Slow brain, slow connection

Tuesday, August 17th, 2004

I’ve had a few glasses of wine tonight after a long, tiring day of report writing and am now trying to dig research articles out of journal databases.

I was watching the little page load icon in Firefox spin around and realised that my brain feels as slow as my internet connection, which is saying something as I’m on rural dial-up. Maybe I should go watch the Olympics instead…

Announcing Maadbooks

Monday, August 16th, 2004

Announcing another site into the Maad collection … Maadbooks.

My husband and I read a lot and buy a lot of books. Maadbooks is a collaborative effort and contains book reviews for the books that we love most – user experience, society, brewing, winemaking, food, fantasy and more. The content is slim at the moment, but we don’t expect it to be something that you read today and forget tomorrow. Although run with a blog tool (WordPress) and blog style in format, we don’t expect this to be the type of site that you have to ‘keep up with’ but a resource for when you need more books and need a friend to recommend them.

We’d love to know what you think, so leave feedback here or there. And come back later as we catch up on reviews.

Designing in the dark, part 2

Thursday, August 12th, 2004

I wrote yesterday about an interesting discussion I had with about a development process that has no user involvement, and mused on how it would be possible to create a good system in a situation like this.

I had some interesting comments here, so I thought I might expand on some of my beliefs – it’s good to question your own rhetoric sometimes ;)

Although my post implied that I thought programmers should have some involvement with users, I’d like to clarify that. I think that it is very important that programmers gain an understanding of the user group and their needs. Even if they have a good set of specifications (yeah, right) or a prototype or good design to follow, that understanding will help with many of the small decisions.

However, I do not believe that programmers should be doing the requirements gathering process or the interface design.

Now it’s not that I think that programmers can’t talk to users. I believe that programmers think in a *very* different way to the users (unless they are writing a product for other programmers, and that isn’t terribly common). Programmers are fabulous at solving problems – the cognitive capabilities to create code are similar to those that we use to solve problems. They are so fabulous at problem solving that they see a problem and think of a solution, immediately. What they aren’t so great at is seeing lots of conflicting problems, determining the underlying cause, thinking about it some more, and then designing a solution. That’s an entirely different way of thinking. Every programmer I have ever personally known collapses at this point – conflicting priorities and individual differences frustrate them to no end.

So how do I think it should be done? Requirements gathering and design are one process, not two (which I probably should elaborate on further another day), so should be done by one person (or one team in a big project). The most difficult issues for this person is then communicating the important parts of the requirements or the design to the people who are going to implement it. There are lots of documented methods, many of which I have never managed to get to work. The things that do work for me are:

  • involving programmers in some representative user contact
  • doing lots of sketches for people who can understand my diagrams
  • lots and lots of discussions (not arguments)

Actually, on thinking about it, the thing that works best for me is respect. I show respect for the abilities of people that I work with, and they usually show respect for me. This means that we discuss ideas, problems and solutions rather than arguing about *my* design. I don’t know how you build a methodology on that!


  • I stole today’s post title from Opposable Thumbs, because it was far better than my original title
  • I’m not the first to say this – many people have put it more eloquently than I
  • I know lots and lots of incredibly talented programmers, and recognise that they think very differently to the way I think, so this is not an anti-programmer post


Wednesday, August 11th, 2004

You know, I’ve spent more time despamming my blog lately than I have writing it. I run MT-Blacklist, which is usually fabulous, but have a persistent spammer who manages to get around it. Need to figure this out…

How do they do it?

Wednesday, August 11th, 2004

User centred design has spoiled me. I cannot conceive of how other people undertake systems design.

I was talking to a programmer today who works for a business who does business software development for a large client. Their process is that the client sends a requirements document, they go back and forth a few times to sort out some detail, and he codes the software or enhancement.

He never, ever sees a user, does not know who they are or what they do. The client has some user contact, but it is limited, and he has never spent time watching how people go about their day to day work. The requirements that are documented are very basic and never describe any more than the bare bones of what they want done.

I simply cannot imagine how this process could create anything even semi-decent. I know from my design experience that to create a good design (not even a great design), I need to understand the context. I need to know what the users already know, what they are doing at the same time as this task, what’s around them. These are the details that provide me with the information to take the magic leap and create a design that works. Without them I’d be making it all up, and there is little chance that it would be right.

Swapping design for art

Wednesday, August 4th, 2004

I’ve just finished a small redesign and complete recoding of a site for an artist friend (Ross Townsend Gallery). I changed the site from tables to CSS-based, did some tidying of the design and changed the IA completely. Muuuuch better… (have a look at the old version).

The best thing is that we did it as a swap – I get a great painting, Ross gets a good site…