Nov 162007

After a lot of research, it looks likely that we’ll be moving the Mozilla Developer Center away from MediaWiki, which we’ve been using for some time now, to Deki Wiki.  There are a number of reasons we’re probably going to be making this move:

  • Two words: Syntax highlighting.  You can specify a language for a code snippet and get syntax highlighting with numbered lines; fantastic for doing explanations of what a sample does.
  • Deki uses lucene for searching, and it’s built in, so we don’t have to fight with Nutch.  Searches can even go into attached files, so a search on, say, “nsIDownloadManager” will not only find articles mentioning that interface, but also any downloadable code samples that make use of it.
  • Deki offers a very snazzy WYSIWYG editor which should make it easier for new contributors to get going.
  • You can easily attach downloadable files to articles, and there’s a nice file manager for organizing these. This will make it much easier for contributors to offer sample code.
  • Very nice built-in statistic features.
  • Articles can be keyword tagged.
  • Advanced printing options, including PDF download option.
  • Since all content is stored in XML instead of in a database, we have some interesting possibilities for making portable versions of the wiki that could be downloaded and browsed offline.
  • It looks like it will be easier to customize the appearance and functionality of the site with Deki.

The folks at MindTouch will be writing us a utility to convert our current MediaWiki content into Deki, and will (assuming we do indeed decide to go ahead with this transition) be adding some new features to their software that we’ve requested.  This is a huge plus for us: we can get the software revised to meet our needs by people that know the code inside and out.

We’re still working out exactly what changes they would be making to the code for us, but it’s looking very good, and I think folks will be pleased with the result.

Assuming this transition happens, it will take place sometime early next year.  Hopefully in the first quarter but I wouldn’t be surprised if it slips into Q2, given the huge amount of stuff that needs to be done to make this happen.

