sheppy

Writer. Programmer. Geek.

 

The last week or so, I’ve been working on sample code for the Source Editor API. While this API is not incredibly mission critical, in that it doesn’t directly affect web developers, and isn’t in the critical path for documentation, I’ve enjoyed this work, and the time spent writing about it — and, more importantly, building sample code for it — has been educational.

One thing that occurred to me is this: we need more real-world examples of how to do things. Too many of our examples are simple, fictionalized snippets of code that don’t show you how to do things in the greater scheme of getting things done. However, you still need to document things in context, too.

What I propose is this: what if we set up a section on MDN for larger examples of all kinds, where each page is a complete example, with downloadable code and one section for each method or interesting section of the example, talking about how it works? Then we can link to those sections from the relevant documentation site-wide.

For instance, this example I’m working on shows how to do all of the following things:

  • Create a new XUL window
  • Import several JavaScript code modules
  • Add a Source Editor to the window
  • Interact with the Source Editor
  • Create and manage a menu bar
  • Check and uncheck menu items given the state of the source editor
  • Update the display in a status area of the window given information obtained from the source editor
  • Asynchronously fetch the contents of a page using NetUtil
  • Overlay XUL from within the browser into the source editor to re-use UI and code
  • Save the text from the source editor to a local file on disk
  • Display alerts using the prompt service
  • Call various methods from XUL definitions of UI
  • Add and remove event listeners
  • Some parsing of file and pathnames
  • Set the title of a window based on the name of the item being edited
  • Add an item to the browser’s content area context menu under specific conditions

That’s a lot of stuff, and being able to demonstrate how all of those things are done in a real-world extension has a lot of value. By having a page that covers all of the things this add-on does, then being able to link to the appropriate parts of that page from all over the site, we can really bring our documentation to a whole new level.

Any thoughts?

 

A few months ago, we decided to set up a driver system for driving documentations on a release-by-release basis, with a writer taking lead on each release as it made its way through the release train process.

This… didn’t really work out. It was a noble experiment that failed.

We’re now in the process of switching to a per-topic documentation driver system. This will let us get documentation for the most important material done more quickly (at least in theory) regardless of when it ships. The driver for each topic area will prioritize the work for that subject matter and help ensure that things get written when appropriate. They’ll help coordinate the writers that are interested in contributing to that topic and make sure that the docs in that area of the wiki are kept tidy and are properly crosslinked.

Obviously, the first step in switching to this driver model is to get people selected for each of the topic areas. We have a new page on the wiki for this. If you know of a topic area that’s not listed there (or is a large enough subset of one of the ones already there that it should be handled separately), please feel free to add it. Similarly, if you’re interested in being a documentation driver for one of those topics, let me know, or put your name down.

I’ve not yet selected the topics I will drive, other than likely the XUL and XPCOM stuff. I’m waiting to see what others would like to do first (indeed, if anyone else wants those two, feel free to take them from me). My primary goal as always will be to coordinate the overall documentation effort, maintain the site in general, and contribute as needed, in addition to driving whichever topics I wind up with.

If you have questions or would like to volunteer to drive a topic, feel free to comment here, send me email, or pop into #devmo on irc.mozilla.org.

 

As pretty much everyone knows, our documentation for events (both standard DOM events and Gecko-specific ones) is pretty lame. We’re missing a lot of stuff, and what we have is often bad and poorly organized.

We have a new event reference page:

https://developer.mozilla.org/en/Mozilla_event_reference

Which embeds the Gecko and DOM event references:

https://developer.mozilla.org/en/Gecko-Specific_DOM_Events
https://developer.mozilla.org/en/DOM/DOM_event_reference

However, neither of these pages are complete, and most of the events have little or no documentation.

This is obviously important documentation, but has never managed to drift to the top of the to-do lists of any of the writers.

For that reason, we’re now looking for a contractor that we’d pay to write and clean up this material. The goal is to have complete documentation of all standard events for the DOM and other open web APIs, as well as for Gecko-specific and internal events.

This will probably take a while, although at the moment I don’t know how long. There’s quite a lot to be done; it would involve, among other things, going through the spec to find events and document them, plus going through the code to see which ones we support and which ones we don’t (as well as, hopefully, where our implementation deviates from spec).

Additionally, the writer would need to be able to look through the code to find, understand, and document the Gecko-internal events, most of which are currently entirely undocumented.

If you’re interested, or know someone that might be interested, please let me know!

 

Here are today’s Wiki Wednesday articles! If you know about these topics, please try to find a few minutes to look over these articles that are marked as needing technical intervention and see if you can fix them up. You can do so either by logging into the wiki and editing the articles directly, or by emailing your notes, sample code, or feedback to mdnwiki@mozilla.org.

Contributors to Wiki Wednesday will get recognition in the next Wiki Wednesday announcement. Thanks in advance for your help!

JavaScript

SpiderMonkey

Developing Mozilla

Extensions

XUL

XPCOM

Interfaces

Thanks to Neil Rashbrook for contributing!

Plugins

CSS

Thanks to leeli and Panagiotis Tsalaportas for their contributions!

SVG

HTML

Thanks to Panagiotis Tsalaportas and Neil Rashbrook for their contributions since last time.

DOM

Thanks to Matt N. for his contribution to the DOM documentation.

 

Last week, the writing team took a look at how documentation work is progressing, and the enormous amount of it coming up in the months ahead, and we realized that our old method of prioritizing writing work doesn’t do the job anymore. In the past, we prioritized work first by which Firefox release it was due to be shipped in, then by topic area.

That simply doesn’t work anymore. Between the rapid release schedule and the fact that we often start promoting new technologies while they’re in Nightly or Aurora builds, we can’t focus on one release at a time. So we’ve decided that going forward, we’re going to prioritize documentation based on the importance or “interestingness” of the topic, regardless of which Firefox release it’s expected to ship in.

This means that going forward, we’re much more likely to ship Firefox releases that don’t yet have complete developer documentation, but it also means that we’re more likely to have all the most important and broadly interesting topics written up earlier in the development process. Of course, we’ve already started to have trouble getting documentation for a release “finished” in time anyway, so this isn’t a big surprise. But by accepting it and embracing the hugeness of the task ahead, we can make better decisions about what to write and when.

Hopefully the Mozilla community will be able to step in and fill the gaps that get left behind as we move forward. There will be lots of great opportunities to contribute to MDN. I look forward to seeing what you can do to help!

 

I apologize for liking it.

 

Here are today’s Wiki Wednesday articles! If you know about these topics, please try to find a few minutes to look over these articles that are marked as needing technical intervention and see if you can fix them up. You can do so either by logging into the wiki and editing the articles directly, or by emailing your notes, sample code, or feedback to mdnwiki@mozilla.org.

Contributors to Wiki Wednesday will get recognition in the next Wiki Wednesday announcement. Thanks in advance for your help!

JavaScript

SpiderMonkey

Developing Mozilla

Extensions

XUL

XPCOM

Interfaces

Plugins

CSS

SVG

HTML

DOM

 

As you’re probably aware, we’ve had a series of problems with the wiki lately. I’d like to share a status report as to what those are and where we stand.

Failing wiki extensions

There’s an issue that’s causing extensions that add features to the wiki to fail to start up. This is a problem caused by a bug in the wiki software that’s not properly handling the scenario in which multiple hosts are restarted at the same time. Due to a lack of proper mutual exclusion during wiki startup, the launch of extensions can fail fairly spectacularly, resulting in the loss of the configuration of the extensions, so that future attempts to start them are guaranteed to fail.

This didn’t happen on every restart (oh, the joy of mutual exclusion bugs), but happened pretty often. Since the wiki periodically restarts itself automatically to clean up cruftiness, the result was that this bug would randomly crop up fairly frequently.

Late last week, MindTouch’s support team gave us a script that detects when this has happened and repairs the lost configuration and restarts the extensions. This was tested over the weekend on three of our most commonly-used extensions, and seems to have worked very well. They’ll be adding the rest of our extensions into the mix tomorrow.

That’s a short-term, hacky, workaround for the problem.

