[WF-Infra] WorldForge website needs

Chord chord at worldforge.org
Mon Oct 29 09:44:52 PST 2001

I was asked to put together a list of some of the larger
needs and requirements of the WorldForge site. These
were located in various documents and logs and never
*fully* documented in one place. This list might not be
totally complete in past months, I lost a lot of logs and
files on my computer in a big hard drive bake.

I will hit up brenda logs from the surrounding time period
to see if I can dig anything else up, but these are a few
of the 'biggies'.


1. Breadcrumbs

They need to be useful in getting someone back to where
they were, without going too deep. While the thought
may be to not plug something that deeply into the site,
with a site with as many documents as WF's, there is only
so much room to stretch horizontally and make the site
easily navigatable (forward and backward) at the same time.

2.  Meaningful anchor text and link reordering

The links in the navigation of the sub-topic areas should
not be arbitrarily ordered alphabetically but should have
the ability to be reordered and have meaningful anchor text
To see why this is necessary, see the 2D structure on moria.
It makes no sense to have the gallery and how-tos listed
before the news and other general area information.

3. Ability to use same content in multiple pages.

Some pages can easily use the ability to use some same
amount of text that is used in others. Currently, the only
way to do this is manually, which causes problems with
this information being updated in one area and not in others.
As a few 'for instances':
	1. It might be nice to be able to pull some specific
	server or client information from a server or client
	being used in a Game System such as Acorn, into
	the Acorn area of the site, without having to have
	people hop links all over the place or having to
	duplicate the information.

	2. We have a definite need to be able to use the
	same artwork in multiple galleries (a general all
           inclusive gallery, a screenshots gallery, a 2d
	gallery, 3d gallery, sub 2D galleries (iso images,
	portraits, character sketches) sub 3D galleries
	(models, etc) without having to update every gallery
	page individually. (tho this particular problem can
	likely be solved in more than one way, it is listed
	here for demonstrative purposes)

4. 'Template' support in creation of new projects areas
(Not an absolute necessity immediately, but needed longterm)

Some basic links should appear in every project or production
area. For instance, all areas should have a news page, team
page, etc. Again, see the example of 2D art on moria. Coding
areas will need a standard set of links for basic documentation.
To facilitate startup projects/products, these basic links and
pages should be pre-generated (without content) to be completed
by the project team. This will further encourage a reliable structure
on the site, making for easier location of specific information.

For instance: Adding a new client (FooClient) to the clients
area, when I create the folder fooclient, the default structure
for that area should already be listed in the navigation bar. This
will allow the project team to simply click the link and edit the
appropriate page with the information needed. (how this is handled
exactly is flexible (I'm not a coder, I don't know how it would best
be implemented), but the point is to make sitewide consistency
built in and obvious from the getgo.

5. Ability to edit without use of HTML

Some ppl don't know html and don't care to know html. Through
use of things like structured text (similar to wiki shortcuts) editors
can bold, underline, etc using *'s, _'s and the like. This, in fact,
should be encouraged as it translates well copied directly into
ASCII text documents/email, etc.

6. Separate layout ability for Game Systems

While the rest of the site should adhere to the basic layout
concept of the main site, bryce expressed a desire to allow
the Game Systems (Acorn and the like) to have individual
layouts, as desired. They should be fully able to use the default
standard layout, but should be able to customize freely by
building their own layout templates.

As a side note, it was never the intention to list all games in
the top nav menu. We need a way to break down the games..
maybe even list them as Games A-M (linking to a listing)
and Games N-Z (again linking to a listing). I know that this
has been an area of concern as people envisioned this list
growing out of proportion and messing up the navbar. While
a decision had never been made on how to split the Game
Systems menu, it was deemed as necessary future action.

7. Simple newbie 'lobby' area menu vs more detailed developer menu

For clarification before we start, a 'newbie' in this not someone
new to the project as a developer, but new to the site in general,
a passerby, that sort of thing. Someone who knows little to
nothing about WF and just wants a bit of a clue.

For a long time the complaint was expressed that newbies have
to dig to find anything. The newbie menu should keep
everything a new visitor to the site could want within a link's
reach. They must be able to find the information they want
(the basic stuff.. faq, screenshots, what is wf explanation) in
a very obvious manner.

On the opposite side of the coin, once someone has joined,
they want to know where to find the juicy information. Hiding
it in obscure directories is frustrating at best. Unless you are
very familiar with the site, you will not realize that worlds/ is
in the content area of the site, unless the navigation menu is
complete and logically presented.

We spent more than two years with that same problem
of no one being able to find where subareas were on the
site. I don't think that this need should be dismissed lightly
just because it makes the top bar navigation large. It's
large, but it's far less obtuse to surf and navigate than a
very small, top level navigation. 2+ years of experimentation
in this matter simply cannot be ignored.

8. Simple editing form to 'mask' zope interface

Basic editing should be done through use of a simple form
that would eliminate the user from having to deal with the
zope interface.

9. Eliminate the need for the old 'upload tool'

Some ppl had difficulties with the upload tool used on previous
versions of the site. One idea for easier uploading was to set
up some inline way to upload files and images from where you
where editing and an easy way to link to the result.

10. Editing permissions

Permissions should be able to be limited to subareas,
that is to say, individual products of the WF project. For
instance, if a developer needs to edit pages for fooclient,
they should be restricted to editing in that area. They
should not be able to wander into barclient and edit that
product's pages, unless they happen to be an active
developer on both products. Adding editors to more than
one area should be rather trivial to accomplish.

The failsafe exception to the editing limitation will be
those who are area coordinators, or site maintainers
who may be called upon to fix things.

11. Page synchronization to the search engine

Pages should be realtime updated with the search engine
on the site when changes are made to them. This includes
addition, modification, and deletion of pages.

This will accomplish two things:
	1. The search engine will then not return non-existent,
	defunct links in the search results.

	2. The load on zope and on the machine will be reduced
	as there will be no need for a scheduled reindexing of
	the complete site at one time. This will slow down the
	site rendering to a great degree. Many will recall the
	times that jack has had to reindex the site. It was a
	painful task to do in one load. Something that immediate
	indexing would help to alleviate.

Only authored documents and images should be indexed
into the search engine, else we could end up with mangled
searches containing templates and irrelevant zope documents.
Which, not being complete pages, would not display correctly.

12. Full documentation on how to edit the WorldForge site

These docs should include any specs and guidelines to which
authors should adhere. This might include document naming
guidelines, area structure requirements, and the like.

These docs would also include helps and how-tos on using
the site's tools and features.

	- Chord

More information about the Infra mailing list