Aug 292014
 

This week, my WebRTC research continued; I spent a lot of time watching videos of presentations, pausing every few seconds to take notes, and rewinding often to be sure I got things right. It was interesting but very, very time-consuming!

I got a lot accomplished this week, although not any actual code on samples like I’d planned to. However, the pages on which the smaller samples will go are starting to come together, between bits of actual content on MDN and my extensive notes and outline. So that’s good.

I’m looking forward to this three-day Labor Day holiday here in the States. I’ll be back at it on Tuesday!

What I did this week?

  • Copy-edited the Validator glossary entry.
  • Copy-edited and cleaned up the Learning area page Write a simple page in HTML.
  • Created an initial stub documentation project plan page for updating the HTML element interface reference docs.
  • Turned https://developer.mozilla.org/en-US/docs/Project:About into a redirect to the right place.
  • Read a great deal about WebRTC.
  • Watched many videos about WebRTC, pausing a lot to take copious notes.
  • Built an outline of all the topics I want to be sure to cover. I’m sure this will continue to grow for a while yet.
  • Gathered notes and built agendas for the MDN community meeting and the Web APIs documentation meeting.
  • Updated the WebRTC doc plan with new information based on my initial notes.
  • Offered more input on a bug recommending that we try to add code to prevent people from using the style attribute or any undefined classes.
  • Filed bug 1060395 asking for a way to find the pages describing the individual methods and properties of an interface in the Web API reference
  • Fixed bug 1058814 about hard-to-read buttons by correcting the styles used by a macro.
  • Dealt with expense reports.
  • Started very initial work on WebRTC doc tree construction, preparing to reshuffle and clean up the existing, somewhat old, pages, and to add lots of new stuff.
  • Started work on trying to figure out how to make the SubpageMenuByCategories macro not lose headers; it’s calling through to MakeColumnsForDL, which specifically only works for a straight-up <dl>. Fixing this to work correctly will be my first task on Tuesday.

Meetings attended this week

Monday

  • MDN bug triage meeting
  • #mdndev planning meeting

Tuesday

  • Developer Relations weekly meeting.
  • 1:1 with Teoli. This went on for an hour instead of the usual 30 minutes, due to the enormous amount of Big Stuff we discussed.

Wednesday

  • MDN community meeting

Friday

A pretty good week all in all!

 Posted by at 10:38 PM
Aug 222014
 

This week looks slower than usual when you look at this list, but the week involved a lot of research.

What I did this week

  • Reviewed and made (very) minor tweaks to Chris Mills’s doc plan for the Gaia web components and QA documentation.
  • Created an initial stub of a page for the canvas documentation plan.
  • Spent the weekend and a bit of Monday getting my broken server, including this blog, back up and running after a not-entirely-successful (at first) upgrade of the server from OS X 10.6.8 Server to 10.9.4. But most things are working now. I’ll get the rest fixed up over the next few days.
  • Pursued the MDN inbox project, trying to wrap it up.
    • Asked for feedback on the current state of things.
    • Added a subtle background color to the background of pages in the Inbox.
  • Started discussions on dev-mdc and staff mailing list about the documentation process; we’re going to get this thing straightened up and organized.
  • Filed bug 1056026 proposing that the Firefox_for_developers macro be updated to list both newer and older versions of Firefox.
  • Redirected some obsolete pages to their newer, replacement, content in the MDN meta-documentation.
  • Created a Hacker News account and upvoted a post about Hacks on canuckistani’s request.
  • Updated the MDN Administration Guide.
  • Installed various packages and add-ons on my Mac and server in preparation for testing WebRTC code.
  • Forked several WebRTC projects from GitHub to experiment with.
  • Found (after a surprisingly length search) a micro-USB cable so I could charge and update my Geeksphone Peak to Firefox OS 2.0′s latest nightly build.
  • Re-established contact with Piotr at CKSource about continuing work to get our editor updated and improved.
  • Removed a mess of junk from a page in pt-BR; looks like someone used an editor that added a bunch of extra <span>s.
  • Successfully tested a WebRTC connection between my Firefox OS phone and my iMac, using my Mac mini as server. Now I should be ready to start writing code of my own, now that I know it all works!
  • Filed bug 1057546: we should IMHO strip HTML tags that aren’t part of a string from within a macro call; this would prevent unfortunate errors.
  • Filed bug 1057547 proposing that the editor be updated to detect uses of the style attribute and of undefined classes, and present warnings to the user when they do so.
  • Fixed a page that was incorrectly translated in place, and emailed the contributor a reminder to be careful in the future.

