2006-05-26

The DRM free web and innovation

My recent "blue sky" article on my perceptions of the importance I place in the user script field has received skepticism and optimism alike from peers, through varying channels.

As much of what I write, it wasn't a very focused post, and I got right into the deep specifics, rather than giving an overview perspective from 10,000 feet. I thought I'd try for that tech top-down overview in this post, instead.

The web is one of the precious online environments which in itself is still DRM free, and I can't place enough importance in that fact. A lock-in free environment, as open standards and data formats go, allowing HTML, CSS and javascript introspection. You can read the source, you can rewire it, and nobody will hit you on the head for doing either. You are actually encouraged to pick up on the tricks of the trade, and there are flourishing online communities available to help you learn, and get going on your own. The web wants you to participate, and opens its doors to user innovation.

User scripting, and end user innovation in general, is reshaping the web, if still only ever so slowly, a trickle here and there by a small clique of us, the übergeek web populace. (I might even reach large parts of that clique with this blog, at just a few hundred subscribers.) We pioneer a field of choice, comfort and preference, as search engines once pioneered a field of findability. Finding a page by typing its URL is about as user friendly as how well adapted the behaviour of a typical web page is to what you want to do with it, and as we could opt out of the former, we can also opt out of the latter.

To me, user scripting is one of the many things that make the web better than, say, PDF or Flash media. One of the many degrees of freedom that are opening up to end users. A gradual shift of control back towards users. Blurring formerly very strict areas of influence, much like how the past ten years has seen web pages with comments by others (besides the site owner) become commonplace, where previously a web page was strictly uni-directional medium of publication. Where previously we had a one author per page environment, we now have a multi-author environment. Where layout and functionality was previously at the sole discretion of that one author, now the tools and choices are at your disposal, too.

Uncoupling such decisions from authors and focusing on getting the the signal through for you to consume in any fashion you well please is where the web was aiming from its very earliest days, but we are only starting to get there very recently.

We could compare user scripting with the configurability of text editors. Some people take editors for what they are at face value with default settings, at most changing to theme, color or font settings they are more comfortable with. They learn a small feature set that allows them to do what they need, not wasting any time to climb the learning curve any further. Others practically meld with their editor of choice, even making it a well integrated part of their lives; socially and otherwise.

I find myself in this category of people, in a web context. At present, it's mostly new levels of freedom for us hard core geeks, though the tools or shortcuts we invent can be applied with ease by anyone who comes across them in our wake. Sharing this has become a lot easier the past year.

I see the web edging closer to this thriving environment of choice, as browsers have recently started to skew in the same direction. Lowering barriers to get your hands dirty, and actually participate in the look, feel, shape and workings of the web we tread. I love this trend. It is a key trait worth guarding closely and inviting more people to. Some browsers, like Flock, are about remixing the web at their very core, responding directly to use case scenarios like "I want to share my pictures with my friends, and subscribe to theirs", remixing in chrome what user scripts remix in the HTML layer itself.

At present, it's just a few devs and savvy gourmets of the technorati that play with this, but that is natural. While the tech itself is already mature in many respects, the community following around it is still picking up momentum. It's not yet trivial to harness user scripting as a typical J. Random User, but will get easier.

The key thing about user scripting is that we never have to stand in line in any feature request queues just to flex our ideas on how to reshape environments we did not make ourselves. Given some knowledge of the workings of the document object model, javascript and the user script environment, we can adapt any web page, without any help, affiliation or other relation to the page publisher. The power of openness, freedom of choice, and the lack of DRM.

I believe in a strong future for any medium that embraces end-user changes. The web has this trait, and this makes it so much more important and full of possibilities and life than any other media I can think of, save perhaps the physical world around us. That is the kind of heritage I think we should be proud of leaving for those who come after us. A puppy we can keep teaching new tricks, and revel in both doing so and in harvesting the benefits we gain with every new step we take along the way.
Categories:

2006-05-25

Pimp my site

Picture some community site where you hang out socially, talk to people in the open, or by mail, perhaps keep up with personal diaries or play some web game together -- that sort of thing. Any will do, be it MySpace, LiveJournal, The Kingdom of Loathing, Flickr, DeviantArt, some dating site or whatnot.

Most likely, being the savvy netizen you are, aware of the pros and cons of at least a handful of communities all over, there are are a few things you are less than happy about with this particular community, be it the cluttered visual layout, badly picked coloring or graphics, a cumbersome structural layout, enforcing several more clicks to get from A to B than you would prefer, a shortage of omnipresent indicators of new messages, or similar. Maybe you are even so used to the status quo, that it no longer bugs you.

This is today's norm of and on the web, whether you slap on a 2.0 tag on it or not.

Some sites do a really good job of keeping things minimal, readable, accessible, well organized and generally beautiful; 37Signals for instance, usually delivers seriously usable web sites it's a pleasure using. Most community sites are not, however. Some of the biggest are downright hideous beasts. Painful sights! Annoyingly cumbersome. Backwards. The kind of thing that makes you want to rip them apart, strip them to the bone and refurnish the whole shebang from scratch.

