Google Wave – worst adoption model in web history?

Have you ever been invited to a party, only to find you’re the only person there, apart from the geeky fellow that invited you? No?

Then you’ve never used Google Wave.

For all the genius that exists at the googleplex, you have to wonder what the marketing department was thinking. Metcalfe’s law states that the value of a telecommunications network is proportional to the square of the number of connected users of the system. Put another way, if you’re the only person in the world with a telephone, it’s completely effin’ useless.

So, let’s say you’ve just invented the telephone and you’re trying to market it. My guess is that your not going to restrict sales of your new invention to a select group of friends who receive the opportunity to buy it by special invitation, like it’s a Coco Chanel dress or the Vermeer you’ve just had stolen from the Met. The reason you wouldn’t do that is because – as we’ve already noted – its value is proportional to its ubiquity.

Yet that’s exactly what google are doing.

Here’s what happens. One day you receive an invite to use Google Wave. You create an account and login. At that point, presuming you can invest the energy to figure out what the hell it is you’re looking at, you gamely click on ‘New Wave’ and attempt to send a message to someone you know. But you can only send it to one of your Google Wave contacts. And the only Google Wave contact you have is the person that invited you.

Exhibit A

Let’s hope you like them. Let’s say you do. You send them a message.

But unless they log into Wave, they’ll never know it. As far as I can tell, Wave won’t ping other systems to inform you that something’s arrived. So it becomes just another system you don’t log into and soon thereafter, forget about entirely.

Of course it’s entirely possible that some of your other friends are already on Google Wave. Unfortunately, there’s no way to find that out either, unless they happen to mention it to you over canapés at the club. Which they probably won’t, since they just had the same experience as you: invited – logged in – perplexed – frustrated – never returned.

The sad thing is, Google Wave rocks. At a technology level it’s an ideal remedy for rambling, circuitous group email discussions, old school threaded news groups (usenet) etc. By providing the capacity to interact with existing content (inline, attributed commenting), those impossible to analyze ten-thousand line email threads that repeat every message every time, with chevrons galore, are a thing of the past, replaced with neat, maintainable nuggets of knowledge.

But for this to be realized, two things will have to happen:

1. google need to drop the walled garden and accept that Wave will have to live in parallel with other messaging systems (e.g. existing corporate and personal email, and RSS and twitter streams too) for some considerable time to come.

2. invitations must die, to be replaced with a facebook-style “invite anyone you like from your address book” approach.

Further Reading

• The Adoption Struggle of Google Wave
• Google Wave: Likes and Dislikes

No, you don’t want a rockstar

Here’s an actual job ad I saw on Craigslist this week. Not that I’m looking, of course.

Taken literally, let’s ponder for a minute the pool of candidates for this position. Maybe that bloke off last season’s American Idol. Or possibly Brandon Flowers from the most inexplicably popular band of recent years, The Killers.

In actuality, what they’re looking for is a mac monkey with excellent HTML and CSS and reasonable JavaScript. And, granted, I’m speculating at this point, but I’m going to hazard a guess that they would like someone to show up on time, work forty hours plus a week, consistently meet deadlines, be reliable, stay sober etc. You know, the typical contractual obligations that “the man” has put in place to suppress our humanity and naturally creative spirits.

Would you like this man to be responsible for the cross-browser and section 508 compliance of your web presence? No, of course you wouldn't.

And, again, I’m going out on a limb now, but what they probably don’t want is someone who occasionally drops by the office on the way to their connection, vomits over their keyboard, bangs underage groupees on the boardroom table and then throws their monitor out of the window in a fit of artistic pique should anyone object to their creative and inspirational wireframe mockups.

How the term rockstar became synonymous with being great at one’s job, rather than simply being great at one job, namely playing rock music, is a mystery to me. Perhaps it’s just a sad attempt to glamorise IT, admittedly a sphere of human endeavour considerably less sexy than pig farming. But the term “Rockstar Developer” isn’t just oxymoronic, it’s moronic.

Don’t get me started on Ninja.

Web Team Organization Part 1 – Management

Back in 1996 it was quite possible for a single individual to maintain a site just as hideous as a myspace page all on their own! Plus ça change, plus c'est la même chose...

