Infrequently Noted

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

Bayeux

There's been a lot going on in the world of Comet in the past couple of months. Post-JavaOne activity from the Java side has been tremendous and I was unaware of most of it until Greg Murray and Greg Wilkins mentioned the various efforts to me. <a href=http://blogs.webtide.com:80/gregw/2006/07/25/1153845234453.html">Greg's got the details of most of the Java activity, save Sun's Comet-on-Grizzly announcement. As was widely covered elsewhere, the excellent work of Juggernaut has demonstrated the Flash XMLSocket approach and integration into a widely-used, modern web framework. Of course, Nevow has been shipping some great Comet infrastructure for Twisted developers for years, but that's been a pretty small group of folks.

In other news, the Cometd project has been accepted into the Dojo Foundation. With multiple demonstrated implementations of the pre-0.1 Bayeux spec, we've got lots of momentum around solving the "last mile" problem for events to browser. Work on the spec has been bursty but I think that's contributed to keeping it simple. Right now we're tackling topic/channel globbing, event timeouts, and multiple event delivery semantics. Perhaps the most exciting thing to Bayeux to me, though, is that implementations of it lend themselves to extension and experimentation with implementing new styles of Comet transport mechanisms. The current Bayeux client in Dojo supports 4 different transport types with more on the way.

I think it's going to be interesting to see how much the ability of platforms and languages to handle Comet workloads impairs or enhances their chances. Can Ruby and PHP pull off something that'll allow them to scale? Will Twisted Python, Erlang, or full-stack Perl finally have their days in the webdev sun? Will great implementations in Java and C# hold the dynamic languages at bay?

I can't wait to find out.

Mea Culpa

The tone of my last post was entirely out of order. There's a serious UX issue at hand and my writing did nothing to bring that discussion to the fore. I hope Jason will accept my apology.

Excuses

Update: read this first

Jason Fried is full of shit.

It's really sad to see a supposed champion of user experience equivocating instead of dealing with a serious experience issue. Initially, the party line was that cross-browser WYSIWYG wasn't possible. After we put that misconception out to pasture with dojo.widget.RichText and showed that the UI doesn't have to be complicated to be functional (dojo.widget.Editor2), it's amazing to see 37signals adopt all the classic signs of NIH-ism. Why would someone use Writeboard if they weren't interested in sharing what they write? Almost all of the UI of Writeboard that isn't taken up by content is dedicated to collaboration. The argument Jason makes takes the side of some mythical hermit writer who wants a crappy text editor that doesn't have auto-save, is difficult to resize, can't load files from disk or save to it, doesn't feature spell-checking on most platforms, and can hardly function when not connected to the network. Umm...yeah.

Folks writing stuff down for consumption by others are necessarily concerned with how it's presented to those other people. Sure, browsers make it a royal pain to do WYSIWYG reliably and consistently across browsers, but is the fact that it's hard somehow a good reason to prevent users from expressing themselves with better fidelity? I argue that it's not, esp. when you're charging people money for a service. Folks who want to learn YAML can download any of a hundred Open Source wikis and start debating the finer points of reStructuredText vs. Textile vs. Markdown vs. MediaWIki syntax. These are people who don't need 37signals to help them identify with the system model.

Which leaves us people who want to share things with other people, don't really give a shit about figuring out what clever combination of keystrokes is going to make something bold, and would like their investment in UI idioms to be portable to the web. I humbly submit that this market represents most humans who interact with computers. When it comes to UI, only be different when you can be demonstrably better.

There are a lot of UI problems left to solve with WYSIWYG on the web today. What we can already do in browsers is a pretty poor baseline for what we should be giving users and hugely smart people have been hacking on the problem for a long time. It's about time that we started evolving some truly "web-ish" idioms about how WYSIWYG should be done and how we can keep users happy but still informed about the limits of the medium. In the Dojo editor, we attacked this by stripping down the number of options to the point where the toolbar represents only what browsers natively support editing on, which falls neatly in line with what they reliably render without losing the semantic of what the user meant to convey. The new "snap-floating" toolbar in Editor2 is designed to keep the chrome in place when it's needed but not break the page-centric idiom. The new editor in 6Apart's Vox drops strange popup windows for much more intuitive in-page dialogs. The latest version of TinyMCE is also showing real creativity in helping users get where they're going without sacrificing the "webishness" of the editing experience. I'm sure that the creative guys over at 37signals can do even better should they set their minds to it. Sadly, they seem too busy telling paying customers that they're wrong.

Less is not better, better is better. That better may correlate with less some significant percentage of the time is in no way causal.

SitePen Gets A Blog

Hot in the heels of my former employer (Jot) reviving their blog from the dumpster of disuse and market-speak crap, we've set up a new blog for SitePen.

I'm lucky to be working with some great people on stuff we care deeply about. From DHTML UI tricks to keeping the web an open, neutral platform, SitePen has a lot to say. Obviously with just one intro post, it's hard to justify to adding it to your RSS reader just yet, but give us a couple of weeks. I think you'll be glad you did.

Getting Past "Wiki"

While i've been in Portland for OSCON, the world of wikis has exploded in a wash of product announcements from Jot, SocialText and MindTouch. Today I had a chance to meet the MindTouch folks on the exhibit floor of the convention, and when I saw their UI I realized right away that they grok what Jot has been preaching since day one: users don't give a flying fsck about wiki markup. In fact, they don't care in the slightest that it's a wiki.

WYSIWYG in wikis, when done right, is a great example of how a brittle and unforgiving system (wiki markup) yeilds to one that isn't as accurate but is more right more of the time. Systems that work harder to meet users halfway have a better chance of success when exposed to real people. Systems that provide a gray area like this provide room for progress since they allow things to evolve around them without the consent of the "carrying" format.

But the applied consequences of Moore's Law only buy you opportunity if you grok them and even if you do, you still have to execute. Jot's new UI concept, "page types", finally gives end users a way to take practical advantage of the way Jot is architected internally. I've often said that Jot is an app platform cleverly disguised as a wiki, and I'm excited to see some of the camouflage coming off. In the same way that users don't care about wikis, they really couldn't care less that your thinger is an elegant, programmable, semi-structured content repository. They care about getting their work done. By pulling a lot of the products that used to have separate "endpoints" back into the Jot container the new version of Jot should giving users the advantages unified search, simple linking, and easy transformation that the system always provided under the covers. Jot is finally executing against their promise and it's exciting to see.

While Jot goes about mutating the wiki concept into something much more ambitious, MindTouch and Socialtext are re-commoditizing wikiware, but with differing views of who the target user is, what they want, and how they view the point of the wiki in their daily routine. It'll be interesting to see how http Atlassian responds and what the next version of SharePoint means.

Hopefully the newfound infusion of focus on what real people actually care about in a wiki isn't a collective one-off. With Jot and MindTouch pushing hard on improving the user experience, I have a suspicion it won't be.

Older Posts

Newer Posts