Re: The Jakarta Site

[Henri Yandell <ba...@generationjava.com>]

[I am inlining the document I have written. I tried to begin a little
formally, but it's all using personal habits of documentaton, so feel free
to be anarchic at it. I'm happy to Wiki it or put it in Jakarta-site2/

I will attempt to maintain change control on it based on comments until
such a time as it goes into one of the above]

***********************************************************************

@author: Henri Yandell <ba...@apache.org>
@creation: 2003/01/31
@state: proposal
@version: 0.1

Introduction
============

Purpose
-------
To create a low buy-in contract for ASF projects [or just ASF Jakarta projects] web
sites so as to provide a more coherent experience for users.

Scope
-----
The existing web sites are huge, and slowly losing coherency.

Parties
-------
Any Contributors, Committers, Members or Directors of the ASF.

Definition of terms
-------------------
ASF = Apache Software Foundation

References
----------
Standard of documentation:  http://www.flamefew.com/~hen/HowToDocument.html
How to architect a site  :  http://www.generationjava.com/articles/web/infoArch.shtml

Over of the remainder of document
---------------------------------
The following is the application of the 10-point 'how to architect a site' plan
against the existing ASF web sites.

An Information Architecture for the ASF sites
=============================================

1 - Mission/Goals

The mission of the Apache website is to present the Apache Software Foundation and
its projects.

2 - Consumers

Members of the ASF, Committers and Contributers, will all use the site to present
their work and the ASF. Herewith known as the People of the ASF.

Existing users will use the site to discover documentation and cross-reference to
other projects. They will also use the site to discover how to communicate with
the People of the ASF.

New users will use the site to discover a project. They will want an introduction
to the project, and to be able to download the project.

3 - Content and functionality

The site's content is chiefly separated into two areas, the ASF and the projects
of the ASF. The ASF itself provides various corporate-style information pages. The
projects of the ASF are hierarchical in nature.

Each project contains the following:

*) Children projects.
*) The parent project.
*) Download of Nightly/Formal releases of Source/Binary.
*) Bug-reporting. [ie bugzilla]
*) Source control. [ie CVS]
*) People of the Project.
*) News. [ie) Official releases, announced bugs etc]
*) Status. [ie) The current state of the project. What's next, which version to use. known bugs list in important releases]
*) Mailing lists. How to join, unjoin, archives.
*) Date of creation of page/site

A project's site is mainly aimed at users, who may be People of another Project.

4 - Security

The site as described in this document is utterly open. Partly because the document
is being written by a user rather than an owner of the site. There are probably hidden
aspects of the site for maning mail-lists/archives/etc.

5 - Content Organisation

The structure of the content maps to the hierarchy of the Projects. It is possible that
Projects may form a graph and not a hierarchy, or even a set of graphs. Project sites
are expected to cross-link a lot. The existing site currently contains this hierarchy
and can be documented at a later date, or allowed to evolve naturally.

6 - Navigation

Again, the existing navigation structure will probably be used. A top-level horizontal
line will contain parent/currnet project display [ie via logo's etc]. The left column
will contain navigation structure for the project. The rest of the page contains the
content, which will contain many embedded ad-hoc links.

7 - Labelling

Project names are already chosen. Project logos need to be standardised as official
'labels' [mainly due to some projects using old logo's, ie Jakarta Taglibs].
Projects contain content with labels of:

[from Dion]
Downloads
Bugs
Status                [Dion said Release Notes, I disagreed]
Mailing Lists
Team Members          [I like 'People']
Documentation

News
Source-Control

Other pieces of content, such as parent/current projects and page/site creation timestamp
will be obvious without needing labels. Parent project are on the left of the top-bar,
current projects on the right.

8 - Search methods

Mail archives need to be searchable. Archives take care of this themselves.
The site needs to be searchable. [Should this search ability be on all pages??]
The source-control system is searchable via a viewcvs.cgi [or equivalent] view.
Projects will be found via the front page, in hierarchical nature.
Deep-linking occurs heavily, so urls are very persistent.

9 - Static vs Dynamic

Due to the high number of users to the website, dynamic pages are a performance issue.
The Bug system has to be dynamic.
Any possible online running examples should be available dynamically to view on the
site, but this probably needs bandwidth donation from the People of the ASF. For
example, I plan to setup a Tomcat server hosting the examples.war from every Jakarta
Taglib project and link it into the site as an example of each example running.

10 - Site expansion

The major growth positions for the ASF site are:

ASF:  New projects added to the hierarchy all the time. Usually it is rare to add
new top-level projects, though currently this is in fashion. New projects also add the
resources needed by projects, source-control, mailing lists, bug-entries.
      ASF News is also added constantly.

Projects:
      People are added and are removed.
      Releases occur.
      Nightly builds happen each night, and it is assumed are removed in some fashion.
      News is added.
      Bugs are added.





---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org