And lo and behold, with just the one tool of magic, it's actually possible too: enter the user script.

By now, anyone who has followed this client side javascript applications blog or been running Greasemonkey for a while from the comfort of their Firefox browser, should be aware of just how simple it is to toss up a user script to tweak some little aspect of a web page; add some missing functionality here, drop an ad <div> tag there, fix a favicon, short-circuit some links, and similar. A few lines of code here, a little touch there.

"I want things my way!"


In all, it is a bit like configuration options for the web, as a whole. The user script is all about controlling your environment, having things your way, whichever way that might be, and about being able to easily share it with others. Being in control of their environment makes people happier. Stylish, similarly, does the same thing for user CSS, though without doing quite as much for the easy sharing bit (so many, like Jasper, use user scripts for doing CSS only fixes like that, too).

Scraping off the mold


Most community sites that keep reminding me of their shortcomings, in the face of what other places show up, have not changed much the past five or ten years. Their look and feel remains just what it always was. Dead code and markup, though, as sites, still as vividly full of human life and critical matter as ever, hence keeping its leash on still growing user bases -- despite the flaws that once worked their way in there and were left unfixed, to rot in blissful peace.

As a somewhat impatient client side hacker, I'm growing ever more weary of those functionally, visually and aesthetically challenged web sites I use, where I know all to well that there will hardly ever come a site revamp, lest I give pigs wings or devise ways of adding Thursdays to the week. On the other hand, nothing stops me from making that site revamp on my own. I'm still shaping and exploring the idea.

Refurnishing


The recipe is about the same as designing and rendering a community site from scratch, but with a few twists:

  • we have a fix server side feature set,
  • we have a live and fully populated site from day one,
  • we start out with a large user base,
  • and we can perform any changes to the live system without ever affecting any of them
So basically, what's left to us to do boils down to:

  • deciding on a (server side) feature subset of present features,
  • mapping out said subset server side for attaching to it,
  • performing the visual and interaction design for our pimped version,
  • and assembling it, atop the server side plumbing
With Kingdom of Loathing, I did most of the above before the age of the user script, save actually replacing the original plumbing; I stuck to injecting alternate ways of interacting with the server side machinery. What made this viable at all for a bookmarklet in the first place was the site frameset, where you could keep browser state even across pageloads. With a user script, you either:

  • opt to keep client side state by way of provisions like GreaseMonkey's GM_setValue() and GM_getValue(),
  • make the entire site a one-page application, resorting to xmlhttprequest for all site round-trips,
  • add a frameset of your own,
  • or settle for some combination of all of the above
Let's say we end up with a generic, perhaps a bit large, feature set such as this:

  • personal bio:s,
  • public (guest-book style) messaging,
  • private (mail style) messaging,
  • friend lists,
  • publishing (bios, text, art, music),
  • browsing (reading, viewing, listening to),
  • search,
  • subscriptions,
  • and live notification of news (subscribed data and messages)
For practical purposes, I believe the ideal mold would be a mix with a frameset for keeping the live notification page, and then rewriting the rest of the pages on the fly on load time, maintaining the URL namespace (subset) intact, where your design adheres to the same content structuring (but not necessarily visual form) and adding made-up pages of your own in uncharted URL namespace (rendering page not found errors you siulently replace with wanted content) for those that do not.

Alternatively (and probably better), your pages synthesizing (via xmlhttprequest) site bits that were structurally apart on the original site, can be modeled on some small page using the URL fragment (never seen server side) for your needed additional name space. For instance, assuming there was no notification administration page, you might pick the tiny /about/ page (to save the poor server from rendering you a 404 or something potentially lengthy) and render different pages of your own for /about/#subscriptions and /about/#messaging instead of giving them URLs like /subscriptions/ and /messaging/.

Conclusion


This kind of extreme client side orchestration can, if you want to, span and mash up multiple sites with one another, much like how the 43* sites (43things, 43places, 43people...) do, but irrespective of prior affiliation. Theoretically, you could make one mother of all meta site, feeding off multiple community backends, all at once. A community version of a feed reader, aggregating environments instead of feeds.

This is all very blue sky, but on a broader scale, I think it makes sense, and hope it might be what parts of the web are slowly moving towards. The web, as a publishing medium, just isn't as interesting as the web as a services medium, where we introduce loose coupling between service provider and service rendition, affording end users a greater amount of control of their online environment and experience. Monopolizing control over user interfaces leads to the same kind of stagnant environment where the few giants in control of the large amounts of users don't continuously evolve because development costs them money. That is neither good for them nor their user base.

User script technology is a vital force that can help uncouple the web even more than it has been to date, lowering contribution and innovation thresholds for people who know better than the big guys what they actually want, and how they want it served.

2006-05-22

A trip to the US

I'll be visiting San Francisco May 30 through June 4, talking to people, seeing Jesse Andrews, perhaps bits of the neighbourhood, and most likely taking part in some local hackery while at it; that kind of thing.

If you are in the region and would want to have a chat with me, this would be a good chance to. It's my first trip across the Atlantic, and I am presently busy picking out some good reading to spend the 14-hour flight plus transit, thinking up things to bring and not to.
Categories: