Jul 112012
 

We have entirely disabled editing of the current MindTouch based wiki, without enabling the automatic redirection to Kuma, while we deal with a technical issue caused by our script that was automatically migrating every edit on the MindTouch site to Kuma. Once that is resolved, we should be able to enable the automatic redirects of edits to Kuma.

I apologize for the inconvenience, and we will try to get things up and running as expected as soon as possible!

 Posted by at 12:24 PM
Jul 012012
 

The editing experience on the new Kuma wiki that we’ll be deploying starting on July 5th is not enormously different from what you’re used to, but there are some key differences I’d like to call out.

Getting into the editor

Let’s take a look, first, at differences in how you get into the editor. Once you’ve logged in using BrowserID, you’ll still see your old friend, the “Edit” button, at the top right corner as usual:

Screenshot of primary edit buttonYou can simply click that big blue “Edit” button to begin editing the entire page. Easy! But if you want, you can edit just a single section. Each header line has its own edit button off to the right, like this:

Screenshot of the section editing button.

Clicking that pretty blue “Edit” button to the right of the section heading will open an editor just for that section.

Changing page information

Once you’re in the editor, you can edit both content and page information. At the top left you see the title of the page:

Screen shot of the heading box.

Clicking on the “i” icon gives you access to edit page metadata:

Screen shot of the metadata editor.

