Jan 302013
 

If you’re a member of any of our illustrious localization and translation teams for MDN, you’ve likely noticed that for a while now, trying to save changes to pages that have been moved has been failing with a strange error about not being allowed to change the page slug.

This bug has just now been fixed, and you should be able to edit these pages again without any problems. Let us know if you’re still having problems!

 Posted by at 3:57 PM
Jan 232013
 

This post is not just a note about the changes in yesterday’s Kuma push to the MDN web site, but also serves to explain a change to our deployment process. The MDN development team is switching to a “continuous deployment” model, where new changes will be pushed to production as soon as they’re ready, instead of batching them.

Because of that, I won’t be blogging every single push anymore. Instead, I’ll mention specific new features as they’re ready for you to use, if they’re of major interest, or I’ll batch pushes together and mention the little but still interesting things all at once.

However, we do have a few interesting things in this new push, so I’ll mention those today:

  • The object returned by the wiki.getPage() KumaScript function now includes a translations array of objects that describe each translated version of the page. Each object in the array has three values:
    • locale — the locale of the translation
    • title — the translation’s page title
    • url — the URL of the translated page
  • The “revert this page” confirmation now shows the tag changes that will result from the reversion.
  • The “needs technical review” and “needs editorial review” banners are now much less scary looking; instead of being red, they’re a softer yellow.
  • The old devnews RSS feed now redirects to an appropriate feed providing appropriate content from the Hacks blog.
  • Some style cleanup has been done to the static portions of the site.
  • The feedback link at the bottom of pages no longer links to our long-discontinued forums; instead, they link to a new page on the wiki that explains how to offer feedback, including how to file bugs, get into IRC, and that you can contribute fixes yourself.

A few nice improvements, and the new deployment plan is an interesting development!

 Posted by at 9:58 AM
Jan 162013
 

We have a new Kuma platform update tonight! The new version features the following improvements:

  • The following JavaScript keywords are now recognized by the JavaScript syntax highlighter: class, enum, export, extends, interface, let, package, private, protected, static, and yield.
  • The favicon has been updated to get rid of spurious white pixels.
  • The link to the CSS Reference in the Learn section of the site has been updated.
  • Fixed a thumbnail hovering problem on the Dev Derby promotion.
  • Added to the Kuma API a new “toc” command, which returns an ordered HTML list representation of the table of contents for a page.
  • The “Save and Keep Editing” button no longer disappears when you reveal the page metadata editing fields.

Nothing major, but a few nice quality of life improvements.

The core MDN team has been meeting in Austin, Texas this week to plan development work for the next year. I’ll be blogging more about what we’ve come up with next week. We have Plans! Big Plans!

 Posted by at 11:28 PM
Jan 102013
 

That’s right! Even though just earlier today I blogged about last night’s Kuma software update on the MDN web site, we have another one. I adore our development team. I could squee all day about this stuff, but instead, let’s have a look at what’s changed:

  • When moving a page, you can now change its title at the same time; this field was previously editable, but its new value was being ignored.
  • The Styles drop-down menu in the editor now includes the “standardSidebar” and “syntaxbox” styles; these are used to create right-floated call-out sidebars and the syntax boxes used near the top of the CSS and (soon) other reference pages, such as HTML.
  • Submenus no longer sometimes stick off the edge of your window if you’re using a right-to-left locale.
  • A formatting problem that could cause ugly wrapping of article version histories has been fixed.
  • More removal of cruft has been done on the development VM.

Not a lot of changes, but several that will be a real boon to select people. In particular, I’m personally thrilled by the improvement to the page move tool, since I’ve been doing a lot of organizational clean-up work lately, and this will streamline that work noticeably. I’m also happy about the update to the Style menu, since these styles are getting used more and more — and being able to avoid dropping into the source editor to apply them is a huge help!

The staff MDN writers and the MDN development team are meeting next week in Austin, Texas to talk about development plans for the next six months or so. I’m looking forward to seeing them all. These are excellent people, and it’s a privilege to work with them all.

 Posted by at 5:14 PM
Jan 102013
 

