Design document [Draft 1]

[Joakim Ziegler <joakim helixcode com>]

So, here's the much anticipated design document draft. There are a couple of
pieces missing, and it'll require quite a bit of discussion, but I think I've
created something that will be a decent starting point. When replying, please
consider trimming extensively, just quoting the exact pieces you're
commenting on, and try to keep it compact. This thread can get very extensive
if we don't. Also, if you have several long comments to different parts,
consider replying in two different mails.


-----

                       GNOME WEBSITES - DESIGN DOCUMENT
                                   Draft 1
                               Joakim Ziegler
                            <joakim helixcode com>

TABLE OF CONTENTS

1. Introduction

2. Audience and goals

3. Navigation structure/usability

4. Graphical design

5. Localization

6. Technology





1. Introduction

This is a draft design document for the GNOME websites. It's based on the
discussion on gnome-web-list gnome org, as well as my own personal
suggestions/preferences. Don't take things here as written in stone, this is
mostly intended as a starting point for discussion.

The structure of the document is fairly general, and is designed to
accommodate most changes, so we won't have to go around changing the actual
structure, just the content of the sections. It's a lot easier that way.



2. Audience and goals

The GNOME websites span a rather large range of audiences (and corresponding
goals), including users, developers, members of the press, representatives of
companies considering supporting GNOME, and so on. The goals can be broken
down as follows:


2.1 Marketing GNOME

One of the primary goals of the GNOME websites, specifically www.gnome.org,
is to market GNOME towards people who don't have it installed yet. Even
though GNOME is well on its way to becoming a de facto standard desktop
environment for GNU/Linux users, there is still a rather large group out
there who are not yet using it (not to mention all the users of other Unices,
as well as Windows and MacOS).

Primary tools for doing this is the www.gnome.org frontpage (body text), as
well as sections specifically designed to market GNOME to new users (the
"Find out what GNOME is" section of the current site is a good example,
although there should be more).


2.2 Providing GNOME news

There is a lot happening in the GNOME community, and people want a place to
get informed about the latest news. news.gnome.org fills this function rather
well, but currently suffers from being poorly integrated with the rest of the
GNOME sites (visually and content-wise).

The base features of the current news.gnome.org are good, though: Posting of
articles with followup discussion, along the lines of Slashdot.


2.3 Informing users

Users need a wide variety of information. New users should have easy access
to introductory documentation, tutorials, installation howtos, FAQs and so
on. More experienced users should be able to find detailed documentation,
troubleshooting guides, pointers to software of different types, etc.

The user-oriented documentation could possibly be arranged around where the
user is in the GNOME pipeline: Getting ready to install - Installing -
Running it the first time - Learning to use it efficiently - Getting more
software.


2.4 Educating developers

developer.gnome.org is the prime resource for GNOME developer information.
Since we're also managing the www.gtk.org assets, we're in a rather unique
position to make developer.gnome.org into a one-stop site for all g-prefixed
development information. Most of the current content is excellent, although
it could benefit from somewhat better organization and navigational structure.

Types of content: Technology overviews/whitepapers, tutorials, API docs,
high-level guidelines.


2.5 Informing the press

GNOME is getting massive press coverage lately. Even when our handling of
press contacts has been low quality, slow, or non-existent, we've gotten
excellent press. It's clear that we could get even more press coverage if we
were slightly more aggressive in our handling of these matters. At the
moment, our press resources mainly consists of a list of e-mail addresses,
one for general press inquiries, a couple of corporate ones, and some for
press contacts local to specific countries.

Ideally, we should have a complete press kit online. It should include all
the stuff journalists normally ask for when they contact
gnome-press-contact gnome org, such as a brief description and history of the
project, the structure of the GNOME foundation, representative screenshots,
publicity shots of central people in the organization, and so on.


2.6 Informing ISVs and other corporate entities

We've traditionally been rather bad at addressing the information needs of
corporate entities specifcally. They've mostly been forced to browse the
standard information on the site, and then post their inquiries to mailing
lists. While the information needs of companies vary a lot, we should at
least make an effort to address their basic needs.

Information about the GNOME foundation advisory board, companies currently
working with and supporting GNOME, and so on will be helpful. Generally, this
is about marketing GNOME to potential corporate backers, as well as informing
them.



3. Navigation structure/usability

The navigational structure for the GNOME sites is by no means a given. There
has been a lot of discussion, particularly about the top-level division of
areas, where there have been suggestions for task-oriented, user group
oriented, and subject oriented navigation, as well as variations over these
three basic themes.

My current proposal is to use a task/subject hybrid structure, with user
group oriented navigation as an alternative method of access. That is, the
main categories of the navigation tree are task/subject oriented, and we
present a small menu in a sidebar or similar on the frontpage for users to
navigate by user group, which leads to one page per user group, with a
collection of links that's relevant for that group.