Meetings attended this week

Monday

  • MDN dev team meeting on security and improved processes to prevent problems like the email address disclosure we just had happen.
  • MDN developer triage meeting.

Tuesday

  • Developer Engagement weekly meeting.
  • 1:1 with Jean-Yves Perrier.

Wednesday

  • 1:1 with Ali.

 Thursday

  • Writers’ staff meeting.

Friday

  • #mdndev weekly review meeting.
  • MDN bug swat meeting.
  • Web API documentation meeting.

So… it was a wildly varied day today. But I got a lot of interesting things done.

 Posted by at 6:16 PM
Aug 162014
 

I’m quite satisfied with how well the past week has gone. It’s been incredibly productive despite a few distractions and a great many meetings. Here’s my report on what I’ve been doing, and what I will be doing in the near future.

What I’m up to

I’ve been busy optimizing my own work processes, as well as setting up information so others know what needs to be done as well. I’ve also done a lot of copy-editing and organizational work in content, and have been touching up stuff ranging from the MDN inbox to the Learning Area to doc plans. It’s been a wonderfully productive week, and it feels good to be getting back into the swing of things.

What’s up next

Next week, I intend to dive into WebRTC, and to start putting together sample code so I can begin work on writing guides to working with WebRTC. It’s going to be really exciting!

As usual, of course, I have a number of other, smaller, tasks I want or need to accomplish, too.

What I did this week

  • Moved the main page on DocShell from the top level of MDN to its proper home, and filed a bug on getting it fully documented.
  • Dealt with infrastructure failures at my office: the air conditioning completely failed (working in a swelteringly hot office is not fun), and I discovered standing water in the restroom. The A/C is now fixed; the water problem has not been figured out yet, although the water has evaporated for now.
  • Helped test the new GitHub login support on the MDN staging server, and filed a few bugs regarding quirks I noticed.
  • Reviewed and had nothing but nice things to say about the new welcome email sent out by MDN to new members.
  • Got involved in the discussion about disabling styled pasting in the MDN editor. I’m opposed to this; I would much rather we solve the problem from the user’s end — contributors should learn to be sure they don’t include crufty styles when they paste into MDN. But ideally we can come up with a solution that doesn’t break existing workflows, punishing people who aren’t making this mistake.
  • Moved the page Write a new entry in the Glossary to the right place; it had accidentally been given an obsolete URL due to a couple of MDN bugs. Reviewed and copy-edited the content.
  • Filed a bug for a feature suggested by biraj: content from one page on MDN that’s presented inside another page should be reflected in the displayed contributor list. I don’t know how likely this is to be addressed (it certainly won’t happen soon). It’s a big project and there are many unanswered questions.
  • Copy-edited the new Glossary entry for the term “i18n“.
  • Added the word “Glossary” to the list of tags that MDN offers auto-completion for.
  • Followed-up on a bug asking me to write some copy for the Github login experience.
  • Did some tidying up of the MDN style guide, including moving Chris Mills’ excellent new section on our policies on gender-neutral terminology to be among the language and grammar topics rather than in the markup and wiki usage topics area.
  • Minor changes to the Learning Area page on CSS. This page needs a lot of work still but I saw low-hanging fruit.
  • Converted the Learning Area into a zone. Its landing page needs finishing, but this is a nice step.
  • Finished an extensive review and copy-edit of the Learning Area page Write an article to help learn about the web.
  • Removed a page that was actually just a set of Firefox problem reports, and emailed the author information about how to properly report issues.
  • Found an MDN “Linking Guide” lurking in a dead part of the site, and moved it into the MDN user guide, with major updates and copy-edits.
  • Updated the MDN user guide’s landing page to use the LandingPageListSubpages macro, so it looks a little better.
  • Adapted Luke’s screenshot/diagram about how to enable a page subscription on MDN into a new page in the MDN how-to guide.
  • Tweaks to the Inbox page in preparation for expanding its visibility.
  • Integrated the first round of feedback into the WebGL documentation plan.
  • Updated my Geeksphone Peak to Firefox OS 2.0 nightly for use in upcoming WebRTC sample code tests.
  • Filed a bug about iCloud.com saying “Android not supported” on Firefox OS 2.0′s browser.
  • Pinged developers about reviewing the WebGL documentation plan.
  • Created several new basic (that is, mostly empty) MDN development project plan pages:
  • Copy-edited the Learning Area’s How to contribute to the Learning Area article.
  • Filed a documentation request bug for documenting the NavigatorFeatures (hasFeature/getFeature) API. This API is low-priority privileged API, documentation-wise.
  • Added notes to a couple of pages in the MDN contributor guide about being careful when pasting, to avoid pasting unwanted styles and classes into MDN.
  • Created the DocPlanHelpUs macro, which inserts text inviting participation in a project and describing how to get started. Added it to the appropriate place in all extant doc plans.
  • Took some notes, sent some emails, and added links to the project planning page for the on-site messaging project.
  • Added a link to the MDN contributor guide to the footer of messages on the dev-mdc mailing list, and tweaked my email address on the moderator email list names.

Meetings attended this week

Monday

  • #mdndev bug triage
  • MDN development planning

Tuesday

  •  1:1 meeting with Jean-Yves

Wednesday

  • MDN Community meeting
  • 1:1 meeting with Ali

Friday

As you see, it was an intensely busy week! I’ve started moving into using OmniFocus to track what needs to be done and by when and I think it’s going to help, but we will see how it plays out over time. I have a history of not doing well at keeping up with my organizational systems, as you’ve possibly noted if you read my posts over history about my various attempts to get organized.

At any rate, it’s been a good week, and I can’t wait to get more done!

 

 Posted by at 12:07 AM
Aug 082014
 

It’s been another good week of Making Things Happen. I’m pleased with the productivity this week: not just mine, but the entire writing community’s.

What I’m up to

As usual, what I did this week doesn’t entirely line up with what I’d expected, but it was still productive, which is the important thing, right?

Work continued on finishing up the doc project planning page migration work, and better integration with other pages on MDN and elsewhere. I also put together the first draft of the WebGL doc plan.

I’m working on trying to reshuffle my many personal appointments that happen regularly to less often interfere with meetings, but unfortunately there’s only so much I can do.

What I did this week

  • Replaced the main documentation plan page on wikimo with a link to the new page on MDN, with an explanation of why it moved.
  • Finished work on moving the Learning area doc project plan to MDN.
  • Migrated the “Writing chrome code” doc plan to MDN, then emailed Will Bamberg to let him know his planning docs had moved.
  • Wrote first draft of the WebGL doc plan and emailed dev team to request feedback.
    • Got quick feedback with WebGL 2.0 ship date and added that information to the doc plan.
  • Added the dev-doc-needed keyword to man WebGL 2.0 related bugs.
  • Filed a bug about a problem with the link editor not suggesting zone pages that have moved out of the /docs/ hierarchy.
  • Added a link to the WebRTC doc project plan to the WebRTC documentation status page.
  • Posted to the dev-media list asking for suggestions on topics to cover in the WebRTC docs.
  • Updated the MDN page about KumaScript macros to link to the new article on troubleshooting them that Stephanie Hobson wrote.
  • Did a quick copy-edit pass on the troubleshooting article, and added some information about how to use search keywords to get to macro pages quickly (to read the built-in documentation most have).
  • Emailed out various meeting reminders.
  • Updated the team priority list spreadsheet with updated URLs and new information.
  • Wrote agenda for writers’ staff meeting and Web API docs meeting.
  • Wrote a nifty new MDN macro, ContentFromWikimo, which imports the content of a specified block (by ID) from a page on wikimo and inserts it into the MDN page.
  • Used the ContentFromWikimo macro to embed module owner information about WebRTC, WebGL, Web Workers, and XPCOM to their doc plans.
  • Filed a number of meta/tracking bugs for the various doc plans.
  • Created meta/tracking bugs for all current documentation plans. See my standup for today for links; I’m not going to copy and paste them all here. :)