We pushed an update to MDN’s Kuma platform last night. One nice, currently-useful change, one change that has more work left to be done before it’s ready to use, and a few behind-the-scenes tweaks you won’t notice yet.

  • Page moves are more clearly called out on the revision dashboard now, with a little box showing the source and destination pages on each relevant entry.
  • Fixed a bug with choosing a locale in Firefox in the translation UI.
  • The environment variables for a page now include information about which review tags are set on the page. This is a JavaScript Array.
  • Removed obsolete remnant bits of DekiWiki and switched to Ubuntu on our development VMs.
  • Reworked save page logic in preparation to bring back support for editing individual sections in addition to full-page editing.

There are some technical issues involved in getting these lists reported as actual arrays, but that’s something we do hope to do soon.

Other than the bug fix and the revision dashboard change, most of these changes are behind-the-scenes for now (the VM changes and the save logic changes).

In addition, you can’t yet see that tag information for other pages (it’s only available via the current page’s environment variables list). I’m filing a bug for that right now; I didn’t clearly communicate the use cases for this to the development team. Oops.

 Posted by at 10:14 AM
Jan 082013
 

We pushed a very small update to MDN’s Kuma software today. There’s only one change: if the text “bug X”, where “X” is a number, appears in an article revision comment, it’s turned into a Bugzilla link to bugzilla.mozilla.org, so you can quickly hop over to that bug for reference.

That’ll be a handy feature! I’ve been looking forward to it for a while now. Enjoy!

 Posted by at 3:53 PM
Jan 082013
 

As a leader of a community-driven documentation project such as that which we have on the Mozilla Developer Network (MDN) wiki, part of my job is to help build that sense of community while at the same time trying to make sure that things get done. This can be a tricky balancing act, especially since I go into things with my own ideas of how I think things should be done, and I’m certainly not always right.

For that reason, it’s sometimes a useful exercise to not get involved in debates and discussions about ideas. At times, I try to simply observe and see where the conversation goes. I let the conversation run its course, then jump in until the discussion reaches one of its typical end points:

  1. A consensus is reached. This happens pretty often, and is the best possible outcome of any conversation. If consensus is reached, I hop in and help to ensure that the idea gets implemented (which sometimes starts a whole new discussion about whose job it is to actually take on the decided-upon course of action).
  2. The conversation peters out with no decision. This is also pretty common. If the conversation fades away, sometimes it’s for the best — whatever was being discussed just isn’t that important, or nobody feels like championing it, so it may as well be left alone for the time being. Other times, I’ll step in and give things a nudge to see if I can get the discussion going again.
  3. The discussion devolves into argument. In our community, at least, this doesn’t happen all that often. When it does, I wade in and try to soothe people’s raw nerves and change the tone of the conversation. I can only think of maybe one or two times this has been necessary, though.

It can be incredibly educational to simply follow along while your community thinks out loud. By keeping your biases out of the way, a lot of great things can happen; often ideas come up that you would never have thought of. In addition, it lets your community members exchange ideas more freely, and can help build their sense of belonging. Certainly it helps them feel more confident that you’re not dictating how things should be done!

Silence isn’t always the best policy, but sometimes it’s a useful tool. Used properly, it can help your community become stronger.

 Posted by at 1:48 PM
Jan 042013
 

Why, hello there! It’s been several weeks since our last push of new code to MDN’s Kuma platform, so the list of changes in our new update is quite long. Let’s dive in and have a look!

Revision dashboard

  • A new filter by topic feature has been added; you can use this to see only documents that are in the HTML subtree, for example, if you’re trying to focus on reviewing changes to HTML documentation.
  • You can now share links to filtered versions of the revision dashboard; the code now uses pushstate to track the required information. For example, you can follow this link to see a list of changes to the HTML documentation in the English locale.
  • The vertical position of the locale information has been improved.
  • Fixed an error that appears to have been getting triggered by Google’s crawl hitting the dashboard.

