Page Summary

- AUTHOR: DavidLeangen
- AUTHOR-CONTACT: mailto:dleangen<at><<BR>>

What you will get from this page

A proposal for an extreme workover of the current Cocoon website.

Your basic skills

Technical prerequisites

"Project" Members

The contributors to this little "project" are:

Main Conent


This page presents a proposal for a complete overhaul of the Cocoon website. Since this approach is very much divergent from the current approach used by the Cocoon project, we expect that it will mostly generate resistence and will not actually materialize on the main Cocoon site.

Nonetheless, this is still a useful excercise to:

General Principles

The new website should:

To accomplish this, the content should:

Elimination of the Wiki

We are proposing that the wiki be eliminated, or at least relegated as a type of sandbox.

As a sandbox, each page may exist for a maximum of 3 months before being deleted. The logic behind this is that if the information is useful, then it should be promoted to the main website. Otherwise, the information is not useful and should be removed.

Proof of the need of this is the large number of unused pages on the wiki. Although great effort has been made to clean up the wiki, inevitably, it will again become messy after a few more months of use.

Target Audience

Currently, the site is targeted towards people with programming skills who plan to use Cocoon themselves for development. We believe, however, that this approach is too narrow and does not help to promote Cocoon for mainstream use.

Again assuming that many of our users are commercial, in many cases, if not most, programmers do not make the actual decision as to what product to use. Rather, somebody higher up the ladder determines what product will be used. This person or persons have many factors to consider beyond nice technical design and any final decision is based on perceived risk versus reward, with an emphasis on the word "perceived".

Or, a user may be a reporter who has heard about Cocoon and wants to report on it. In many cases, the reporter has little technical knowledge: we need to spoon feed the information. If the reporter cannot understand what we're trying to do, no article will ever get written. However, we want to reach not only developers, but also the decision-makers who's interests are more commercial than technical. We therefore want to make the Cocoon message simple enough to be passed on by the non-technical. As it stands, the information is too technical.

In any case, one fundamental principle holds true: if people cannot relate to the content, if they cannot understand what we're saying, they will simply move on. First impressions are important.

We believe, therefore, that the intended audience must be expanded and the content adapted in consequence to relate better to each of the target user profiles.

Task-based Content

Navigation of the site should be task-based and not content-based. What we mean by this is that content should appear according to what the user is trying to achieve, rather than according to the information we want to present. This means, counter to the fundamental programming axiom of "once and only once", that information may be duplicated. Note, however, that the information source need not be duplicated: only the resulting HTML.

For example, User A is a company decision-maker with moderate technical skills. She has been nagged by some of her developers to look into Cocoon, since they have used it before and believe that it could help their company. Her goal, then, is to make a first evaluation of Cocoon to evaluate the risk of using an open-source project from within the company.

User B is a very experienced developer with fairly advanced skills. User B doesn't want fluff, but wants to get right to the meat. He doesn't like people spoon feeding him information, but would rather see what's inside Cocoon and how it works and make a decision for himself.

User C, however, is fairly new to programming, or at least Java programming. His job is to build a corporate website for a small company of 50 people. He has used PHP, but is frustrated with its limitations. Hearing about what Cocoon has to offer, he wants to give it a try.

Each of these types of users have not only very different goals, but different skill sets. What they want from the site is very different. Using the "once and only once" approach, it is simply not possible (except using some business logic in a dynamic site, which is not what we're proposing here).

<This could be a complete article on its own...>

Proposed Content Structure

This section explains the approach we will take to determine what the structure of the new site should be.

Fundamental Questions

To determine what the structure should be, we first need some way of being able to answer these fundamental questions:

Use-case Browsing

Most web sites are structured according to what the author's want to say. They look at their product and make a functional decomposition of the site content based on the product's structure.

What we are proposing here is instead to base the structure of the site on the use-case: what does the user want to accomplish?

There are several possible use cases, including:

<to be continued>

Discussion Between Mark and David


MarkLundquist comments:

DavidLeangen replies:

Elimination of Wiki

MarkLundquist comments:

DavidLeangen replies:

User Profiles

MarkLundquist comments:

Deprecation of Documents

MarkLundquist comments:

DavidLeangen replies:

Look and Feel

MarkLundquist comments:

DavidLeangen replies:

JonathanMerriman replies:

Major design issues with the site:

Quick fixes:

Random Thoughts

MarkLundquist comments:

DavidLeangen replies:

ExtremeDocumentationOverhaul (last edited 2009-09-20 23:42:27 by localhost)