Compelling, authentic science fiction. Spooky.
It’s common for the teams working on parts of the various Mozilla projects to have periodic work weeks or in-person meetups, wherein the teams travel from all over the world to sit in one place and work together or talk for a few days. These are a great way to sync up, bond, and exchange information face-to-face.
There’s a lot of information to be gained at these events. More importantly, perhaps, they’re a great way for people to meet and find out who knows what about which topics. As such, there’s a lot of potential value in having a representative of the MDN writing team attend your work week. By having a writer attend, you can share with them your concerns about the quality or state of the documentation, share valuable insights about how the code works, or even simply guide the writer to where all the best design notes and discussions are archived.
As such, we’d really appreciate being looped in if you have a work week planned. We can’t necessarily send someone to every work week every team has, but we’d sure like to try to at least drop in for a day or two to the ones we can get to.
In addition to our writing team gathering useful information, we can provide useful information to your team, such as:
Whenever your team schedules a work week, please feel free to email me and ask if we could send a writer to join you. Like I mentioned before, we might not always be able to do so, but we will try to when it’s possible and makes sense to do so.
It’s been many months since my last status report on the state of Kuma. There are many reasons for this; some technical, some personal. I’ll be trying to do this more regularly again going forward. Obviously, the big project is the redesign of MDN. Most of our fixes apply directly to that project right now.
Here’s a quick list of the things that landed in the last few days:
Also, several internal fixes building up toward upcoming big features have been committed.
We should be getting the ability to delete and move pages very soon. The code is finished and committed; I’m trying to sort out why it’s not enabled yet so we can fix whatever remains to be done so it can be switched on, at least for a few people to test.
Beautiful. Enthralling. Almost accurate physics.
I’ve released OK-Writer 1.4! The latest version of my Mac OS X word processor aimed at children and others who need a simplified user interface for word processing. The new version has new retina-quality icons, improved user interface layout, full-screen mode support, and other improvements.
One of the things I’m particularly proud of is the unforeseen use of OK-Writer by people with disabilities, especially vision problems. Its speak-as-you-write features have proven useful for the disabled. That’s a great source of personal pride for me.
To get a little more specific about what’s changed in this version other than the retina icons, I’ve spruced up some of the innards a bit to prepare for some future work I’m planning to do, and obviously the background is no longer brushed metal, but is a lovely periwinkle-like blue. I’ve fixed a couple of minor bugs, and the buttons don’t drift around slightly crazily when you resize the window anymore.
Full-screen mode has proven popular with Sophie, too. I may do some experiments with ways to make that experience better and/or more fun in the future. I made sure to make that code conditional so that the program still works on OS X 10.6 upward.
I did drop PowerPC support in this release, and I dropped support for Mac OS X 10.3 through 10.5. But this version is built as a 32/64-bit Universal binary. It was time to cut the cord on some of the older Macs, but the older version of OK-Writer is still available on my web site for people who need it.
Ah, spring! The flowers bloom, the snows melt (usually), and lovers of the Web and of Mozilla are heading to Vancouver, British Columbia to participate in our spring documentation sprint at the Vancouver Mozilla Space.
We’ll be gathering writers and a few developers together to pound out as much great documentation as we can, along with, I’m sure, a few fun evening activities.
If you can join us, feel free to drop in! Or participate virtually by logging into MDN and joining the chat in the #devmo IRC channel. We’ll save a seat for you at the ol’ keyboard.
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!
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 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!
The Mozilla Developer Network (MDN) is (and yeah, I may be a little biased here) one of the greatest online resources for Web developers you’ll find online. We’re constantly writing away, trying to make it better, and if you haven’t seen me (or one of our other team members) out there trolling for more people to write documentation, you’ve probably not been paying attention. Which is fine — because maybe you’re not much of a writer, or you prefer to hammer away at code.
As it turns out, there’s more to MDN than writing prose explaining how things work. Here are a couple of things you can do to help out if you’d like to make MDN better but find writing in languages other than C or JavaScript tedious and frustrating!
Make the documentation platform better
MDN uses our very own, open-source, Kuma wiki platform to power its documentation. We’re hard at work to make the software better, with our fabulous and hard-working development team pounding out code at ludicrous speed.
That said, however, there are plenty of things on our development team’s to-do list, and some help is always welcome. In addition, maybe you have an idea of your own!
The Kuma code is available on Github. Feel free to pull it and see what you can do. There are instructions available for how to set up your build environment, as well as for how to contribute to the code.
If you’d like to talk with the development team, get help, and even talk with the writers that are most engaged with the development process, feel free to pop into the #mdndev channel on IRC. You can also keep an eye on what the rest of the development team is up to by checking out their status updates on our Standu.ps site.
Sample code
A key feature of any developer documentation is good sample code. While we have some sample code, we can always use more. Until recently, adding samples was not always easy, especially if you wanted people to actually be able to see what the code does. However, with the recent addition of our live inline sample support, that’s all changed for the better.
Feel free to peruse our documentation and find places where samples would be useful and devise some! Obvious candidates for live samples are the HTML and CSS documentation, as well as documentation about DOM interfaces and functions. You can probably also come up with some helpful examples for the JavaScript docs, too.
Examples don’t have to be fancy or flashy. Indeed, the simpler they are, the better, in most cases. The less extra “stuff” there is for the reader to have to deal with, the more quickly they can get to the heart of the matter and really understand what they’re looking at.
Help me, Coder-wan Kenobi… you’re my only hope
There’s a ton to do! Between documentation (that’s where the writing community comes in), the Kuma project (where our Kuma dev team, hopefully including you soon, comes in), and samples (where, well, everyone comes in!), there’s plenty to be done. There’s something out there for everyone. Can you find your perfect place to contribute to help make the best online resource for Web developers even better?
We’re having a virtual — that is, online — MDN documentation sprint from November 30 through December 1! We encourage anyone interested in helping make documentation of and for the open Web to log onto #devmo on irc.mozilla.org and help out. Even if you only have a few minutes, it’s possible to make a huge difference. Indeed, if you’re a Web developer that knows lots of things, you can log in and help answer questions the writers might have. That’s a way you can contribute to MDN content without doing any writing yourself!
Check out the wiki page about this doc sprint and put your name on the list if you plan to participate. There’s even a list of links to suggested topics for work. And you can even contribute by simply adding live samples to existing articles, using our nifty new live sample system!
I hope to see you there! We always have a good time and get lots of great work done to make developing for the open Web easier for everyone!