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.

Categories:

• greasemonkey
• UserScripts
• LooseCoupling
• BlueSky