> Ok. My grand plan, which I did back in August, is at
> <http://critique.net.nz/project/mozilla.org/mozilla-org.jpg>.

Before I say anything, I should say that the vast majority of this is spot
on. I wouldn't want you to think I was just being negative :-)

> requirements:
...
> * be more attractive as the default home page for Mozilla users

Ooh, controversial :-) I'd question that this is a requirement. This
implies that the front page of www.mozilla.org should be some sort of
portal (because most people's start pages are) and I don't think we want
to go there at all.

> * get involved
>   - quality assurance
>     o how to report bugs
>     o how to find duplicates

Why is QA under "get involved" yet the stuff about contributing code is
not? They are equivalent. I agree with whoever said that /quality/ should
be top level. 

>   - sponsorship

<raises eyebrows>
 
> * translation bar (for showing translations of current page)

Surely this is a browser or a webserver, not a website function? Either we
get the server to detect the browser language and serve up the correct
content if available (the best solution) or we let them use a pulldown to
use an external translation tool.

> * aesthetics of site should change every ~12 months

Any particular reason?

> * URL as UI <http://www.useit.com/alertbox/990321.html>

Yes and no. Often URLs are quoted, in News or IRC, and so need to provide
some summary of what they are about. For example, I much prefer
http://mozilla.org/bugzilla/guide/tips.html to e.g.
http://www.cnet.com/100,2342,3243.4334.5.html or whatever it is they do.

So, URLs have to have some UI (Useful Information) component, even if you
aren't expected to use them as UI (User Interface.)

>   - clear URL hierarchy (avoid meaningless levels like `docs/')

I still maintain that there are documents, like The Bugzilla Manual, which
are definitely "docs" and documents, such as the download page, which are
not. It's true, in the end everything is a "document", but that's not what
a docs directory means. It stands for "documentation" :-) And I think it's
a meaningful distinction.

Gerv



Reply via email to