[WF-Infra] WorldForge website needs
jason at oppel.net
Mon Oct 29 13:16:28 PST 2001
On Mon, 29 Oct 2001, Chord wrote:
> 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.
> 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.
> 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.
I think the bottom line here is that when newbs browse the site they
generally have a totally different agenda from old WF hands. Trying to
integrate these two needs into a one size fits all menu bar would be an
enourmous mistake. I'm afraid what we would end up with is a site that
doesn't fit anyone's needs very well.
I'd strongly encourage keeping the newb and developer areas seperated. I
think Chord did an _excellent_ job with organizing the categories and
balancing everyone's needs when visiting the site. There was a lot of
thought and research put into this heirarchy. Why are we reinventing
> 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.
It goes without saying that there should be very few area coordinators on
the web site but I also think that the number of editors in general should
be kept way down. I don't know if I would go as far as to say that only
ppl on infra should do any editing like Gabriel suggests but I think he
does have a point in that the number of editors should be kept to a
minimum. In the past we've had _way_ too many wiki accounts floating
around and we've been passing them out like candy. This has enabled green
newbs to edit areas of the site which they have either no or a very
superficial understanding of what they're editing. IMO this has to stop
or else we're going to ednd up with a tangled mess just like we have now
on the Wiki site. We should have some sort of requirements before an
account is handed out or at least require that submissions from new ppl go
through some sort of approval procedure from an area coordinator. We
don't allow complete newbs to generally do commits in CVS w/o some sort of
supervision. The same should apply to the web site. Imagine what kind of
mess or project would be in if just anyone was allowed to run around
rampant in CVS. Hence we find ourselves with a tangled and disorganized
wiki web site.
The fates lead the willing, and drag the unwilling. --Seneca
More information about the Infra