Back in the day (c. 1996), a website was managed in all its animated gif and <blink> tagged glory by a single individual, a “webmaster”, an awkward term somewhat too close to “dungeon master” IMHO, though derived from the established role of “postmaster” – the individual nominally responsible for a domain’s email. Webmasters did everything: server configuration, information architecture (such as it was), content markup (if not the actual writing) and design (again, such as it was at the time, or, if you need a refresher, what myspace looks like today) .

Then sometime in 1997 the web began to attract a handful of users that weren’t unix sysadmins and physicists, which meant (according to marketing) that it had to look gorgeous. So design was outsourced to, umm, designers and webmasters now had to learn a new skill, “front end development”, which is a euphemism for converting someone’s quixotic artistic vision into code and ensuring that when that code is converted back into pictures on any device, anywhere in the world, 24/7 (as we used to say in 1997), it bears at least a passing resemblance to the aforementioned vision.

Then in 1998 the chaps in marketing realized that it wasn’t enough just to have a web site – people had to be able to find it too – and not just via the flyers they’d just printed 90 000 copies of with a URL that doesn’t even exist and you may not even own. Which added Search Engine Optimization to the necessary skills inventory.

Content Management Systems, like the heartbreakingly beautiful drupal (pictured above), theoretically make it slightly less arduous to manage large quantities of quality content. And should anyone ever create a large quantity of quality content, we'll actually find out!

Meanwhile those marketing folks were dreaming up considerably more ambitious web sites, filled to the brim with content that they would never actually get around to writing or updating. But just in case they ever would, we moved away from building sets of HTML files with the odd server-side include for navigation, and determined instead to serve content dynamically from databases via a new type of software called a Content Management System. And this meant that the humble webmaster also had to be a software engineer and database administrator, if they weren’t already.

By now it’s the year 2000, and it had dawned on most medium to large scale organizations that one person can’t do all this. So farewell, jack-of-all-trades webmaster. Or not so much farewell, as “welcome to management.”

Since that time a whole new generation of professionals has entered the business, often as specialists, never once having had to either reboot a server or sub-edit an article (let alone optimize a gif using the “web-safe” palette or convince a manager not to use frames). I think they missed out.

In any case, the role of web manager is still vital. I know this because not all of the websites under my, umm, aegis, currently have real managers (at least, not as I understand the term), and they are much the worse for it. Sure, they may have an ‘Executive Producer’ or a ‘Project Manager’ or a ‘Lead Developer’ and indeed any number of people with one or more fingers in the pie. Ultimately, however, if you want a site to be successful, you need to give an individual full responsibility and authority for it – an individual with a broad appreciation of the principles of web design and who will love the site like a child of their own flesh.

So begins a short series of articles on web team organization, starting at the top with my definition of a web manager and how to spot one…

Let’s begin with my four prerequisites for hiring anyone to do anything. Articulating the baseline will allow us to bypass the obvious and focus on specifics. Thus, any individual I hire needs to…

1. be intelligent.

2. get stuff done.

3. give a monkey’s.

4. play well with others.

As an aside, giving someone full responsibility for a particular website tends to help with #3, as one’s chances of getting hired anywhere else will be severely limited if the website that’s on your business card and in your job title is a complete shambles.

In any case, all of the above is necessary but not sufficient to ensure success in web management. You’ll also need…

1. Superb development or process management skills.
Websites are software, software is technical, and if you’re not then you will forever be at the mercy of those who are, which is not a great position for a manager to be in. Developers, struggling to articulate in non-technical language the operational complexity of your ask, will simply tell you that it can’t be done, or will take nine months, and you will not be able to call them on it. Or you may in turn get frustrated and tell them to “just do it… in two weeks” – and they’ll go off and do it badly, ignoring dependency x or contingency y and it’ll come back to bite you.

So my primary advice is to hire a manager who can code.

That said, a good alternative would be someone who is technically adept and an excellent process manager. It takes a more structured management approach to stay on top of things this way, and communication with the development team will absorb more cycles, but a good Project Manager can manage a website without learning python/ruby/C#/whatever.

What’s my criteria for ‘technically adept’? Able to organize information in MS Excel and use whatever CMS you’ve adopted to its fullest ability without any hand-holding.

2. Web Design 101: Information Architecture, Usability, Search Engine Optimization, Email Marketing, the Law…
There are principles of good web design, and if you do not know what they are, you will make bad decisions. It’s not enough that your content is great (if indeed your content is great), it needs to be written/shot/edited for the web, it needs to be tagged / filed / organized so that it can be discovered, either by following clear, semantically distinct links, or via your search engine, or via someone else’s search engine, or via social media syndication. It should follow design conventions, or be very clear why it isn’t, so that your visitors will find it easy to digest or interact with.

