(Don't let me start out all negative and whiny:) I'm concerned that we could spend too much time trying to find the "ideal" information architecture, but let's not.
I'd suggest making decision based on how many contributors we have. We probably shouldn't consider too much about web developer documentation. Yes, it is important, but after IO and Rudman left since our separation from Netscape we are having no help on web dev doc, and I don't suppose the situation will change soon.
As we bring up DevMo, we should not worry about links working; until we "launch" the site to the masses, we must be able to fix mistakes as we go. Moving fast trumps moving with utmost care and caution. Bite-sized editing and fixing/polishing trumps "get all 100 pages perfect before releasing them."
agree, having short, intensive projects is a good way to get started
Marshalling volunteers with good reputations in parallel is key.
All that open source motherhood and apple pie aside, it's vitally important that we have an editor-in-chief who will set prose and web content style rules, rally writers and other editors to urgent tasks, police the prototype site for bugs, and lead in driving the buglist to zarro. Volunteers?
nominating fantasai and Simon Paquet :-)
Proposal: we have our own look, but with similar bars along the top:
- highest has some few right-justified items to get to www.mozilla.org and a sitemap;
I'd suggest we avoid sitemap. Having the need for a site map usually indicate you are doing something wrong, and needing one when you are still small is a very bad sign.
- next has a gradient and a left-justified "DevMo" logo, or something as simple yet attractive and even more distinctive;
- lowest/most-used toolbar has: DevMo | Topics | Library | Downloads | Samples | Subscriptions | Worldwide
We could leave out Subscriptions and Worldwide for now, or stub them out and call for volunteers.
don't we already have www.mozilla.org/community/ ?
We will hope to get to the point of having so many articles, and such a stream of fresh ones, that we can or must do likewise, but for now, it seems better to me for us to have docs organized in a fairly flat category tree that organizes and includes at least:
DOM (doron has a plan for these docs, I understand)
DOM Inspector
CSS
Gecko Embedding APIs
HTML
Java
JavaScript
JavaScript Debugging APIs
MathML
Python
SVG
Venkman User Docs (there's a great site at http://www.svendtofte.com/code/learning_venkman/ -- maybe we could host it?)
XBL
XML
XPath
XPCOM
XPConnect
XPInstall
XSLT
XUL
let's leave out CSS, HTML, MathML, XML, Python, and XSLT for now. Don't get too ambitious.
We definitely want tutorials organized by hot "How do I do X?" questions and scenarios. Guides and other longer docs that cover larger APIs and sets of APIs are needed.
Architecture and user-interface laundry-list:
- Need a graphical design strawman or mock-up that we can all nitpick into shape and agree on, soon.
- How do we want to generate or otherwise maintain docs with consistent style elements, toolbar headers, etc.?
- Do we want a wiki front end? Shaver has argued that we do, based on his recent experience.
yes we do. We should lock front page and top-level index pages though.
- What should we use for the repository? CVS is easy for us to set up, and a known quantity with admin support (http://despot.mozilla.org/).
CVS is a big hurdle for many new contributors, both in m.o and mozdev.org. What alternatives do we have?
Let's go! DevMo!
Do we have a schedule for this? I'm trying to get a International Month started on April or May, so I'd like to avoid bad time collision.
_______________________________________________
mozilla-documentation mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-documentation