Meetings attended this week

Monday

  • #mdndev bug/triage/planning meetings.

Tuesday

  • Messaging discussion for MDN feature planning.

Wednesday

  • 1:1 meeting with Ali.

Thursday

  • MDN writers’ staff meeting.

Friday

  • MDN development bug swat meeting.
  • Web APIs documentation meeting.

So, whew! Lots done! I’m particularly proud of the ContentFromWikimo macro work. It was also a lot of fun to do. I think it’ll be useful, too, at least sometimes.

I have a good feeling about next week. I think it’ll be even more productive!

 Posted by at 1:47 PM
Aug 012014
 

It’s been a while since my last Sheppy Report; there several good(ish) reasons for that. I won’t rehash all that today, though.

My intent is to resume these weekly reports; they were well-received back then, and I hope they’ll help improve my ability to keep people apprised of what I’m doing and about what’s new on MDN.

What I’m up to

My primary mission this week was to work on the MDN documentation project plans, getting them prepared for use by moving them to MDN, building any necessary content and macros  to support their presence, and so forth. This has gone pretty well, although it’s not quite finished yet. I plan to work on Saturday to complete this project.

Next week, I intend to tackle integration of the project plans with doc status pages and to write the WebGL documentation project plan. This will let us get started with the job of finding someone to write that important content.

There’s plenty more on my to-do list, and it’s possible priorities could shift, but finishing the current work is pretty much my Most Important Thing right now.

What I did this week

  • Created the landing page for the new home of MDN documentation project plans.
    • We decided to move these planning documents to MDN (even though planning docs don’t traditionally belong on MDN) in order to integrate them with our processes better. Having them on MDN means we can use KumaScript to automatically populate tables from bug lists, other areas of MDN, and so forth.
    • This will also let us integrate them with our existing doc status page system, which has been a great tool. I look forward to this augmentation work.
    • This page automatically rebuilds every four hours so its macro-generated list of subpages can be kept up to date.
  • Archived our old “Team Status Board” page. This was an experiment in tracking what individual MDN contributors were working on that didn’t work out.
  • Updated the non-standardGeneric macro
    • Corrected a typo that broke the macro, causing a KumaScript error on all pages using this macro or one that calls it.
    • Improved performance slightly by adding code to bounce out of loops when an end condition is detected early.
  • Migrated the developer phone documentation project plan to MDN, reformatting it to follow the new organizational structure for these plans.
  • Copy-edited the string.repeat() documentation.
  • Rewrote parts of the MakeColumnsForDL macro on MDN; this macro, which breaks up a <dl> into two columns for our landing pages, was in some cases splitting the list in the midst of a <dt> tag.
  • Migrated the Game Developer Zone documentation project plan to MDN.
  • Created a framework doc plan page for the RecRoom project.
  • Created a framework doc plan page for the WebGL docs project.
  • These framework doc plans will require filling -out, of course.
  • Corrected an accidental “translation-in-place” incident that replaced the English Apps zone landing page with Italian.
  • Created the <picture> element doc plan page on MDN.

There’s lots not covered here, such as email catch-up from my vacation a week or two ago, and all sorts of non-meeting discussions about MDN features, ideas for improving articles, etc. But you’re likely not interested. In fact, I bet you didn’t actually read this far anyway. :)

Meetings attended this week

Monday

  • #mdndev planning meeting
  • #mdndev pull request triage
  • MDN bug triage
  • Mozilla staff meeting

Tuesday

  • Developer Relations town hall meeting

Wednesday

Thursday

  • One-on-one meeting with Jean-Yves
  • Employee training meeting

Friday

  • One-on-one meeting with Ali

Unfortunately, a personal meeting ran very long on Friday, causing me to miss several scheduled meetings. Repeat apologies to everyone affected.

In general, a pretty productive week. A lot got done, and I’m making definite progress.

 Posted by at 6:12 PM
Jun 142014
 

I’m happy with how my talk at the Open Help conference went this morning. I gave a talk about how Mozilla builds, fosters, and provides useful information to our documentation community. I enjoyed giving it, and the questions were good ones.

I saw a lot of note-taking and nodding heads, and the discussions over the rest of the day definitely gave me the sense that people appreciated my thoughts on documentation community-building and processes. I hope there will be video available at some point; certainly it was recorded.

Our documentation status pages and other ways we present data about tasks that need to be performed really got a lot of attention, and Florian’s graph of our contributor growth really opened some eyes — especially when I pointed to the sharp uptick since we deployed our in-house grown, open source, Kuma documentation platform.

Also, I think our development team will be pleased that I heard a lot of “I wish we were using Kuma for our docs” today, and at least one person saying they’re going to look at setting up to try building it themselves.

Three or four people said that if it were separated from the Mozilla-specific bits, they’d be pushing to switch to Kuma. That made me smile; hopefully they will still feel that way if/when we manage to ever make the platform separate from the MDN-specific parts.

I’m with my people here; it’s really wonderful to just talk about documentation tactics without all the other stuff. It’s a great feeling, especially when it seems you’re able to give your peers ideas to take home and try for themselves.

My slides

View my slides below, or download them as a PDF.

 Posted by at 10:10 PM
Jun 112014
 

I’ll be attending the Open Help Conference & Sprints event this weekend, arriving in Cincinnati on Friday afternoon and returning home on Tuesday morning after the first day of documentation sprinting. Mozilla is a proud sponsor of this event, which features a number of key influencers in the open source documentation arena. The mission: to exchange notes and ideas about how to improve the quality and quantity of good open source documentation, and to hold documentation sprints to get some writing projects done.

I’ll be giving a talk on Saturday morning (at 10 AM—the first presentation of the event) entitled “Help people so they can help you.” I’ll be covering the things the MDN team does to build, foster, and support its growing community of contributors. I’m looking forward to this, even though I’m nowhere near prepared yet. I enjoy sharing ideas about how to create and maintain excellent documentation. It’s my career’s mission, and as a Mozillian, I’m pleased to be able to share. Hopefully, too, I’ll get new ideas this weekend as well!

As an aside, if you have any thoughts on things I should be sure to mention, don’t hesitate to leave a comment or drop me an email!

If you’re going to be at Open Help, or are simply in the Cincinnati area, I hope to run into you!

 Posted by at 9:51 AM
Mar 142014
 

Last weekend, we had an MDN work weekend at Mozilla’s Paris space. Over the course of the three days—Friday, Saturday, and Sunday—we built code, wrote and updated documentation, and brainstormed on new and better ways to present documentation on MDN. A grand total of 34 participants (wow!) including 16 volunteers and 18 paid Mozilla staff sat down together in a big room and hacked. 11 countries were represented: France, the United States, Canada, the United Kingdom, Sweden, Italy, Spain, Poland, Germany, India, Bangladesh, and Brazil. We completed 23 projects and touched (either adding, updating, or closing) over 400 bugs.

The most important thing, to me, was the reminder that our community is a real, tangible presence in the world, rather than an ephemera that flits about touching documentation from time to time. These people have real jobs, having real and important impacts on their local communities. Coming together is a chance to enhance our bond as Mozillians. That’s a great thing.

What’s also great, though, is the amazing amount of output we produced. Let’s look over some of the stuff that went on (if I leave out something you did, I apologize!).

Documentation work

  • Prototyped new UX for the MDN App Center.
  • All KumaScript errors on every page in the English, German, and French locales were resolved! This is a huge deal and I’m grateful to Jean-Yves, Florian, and Sphinx for this work.
  • Lots of work was done to sketch out and plan an improved onboarding experience for new contributors.
  • Lots of new Web documentation was added for various CSS properties, as well as for the HTML <template> element used by Web Components.
  • Over 100 pages of beginner content were properly tagged to be easier to find using MDN’s search filters.
  • Planning work for the new MDN “Learning” area was done; this area will provide content for new Web and Web app developers.
  • Work to plan out requirements for future MDN events was done.
  • Planning for the next steps of the compatibility data project was done; I missed this meeting although I meant to be there. We will be building a system for maintaining a database, in essence, of compatibility for all the things that make up the Web, then updating our compatibility tables to be constructed from that database. This database will also be queryable.
  • Progress was made on documenting the Web Audio API. Thanks to Scott Michaud for his work on this.
  • Chris Heilmann worked on adding live samples to pages; his work included some experiments in ways to make them more interactive, and he talked with our dev team about an improved user interface for implementing live samples.

