New Structure
Gervase Markham
hope people will check out the CVS treee, take a scratch copy, move some
directories around and see what they come up with. Once the directory
structure is roughly sorted, and a "grand plan" - the reasoning behind the
structure - established, then we can start moving individual .HTML files.
After that, of course, we need to work out how to fix the internal links
<sigh>...
Another point for debate: Are we going to put in "this file has moved" for
_every_ file that changes, just the most important, or none of them? We
obviously need a custom 404 which explains the changes and the new
layout...
Gerv
Ben Bucksch
> Another point for debate: Are we going to put in "this file has moved" for
> _every_ file that changes, just the most important, or none of them?
Dead links (which includes custom 404 pages) are annoying. Since you
don't know, which ones are linked: all. (IMO)
Gervase Markham
Mozilla top-level web directories:
aurora [empty]
banners Mozilla ad banners
blue-sky [Obsolete] Column detailing the best ideas from wishlist
bugs Bugzilla user docs, project docs
build Build documentation (all platforms)
classic [Obsolete] Documentation graveyard for Mozilla Classic
credits Credits page (one page only)
CVS -
directory Directory SDK (all versions)
docs Documentation of all sorts
editor Mozilla Composer
editorials mitchell's "About the project" editorial from June this year
ef Electrical Fire
events One event only - the Mozilla thing at Stanford in April
hacking Hacking best practice docs
HOWTO Single page - index of other documentation
implementation [empty]
js The Javascript engine
keymaster XUL joke
layout [empty]
legal The Wang case (2 documents) May 1998
mailnews Mail/News
MPL MPL and NPL
msgsdk Messaging Access SDK
mstone [empty]
newlayout Gecko stuff
newsbot The newsbot
NPL [empty]
oji OJI stuff
party Mozilla parties 1, 2, and 3
performance Performance - leak reports, test cases
ports Ports - each in its own subdir (yay!)
prefs A .txt from Seth Spitzer :-)
press A press release on security from March
profilemanager A bit about the Profile Manager
projects A whole _bunch_ of Mozilla projects, big and small
quality QA
raptor [empty]
rdf RDF documentation
releases Mozilla 0.6 only at the moment
rhino Our Javascript in Java implementation
roadmap-images The two images from the roadmap. (Grr...)
school RHP's project to get students working on Mozilla (lastmod in
June)
scriptable XPConnect (Javascript and XPCOM interoperation)
security List of security-related projects (one file)
statistics A page which indexes two sets of moz stats
status Status reports
unix Mozilla on Unix
update [obsolete] Beta1 "update notification"
wallet Stuff for submitting forms to the master wallet server
xfe [obsolete] X front end
xmlextras Vidur's XML extensions module
xpapps The crew who write the XPFE
xpfe More XPFE
Gerv
Ben Bucksch
/apps/mailnews. Then, we need a name for those "horizontal" projects
like docs, build, qa, coding etc..
Gervase Markham
The problem with this is that, because it's in CVS, this involves checking
in a custom redirect for _every_ file. It also means (even more
annoyingly) that the website tree will still be a mess, as we won't be
able to get rid of any files. There are still "This number has been
disconnected" pages all over the tree from _years_ ago. I want to avoid
that.
(dredges memory) Isn't there a cunning way of getting Apache to do this?
Virtual directories, I think it's called... <checks> Could we use
mod_rewrite?
Gerv
Henri Sivonen
<gervase...@univ.ox.ac.uk> wrote:
> editor Mozilla Composer
> ef Electrical Fire
> js The Javascript engine
> mailnews Mail/News
> newlayout Gecko stuff
> oji OJI stuff
> profilemanager A bit about the Profile Manager
> rdf RDF documentation
> rhino Our Javascript in Java implementation
> unix Mozilla on Unix
> wallet Stuff for submitting forms to the master wallet server
> xmlextras Vidur's XML extensions module
> xpfe More XPFE
It might be useful to have a directory (with a guessable name) for each
major Mozilla component, acronym and platform.
xml/
mathml/
css/
xsl/
dom/
svg/
...
mac/
win32/
beos/
os2/
--
Henri Sivonen
hen...@clinet.fi
http://www.clinet.fi/~henris/
Ben Bucksch
> The problem with this is that, because it's in CVS, this involves checking
> in a custom redirect for _every_ file.
Why? Not everything on the site has to be in CVS. I guess, you could do
some tricks with Apache config files, so you don't even need the files.
> It also means (even more
> annoyingly) that the website tree will still be a mess, as we won't be
> able to get rid of any files. There are still "This number has been
> disconnected" pages all over the tree from _years_ ago.
*shrug* That's the result of a messy site structure.
> I want to avoid that.
Then create a future-compatible URL structure. I remember an article
about that on useit / www.w3c.org.
> (dredges memory) Isn't there a cunning way of getting Apache to do this?
> Virtual directories, I think it's called... <checks> Could we use
> mod_rewrite?
I bet there is lots of interesting stuff for us. I think, you can also
have additional config files in each dir.
Jake
> Dead links (which includes custom 404 pages) are annoying. Since you
> don't know, which ones are linked: all. (IMO)
For simplicity sake, a custom 404 CGI script and a flatfile DB of
changes. For example:
/docs/ /docs/dev/
This would allow the 404 to have information on where to find the new
page and still allow the old layout to be removed from the server (for a
cleaner directory tree/CVS checkout).
Jake
I think we should make better use of subdirectories and a good directory
tree in the layout... For example:
/projects/mozilla/broswer
/projects/mozilla/mailnews
/projects/mozilla/editor
/projects/bugzilla
/projects/tinderbox
/projects/bonsai
/doc/dev/cvs
/doc/dev/hacking
/doc/dev/build
/doc/usr/design
/doc/os/win32
/doc/os/unix
/doc/os/mac
/doc/os/linux
This is obviously an incomplete list, bit I think it's enough to get the
point accross.
Gervase Markham
> /apps/mailnews. Then, we need a name for those "horizontal" projects
> like docs, build, qa, coding etc..
I think that's a good idea...
Gerv
Gervase Markham
> > hope people will check out the CVS treee, take a scratch copy, move some
> > directories around and see what they come up with.
>
> completely new directories.
Everyone can think about it the way that suits them best :-)
> > Once the directory
> > structure is roughly sorted, and a "grand plan" - the reasoning behind the
> > structure - established, then we can start moving individual .HTML files.
>
> what's with use of databeses or includes (.shtml)-files
Databases: No, because we want to lower the barrier to entry and make
things easier.
Includes: No, for performance reasons.
> my proposals for a new structure are:
> - use of full english words for files, if we are able to use long file
> names, no abbreviations
This should be the case already.
Gerv
Gervase Markham
( -> indicates a rename). "New directories" which already exist will
obviously still contain what's already in them. Obviously each subdir will
need a tidy-up inside it, but I'm not thinking about that now :-)
New top level dirs Current top level dirs to move inside them
------------------ ------------------------------------------
community banners, events, party, school
docs build, classic, hacking, statistics
ports unix
projects bugs -> bugzilla, directory, editor, ef, mailnews, msgsdk,
rhino
quality bugs (rest of it)
releases (stuff from seamonkey)
status
tech rdf, scriptable -> xpconnect, wallet, xmlextras -> ?, xpapps,
xpfe, js, newlayout -> gecko, oji, performance,
profile-manager
**** editorials, legal, press, roadmap-images, lots of the docs
in the root dir
Really Important URLs we can't move:
MPL
credits
keymaster (?)
(Are there more of these?)
**** - I know these things should be grouped, but I can't think of a good
name for the directory they go in.
It would be good if there was only one document - index.html - in the top
level, but that may not be possible.
The question is, does the top-level structure proposed above provide a
sane home for all the content mozilla.org is likely to host? Comments,
please :-)
(/me remembers how much his newsgroup proposal got improved...)
Gerv
Axel Hecht
how would that structure map to cvs modules? At least the projects
should have their own modules.
Axel
Axel Hecht
Gervase Markham wrote:
>
> OK. Here's my first shot:
>
> ( -> indicates a rename). "New directories" which already exist will
> obviously still contain what's already in them. Obviously each subdir will
> need a tidy-up inside it, but I'm not thinking about that now :-)
>
> New top level dirs Current top level dirs to move inside them
> ------------------ ------------------------------------------
> community banners, events, party, school
banners? Is that stuff now under /images/? or something different? If
those are just graphics for site use, the should IMHO stay in /images/
> docs build, classic, hacking, statistics
do we need separate dirs for user and developer docs?
> ports unix
> projects bugs -> bugzilla, directory, editor, ef, mailnews, msgsdk,
> rhino
This could get rather crowded, which pages of a project should go
beneath the projects dir, which should go to docs? Or is projects/ more
of the developer doc hierarchy?
> quality bugs (rest of it)
> releases (stuff from seamonkey)
> status
> tech rdf, scriptable -> xpconnect, wallet, xmlextras -> ?, xpapps,
> xpfe, js, newlayout -> gecko, oji, performance,
> profile-manager
> **** editorials, legal, press, roadmap-images, lots of the docs
> in the root dir
>
> Really Important URLs we can't move:
> MPL
> credits
> keymaster (?)
> (Are there more of these?)
>
> **** - I know these things should be grouped, but I can't think of a good
> name for the directory they go in.
Where should we have L10N? Do we want translated introductions on
mozilla.org?
<...>
Axel
Jenni &/or Patrick
Hash: SHA1
Apparently the /banners/ is for people who want to advertise Mozilla
on their sites...
Regarding translations, it would be entirely possible to do a
/{page-name}.html.{language-code}, and this is transparently do-able
in Apache. This is good for a few reasons - its all in one place :-).
So for english we have:
http://www.mozilla.org/organisation/at_a_glance.html.en, for German
we could have
http://www.mozilla.org/organisation/at_a_glance.html.de, and when
refernecing the page you would just say
http://www.mozilla.org/organisation/at_a_glance.html. (then apache
would use the pref. lang which gets sent by the user-agent somewhere
in the HTTP request.)
(escuse my non-american spelling).
Or the other track would be to have a lump translation: eg
http://www.mozilla.org/en/organisation/at_a_glance.html.
http://www.mozilla.org/de/organisation/at_a_glance.html
Personally I don't like the second option...
I presume Netscape-Enterprise/3.6 could do something
similar.....................
Also, I reckon things like editorials, legal, press, roadmap-images,
etc would go nicely in a /organi{s/z}ation/ directory.
E.g. /organisation/editorials/, or /organisation/legal/, or
/organisation/press/, etc.
And for docs that don't fit anywhere, maybe a /misc/ :-), that way
one could really get rid of the /*.html's. (except for index.html).
My NZ 2 cents. (approx 5 cents american.)
- -Patrick.
- ----- Original Message -----
From: "Axel Hecht" <a...@numerik.uni-kiel.de>
Newsgroups: netscape.public.mozilla.documentation
To: <mozilla-do...@mozilla.org>
Sent: Wednesday, December 13, 2000 1:56 PM
Subject: Re: New Structure
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOjYnz+5gPjuO7VwfEQIU9QCeNckzET47iTFvVvDkn+2jXnheZnoAmQEK
WJbEAQLpOQIGKof82BNz8LXn
=Ah5v
-----END PGP SIGNATURE-----
Gervase Markham
> > obviously still contain what's already in them. Obviously each subdir will
> > need a tidy-up inside it, but I'm not thinking about that now :-)
> >
> > New top level dirs Current top level dirs to move inside them
> > ------------------ ------------------------------------------
> > community banners, events, party, school
>
> banners? Is that stuff now under /images/? or something different? If
No, the stuff currently in /banners - loads of old and forgotten banners
people can nick to promote Mozilla on their websites.
> > docs build, classic, hacking, statistics
>
> do we need separate dirs for user and developer docs?
Yes. I was merely rearranging the old dirs. I didn't touch on what new
ones we needed.
> > ports unix
> > projects bugs -> bugzilla, directory, editor, ef, mailnews, msgsdk,
> > rhino
>
> This could get rather crowded, which pages of a project should go
> beneath the projects dir, which should go to docs? Or is projects/ more
> of the developer doc hierarchy?
Good question. I suppose docs not related to a particular project go under
docs (hacking, general building, end-user for the browser suite, etc.),
and project docs in /project/*. Unless you do what someone did, and make
end-user docs a project (/project/user-docs/) but I don't like that.
> > **** - I know these things should be grouped, but I can't think of a good
> > name for the directory they go in.
>
> Where should we have L10N? Do we want translated introductions on
> mozilla.org?
Hmmm. Good question. See someone else's comment :-)
However, I forgot that www.mozilla.org doesn't run Apache. Does this mean
we can't use mod_rewrite, or is there an equivalent?
Gerv
Gervase Markham
> should have their own modules.
/projects/* would each be a module, I assume.
Gerv
Zach Lipton
> MPL
> credits
> keymaster (?)
> (Are there more of these?)
>
Why can't we move these? I know that they are important (move keymaster and
not a single xul file is standards compliant), but if we need to move them,
we can make redirects to the new location. I am not sure if we use apache or
not, but if so we can use Redirect Permanent in a .htaccess file to do this.
Zach
Gervase Markham
Zach Lipton wrote:
>
> > Really Important URLs we can't move:
> > MPL
> > credits
> > keymaster (?)
> > (Are there more of these?)
> >
>
> Why can't we move these? I know that they are important (move keymaster and
> not a single xul file is standards compliant),
Actually, now that I think about it, that's not really the case AIUI. XUL
files are uniquely identified by that URL. There is no requirement for
anything to be at the other end (as can be seen if you look at what's
there ;-)
> but if we need to move them,
> we can make redirects to the new location. I am not sure if we use apache or
> not,
Netscape Enterprise Server.
> but if so we can use Redirect Permanent in a .htaccess file to do this.
We could do. It's just that, oh, I don't know, it seems _wrong_ to move
them :-)
Gerv
Braden McDaniel
<mozill...@bucksch.org> wrote:
> Then create a future-compatible URL structure. I remember an article
> about that on useit / www.w3c.org.
This is probably what you were remembering:
<http://www.w3.org/Provider/Style/URI>
Anyone contributing to this thread who hasn't read that article should do
so immediately.
Braden
Jake
the category under "We just reorginized out website to make it better."
(Yes, it really does say 'out'). In the section, it mentions that there
is a possibility that the old URI's can be orginized so poorly that they
have to be pulled down.
When I say a good 404, I mean where the 404 fires a CGI script that has
a datbase of what file moved where. It can then return something along
the lines of:
404 File not Found
The file you are looking for is longer at this location.
Possible new location: <URL_GOES_HERE>
I can dig through my old perl scripts and see if I can come up with the
basic framework for this.
Henri Sivonen
<bra...@endoframe.com> wrote:
> <http://www.w3.org/Provider/Style/URI>
>
> Anyone contributing to this thread who hasn't read that article should do
> so immediately.
Considering the above-mentioned document, I don't like moving pages
around at least not without proper redirects. A good 404 page isn't good
enough.
Most documents could stay at their current locations (both URL and CVS
tree) if we made good enough directory/index pages for each category
with links to the documents (where ever they are in the file system).
Henri Sivonen
<a...@numerik.uni-kiel.de> wrote:
> Do we want translated introductions on mozilla.org?
For end users?
Gervase Markham
> around at least not without proper redirects. A good 404 page isn't good
> enough.
Well, it depends on what the NS Webserver's redirect capabilites are like,
and whether someone can be bothered to write all the rules.
> Most documents could stay at their current locations (both URL and CVS
> tree)
I'd much rather they moved - that's a lot of the point of the
reorganisation - merely having them in a sensible hierarchy will encourage
people to be more organised.
Gerv
Asa Dotzler
>
>> Most documents could stay at their current locations (both URL and CVS
>
>> tree)
>
>
>
> I'd much rather they moved - that's a lot of the point of the
>
> reorganisation - merely having them in a sensible hierarchy will encourage
>
> people to be more organised.
>
>
> Gerv
I think that we've gone for too long where you had to rely solely on an
index page (admittedly not a very good one) to find your way around the
site and it would be extremely helpful for there to be some
reorganization of pages into something that made more sense.
-Asa
fantasai
I don't think that goes far enough.
Here's a design guideline:
The new directory structure must be *extensible* as well as persistent.
Here's my attempt at sketching a directory structure:
http://fantasai.tripod.com/Mozilla/2000/reorg.txt
It's a rough outline--not very complete.
James Green
[ snip ]
>>> docs build, classic, hacking, statistics
>>
>> do we need separate dirs for user and developer docs?
>
>
> Yes. I was merely rearranging the old dirs. I didn't touch on what new
> ones we needed.
Hmm. Could be a pain to update in cvs, since it could trigger two
modules (/docs/user/navigator, /projects/navigator)...
>>> ports unix
>>> projects bugs -> bugzilla, directory, editor, ef, mailnews, msgsdk,
>>> rhino
>>
>> This could get rather crowded, which pages of a project should go
>> beneath the projects dir, which should go to docs? Or is projects/ more
>> of the developer doc hierarchy?
>
> Good question. I suppose docs not related to a particular project go under
> docs (hacking, general building, end-user for the browser suite, etc.),
I like that.
> and project docs in /project/*. Unless you do what someone did, and make
> end-user docs a project (/project/user-docs/) but I don't like that.
/projects/<product-name>/{user}{dev}/whatever
e.g.
1. /projects/navigator/user/reloading_pages
2. /projects/navigator/dev/reloading_pages
1. Covers hitting CTRL-R, CTRL-Shift-R, etc.
2. Covers what the code does when you hit CTRL-R etc.
>>> **** - I know these things should be grouped, but I can't think of a good
>>> name for the directory they go in.
>>
>> Where should we have L10N? Do we want translated introductions on
>> mozilla.org?
I suggest we postfix all pages with .lang
/projects/navigator/user/reloading_pages.en_uk
/projects/navigator/dev/reloading_pages.de
> Hmmm. Good question. See someone else's comment :-)
But let's not rely on us using .html in the future...
> However, I forgot that www.mozilla.org doesn't run Apache. Does this mean
> we can't use mod_rewrite, or is there an equivalent?
Well we need to know what the new site will need in terms of webserver
functionality. I have no experience of Netscape servers, but I wouldn't
be surprised if we were all shouting for Apache to be installed soon.
James Green
James Green
I can't think of a better way.
What you don't want is /context/project/ e.g. /docs/navigator,
/tech/navigator, etc. That's too many modules.
James Green.
Gervase Markham
What's the difference between /docs, /projects/docs and
/projects/project_name/docs? Too many docs directories :-)
Why is mozilla not a project? Why have another directory called software?
Aren't projects software?
Why are tools not projects (most of them are in the current structure.)
Where's the division between tool and project?
Gerv
fantasai
>
> > http://fantasai.tripod.com/Mozilla/2000/reorg.txt
>
> What's the difference between /docs, /projects/docs and
> /projects/project_name/docs? Too many docs directories :-)
Well.. it needs work. ^^
/docs contains or references (mostly references) _all_ the
documentation on mozilla.org. Possibly it can be a single HTML
file such as the one there right now. This is for an everything-
in-one place organization. It includes developer, web-developer,
and user documentation (or rather, indexes and links to the
appropriate files)
/projects/docs holds any documentation pertaining to all
the projects. /docs/developer could do the same job; I'll
change it if you think I should.
Files that might go in there or in a subdirectory of it:
http://www.mozilla.org/build/verification.html
http://www.mozilla.org/build/making-additions.html
http://www.mozilla.org/build/jar-packaging.html
http://www.mozilla.org/build/sheriff.html
http://www.mozilla.org/docs/lxr-comments.html
http://www.mozilla.org/docs/refList/i18n/
http://www.mozilla.org/docs/events.html
http://www.mozilla.org/hacking/
http://www.mozilla.org/hacking/portable-cpp.html
I think I'll stop now...
/projects/project_name/docs contains project-specific documentation.
This is pretty much what we have now, except that right now,
half the projects are in the projects directory, and half of
them are top-level. *_*
> Why is mozilla not a project? Why have another directory called software?
> Aren't projects software?
mozilla can be a project; I didn't exclude it.
/projects is a developer directory.
The directory called software holds everything related to software
*releases*, not development. Should I rename it to /releases?
It's somewhat redundant with mozilla/releases, but that can be changed
to relnotes if there's nothing except relnotes associated with a
given release. (Every doc issued with/for a release should be archived.)
>
> Why are tools not projects (most of them are in the current structure.)
> Where's the division between tool and project?
Development of tools goes under projects--bugzilla will have its
own project directory. The /tools directory is for using the tools.
Stuff like
http://www.mozilla.org/bugs/
http://www.mozilla.org/quality/help/bugzilla-helper.html
http://www.mozilla.org/bonsai.html
http://www.mozilla.org/tinderbox.html
all go in /tools.
James Green
> http://fantasai.tripod.com/Mozilla/2000/reorg.txt
>
> It's a rough outline--not very complete.
Unless anyone can think of a good reason not to, I'd go with this. Seems
logical enough and can provide good cross-referencing between modules.
I'm sure if there are problems we can adjust this design to take them
into account.
Next problem is to identify exactly what information we have currently,
and see if the above design works well with it. If things seem sound, we
need to find out from the people who write content for the site what
they want from mozilla.org v2.
While that is happening we should all raise our hands and be counted as
site staff... Who other than Gerv is going to join me in that? All raise
your left hand now! :)
James.
Gervase Markham
> logical enough and can provide good cross-referencing between modules.
I can think of several :-) (Well, I mean, he invited criticism :-)
A good design for the site should have the following qualities:
a) Obviousness. Given a document in your hand, it should be obvious
exactly where in the tree it goes in the vast majority of cases. I believe
that this design doesn't (yet :-) fulfil this criteria.
b) Balance. There shouldn't be root directories with two files in and
others with 2000, without a good reason.
c) Split along the fault lines. The divisions should be where they are in
people's heads.
> I'm sure if there are problems we can adjust this design to take them
> into account.
No, no, no :-) We finish the design as best we can _first_. This is very
important. Otherwise you get cruft. You'll be surprised how quickly design
decisions become very hard to change.
> Next problem is to identify exactly what information we have currently,
> and see if the above design works well with it.
No again :-) We write a design which a) can encompass all the current
information and b) provides room for expansion. We don't do a design and
then try and fit our information into it!
> While that is happening we should all raise our hands and be counted as
> site staff... Who other than Gerv is going to join me in that? All raise
> your left hand now! :)
Easy, there, tiger - I volunteered to do a small effort, medium reward
reorg. This is rapidly turning into a massive effort, big reward reorg.
I'm not completely sure I'll be able to spare the time. Not that it isn't
a great thing to do, and I'm glad I kick-started it, but I have final
exams next summer...
Gerv
Andreas Franke
Gervase Markham wrote:
> New top level dirs Current top level dirs to move inside them
> ------------------ ------------------------------------------
> community banners, events, party, school
> docs build, classic, hacking, statistics
> ports unix
> projects bugs -> bugzilla, directory, editor, ef, mailnews, msgsdk,
> rhino
> quality bugs (rest of it)
> releases (stuff from seamonkey)
> status
> tech rdf, scriptable -> xpconnect, wallet, xmlextras -> ?, xpapps,
> xpfe, js, newlayout -> gecko, oji, performance,
> profile-manager
> **** editorials, legal, press, roadmap-images, lots of the docs
> in the root dir
Just brainstorming... Have a look at this (sorry, it's in German):
http://www.iud.fh-darmstadt.de/methodik/server/survey1.htm
The top-level classification used there is something like this:
A. Site & Server
B. News & Events
C. Projects & Activities
D. Documentation
E. People & Institutions
F. Search
On http://www.mozilla.org, we currently have:
The Mozilla Organization
At A Glance | Feedback | Get Involved |
Newsgroups | License Terms | Newsbot
Developer Docs
Roadmap | Projects | Ports | Module Owners |
Hacking | Get the Source | Build It
Testing
Download | Report A Bug | Bugzilla | Bug Writing
Tools
View Source | Tree Status | New Checkins | Submit A Bug
FAQ
Search
Andreas
Gervase Markham
> http://www.iud.fh-darmstadt.de/methodik/server/survey1.htm
And, annoyingly, a graphic, which babelfish can't read.
> The Mozilla Organization
> At A Glance | Feedback | Get Involved |
> Newsgroups | License Terms | Newsbot
<snip>
It's _vitally_ important that we divorce the actual underlying
organisation of the site from the things that we choose to "splash" in the
sidebar. The two are most definitely not equivalent. This thread was
started, at any rate, on the subject of directory reorganisation, but
seems to have got a bit out of hand ;-) Nevertheless, I think the actual
things we choose to link to on the sidebar is a minor matter.
Gerv
fantasai
> > Unless anyone can think of a good reason not to, I'd go with this. Seems
> > logical enough and can provide good cross-referencing between modules.
>
>
> A good design for the site should have the following qualities:
>
> a) Obviousness. Given a document in your hand, it should be obvious
> exactly where in the tree it goes in the vast majority of cases. I believe
> that this design doesn't (yet :-) fulfil this criteria.
I made a few changes. Tell me if it helps (and of course, where more
could be done ;)
http://fantasai.tripod.com/Mozilla/2000/reorg.txt
> b) Balance. There shouldn't be root directories with two files in and
> others with 2000, without a good reason.
IMO, "Balance" shouldn't be a consideration. Comparing the hierarchies
can be a useful tool in determining whether some part of the design ought
to be looked over once more, but it shouldn't be a requirement to have
similar sizes. Most filesystem setups aren't "balanced", but that doesn't
make them any less organized.
> c) Split along the fault lines. The divisions should be where they are in
> people's heads.
I've explained where I see them in the notes section. If that's not
where everyone else sees them, then they'd better point me in the
right direction!
> > I'm sure if there are problems we can adjust this design to take them
> > into account.
>
> No, no, no :-) We finish the design as best we can _first_. This is very
> important. Otherwise you get cruft. You'll be surprised how quickly design
> decisions become very hard to change.
>
> > Next problem is to identify exactly what information we have currently,
> > and see if the above design works well with it.
>
> No again :-) We write a design which a) can encompass all the current
> information and b) provides room for expansion. We don't do a design and
> then try and fit our information into it!
Agreed on both points. Measure twice, cut once. XD
~fantasai
Gervase Markham
> could be done ;)
This is looking pretty good. Again, IMO:
1)
Create docs/end-user and docs/web-developer. Use docs/end-user instead of
software/mozilla/docs - then all projects can have end-user docs. The
remove the docs/software symlink.
I think that we should centralise, under /docs, all documentation except
that which is (dev-specific && project-specific), which goes in
project_name/docs.
2)
" The creation of software instead of just a directory for mozilla
prepares mozilla.org for the possibility of splitting the application
into separate releases, as in a Navigator app, a Composer app, a
Messenger app, etc. It also provides a place for any other software
released by mozilla.org."
There are never going to be separate releases of the different apps,
because they are all UIs to the same framework. There may be separate
releases of different components, such as the JS engine, but they are all
under /projects anyway.
And I maintain that /projects is the "place for software released by
mozilla.org."
Just because the Mozilla project is the biggest thing we do, it doesn't
mean it shouldn't fit into /projects like the other projects. Bugzilla
already fits there, so I don't know why it also ended up in /software.
Abolish /software! ;-) Just transplant everything under it directly into
/projects, and I'll be happy. ;-)
Gerv
Matthew Thomas
>...
> Create docs/end-user and docs/web-developer. Use docs/end-user instead
> of software/mozilla/docs - then all projects can have end-user docs.
> The remove the docs/software symlink.
>
> I think that we should centralise, under /docs, all documentation
> except that which is (dev-specific && project-specific), which goes in
> project_name/docs.
Ok, time for me to jump in here (perhaps as the `information architect'
which someone was asking for earlier:-).
To have separate hierarchies for `docs' at all is meaningless. With the
exception of binaries and stuff, everything on a Web site *is* documentation.
> 2) "The creation of software instead of just a directory for mozilla
> prepares mozilla.org for the possibility of splitting the
> application into separate releases, as in a Navigator app, a
> Composer app, a Messenger app, etc. It also provides a place for any
> other software released by mozilla.org."
>
> There are never going to be separate releases of the different apps,
> because they are all UIs to the same framework.
You can't know that. That is how the Mozilla suite has worked from
mid-1999 to the present. It was not how Mozilla worked before mid-1999,
and it may not be how Mozilla works after 2002.
It is quite possible, for example, that the Mozilla base (networking,
layout engine, XP Toolkit, etc) will be turned into a number of
libraries which individual Mozilla applications can then link to.
Indeed, if the Mozilla suite is never available as separate
applications, it will forever be slower, more bloated, and more unstable
than its single-application competitors. So I would doubt that we'll be
taking the current approach forever.
> There may be separate
> releases of different components, such as the JS engine, but they are
> all under /projects anyway.
>
> And I maintain that /projects is the "place for software released by
> mozilla.org."
>...
Having a /projects hierarchy makes about as much sense as having a /docs
hierarchy. Given enough mindless advocacy, anything could be considered
a `project'.
--
Matthew `mpt' Thomas, Mozilla user interface QA
Mozilla UI decisions made within 48 hours, or the next one is free
Gervase Markham
> which someone was asking for earlier:-).
>
> To have separate hierarchies for `docs' at all is meaningless. With the
> exception of binaries and stuff, everything on a Web site *is* documentation.
Hmmm... that's sort-of true. The Mozilla Users Guide (to be written) seems
more obviously a "doc" than the list of component owners.
> > There are never going to be separate releases of the different apps,
> > because they are all UIs to the same framework.
>
> You can't know that. That is how the Mozilla suite has worked from
> mid-1999 to the present. It was not how Mozilla worked before mid-1999,
> and it may not be how Mozilla works after 2002.
>
> It is quite possible, for example, that the Mozilla base (networking,
> layout engine, XP Toolkit, etc) will be turned into a number of
> libraries which individual Mozilla applications can then link to.
Indeed. Absolutely. But all these parts are already under /projects, which
is designed for this sort of thing. My objection was to his justification
for the existence of the /software directory (see the comments at the
bottom of the file).
> Having a /projects hierarchy makes about as much sense as having a /docs
> hierarchy. Given enough mindless advocacy, anything could be considered
> a `project'.
Again, true.
I'm now leaning more towards having a single top-level directory for each
"project". But then we need to decide what additional top-level
directories we need for information which applies to the whole
organisation (such as hacking docs etc.)
<sigh> Why is this stuff never easy?
Gerv
Zach Lipton
mp...@student.canterbury.ac.nz wrote on 12/18/00 3:14 AM:
> It is quite possible, for example, that the Mozilla base (networking,
> layout engine, XP Toolkit, etc) will be turned into a number of
> libraries which individual Mozilla applications can then link to.
>
Isn't this how things are now? At least on mac, almost everything is built
as a shared library.
Zach
fantasai
>
> Gervase Markham wrote:
> >...
> > Create docs/end-user and docs/web-developer. Use docs/end-user instead
> > of software/mozilla/docs - then all projects can have end-user docs.
> > The remove the docs/software symlink.
> >
> > I think that we should centralise, under /docs, all documentation
> > except that which is (dev-specific && project-specific), which goes in
> > project_name/docs.
>
> Ok, time for me to jump in here (perhaps as the `information architect'
> which someone was asking for earlier:-).
>
> To have separate hierarchies for `docs' at all is meaningless. With the
> exception of binaries and stuff, everything on a Web site *is* documentation.
I recognize that, which is why both software and projects are symlinked
under /docs. However, as many people will identify them as top-level, they
exist there, too. There's no reason why you can't have both, so to all
intents and purposes besides physical file storage, I put both.
The exception also applies to publications such as editorials; unless you
get technical to the extreme (which most people don't except for the sake
of argument) they are not documentation--just documents. Also the search
form, the main page of the site, and various other paraphernalia. Hence
the docs directory.
At any rate, if you have a better plan, or any specific improvements, do post.
One can only work with so much abstraction.
> > There may be separate
> > releases of different components, such as the JS engine, but they are
> > all under /projects anyway.
> >
> > And I maintain that /projects is the "place for software released by
> > mozilla.org."
> >...
>
> Having a /projects hierarchy makes about as much sense as having a /docs
> hierarchy. Given enough mindless advocacy, anything could be considered
> a `project'.
And why not, if the files are useful and you're willing to maintain them?
~fantasai
fantasai
> Matthew Thomas wrote:
> > It is quite possible, for example, that the Mozilla base (networking,
> > layout engine, XP Toolkit, etc) will be turned into a number of
> > libraries which individual Mozilla applications can then link to.
>
> Indeed. Absolutely. But all these parts are already under /projects, which
> for the existence of the /software directory (see the comments at the
> bottom of the file).
No, no. /projects is designed to hold the sort of information needed by a
developer to _understand and modify the code_. /software is for the release
of the software. Libraries are software, are they not?
> > Having a /projects hierarchy makes about as much sense as having a /docs
> > hierarchy. Given enough mindless advocacy, anything could be considered
> > a `project'.
>
> Again, true.
That's the point. Then every initiative (since you don't like the word
project) can have a directory to arrange and display their files.
>
> I'm now leaning more towards having a single top-level directory for each
> "project". But then we need to decide what additional top-level
> directories we need for information which applies to the whole
> organisation (such as hacking docs etc.)
You'll wind up with more top-level directories than you can count,
and a poor organization to go with it.
>
> <sigh> Why is this stuff never easy?
My inadequate explanations? I don't thing I'm getting the point across.
Let me try again.
/softWARE - holds everything relating to the distribution of
mozilla.org's _wares_
Software is not a project. Development of software is a project. The
end result of the /project/ is a released /product/. The product is
software, not the project.
Word games aside, I think there's a valid distinction between using
the software--for whatever purpose, be it end user or middleman--and
the development of the software. There is no reason for users to sift
through project docs aimed at developers. Likewise, there is no reason
for developers to have to deal with instructions for downloading and
installing the software when they're studying the architecture.
Remember, _HyperText_ Markup Language /can/ link across directories.
From the developer's main page for the Mozilla project (/projects/mozilla)
you can link to instructions for downloading and installing the latest
release (/software/mozilla). And from the download page for mozilla,
you can link to the project's "Get Involved" page. The website is a web,
the filesystem, a hierarchy.
Gervase Markham
Oops, sorry :-)
> > for the existence of the /software directory (see the comments at the
> > bottom of the file).
>
> No, no. /projects is designed to hold the sort of information needed by a
> developer to _understand and modify the code_. /software is for the release
> of the software. Libraries are software, are they not?
This means that any bit of software capable of being released on its own
will need a directory under "software" and one under "projects" as well.
This seems to me like a recipe for confusion. Also, if "software" is for
releases, why not call it "releases". The name is very counter-intuitive.
> > > Having a /projects hierarchy makes about as much sense as having a /docs
> > > hierarchy. Given enough mindless advocacy, anything could be considered
> > > a `project'.
> >
> > Again, true.
>
> That's the point. Then every initiative (since you don't like the word
> project) can have a directory to arrange and display their files.
I have no problem with the word project, not the idea of a projects
directory - it was in my proposal, after all.
> > I'm now leaning more towards having a single top-level directory for each
> > "project". But then we need to decide what additional top-level
> > directories we need for information which applies to the whole
> > organisation (such as hacking docs etc.)
>
> You'll wind up with more top-level directories than you can count,
> and a poor organization to go with it.
Multiple top-level directories isn't necessarily a bad thing. Any system
will work poorly if people don't understand it, and well if they do.
> /softWARE - holds everything relating to the distribution of
> mozilla.org's _wares_
>
> Software is not a project. Development of software is a project. The
> end result of the /project/ is a released /product/. The product is
> software, not the project.
Then, I think this directory has the wrong name, and should be called
"releases".
But why do you think the distinction between software-in-development and
software-that's-released is so big as to split the two parts apart? Why
can't they live together? It also makes it much harder for each software
module owner to have a CVS checkout of just his stuff, because it's across
multiple disparate directories.
> Word games aside, I think there's a valid distinction between using
> the software--for whatever purpose, be it end user or middleman--and
> the development of the software. There is no reason for users to sift
> through project docs aimed at developers.
Having them stored in the same directory does not mean that this will be
the case - this is down to what's on the web pages, not where they are
kept.
> Remember, _HyperText_ Markup Language /can/ link across directories.
Yes, but CVS isn't very good with it. And people inserting stuff will be
mentally confused about where things should live.
Gerv
Matthew Thomas
> > It is quite possible, for example, that the Mozilla base
> > (networking, layout engine, XP Toolkit, etc) will be turned into a
> > number of libraries which individual Mozilla applications can then
> > link to.
>
> Isn't this how things are now? At least on mac, almost everything is
> built as a shared library.
Now matter how `almost' it is, it's not enough while Mozilla is still a
single app. I still get Navigator authentication dialogs annoyingly
taking focus when I'm in the middle of composing a message in Messenger,
because Navigator and Messenger aren't separate apps. And if I crash in
Chatzilla it will take down all my Composer windows too, because
Chatzilla and Composer (an IRC client and an HTML editor! how much less
obviously interdependent could you get?) aren't separate apps.
Simon P. Lucy
> The website is a web,
>the filesystem, a hierarchy.
A nitpick, but possibly an important one. A web cannot be a hierarchy, it
can be sliced as a hierarchy but its really a network. The purpose of
creating a hierarchy is to map to a file system that is inadequate at
representing information networks. People sometimes find it harder to
explain terms in the network context and so fall back onto the hierarchy.
Simon
Matthew Thomas
>...
> A nitpick, but possibly an important one. A web cannot be a
> hierarchy, it can be sliced as a hierarchy but its really a network.
> The purpose of creating a hierarchy is to map to a file system that is
> inadequate at representing information networks.
No. One of the great things about HTTP is that the URL hierarchy need
have no resemblance to the file system whatsoever. I can request
<http://mozilla.org/support/mozilla/5.0/navigator/bookmarks/keywords/>,
and be served a document which actually resides under
/usr/www/docs/end-user/keywords.html, without having to be exposed to
any of the details of the file's actual crufty location.
> People sometimes
> find it harder to explain terms in the network context and so fall
> back onto the hierarchy.
Right. Given that the URL hierarchy and the filesystem do not have to be
equal, the URL hierarchy should be designed so that it provides the most
logical organization for those visiting the site
<http://www.useit.com/alertbox/990321.html>, rather than necessarily
providing the most logical organization for those who put the documents
on the site.
Simon P. Lucy
>"Simon P. Lucy" wrote:
> >...
> > hierarchy, it can be sliced as a hierarchy but its really a network.
> > The purpose of creating a hierarchy is to map to a file system that is
> > inadequate at representing information networks.
>
>have no resemblance to the file system whatsoever. I can request
><http://mozilla.org/support/mozilla/5.0/navigator/bookmarks/keywords/>,
>and be served a document which actually resides under
>/usr/www/docs/end-user/keywords.html, without having to be exposed to
>any of the details of the file's actual crufty location.
I didn't mention anything about URLs, what you say is trivially true. I do
think though that there is confusion between the presentation framework and
the storage framework in all of this discussion.
> > People sometimes
> > find it harder to explain terms in the network context and so fall
> > back onto the hierarchy.
>
>Right. Given that the URL hierarchy and the filesystem do not have to be
>equal, the URL hierarchy should be designed so that it provides the most
>logical organization for those visiting the site
><http://www.useit.com/alertbox/990321.html>, rather than necessarily
>providing the most logical organization for those who put the documents
>on the site.
Yes, exactly.
Simon
Gervase Markham
> > exception of binaries and stuff, everything on a Web site *is* documentation.
>
> I recognize that, which is why both software and projects are symlinked
> under /docs. However, as many people will identify them as top-level, they
> exist there, too. There's no reason why you can't have both, so to all
> intents and purposes besides physical file storage, I put both.
But what we are defining is _exactly_ physical file storage. As others
have pointed out, you can map access directories on top using your web
server if necessary. I think the guiding priciples have to be simplicity
and obviousness for the person committing docs, not ease of navigability
(although that comes with it, to an extent.)
This is why I keep shouting about only have one set of docs directories,
and one set of projects directories, and everything working the same for
Mozilla itself and other projects/modules.
Gerv
fantasai
>
> > > is designed for this sort of thing. My objection was to [her] justification
>
> Oops, sorry :-)
It's okay. ^^
> > > for the existence of the /software directory (see the comments at the
> > > bottom of the file).
> >
> > No, no. /projects is designed to hold the sort of information needed by a
> > developer to _understand and modify the code_. /software is for the release
> > of the software. Libraries are software, are they not?
>
> This means that any bit of software capable of being released on its own
> will need a directory under "software" and one under "projects" as well.
> This seems to me like a recipe for confusion.
Release docs in one directory, everything else in another.
This is confusing?
> Also, if "software" is for releases, why not call it "releases". The name
> is very counter-intuitive.
done (since two nights ago, actually)
>
> > /softWARE - holds everything relating to the distribution of
> > mozilla.org's _wares_
> >
> > Software is not a project. Development of software is a project. The
> > end result of the /project/ is a released /product/. The product is
> > software, not the project.
>
> Then, I think this directory has the wrong name, and should be called
> "releases".
>
> But why do you think the distinction between software-in-development and
> software-that's-released is so big as to split the two parts apart? Why
> can't they live together?
- They are aimed at different audiences.
- Their purposes are completely different.
- They don't follow the same time-table.
- Releases don't always correspond with major changes in code that
require documentation changes or additions; they come out after
many minor changes, also.
- Major changes to the code don't immediately trigger new releases;
the code must be tested and stabilized first.
- Software-that's-released is static. Software-in-development is dynamic.
As I see it, if you were to create a table of all the project-related docs,
you would get something like this:
|| Development Docs || Use Docs (not "User") |
||overview|documentation|project-org||overview|relnotes|build-instruc|
-------||----------------------------------||-------------------------------|-
project||what is |how does it |community/ ||what's |(self- |how to get it|
name || it? | work? |involvment || it do? |explain)| |
You want the split along each row, then by columns
I want it along the column groups, then by rows, then by columns.
> It also makes it much harder for each software module owner to have a
> CVS checkout of just his stuff, because it's across multiple disparate
> directories.
I don't know how module owners are set up for the site. Does adding a
release to the list generally involve checking out the entirety of the
project documentation? Should it?
Anyhow, for comparison, I have put up what, as far as I can tell from
these posts, you want for the directory structure:
http://fantasai.tripod.com/Mozilla/2000/reorg-new.txt
- no releases/ top-level directory - there's one under each project
- no tools/ directory
Find where the following documents would fit, and notify me of any
changes necessary:
http://www.mozilla.org/bugs/
http://www.mozilla.org/quality/help/bugzilla-helper.html
http://www.mozilla.org/bonsai.html
http://www.mozilla.org/newlayout/
Get someone to second that redesign, and if no one counters with a stay,
I'll replace reorg.txt with it. (I'll still dispute the exclusion of /tools)
fantasai
>
> > > To have separate hierarchies for `docs' at all is meaningless. With the
> > > exception of binaries and stuff, everything on a Web site *is* documentation.
> >
> > I recognize that, which is why both software and projects are symlinked
> > under /docs. However, as many people will identify them as top-level, they
> > exist there, too. There's no reason why you can't have both, so to all
> > intents and purposes besides physical file storage, I put both.
>
> But what we are defining is _exactly_ physical file storage.
Didn't know that.
> As others have pointed out, you can map access directories on top using
> your web server if necessary. I think the guiding priciples have to be
> simplicity and obviousness for the person committing docs, not ease of
> navigability (although that comes with it, to an extent.)
> This is why I keep shouting about only have one set of docs directories,
> and one set of projects directories
No, you wanted different docs directories for users, web-developers, and
developers. More than one. I'm still not sure how this should be organized
in *either* plan, so I haven't put the last two in yet.
Still, it could have been streamlined more, and I agree with you there.
So, I have removed the superfluous one in /software, but I've retained
/tools under /docs/dev/tools. (It fits better there.)
> everything working the same for Mozilla itself and other projects/modules.
This is already the case.. It's the main reason why I posted a redesign in
the first place.
Asa Dotzler
<snip>
> Anyhow, for comparison, I have put up what, as far as I can tell from
> these posts, you want for the directory structure:
> http://fantasai.tripod.com/Mozilla/2000/reorg-new.txt
not sure if i'm adding these comments to the right palce in the thread but:
i don't like quality living under documents. it doesn't seem logical
that quality is a kind of documentaion. it is more of a project than it
is a document. i don't like it under projects either since it spans
projects. i think it belongs at the same level as projects and docs or
(my second choice) in the projects directory.
--Asa
Gervase Markham
> these posts, you want for the directory structure:
> http://fantasai.tripod.com/Mozilla/2000/reorg-new.txt
Yep, looks good - but, in fact, the meeting notes, which will be posted
RSN, may change things again. <sigh>
> Find where the following documents would fit, and notify me of any
> changes necessary:
>
> http://www.mozilla.org/bugs/
/projects/bugzilla/
> http://www.mozilla.org/quality/help/bugzilla-helper.html
Roughly the same place as now - see Asa's comment, which I second. quality
is top-level :-)
> http://www.mozilla.org/bonsai.html
/projects/bonsai/ ? I don't know what this doc is offhand, and
www.mozilla.org is down. Perhaps /docs/hacking/, if it's that sort of
thing.
> http://www.mozilla.org/newlayout/
/projects/gecko/
Gerv
fantasai
>
> not sure if i'm adding these comments to the right palce in the thread but:
> i don't like quality living under documents. it doesn't seem logical
> that quality is a kind of documentaion. it is more of a project than it
> is a document. i don't like it under projects either since it spans
> projects. i think it belongs at the same level as projects and docs or
> (my second choice) in the projects directory.
Done.
http://fantasai.tripod.com/Mozilla/2000/reorg.txt
http://fantasai.tripod.com/Mozilla/2000/reorg-new.txt
I've also eliminated the /docs directory and moved its contents to the
top level.
fantasai
>
> > Anyhow, for comparison, I have put up what, as far as I can tell from
> > these posts, you want for the directory structure:
> > http://fantasai.tripod.com/Mozilla/2000/reorg-new.txt
>
> Yep, looks good - but, in fact, the meeting notes, which will be posted
> RSN, may change things again. <sigh>
What's RSN? I'm guessing it means "soon", but that can't be the expansion..
> > http://www.mozilla.org/bonsai.html
>
> /projects/bonsai/ ? I don't know what this doc is offhand, and
> www.mozilla.org is down. Perhaps /docs/hacking/, if it's that sort of
> thing.
Actually, it depends on the section.
Also, this one: http://www.mozilla.org/tools.html
Gervase Markham
> > RSN, may change things again. <sigh>
>
> What's RSN? I'm guessing it means "soon", but that can't be the expansion..
Real Soon Now.
> > > http://www.mozilla.org/bonsai.html
> >
> > /projects/bonsai/ ? I don't know what this doc is offhand, and
> > www.mozilla.org is down. Perhaps /docs/hacking/, if it's that sort of
> > thing.
>
> Actually, it depends on the section.
The top half should go in projects/bonsai/docs, the bottom half in
projects/bonsai/index.html.
> Also, this one: http://www.mozilla.org/tools.html
Subsumed into projects/index.html ;-)
Why are we doing this, again?
Gerv
Matthew Thomas
>...
> At any rate, if you have a better plan, or any specific improvements,
> do post. One can only work with so much abstraction.
Ok. My grand plan, which I did back in August, is at
<http://critique.net.nz/project/mozilla.org/mozilla-org.jpg>.
For purposes of threaded discussion, here's the text from that scan
(with some expansion).
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
* 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')
- press releases
- developer meetings
- parties
* developer info
- Mozilla development
o code architecture overviews
o ports
o accessibility
o usability
o internationalization
o localizations
o good coding style
- application development
o XP Toolkit
o XUL reference
o embedding
- Web development
o supported standards
o articles on cool ways to use the standards
- tools
o Bugzilla
o Bonsai
o LXR
o Tinderbox
* software [I agree with Fantasai that this should be a separate area]
- 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]
* support
- Mozilla Update (detect Mozilla version, and offer upgrades)
- language packs
- FAQs
- links to Usenet groups and IRC channels
* get involved
- quality assurance
o how to report bugs
o how to find duplicates
- advocacy guides
- hacking
o downloading source
o getting CVS access
o building the Lizard
- writing documentation
o style guides
o list of missing documentation
o localizing mozilla.org
- sponsorship
general page contents:
* link to home page
* link to ancestor section
* form for searching ancestor section (and link to advanced search)
* breadcrumb navigation
* links to subcategories
* content
* translation bar (for showing translations of current page)
* boilerplate footer.
Most of the page contents needs to be dynamically generated. Trying to
do stuff like navigation and subcategory links statically is too tedious
and error-prone -- with the result that the current site offers terrible
navigation, other than a context-insensitive `wrapper' which is like
offering a map of the world to someone who's trying to find their way
around a suburb.
maintenance:
* contents, subcategories, etc for each page stored in a database
* registered users (e.g. developers) can make annotations to pages from
within their Web browser, like they can on <http://php.net/manual/>
(allowing for far faster and easier updating of pages by busy people)
* mozilla.org editors can incorporate annotations into the text of the
page in the next revision
* aesthetics of site should change every ~12 months, but navigation
layout should generally stay the same
meta-qualities:
* compliant XHTML and CSS (no TABLEs required, 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
- persistent redirects from old URLs to their new locations, where
URLs need to be changed in order to make them more obvious.
Gervase Markham
> <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
fantasai
>
> > > Yep, looks good - but, in fact, the meeting notes, which will be posted
> > > RSN, may change things again. <sigh>
> >
> > What's RSN? I'm guessing it means "soon", but that can't be the expansion..
>
> Real Soon Now.
Ah, thanks. :)
> > Also, this one: http://www.mozilla.org/tools.html
>
> Subsumed into projects/index.html ;-)
CVS and LXR are mozilla.org projects?
/projects/index.html should be an index to mozilla.org's projects.
tools.html lists and describes the various tools used in
development--that's more of a generic development doc, IMO.
> Why are we doing this, again?
I want to get an idea of where, under reorg-new.txt, the /dev/tools
docs would go.
Matthew Thomas
>...
> > * 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.
No, it doesn't, and we don't.
It's just that Mozilla Navigator is this amazingly standards-compliant
browser, with support for HTML 4.0, and CSS1, and a lot of CSS2, and the
DOM, and all that funky stuff. And when people start it up for the first
time (modulo bug 61121) ... they get presented with
<http://mozilla.org/>, the sort of page which Todd Fahrner refers to as
a `1996-99-era GIF-and-table HTML confection'. To be blunt, it smells.
mozilla.org needs to be more attractive, and it needs to show off
Mozilla's standards support a bit more. Sure, Mozilla testers (except
the ones who regularly test nightlies, and have to trash corrupted
profiles every week or so as a result) are going to change their home
page five minutes after they start up, but Mozilla should still make a
good impression by showing a nice page the first time.
I have prototyped the page design on
<http://critique.net.nz/project/mozilla.org/mozilla-org.jpg> using CSS,
degrading extremely nicely to vanilla HTML for those browsers which have
CSS disabled/unsupported. And the layout resizes and rearranges itself
to work properly whether you're on a workstation or a cellphone. No
TABLEs required.
> > * 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?
Contributing code *is* under "get involved".
|...
| * get involved
| - quality assurance
| o how to report bugs
| o how to find duplicates
| - advocacy guides
| - *** hacking ***
| o downloading source
| o getting CVS access
| o building the Lizard
>...
> > - sponsorship
>
> <raises eyebrows>
Dawn Endico wrote (by e-mail):
|
| we need a credits page for corporate contributors
| (netscape, sourceforge, bluemartini, meer.net)
And I don't see what's wrong with that. The Mozilla Organization has
companies which donate build machines, servers, bandwidth etc. These
companies deserve recognition.
> > * 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)
Yes, but we still need to show the available translations for each page,
because the site (like the rest of the project) is a volunteer effort.
So (for example) someone who is fluent in Japanese, but who prefers to
read Web pages (including mozilla.org docs) in English, can see `oh!
there's no Japanese version of this page! I could translate it for
them ...'
> or we let them
> use a pulldown to use an external translation tool.
Mechanical translations (especially of technical docs, such as those on
mozilla.org) will probably not be as good as human ones for another ten
years, at least.
> > * aesthetics of site should change every ~12 months
>
> Any particular reason?
To keep it looking fresh. All that would be required would be tweaking
the style sheets.
> > * 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.)
I see all `yes' there, I don't see any `no'. You're exactly right. Being
useful is a large part of being usable.
> > - 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.
>...
So where would you draw the line on these (hypothetical) documents about
which are `docs' and which are not:
* Bugzilla Manual
* Bugzilla FAQ
* Bugzilla version history and changelog
* Bugzilla release notes
* Bugzilla download instructions
* Bugzilla download page
`Docs' is just a contraction of the word `documents'.
--
Matthew `mpt' Thomas, Mozilla user interface QA
NB: I will be offline from December 28 to January 8
Gervase Markham
Yeah, OK, fair enough :-) <cop-out> But anyway, this is a long-term-reorg
thing, and so I'm going to stop being obstructive and let the LTT people
get on with it :-) </cop-out>
Gerv
Gervase Markham
> browser, with support for HTML 4.0, and CSS1, and a lot of CSS2, and the
> DOM, and all that funky stuff. And when people start it up for the first
> time (modulo bug 61121) ... they get presented with
> <http://mozilla.org/>, the sort of page which Todd Fahrner refers to as
> a `1996-99-era GIF-and-table HTML confection'. To be blunt, it smells.
Oh, indeed. Bugzilla's playing up again, so I can't look at your bug, but
I would contest the assertion that www.mozilla.org/ needs to be the
default start page at all. As long as we maintain its other aims, it will
always be a bad start page for a browser. What would be better would be a
mozilla.org/start.html (but in the right place, obviously) which is more
geared to that need.
> I have prototyped the page design on
> <http://critique.net.nz/project/mozilla.org/mozilla-org.jpg> using CSS,
I don't seem to be able to reach this. My browser just sits there
"Contacting critique.net.nz..."
> > > * 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?
>
> Contributing code *is* under "get involved".
I was talking about your "developer info" section. Most of the stuff under
/quality now is directly analogous to that.
> | * get involved
> | - quality assurance
> | o how to report bugs
> | o how to find duplicates
> | - advocacy guides
> | - *** hacking ***
> | o downloading source
> | o getting CVS access
> | o building the Lizard
Yes, but then why isn't _everything_ under "get involved"? After all,
everything we do is people getting involved. My point is that people who
are already involved use the QA pages.
> >...
> > > - sponsorship
> >
> > <raises eyebrows>
>
> Dawn Endico wrote (by e-mail):
> |
> | we need a credits page for corporate contributors
> | (netscape, sourceforge, bluemartini, meer.net)
>
> And I don't see what's wrong with that. The Mozilla Organization has
> companies which donate build machines, servers, bandwidth etc. These
> companies deserve recognition.
No, that's fine. I just got the wrong end of the stick.
> Yes, but we still need to show the available translations for each page,
> because the site (like the rest of the project) is a volunteer effort.
> So (for example) someone who is fluent in Japanese, but who prefers to
> read Web pages (including mozilla.org docs) in English, can see `oh!
> there's no Japanese version of this page! I could translate it for
> them ...'
That would be all of them, then :-)
The problem with hand-translations is that they have to be kept up-to-date
with the main version, or else you need some method of marking them as not
up-to-date. But I accept the general point :-)
> > > * aesthetics of site should change every ~12 months
> >
> > Any particular reason?
>
> To keep it looking fresh.
Seems to me (natural conservative that I am ;-) that this is merely change
for change's sake. I like mozilla.org's current look, and it's been that
way for three years :-) Just because something's easy (with style sheets)
doesn't mean it has to be done.
> > > * URL as UI <http://www.useit.com/alertbox/990321.html>
Oops, my mistake. I thought Jakob's point was that URLs should *not* be
used as a method of site navigation, because that's bad UI, and I thought
you were agreeing with that point (which he didn't in fact make). Oops.
> > 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.
> >...
>
> So where would you draw the line on these (hypothetical) documents about
> which are `docs' and which are not:
In any classification scheme there are things which fit in multiple
categories. The fact that this is the case does not invalidate the
classification scheme.
> `Docs' is just a contraction of the word `documents'.
Well, then, let's call it "doc", as a contraction of documentation. But if
you look at the source distribution of any software, there is a particular
class of manual-like texts which are found in a subdir "docs". Most people
understand what is meant.
Gerv
Jake
> I have prototyped the page design on
> <http://critique.net.nz/project/mozilla.org/mozilla-org.jpg> using CSS,
I see you included bugzilla in this... From what I can see, the only
changes your prototype makes is a bit in the header section and
completely rearranging the the fields. The header isn't terribly hard
to change. I am a bit "Bugzilla Home -> Bug 48320" part as bugzilla
currently has very little support for templates (a bit in the header, a
bit in the footer).
Rearranging the fields, on the other hand, is a major undertaking as
this HTML code is burried inside the bug_form.pl perl script. If there
were a good enough reason, it could probably be done, but I don't think
it would/should be done just for the sake of doing it.
I think any major UI changes to bugzilla should wait until 3.0 which
should have better support for customization.
fantasai
|
| 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.
Matthew Thomas
>...
> > <http://mozilla.org/>, the sort of page which Todd Fahrner refers to
> > as a `1996-99-era GIF-and-table HTML confection'. To be blunt, it
> > smells.
>
> Oh, indeed. Bugzilla's playing up again, so I can't look at your bug,
> but I would contest the assertion that www.mozilla.org/ needs to be
> the default start page at all. As long as we maintain its other aims,
> it will always be a bad start page for a browser.
It's not mozilla.org's job to provide a portal-like start page for
Mozilla Navigator. It's mozilla.org's job to attract (and coordinate)
developers. And if we can use the default home page as part of doing
that, that's good.
An attractive <http://mozilla.org/>, which makes it easy for visitors to
find ways to contribute to Mozilla, will help turn many of those Mozilla
end users (the people who don't use Mozilla builds for testing, the
people who actually use them for Web browsing and e-mail, the people who
Ben Bucksch pretends doesn't exist) from passive users into Mozilla
contributors.
>...
> > I have prototyped the page design on
> > <http://critique.net.nz/project/mozilla.org/mozilla-org.jpg> using
> > CSS,
>
> I don't seem to be able to reach this. My browser just sits there
> "Contacting critique.net.nz..."
Worksforme.
>...
> > Contributing code *is* under "get involved".
>
> I was talking about your "developer info" section. Most of the stuff
> under /quality now is directly analogous to that.
`Developer info' is for when you're already involved. It would include
testcases, testing tools, etc for QA people, linked from the relevant
functional and UI specs for the programming people.
>...
> Yes, but then why isn't _everything_ under "get involved"? After all,
> everything we do is people getting involved.
No it isn't. Documents such as
<http://mozilla.org/projects/xpcom/nsString.html>, or
<http://mozilla.org/projects/security/components/design.html>, or
<http://mozilla.org/projects/embedding/embeddingTasks.html> are nothing
to do with people getting involved. They're developer info, for people
who are *already* involved.
> My point is that people
> who are already involved use the QA pages.
Now that I'm already involved in QA and know what I'm doing, I never
look at the QA pages at all.
>...
> > `Docs' is just a contraction of the word `documents'.
>
> Well, then, let's call it "doc", as a contraction of documentation.
> But if you look at the source distribution of any software, there is a
> particular class of manual-like texts which are found in a subdir
> "docs". Most people understand what is meant.
>...
mozilla.org is not a software distribution. mozilla.org is a Web site.
Matthew Thomas
>...
> I see you included bugzilla in this... From what I can see, the only
> changes your prototype makes is a bit in the header section and
> completely rearranging the the fields.
Well, I didn't include a mockup of my ideas for a redesigned Bugzilla
home page. (Disclaimer: I designed the current Bugzilla home page.)
The new home page would include hourly-updated lists of things like:
* 5 most recently-reported bugs
* 5 oldest unconfirmed/unverified/qawanted bugs
* 5 most-doomed assignees (with links to their bugs)
* 5 most-doomed QA contacts (with links to their bugs)
* 5 random open bugs.
>...
> I think any major UI changes to bugzilla should wait until 3.0 which
> should have better support for customization.
Yes. And the sooner this comes, the better. The current Bugzilla UI is
awful, and by improving its usability even 10 or 20 percent we could
probably double the number of QA volunteers. (The same applies to the
mozilla.org Web site in general, with the number of Mozilla contributors
in general.)
KOIKE Kazuhiko
> Yes, but we still need to show the available translations for each page,
> because the site (like the rest of the project) is a volunteer effort.
> So (for example) someone who is fluent in Japanese, but who prefers to
> read Web pages (including mozilla.org docs) in English, can see `oh!
> there's no Japanese version of this page! I could translate it for
> them ...'
We already have the Japanese translation of mozilla.org.
Japanese volunteers have translated hundreds of documents. It will be
nice if we visit an English page in mozilla.org and find it has a
Japanese translation.
KOIKE Kazuhiko
Simon P. Lucy
>Matthew Thomas wrote:
>
>>Yes, but we still need to show the available translations for each page,
>>because the site (like the rest of the project) is a volunteer effort.
>>So (for example) someone who is fluent in Japanese, but who prefers to
>>read Web pages (including mozilla.org docs) in English, can see `oh!
>>there's no Japanese version of this page! I could translate it for
>>them ...'
>
>
>http://jt.mozilla.gr.jp/
>
>Japanese volunteers have translated hundreds of documents. It will be nice
>if we visit an English page in mozilla.org and find it has a Japanese
>translation.
The Japanese effort is remarkable, I think though that Matthew was using it
as an example, it would be the same for a Korean to translate it into
Hangul, or an Italian, etc.
Simon
>KOIKE Kazuhiko
>
>
Ryuzi Kambe
> > because the site (like the rest of the project) is a volunteer effort.
> > So (for example) someone who is fluent in Japanese, but who prefers to
> > read Web pages (including mozilla.org docs) in English, can see `oh!
> > there's no Japanese version of this page! I could translate it for
> > them ...'
Hi,i am a member of the mozilla.org Japanese Translation Project.
http://www.mozilla.gr.jp/jt/index.html
(mozilla.org allows us to translate the document,we have got a
permission)
I want a system on the mozilla.org to support translate documentation.
like this...
1.display or get a document without tmplate with a HTML or its source)
2.there would a e-mail adress or form to commit our work each of the
page.
3.(if any) there is a translation QA or reviewer,and they would check
the
quarity of the document.
4.after checking,the document would be update to the front page by a
translation document manager(IT IS NEEDED WHO HAS A MIGHT TO CHECK IN).
5.the document would be treated as a translation version of the
document.
(but out of the law)
if there would such a system,we all could contribute rather than now we
do.
and many people could read each language version with high quarity.
> That would be all of them, then :-)
yep,that's right
> The problem with hand-translations is that they have to be kept up-to-date
> with the main version, or else you need some method of marking them as not
> up-to-date. But I accept the general point :-)
i agree.this is a good system.
Ryuzi Kambe
ka...@mc.kcom.ne.jp
Asa Dotzler
<snip>
> Now that I'm already involved in QA and know what I'm doing, I never
>
> look at the QA pages at all.
This is a shortcoming of the QA documentation, not, I think, an intended
result. Ultimately I think the QA and Testing pages should be focused
on qa and testing -- test suites, specifications, quality measurement
and tracking, etc. However, I think that much of what belongs in this
section _will_ have a "how to" feel like "how to run this testcase"
which may be less useful to those already familiar with that particular
area or test. There may also be pages that have "how to get involved
-beginner/intermediate/advanced" which point to content (specs and
testcases or other activities like triage or quality tracking) within
the differnet QA Groups. Maybe this second class of documents (a couple
docs might suffice) belongs in a "getting involved" section.
-Asa
Gervase Markham
> > but I would contest the assertion that www.mozilla.org/ needs to be
> > the default start page at all. As long as we maintain its other aims,
> > it will always be a bad start page for a browser.
>
> It's not mozilla.org's job to provide a portal-like start page for
> Mozilla Navigator.
Sorry, that's what I thought you were saying.
> An attractive <http://mozilla.org/>, which makes it easy for visitors to
<snip>
Oh, yeah, sure. <me gets wrong end of stick again>
> > I don't seem to be able to reach this. My browser just sits there
> > "Contacting critique.net.nz..."
>
> Worksforme.
Yes, got it now. Anyway, you emailed me this :-)
> > I was talking about your "developer info" section. Most of the stuff
> > under /quality now is directly analogous to that.
>
> `Developer info' is for when you're already involved. It would include
> testcases, testing tools, etc for QA people, linked from the relevant
> functional and UI specs for the programming people.
But QA people aren't "developers" (in the normally-understood sense of the
word.) So their stuff shouldn't be under "developer info". Quality is a
top-level directory at the moment, and it works well there.
> Now that I'm already involved in QA and know what I'm doing, I never
> look at the QA pages at all.
See Asa's comment. And I use them all the time.
> > Well, then, let's call it "doc", as a contraction of documentation.
> > But if you look at the source distribution of any software, there is a
> > particular class of manual-like texts which are found in a subdir
> > "docs". Most people understand what is meant.
> >...
>
> mozilla.org is not a software distribution. mozilla.org is a Web site.
Yes. And a subset of pages that it contains are documentation for software
(in the above sense.) So, if we have a top-level dir "software", and
subdirs for e.g. "Bugzilla", it should have a subdir "docs".
Gerv
Matthew Thomas
>
> Matthew Thomas wrote:
>...
> | - 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..
Yes, except that it would work. (Notice how nobody uses Newsbot any
more.)
>...
> 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.
Yes. A typical URL might be
<http://mozilla.org/news/2000/04/>, which would have links to all the
news items for April 2000. Most (but not all) of these `news items'
would be pointers to recently-updated documents elsewhere on the site,
in sections that would have their own datestamp (e.g.
<http://mozilla.org/events/mozilla.party/1999/>), but some would be
articles in the News hierarchy itself (e.g.
<http://mozilla.org/news/2006/07/fantasai.interview/>).
> Latest stuff can go without a date.
No. URLs should be designed to be persistent, otherwise you will suffer
linkrot <http://www.useit.com/alertbox/980614.html>. This means that if
datestamps are ever going to be used for documents, then that includes
the latest stuff.
> | * 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.
Not just guidelines, but all documents relating to these aspects of the
development of Mozilla (what some people are referring to as
`projects').
> | - application development
> | o XP Toolkit
> | o XUL reference
> | o embedding
>
> Who are these documents aimed at?
> - Mozilla developers
> - outside developers using Mozilla code
> - both
Both. (Whereas the documents in the `Mozilla development' section are
mainly of interest to Mozilla developers.)
> | - 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.
It's not under Mozilla development, it's under `Developer'. Something
like a Mozilla standards compliance status update will be of interest to
Mozilla developers, application developers, and Web developers alike, so
it would be splashed at the second-level `Developer' section; whereas
other items would be of interest only to one particular class of
developers, and would appear in their third-level pages.
> /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.
Well, if there are ways for developers to use NNTP, SMTP, IMAP, etc
which are interesting enough to be written about on mozilla.org, then
maybe so. But the only thing I can think of which falls into that
category is telling mailing list maintainers how to use the
`Unsubscribe-To:' header (which Mozilla doesn't even support yet).
>...
> | * software [I agree with Fantasai that this should be a separate
> | area]
>
> /software or /releases?
/software. Installation instructions, feature summaries, etc would go in
this section, not just release notes (which is what /releases implies).
>...
> | * 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.
I think it would be easier for people looking for this stuff to find it
starting from a single place, rather than having to go into separate
areas for each application.
>...
> | - advocacy guides
>
> ?
<http://www.datasync.com/~rogerspl/Advocacy-HOWTO.html>
>...
> 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.
All of them are required if you are intending to `hack' Mozilla in the
general sense (which doesn't necessarily involve modifying the code).
>...
> Where do community-related things go?
> - newsgroups/mailing lists
Generally, under the Get Involved section. Specifically, under the
relevant Developer (or Support) sections.
> - links to other mozilla-related sites
dmoz.org. Listing them on mozilla.org itself would be a slippery slope.
>...
> | * breadcrumb navigation
> What's this? ^
You are here: _mozilla.org_ > _Developer_ > _Application_development_ >
_XP_Toolkit_ > _XUL_Reference_ > tabbox
A breadcrumb trail of links leading from the front page to where you are
now.
>...
> | - 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.
Exactly right.
Micah Harwell
> What's the difference between /docs, /projects/docs and
> /projects/project_name/docs? Too many docs directories :-)
>
> Why is mozilla not a project? Why have another directory called software?
> Aren't projects software?
Unless I'm mistaken, Seamonkey is the name of the project, not
Mozilla. Wouldn't we have /projects/seamonkey/ instead?
--
Micah Harwell
Industrial Techware
http://www.industrialtechware.com/
Gervase Markham
> Mozilla. Wouldn't we have /projects/seamonkey/ instead?
I believe that that's rather deprecated - seamonkey was the old name for
the browser bit. It's disappearing in the NG renaming, and it should
probably disappear in the website reorg too.
Gerv
fantasai
| fantasai wrote:
| >...
| > 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.
|
| Yes. A typical URL might be
| <http://mozilla.org/news/2000/04/>, which would have links to all the
| news items for April 2000. Most (but not all) of these `news items'
| would be pointers to recently-updated documents elsewhere on the site,
| in sections that would have their own datestamp (e.g.
| <http://mozilla.org/events/mozilla.party/1999/>), but some would be
| articles in the News hierarchy itself (e.g.
| <http://mozilla.org/news/2006/07/fantasai.interview/>).
I think the structure before the date (at least before the year)
should be minimal, which isn't the case with
http://mozilla.org/events/mozilla.party/1999/.
Is http://mozilla.org/news/1999/events/mozilla.party/ acceptable?
Also, is there a reason why you chose numbers as opposed to
names for the months?
Where would you put general articles--that is, informational
articles that aren't particularly dated? (Something like a
National Geographic article, which is not news yet relevant to
the time though not any particular date.) Under the release date?
| > Latest stuff can go without a date.
|
| No. URLs should be designed to be persistent, otherwise you will suffer
| linkrot <http://www.useit.com/alertbox/980614.html>. This means that if
| datestamps are ever going to be used for documents, then that includes
| the latest stuff.
Gotcha.
| > | * 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.
|
| Not just guidelines, but all documents relating to these aspects of the
| development of Mozilla (what some people are referring to as
| `projects').
So, what do you refer to as 'projects'? It needs to be there,
as a coordinating point for each specific aspect of Mozilla.
And what, consequently, from the 'projects' directory, would
you put under general Mozilla development?
Also, would you post a short description of each of the Mozilla
development categories? I'm having trouble imagining what sorts
of things would go in each.
| > | - application development
| > | o XP Toolkit
| > | o XUL reference
| > | o embedding
| >
| > Who are these documents aimed at?
| > - Mozilla developers
| > - outside developers using Mozilla code
| > - both
|
| Both. (Whereas the documents in the `Mozilla development' section are
| mainly of interest to Mozilla developers.)
|
| > | - 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.
|
| It's not under Mozilla development, it's under `Developer'. Something
| like a Mozilla standards compliance status update will be of interest to
| Mozilla developers, application developers, and Web developers alike, so
| it would be splashed at the second-level `Developer' section; whereas
| other items would be of interest only to one particular class of
| developers, and would appear in their third-level pages.
Ok, I see what you're doing here--misinterpreted your use of "developer".
|
| > /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.
|
| Well, if there are ways for developers to use NNTP, SMTP, IMAP, etc
| which are interesting enough to be written about on mozilla.org, then
| maybe so. But the only thing I can think of which falls into that
| category is telling mailing list maintainers how to use the
| `Unsubscribe-To:' header (which Mozilla doesn't even support yet).
Ok
| >...
| > | * software [I agree with Fantasai that this should be a separate
| > | area]
| >
| > /software or /releases?
|
| /software. Installation instructions, feature summaries, etc would go in
| this section, not just release notes (which is what /releases implies).
All right.
1 for /software
1 for /releases
Since that's a tie, and I prefer /software, it's been changed back (for now).
Any comments from the community at large?
| > | * 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.
|
| I think it would be easier for people looking for this stuff to find it
| starting from a single place, rather than having to go into separate
| areas for each application.
Logically or physically? IMO, the documents should physically go under
their respective release directories--that includes the web address.
But a general support page can tie these up with links.
| >...
| > | - advocacy guides
| >
| > ?
|
| <http://www.datasync.com/~rogerspl/Advocacy-HOWTO.html>
--> /advocacy. Objections?
| >...
| > 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.
|
| All of them are required if you are intending to `hack' Mozilla in the
| general sense (which doesn't necessarily involve modifying the code).
I think coding style and rules for changing builds are better classified
as "hacking".
| >...
| > Where do community-related things go?
| > - newsgroups/mailing lists
|
| Generally, under the Get Involved section. Specifically, under the
| relevant Developer (or Support) sections.
Developer > Mozilla > Get Involved > Community is a bit much, I think.
Would this do?
Devloper > Mozilla > Community
|
| > - links to other mozilla-related sites
|
| dmoz.org. Listing them on mozilla.org itself would be a slippery slope.
|
| >...
| > | * breadcrumb navigation
| > What's this? ^
|
| You are here: _mozilla.org_ > _Developer_ > _Application_development_ >
| _XP_Toolkit_ > _XUL_Reference_ > tabbox
|
| A breadcrumb trail of links leading from the front page to where you are
| now.
Ah, yes. Thanks.
fantasai
http://fantasai.tripod.com/Mozilla/2000/reorg.txt
but haven't taken into account most of Matthew's
post.
I've also put up
http://fantasai.tripod.com/Mozilla/2000/reorg-fr.txt
which mirrors my local scrap file, so to speak, where
I'm trying to work in more of mozilla.org's development
files.
I've also moved documentation up to
/dev/documentation/thing_being_documented
instead of
/projects/project_name/docs/.
If anyone approves, I'll copy the change into reorg.txt.
~fantasai
Matthew Thomas
>...
> I think the structure before the date (at least before the year)
> should be minimal, which isn't the case with
> http://mozilla.org/events/mozilla.party/1999/.
Any particular reason? (Normally I imagine it would be, but not in the
case of a regular thing such as mozilla.party.)
> Is http://mozilla.org/news/1999/events/mozilla.party/ acceptable?
No, because the parties have more to do with each other than they have
to do with other events in the same year.
> Also, is there a reason why you chose numbers as opposed to
> names for the months?
Three reasons, in descending order of importance: conciseness,
internationalization, and alphabetical sorting in FTP listings.
> Where would you put general articles--that is, informational
> articles that aren't particularly dated? (Something like a
> National Geographic article, which is not news yet relevant to
> the time though not any particular date.) Under the release date?
If the article was a useful part of a larger knowledge base, then it
would go in its relevant section (e.g.
<http://mozilla.org/developer/web/style/alternate.stylesheets/>). As I
said, most items in the `News & Events' section would actually be links
to new/updated documents in other sections.
Otherwise, an article would go in the news/ hierarchy under its year and
month hierarchies.
>...[`Mozilla Developer' section]
>
> | Not just guidelines, but all documents relating to these aspects of
> | the development of Mozilla (what some people are referring to as
> | `projects').
>
> So, what do you refer to as 'projects'?
I don't. Like I said, given enough hype, anything within Mozilla could
be referred to as a `project'. It's a more or less meaningless
categorization.
>...
> Also, would you post a short description of each of the Mozilla
> development categories? I'm having trouble imagining what sorts
> of things would go in each.
The ones I posted were just examples. Most of the documents currently
linked to from <http://mozilla.org/docs/> (from the `Core Mozilla
architecture' section onwards) would end up in the `Developer' >
`Mozilla Developer' section.
>...
> | I think it would be easier for people looking for this stuff to
> | find it starting from a single place, rather than having to go into
> | separate areas for each application.
>
> Logically or physically? IMO, the documents should physically go under
> their respective release directories--that includes the web address.
> But a general support page can tie these up with links.
Nothing wrong with that in itself -- but it would have to be possible
for people to do a search of all the documents linked to from the
`Support' section (e.g., search for the phrase `security hole') without
the search returning documents from other sections. If they weren't
under the same (either) directory or URL hierarchy, this would be
considerably more difficult to set up.
>...
> | > Where do community-related things go?
> | > - newsgroups/mailing lists
> |
> | Generally, under the Get Involved section. Specifically, under the
> | relevant Developer (or Support) sections.
>
> Developer > Mozilla > Get Involved > Community is a bit much, I think.
>...
It's not. It's `Get Involved' > `Discussion groups'. The URL would be
<http://mozilla.org/contribute/discussion/>.
fantasai
| fantasai wrote:
| >...
| > I think the structure before the date (at least before the year)
| > should be minimal, which isn't the case with
| > http://mozilla.org/events/mozilla.party/1999/.
|
| Any particular reason? (Normally I imagine it would be, but not in the
| case of a regular thing such as mozilla.party.)
Because that structure might change over the course of, say, five years.
For instance, one might decide to further subdivide it by location:
http://mozilla.org/events/mozilla.party/jp/2004/
which doesn't follow the pattern from 1999.
|
| > Is http://mozilla.org/news/1999/events/mozilla.party/ acceptable?
|
| No, because the parties have more to do with each other than they have
| to do with other events in the same year.
http://mozilla.org/events/1999/mozilla.party/
| > Also, is there a reason why you chose numbers as opposed to
| > names for the months?
|
| Three reasons, in descending order of importance: conciseness,
| internationalization, and alphabetical sorting in FTP listings.
I'll accept the alphabetical sorting. IMO, recognition is more
important than conciseness. Although I've been using numbers
for years, it's still not as automatic as seeing the names.
Besides, you only gain one character if the names are abbreviated.
|
| > Where would you put general articles--that is, informational
| > articles that aren't particularly dated? (Something like a
| > National Geographic article, which is not news yet relevant to
| > the time though not any particular date.) Under the release date?
|
| If the article was a useful part of a larger knowledge base, then it
| would go in its relevant section (e.g.
| <http://mozilla.org/developer/web/style/alternate.stylesheets/>). As I
| said, most items in the `News & Events' section would actually be links
| to new/updated documents in other sections.
| Otherwise, an article would go in the news/ hierarchy under its year and
| month hierarchies.
Ok, but where would you put such articles that are outdated? Like,
an article on Russia today would be of historical, but not current,
significance ten years from now. So, an article on writing web pages
for Mozilla today--which would go under Web Developer--where can I
find it ten years from now?
|
| >...[`Mozilla Developer' section]
| >
| > | Not just guidelines, but all documents relating to these aspects of
| > | the development of Mozilla (what some people are referring to as
| > | `projects').
| >
| > So, what do you refer to as 'projects'?
|
| I don't. Like I said, given enough hype, anything within Mozilla could
| be referred to as a `project'.
What is your objection to that?
| It's a more or less meaningless categorization.
I disagree. I think it's currently a meaningless categorization,
but that it can be a useful one in reorganization.
|
| >...
| > Also, would you post a short description of each of the Mozilla
| > development categories? I'm having trouble imagining what sorts
| > of things would go in each.
|
| The ones I posted were just examples. Most of the documents currently
| linked to from <http://mozilla.org/docs/> (from the `Core Mozilla
| architecture' section onwards) would end up in the `Developer' >
| `Mozilla Developer' section.
These all go at that level?
http://www.mozilla.org/projects/xbl/xbl.html
http://www.mozilla.org/projects/xpcom/nsCOMPtr/
http://www.mozilla.org/hacking/portable-cpp.html
http://www.mozilla.org/newlayout/
| >...
| > | I think it would be easier for people looking for this stuff to
| > | find it starting from a single place, rather than having to go into
| > | separate areas for each application.
| >
| > Logically or physically? IMO, the documents should physically go under
| > their respective release directories--that includes the web address.
| > But a general support page can tie these up with links.
|
| Nothing wrong with that in itself -- but it would have to be possible
| for people to do a search of all the documents linked to from the
| `Support' section (e.g., search for the phrase `security hole') without
| the search returning documents from other sections. If they weren't
| under the same (either) directory or URL hierarchy, this would be
| considerably more difficult to set up.
I don't think someone searching for security holes in their
copy of Messenger will be interested in any password security
holes in Bugzilla. (Not that there are any--I wouldn't know.)
Generally speaking, you're going to want to search under the
product *you* have and not all the support pages provided for
everything else.
Also, I don't think it's such a bad thing if you can include
the release notes in your tech support search.
| >...
| > | > Where do community-related things go?
| > | > - newsgroups/mailing lists
| > |
| > | Generally, under the Get Involved section. Specifically, under the
| > | relevant Developer (or Support) sections.
| >
| > Developer > Mozilla > Get Involved > Community is a bit much, I think.
| >...
|
| It's not. It's `Get Involved' > `Discussion groups'. The URL would be
| <http://mozilla.org/contribute/discussion/>.
I see.
I still think Get Involved is an awkward and ambiguous
categorization. Where do you draw the line between
"Getting Involved" and /being/ involved? It's like the
"docs" you were complaining about.
For example, I can be involved in Mozilla layout by using
my bugzilla account, even if I'm not subscribed to
n.p.m.layout. If I later decide to subscribe to the layout
newsgroup, must I go to Get Involved, when I'm already
involved? Or does "Get Involved" mean involved with the
newsgroup specifically, not the layout project?
Which specific pages under QA would go under Get Involved?
Those asking for help? Those aimed at beginners? Those aimed
at people beginning to become advanced?
Why are the instructions for building Mozilla under "Get
Involved" and not the guidelines for writing C++?
If you're going to get -CVS access-, you must demonstrate
-good coding practices-.
I don't see why pages should be split up like this. IMO, the
topic and the audience are more important in categorization.
Pull out "Get Involved" and your hierarchies are no longer as
self-contained, but cross-linked far more than necessary.
<blockquote cite="http://www.useit.com/alertbox/990321.html">
- URLs that visualize the site structure
- URLs that are "hackable" to allow users to move to higher
levels of the information architecture by hacking off the
end of the URL
</blockquote>
From "getting CVS access", I should be able to move -up- to
"Developer", shouldn't I?
On 2000-12-16, Gervase Markham wrote in "Re: New Structure"
<3A3BCBE8...@univ.ox.ac.uk>:
[ A good design for the site should have the following qualities:
[
[ a) Obviousness. Given a document in your hand, it should be obvious
[ exactly where in the tree it goes in the vast majority of cases.
[ ...
[ c) Split along the fault lines. The divisions should be where they
[ are in people's heads.
Matthew Thomas
>
> Matthew Thomas wrote:
> |
> | fantasai wrote:
> | >...
> | > I think the structure before the date (at least before the year)
> | > should be minimal, which isn't the case with
> | > http://mozilla.org/events/mozilla.party/1999/.
> Because that structure might change over the course of, say, five
> years. For instance, one might decide to further subdivide it by
> location:
> http://mozilla.org/events/mozilla.party/jp/2004/
> which doesn't follow the pattern from 1999.
Or we could get really really paranoid about future compatibility, and
have <http://mozilla.org/event?type=party&date=1999&area=jp>, so that
the order of the arguments didn't matter ...
>...
> | If the article was a useful part of a larger knowledge base, then
> | it would go in its relevant section (e.g.
> | <http://mozilla.org/developer/web/style/alternate.stylesheets/>).
> | As I said, most items in the `News & Events' section would actually
> | be links to new/updated documents in other sections.
> | Otherwise, an article would go in the news/ hierarchy under its
> | year and month hierarchies.
>
> Ok, but where would you put such articles that are outdated? Like,
> an article on Russia today would be of historical, but not current,
> significance ten years from now. So, an article on writing web pages
> for Mozilla today--which would go under Web Developer--where can I
> find it ten years from now?
Ok, make the URL <http://mozilla.org/developer/web/style/user.choice/>,
so it's not implementation-specific. That URL would be understood to
mean `discussion of the state of the art in allowing users to choose
different styles in which to present Web documents'. Meanwhile,
<http://mozilla.org/developer/web/style/user.choice/2000/> would mean
`discussion of how allowing users to choose different styles in which to
present Web documents could be achieved in 2000'. Right now these two
URLs would have the same content, but over the next few months/years
they would gradually diverge. (This is the sort of scheme used in the
<http://www.w3.org/TR/> hierarchy, albeit that the W3C needs to use more
specific dates for its recommendations and drafts thereof.)
>...
> | > So, what do you refer to as 'projects'?
> |
> | I don't. Like I said, given enough hype, anything within Mozilla
> | could be referred to as a `project'.
>
> What is your objection to that?
That it's a more or less meaningless categorization.
> | It's a more or less meaningless categorization.
>
> I disagree. I think it's currently a meaningless categorization,
> but that it can be a useful one in reorganization.
Sure. We can use it somewhere on the site where we can't think of a
better name for something. :-)
>...
> | The ones I posted were just examples. Most of the documents
> | currently linked to from <http://mozilla.org/docs/> (from the `Core
> | Mozilla architecture' section onwards) would end up in the
> | `Developer' > `Mozilla Developer' section.
>
> These all go at that level?
No.
> http://www.mozilla.org/projects/xbl/xbl.html
Developer > Application Developer > XP Toolkit > XBL > Specification > 1.0
> http://www.mozilla.org/projects/xpcom/nsCOMPtr/
Developer > Mozilla Developer > Technology > XPCOM > nsCOMPtr
> http://www.mozilla.org/hacking/portable-cpp.html
Developer > Mozilla Developer > Qualities > Portability > C++
portability guide
> http://www.mozilla.org/newlayout/
Developer > Mozilla Developer > Technology > NGLayout
>...
> I still think Get Involved is an awkward and ambiguous
> categorization. Where do you draw the line between
> "Getting Involved" and /being/ involved?
Probably a good rule of thumb would be that items in the `Getting
involved' section would be ones that you would only need to visit once,
whereas those in the `Developer' section would be useful references to
return to again and again.
>...
> For example, I can be involved in Mozilla layout by using
> my bugzilla account, even if I'm not subscribed to
> n.p.m.layout. If I later decide to subscribe to the layout
> newsgroup, must I go to Get Involved, when I'm already
> involved?
No, because there is also a link to it from the NGLayout main page.
> Or does "Get Involved" mean involved with the
> newsgroup specifically, not the layout project?
It means with the project generally.
> Which specific pages under QA would go under Get Involved?
> Those asking for help? Those aimed at beginners? Those aimed
> at people beginning to become advanced?
All of the above.
> Why are the instructions for building Mozilla under "Get
> Involved" and not the guidelines for writing C++?
Because the former is a one-time thing (once you have built Mozilla
once, any problems you have building it later are likely to be too
esoteric to be in the build instructions), but the latter is a reference
which you may need to refresh yourself on every few months (or when you
break the tree).
> If you're going to get -CVS access-, you must demonstrate
> -good coding practices-.
I guess the non-coders who want to fix up the Web site are doomed, then?
> I don't see why pages should be split up like this. IMO, the
> topic and the audience are more important in categorization.
> Pull out "Get Involved" and your hierarchies are no longer as
> self-contained, but cross-linked far more than necessary.
Alternatively, lump them all together like we do now, and you have half
as many volunteer contributors as you would otherwise -- because those
who are half-interested in helping out the project are wading through a
mountain of documents about nsCOMPtrs and jar packaging.
I know which I'd choose.
>...
> On 2000-12-16, Gervase Markham wrote in "Re: New Structure"
> <3A3BCBE8...@univ.ox.ac.uk>:
> [ A good design for the site should have the following qualities:
> [
> [ a) Obviousness. Given a document in your hand, it should be
> [ obvious exactly where in the tree it goes in the vast majority
> [ of cases.
> [ ...
> [ c) Split along the fault lines. The divisions should be where they
> [ are in people's heads.
Yes. So if we had the budget, we'd do Jakob Nielsen's trick of giving 50
people (evenly split amongst current contributors, and people who've
never heard of Mozilla) a bunch of cards, each containing a description
of one of mozilla.org's Web pages, and we'd ask them to sort the cards
into 4~8 categories, and we'd use the categorization which the majority
of people came up with.
But since we don't have the budget to do that (just as we don't have the
budget to do exhaustive usability testing of the Mozilla user interface
itself), we just have to use common sense and a bit of guesswork instead.
--
Matthew `mpt' Thomas, Mozilla user interface QA
fantasai
|
| fantasai wrote:
| >
| > Matthew Thomas wrote:
| > |
| > | fantasai wrote:
| > | >...
| > | > I think the structure before the date (at least before the year)
| > | > should be minimal, which isn't the case with
| > | > http://mozilla.org/events/mozilla.party/1999/.
| >...
| > Because that structure might change over the course of, say, five
| > years. For instance, one might decide to further subdivide it by
| > location:
| > http://mozilla.org/events/mozilla.party/jp/2004/
| > which doesn't follow the pattern from 1999.
|
| Or we could get really really paranoid about future compatibility, and
| have <http://mozilla.org/event?type=party&date=1999&area=jp>, so that
| the order of the arguments didn't matter ...
#_#
Events are highly date-oriented. Now, explain to me what,
specifically, is wrong with
http://mozilla.org/events/1999/mozilla.party/
|
| >...
| > | If the article was a useful part of a larger knowledge base, then
| > | it would go in its relevant section (e.g.
| > | <http://mozilla.org/developer/web/style/alternate.stylesheets/>).
| > | As I said, most items in the `News & Events' section would actually
| > | be links to new/updated documents in other sections.
| > | Otherwise, an article would go in the news/ hierarchy under its
| > | year and month hierarchies.
| >
| > Ok, but where would you put such articles that are outdated? Like,
| > an article on Russia today would be of historical, but not current,
| > significance ten years from now. So, an article on writing web pages
| > for Mozilla today--which would go under Web Developer--where can I
| > find it ten years from now?
|
| Ok, make the URL <http://mozilla.org/developer/web/style/user.choice/>,
| so it's not implementation-specific. That URL would be understood to
| mean `discussion of the state of the art in allowing users to choose
| different styles in which to present Web documents'. Meanwhile,
| <http://mozilla.org/developer/web/style/user.choice/2000/> would mean
| `discussion of how allowing users to choose different styles in which to
| present Web documents could be achieved in 2000'. Right now these two
| URLs would have the same content, but over the next few months/years
| they would gradually diverge. (This is the sort of scheme used in the
| <http://www.w3.org/TR/> hierarchy, albeit that the W3C needs to use more
| specific dates for its recommendations and drafts thereof.)
So, to put it shortly, the generic location of the article would
contain dated subdirectories to hold previous versions. ?
| >...
| > | > So, what do you refer to as 'projects'?
| > |
| > | I don't. Like I said, given enough hype, anything within Mozilla
| > | could be referred to as a `project'.
| >
| > What is your objection to that?
|
| That it's a more or less meaningless categorization.
All right. I'm sorry, I read more into your use of "thing",
limiting it with the definition of project rather than taking
the word by its own literal definition.
As for my question, it was intended to ask "What is so
objectionable about allowing any mozilla-sanctioned concerted
effort to obtain its own directory to facilitate coordination
of its members?"
|
| > | It's a more or less meaningless categorization.
| >
| > I disagree. I think it's currently a meaningless categorization,
| > but that it can be a useful one in reorganization.
|
| Sure. We can use it somewhere on the site where we can't think of a
| better name for something. :-)
The word /has/ a definition, you know.
| > | >...
| > | > Also, would you post a short description of each of the Mozilla
| > | > development categories? I'm having trouble imagining what sorts
| > | > of things would go in each.
| > |
| > | The ones I posted were just examples. Most of the documents
| > | currently linked to from <http://mozilla.org/docs/> (from the `Core
| > | Mozilla architecture' section onwards) would end up in the
| > | `Developer' > `Mozilla Developer' section.
| >
| > These all go at that level?
|
| No.
Then why didn't you say so? I can't read your mind, Matthew.
|
| > http://www.mozilla.org/projects/xbl/xbl.html
|
| Developer > Application Developer > XP Toolkit > XBL > Specification > 1.0
|
| > http://www.mozilla.org/projects/xpcom/nsCOMPtr/
|
| Developer > Mozilla Developer > Technology > XPCOM > nsCOMPtr
No objections. I like "Technology".
| > http://www.mozilla.org/hacking/portable-cpp.html
|
| Developer > Mozilla Developer > Qualities > Portability > C++
| portability guide
I'm thinking, either "Qualities" includes stuff like
localizability and i18n, or Portability moves up to
their level, eliminating the category.
|
| > http://www.mozilla.org/newlayout/
|
| Developer > Mozilla Developer > Technology > NGLayout
See below.
|
| >...
| > I still think Get Involved is an awkward and ambiguous
| > categorization. Where do you draw the line between
| > "Getting Involved" and /being/ involved?
|
| Probably a good rule of thumb would be that items in the `Getting
| involved' section would be ones that you would only need to visit once,
| whereas those in the `Developer' section would be useful references to
| return to again and again.
|
| >...
| > For example, I can be involved in Mozilla layout by using
| > my bugzilla account, even if I'm not subscribed to
| > n.p.m.layout. If I later decide to subscribe to the layout
| > newsgroup, must I go to Get Involved, when I'm already
| > involved?
|
| No, because there is also a link to it from the NGLayout main page.
|
| > Or does "Get Involved" mean involved with the
| > newsgroup specifically, not the layout project?
|
| It means with the project generally.
|
| > Which specific pages under QA would go under Get Involved?
| > Those asking for help? Those aimed at beginners? Those aimed
| > at people beginning to become advanced?
|
| All of the above.
The Verification guidelines are aimed both at advanced and
beginning-to-become-advanced.
| > Why are the instructions for building Mozilla under "Get
| > Involved" and not the guidelines for writing C++?
|
| Because the former is a one-time thing (once you have built Mozilla
| once, any problems you have building it later are likely to be too
| esoteric to be in the build instructions), but the latter is a reference
| which you may need to refresh yourself on every few months (or when you
| break the tree).
Thus the new contributor is sent scampering across top-level
hierarchies to read up on contributing docs and general
contribution guidelines.
I'd like to suggest coherence as a quality of good categorization.
| > If you're going to get -CVS access-, you must demonstrate
| > -good coding practices-.
|
| I guess the non-coders who want to fix up the Web site are doomed, then?
No, they just have to get their docs checked in by someone who
will ensure the quality of the markup.
| > I don't see why pages should be split up like this. IMO, the
| > topic and the audience are more important in categorization.
| > Pull out "Get Involved" and your hierarchies are no longer as
| > self-contained, but cross-linked far more than necessary.
|
| Alternatively, lump them all together like we do now, and you have half
| as many volunteer contributors as you would otherwise -- because those
| who are half-interested in helping out the project are wading through a
| mountain of documents about nsCOMPtrs and jar packaging.
Or, alternatively, you can split documents into project
(organization) pages and product (tech) documentation pages.
Making an example of NGLayout: http://www.mozilla.org/newlayout/
If you look at the pages linked from the main NGLayout index,
you can split them up into those documenting the layout engine--
those detailing how it does what it does--and those explaining
about the NGLayout project--e.g. its purpose, the people involved,
how to get involved, what needs to be done, how to access the
discussion areas, what is currently being done on the layout
engine, frequently asked questions, etc.
Matthew Thomas
>...
> Events are highly date-oriented. Now, explain to me what,
> specifically, is wrong with
> http://mozilla.org/events/1999/mozilla.party/
Nothing.
>...
> So, to put it shortly, the generic location of the article would
> contain dated subdirectories to hold previous versions. ?
Correct.
>...
> As for my question, it was intended to ask "What is so
> objectionable about allowing any mozilla-sanctioned concerted
> effort to obtain its own directory to facilitate coordination
> of its members?"
Nothing. But calling such directories `projects' should be avoided, if
there is a term to describe them which is more meaningful to a visitor
to the site than `projects' is.
>...
> | > | The ones I posted were just examples. Most of the documents
> | > | currently linked to from <http://mozilla.org/docs/> (from the
> | > | `Core Mozilla architecture' section onwards) would end up in
> | > | the `Developer' > `Mozilla Developer' section.
> | >
> | > These all go at that level?
> |
> | No.
>
> Then why didn't you say so? I can't read your mind, Matthew.
I did say so. See the sentence beginning `Most of the documents ...',
paying particular attention to the word `most' at the start of that sentence.
If you want a full list of where *every* document linked from that page
would go, just ask. (Otherwise I'll assume that spending the time to
post such a list now would just bore everyone to tears.)
>...
> | Developer > Mozilla Developer > Qualities > Portability > C++
> | portability guide
>
> I'm thinking, either "Qualities" includes stuff like
> localizability and i18n,
Indeed it does. Other qualities include accessibility, usability,
scriptability, and performance. Anything which applies to the Mozilla
code as a whole, rather than just one particular module.
>...
> | > Which specific pages under QA would go under Get Involved?
> | > Those asking for help? Those aimed at beginners? Those aimed
> | > at people beginning to become advanced?
> |
> | All of the above.
>
> The Verification guidelines are aimed both at advanced and
> beginning-to-become-advanced.
The only `verification guidelines' I can find on mozilla.org are
<http://mozilla.org/quality/mailnews/mail-bug-verification.html> (which
is in a mailnews/ hierarchy despite having nothing in particular to do
with mail/news). Is this the document you are referring to? It seems
mainly aimed at beginner-to-intermediate QA volunteers, and is not a
document you would need to return to again and again.
>...
> | Because the former is a one-time thing (once you have built Mozilla
> | once, any problems you have building it later are likely to be too
> | esoteric to be in the build instructions), but the latter is a
> | reference which you may need to refresh yourself on every few
> | months (or when you break the tree).
>
> Thus the new contributor is sent scampering across top-level
> hierarchies to read up on contributing docs and general
> contribution guidelines.
Better that than that they can't find what they want at all.
> I'd like to suggest coherence as a quality of good categorization.
Although they are nominally organised into a hierarchical
management structure,this does not constrain the way people will
communicate, and share information, equipment and software
across groups ... The actual observed working structure of the
organisation is a multiply connected "web" whose
interconnections evolve with time.
-- <http://www.w3.org/History/1989/proposal.html>
In other words, Don't Panic. This isn't a gopher site we're designing
here, it's a Web site. Links between sections *are* allowed.
>...
> If you look at the pages linked from the main NGLayout index,
> you can split them up into those documenting the layout engine--
> those detailing how it does what it does--and those explaining
> about the NGLayout project--e.g. its purpose, the people involved,
> how to get involved, what needs to be done, how to access the
> discussion areas, what is currently being done on the layout
> engine, frequently asked questions, etc.
Nothing wrong with that. The NGLayout section is probably one of the
best-organized sections on the mozilla.org site at the moment.
fantasai
|
| fantasai wrote:
| >...
| > Events are highly date-oriented. Now, explain to me what,
| > specifically, is wrong with
| > http://mozilla.org/events/1999/mozilla.party/
|
| Nothing.
....
| >...
| > As for my question, it was intended to ask "What is so
| > objectionable about allowing any mozilla-sanctioned concerted
| > effort to obtain its own directory to facilitate coordination
| > of its members?"
|
| Nothing. But calling such directories `projects' should be avoided, if
| there is a term to describe them which is more meaningful to a visitor
| to the site than `projects' is.
I can't think of any replacements, and the only synonyms I found
were worse, not better.
"project" has a nice definition itself, though, and I think it
carries all the necessary connotations. Denotations for the noun
include "An undertaking requiring concerted effort" and "A plan
or proposal", exact definitions varying by dictionary.
I think it adequately describes the category. Have you other
suggestions?
| >...
| > | > | The ones I posted were just examples. Most of the documents
| > | > | currently linked to from <http://mozilla.org/docs/> (from the
| > | > | `Core Mozilla architecture' section onwards) would end up in
| > | > | the `Developer' > `Mozilla Developer' section.
| > | >
| > | > These all go at that level?
| > |
| > | No.
| >
| > Then why didn't you say so? I can't read your mind, Matthew.
|
| I did say so. See the sentence beginning `Most of the documents ...',
| paying particular attention to the word `most' at the start of that sentence.
Almost none. /Mostly/, they're in subsections of Mozilla Developer.
But, anyway..
| If you want a full list of where *every* document linked from that page
| would go, just ask. (Otherwise I'll assume that spending the time to
| post such a list now would just bore everyone to tears.)
I just wanted an idea of how Mozilla Developer is organized; you
gave me the impression that everything would be at the same level
until I read those examples.
We will have to get up a complete list at some point, and
quite frankly, I think you'd do a better job than I would.
Although I'll still /try/.
| >...
| > | > Which specific pages under QA would go under Get Involved?
| > | > Those asking for help? Those aimed at beginners? Those aimed
| > | > at people beginning to become advanced?
| > |
| > | All of the above.
| >
| > The Verification guidelines are aimed both at advanced and
| > beginning-to-become-advanced.
|
| The only `verification guidelines' I can find on mozilla.org are
| <http://mozilla.org/quality/mailnews/mail-bug-verification.html> (which
| is in a mailnews/ hierarchy despite having nothing in particular to do
| with mail/news). Is this the document you are referring to? It seems
| mainly aimed at beginner-to-intermediate QA volunteers, and is not a
| document you would need to return to again and again.
Sorry; should've posted a link.
http://www.mozilla.org/quality/bug-verification-guidelines.html
I hope you didn't spend too much time looking for it.
| >...
| > | Because the former is a one-time thing (once you have built Mozilla
| > | once, any problems you have building it later are likely to be too
| > | esoteric to be in the build instructions), but the latter is a
| > | reference which you may need to refresh yourself on every few
| > | months (or when you break the tree).
| >
| > Thus the new contributor is sent scampering across top-level
| > hierarchies to read up on contributing docs and general
| > contribution guidelines.
|
| Better that than that they can't find what they want at all.
|
| > I'd like to suggest coherence as a quality of good categorization.
|
| Although they are nominally organised into a hierarchical
| management structure,this does not constrain the way people will
| communicate, and share information, equipment and software
| across groups ... The actual observed working structure of the
| organisation is a multiply connected "web" whose
| interconnections evolve with time.
|
| -- <http://www.w3.org/History/1989/proposal.html>
|
| In other words, Don't Panic. This isn't a gopher site we're designing
| here, it's a Web site. Links between sections *are* allowed.
Sure. But related information should be under the same directory;
if you're minimizing cross-top-level links, you've probably got a
better organization.
| >...
| > If you look at the pages linked from the main NGLayout index,
| > you can split them up into those documenting the layout engine--
| > those detailing how it does what it does--and those explaining
| > about the NGLayout project--e.g. its purpose, the people involved,
| > how to get involved, what needs to be done, how to access the
| > discussion areas, what is currently being done on the layout
| > engine, frequently asked questions, etc.
|
| Nothing wrong with that. The NGLayout section is probably one of the
| best-organized sections on the mozilla.org site at the moment.
One of the reasons I picked it. My point is, though, that
instead of splitting into Getting Involved and Everything Else,
we should split the documents into technical info and project
organization info. That serves the purpose of separating
technical docs from the "Getting Involved" stuff without
dictating which documents you read in what order and whether
you're supposed to read a document once or not.