MindTouch’s engineers are working on a patch that will correct the underlying bug. They’ve implemented the fix on their trunk codebase, and are testing it there now. It’s a substantial revision to how extensions are loaded, and they want to get it thoroughly tested. Once they’re sure the patch works, they’ll backport it to the release we’re running and test it there. Then, finally, we’ll get it installed, and we should be in good shape.

This situation is being tracked in bug 715341 if you’d like to follow along.

The Great DOM Reference Kerfluffle

While experimenting with some ideas for the DOM Reference, Jean-Yves inadvertently initiated a move of the entire DOM Reference to a different part of the wiki. That was bad enough, but could have been easily fixed. Unfortunately, the site crashed partway through the move, resulting in things being left in a state where it wasn’t a simple “move the subtree back where it belongs” operation. Instead, he had to manually move every page back where it belonged one at a time. This took several days, but is now finished. If you notice any issues with the DOM Reference, please let us know!

 

I love the English language. It’s crazy, complicated, and bloated, and those are all things that contribute to its amazing expressiveness. If a word doesn’t exist, someone will make it up, or rip it off from another language. It’s a quirky, twisted amalgamation of words and syntax from a broad swath of other languages. From Latin to German to Japanese and Cherokee, English has swiped words from dozens of other languages.

All of that makes it a tricky language to master. It’s not hard to get your point across in English, but to do it with an appropriate level of grammatical correctness and meet the style and formality of whatever context you’re working in can be difficult.

English can be ugly and twisted or fluid and beautiful, depending on the skill level of the writer and the point they’re trying to get across. It can be used to create magnificent works such as Handel’s “Messiah” and Shakespeare’s Hamlet, popular novels such as Stephen King’s Carrie, or technical materials such as the MDN wiki I administrate. If you look at all of these works, they demonstrate the wide variety of styles of material you can create in English, and they each practically feel like they’re written in a different language, because of how differently the construction of sentences and the flow of the material works.

That English can be difficult to master has the side benefit of making being a technical writer a very attractive and lucrative line of work. If you know how to write code and can also write in English easily and with skill, you have a unique suite of capabilities that make you highly employable. And if you love words, and have fun writing code, technical writing is a blast — being able to do both is the most fun I’ve ever had in my working life, and I’m incredibly thankful that I get to do it.

 

As I came to the realization, which I mentioned in my previous post, that I was fed up with game development for a living, I had been playing with BeOS for a while, so I decided I’d like to work for Be. I went to their job listing page and looked through the list of openings. The only one that didn’t require a college degree (which I didn’t have) was one for a technical writer.

So I applied. A few weeks later, they let me know I didn’t get the job.

I got myself fired by the game company (due to my unwillingness to cooperate with a particularly bad business decision), and wound up at another one. About three weeks after starting that job, Be called back and asked me to come up for an interview. So I went up to the Bay Area and met with Doug Fulton and one or two other people up there (I don’t remember who all else, since there were several, and it’s been a long time). We chatted for a while, I felt I made a terrible impression, and I went home.

A few weeks after that, Be let me know that while they didn’t think I was qualified for the technical writer job, they’d bring me on as a junior writer if I was willing to do that. I jumped all over that, and my career as a technical writer began.

I started at Be in September of 1997, working out of the office in Menlo Park. I was the junior of three technical writers. One of them (whose name I agonizingly fail to remember) left not too long after I started, but Doug I remember. Doug had worked as a writer at NeXT, and would tell stories about how great his desk was being near the rear exit of the building so he could escape when Steve Jobs came in.

I had zero experience as a technical writer, so working with Doug, a long-time writer, was a great experience for me. He didn’t teach, per se, but offered a lot of guidance, and I watched how he did things closely as I got into the swing of things. If that experience hadn’t been such a good one, it’s entirely possible I might have fled technical writing back to programming, which probably would have been a mistake.

I’m a decent programmer — even a very good one, within certain bounds. But I like to think I’m a very good technical writer. Doug (and by extension, Be) gave me the opportunity to figure that out and spread my wings. By the end of my first year at Be, I was a senior technical writer and had had my pay bumped three times to match that title.

I’d found my calling at last. So thanks for the job, Doug.

© 2012 Bit Stampede Suffusion theme by Sayontan Sinha