Spotted: an HTML Button

"Good god, man... How a person can write so much about HTML buttons fascinates me." - A toli commentator

Per Google, I have an unseemly amount of clout when it comes to the subject of the HTML button born of 9,000 word folktales bemoaning its general under-appreciation and lack of use.

I've always felt guilty that I didn't offer more prescription to the 50-60 searchers who daily come across that piece. Still I thought I was only stating the obvious (albeit at length, and with tongue in cheek).

Thus I was pleased to note yesterday that Google Reader switched from its misguided use of simple hyperlinked text for its "Refresh" and "Mark all as read" functions to now use items that look like html buttons. I won't bemoan their developers not using native html buttons since they've at least recognized that it is best to have clear indicators for potentially unsafe operations. I wonder when Bloglines will follow suit...

I'll echo Phil Ringnalda again:

Making the fire alarm look just like a light switch isn't an example of daring and innovative design, it's just dangerous.

These small usability tweaks add up to broaden the appeal of the web which after all is our great mass participation medium. My rule of thumb in systems design is that we should favour participation over control. I believe this notion extends to user interface design. Giving up full control of the user interface in favour of standards tends to benefit an application because it often meshes with user expectations. There is paradoxical joy to be found in a constrained design space.

A parting sidenote: for the past few months I've been working on the Dojo toolkit, that open source javascript toolkit. At a certain point it was vaguely suggested that I work on form widgets including developing custom buttons. As you might suspect, I immediately demurred and disqualified myself pointing to my paean to html buttons. My position is unchanged: in as much as possible, one should use the built-in browser components and lobby the browser vendors to implement XForms, Web Forms 2.0 or whatever standard can improve the experience of building form applications on the web. HTML forms have been second class citizens for too long yet they are essentially the equivalent of Mary Magdalene and the disciples - the foot soldiers of the web style (digression: Bill de hÓra has been grumbling of late that HTML forms are the original sin of the web). I am pleased to see movement on many fronts these days. Every little bit helps I suppose. Let's celebrate these small things:

Next: The ballad of the link

File under: html, button, design, google, usability, ui, interface, forms, web, standards, technology, Small Things, toli

On Tags in Technorati

In the great tradition of blogging allowing one to cc the world, here's a short email to David Sifry and support@Technorati

• Enhancements to Technorati Tags
• A Technorati Tag Chat

Enhancements to Technorati Tags

Great to see the beginnings of tag aggregation at Technorati in the past few months, the beta UI is even better. It's a great glue layer solution, one that got me to tag the 100 or so posts I've written on my blog. One nitpick: you seem to give undue great prominence to tags that use the technorati.com namespace. From reading the guide to Technorati tags, I had thought that other namespaces using the rel=tag attribute would show up in the aggregation user interface, but they don't seem to, at least not yet... What gives?

In any case, I have a couple of enhancement requests:

For members who have claimed a blog, in addition to the cosmos for a given blog, please provide

1. a list or "tag cloud" of all tags used by that blog (or link to said tag list or cloud)
2. Also for members-only, and for claimed blogs only, I'd like to see the list of tags used for a given post

For example, if I tag my forthcoming post about those parasites that got my blog temporarily consigned to the "Spam Blackhole in Technorati" a couple of months ago with "blackholes, spam, technorati" I should be able to later on navigate and see the list of tags used and not just from my blog but also from technorati.

Ideally the tags should be listed as hyperlinks under the post (ala delicious) but I would settle for a nice new icon like the ubiquitous cosmos icon (great branding by the way). When clicked it would display the tags used.