Are you collecting user data? Then you’ll need to know about both privacy and freedom of information law. Are you sending out spam? Then you’ll need to know the law on opt-ins and opt-outs, as well as usability lore on email marketing. Do you care about differently abled site users, or are you designing for a government site? Then you’ll need to know about Section 508 (US), or the Disabilities Discrimination Act (UK) and ensure that your site meets W3C accessibility standards. Etc.

It’s not that any of this stuff is rocket science. It isn’t, and presuming you fit employment criteria #1 above, you could probably get up to speed in just a few months with some dedicated effort.

You cannot presume, however, that any of this is innate or intuitive and that someone coming from a different field or with a particular specialty will simply have absorbed these “soft skills of the web” by osmosis. Every web manager has to know this stuff.

3. Passion for the medium.
This is almost a restatement of employment criteria #3, but any web manager needs to be excited enough about their work that they stay current and remain alert to the potential of the medium. You need to get the feeling that they would be completely immersed in this stuff even if they weren’t being paid. They use the web to organize a significant portion of their daily life, they follow mashable etc, they try things out, they’re either on the bandwagon or they know why they’re not. All of this assists them in knowing the art of the possible in a world that changes every week.

4. Excellent communication skills.
Almost no other role has greater touch within an organization than that of web manager. Even if a colleague has no direct role in producing the site, they will use it, or they’ll be referring people to it, and they’ll have an opinion about it. The web management role touches directly on IT, Marketing, Sales and Corporate Communications, and often beyond the organisation with technology partners, major accounts and other stakeholders. And then there’s your own team of developers, creatives and editorial staff whose own worlds seem mutually impenetrable. In short, much communication is required to draw all these elements together into something approaching a coherent whole, whilst keeping everyone more-or-less happy about it. It’s not enough for a web manager to be able to talk strategy with the boss and code with the developer – they need to be able to effortlessly communicate across these two worlds, and all the others too.

5. Leadership, Responsibility, Authority and an Inclusive Approach
Beyond the specific traits of the individual given the role, it’s vital that the organization invests both responsibility and authority for the site in that individual. Unfortunately it’s all too common for the person who has the fullest appreciation of the site, its abilities and potential, and who loves the site and cares about its quality more than anyone else, to be countermanded / over-ruled / ignored / told what to do by someone with greater authority but whose perspective is severely limited by their specific focus or area of professional responsibility. The consequences of such arrangements are poorer websites and demoralized staff.

So your web manager will require leadership skills – to articulate a vision, to make decisions and to hold the line. Which isn’t to say that the web manager is the boss of everything – just that they are best placed to maintain a holistic view of the site and implement the corporate strategy from that perspective. They’ll also need the humility to realise that they are not necessarily the best copy writer, graphic designer etc in the group, and be more than happy to step out of the way and let the subject experts in the team make the calls – all other things being equal, that is. Don’t get me started on ’rounded corners’.

Further Reading

• There a synergy between my definition of a web manager and Joel Spolsky’s definition of the product manager role on software teams.

Drupal – and the modules that aren’t

This is all we had back in the day. And it's all we needed.

In the spring of 1978, I spent a lot of time with Lego. 1970s Lego, for those of you that have forgotten or weren’t yet born, was a relatively simple affair, and as such was both better and worse than its modern counterpart.

It was worse in that the final products were less photorealistic analogues of the objects they were built to represent. That was OK, because back in the 1970s children possessed a faculty known as imagination.

In every other respect it was better, and it was better because it was composed of just a few simple pieces. With the exception of a handful of modish specimens which were (quite rightly) considered a bit thin-end-of-the-wedge by purists, bricks were largely of the 4 or 8 dot variety and white, red, blue, yellow or black. Despite this apparent limitation, children such as myself found it relatively straightforward to fashion any number of (albeit rough-hewn) laser pistols, dinosaurs, houses, cars, aeroplanes, animals, swords and so forth from these parts, using our aforementioned faculty.

Its simplicity made it infinitely more flexible; it also encouraged creativity and problem-solving, which I think was the point.

Blackbeard. Try making a laser pistol with this.

