Matthew Thomas wrote:
|
| mozilla.org redesign
| --------------------
|
| requirements:
| * attract developers
| * make it easier to find information
| * provide for easier maintenance and addition of documentation
| * be more attractive as the default home page for Mozilla users
| * make project status and progress more obvious
|
| information architecture:
| * about the project
| - who we are
| - mission
| - FAQs
| - sponsors
>> - how the organization works
| * news and events
| - status updates
| - newsgroup summaries
| o modelled on `Kernel Cousins' <http://kt.linuxcare.com/>
| o could eventually replace the status updates, encouraging
| developers to post interesting status in the newsgroups for
| discussion (rather than saying `here's what I did this week')
Sort of like Newsbot..
| - press releases
| - developer meetings
| - parties
Ok. All this needs to be archived under some top-level directory;
the second level needs to be a date stamp (year should do). The
structure can go under that, as it might change from year to year.
Latest stuff can go without a date.
| * developer info
| - Mozilla development
| o code architecture overviews
| o ports
| o accessibility
| o usability
| o internationalization
| o localizations
| o good coding style
Ports and code architecture overviews don't seem
to fit here. They're software-specific--everything
else seems to be overall guidelines.
| - application development
| o XP Toolkit
| o XUL reference
| o embedding
Who are these documents aimed at?
- Mozilla developers
- outside developers using Mozilla code
- both
| - Web development
| o supported standards
| o articles on cool ways to use the standards
This should probably be top-level; it definately
doesn't go under Mozilla development. /web?
It's very browser-centric. What about mail-news?
NNTP is an Internet Protocol--not a Web one, but
it's still supported--by mail-news, not by Bugzilla.
This needs to be worked out more.
| - tools
| o Bugzilla
| o Bonsai
| o LXR
| o Tinderbox
| * software [I agree with Fantasai that this should be a separate area]
/software or /releases?
| - Mozilla
| o download
| o feature summaries
| o release notes
| - Bugzilla
| o download
| o installation instructions
| o release notes
| - Bonsai
| o download
| o installation instructions
| o release notes
| - LXR [ditto]
| - Tinderbox [ditto]
LXR, I believe, is not a mozilla.org technology.
(Linux Cross Reference)
Under these, everything release-specific should go under its
own release directory. That probably includes feature summaries
as well as release notes, since those also vary between releases.
| * support
| - Mozilla Update (detect Mozilla version, and offer upgrades)
| - language packs
| - FAQs
| - links to Usenet groups and IRC channels
These are mostly app-specific and should not be in a general directory.
| * get involved
I agree with Gervase, that this should not be a category.
It can be a document, with pointers on where to get started,
but I think getting involved should be on a project-by-project
basis.
| - quality assurance
| o how to report bugs
| o how to find duplicates
Either top-level or /dev/quality. (I personally prefer the latter.)
| - advocacy guides
?
| - hacking
| o downloading source
| o getting CVS access
| o building the Lizard
These are /not/ hacking docs. I can build Mozilla without intending
to modify the source code (as, to test something that's been
#ifdef-ed out on official builds).
Downloading and building are related--and app-specific.
Getting CVS access is organizational.
| - writing documentation
Mozilla Documentation Project
| o style guides
Same place as coding guides.
| o list of missing documentation
Get Involved or To Do under MDP
| o localizing mozilla.org
Can get it's own project.
| - sponsorship
Put it with the sponsors.
Where do community-related things go?
- newsgroups/mailing lists
- links to other mozilla-related sites
| general page contents:
| * link to home page
| * link to ancestor section
| * form for searching ancestor section (and link to advanced search)
| * breadcrumb navigation
What's this? ^
| * links to subcategories
| * content
| * translation bar (for showing translations of current page)
| * boilerplate footer.
|
<snip>
| meta-qualities:
| * compliant XHTML and CSS (no TABLEs required, except for tabular stuff)
I think writing to HTML Strict is sufficient.
>(no TABLEs allowed, except for tabular stuff)
| * URL as UI <http://www.useit.com/alertbox/990321.html>
| - clear URL hierarchy (avoid meaningless levels like `docs/')
| - don't include meaningless stuff like `.html', `.php3', or `www.' in
| links
There shouldn't be any file extensions /at all/.
Nice side effect: documents can become directories in the future.
