[webteam] Sections

Adam Nemeth aadaam at gmail.com
Tue Sep 18 10:18:33 CDT 2007


On 9/15/07, Robert Martinez <mail at mray.de> wrote:
> > So basically, I still think it's a hierarchy, probably with the 'links
> > for everyone' (alias end-users' floating always, if it does feel
> > better for anyone.
> >
> >
> I don't understand what hierarchy you are talking about.

There are three navigational models: linear (webshop checkout),
hierarchical and web (or "random access"). The second one is
preferred.

In practice: it means that we have:

- A section selector somewhere (for some: the whole startpage, like on
felvi.hu; others, it's somewhere in the header, but it must be clearly
visible and emphasized - I draw a concept on that already iirc)
- If a user selects a section, it gets different set of pages as
'menu', than selecting another one.
You wrote it as:
> >
> >>   I'm not a fan of having a menu or list of links that changes slightly
> >> based upon "another menu".

The main argument of my letter was - probably not clear enough - that
this is still a good solution for average people, while still
tolerable by advanced users, if used in a clever way.

I added, that there could be some pages from the "IM-user" section
which would still show up at every audience.

(Constant pages like impressum, contact, etc are needed anyway, but
they're 'in another box').

So, we should have the following boxex:
- Audience/section selector
- Context- or section-based menu (which could overlap, if needed, but
it would make confusion with the next point)
- Constant menu which is useful for every audience
- Constant menu which is the usual constant things every webside should have.

These should be visually separate.

> > That's called modality. It's considered bad in some schools. On other
> > schools, it's called information hiding, and it's considered the best
> > thing since sliced bread: way too much information confuses the
> > novice.
> >
> >
> After all we don't need a deep cut dividing people into completely
> different audiences (exept we are keen on building several homepages at
> once), but we want to make it easier for people to find what they want.
> And I admitt that I even have personal interest in keeping it "ONE" site
> instead of many.
> So please try to think more about solutions that directly adress the
> fact that we have one database that should satisfy different audiences.
>

Still it shouldn't be a primary point of view in my opinion. We have
content. Of course we try to reduce redundancy, but we speak about
providing content for different needs. Sources of this content is a
secondary argument.

> >
> > I'm still besides the good ol' hiearchy, probably with some sticky pages.
> >
> Please explain how your hierarchy looks like (systematically).

(I said it opposite to tagging, which is a popular solution nowadays)

Hierarchy is like that:

http://wiki.jabber.org/index.php?title=Jabber.org_relaunch&oldid=2247

On every level, only the actually selected node is visible, plus it's
parents and  immediate successors.

>
> My attempt would mainly rely on offering different starting points (one
> per section) that keep things simple and clear.
> I would do that by:
> 1. Offering only a selected number of links to our complete set of
> information in the beginning. (A trimmed menu)

That's why they land on end-user site, don't they?

> 2. Offering some big fat buttons that directly link to the most
> important places according to the audience.

That's what I've drawn in that mockup (it was re: progress I think)

> 3. Welcome each audience with a friendly text according to their needs.
>
>
Forget welcome texts, noone reads them (I bet neither you.) Provide
useful informations on every section startpage. For end-users, your
three-button wizard is fairly good, we'll see it in statistics if it
helps or decreases performance.

For developers, get planet jabber in, plus a few project highlights,
like chesspark and qunu, which aren't a "usual IM client built on
jabber" category. For business managers, aggregate case studies.
Friendly welcome text are never read.
>


-- 
Aadaam <aadaam at gmail.com>


More information about the webteam mailing list