Kuma platform work

Seven new people had the Kuma build system set up on their computers, with a virtual machine running a Kuma server up and running. Those seven people included me. In fact, I devised and submitted three patches to the Kuma platform over the weekend! They’re nothing particularly big, but it did allow closing three longstanding minor bugs. Not a big deal, but I’m proud of that anyway.

And I’m not the only one: a ton of amazing enhancements to the Kuma platform were developed over the weekend. Some are already deployed; others will not be for a while, since there are quirks to iron out.

  • Live samples are now better delineated by having a border drawn around them (this one is mine, and already deployed).
  • A new JavaScript snippet has been developed that can be embedded into any Web site to automatically link common terms to the appropriate pages on MDN. This is almost but not quite ready to deploy as I write this.
  • A bunch of old code we inherited from the Kitsune project has been removed (Ricky did this).
  • The email sent to admins after a page move operation is completed has been enhanced to include a link to the new location and to have the subject be more specific as to which move finished (another of mine; not yet deployed but probably will go out in the next push).
  • The “revert this page” confirmation prompt has some wording corrections (mine, and pushed to production).
  • A new “top contributors” widget has been developed; this will show the top three contributors to a page, with their avatar image, at the top of the page somewhere. This isn’t finished but the prototype is promising. This work was done primarily by Luke Crouch, I believe.
  • UX design work was done for future enhancements to how we display search results.
  • UX design work was done for how we display the language list, to improve discoverability both of the fact that there are multiple languages, but also that pages can be localized by contributors.
  • The revision diff page you get when comparing two pages in an article’s history now includes a “Revert to this revision” button. Also mine; I don’t know if it’s on production yet but I think so.
  • Lots of design and planning work for improved search UX, filtering, and more. This stuff will amaze you when it lands!

I won’t become a huge contributor to Kuma, probably. I don’t have time. I’m too busy writing and (more often, really) organizing other writers. That’s okay, of course. I’m having my own impact on our worldwide community of Mozillians and users and developers on the World Wide Web.

 Posted by at 6:47 PM
Feb 212014
 

The most important rule of contributing to the developer documentation on MDN is this:

Don’t be afraid to contribute, even if you can’t write well and can’t make it beautiful. It’s easier for the writing team to clean up information written by true experts than it is to become experts ourselves.

Seriously. There aren’t that many of us on the writing team, even including our awesome non-staff contributors. We sadly don’t have enough time to become experts at all the things that need to be documented on MDN.

Even if all you do is copy your notes onto a page on MDN and click “Save,” that’s a huge help for us. Even pasting raw text into the wiki is better than not helping at all. Honest!

We’ll review your contribution and fix everything, including:

  • Grammar; you don’t have to have perfect (or even good) writing skills—that’s what the writing team is here for!
  • Style; we’ll make sure the content matches the MDN style guide.
  • Organization; we’ll move your content, if appropriate, so that it’s in the right place on the site.
  • Cross-linking; we’ll add links to other related content.
  • Structure and frills; we’ll ensure that the layout and structure of your article is consistent, and that it uses any advanced wiki features that can help get the point across (such as live samples and macros).

It’s not your job to make awesome documentation. That’s our job. So don’t let fear of prevent you from sharing what you know.

 Posted by at 10:15 AM
Feb 202014
 

Among the first steps we need to take for our “Year of Content” this year is to review our existing documentation to find where improvements need to be made. This involves going through articles on MDN and determining how “healthy” they are. If a doc is reasonably healthy, we can leave it alone. If it’s unhealthy, we need to give it some loving care to fix it up.

Today, I’d like to share with you what constitutes a healthy document. Only once we know that can we dive into more depth as to how to fix those articles that need help.

Check the content’s age