That still leaves the problem of creating the top-level categories. It's very
easy to either overspecialize the categories, and end up with too many
(anything over 10-12 is too many, in reality) or create too broad categories
that are unintuitive. I created 12 categories which I believe are rather
intuitive for the user, and span all the information we want to place on the
GNOME sites. I've not created the actual structure beneath each toplevel
category, as I think it's not entirely clear yet what things we actually
*want*, however I believe this structure is general enough that it'll be able
to hold whatever we want to put into it. The order of this list might be
illogical.


3.1 Top-level structure

About

  Introductory documents. Mainly for those unfamiliar with GNOME in general,
  and who want a quick way to figure out what this is all about. Includes the
  a "What is GNOME" document, the general GNOME FAQ, and also documents for
  companies interested in supporting GNOME, the project roadmap, etc.


Screenshots
  
  An important link to have on the front page, since this is what a lot of
  people look for. Idea for structure: Split it up into several different
  types of screenshots, like "Basic", "Businesslike", "Applications",
  "Oddities", etc. Perhaps make screenshots imagemaps which can be clicked to
	bring you to the appindex page of each displayed application?


Get it

  Describe the various ways to get and install GNOME. CVS, GNOME FTP servers,
  Linux distributions which include GNOME, and Helix GNOME would all be
  relevant pointers here. It's a matter of resources how much we want to
  actually support all of this, but we should at least have instructions for
  how to get, build and install GNOME from CVS and GNOME FTP.


Support

  How to get help with GNOME. All the documentation should be here, as well as 
  pointers to mailing lists, bugzilla, IRC channels, etc.


News

  Gnotices in some shape or form. Basically newsitems with discussion.


Software

  A revamped, expanded version of the Appindex. Should let you search for
	software in a variety of ways, including category, file types it'll read
	and write (very practical for all the people who come onto IRC and say
	"What GNOME program can read a .foo file?", and so on. Possibly also an
  equivalence index, where people can say "I need something like Outlook",
  and it'll take you to Evolution.


Developer

  Entry for the developer minded. Basically the combined content of today's
  developer.gnome.org and www.gtk.org.


Press

  All the info members of the press would need to represent GNOME in a
  correct manner. Journalists work under time constraints, so this is where
  we have the chance to give them all the info they need in one neat package.
  Should include a press kit (possibly in PDF format), a list of contact mail
  addresses and phone numbers (I know, phone numbers are so 1985, but some
  journalists prefer them), press photos (preferably, each press contact
  listed should have a downloadable high-resolution photo for the press to
  use when interviewing), representative screenshots (of the nice and simple
  variety), and so on. The press kit itself should be a brief presentation of
  GNOME, talking about the project history, the foundation, the current
  status, what corporate backers there are, etc.


Foundation

  All the formal stuff about the foundation, how a company can join the
  advisory board, current board of directors, board meeting minutes, and so
  on. The exact content of this section should be up to the people more
	directly involved with the foundation, I believe.


Contact

  Ways to contact the GNOME project and the members, for various purposes.
  This should definitely be broken down by task, so that bug reports can be
  directed to bugzilla, press inquiries to the press section, etc.


Events

  An events calendar, listing upcoming tradeshows where GNOME will be
  present, as well as scheduled upcoming releases.


People

  Developer index, developer interviews (I'd like to resurrect that section,
  even though I only ever did one interview, I think it was a good one, and
  it's a great way to show the faces behind the software. Actually, it's such
  a good idea that KDE cloned it off our site), and so on.


3.2 Other navigation methods, shortcuts into the structure, etc.

The structure outlined above is a reasonable main navigational structure, but
one structure will never fit everyone. Hence, I'm suggesting augmenting it
with a few metastructures that will mainly be accessible through the front
page:


Role description

  Allow people to choose who they are from a small menu (about ten items,
  perhaps), and arrive on a page of quick links for the group they chose. The
  links go directly into the structure, and are the ones we believe are
  useful for that group, in the order they should be read.


Quick tasks

  Allow people to choose a few typical tasks from a menu, and go directly to
  those pages. These should be the 4-8 pages people visit the most, but that
  are still not logical to make into top-level categories. Things that spring
  to mind as obvious candidates are "Report a bug", "I need help!", etc.


Search the site

  A search box on the front page is a necessity, and should search the entire
  site.



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.


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).


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.


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.


6. Technology

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


-----


-- 
Joakim Ziegler - Helix Code web monkey - joakim helixcode com - Radagast IRC
      FIX sysop - free software coder - FIDEL & Conglomerate developer
            http://www.avmaria.com/ - http://www.helixcode.com/