Sep 212012

Yesterday afternoon, we pushed a new update to MDN’s Kuma software. This update got us tons of changes; it had been two weeks since our last push (which is, to date, the longest we’ve gone without an update since we launched the new platform). Here’s a rundown of what’s changed:

  • By default, all users now have permission to attach files to articles; instead of granting upload permission, we now remove it from individual users as needed.
  • Localizers can now edit the titles of translated articles (woohoo!).
  • The description of an attached image (as entered when adding the attachment) is now the default alt text for images.
  • The styles in the editor now more closely match the styles you see when reading content.
  • Special pages, like edit pages, history, compare, and translation pages, are now marked as not being things that Google should crawl and index. This will help some broken SEO and other issues.
  • When users try to log into MDN for the first time since our switch to Persona, and they don’t have an email address in their MDN configuration, they now get an appropriate message explaining what they need to do; previously, we had an unfortunate error condition here.
  • Inconsistencies in the markup of tables of contents have been corrected.
  • When pages skip heading levels, the table of contents now draws more attractively than before.
  • The template editor no longer displays bogus error icons by the line numbers in certain cases.
  • Using the <code> element in headings no longer breaks those headings’ entries in the table of contents.
  • Display of some text in the static Learn HTML page has been fixed.
 Posted by at 10:11 AM  Tagged with:
Sep 082012

I was driving along yesterday and happened to drive past a gas station (which is a pretty common occurrence, as there are three along the main road leading toward my neighborhood). As I did, the thought popped into my head: “What kind of civilization would arise if there were no fossil fuels?”

This led to a broader question: “Why wouldn’t there be any fossil fuels?”

And finally to: “What if the first major wave of evolution resulted in a civilization?”

Let’s consider the history of evolution on Earth for a moment. There have been at least two or three “waves” of evolutionary development, separated by massive extinction events that wiped out much of the evolutionary progress that had been made.

For example, dinosaurs evolved over many millions of years into the often large, powerful creatures we know and love from the fossil record and movies such as Jurassic Park. Then they were wiped out by an asteroid impact and the resulting climate change. The next wave of evolutionary progress resulted in our civilization.

Our civilization has benefited from the billions of years before it, in which massive amounts of life has existed, died, and over time been turned into fossil fuels.

Now consider: what if the very first wave of evolution resulted in a civilization. There would be little or no fossil fuel available for them to use. How would they develop differently as a result? Would they rely on wood-fired steam power until they discovered nuclear or solar power? Would they be stuck in the Stone Age forever, unable to make the massive leap from wood power? Or would they discover some other kind of power we haven’t even thought of?

And how would their understanding of biology and of evolutionary theory differ from ours? With a much smaller fossil record to draw from, how well would they understand where they come from? We know with a fair degree of certainty a lot about the evolution of species on Earth, despite the dogmatic opining from certain corners.

This line of thought intrigues me, and I invite opinions!

 Posted by at 9:00 AM
Sep 072012

Families share photos. We have multiple computers. Why are there still no home photo servers that let multiple users share a library and maintain the photos, metadata, and so forth all at the same time? Not having a way to this nowadays is absurd.

iPhoto is by and large a nice piece of software (although it has a number of quirks; don’t get me wrong). But it’s not set up to let me sit at my laptop and manage the family’s photo library, which is kept in iPhoto on my daughter’s iMac. That iMac is the source for all our photo syncing to iPhone and iPad devices, as well as for our AppleTV. I don’t like having to sit at my daughter’s computer when I want to import new photos, edit them, and add metadata to them. Her desk is small and uncomfortable for a big guy like me. And often the times I want to be working on the photos is in conflict with her wanting or needing to be at her desk.

On top of that, adding comments and ratings to photos is exactly the sort of thing that’s nice to be able to do while sitting on my laptop (or, dare I say it, my iPad) in front of the TV.

Someone is likely to think, “Why not store the library on a NAS?” That doesn’t work because you can’t use it from multiple computers at the same time, which I need to be able to do. There are too many people (and devices) in my house that want or need to access the library at the same time. And I don’t think it makes sense that I should have to compromise on something that should be a basic, obvious requirement nowadays.

It’s absolutely ludicrous that there’s no way to do this. I’ve spent a lot of time looking for a solution for this, and there’s pretty clearly not one.

 Posted by at 9:17 AM
Sep 062012

