The following is a transcript of a discussion between Jared Spool and Hagan Rivers. To keep true to the original discussion, we've only made minor edits.

Jared Spool: Welcome everybody. I am talking today
with Hagan Rivers and she has just published a report called “The Designers
Guide to Web Applications Part 1: Structure and Flows.” And we are going
to talk about that report a little. Hi, Hagan.

Hagan Rivers: Hi, Jared.

Jared: I really enjoyed reading this report. It is
really a neat concept. What I really liked about it, you know it has stuff
in there as before, you talk about sort of different types of structures that
a web-based application can have. It was not until I started sitting down and
reading this report that I realized that designers really have options and
the choices they make can have dramatic effect on the results.

Hagan: Yeah, we have lots of options. We have too many
options, way too many. And it is hard to sift through them and figure out what
to choose. There are lots and lots of different levels to the design and they
are all interconnected. So the first report is about structure, it is about
the bottom level. Which is almost, almost invisible in many ways in the design
process, but it has a huge effect on the rest of the design. I find that the
structure stuff can be the most difficult, because it is hard to visualize.
It is hard to see exactly what you are talking about. So that is one of the
reasons I wanted to write the report.

Jared: Now, one of the things you talk about in the
report is this idea about hubs and interviews. Can you say a little bit about
what those are?

Hagan: Yeah, well I started noticing we do a lot of
consulting with different software companies helping them design their software.
I have worked on lots and lots and lots of products. And one of the neat things
about working on such a variety of products is that you start to see patterns
emerge. You see similar things, even though they are solving very different
problems, they are using a lot of the same design structures in order to be
able to solve those problems. So I started noticing this structure, which I
called the hub, which is like this central page, were usually there is a list
of stuff on the page. Not always, but usually and there are commands. And the
user sits at the hub and they issue a command and they go to a spoke on the
hub like the spokes on a wheel. They do the things they are going to do and
then they come back to the hub and they see the list updated. And this basic
structure, I find it in pretty much every single web application that is out
there. And some of them are using the structure, but they are not using it
well. And so, they do not really understand what structure it is they are using.
So I hope to reveal some of that in the report. And then the other one is interviews,
which is, I guess, better understood as a wizard in the desktop applications.
And that is really a step-by-step process for gathering information and completing
a task. And that is another structure that is widely used.

Jared: And so these. It is not a matter of choosing
one or the other, you have to actually look at the specific part of your application
and say is one a hub? Is one an interview? Right?

Hagan: Yeah, exactly. In fact they are probably not
interchangeable in most places, but I find these two basic structures can be
used to build just about any application.

Jared: Right. So I was working, just the other day,
after reading the report, I went and I actually ordered flowers from proflowers.com,
which I think is a wonderful site and has gotten me out of much trouble in
my life. I have often thought that they should just start the home page with
a pull down that says just how much trouble are you in?

Hagan: We will help you. [laughing]

Jared: Just the right help from there, but as you are
ordering the flowers it is basically a typical order entry application, so
it is an interview structure were they first start with things about the flowers
you are ordering. Do you want balloons? Do you want chocolates? Do you want
to upgrade for, to get twice as many roses, because really for what you just
said, you are going to need the twice as many roses.

Hagan: That is right.

Jared: So they have that, but then they go on to the
shipping information and who you are shipping it to and things like the card.
And then they go on to billing information. They get your credit card information.
They ask for your billing credit card. And then they have a confirmation page.
And so that is all an interview right there. But what was interesting about
the confirmation page was that it showed all of the sections that we had just
entered. And it had a little edit button next to each one of those.

Hagan: Yep.

Jared: That was a hub design.

Hagan: That is right. Yeah, that is a blend between
an interview and a hub. And we see that a lot in very long complex interviews,
where you get to the end and the user may need to go back and change something.
So, what you do is that summary page becomes your hub and at that point each
step in the interview becomes an individual spoke that you can return to and
make changes to. It can work really, really well. It is a pretty straightforward
structure. Very effective and well understood by users.

Jared: Now, one of the things that has always annoyed
me about profiles is that you get to that page and you say, “Oh, oh you
know what, the card does not quite say what I wanted to say.” So you click
the edit button next to it. It brings you back to page that was a card, which
was the second of four in this interview. But then when you are done editing
the card, it makes you fill out your billing information.

Hagan: [laugh] Woops!

Jared: Like we need to look at that screen one more
time. And so, they did not quite get that that was a hub at that point.

Hagan: Right. That is right. They talked of throwing
you back into the interview.

Jared: Exactly.

Hagan: Yeah. That is definitely a key mistake. I mean,
at that point the user has already answered all those questions. All they need
to do is go back and fix that one thing. So, it is a little more engineering
work, because you have to present screen in two different ways. One way is
with a next button and another way is with a done button. But you know what?
It is not that hard to do.

Jared: Exactly. Yeah, as we say in the trade, it is
just a simple matter of programming.

Hagan: [laughing] how hard can it be?

Jared: Yeah, exactly. [laughter] As all the programmers
slam down the phones and refuse to listen to anymore of the podcast.

Hagan: That is right!

Jared: Now, one of the things that I really liked about
the report was that you came up with this really ingenious way of diagramming
out hubs and interviews. And I had never seen that type of diagramming, but
I could see how that would be extremely useful. And in fact, for example, the
Proflowers people would almost instantly point out this problem that we just
talked about.

Hagan: Yeah, this diagramming that I came up with is
really my own little notation system that I have developed over the years as
I would visit new clients.

Jared: I am betting that it was invented on a white
board.

Hagan: Yeah, I would visit new clients and they would
sit down in an initial meeting and show me their product. So I am seeing a
brand new product for the first time and demos are usually very fast and very
intense. I needed to try to remember what I was seeing. So what I would do
is diagram it using these diagrams. I would create little hubs and interviews
on the paper and just label them so that I could remember of the screens I
saw, how they were related to one another. I discovered in the process of creating
that diagram was that I could identify problems in the first hour or two of
meeting a new client. Because I could see it in the diagram I was making. I
could see just what you talked about the Pro Flowers that they had failed to
create a hub that they needed to or that the interview wasn’t working right.
I realized that it was good tool for communicating these structures. And they
do show up on white boards. In fact, I have also had clients where they take
screen shots of the windows in their applications and they hang them up on
the wall and they put lines in between the windows to show the relationship.
As soon as you do that, you have made a hub diagram, you can see that.

Jared: I have seen that. We walked over to one of our
clients the other day and they had an entire conference room dedicated to diagrams
much like this. And it was not just their design but all their competitors.

Hagan: Absolutely.

Jared: It was interesting because you could instantly
from six feet away see how the competitors differed by just looking at this.
So that diagramming technique is really cool. Another thing that you did in
the report that I really liked was you took apart supports. Where did you find
that application?

Hagan: [laughing] It was funny. I was trying to find
a nice, straight forward, easy to understand application that would work well
in the report that I could just kind of dissect it a little bit. I needed something
with a lot of screens so that it had good structure but I didn’t want any one
screen to be too complicated. I didn’t want it to take up a lot of time to
understand how it was working. That was kind of the details that I was into
right now as much as the structure. I was filling in a ticket at our web hosting
company one day and I suddenly looked at the ticketing application and this
was perfect, it was absolutely perfect. It was the whole application for communicating
with IT, submitting a ticket for what is wrong with your website. It is a very
simple application it has a lot of screens.

Jared: It really does. You know when you first showed
it, I thought this is really just a simplistic application but as you started
diagramming it out.

Hagan: There is a lot there.

Jared: There really is a lot there and I thought that
was really fascinating. What is really neat in the report is that you then
go and revise it. First by diagramming it out, and then changing the diagram,
then going back and changing the screens to reflect the diagram. Is that the
process that you normally use?

Hagan: It is one of the processes that I use. I often,
you can uncover problems through the diagram. And as you talk about, maybe
you try to run a task through and you see that a task is hitting a lot of bumps.
Maybe just too many screens and it is just too hard to finish the task. A lot
of times, I will just go back to the structure diagram that I have created
and say you know what is wrong with the structure here that is making this
task too hard to do? And rework the structure and then think about what would
that mean for how these windows are arranged in relationship to one another.
Sometimes, I do it the other way around. I will fiddle with the windows. Then
I will think, gosh what have I done to the structure? It is a little back and
forth but the diagram help keeps me grounded in how this application is organized.
And you need that grounding because when you are making changes, you are changing
a lot of things and you need to remember how everything relates to one another.

Jared: Right. Plus it feels to me like it is a great
tool for the team to sort of keep in touch. You can show changes, for instance,
in a different color so people can say, oh this is going to affect these components
and that is going to cause these schedule changes.

Hagan: Absolutely, I have definitely used it working
with other designers to communicate very quickly communicate structure changes.
I have also used it with clients when we sit down and do a redesign. And I
show the before and after structure to show what we have done.

Jared: OK. I also really liked how many different examples
you used throughout this. We didn’t just focus on the supports and applications
but you showed examples from dozen of different sites. Ones that we know of
like Amazon and Microsoft Money and a couple in there that I had never seen
before such as Power Way, Shutterfly, and you’ve got a lot of different examples
out there.

Hagan: I am a collector of web applications. I love
them. I take screen shots of just about every application I ever use. Which
truly slows me down if I’m doing online shopping or anything because I have
to stop and take pictures of it. I am a very visual person. When I learn, I
like to see pictures. I like to see examples. They help ground the information
for me. The reason I use all these pictures is purely selfish. I need them
to be able to understand the problems and understand the solutions. And I found
as I have been teaching seminars and stuff like that, that people really enjoy
seeing the photos because it helps them immediately understand what I am talking
about instead of in abstract terms. I try to put a lot of pictures in and put
lots of examples there.

Jared: So now this is part one of a series. What are
some future things that we can expect in subsequent parts of our series here?

Hagan: Well, one of the reports that I have been working
on right now is a report on how to make lists and how to deal with tables of
information. So sorting, paging, and selection and how to present information
in tables and all that good stuff. There is also a sampler of web applications
that I have been putting together that just sort of visits several different
robust, pretty well designed applications. It digs down in their design and
really looks hard at them and says what went well here and what might you want
to look at and copy? So both of those are in the works.

Jared: Excellent. We look forward to those. Thank you
very much, Hagan.