Organize foswiki.org

Structure the website according to user needs

Discussion topic on the website organization. Concrete task in Item29.

This project does not yet follow the guidelines as described in UserExperienceTaskTeamProjects. Please help improve this page.

Please discuss on the discussion page.

Summary

What information should be presented and where?

In WebsitePersonas we have defined a set of user needs by means of personas. This could still provide a base for the content we offer here.

Diagram of persona needs mapped to a site structure (click to view image):

This diagram is not meant as a final structure. It may be of help to see subject relations.

Concrete tasks

Do we need an About web?

Currently we have Home in the menu. This label would not assume there is a lot of content behind it. On most sites the Home link is just one page, not a group of pages. Additionally, on some sites, the home page link is not included within the main menu navigation, but located elsewhere (often the site logo itself or nearby).

Do we need a System web?

Or: do we need to have it this explicit, in the main menu?

Where to put Supplemental Documents?

Raised in Tasks.Item129

This comes down to:

1. Where do we store Documentation?
   • In Item29 the web name Docs is used. Instead of a web, this could be placed in web About (see "Do we need an About web?"). It depends a bit on the depth and scope of the docs if it deserves a separate web.
2. What relationship have Supplemental Documents?
   • Can these be considered as FAQ documents?
   • How dynamic are these documents? Changed often?
   • Who will change these documents?

Where do we place support pages for extensions?

On twiki.org users that have a question generally go the Support web. Our new support question form follows this idea: here you can enter the name of the extension you have trouble with.

It is logical to group extension support questions in the Support web, not in 1 long *dev page.

Unless there are severe problems with this approach we can start to create stubs/templates to facilitate this.

My suggestion is to deprecate use of *Dev topics, or to leave these to developers. And let users start in Support.

-- ArthurClemens - 23 Nov 2008 - 13:10

Good ideas to move away from Dev topics and on to an application that look up in Support web AND in bugs web. You need to be able to both submit and immediately view all the related support questions and bugs as headlines. We cannot discard the existing Dev topics. They contain important info, bugs reports and patches that it would be a crime against the plugin developers to just discard.

-- KennethLavrsen - 27 Nov 2008 - 21:55.

We can't discard Dev topics of extensions. They have mistakenly been used for support questions. They are originally intended to coordinate and announce development in a lightweighted fashion. Sure, we've got the task web for issue tracking as well but I think it is important to keep the entry barrier low for users to comment on a plugin.

-- MichaelDaum - 28 Nov 2008 - 07:52

I just reviewed the Dev pages for a number of extensions on TWiki.org. Without a couple of small exceptions, they are all about (1) reporting bugs and (2) asking support questions. Bugs should go in Tasks web, and support questions in the Support DB. Further, most of the time input in these topics has been ignored for long periods. i haven't found a single example where they have been used to coordinate development, other than duplicating what the Tasks web does better. I do not favour keeping Dev topics.

On the other hand I do consider feedback valuable. I'd love to see a way for users to feed back a rating and comments on the extensions they use. But the Dev topics is too chaotic to be useful for that.

-- CrawfordCurrie - 28 Nov 2008 - 08:26

Personas and website structure

Here are some thoughts of a "normal" user on the structure of the website. (I am TERRIFIED by the old site twiki.org - it's ugly and a enormous mess). I like the ideas of Personas, but the whole concept on these pages was too business-specific, too complicated and AFAIK was never used. I propose a much simpler Level of Experience model which could be helpful in remodeling the structure of the website. Le voila:

Here is the diagram above, colored in the respective loe

• Layer_Learn.png:
  

• Layer_Usage.png:
  

• Layer_Community.png:
  

(not too much community there... )

• Layer_Contrib.png:
  

Do I make any sense? Otherwise, feel free to delete me

-- YogiParish - 03 Dec 2008 - 09:20

OK, fine. That is a nice addition. How would you continue from here?

-- ArthurClemens - 03 Dec 2008 - 11:45

Just start with the first one, 'learn about Foswiki'. Create it in a 'beta area' of the website and move it over 'Home' when it is good enough. The 'Use Foswiki' needs to be in place around the same time as the first release. The other two items can be created after the first release, I guess.

-- ArnoldAtMallos - 16 Dec 2008 - 23:51

We need to start doing something now: Tasks.Item912.

-- ArthurClemens - 30 Jan 2009

A new visual design (skin) is stated for end of November.

I think currently most needed is:

1. Complete the About web
   • Recently added: About, UseFor, ExampleSites, Security
   • Look at the diagram and add new insights
2. Restructure Community.WebHome
   • The Task teams are almost invisible. How to see what they do? It almost looks like a dead place.
3. Restructure Extensions.WebHome
   • Can we make browsing/choosing easier?

-- ArthurClemens - 29 Sep 2009