I’ll blog further on this as things develop.

 Posted by at 4:26 PM

  25 Responses to “MDC: Big changes ahead”

  1. Whoa, I guess the cat is out of the bag. :-)

    We’re super stoked about this. Once the Mozilla community gets a look at what MindTouch Deki Wiki can do they too will be very excited. You linked to our corporate website where we serve up a VMware image of our free and open source software (GPL2), but some of your readers may prefer source code. For this go here:

    Some key points that the Mozilla community will dig I make here:

    Here’s our API documentation: , our community forums:

    And finally, here’s a short demo vid most of you folks should really dig:

    This is a _very_ big deal for MindTouch. We’re going to bend over backward to live up to the expectations of the Mozilla community, I’m confident in the end we will exceed them.

    Thanks for the intro E.

  2. There are a few other things that really make me optimistic about life with Deki:

    1) Can mix SVG and other content into the page, making our examples much more pleasant to work with.
    2) Has support for integrating things from other services, ranging from calendars and maps to (in theory) systems like Bugzilla

    Could be good!

  3. I’m curious as why it would be easier to migrate to a completely different system than to fix MediaWiki. I’m sure most of the features you mention (such as syntax highlighting and maybe PDF export) could be added to MediaWiki by some plugin. Not all of them are appealing to me, for example I have yet to see a convincing implementation of Wysiwyg editing in a wiki. And “all content is stored in XML” sounds scary to me, when I read this the word “entreprisey” immediately came in my mind. Ever read the Daily WTF horror stories? :-) More seriously, I hope it won’t make performance worse than it is already.

    I tried to get a little more information on their site, but there doesn’t seem to be a live demo (when you click on “demo”, you get a bunch of Flash presentations which is not what I expected). Many questions remains. For example, what would it mean for our localizations? The word itself doesn’t even seem to exist on the site! I’m also concerned about the complex system of parametrized templates that we use (for example in the XUL reference), which is far from a simple “page transclusion”. Also, what about all the tools and abilities that all our contributers have built for some years? As a localizer, I’d hate to work without the wonderful japanese bot, or the “What links here” and “Related changes” links.

    That’s not to say it’s a bad idea, but I hope you’ll also take in account the unavoidable disruption it would cause in our teams. To quote another team member, “we were just beginning to understand how to handle MediaWiki” :-)

  4. PDF file format is widely known, widely acknowledged to be non-accessible, dependent on installment of an external software, to increase file size, etc. A very large majority of accessibility groups and gurus (J. Nielsen, V. Flanders, etc) all converge to say that PDF file format should be used only for printing documents requiring a very precise print formating and that any other usage for PDF is formally discouraged.
    Usability studies overwhelmingly converge to say that users dislike, hate (for many reasons) PDF links. Acrobat Reader requires a long download (the .exe is over 20Mb), requires a lot of
    user system resources to start and to work and often have bugs, including security ones.

    3 questions:

    1- Right now, MDC is based on XHTML 1.0 transitional. What will be the doctype declaration and DTD used by Debi Wiki? Will it be possible to choose only one? Can it be possible to customized Debi Wiki to use only HTML 4.01 strict DTD?

    2- Will MDC allow interactive DHTML demos (“show” examples for instructiveness purposes) to be embedded, inserted into webpages… just like MSDN webpages do?

    3- Will the snazzy WYSIWYG editor create entirely valid markup code at all times?

    Regards, Gérard

  5. PDF is just one of the things you can do, it’s not required.

    As for Gérard’s questions:

    1 — I’m not sure specifically, but will find out, what doctype declaration and DTD will be used.

    2 — Yes, we’ll be able to embed demos into pages. We’ll also be able to embed SVG samples and the like. It’ll be awesome.

    3 — Because Deki doesn’t use wikitext, but instead saves everything as XHTML, the WYSIWYG editor doesn’t have to create valid wikitext markup — instead, it creates XHTML and saves that instead. At least, this is my understanding of things. All I can say is that it seems to work very nicely.

  6. The software itself is localized into a subset of our languages (we’ll be working to get the remaining active languages localized in the software and upstreamed; it’s about 1000 strings per language all in one file), but the localization model would be the same as it is now: multiple wikis run on a common source base, with unified authentication. I wouldn’t worry about what format the content is stored in — did you know that Firefox’s UI is also all stored in XML? :) — and please rest assured that performance is a very significant evaluation factor for us. (I personally think “stick everything in a relational database! whee!” is far more enterprise-folly than “store documents as XML”, but we could debate that all day!)

    Extending and maintaining our extensions to Mediawiki has been quite difficult for us, so Deki’s focus on providing stable (and rich) APIs for web applications to be integrated, along with the availability of expert support on call from MindTouch, is a major motivator. (If you can find a good syntax highlighting extension or PDF export system for Mediawiki that’s being maintained, I’d be surprised — we’ve been looking for them for some time, and our experiences with writing our own extensions have been pretty painful. The set of stable and available APIs for working with additional page metadata — or even the way page IDs are tracked — is quite small.)

    The Deki template system is powerful enough to do what we do (and I think even more so), and the migration will include making our existing templates work just fine. What-links-here and related-changes should persist, and we’ll be working with the tool operators to make sure that the capabilities they need are present. We should in fact be able to provide better hooks for those tools, because of the richness of the API, and the focus of the Deki team on making sure their system is a hospitable environment for such extensions.

    I think it’s hard to find a tougher editor customer than Eric, so his endorsement of it weighs quite strongly with me. Because the format is XHTML, though, you can really use any editor you want and paste in, which will make it easier to include content from other tools as well.

    Please don’t think that we would undertake something like this lightly — we think that we’ll end up with a system that’s even easier for all our contributors to work with (you’ll be able to post localized example files, for example, without needing to email them to Eric every time they’re changed!). And we would have a contract with MindTouch for both installation _and_ development support, to make sure that we’re able to take full advantage of the power of the system over time.

    We have a test and development site coming online shortly, and you’ll be able to see and experiment with things there, including the migration of content and templates, the localization setup, and the editor. Thank you very much for your comments, and for raising issues you think we need to keep in mind. As it happens we’ve been discussing all of the ones you listed, but please keep them coming. MindTouch is very motivated to make this a successful and pleasant experience for our whole community, and I know they’re eager to learn more about our specific needs. (dev-mdc might be a better place for such a discussion, as it’s easier to discuss things there.)

  7. s/lucerne/lucene/

    (The town is pretty nice by the way ;-) )

  8. Will the migration utility be published? At my company, we also hit some limits of MediaWiki and would definitely consider switching, but only if such a tool was available.

  9. Hello,

    I went to and visited a few webpages and I’m not impressed. Everything is in XHTML 1 transitional, has 50-100 validation markup errors, is basically a huge macaroni of div tags, a spaghetti of classes, ids everywhere, over-qualified selectors and plenty of invalid attributes. So, it’s going to be obviously contradictory to tell people to code the opposite way of what the webpages are made of, to write valid markup code on a MDC webpage when such MDC webpage is written with invalid – DekiWiki – markup code. Practice what you preach. Yeah… is supposed to be an organization using and promoting web standards, not the opposite. proudly claims to be an organization using and promoting web standards – a thing that is repeated and underlined at webpages, a reason for choosing products like Firefox according to webpages.

    At least 20% of all filed/created bugs at bugzilla about a specified URL for products like Firefox and Seamonkey are clearly about webpage authoring, about IE6/7 doing differently than Firefox, etc..: in such cases, what are you (QA triaging volunteers) going to tell them? To make sure they use valid markup code, valid CSS code, make sure their webpage triggers standards compliant rendering mode and… then to visit MDC??


  10. Has that any anti-spam bot support (many register at devmo)

  11. Mike: Of course, XML is a wonderful way to describe, export and handle page data. It’s just not what I would use to keep multiple revisions of the same file by various editors. But I’ve seen in the API doc that they actually use MySQL, so the point is moot anyway.

    I’ll try to install the system locally on my machine in the next few weeks to be able to make more constructive comments :-)

    Gérard: While you’re right about how we should teach by example, MediaWiki isn’t exactly (X)HTML Strict either.

  12. I’d be deserting my duty as a Mozilla Accessibility project member if I didn’t ask about accessibility. How accessible is the created content? Sure, a part of that depends on what content people create, but you can mitigate that to some extent with templates and good practice guidelines. It’s more than just creating valid markup, though perhaps an extension of it.

    I don’t know if XHTML adds more accessibility issues than HTML 5, but I get the impression that there’s an industry sea change towards HTML. Aaron Leventhal could probably comment on that from an accessibility angle.

    Perhaps more importantly how accessible is the WYSWIG editor? For example can screen reader users easily edit content? Firefox 3.0 offers great accessibility features so users including those of Assistive Technologies like screen readers have the best chance of a good experience. But what about those still using other browsers (intentionally evangelistic phrasing).

    Another issues is how good it is it at filtering and managing wiki spam? I don’t know what the MDC experience is but several MediaWiki’s I’ve been involved with have been hit badly, even with Bad Behaviour installed. I’ve even had to disabled new accounts on a couple (e.g which negates the whole point of a wiki. Admittedly we’re stuck on an older version of MediaWIki ’till we can use PHP 5.

  13. Actually, Lucerne is a city in Switzerland and the Apache Foundation project is called Lucene :)

  14. Benoit,

    I have complained loud about invalid markup code regarding the current MDC, regarding the webpages themselves and regarding the examples (having validation markup errors or using/relying on transitional DTD) shown for demonstration purposes in the webpages. Deki Wiki is not (will not be) an improvement in that regard. MDC currently does not teach by example and the proposed changed is not an improvement.

    Code validity, clear separation of content from presentation, triggering standards compliant rendering mode, semantic markup, properly structured markup code, CSS code reusability, etc.. are important and should always be important.

    Many authors have said that XHTML is dead. Why do we keep authoring with XHTML served as text/html? A few years ago, style and markup guidelines were set: why MDC never followed such guidelines, authoring guidelines?

    Transitional DTD: why is that in end of 2007?


  15. We run an internal MediaWiki for knowledge management within Radiant Core, and have been loosely working with the guys at MindTouch for quite a while now so we know Deki pretty well. I can say that Aaron and the crew have forgotten more about wikis than I’ll ever learn, and that Deki is a far more mature and well maintained infrastructure than MediaWiki is. Our internal wiki is obviously much, much smaller than MDC, but we’re considering porting over for many of the same reasons, and can’t wait to have a tool to do most of it for us. For whatever it’s worth, this gets my vote.

  16. I’m typing this on a machine with a white on black desktop theme — that means the textarea for comments is white on white. Bad form and I’d expect Mozilla people to understand problems like this!

    The top menu at relies on javascript. I can’t seem to find a demo of dekiwiki, the best I can hope for is that it’ll work without script as I regularly consult MDC for the DOM and Javascript materials.

  17. Gérard: if it’s not worse than the current situation, I don’t see how that’s a problem. Also, while validation is a concern, I think getting the information across is a more important one (but it doesn’t matter here anyway, because we’re not robbing Peter to pay Paul).

    So everything’s stored as XHTML? I’m curious how well this roundtrips edits, because if it doesn’t do so well it limits you to the flexibility that the WYSIWYG interface exposes. I’m also minimally concerned about consistent style (particularly for some of the things we attack with templates right now), but I guess the intent is that editors not have to think about that. If you drop to source-editing mode, do you get a pretty-printed version that’s more amenable to edits?

    How do intrawiki links work at source level for preserving wiki location migration?

    Does it have support for some form of a prebuilt page store, so that, say, I can copy the format of a CSS property page when documenting a new property on a new page?

    What support is provided for articles intended to be read in series, or for books presented in chapters?

    I’m sure I have more questions to ask, but I should definitely put off asking them to a different time. :-)

  18. It certainly could be nice not to be limited by wiki markup and be able to use full xhtml, css, svg, etc.

    From my exploration of the limited documentation I have not been able to find what the capabilities of the WYSIWYG style editor are. Is there a ‘edit source’ mode to edit the xhtml/etc. code directly? Or do human editors that need to edit a page that cannot be edited with the WYSIWYG editor have to submit revisions with an external tool?

    For example, is it possible to create per-page CSS for use in tables (where it is much less readable and maintainable to mark the style of each cell individually)? That has been a holdup for introducing flowable, editable component block diagrams in html such as in this mockup page (best viewed with Mozilla browsers) from bug 334225 (“CSS style rules for component stack diagrams, component block diagrams”).

    For anyone looking for prerequisites documentation, unfortunately the download links take you directly to a sourceforge download, not to a download description page. (240MB is too much for some of us to wait to download without having a clue whether it will be able to run.) Site search field didn’t help much; I eventually had more success with off-site Google.

  19. I’ve got responses and thoughts on a lot of these comments, but am going to post a new blog post with those thoughts.

  20. […] Mozilla Developer Center ? Mediawiki? ???? ???? ????. ??? ?? Deki Wki? ?????? ??? ????? ???. ????? Mediawiki? wikipedia?? ???? wiki?? […]

  21. “After a lot of research”

    Eric: any chance that research is published somewhere? We’re looking at migrating from a MediaWiki to DekiWiki – and part of that involves some evaluation & research. I’m hoping to be lazy and take a look at some of what you guys did for MDC.

  22. @Steve Lee: I’ve spoken to some dekiwiki devs and hopefully some accessibility work will be happening in the near future. See

  23. > If you can find a good syntax highlighting extension or PDF export system for Mediawiki that’s being maintained, I’d be surprised

    What’s wrong with the Geshi extension? It’s actively maintained and is used by a number of high-profile Mediawiki sites, including Wikipedia.

    This extension is being used on one or more of Wikimedia’s wikis. It means that the extension is stable and works well enough to be used by such high traffic websites.