forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konstantin Piroumian" <kpiroum...@apache.org>
Subject Re: Usability news website
Date Wed, 26 Mar 2003 15:59:09 GMT
Just wonder why don't you like the JavaScript version of menu?
See it here: http://cvs.apache.org/~kpiroumian/forrest/page.html

--
  Konstantin

From: "Nicola Ken Barozzi" <nicolaken@apache.org>

>
>
> Stefano Mazzocchi wrote, On 26/03/2003 12.23:
> > Nicola Ken Barozzi wrote:
> ...
> > when entering the tree, it is shown as
> >
> >  v 1
> >    > 1.1
> >      1.2
> >      1.3
> >  v 2
> >      2.1
> >      2.2
> >    > 2.3
> >
> > this is better than simply
> >
> >  > 1
> >  > 2
> > because it gives enough contextual information for the user to navigate.
> >
>
> Ok, I reckoned too.
>
> This means that we have them always open (v); I tried to see how they
> show without the 'v's, but it's visually worse.
>
>
> > The visual codes are:
> >
> >  1) icons indicate which branches are open, which branches contain
> > inside information and which do not
> >
> >  2) colors/borders/shades indicate the current page.
>
> Ok. Point 2 done, need to fix point 1.
>
> > Possible icons are:
> >
> >  - triangles (used in macosx aqua and swing metal)
> >  - +/- signs (used in windows)
> >
> > All nodes that relate to a page are hyperlinked. The current page is
> > *NOT* hyperlinked.
>
> Yup. Though this doesn't apply to tabs, since in practice (ie out of
> real-world usage) it's *very* useful to have them always linked and
> reference the base page of the tab.
>
> > Now, let us suppose that we want to reach section 2.3.2.1.1 We click on
> > "2.3" and the tree becomes.
> >
> >  v 1
> >    > 1.1
> >      1.2
> >      1.3
> >  v 2
> >      2.1
> >      2.2
> >    v 2.3
> >      > 2.3.1
> >      > 2.3.2
> ...
> > then click on '2.3.2.1' and the tree becomes
> >
> >  v 1
> >    > 1.1
> >      1.2
> >      1.3
> >  v 2
> >      2.1
> >      2.2
> >    v 2.3
> >      > 2.3.1
> >      v 2.3.2
> >        v 2.3.2.1
> >            2.3.2.1.1
> >
>
> Ok, I see what you mean...
>
> > This navigation method has several advantages:
> >
> > 1) high-depth navigation is possible and still it's very easy to find
> > the way up without having to resort on the damn back button.
> >
> > 2) navigation is kept contextually minimal, this is done to reduce the
> > visual occupation cost since we provide visibility only for those nodes
> > that we assume can be useful to show.
> >
> > 3) it can handled arbitrarely-complex trees, optimizing visible space.
> >
> > There are potential optimization for high-depth trees, most notably,
> > keeping the depth size fixed to, say, three or four levels. This means
> > that only the 3 or 4 levels higher than the current page are shown.
> >
> > This behavior could be made configurable, as the trimming of node names
> > to save space.
>
> But it tricks the user.
>
> If I see:
>
>  >      v 2.3.2
>  >        v 2.3.2.1
>  >            2.3.2.1.1
>
> I reckon that 2.3.2 has only *one* child, which is not the case.
> I need a visual clue that it can have children, like (maybe)
>
>        v 2.3.2
>          v 2.3.2.1
>              2.3.2.1.1
>            ...
>          v 2.3.3
>
>
> Another option would be to close the top-level nodes to reclaim space:
>
>    > 1
>    v 2
>        2.1
>        2.2
>      v 2.3
>        > 2.3.1
>        v 2.3.2
>          v 2.3.2.1
>              2.3.2.1.1
>
> Or to use a different visual paradigm like stacking
>
>    home
>   ------
>     2
>   ------
>    2.3
>   ------
>    2.3.2
>   ------
>   v 2.3.2.1
>      2.3.2.1.1
>   v 2.3.2.2
>      2.3.2.2.1
>      2.3.2.2.2
>
> In this way we keep open the *last* n levels and keep the previous ones
> in a stack.
>
> This gives a more detailed view of the local context, which matters much
> more.
>
> I like this last solution, but collapsing the top level items... I'm not
> sure.
>
> >> Ok, what I did is to use only two colors for links. Dark blue for
> >> not-visited links, and black for visited links, because I reckon that
> >> they don't need the attention of the user anymore. Do you have a
> >> better suggestion maybe?
> >
> > I would use two tones of blue. A ligther one for non-visited links (say
> > 'navy') and a darker one for visited ones.
>
> I did it but the colors I chose don't look optimal. If anyone wants to
> make them nicer, go or it.
>
> > and some highly contract
> > color (dark red-ish) for active links.
>
> Ok. BTW, do you know what active links are for? The clicks are so fast
> that most browsers don't even show them.
>
> > using black gives the wrong impression since black underlined link gives
> > cognitive dissonance to people since they don't know if the text is
> > really meant to be underlined or it was a link.
>
> Right.
>
> > this is where cromatic information (also called 'color keying') really
> > does help removing cognitive misconceptions.
>
> Unless the person is color blind, which is why luminance is so much more
> important in accessibility.
>
> >>> 3) the section bars are too big. you don't need more than one pixel
> >>> to indicate separation. everything else is abusing precious screen
> >>> space.
> >>
> >> I disagree to some point. I want to keep a visual consistency with the
> >> rounded corners, and added them to these bars. The height is the
> >> smallest reasonable one IMHO that can be used, remembering that
> >> second-level sections have even thinner bars.
> >
> > You must ask your self if the information you want to convey with those
> > rounded corners is important enough for the screen space it consumes.
> >
> > it's a measure of cognitive cost and it's not an objective metric so
> > there is no objective point to make.
> >
> > I personally believe that those rounded corners aren't worth (visively)
> > the price of the space they occupy, but that I'm more and more into
> > 'down to the bone' visual semantics.
>
> Yeah, I've seen that. I'll not follow you too much on this, because I
> know the dynamics: fead up with complexity, one starts going to basics,
> then starts using small extra features, it grows, becomes caos, resorts
> to simplicity... I've been over that too ;-)
>
> >> Not sure here, but there was a meaning for them to be like that.
> >
> > I'll leave it up to you.
>
> I'll leave that up to users. Many changes that have been done there were
> taken from them.
>
> Actually they asked to reuse "filled" bars like the apache or tigris
> ones, what do you think of them? I find them too oppressive.
>
> Look at the ant site ant.apache.org to see what they resorted to using.
> BTW, it's done with Anakia ;-)
>
> >>> 4) I would place the logo buttons on the left but down the very
> >>> bottom of the page so that they are visible, but not intrusive.
> >>
> >> IMHO this doesn't change things much from having them at the bottom...
> >> they seem ok where they are ATM, where also they usually are on other
> >> sites (and where users think they'll find them).
> >
> > Again, there is no objective reasons for having stuff there or at the
> > bottom so there is no reason to argue.
> >
> > As a sidenote I would say that those colorful bottons are distracting
> > where they are and I would like to see them at the bottom, after the
> > person has 'scanned' the top of the page for information.
>
> Distracting? Good, then the place is right! They *should* distract on
> the first visit IMHO (publicity).
>
> ...
> >>> 7) the media="print" properties of the CSS has to be tweaked to
> >>> remove the logos and to put the published date in the better position.
> >>
> >> When I did the print CSS, I kept the logos on purpose. Maybe I should
> >> use the alternate text as text in the top of the page, but how?
> >
> > In theory, you could match for the attributes and turn them into blocks.
> > But I doubt that any browser supports that.
>
> I resorted to including them both and selectively using the logo or the
> text in normal or print modes.
>
> >> For the date should it go on the top too?
> >
> > Should be at the bottom, but again, not sure any browser supports
> > vertical floats.
>
> Ok. Since we have it at the bottom too I put it there.
>
> --
> Nicola Ken Barozzi                   nicolaken@apache.org
>              - verba volant, scripta manent -
>     (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>


Mime
View raw message