canmove, Confirmed users
1,953
edits
MDN/Doc Sprints/2010Q4: Difference between revisions
→Results
| Line 119: | Line 119: | ||
This doc sprint was intentionally kept small, since this was the first event of its type that we've tried. For future events, broader participation should be pursued, through earlier and wider publicity of the event. | This doc sprint was intentionally kept small, since this was the first event of its type that we've tried. For future events, broader participation should be pursued, through earlier and wider publicity of the event. | ||
Participants gave feedback that the sprint was a valuable experience for meeting Mozilla community members, and to have both technical and informal discussions. | |||
==== Schedule ==== | ==== Schedule ==== | ||
| Line 130: | Line 132: | ||
The work accomplished is linked from a [http://hacks.mozilla.org/2010/10/web-standards-doc-sprint-finis/ Hacks blog post]. | The work accomplished is linked from a [http://hacks.mozilla.org/2010/10/web-standards-doc-sprint-finis/ Hacks blog post]. | ||
The original plan for the sprint was to produce tutorials related to open web standards (c.f. [#Potential_Topics]). The actual topics produced were determined by participants' interests and knowledge, so only some of them relate to open standards or tutorials. Everything written is a valuable contribution to MDN, but the focus of the sprint was not maintained. | The original plan for the sprint was to produce tutorials related to open web standards (c.f. [[#Potential_Topics]]). The actual topics produced were determined by participants' interests and knowledge, so only some of them relate to open standards or tutorials. Everything written is a valuable contribution to MDN, but the focus of the sprint was not maintained. | ||
For future events, some possible ways to keep more of a topical focus would be: | For future events, some possible ways to keep more of a topical focus would be: | ||
| Line 137: | Line 139: | ||
* Provide examples and templates of the types of documents, so participants are not starting from scratch. | * Provide examples and templates of the types of documents, so participants are not starting from scratch. | ||
* Ask for commitments regarding who will write what on the list of brainstormed topics. | * Ask for commitments regarding who will write what on the list of brainstormed topics. | ||
==== Process ==== | |||
The process during the sprint was very informal: At the beginning of the sprint, each person talked about what they planned to do during the sprint; each subsequent day, we talked about what we had accomplished and still needed to do. Towards the end of the last day, we summarized and showed off what we had done. | |||
Some suggestions from participants on improving the process: | |||
* Have metrics such as number of documents or topics planned and accomplished, and review them each day. | |||
* Have 1-2 hour group activities like brainstorming or games that lead to doc writing while having fun. A big whiteboard might be good for this. | |||
* Try to document difficult stuff when there are experts there to help you. | |||
* There was not much teamwork because everyone was working on something different. IRC was a good tool to ask questions in public, so that everyone could have the answers if they were interested, but not be interrupted if they weren't. | |||
==== Tools ==== | |||
The tools used were the standard toolset for MDN: the Deki-based wiki and IRC. David Bruant gave the following specific feedback on the wiki: | |||
We've already discussed this point with Sheppy and Janet. The tool, even if currently fitting the goal, has quite terrible features. I have been told that you're planning on writing another one. I would be interested in following if not participating in the design phase of the tool. Who are the people in charge? Is there some doc or preliminary work around that project? Sources already? | |||
I had began drafting something for a wiki user interface and I really don't have the time to finish/polish it, so I will just give you my different sources of inspiration and ideas : | |||
As concluded in this excellent article (http://mozillalabs.com/conceptseries/2010/08/16/crowdsourcing-project-summary-of-best-practices/), one of the most important thing to get people involved in a community project is having a "low barrier to entry". And, what is said about wikipedia is particularly relevant : "anyone can edit almost anything. In fact, the biggest barrier to entry for Wikipedia is its editing tools which many have criticized as un-user-friendly". | |||
To address that, web browsers have all they need to write an "inline" text editor : the contenteditable attribute (https://developer.mozilla.org/en/DOM/element.contentEditable) ! When you want to edit a wiki page, there should be no need for going in another page with an edit interface and there should be no need for loading an iframe. Editing could be done this way: | |||
* Perform a double click on any section of the wiki article. | |||
* A discrete popup opens up to ask for edition intention confirmation. (This is necessary to avoid unexpected edits) | |||
The only small problem I have found with this is that on some OS and/or browsers, double click might already "mean something". For instance, on Ubuntu with Firefox, I use double-click on words to select them. This is the reason why the popup should be discrete and preferably out of the article content. | |||
* Edit (and there is no any better WYSIWYG since you're typing directly in the web page). | |||
* Do Ctrl+S to save (prevent default behavior) | |||
This is a light process, nothing needs to be loaded. The only unsolved issues being : how to add/remove a section? | |||
Obvisously, an HTML source mode would be nice. About the markup, I've been following an interesting discussion about headings: | |||
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027443.html | |||
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-April/026110.html | |||
The main idea being that with HTML5 new elements (article, section), a markup like | |||
<section> | |||
<h1>Header</h1> | |||
<section> | |||
<h1>Subheader</h1> | |||
<p></p> | |||
</section> | |||
</section> | |||
could be prefered to : | |||
<h1>Header</h1> | |||
<h2>Subheader</h2> | |||
<p></p> | |||
I tend to agree with the immediate benefit that you never have the problem of scrolling up thinking (where am I? should I write an h3 or h4 now?) | |||
About the table of content, there might be interesting things to do with a fixed proportional table of content : | |||
http://www.jankoatwarpspeed.com/post/2009/08/20/Table-of-contents-using-jQuery.aspx | |||
http://www.jankoatwarpspeed.com/examples/table-of-contents/ | |||
I think all what I've thought about is here. Just a last point. During my investigation on contenteditable, I've found an interesting blog post (http://accessgarage.wordpress.com/2009/05/08/how-to-hack-your-app-to-make-contenteditable-work/) which seems to point that the Firefox contenteditable implementation has some problems. Though, they seem to find their solutions. Anyway, if they are still present in Firefox 4, having MDC using contenteditable would be a good occasion to fix them ;-) | |||