forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Usability news website
Date Wed, 26 Mar 2003 15:39:29 GMT


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