• Pages

  • About
  • Download Files
  • Polls

• Blog Categories

  • Firefox (51)
  • Geekology (101)
  • MDC (54)
  • Mozilla (395)
  • Personal (194)
    • Movies (6)
    • Television (15)
  • Politics (8)
  • Rants (27)
  • Uncategorized (8)
• 

• Blog Archives

  • July 2009
  • June 2009
  • May 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009
  • December 2008
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • November 2007
  • October 2007
  • September 2007
  • August 2007
  • July 2007
  • June 2007
  • May 2007
  • April 2007
  • March 2007
  • February 2007
  • January 2007
  • December 2006
  • November 2006
  • October 2006
  • September 2006
  • August 2006
  • July 2006
  • June 2006
  • May 2006
  • April 2006

• Meta

  • Register
  • Log in
  • WordPress
  • Beeblebrox Theme

• Copyleft

  

  The content of this website is licensed under a Creative Commons License.

25 Responses to “MDC: Big changes ahead”

1. Aaron Fulkerson says:
   November 16th, 2007 at 5:32 PM

   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: https://sourceforge.net/projects/dekiwiki

   Some key points that the Mozilla community will dig I make here: http://www.mindtouch.com/blog/2007/11/12/open-source-open-standards-open-api/

   Here’s our API documentation: http://wiki.opengarden.org/Deki_Wiki/API_Reference , our community forums: http://forums.opengarden.org

   And finally, here’s a short demo vid most of you folks should really dig: http://www.viddler.com/explore/Roebot/videos/15/

   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. Mike Shaver says:
   November 16th, 2007 at 5:54 PM

   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. Benoit says:
   November 16th, 2007 at 6:08 PM

   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. Gérard Talbot says:
   November 16th, 2007 at 6:46 PM

   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. sheppy says:
   November 16th, 2007 at 7:04 PM

   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. Mike Shaver says:
   November 16th, 2007 at 7:13 PM

   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. Aaron Fulkerson says:
   November 16th, 2007 at 8:18 PM

   dev-mdc: https://lists.mozilla.org/listinfo/dev-mdc

8. Sylvain says:
   November 16th, 2007 at 9:34 PM

   s/lucerne/lucene/

   (The town is pretty nice by the way )

9. Jens Bannmann says:
   November 17th, 2007 at 2:23 AM

   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.

10. Aaron Fulkerson says:
    November 17th, 2007 at 2:30 AM

    @Jens, yes.

11. Gérard Talbot says:
    November 17th, 2007 at 3:25 AM

    Hello,

    I went to mindtouch.com 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…

    Mozilla.org is supposed to be an organization using and promoting web standards, not the opposite.

    Mozilla.org proudly claims to be an organization using and promoting web standards – a thing that is repeated and underlined at mozilla.org webpages, a reason for choosing products like Firefox according to mozilla.org 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??

    Gérard

12. nul says:
    November 17th, 2007 at 4:35 AM

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

13. Benoit says:
    November 17th, 2007 at 5:00 AM

    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.

14. Steve Lee says:
    November 17th, 2007 at 7:32 AM

    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 schoolforge.org.uk) which negates the whole point of a wiki. Admittedly we’re stuck on an older version of MediaWIki ’till we can use PHP 5.

15. Fred says:
    November 17th, 2007 at 8:23 AM

    Actually, Lucerne is a city in Switzerland and the Apache Foundation project is called Lucene

16. Gérard Talbot says:
    November 17th, 2007 at 12:24 PM

    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, mozilla.org style and markup guidelines were set: why MDC never followed such guidelines, authoring guidelines?

    Transitional DTD: why is that in end of 2007?

    Gérard

17. Jay Goldman says:
    November 18th, 2007 at 2:35 AM

    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.

18. nobody says:
    November 18th, 2007 at 8:56 AM

    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 wiki.mindtouch.com 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.

19. Jeff Walden says:
    November 18th, 2007 at 3:55 PM

    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.

20. Gc says:
    November 18th, 2007 at 4:31 PM

    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.

    https://help.mindtouch.com/Deki_Deployment/System_requirements

    http://wiki.opengarden.org/Deki_Wiki/Installation_and_Upgrade

    http://wiki.opengarden.org/Deki_Wiki/Installation_and_Upgrade/Installation_FAQ/Deki_Wiki_Dependency_Lists

21. sheppy says:
    November 19th, 2007 at 12:07 PM

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

22. Mozilla? ??? Deki Wiki says:
    November 20th, 2007 at 12:57 AM

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

23. stevel says:
    January 10th, 2008 at 6:14 PM

    “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.

24. David Bolter says:
    April 25th, 2008 at 4:08 PM

    @Steve Lee: I’ve spoken to some dekiwiki devs and hopefully some accessibility work will be happening in the near future. See http://bugs.opengarden.org/view.php?id=3858

25. chocolateboy says:
    May 18th, 2008 at 1:23 PM

    > 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.

Leave a Reply