We have a new update to the MDN Kuma wiki that’s just gone live this afternoon. There are a number of fixes for SEO as well a couple of editing experience changes that should be appreciated.

  • You can now add and remove tags while using the translation user interface.
  • The template editor displays properly again. Our update late last week inadvertently broke it.
  • An extra <h1> block that was harming SEO has been corrected.
  • Canonical links are now reported using <link rel=”canonical”> to further improve SEO.
  • Window titles are now suffixed with “MDN” instead of with “Mozilla Developer Network”. This both helps SEO (since people search on “MDN,” not “Mozilla Developer Network”). It also reduces the visibility of the Mozilla brand, which is important since much of our content is browser-agnostic.
  • Fixed some typos in September Dev Derby text.

A relatively modest update today. However, we continue to fight the good fight to improve our Google juice, while at the same time gradually bringing new features to our community.

 Posted by at 4:37 PM  Tagged with:
Sep 052012

If you hadn’t noticed, the pace of development at Mozilla has really picked up lately. Between the ongoing rapid progress on the Boot to Gecko project, the six-week development cycle of Firefox, the web apps, marketplace, and Persona projects, not to mention other projects, it’s become clear that we need to start being more careful about our documentation workflow.

For that reason, we’re going to make some changes to our documentation process.

What’s changing?

In the past, too many person-hours of writing work have been used documenting technologies that were so far from fully-baked that we’ve had to redo (sometimes more than once) these documents. Often, the docs never get properly updated (I’m looking at you, IndexedDB). This is a huge waste of time in an era in which our excellent developers are pumping out so much new code and so many new APIs at a faster pace than ever.

Instead, we will only document new APIs when we can be given a reasonable degree of assurance that they’re stable.

  • For an API that is expected to be standardized, it has, at a minimum, been submitted to the appropriate standards body and gotten through at least one round of feedback and revisions. This will work out enough of the kinks that we can feel good about documenting it.
  • For an API that’s expected to be Mozilla-specific, it has settled down and the developers behind it are able to convince the docs team that it’s stabilized.

This likely means there will be times when the documentation team doesn’t feel that something is ready for documentation as soon as other groups would like to see the docs written. This is an unfortunate side effect of the remarkable productivity level of our development team! Someday, I hope our documentation team will be large enough to keep up with them. But until then, we’ll have to be more selective.

How you can help

If you’re a developer, the first, easiest thing you can do to help is to ensure that your code and headers are well commented, and that you use the dev-doc-needed keyword to mark any bugs that will require documentation updates.

A better, and in the end possibly even more helpful, thing you can do is to provide information! Send email (or, better, add notes to bugs) explaining what’s changed and what needs to be documented. Much of the time, dev-doc-needed means that we have to chase down the right people and ask a lot of questions that could have been avoided with the addition of notes to a bug.

You can go even further and actually update the docs yourself. This may not necessarily always be a viable course of action, but if you’re an expert on a topic, it may make more sense for you to spend a few minutes or an hour or two writing about it than to have the writing team have to do all the research of something you already know. It’s a better use of everyone’s time for you to write down a quick bit of information that we can clean up and turn into beautiful docs than for you and us to go around and around for ages until something’s finally written!

If you write a blog post about something that you think should be in the documentation, please either put it in the docs or at least let the docs team know about it!

The writing team hangs out in the #devmo channel on IRC. Feel free to drop in and ping us with your input or suggestions.

At this point, it’s all about making the best possible use of everyone’s time while turning out not just great code, but great documentation. Because what good is your awesome code if nobody can figure out what they can do with it, right?

 Posted by at 9:30 AM
Sep 042012

I’m back from my week of PTO and just in time! We have a new Kuma wiki platform update today on MDN. To wit:

  • You can now choose SVG images when inserting images into articles. This will be great for diagrams as well as for the SVG reference documentation.
  • The syntax highlighter now has an option for C/C++. How we missed including this originally, I have no idea!
  • The default link in the link editor is now the “simplest” one; that is, the one with the shortest slug. This doesn’t yet make the default always the best choice, but it’s an improvement.
  • The “Revision content” button in a revision details page in the history system now actually shows you the content of the revision.
  • Some initial behind-the-scenes coding for the page moving system has been implemented. There’s more to come.
  • You can now use the class and style attributes the HTML <strong> element.
  • The name attribute is now allowed on <a> elements.
  • You can now use the start attribute on <ol> elements.
  • More MathML elements and attributes are on the editor’s white list. We’re gradually making our way toward being able to use MathML in page content.
  • You can no longer use quotes in page slugs.
  • User profile pages’ list of recent documentation activity now has correct URLs to the affected content.
  • Updated the text of the Dev Derby rules.

In all, another handy little update. Lots of tweaks to make things more pleasant to use, and to fix a few more little glitches in content around the site. This week, our development team is all back from their various vacations, so I have high hopes for great things!

 Posted by at 12:54 PM  Tagged with: