Re: Design document [Draft 1]

[Shawn T Amundson <amundson eventloop com>]

On Thu, Dec 14, 2000 at 11:56:57AM -0600, Joakim Ziegler wrote:
> 
> 4. Graphical design
> 
> There have been several quick sketches of the web site look and feel on the
> list lately. There seems to be considerable agreement on several aspects of
> the graphical design. I've tried to sum up those here, as well as inject some
> common sense rules, and some opinions of my own, of course.
> 
> 
> 4.1 Colors and typefaces
> 
> High contrast is easier to read than low contrast. Dark text on a light
> background is easier to read than the opposite. It seems clear that we should
> use black text on white or light pastel backgrounds throughout the site, to
> keep readability as high as possible. This doesn't, however, exclude the
> occasional use of light-on-dark for menus with reasonably few items, etc.
> 
> Typefaces on the web are a difficult problem. While technologies like CSS
> give decent control over what typefaces the browser chooses to use, there's
> no good, standardized and open method for downloading typefaces, hence one is
> limited mainly to specifying sans-serif or serif fonts. Sans fonts are widely
> used because they look cleaner, however, serifs theoretically increase
> readability, if rendered correctly, but font rendering in web browsers,
> especially under X, is abysmal. Thus, it might be worth considering using a
> sans font for the GNOME sites.

I suggest the site be designed in such a manner that this is dynamic
and can be changed easily.  Think of having things like a Christmas or 
Halloween theme.  (Ok, these are poor cultural examples, but you get
what I'm saying.)  Or maybe changing the website "theme" in for GNOME 
2.0.

> 4.2 Headlines and icons
> 
> For maintainability, headlines should be text only. The current design uses
> graphics for some text (most notably the menus), and this has proven to be
> difficult to maintain and update. Even though there are techniques for
> generating images of text on the fly and caching them, we should try to avoid
> this as much as possible.
> 
> It would be good to integrate some icons into the site, since GNOME has very
> attractive icons on the desktop, etc. However, keeping the site light on
> graphics is probably a good idea, and since icons would have to be specially
> created for the site, it's dangerous to rely on them (if we had an icon per
> section, adding a new section would entail finding an icon artist to do
> another icon in the style of the existing ones).

I agree completely. 


> 4.3 Navigation bars and menus
> 
> There are basically two main layouts used for the main navigation bars
> (navigating the main hierarchy). One, which has been the standard for most
> sites for a very long time, is the "Along the left side of the page" vertical
> menu. The advantages are that we can include basically as many items as we
> want, since vertical is the axis people are used to scrolling on anyway. The
> disadvantage is that subnavigation is difficult to integrate intuitively
> (most attempts use an indenting system, which tends to make the menu very
> wide).
> 
> The other, which has become more common lately, is the stacked horizontal
> navbars along the top of the page. The advantages of this is that revealing
> several levels of navigation is very easy and intuitive, by adding bars below
> each other, The disadvantage is that it's somewhat limiting in the number of
> items that can be included on each level of navigation.
> 
> Personally, I've come to prefer the stacked horizontal bars, if they're
> practical given the navigation structure, for a number of reasons. They stay
> out of the way a lot more than the vertical menu (since the vertical menus
> usually means wrapping the whole content in a table and putting the menu in a
> table cell to the left of it, so that there's essentially a strip of blank
> space all the way down below the menu bar), it takes up less screen
> realestate in general, and it's a model most people are comfortable with.
> 
> We could optionally also include "breadcrumbs" to make finding out exactly
> where you are in the structure simpler (breadcrumbs are the category >
> subcategory > current page used on for instance yahoo.)
> 
> If we use horizontal stacked bars, I suggest we place the alternate
> navigation methods (user group based, quick links, search) in a column along
> one of the sides of the frontpage, possibly in little boxes.


Because of the long list of things that might potentially be in the
secondary menu, I suggest a more standard horizontal toplevel with
the vertical secondary. 

A dual vertical would be difficult to do properly without using 
graphical text.  

In addition, if the site is in that big table, you can flip flop
between the differenty styles at will.  I think the vertical one
will be easier initially.

> 5. Localization
> 
> We've amply discussed this. I'm going to write a section on it, but I believe
> it's not vital right now, and I really want to just get this document out
> there.

Perhaps someone who has strong opinions supporting Localization should write 
a draft of this section.  I also believe it is not important at this time, but
it will quickly become important when implementation eventually begins.

> 
> 6. Technology
> 
> Technology should be decided after a few days of discussion and fleshing out
> of the sections above.
> 

I suggest stating it is tenatively PHP with mySQL, because it sounds
like that's what most people are thinking.  Obviously the group as a
whole won't decide this: the implementors and maintainers of the site
will determine it.  

-Shawn

--
Shawn T. Amundson                       amundson eventloop com	
Research and Development                http://www.eventloop.com/
EventLoop, Inc.                         http://www.snorfle.net/

"The assumption that the universe looks the same in every
 direction is clearly not true in reality." - Stephen Hawking