These days, Lego kits are like Airfix models. You can follow the instructions very carefully to build an amazing looking pirate ship / uss enterprise / batmobile. Or you can throw away the instructions and build something that looks crap, because what else can you do with a Jolly Roger, a little man with an eyepatch, a photon torpedo and a headlight? Answers on a postcard, please.

Now where was I going with this? Oh yes, that’s right: it’s an analogy. If a good module is an old school Lego brick, a bad module is a Lego Blackbeard.

When people proclaim the success of drupal by referencing the volume of modules in its library, they neglect the fact that it contains about 50 bricks and around 5,000 assorted Blackbeards.

There are good reasons for this.

For a start, there are two “rules of three” in software engineering. One states that it is three times as difficult to build a resusable component as a single-use component. The other states that a reusable component needs to be tried in three different applications before it is general enough to become a library component.

LoginToboggan, anyone?

But most drupalers – and most developers, for that matter – are not especially interested in writing reusable components. They are interested in writing components full stop, and will only consider abstraction and reusabilty when it dawns upon them that they are about to write the same code again in another context. And then they think: while that would be the right thing to do, I really just have to get this thing done today, and besides that other code’s already shipped, and so instead I’ll just copy-and-paste and change the variable names and make it home in time for Dollhouse.

Even if the developers are good boys and girls and want to do the right thing, they probably find themselves sneaking in a bit of refactoring when the boss isn’t looking, ’cause the boss is generally more focused on the fact that the whole project should have shipped yesterday and could you just “make it work” if you’d be so kind?

Beyond this, even with the best will in the world and a zen-like mastery of “the drupal way”, the breadth of drupal is such that omissions of logic are inevitable. That someone’s module doesn’t play nice with domain access or i18n is as forgivable as it is frustrating for anyone who gamely retains a ‘plug and play’ attitude towards drupal’s bold but fallible modularity.

So, things being what they are, an awful lot of modules are not designed with reusability in mind and are contributed in that state – fantastic at solving one particular problem well, but not especially adaptable. They are Blackbeard, if you will. Except for the buggy ones. Those are more like a Blackbeard that your little sister has chewed on, perhaps swallowing an arm.

This begets another problem, which is that the library is bloated with a lot of not particularly modular modules, and you can waste a lot of time playing around with them before you realize you’d be better off starting from scratch (incidentally making this a circular problem). This is due to another law of software engineering, namely that modification of reused code is particularly error-prone, and if more than 20-25% needs revision, it is more efficient and effective to start again.

I know that’s an ugly truth, somewhat antithetical to the spirit of open source, but truth it is. Besides, every developer knows that it’s easier and a lot more fun to write new code rather than analyze and fix/enhance somebody else’s mess. That’s why they call themselves developers and not maintainers / enhancers / fixers etc.

And so it goes on, with some notable exceptions, some of which will one day find themselves in core.

There’s an alternative to rewriting modules from scratch, of course. You can simply take them “as is” and live with (or workaround) the fact that they’re not exactly what the spec asked for, but they are at least going to save you a week of work. And that’s a fairly easy sell when management only scheduled half as many weeks to complete the project as it would take Dr Manhattan to write it. It’s the kind of mediocrity that satisfies no-one, but is suffered in the interests of pragmatism. In other words, it’s soul destroying.

Well, there you have it… and the fact that the phenomena is explicable doesn’t make it any less annoying.

Drupal – Not for Muggles

It's drupal "out of the box". Only better organized.

Light travels very quickly indeed. At the same time, the universe’s maximum speed limit is still frustratingly slow for anyone actively considering interstellar travel.

It’s all relative, isn’t it?

Considering what drupal does, considering what’s actually going on under the hood (not to mention the materials from which the engine is honed), it’s really very fast indeed. At the same time, if you stop considering that, and instead just start clicking your way around a reasonably sized drupal website, you’ll have time enough to update your facebook status and twitter your breakfast du jour while you wait for the search results to display.

There are workarounds, of course. For example, you could decrease front-end load times by distributing key assets via a CDN, enable APC on your server, look into MySQL 5 query caching or use the filesystem to cache static versions of pages. And so forth. Host willing.

Any of that sound straightforward to you? If so, you are a geek, congratulations. If not, that’s a shame; especially as you’re the kind of person drupal is opening its hypothetical blue arms to viz. “Drupal allows an individual or a community of users to easily publish, manage and organize a wide variety of content”[1] and “anyone willing to invest a little time and effort can learn how to use, setup, configure and maintain a Drupal based web site.”[2]

