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/.
|
| 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"
<[EMAIL PROTECTED]>:
[ 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.