Look to see how recently the content was updated. If it’s been a long time, odds are good that it’s out of date. The degree to which it’s out of date depends, of course, on what the topic is and whether or not there’s been development work in that area recently. Content about CSS is a lot more likely to go quickly stale than material about XPCOM, for example.

Review articles in areas of the site, looking to see how long it’s been since it was last changed, and use your judgement as to whether it’s been too long.

Do the pages have quicklinks?

Quicklinks appear in the left sidebar on MDN pages to offer links to related content. We are in the process of phasing out the old “See also” block at the end of articles in favor of quicklinks. If you see pages that have a section entitled “See also”, they need to be updated. Similarly, many areas of the site have standard quicklink macros that should be used, such as HTMLRef or CSSRef. These automatically construct advanced sidebars which link to related material as well as all other HTML elements or CSS properties.

Pages with no “See also” section or quicklinks may need some added; it’s often useful to provide additional links like these. However, they’re not mandatory.

Are there any KumaScript errors?

This is a big one. Any page that presents a big red KumaScript error box at the top of the page is an immediate “drop everything and fix this” alert. If you don’t know how to fix these (or aren’t able to), visit #mdn on IRC or drop me an email.

Are there appropriate examples and images?

Developers learn best and fastest by example. Any page about a developer technology that doesn’t have good code samples—with explanations of how they work—is probably flawed. Take note of pages that are missing examples, or have overly simplistic (or excessively complicated) examples. Also, most examples should be presented using our live sample system, which allows us to demonstrate inline the results of executing a piece of code.

Similarly, if an article would benefit from screenshots or other images (or videos) to help explain a topic, and doesn’t have any, that’s a detriment to its health, too.

Are there compatibility tables?

Every page about an API or technology should have a compatibility table that indicates what browsers and platforms support it. This includes both tutorials and reference pages. If these are missing, users will have a hard time evaluating whether or not a technology is ready for prime time.

On a related note, pages that are written from the perspective of using them from a particular browser are also flawed. Much of our content is still very Firefox-specific, which isn’t appropriate. MDN’s content should be browser-agnostic, supporting our developers regardless of what platforms and browsers their users are on. We need to find and get rid of boxes and banners that say a technology was added in Firefox version X and move that information into proper compatibility tables.

Do reference pages link to specifications?

Every reference page should include a link to the specification or specifications in which that API was defined. We have a standard table format for presenting this information, as well as a set of macros that help construct them.

Are pages formatted properly?

All pages on MDN should follow our style guide. Admittedly, our style guide is a bit in flux at the moment, and not all of it is written down yet. However, that will change soon (certainly by the time we dive in deeply into this work), so it deserves mentioning here. Content that deviates from the style guide needs updating.

Important: Many older parts of MDN use custom styles, or embed CSS examples within the body of articles. This is no longer allowed, and in fact the ability to edit content like this will eventually go away, so it’s important that these pages be updated to use only our standard styles, and to move all examples into live samples.

Are pages tagged correctly?

Increasingly, we’re using macros for everything from generating landing pages and menus to search filtering to building to-do lists. This depends heavily on pages being tagged correctly. Articles that don’t follow our tagging standards need to be updated so that all of these features of the MDN Web site work correctly.

Do pages need review?

Healthy articles have been fully reviewed; they have no review requests flagged for them. New articles are automatically flagged for both editorial and technical review, and these reviews may be requested at any time after the article has been created, as well. These reviews help to ensure the documentation’s quality and clarity.

Make sure there aren’t any dead ends

Every article should have links to other pages. Articles that don’t cross-link properly to other content become dead ends in which users get lost. Be sure that terms are properly linked to relevant content elsewhere on MDN; if there aren’t appropriate links to other pages, the articles aren’t healthy.

Do pages use macros properly?

We use macros on MDN for a lot of things. It’s important that they’re used consistently and correctly. By using macros to generate content, we can create more and more consistent content more quickly. For example, when linking to API interface objects, use the DOMXRef macro instead of directly linking to the object’s documentation. This macro can adapt quickly to site changes and design changes. In addition, it automatically creates appropriate tooltips and automatically handles other tasks to improve the site’s usability.

 Posted by at 12:05 PM