Bonus points: display the list of tags others have used (extra credit) ranked by authority, or date. Some nice visualization could come into play also if one was to be ambitious to show the evolution of tags used over time. (And I'll buy you some Schnapps or Palm Wine).

I understand that such a feature would decrease performance since it ties the search engine more deeply with the tag aggregation engine. But it is so much nicer and promotes immediacy wouldn't you think? Being able to pivot on tags by simply clicking a link is very satisfying.

Bonus points, allow specification of uri parameters to slice and dice the tags, and blog posts, eg. being able to see all posts tagged with a given tag query. (with an option to specify internal tags and external). Your garden variety RESTful api at work here

I do that with del.icio.us as my poor man's categorization. For example, this is a link to my Cambridge Toli Chronicles

Lastly, and lowest on the totem pole of feature requests, how about some metrics about the tags used per blog. Statistics give some comfort to people. I'd like to know how many tags I've used. I can eyeball my tag list at delicious and figure out that its probably 100-200 or so (I'm so verbose). But I'm a lazy sort, and I believe in the Lazy Web.

A Technorati Tag Chat

P.S. don't you just love that Google has been so delinquent as to give you the opportunity to gain such a headstart not just in blog search but also now in tag aggregation since they don't even provide categories in Blogger. The current situation gives rise to chats like the following from just a few weeks ago:

Koranteng@Toli    did you mean this absurd sequence...< ol>

write a post...

post to blogger....

write tags in delicious (wait a few minutes to better get a sense of what to tag since, if you tag as you write, they aren't useful...

copy tags from delicious and generate technorati tags using technorati tag bookmarklet...

copy said technorati tags and paste in updated post to blogger...

and then if I feel like it (if I want to save it or if it is about to go into a for pay subscriber-only walled garden then furl my post copying keywords and navigating the awful ui for multiple topics therein...[Furl's UI for multiple topics is awful even though it could be easily fixed and I've sent suggestions to their support to no avail]

That's a twilight zone... not quite Orwellian but echoes of Beckett and Waiting for Godot

JJMG    I have started three separate ST topics with you

JJMG    (1) yes the absurd sequence although I thought it was

1. add the technorati tags with the bookmarklet;
2. copy the resulting tags out of the post and post your posting to delicious; I didn't know about furl

JJMG    anyway, I can't believe how ridiculously many steps you have to make to post to your blog with tags

JJMG    you'd think there would be a way to at least tag to delicious and technorati at once, and in fact these two postings imply that you can:

JJMG    but you aren't using their technique

JJMG    your HREFs at the bottom of your postings are all technorati hrefs

JJMG    and then you just HAPPEN to post the same posting to delicious with the same tags

Toli    all because Blogger doesn't implement categories.... I believe that typepad categories now get mapped to technorati tags...

JJMG but those two pages imply that if you use HREFs that point to delicious, then they become technorati tags, but in fact it appears that they do not
JJMG    (there is a rel="tag" thing in there which is supposedly what makes technorati think it's a tag
JJMG    so, for instance, at the bottom of the freshblog's postings

Toli    right but that is just technorati playing favourites in its aggregation ui to things that are 'proper' technorati tags

JJMG    so at the bottom of the freshblog postings, all the hrefs are to http://del.icio.us/jrfj44
JJMG    yours are all to technorati
JJMG    yours actually work, but theirs don't, so I don't know why they document that theirs do
JJMG    when I say yours "work" I mean that you can go to technorati.com/tag/ and you show up
JJMG    when you do, say, technorati.com/tag/how-to, you don't get the freshblog thing in the technorati list, although you can get to it from the delicious list, so I kind of miss the point of what they are documenting in those two pages ...

Toli    they might have but again technorati are the aggregator so they decide what happens... I really hope google buys all of these services up
Toli    yep the spirit of the technorati inital proposal about the rel=tag implied the kind of flexibility but then reality stepped in

JJMG    in fact those two postings I just sent you
JJMG    they say
JJMG    "I just learned that technorati tags do not need to actually link to technorati. This is important because for a while now I've been using delicious as a way to make categories on my blog posts. "
JJMG    simply having the rel="tag" is supposed to make it a "technorati tag"
JJMG    but -- again, the technorati UI doesn't seem to treat it the same way unless it really links TO technorati
JJMG    anyway ...

File under: technology, technorati, tags, bookmarks, del.icio.us, bookmarking, ui, interface, design, feature, social software, software, glue, aggregation, usability, absurd, toli

On GMail and DHTML architecture again

So Jon Udell has been pondering GMail and its architecture on his blog. He's also trying to figure out when to augment DHTML apps with even richer client technology. Below follows what I thought would be a short email that I repeat here for blogospheric conversation's sake.

GMail's architecture is actually very generic for a DHTML app. Everyone with a clue should be trying to leverage the browser and that, in essence, is all they are doing.

I helped implement an analogous architecture in Lotus K-station back in 1999. The major difference now is that everyone is using the "v.5" versions of the browsers; no one cares any longer about Netscape 4.7x.

For me the tipping point for rich DOM/JavaScript applications came when we saw mainstream applications like Hotmail and Yahoo Mail start using DHTML menus. My Yahoo only switched to DHTML menus when it was relaunched a few weeks ago and that's my litmus test for conservatism. (Ironically GMail switched back from DHTML menus to standard HTML selects for its "More actions" and apply label bar a month or so ago - although that might just be from usability testing). A similar event happened in the past year with the way users can rate items in Amazon.com wishlists and also in Netflix without seemingly causing page reloads - you know those five stars.

I mention the spread of all these little DHTML flourishes because I remember back in 2000 spending 3 months and well over 10 heated meetings trying to convince IBM architects to allow the use of simple things like DHTML menus and losing the battle. Of course given that kind of resistance, it was unlikely that features like drag-and-drop which one got from the UI engine in K-station would see the light in WebSphere Portal.

I was arguing that judicious leverage of DHTML could improve the user experience and that it could done while addressing accessibility concerns. Ostensibly the objections were not about usability or consistency but rather about not wanting to write multiple UIs and lack of expertise in DHTML programming. I realized then that the argument was not really about "to-DHTML-or-not" but more about comfort with a repartitioning of one's architecture.

It is riskier to do more on the rich browser client because it has been a more brittle platform over this past decade. Companies that do middleware and server-side tooling take a while to move from their core competency. Architects that thrive in that environment are essentially conservative and for good reason... Four years later, I now hear mutterings about drag-and-drop and richer clients in our corridors...

This only underscores the point that Jakob Nielsen's predictions about browser adoption cycles have turned out to be pretty accurate. Even though web application developers have been quietly spreading unobtrusive javascript usage in the interim, it is only now that there's a critical mass of clients that can leverage them; when Amazon and Yahoo move, something must be happening.

The developer tools and resources have gotten (slightly) better and there's more experience with the DOM. Increased adoption of broadband also helps reduce latency for the average client so you don't have to fight the inevitable arguments about performance and can couch your advocacy in terms of user interaction. In any case if and when you do have the performance discussion you can always argue that caching as close to the client as possible is a good thing and what better cache than the browser itself. It just so happens that applications like GMail, Bloglines and Oddpost are the state of the art in terms of browser leverage.

I recently wrote about this type of architecture in my recounting of the history of the DHTML spreadsheet and presentation components that are the genetic forebears of OddPost.

The idea is to fetch an HTML skeleton, decide what content you need, fetch that (as XML), and cache it wherever you get a chance. Render incrementally.

The pattern is simple: Database <-> XML (Optional) <--> JavaScript Object Bindings <--> UI Bindings (HTML) + UI management code

This pattern works very well for page oriented applications like portals, email, aggregators. You can cache or preload your javascript objects and just manipulate the CSS display or visibility attributes for your UI Bindings.

Incremental rendering and multithreaded loading is the name of the game here. Your application is essentially architected as a hypermedia browser just like the browser and leverages the browser's built in core features, our old favorites: incremental rendering and multithreaded downloading.

The decision about using XML as the data transfer format instead of Javascript objects is a toss-up, trading off client reach and memory. XML support in Safari and Opera is not as baked as MSIE or Mozilla so having JavaScript as your interchange format with your UI engine will buy you increased reach and smaller footprint.

Ultimately though XML will be your backend data format so the temptation will increasingly be to use the various XML-on-the-wire APIs (XMLHTTPRequest). Maybe another 4 years is needed for this pattern to see more widespread usage, JavaScript on the wire suffices for now.

Perhaps K-station was too bleeding edge trying to go for XML over HTTP, DHTML and extreme leverage of the browser client 5 years ago but that experience was a great testbed for me and I learned lots of lessons about building rich REST-ful applications, the importance of URIs etc.

Again the major missing feature for this rich web application platform is offline usage and synchronization without introducing new security holes in the browser. But then that's why Bosworth is at Google as the rumour goes, right? I suspect he's got other things in mind though...

I would note that the Mozilla folks know that the offline capabilities in their platform are a bust so I'd expect some eyes on this. Look also at applications like FormsPlayer for innovation in this space or anyone doing forms in general. XForms is my current thing and offline forms are a great feature that users can understand and demos very well; it's also something that the Notes platform does very well. Our old friend, Groove, also does that kind of synchronization well but I'd want that for the web, natively in the browser.

I think that increased leverage of the browser and the DOM is a good thing. It's also a clear trend and for many applications, the browser is good enough. Good enough for Google, good enough for Yahoo, good enough for me.

Sidenote:
One note about memory consumption and pushing things onto the client. There's an end-to-end argument for this notion of pushing intelligence to the endpoints but there is a cost and in this case it's memory consumption. It's mininal but it exists in this case. One lesson I learned was that it's good to use the kind of machines that the average client would be using and consequently I always hoard older machines. I've noticed that with lots of tabbed browsing and increased use of GMail and Bloglines, my four year old Windows ME box (Athlon 900 Mhz 512MB RAM) thrashes memory more often and I've seen more sporadic crashes/freezes with Mozilla. I know this is actually a lagging indicator and that most users are now on Windows 2000 and possibly XP, but it is a pointer to the memory consumption overhead of DHTML apps. All my other machines are fine and I should note that these applications run just as fine on ME as on other platforms in terms of interactivity and all, it is just prolonged use and a piece-of-junk memory and resource subsytem in that excuse for an operating system... My next representative machine is a Win2k box and on that evidence everything is in order even with these highly leveraged applications.

File under: architecture, DHTML, programming, technology, web, javascript, xml, patterns, html, UI, udell, conversation, history, observation, adoption, DOM, scripting, xml, xmlhttp, interaction, IBM, Lotus, K-station, oddpost, yahoo, google, gmail, toli