This then, is my gripe. Drupal is a geek’s CMS, much like linux is a geek’s operating system. That’s just fine, but let’s not pretend otherwise.

In fact Drupal is not a solution, it’s a starting point. It’s lacking in both the usability necessary for direct muggle interaction and the polish necessary to sell it to marketing. Out of the box, it’s about as useful as an IKEA flatpack without the instructions and half the bolts.

We might almost call it middleware; and indeed it is partially self-categorized as a “content management framework.”³ In this regard it has its own pros and cons which I will come to in a later post. The bottom line is that you’re going to need developers – good, creative developers – to build a half-decent online experience from these ill-assorted Lego bricks. And if you have good, creative developers, then you have other options on the table.

Drupal – Uglier than a monkey’s armpit

Garland, drupal's default theme.

Out-of-the-box, drupal is responsible for some of the least attractive websites in existence, and rectifying this matter is a costly and time-consuming proposition.

“Beauty is in the eye of the beholder”, “look and feel are subjective”, “undesign is the new design” – these are the kind of progressive platitudes one pays lip-service to, up to a point. That point would be when you first install drupal and see a website rendered in Garland…. a Pauline epiphany hammered home as you begin manically switching through the core theme set in the hope of finding, oh, I don’t know, a diamond in the rough. Something that, given a little TLC, a little tweak here and there, might be massaged into something you could reasonably present to your boss as “a draft proof of concept” without entailing the risk that she will regurgitate her lunch over your keyboard.

Drupalistas, for reasons we will come to later, are for the most part software geeks, and have been reminded repeatedly by their parents from an early age that looks are not important. In my heart, I know they are right; morally right. At the same time, none of this mushy stuff is going to fly with marketing. Or the corner office.

Perhaps you prefer Marvin?

Not to worry, of course. That’s what designers are for.

And this is where the problems begin. I’m not talking about the usual kind of designer/developer impedence that we’re all used to. You know what I’m referring to – a designer with no grasp whatsoever of usabilty conventions let alone actual front-end development is given the job of redesigning a website. They lock themselves in a warehouse with a giant canvas and begin tipping bright primary colours all over, in the manner of Jackson Pollock, before driving and skidding over said canvas with various farm implements and forms of transporation before finally stripping themselves naked and crawling over their masterpiece so as to become fully at one with their medium. Finally, their work complete, they photograph the canvas, upload it into photoshop and send it you as a PSD. Job done.

No, I’m talking about a more subtle impedence that emerges in those few web / marketing groups that are actually committed to positive collaboration viz.

Or Bluemarine, perhaps? C'est tres joli, n'est pas..? Mais non.

Developer: You’ve put a “see more” link in a block title.
Designer: I’ve done what?
Developer: You’ve put a see more link here, next to the news feed title.
Designer: Yes.
Developer: Well, the “see more” is part of the block body, not the title.
Designer: Oh?
Developer: So you’ll have to move it.
Designer: I think that’s where people will expect to see it.
Developer: You’ll have to move it.
Project Manager: Is there any alternative?
Developer: (looks pained) Well, I suppose I could try and over-ride it in the theming layer… but then, if we ever want to change theme… or when we upgrade… it’s hacky…
Project Manager: (to designer) Can we move it?

Designers sometimes think that Drupal gives you have a bunch of little UI building blocks that you can move around as you wish. This is half-true, but it’s the other half that’ll burn you: the building blocks are actually stuck together and isolated in little piles. In Drupal, you have the node stack which is all the pieces of a node teaser or page but they are all pretty much stuck together. You have the block stack. The view field and view style plugin stack. The form stack. And so on.

Within one of these stacks you have some freedom, but try to move something from inside one to another… Good luck.

- Young Hahn, Limitations of the Drupal Theme Layer

The Public Internet Channel. Looks great! And I think we can all agree that the result was absolutely worth all the time the developers spent hitting their heads repeatedly against the fake pine fascia of their desks

There’s another issue too, and that’s that drupal theming* is an esoteric art form only fully understood by seven people in the world, and all of them are accomplished backend developers. Which is a problem if you like to split off front-end and back-end development roles, and ironic given that the purpose of any templating system is to separate content from presentation. The result is that to be a competent drupal themer you need to have an excellent grasp of HTML, CSS and possibly jQuery, plus drupal development and the quirks of its theming capabilities – and aesthetics. Such people are few and far between and command salaries commensurate with the laws of supply and demand.