You can then edit the page’s title (that is, the text displayed as the title of the individual page, and the slug, which is the URL component below the parent page (which you can’t edit; there’s a separate move feature for that).

The “TOC” checkbox lets you toggle whether or not the page displays its table of contents of its headers.

Saving and previewing

Then, at the top right of the editor screen, you’ll see these buttons:

Screen shot of the bar of save/discard options.

These are pretty self-explanatory. The first gives you the option to save your changes without leaving the editor; this is a feature we’ve wanted for ages, but finally have. The second button saves your changes and closes the editor.

The “Preview Changes” button actually opens a new tab showing a preview of the page. We finally, finally, have the ability to double-check our use of scripted templates before saving your edits. This is a huge deal for us!

Finally, the “Discard Changes” button lets you throw away your edits. Hopefully that’s pretty obvious.

Editing

The editor is essentially the same CKEditor we’ve always used on MDN, although it’s a newer version. Most of our keyboard shortcuts are the same as they were before. The most notable difference is that Ctrl-S no longer toggles source mode; instead, it does a “Save Changes.”

One thing we’ve done is revamp the toolbar to be more useful for the types of work we do:

Screen shot of the MDN editor's toolbar.

This is very reorganized from what we had before, with fewer unneeded buttons. Immediately below the toolbar is a block hierarchy bar; this shows you the hierarchy of elements that leads to your current cursor position. This is helpful, for example, to know what heading level you’re on, or how deeply nested your list is, and so forth.

We also now have handy buttons for the heading levels, and a button for preformatted text. To the right of the <pre> button is a menu that, when opened while your cursor is in a <pre> block, presents a list of syntax highlighting language options:

Screen shot of the MDN syntax highlighting popup.

This list is much simpler than the old one, and is certainly easier to read!

The style drop-down menu is pretty similar to the old one, with an assortment of styles we use regularly:

Screen shot of the styles drop-down menu.Tagging articles

Currently, the only way to tag articles is from within the editor screen. This will be changed at some point, but for now, you will find the tag editor at the bottom of the edit page:

Screen shot of the MDN tag editor.

You can delete tags by clicking the “X” in each tag’s box, or add new ones by simply clicking to the right of the tag list and starting to type.

There’s currently a bug that makes it impossible to enter tag names with spaces in their names. This will hopefully be fixed before we deploy Kuma.

Requesting reviews

We’re in the process of building a new, formal review system. While not all of the support for tracking reviews is in place yet, you can establish review requests using the checkboxes at the bottom of the editor page:

Screen shot of the review checkboxes.

For new articles, both the technical and editorial review requests are enabled by default. You can set or clear these as appropriate based on the type and number of changes you’ve made (and, of course, your confidence in your work!).

The “Template” review request is used to indicate that a template has been changed and needs a code review. This won’t affect very many people, because template editing is now under a tighter set of permissions than most editing, for security reasons.

Onward and upward

We will continue to iterate on the editing experience going forward, to make it even better. There are lots of things we want to do to make Kuma amazing!

Sometime in the next couple of days, I’ll share a look at the new localization tools we provide in Kuma. They’re not finished, but they’re already much, much better than what we had with our old system (which is to say: none at all).

 Posted by at 7:54 PM
Jun 272012
 

Hopefully by now you’re aware we’re switching to a brand new, Mozilla-built wiki platform for the Mozilla Developer Network. The new site will launch in mid-July, and we’re incredibly excited about it!

As part of the launch process, we’re going to begin directing all editing of content to the new wiki starting on July 5th. That means any time someone tries to edit a page, they will actually go to the new site and edit that instead. No editing of the current, MindTouch powered site will be possible from that time on.

The current site will remain in place for the time being, and viewers will see that rather than the updated content. However, each page will include a banner explaining the situation and offering a link to the equivalent page on the new wiki, for people that want to view the very latest content.

On the weekend of July 7-8, we plan to have a very structured test program, led by Mozilla’s brilliant QA team. We will be inviting community members to participate actively, to help ensure that the new site is ready for action.

We continue to expect to launch the new site on or around July 15th, directing all traffic there.

Watch this space for further announcements. We’re getting close now, and we’ll need your help to get there!

 Posted by at 1:17 PM  Tagged with:
Jun 212012
 

Change is coming to the Mozilla Developer Network!

As you probably know, we’ve been using the MindTouch wiki software for several years now, and although it’s a nice package, it has not been a good fit for us. As I hope you also already know, we’ve been working for the last couple of years on a brand new replacement wiki, codenamed Kuma, to replace it.

The time for the switch to Kuma is nearly upon us! On or before July 15, we will throw the switch and have all users on the Kuma wiki platform.

Change can be a little scary, but this is a great thing for us. We will get stability, reliability, performance, and, over time, some kick-ass new features. As it stands, localizers should be pleased with a number of new tools they’ll get with Kuma.

The Kuma launch will happen on or before July 15. That’s not much time at all. We have some ongoing test projects for small groups, and we’ll be announcing tests for larger groups soon.

The important thing I want to get out there is that you’re going to see changes, and we don’t want you to be totally surprised! Future blog posts will share details about what to expect, but you can learn more from our basic Kuma documentation on MDN. It’s sketchy at the moment but I promise it will get better very soon!

Watch this space for further news and details. We’re all very excited about this project, and we think you’re going to love it.

 Posted by at 1:34 PM
May 082012
 

Through some dark IT voodoo, we won’t be losing access to MDN today after all! That’s the shorthand version of what’s going on.

More precisely, IT has shut down one of our three MDN hosts and created a VM based on it down at the new data center; MDN will be hosted entirely off that one VM until the physical hardware is in place, at which point we’ll switch back over to the three physical servers we usually run on. Because the VM will be using our real database server the whole time, we don’t even have to lock down to prevent editing! This is an unexpected but highly welcome development that deserves a huge round of applause for our IT department, because every time we’ve tried this in the past, some dark MindTouch secret has prevented it from working.

All that said, because MDN will be operating on a single VM instead of three physical servers, I expect performance will be significantly lower than usual. So be ready for that.

 Posted by at 7:55 AM
May 072012
 

Please don’t forget: MDN will be offline for about eight hours tomorrow (that is, Tuesday, May 8th). Our IT team is physically removing the servers from their current data center and driving them to our new data center to transplant them there.

For the duration of that move, I expect visitors to MDN will be directed to visit dochub.io or other sites temporarily for their basic documentation needs.

It will be interesting how many panicky emails, bug reports, and angry tweets we get over this planned downtime.

 Posted by at 12:24 PM
May 012012
 

I was ecstatic to discover that Mozilla has opened a position for a Mac Platform Integration engineer. While Firefox works, and works pretty well, on the Mac, there are a lot of quirks and oddities that get me down.

In some cases, it’s a matter of the uncanny valley effect. A long time ago, Firefox felt like a Windows application on the Mac. The UI was distinctly different from every other Mac application, and it stood out like a sore thumb. But you knew what you were getting into. You started it up, and because it looked nothing like a Mac app, it was okay that it didn’t really act like one. You didn’t expect it to.

But then we put a fair amount of work into making it look a lot more like a Mac application. As a result, we now have a Firefox that looks much more like a Mac app… but doesn’t quite act like one. There are little, subtle things that just feel wrong. This gives you this uneasy feeling, very much like the uncanny valley effect, and it’s unsettling. This really needs to be addressed, because it’s a big turnoff to a lot of people (myself included).

There are big things, too, of course.

A few things, right off the top of my head, that bug me:

  • Pop-up menus don’t behave like real Mac pop-up menus. This is one of those uncanny valley problems; they used to act totally different, then we made them much closer, but there are still differences, and they’re annoying.
  • Our pop-up panels (like the one that appears when you go to edit a bookmark) look very out-of-place, and many of them are not resizeable even though they would be much more useful if they could be resized.
  • Text selection behavior is subtly different in ways I can’t put my finger on, but I know the issue is there.
  • Drop-down sheets — particularly the one for configuring the toolbar — are just not right.
  • If Firefox isn’t running, and you click a link in another app that causes Firefox to open to open that app, and Firefox has an update pending, the update installs, Firefox restarts, and you don’t get your link opened. This was fixed at one point, then rebroke (possibly around the time we switched from Carbon to Cocoa). This drives me nuts, especially since I run on Aurora and/or Nightly, so it happens to me all the time.
  • We could use more and better gesture support. At one point, we had swipe to top and bottom support, but that vanished at some point. With Lion making it clear that gestures are the wave of the future on Mac, we need to get on board.
  • With Mountain Lion on the way, we need to look at integrating with the new Notification Center as well as the operating system’s built-in sharing service. Being able to quickly tweet using that service would be a really nice touch.

That’s by no means everything, but just what I could think about in the five minutes or so it took me to compose this post.

So if you’re a Mac developer looking for work, consider Mozilla! You’ll be glad you did! It’s a kick-ass place to work, and a lot of fun. And you’ll be making a great browser greater on the best operating system around.

 Posted by at 8:05 AM
Apr 302012
 

We had a fantastic documentation sprint this weekend! I won’t go over all the stuff we got accomplished, since that’s already covered elsewhere. Instead, I’d just like to thank the folks that came out for their time, and for all their hard work.

In addition to writing a lot of material, we got a lot cleaned up, and spent some great time talking, getting to know one another, and seeing the city of San Francisco and the surrounding area. Our ferry ride up to Sausalito for dinner, and the cab ride back to the city across the Golden Gate Bridge was, I know, a big hit with some of our first-time visitors to the Bay Area.

I personally enjoyed meeting everyone I didn’t already know, and seeing familiar faces once again. On top of that, it was nice to check out the San Francisco office, which I’d not yet seen. I understand now why it’s so popular. It’s one of the most impressive locations I’ve ever seen!

While most people share pictures of the view of the Bay or of the Bay Bridge, I want to share this one. I remember this sign from when I was a kid, but never from this close up!

The iconic Hills Bros. building sign!

It makes me very proud to work for an organization that will bring community members together like this to collaborate in real time, in person, now and then. It’s great for community bonding as well as for just getting things done. And I’m proud of our contributors that attended for giving up some of their personal time to spend time with us here in the City by the Bay. Thank you!

 Posted by at 1:17 PM
Apr 242012
 

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.

Note: This Wiki Wednesday is published way off-schedule, and a little short, due to a technical problem I ran into compiling it.

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

JavaScript

Thanks to Berker Beksag for contributing!

SeaMonkey

Developing Mozilla

Extensions

Thanks to Neil Rashbrook for his contributions since last time!

XUL

XPCOM

Thanks again to Neil Rashbrook for his help!

Interfaces

Thanks (yet again!) to Neil Rashbrook for his contributions.

Plugins

CSS

Thanks to brianloveswords!

 Posted by at 11:09 AM
Apr 152012
 

As I’ve blogged about before, I’ve been working on sample code for the source-editor.jsm that was added to Firefox as part of the ongoing work on the developer tools. This sample code evolved over time into a full-fledged extension, and one I’m rather proud of. I just posted it to AMO today.

Edit Source adds options to the Web Developer menu and the context menu on text-based documents (including HTML, CSS, XML, and JavaScript), which lets you open a source editor window. You can then edit the document’s text, save it to your local disk, and most interestingly, re-render the original document (for HTML, anyway) to reflect the changes you’ve made.

This makes it a handy tool for experimenting with HTML, and a nice learning tool. In addition, if you open up an about:blank tab and edit its source, you can write HTML from scratch and see what it looks like rendered on screen. That’s also a pretty neat trick.

There are things that would be fun and useful to add to it, but I probably need to move on and get to writing again! So I’ve posted the code to Github. Feel free to take a look and tweak it! There’s an IDEAS.txt file in the repository you can look at for some thoughts for things that might be handy to add.

 Posted by at 4:46 PM