CHI-WEB Archives

ACM SIGCHI WWW Human Factors (Open Discussion)


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Louis Rosenfeld <[log in to unmask]>
Reply To:
Louis Rosenfeld <[log in to unmask]>
Tue, 25 Aug 1998 22:37:21 -0400
TEXT/PLAIN (129 lines)
On Tue, 25 Aug 1998, Jennifer Fleming wrote:

[...stuff (some from Klaus) deleted...]

> * One of the things I'm really interested in is how design can be used to
> show a site's space, or architecture. What are the best ways to communicate
> that structure so people can more rapidly understand options? What happens
> if visual organization is at odds with logical organization? This touches
> on what you're talking about. I don't have answers... only areas I'd like
> to explore more. There's a whole body of knowledge in graphic design + info
> design that I think needs to be interpreted for the web. So far most GD
> books for the Web gloss right over it.

I see visual and logical organization clashing primarily in situations
that heavily involve interface design; e.g., how a search interface works
(this just came up for us today).  In cases like these, issues like
site-wide navigation may become less important (or even non-existent),
while the widgets that help the user move procedurally through both
content and applications require both logical and visual design more

As far as representing a site's logical architecture, I certainly don't
have the answers, but I do wonder if part of the solution goes back
(again) to separating content from design/container.  Practically, we are
architecting content, not pages, documents, files, or any other artifact
of traditional and well-known metaphors.  And yet when we design
blueprints of sites, many of us (and the commercially available tools) are
fixated on pages, which, not surprisingly, are more familiar concepts to
us.  This fixation trips us up and results in more confusing diagrams
where pages, groups of pages, and chunks of content that happen to live in
pages all coexist.  If we can remind ourselves that content ultimately
exists independently of its container (e.g., pages), then maybe we can
start representing our sites' architectures more clearly and accurately.
Then again, this would represent a paradigm shift, and it might be too
much to ask others (i.e., users and clients) to make the same leap, at
least not right away.

> * Sounds like you're talking about a mixture between wireframes and page
> templates, here. I'm not sure how I feel about one "frame" or design being
> applied to many sites (is there an assessment process first? how does that
> work? have I missed the point?). However, there are some interesting
> stories that you can take or leave.... For example, at a recent conference
> session, Jeff Veen of Hotwired used wireframes to show how users approached
> the screen at their site. The top portion of the page was expected to be
> branding and site-wide navigation; the left column was expected to be
> section navigation; and the remaining chunk to the center and right of the
> screen was expected to be page content. I have no idea how they arrived at
> these conclusions, by the way... but it does seem to be how people approach
> large information sites (Lycos, CNET, MSNBC, & even use a
> similar model). Proviso: please take it with a grain of salt. This is an
> interesting model that works for *some* sites. Obviously, every site is
> different. :)

It really depends on how detailed a "wireframe" is.  We've had luck with
using what we call "architectural approaches" that are then adapted for
use within the constraints of particular projects.  I'll admit that the
idea of selling a specific architectural approach, pre-designed within a
piece of software, makes me feel a little queasy (will us IAs be
replaced?), but I think it's starting to happen:  my understanding of what
Perspecta and Plumtree's products are is just along these lines.  But even
these products will require a lot of customization as they are implemented
for specific projects.

> * As far as how to test a site's structure before diving in with design, I
> needed to do this recently and had a lot of success with just showing
> people outlines. In the case of this project, I was debating over 3 broad
> approaches to a site structure: shallow (more choices on the front door),
> deep (fewer choices on the front door, but more categories to wade
> through), or something in the middle. I showed people 3 simple text
> outlines that listed major site sections and subcategories of them (top
> level stuff).  This is not exactly an academic method -- or a high-tech
> one, for that matter.  :)  But the funny thing was that I got some very
> strong opinions from users, and some really useful feedback, including some
> great comments about the labels we were using. Proviso: this was an
> audience of web developers, so could take to the problem quickly and
> without much explanation. Not sure if this would work for an "ordinary"
> user. It's one idea... I'd be very interested in what Lou had to say about
> this. Any other ideas for how to get a reality check on a site's structure
> before you dive in? Would you look for such a check, or would you trust
> your instincts?

IMHO, the key is what information needs your users have as you're showing
them these three approaches.  One of my concerns about the sort of testing
done by folks without information retrieval/librarianship backgrounds is
that the queries they select for testing are not representative of users'
actual information needs.  It's easy to test (and measure the results of)
"known-item" queries, where there is a "right" answer to the query and it
exists in the system (e.g., "What time is last call at Bud's Bar and
Grill?").  We can tell how long it took them to find the answer, how many
keystrokes, etc.  But what about exploratory queries (e.g., "I'd like to
learn more about the poodle's role in Western Civilization"), research
queries (e.g., "I have to find out everything there is to know about push
technologies for my upcoming feature in Silly Investor Monthly") or other
query types?  These are much harder to evaluate, and I hope that this
thread veers in some point toward exploring this issue further.

I think the trick is to identify the most common types of queries a
system's users, and design, test, and evaluate around them.  This is even
more important than distinguishing between audience types, as the same
users will have different query types, even in the same session.

> As far as the literature, have you tried the ACM Digital Library
> ( You need to register to see the articles, but it's free and
> easy to do. I also have a "netography" from my book up at
> in case you want to try some of
> those resources. Not sure if any of them speak directly to your problem.

Another bib is the one from Peter Morville's and my book, which we're
slowly updating:

> Best of luck with it... I'd be really interested in hearing what you come
> up with. Hope you can keep us posted!
> Sorry for the very long message,
> jef
> Jennifer Fleming
> Web Navigation: Designing the User Experience (O'Reilly, 1998)
> Square Circle Solutions -
> Anchor -

Thanks all for making this such an active and interesting thread!

Louis Rosenfeld / [log in to unmask]
Argus Associates / / 734.913.0010
Information Architecture for the WWW /