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 ...
>...
> | 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"
> <[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.
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
Mozilla UI decisions made within 48 hours, or the next one is free
