Global, local, desktop, mobile
About a million years ago I wrote the web globalisation strategy for a large corporation that included, variously, authoring and production strategy, globalisation, localisation and internationalisation requirements, data architecture, content management platform definition, functional specifications, business requirements, lots of pictures of concentric circles, some arrows, some double-byte character sets, search integration, all sorts of stuff. I mean, I didn’t write all of it. No, actually, I did write all of it. And it was pretty good. But it never happened.
It never happened because the content strategy that supported a ‘write once, publish everywhere’ model was simply too inflexible for stakeholders to sign up to. The idea is perfectly simple. The execution is pretty doable. We could build the platform, we could integrate localisation workflows, we could support content authors with different levels of scope and authority, we could distribute that authoring, we could centralise that authoring, we could mash everything together into a globalised online presence, and Bob would indeed be your uncle.
However, different stakeholders want different things. Different customers want different things. Different users want different things. So, what’s good for the North American goose isn’t necessarily good for the Korean gander. What’s good for the North American buck isn’t necessarily good for the French doe. What’s good for the North American seahorse isn’t necessarily good for the Australian, well, seahorse. And the subtleties of those differences are what led the program to dribble to an apologetic unconclusion. We simply couldn’t define a content strategy that was flexible enough to assemble and distribute a globalised site, based on the centralised, corporate brand and product requirements and the business needs of the content experts and marketeers in the countries. It was easier for the countries to roll their own. So that’s what they did. Using the platform we built to support the central content model. They just created their own instances and copy and pasted the bits they needed from .com, creating silos and duplicates all over the place thankyouverymuch.
It’s that difficulty I witnessed in the global vs. local model that appears to be a central (pun intended) issue with desktop vs. mobile. Well, ok, it’s one of the central issues. I mean, it’s a bit of an issue. IT’S AN ISSUE.
There’s no reason why technically we can’t support the authoring, publishing and distribution of content and services that can provide a coherent experience across all kinds of screens and devices. Responsive design is a method. Having less stuff is a method. Having smaller stuff is probably a method. But for a properly scalable, flexible and efficient operation, it’s just not going to happen unless all stakeholders are in agreement about the content strategy. And when I say stakeholders, I mean anyone who owns, manages, authors or consumes that content. As a content owner, you might not care about comments disappearing from an article when you read it on a smaller viewport. As a commenter, you’ve just been slapped with the wet fish of ‘fuck you’ simply because you’re reading the article on something that fits in your palm. And that’s why content strategy is hard and why rendering isn’t the whole answer.
I’m not proposing a solution, I just see parallels with the globalisation efforts I went through years ago. I don’t think anyone has ever really got globalisation right. I’m not sure anyone will ever really get content strategy for the wider web right. But it is fascinating seeing the component parts evolve that might make it happen.
Jennifer might enjoy this Global Web Programs presentation (PDF 5mb) that talks about the common web platform. Fun times.