I began drafting my final Pastry Box piece, about companies locking in developers and consumers by restricting their choice in a process known euphemistically as “being part of their ecosystem”. This isn’t new; for centuries, royal families and backwoods communities only mated with close blood relatives, because restricting the gene pool is a proven way to promote strength and robustness.
But as I was faffing around drafting, Terence Eden wrote about it, expressing it much better than I did, so I leave him to express my final thought of the year:
I just want us all to get along. I want my disparate equipment to talk to each other. I don’t want to live in a house where ever component has to be made by the same company otherwise nothing works correctly. I don’t want to be stuck using a crappy product because they’re the only ones offering service X.
I don’t want toys that only run on your flavour of batteries.
I don’t want to be part of your fucking ecosystem.
Web site performance is in the news. There are conferences, guidelines, even a W3C Working Group. These are valuable, but we need to keep a sense of proportion. Of course, reduce the number of HTTP requests your site makes and crush your images, but work out where the biggest bang for your buck is likely to come from.
In situations where networks are really slow, or devices under-powered, spending time testing sites across mobile browsers, and focussing on the user’s needs rather than bloating sites with organisational vanity publishing should be your priority.
On standards and sausages
In any industry, standards are vital, and the Web industry is no different.
After the dark days of the browser Wars, in which Microsoft and Netscape competed on adding ever more proprietary whizz-bangs to lock developers in – ahem, more deeply engage developers into their eco-systems, I mean – we’re in an age when all browser and tool vendors compete to tell you how great their standards support is. And this is A Good Thing™.
As Bismarck never said “Laws are like sausages. You should never see them being made” and the same is true of standards. There are many ways to make a standard – some more palatable than others.
Others are retrospectively standardised at the end of their evolution from proprietary whizzbang to defacto standard to real standard. Examples of this are some of Microsoft’s best gifts to the Web: XMLHttpRequest (XHR) which powers almost all Ajax-driven sites, innerHTML and contentEditable.
Another example, this time from Apple, is <canvas> – invented for Apple’s dashboard widgets, liked by everyone and so reverse-engineered and improved by Mozilla, reverse-engineered and implemented by Opera, reverse-engineered and specified by Ian Hickson as part of the HTML5 effort. When Microsoft wanted to implement it, they didn’t have to waste hundreds or thousands of man-hours reverse engineering, with its stupid waste of time and potential to introduce interoperability-damaging bugs: they just picked up the spec and implemented what it said.
But as the editor of HTML5, Ian Hickson, said of <canvas>, “The real solution is to bring these proposals to the table, get some consensus between the relevant vendors and other interested parties, and then use that.”
The best kind of standards process involves as many competitor stakeholders as possible going completely crazy:
- sharing ideas
- trying out ideas in their own labs and sharing results
- discussing openly
- compromising where necessary to achieve concensus
- implementing what has been specified.
This is how the HTML5 effort has worked. Anne van Kesteren described it:
We developed HTML in the open, taking input from anyone, and pretty much from anywhere (mostly tracking blogs back in the day). Until that point HTML was by and large developed by a committee in private meetings.
But the collegiate, co-operative, productive working environment that bloomed so encouragingly seems to be withering.
More and more, we see different companies seeking to solve similar problems secretly, and without discussion. This is why we have many formats for packaged/installable Web applications. Of course, each company promises that it will eventually standardise its solution to the problem, leading to a proliferation of “standards”.
Trying stuff out (perhaps with vendor prefixes) and reporting back is a vital part if standardisation. But presenting whole new features as a fait accompli, and encouraging their use by developers on the open Web loses discussion, the sharing of ideas and results from the process. The end-result loses ease for developers and, ultimately, interoperability for consumers – you know, the great unwashed that we actually make Websites for.
Tossing a specification that you’ve written in-house, in secret and already implemented onto a table at W3C, saying “here, standardise this” as you saunter past isn’t a Get Out of Jail Free card for proprietary misdemeanours. And it isn’t standardisation.
I once gave a talk on developing web standards-based mobile apps. A native coder in the audience asked me “How can I protect my source code? ”
“You can’t”, I replied. He was horrified. I don’t know who was more surprised: him, because of my answer, or me because of his reaction to it.
Every desktop browser has included a view-source option, which is odd when you think about it: you cannot view the source of a PDF or a Word document.
The Web has thrived on people viewing source, copying and pasting, then tweaking until they get the page they want. Any number of free scripts (of varying quality) can be found to make Tinkerbell fairies follow your mouse pointer. Freely available shivs and polyfills abound. Great people (like many of those who write for Pastry Box) spend hours of their own time blogging tips and tricks that in other communities might remain jealously guarded competitive advantages.
So the next time you hit upon a clever technique, blog about it. Or if you write some code that could be useful to someone else, put it on Github. Put something back into the community.
My kids are sometimes confused when using the Web to do their homework, as sometimes (often!) two sites will disagree or have conflicting “facts”. It’s a good lesson for them that what we used to call the Information Superhighway is really a communication superhighway.
It’s good for us to remember that, too, as we finesse our design or finesse our APIs: all the design, all the tech is merely a vehicle for communication. That’s what we’re building.
On a World Wide Web, sometimes your customers come from unexpected places. Let's take the dating web site, Ignighter (now called Step Out) as an example. Set up by a group of New Yorkers, it was founded in 2008 and, after an advertising blitz, by the end of that year had 50,000 registered users in the USA, which wasn't really enough for "critical mass".
In April 2009, the marketing manager noticed that there was a lot of traffic to the site from Singapore, Malaysia, India and South Korea. By June, they had more visitors from India than any other Asian nation. In January 2010, Ignighter made the decision to re-launch itself as an Indian dating site. It gains the same number of Indian users a week as it gained in America in its first year. (Read more about Ignighter.)
If Ignighter had only been coded with single-vendor prefixes and browser-sniffed to work only on iPhones, it probably wouldn't have been able to grow like this, as that's a highly aspirational product in India where it costs many times a professional's monthly salary. But it was a website, capable of being looked at on the feature phones that are so widespread in Asia.
Obviously, there's no guarantee that you'll have similar success if your website works across browsers and across devices. But if your website doesn't, it's pretty much guaranteed that you won't be able to develop a market in the fast-growing economies of India and China, where 40% of the world lives.
The mobile pundits got it right: sites should be minimal, functional, with everything designed to help the user complete a task, and then go. But that doesn't mean that you need to make a separate mobile site from your normal site. If your normal site isn't minimal, functional, with everything designed to help the user complete a task, it's time to rethink your whole site.
And once you've done that, serve it to everyone, whatever the device.
I'm not surprised that companies try to become monopolies or to block open standards. I'm always surprised that developers are happy to let them.
The Web should be consumable by all, but it should also be easy to author. Publishing tools like WordPress enable millions to author sites, and can produce high-quality code, but it's still essential that it's easy to hand-author HTML. Not everything can be simple, but it should be as simple as possible. That's why I support HTML5 - it simplifies authoring by making some previously-scripted effects declarative (form validation, controls for video and audio) and provides simple APIs where previously complex script was required - eg, localstorage APIs.
The Web is about communication. It connects many people who previously were isolated such as those with disabilities or those in oppressive regimes. It's a World-Wide Web, not a Wealthy Western Web. If your super-clever site only works with a mouse and monitor, on the latest $2000 super-spec laptop, with a fat broadband connection, you're missing the point.