Infrequently Noted

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

a9 and JS

a9 is yet more evidence that the rules of web interface construction are changing. Based on 36K of JavaScript, the interface is fluid and uses DHTML to effect reload-less state keeping. In essence, the client side does what clients should do: maintain their own damn state. Informing the server for the purpose of keeping preferences intact is one thing, but allowing the client side to handle it on it's own is clearly preferred. The cookie and iframe approach that a9 is using get much, much closer the user expectation mark.

Horray for the user winning.

Where did all the good DHTML geeks go?

I thought San Francisco was supposed to be the place where you could get a good unemployed web geek in any coffee shop...so where'd everyone go?

I know of at least 2 companies that need a top-notch HTML/DHTML geeks in the bay area stat. Send me resumes and I'll see that they get into the right hands. If you've got a URL or an example of work, so much the better.

Anderson's Law

Anderson's law:

Moore's law doesn't imply that applications improve in performance, because programmers are always as lazy as their hardware permits them to be.

OpenVPN

OpenVPN needs an OS X and Windows front-end for client systems and a generally non-sucky configuration interface for systems that are going to act as gateways for road-warrior users. I've gotta think there are a lot of people in the same boat as me who really don't want to be hacking their ifup scripts to change their routes every time your laptop moves to a new network.

I bet you could even charge for code like that.

wikis

The development team that I'm a part of at work uses wikis pretty extensively since we have people that need access at all times of day to information in a central place. The concept works very well for what we do, but the implementation leaves a proverbial ton to be desired.

One of the more interesting panels I attended at SXSW was about wikis and their use in distributed organizations. I kept hearing from the panelists and the audience was that the wiki markup language is awful. Not just kind of bad, not just somewhat obtuse, but nearly unusable for people that just want to get something done. To tell the truth, I'm a geek and even I feel the same way. A good first step (ISTM) would be to allow Textile-style markup in wikis

I have a couple of theories about usable technology (one of them being that any single system that requires a full time admin will be replaced by more usable technology SRTL), and wikis defy my theory that new markup syntaxes should show significant benefit and reduce effort or they aren't worth writing. Does the user derive reusable benefit by learning the Wiki markup language? Does it leverage their existing mental model of how they want the text to appear at the end of the process? Does it make use of existing markup syntaxes they already know? (hint: the answers, in order, are "no", "no", and "no").

The other thing I kept hearing in the talk (and keep hearing around work) is that there are very few sane ways to keep tabs on the structure and activity of a wiki. Many wikis seem to support a "most active" or "most recently updated" list, but very few give any ability to understand the relationship between pages, understand the importance of a page, or change these properties. Given that wikis give a great bi-directional linking language, this seems like a pretty obvious next step as well: navigation via self-organization of content.

A DHTML front end with rich-text editing capability and a sane XML-driven back-end for a Wiki also seem like no-brainers. Content transfer to and from wikis seemed to be another hot-button item that the panelists seemed to just accept because nothing did it right (yet). Oh, and an OODBMS system to make versioning, system modification, and self organization from pages really simple.

Who wants to help write it?