[WF-Infra] WorldForge website needs

HansHäggström hans.haggstrom at helsinki.fi
Tue Oct 30 00:34:10 PST 2001

At 19:44 2001-10-29, Chord wrote:
>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.


The new layout has a "Current Path" bar, which lists links to parent pages.

The Navigation section in the sidebar is being worked on, and will
probably contain links to all the parent pages of a particular page,
all the siblings of that page, and all it's children.  It could perhaps
also include 'uncle' pages, but that might take up too much room.
Grandchildren is another alternative, but again it is potentially a lot of

Here's an example of how it would look like,
with the page /games/mason/technology selected:

* WorldForge
    * Games
       * Mason
          * Project
          * Game
    >>  * Technology
             * Overview of Mason Architecture
             * Physics
             * Items
             * ActiveObjects
             * Connections
             * Actions
             * Skills
             * Control Interfaces
             * Client UI
          * Content

Uncles of the mason/technology page would be other game system pages,
such as acorn, open racer, etc.

>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

The new layout has a sort property that can be set in the page edit form.

>  and have meaningful anchor text

The page title is used in autogenerated navigation bars, breadcrumbs, etc.
If a page is linked from inside another page, then normal <a> tags are used,
and the anchor text is defined by the user..  Do we want/need some system
to create links to other pages that use the title of that page as the 
anchor text?

It seems related to the 'Related Pages' -section idea.  We could perhaps 
use a special
dtml based linking system in the page content, that would automatically
insert the title of the page at edit time, and also create a list of the 
linked, 'related',
pages, that could be listed in a table in the text if the user wants to, or 
shown in a
sidebar section.

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

Hmm..  That might be harder.  Where would this typically be used?

Would just a description of a page be enough? (those we currently have
separated from the actual page content, and they would be easy to include.
(think of a page_description as a sort of abstract or 
about the content of a page)).

Or do we want to quote parts of a page? (that
would require some markup on the source page to specify the quotation area,
and could be harder to implement...  one way to do it would be to write the 
included text separately, and use <dtml-var include_section_name> to include
it into the desired pages).

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

The media repository should take care of that.

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

This is something that I'd love to see too.  We could have a form for
adding a new effort of some type, with checkboxes for wether
to create an own news section, what sidebar sections are needed,
and so on.

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

This should help us maintain a good structure on the site when new
projects are added.

With the Mason game system, I found it practical to divide the mason area into
four parts,

* Project
Contains news, overview, meetings, team, required reading, battleplan, 
goals, etc.

* Game
Game concept documents, user interface ideas, end user documentation, 
features, etc.

* Technology
What RIMs / systems / modules are needed to implement the game features, 
what new RIMs
need to be coded, overview of how the different modules in the game interact.

* Content
What world to use, needed maps.
New item types, creatures, materials, etc that need to be added, the 
descriptions and stats for them.
Textures, models, sprites, illustrations, sound effects, and music needed 
for the new items and areas in the game.

Does this look like a good layout for a game effort template?

Each main section would have separate pages for the different things, and 
news pages, meeting pages,
etc would be pre-generated special areas with controls to add news / meetings.
Also, content listings and other task list might be connected to request 
tracker somehow,
and the media pages would have a way to add new media tasks that 
automatically creates entries for them in
the media database and request tracker.

What different areas are needed for clients, servers, game worlds, and 
other products?
Can any sections be shared?  (at least the project section could be shared, 
it seems).

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

Structured text is supported, as is HTML and plain text.

There's some interest in supporting DocBook documents too,
but I don't know anything about the status of that.

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

Hmm..  Open Racer does this currently.

It would probably be possible, and I can see some motivation in
creating a flashy page for a specific game.

At the same time, if the game layout hides navigation controls,
the breadcrumb bar, the sidebar, etc, then it will be _very_ bad for 
general usability
of the site.

Changing the color scheme or using some background textures, etc, is possible.
The color scheme can be changed easily on the new site by setting the zope
properties darkcolor, lightcolor, mediumcolor, brightcolor, etc.
This is what each main area does. (see http://moria.mit.edu:8080/wf/new )

Note that a new color scheme for a game system also disrupts the navigation
a bit, since the colors are used to identify main areas of the site.

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

Currently we just have a bar with the different main areas of the site
listed.  But listing the N first items under each could be done too,
to make navigation to a specific place faster, and give some general
idea of what the areas contain.

The items to show would be selected based on sorting order, and
three dots might be used to indicate that there's other entries (that can 
be seen
by going to the main page for that area).

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

Hmm.. Many of these things could be on the front page.
( http://moria.mit.edu:8080/wf/new has a list of the currently planned
things for the front page, feel free to suggest other things that should be 

Also, a latest screenshots section is planned for the sidebar, this would 
give a
nice visual representation of where we are and what's going on.

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

Good point.
We'll work on getting the top area navigation to show the subareas then.

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


The page edit form currently looks like this: 

We also have an "Add Page" form, and an "Add News Item" form (currently
the same as adding a page, but will probably be specialized for news items 

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

For this we could perhaps have some system in the page edit form,
or a separate "Add Image" / "Add File" link.

Also, often it is preferable to use the Media Repository to store the graphics,
so that it is as easy as possible to reuse in other pages and for other 
or to update it when needed.

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


We don't have much for the new layout yet, but here's the start
of an user guide by Phil:

Also, we have tried to provide short descriptions about filling in each
field in the edit forms too.
General naming standards, etc, could be mentioned there when needed.

>         - Chord

Hans Häggström (aka zzorn)
"Share and Enjoy" - Cirius Cybernetics corp. - THHGTTG

More information about the Infra mailing list