This being the case, you will spend a good amount of time and money making sure your drupal site looks nothing like, well, a drupal site.

You will then wonder if it was worth the effort.

A thought that will be later be confirmed when you decide to upgrade to the next major version, whose framing layer will have been completely retooled.

Before you say it, there are a host of reasons why it is thus: the theming layer needs to accomodate a highly modular framework, for example, and the fact that most developers can’t distinguish Klee from Kandinsky.

Ultimately, however, “the man”, “the suits”, the marketing executives and so forth don’t actually care why the site looks crap. They will not be swayed by arguments such as “yes, it looks crap, but the modular framework means that we can add a crap looking poll module tomorrow without even having to touch the theming layer! Probably.” In fact, they just care that the URL on their business cards and resume points to a page that looks like it was designed for colour-blind Romulans, while their kid’s wordpress blog looks, well, pretty good.

Further Reading

• 5 Things Drupal Could Learn From WordPress About Themes
• Limitations of the Drupal Theme Layer

* sic; yes, it’s called theming and not templating. This follows another drupal pattern which is to never use an existing term when a new one will do.

Death by Drupal – An Introduction

Here, drupal weeps. A taste of your own medicine, eh?

To paraphrase Churchill, drupal is the worst possible content management system, apart from all the others.

At some point prior to my arrival at One Economy, a consultant was hired to determine which CMS the corporation should adopt. Some x weeks and y thousand dollars later, the answer was provided. 42. I mean drupal.

Skip forward eighteen months and we are now, to paraphrase Macbeth, in drupal stepp’d in so far, that, should I wade no more, returning were as tedious as go o’er. One Economy currently operates no less than 9 sites and services in drupal, with The Beehive (localized, internationalized and web services integrated) at the bleeding edge and The Public Internet Channel not far behind. For a single organization – rather than an agency – that’s plenty. What we’ve done with this CMS is nothing short of amazing… and yet hardly a day passes when I do not curse its name.

Rewind to 2006. My only previous experience of drupal had been to install it, follow the instructions that appear on the homepage following a succesful install, then wonder what the bloody hell was going on. The system has a prima facie opacity akin to the moai sculptures of Easter Island. My reaction might best have been described as bemusement modulated by impatience, an emotion not in the least bit mollified through discussion with then colleague and drupalista, Katrin (aka nonsie, for those of you in the know)…

Me: Hey, Katrin – you use drupal, right?
Katrin: (wondering where this is leading) Yes…
Me: It’s a CMS, right?
Katrin: Yes.
Me: What can you do with it?
Katrin: Anything you want.
Me: So it’s not just for community sites? [This was 2006]
Katrin: No. Anything you want.
Me: All types of content? Say, our corporate site… we could do our corporate site in drupal?
Katrin: Sure.
Me: OK, well, I’ve just installed it. I’m poking around with it. Only…
Katrin: Yes?
Me: Well, I’ve written an article and I suppose I want to categorise it.
Katrin: You can use menus.
Me: Menus?
Katrin: Or taxonomy.
Me: Taxonomy?
Katrin: Yes, taxonomy. It’s a module. Oh, and you’ll need CCK too.
Me: CCK?
Katrin: Yes, CCK, the Content Construction Kit. It’s a module.
Me: Umm, OK… thanks. Oh, one more thing…
Katrin: Yes?
Me: I’d like to add a photo to my article.
Katrin: Ah. You’ll need image assist possibly, but that depends on imagemodule which creates images as nodes. Or you could use imagefield… Do you have imagemodule?
Me: I don’t know. Do I? What’s a node?
Katrin: Probably not. It’s a contrib module. A node is like a page… Why are you looking at Mambo?

A Balloon Mouse - technically impressive, yet fragile, quixotic and unappealing. Remind you of anything?

And that’s pretty much where I left things until my first day here. To my enormous good fortune, Katrin was hired too… and I’m not entirely sure where we’d be without her. At the same time, it’s a bit like watching a children’s entertainer fashion animals out of balloons, since

• in the hands of anyone else, the balloons are likely to explode, and
• one cannot quite escape the feeling that balloons are neither the most expressive nor the most accessible nor the most flexible nor the most aesthetic of artistic mediums

