Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Comments for ...since sliced bread

Amen, brother. I feel the same way: nice idea, lousy religion.

I will have to try out this WYSIWYG editor of which you speak. My vision of edit-in-place is the same as yours, and I've done some prototyping of it (but as native apps using WebKit). I know Safari / WebKit have some bugs that make HTML editing difficult (and I know other browsers have other bugs) so I'm impressed that you (and other folks at Jot) have gotten it to work cross-platform. Congratulations!

Haha. Amen. My general dislike of wikis is what dissuaded me from trying harder to get a job at Jot. Well, that and the fact that they are in Palo Alto.

I'm very happy that Jot Live actually happened, though, and I'm proud to have played some small part in realizing that vision. The Tracker v2 screencast is mindblowing as well. I wish Jot the best of luck, and look forward to see what other envelope-pushing things get produced!

Have you seen WikiWyg ( It seems very similar to what you've described so far, although I haven't tried out the new wysiwyg from Dojo.
Hi Michael,

So when I worked at Jot, SocialText's Wikiwyg was one of "the competition", but it had (and still has) several fatal flaws. The first is that when you got into wiki-markup mode and then go back to HTML, you lose your changes. Of course, there's no notice of this when you go to wikimarkup mode and it doesn't give you a chance to not lose your data if you are somehow duped into clicking those inviting mode buttons at the top. Data loss == a crappy experience.

The biggest problem, though, is that Wikiwyg seems to assume that having access to Wiki markup is somehow a good thing. It spends amazing amounts of effort trying to convert HTML to wiki markup (but not the other way around, hence the data loss). It is, in essence, a wiki markup editor with some HTML bits hanging off the edge.

Jot/Dojo's editor by contrast is a WYSIWYG editor that happens to interface with a back-end which handles conversion/translation to and from the wiki markup. Which is where it should be happening in the first place. Having to keep a JavaScript version of your perl-implemented one-off markup language in sync with all of the server conversion idioms is a recipe for bad corner-case behavior.

I remember reading a press release at some point that said that Wikipedia was going to be integrating Wikiwyg, which I suppose makes some sense if the point is to have a front end that is compatible with the wiki religion and perhaps Socialtext is shipping it to their customers, but I can't imagine that it's a good experience.

If users wanted wiki markup, they would have picked the wiki markup editing mode in the first place. Our experience showed that users just care about getting their content into the wiki.


by alex at
Hey Alex, is it just wiki markup that you don't like? Or is it also the whole freeform collaborative editing and page linking?

(Ward Cunningham said somewhere that he wished he had a good WYSIWYG editor in the first place...)


by Bob Haugen at
Hey Bob!

It's mostly wikimarkup that I find offensive, but the total lack of structure in most wikis is also tremendously problematic. That Jot lets you build things that are as structured as you need them to be (but no more rigid than that) was what really closed the deal for me. I'm convinced that a semi-structured content repository like Jot is the future. Keeping the barrier to entry for adding content low is a wonderful thing, and systems that build in saftey nets to solve some of the problems that arise from that strike me as a "good deal" from an interaction perspective.


by alex at