2008-02-21

Reducing user scripts to atoms

Over the past few weeks, I have found myself to prod ever more frequently at two user scripts; a UI reducing one and a UI extending one. Both @include the entire web, but are tailored to sites individually on a site by site basis, as I realize that I miss either feature somewhere, and add it, for my own comfort -- some cruft I rarely want to see here, some action I want bound to a key there.

It was only a question of time, and I just hit that tell-tale moment where these two growing (yet, due to factoring it down into convention based descriptive more than programmatic notation, still fairly maintainable) beasts want to marry one another and finally gain independent sentient thought and a soul, uhm, augment features of one another to become greater than the sum of their respective parts.

I'll be back to that in a moment, after summarizing how they came to be and what they do. Each started on the premise of recognizing an improvement I would like to see for web sites mostly everywhere, that would entail approximately the same code for any site I wanted to apply it on, but with minute changes to parameters.

In the first case it was the all-too-popular tendency on the web (if, however, probably mostly also equally unintentional) -- of giving gratuitous focus to visitor voices, at the expense of my taking in the author voice -- that is less popular with me. A few swift DOM cuts, and the excess commentary is folded away.

In the second case, it was recognizing what a great improvement in usability changing web pages to offer comfortable keyboard commands, and more so, comfortable standardized keyboard commands, that I could pick myself, but would work on lots of web sites that I use in a similar fashion. (More on that after this hyperbole. :-)

A few years ago, I was wary of web comics, mostly because I read them seldom and would never remember where I trailed off last time, so I could continue from there, yet I neither wanted to reread lots of them to find my bookmark (and browser bookmarks were too much labour overhead), or miss a strip. One early hack was a bookmarklet that would set a cookie to the present url, or, if invoked from the frontpage, go to the url in that cookie. Instant recollection of last location, and a single bookmarklet for any web site. Excellent.

Eventually, I found and had a love affair with Greasemonkey, and it seems in 2006, or perhaps some year earlier, that bookmarklet, too, was too much to keep track of, and I crafted an automated user script to keep track of last-read for me. The main net benefit with crafting hacks like that is often finding the additional features that are so easy to add, yet prove much more valuable than hard to implement. In this case, it was realizing that this little repository keeping track of all comics I read could link them to a little comics ring that would follow me around, always linking to the next in the ring, and specifically the last one I had read, ready to continue traversing. Better still, that way I wouldn't forget those least frequently updated or read comics, as I often would otherwise. Handy!

And when I started assigning keyboard shortcuts to web sites, adding them for comics was another eye opener -- arrow left and right (or j/k) to head backwards and forwards in the archive, "n" for next site in the ring. Instant gratification, all over again. After I fell in love with Questionable Content, I extended that to also include hotkeys to scroll up/down a panel, p/m (for giving that comfy lazy restful right hand resting on m/k/p, to zoom through its bountiful archive in no time flat), and next thing I knew, my spine expected those handy scrolling keys to work on interesting forums too.

If Jon Udell has a thing for overcoming data friction, I guess one of my bigger things is overcoming user interface friction. With the tiny convention based system I crafted, adding a keyboard binding somewhere was just pasting a hostname, deciding on a regexp for what on-site pages to augment, deciding on keys and crafting a quick xpath expression for picking up which link or page entity to click on with that button, or one to slice out which nodes to snap to for the scroll actions. Done in essentially no time at all, for a geek such as myself. Complete comfort, at essentially no time or work investment on my part.

And then it dawned on me. I want that handy scroll-to-the-next-something on all those sites where I taught that first script how to fold comments. And, as I had stylishly also taught that script how to count comments for each site, it already knew how to find each comment node, so with a quick marriage of these scripts, lots of sites would gain that feature in the blink of an eye.

Except I don't really want to do that. It's conceptually wrong; it makes every script that could use a detail of another clump up into big chunks of things to satisfy the exact preferences of me at the expense of other users that only want, say, the hotkey feature, or perhaps only want it for a single site they care about. It would be much, much better if these scripts could cooperate like in a symbiotic biological environment, each script specializing in one thing and doing that well.

It would reduce each script to a small axiom; one script handling the core aspects of registering keyboard listeners that do not interfere with form input, while assigning key bindings to specific page elements or page actions common throughout the web, from a recipe entailing which keys to bind to what features of pages on a specific site. One script handling the logic of folding entities of some sort, given recipes for the same thing. Lots of little dumb work drone scripts that handle recognizing and marking up page features for other scripts -- comments on this page are here, a link to the next, previous and index pages of this site are here. For the latter, there is even a meta tag microformat which good browsers like Opera handle natively, so these scripts, when possible, should decorate the page with that microformat so other entities which consume the microformat get it for free. And so on; one script to connect microformat with keyboard shortcuts, one to connect comments with folding functionality.

That way, we would get specialization, and we would get decentralization, as anybody on the web can easily, independently, craft a new recognizer targeting sites they use, and I wouldn't even hear about it; they would post their scripts to userscripts.org, and all the Japanese who frequent that site would pick it up, and we basically have a lovely SOA system right there. Each part can evolve and iterate independently, at landslide speeds, and people would find these scripts by looking for scripts catering their sites, not through looking for keyboard shortcut scripts, which no doubt very few do.

I think this could use some catering in Greasemonkey, though, to tie the components together and help users tie together producer (those tiny custom drones) and consumer (the feature implementing agents) with one another, maybe even associate them with one another visually in the Greasemonkey script manager. Signals in the user script header like @produces and @consumes tags, of some sort, seem like one good way of doing it.

I am not sure of exactly which all this plumbing should do, nor how, but I think that there is a lot of good that would come out of it, just like how all the above evolution of three user scripts has changed my web experience to a very luxorous one, compared by the counterpart of only last year. I had no idea how much I would lavish in neither using the mouse nor arrow keys nor page up/down to do my web navigation, but factor in the amount of time you spend with those tools, and it should be quite apparent to anyone.

Your thoughts and ideas are welcome, especially if you blog them after noodling on it for a while; I think we deal in largish ideas that fit the comments field below less than well. Especially as my own site, too, so far, still suffers the "comments dwarf original posts" syndrome when subjected to great visitor attention.
blog comments powered by Disqus