Wiki improvements

  • The new “Clone this page” option has been added to the “This page” menu. You can use this to duplicate the current page in its entirety, including its tags. This will be incredibly useful for using pre-defined page layouts for references and other documents!
  • The width and height attributes are now accepted on <img> elements.
  • The <ins> and <del> elements now allow the datetime attribute.
  • The cite attribute is now allowed on the <q>, <blockquote>, <ins>, and <del> elements.
  • The Bengali (bn-BD) locale is now supported.
  • You can now see a list of all tags: https://developer.mozilla.org/en-US/docs/tags

Other improvements and fixes

  • Parts of the work to restructure our file attachment management have been integrated. More needs to be done, but we’re well on our way!
  • The sitemap was not valid, and was therefore being ignored by Google. Fixed.
  • The “create a page on 404″ functionality is no longer triggered if the viewer isn’t logged in.
  • SEO attributes have been added.
  • Attached images are losslessly compressed to improve page load times.
  • Page lists no longer include redirects or templates.
  • Promotional content has been updated.

So this is a huge update, and it’s got some really nice stuff in it. Stay tuned! There’s more to come!

 Posted by at 11:14 AM
Jan 032013
 

Today, I missed that a meeting that I run was about to start, because while all the other attendees knew about it, it wasn’t on my calendar for this week. It’s a biweekly meeting, and my calendars show it as happening next week.

This is not a new problem. It’s not even a rare one. Calendar sync is a problem that has continued to almost uniformly suck beyond words since people first started carrying gadgets around. Interestingly, it seems to have gotten worse, rather than better. Problems with my calendar being out of sync were rare back in the days I was carrying a PalmPilot around, syncing it using the good-old-trusty HotSync® protocol and a cradle. Nowadays, though, it seems to be the norm for my calendars to be entirely out of whack.

This is, of course, probably because I expect my calendars to be accurate in more places. Web apps, my iPhone, my iPad, two desktop computers, and a laptop. I use them all to update calendar information. Perhaps I need to give up on this expectation and hope, and just use one gadget for all my calendar information from now on.

I shouldn’t have to do that, though. This shouldn’t be an impossible problem to solve, especially since the information is being maintained on a server.

I’m tired of not being able to trust my calendar to be correct. Why hasn’t this been solved yet? I’ve been using electronically synchronized devices to keep track of my schedule for almost 20 years now (I started with a Newton MessagePad 110 in 1994). There’s no reason why this should continue to be so frustrating after all this time.

I’d appreciate tips on what you do to reduce these problems!

 Posted by at 11:54 AM
Dec 172012
 

Given our ongoing documentation-needed overload, we’ve decided to look into contracting out some writing work to help catch up our Firefox developer documentation. Basically, we’ve not been able to keep up with our Firefox X for developers documentation (see Firefox 17 for developers, for instance). While stuff gets listed, the list is often not complete, and even where items are put on the list, they’re usually not actually documented.

This is, frankly, embarrassing.

However, the staff writers, and even most of our community of writers, have been very busy with Firefox OS and other documentation, leaving Firefox itself rather strapped for attention. That’s got to change.

So the other day, I talked to Ali (my boss) and we agreed that we should see about contracting someone to go through all of these documents, from Firefox 13 onward, and get them fully up to date, and try to document the technologies and changes as needed.

There are some skills required:

  • You need to be proficient in JavaScript — at least well enough to read code without needing a lot of help, and to throw little snippets together as needed to demonstrate new features.
  • Likewise, you should be competent with HTML and CSS, at least well enough to sort things out without hand-holding.
  • If you have experience reading the IDL that describes DOM interfaces, that’s a big help, but we can help you figure it out (it’s not hard).
  • You should feel comfortable talking to developers by email and in IRC. You’ll have questions and being able to interface with these guys will be a huge help.

You won’t be in this alone, of course. Our existing community of writers hangs out in #devmo on irc.mozilla.org and we’ll be there to offer encouragement, advice, and some help.

If you’re interested, let me know. We haven’t opened up this contract yet, but I’d like to start getting a handle on who might be interested, so I can have a list of possible candidates ready to go once that happens.

This is important work that’s sadly fallen by the wayside due to limited resources and conflicting priorities. Help us make the Firefox developer documentation excellent again!

 Posted by at 1:01 PM