Website Needs for the Worldforge Project

by Chord

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.

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.

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)

'Template' support in creation of new projects areas

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.

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.

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.

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.

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.

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.

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.

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.

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.