One of the issues facing IT managers in the position of selecting a CMS is a lack of information pitched at a level between the marketing fluff and insider geek babble; indeed, it’s an issue I whine about constantly at the Internet Strategy Forum, and a gap I intend to address in this next series of articles – a series which will, for me at least, also serve as a kind of cathartic therapy. Drupal is amazing. Truly it is. And, at the same time, it has driven me perilously close to the rocky shores of madness. Here’s why, in seven easy pieces plus a proviso (all coming soon)…

1. it looks awful – or costs a packet
2. it’s not plug and play, unless you’re Stephen Hawking
3. it’s full of non-modular modules
4. maintenance makes me cry
5. the framework is ideosyncratic, the learning curve is steep
6. usability hell – or why you’ll never bypass the webmaster bottleneck
7. the social anthropology of drupal

I’ll then round things off with what there is to love about drupal, despite it’s manifest inadequacies, if only so I’m not lynched at the next drupalcon (see 7, above).

Death by Tweet

The other week I gate-crashed a Social Media Club of Portland planning meeting. I hadn’t been invited, but I like to think that was an oversight. Thoroughly lovely people, although someone did insist I validate my identity via business card, as if perhaps this was rather more a debutante’s ball and rather less an administrative ritual. And then of course the inevitable question, “What’s your twitter handle? So I can follow you…”

I’ll dispense with my etymological objections straight away: ordinary people have neither handles nor followers. Tea-pots have handles, cultists have followers.

Even the term twitter is so intrinsically inane it is already satirical; it stands as a whimsical vision of what people might do in some contrived futuristic, post-capitalist society to pass the time when all other human needs have been satiated (cf. the peerless, childless city of San Francisco). Nevertheless, the insufferably smug founder Nathan Barley Jack Dorsey - tours Baghdad’s Green Zone at the behest of the State Department, iPhone held aloft as might a missionary his scripture, for in this – we are to believe – lies the salvation of democracy. I’m going to go out on a limb here and suggest that the denizens of Baghdad – no thanks to us – are working at a slightly lower plane of Maslow’s Needs Hierarchy than those surfed in the San Francisco Bay. I might even be tempted to put an inoculation or a text book ahead of a twitter short code.

On the other hand, Twitter does provide useful and virtually free ammunition in our phoney war with Iran, hence no doubt the State Department’s interest. But I digress,

At its best, Twitter is an RSS reader for the masses.

Even though RSS stands for Really Simple Syndication, and it’s not rocket science, my dad’s never going to configure an RSS reader to get his news. And he has a doctorate. Setting up a twitter follow is marginally simpler, if only because twitter handles are simpler to remember and communicate verbally than URLs. Also the brevity of tweets makes following an attractive alternative to email signup for those drowning in junk email. If you choose who to follow wisely, twitter has some value.

Still, it remains primarily a medium for middle-aged marketing executives and narcissists.

“In a society supposedly saturated with media messages, information and meaning “implode,” collapsing into meaningless “noise,” pure effect without content or meaning” – Kellner on Baudrillard (1983)

Unbelievably, somebody somewhere has had the twitter fail whale tattooed to their leg.

- yup, that’s about the size of it. The twitterverse is, to me, no other thing than a tsunami of banality, the retweet being the semantic equivalent of the Boss BF-2 super feedback and distortion pedal. Much like the poor chaps at the CIA dedicated to monitoring our phone calls for indicators of sedition, the signal to noise ratio is off the scale.

Pretty much the last thing I need is more data coming at me, more sludge to sift through in the unlikely hope that there be gold in them thar hills. And sludge it is too; search.twitter.com finds me no less than 14 mentions of cornflakes in the last two hours – and it’s not even breakfast time.

Ultimately twitter beyond RSS – twitter for the masses – exists because some people like the sound of their own voice, have too much time on their hands, are resistant to concepts which require more than 140 characters to convey and are naive enough to believe that anyone else out there gives a monkey’s about what they ate for lunch.  Most of them happen to be middle class and middle aged, which is of course twitter’s key demographic.

I say it’s a flash in the pan. And you can all mock me when I’m proved wrong.

Further Reading

• I Hate Twitter [blog]
• I Truly Hate Twitter [blog]
• Twouble with Twitters: SuperNews! [animation]
• Analysis: 40% of Tweets Are Pointless Babble – only 40%?
• Exhibit A – Twitter CEO’s Wife Tweeting While in Labor – words fail me