Nov 192007

As I remarked previously, we’re looking seriously into switching from MediaWiki to Deki Wiki for MDC.  This has caused quite a run of discussion, so I figured I’d post more thoughts on this.

We will have a development server up soon that people will be able to use to try out Deki and where we’ll be working on the software to make it work the way we need it to work.

Regarding spam

Deki provides a captcha mechanism to help prevent spam bots from signing up for accounts in the first place; this is an improvement over our current MediaWiki setup (although there is a captcha system available for MediaWiki, we’ve not installed one yet).

We’re pretty comfortable that the spam situation will improve with Deki (although to be honest we’ve managed it pretty well with MediaWiki so far, although it’s been a bit of a cat-and-mouse game to keep ahead of the spammers).

Regarding accessibility

I don’t know a ton about accessibility so I’ll be relying heavily on others to gauge the accessibility of Deki Wiki.

Regarding invalid markup

Yes, this is an ongoing problem.  It would be lovely to have perfectly valid markup but to be frank, that’s not really my priority.  My priority as documentation lead is to get the information out there and make it as easy as possible to create and manage that information.  I hope that we can make progress on this front, but I can’t let validity of the markup be an overriding factor in deciding what software to use to create the documentation because when you’re sitting there writing and editing content, that’s just not what matters the most.

As long as the site works in Firefox and other popular browsers, that’s really what means most.  However, that being said, I fully intend to urge the Deki guys to work on this!

Regarding the Deki editor
There’s an edit source mode that allows you to directly edit the XHTML for an article.  I don’t know about per-page CSS, although that would be nice.

There is a nice WYSIWYG table editor, although I’ve had some interesting issues with it acting oddly on certain table configurations (in particular, single-row tables seem to confuse it a bit).

 Posted by at 12:11 PM

  11 Responses to “More thoughts about a Deki switch”

  1. Captcha is definitely an accessibility problem unless you use a system like reCAPTCHA. It’s a free, accessible system and it helps digitize books. I don’t know of any other accessible system.

    If we go for another off-the-shelf captcha system my contributors will be hosed. We already have that problem on Mozillazine and despite reasonable efforts have not gotten any response to our request to move to reCAPTCHA. Pretty frustrating to be honest.

  2. On accessibility, Captchas are intrinsically inaccessible on purpose. Using a visual Captcha with an audio Captcha as an alternative immediately excludes deafblind people (and doing so is illegal in some countries, including the UK). Eric Meyer’s wp-Gatekeeper is an example of an accessible alternative.

    Using non-semantic mark-up is also at odds with accessibility: if semantics are only conveyed using visual convention (big, bold text is a heading) rather than explicitly described in the mark-up (stuff inside an h3 element is a heading), blind people and Googlebots miss most of the writer’s intention, which makes it harder to convey meaning.

    Invalid mark-up isn’t necessarily semantically void, but it tends to be (and ?why invalid structure use no reason good for).

  3. Those are good points about accessibility and captchas. The problem is that the entire point to them is to prevent automated mechanisms of getting into the system.

    However, assuming that they’re only used when signing up for an account (which I believe to be the case), we could probably come up with a special way to create accounts for people for whom captchas are a problem.

  4. Some of the blogs on use perfectly accessible captchas. They’re mostly questions which are very easy to answer for a human but hard for a computer. That’s definitely the way to go.

  5. One thing about accessibility and markup: since Deki offers source-level editing, I think users will have improved accessibility in that regard.

  6. Personally, I’m really looking forward to WYSIWYG editing, even if it has bugs. That one feature alone will make updating the site exponentially easier.

  7. I checked out the Wiki at the Deki Wiki homepage, and do not see any problems with those pages. Headings etc. are all marked-up properly, the table of contents can be found easily. So the one big problem that needs to be solved is the Captcha. I’d prefer a system that doesn’t require human interaction on the administrator’s part, since that will always delay login approvals and therefore hinder interaction and will make people who can’t use the regular captcha feel “at the mercy” of someone else.

  8. How many wikis have been evaluated?

    Have you looked at TWiki?

  9. Glad to see it works for Marco. He forgot to mention that he’s browsing with the JAWS screen reader. Sounds like the accessibility is fine other than the captcha.

  10. I forgot to ask: Does Deki Wiki allow turning off the WYSIWYG editor? WYSIWYG editors usually don’t play nicely with current screen reader versions. There are provisions in Firefox 3 to deal better with this, but these have to be supported by screen reader vendors. So before that happens, it should be possible to edit the wiki pages in code, too. Is that guaranteed?

  11. Marco — Yes, you can switch to a source level editor that lets you edit the raw XHTML of the content.