A rant (contains some immoderate language)
Software companies large enough to have responsibilities of stewardship over common aspects of the Web often make inferior technical decisions for no reason than their short-term gain at the expense of long-term benefit to everyone. Usually I let this wash past, I’m acutely aware it’s happening, but I don’t let it derail my thinking or my work. But sometimes — I just can’t help it — something will just piss me right off. Invariably it’s something modest, something that would simplify my life as a software developer, or open a small pocket of creative possibilities; invariably something that’s put to death as part of the collateral damage of a corporate business plan somewhere.
This time it’s the handheld media type for CSS. This harmlessly enumerated value promised to give developers a way to tailor websites for display on handheld devices. It was introduced in the CSS2 specification 13 years ago, with the following straightforward description:
Intended for handheld devices (typically small screen, monochrome, limited bandwidth).
Technology moves quickly and this was subsequently amended to:
Intended for handheld devices (typically small screen, limited bandwidth).
Any rationally minded individual would, I think, agree that any iPhone is by definition a handheld device. One that, whether it’s typical or not, has a small screen and limited bandwidth compared say a desktop or laptop computer, two other device classes that are frequently used to browse the Web.
So why does the Apple iPhone not classify itself as a handheld device? Here’s Apple’s justification:
CSS3 recognizes several media types, including print, handheld, and screen. iOS ignores print and handheld media queries because these types do not supply high-end web content. Therefore, use the screen media type query for iOS.
This is dross: superficially intelligible, but still drivel. It’s the sort of thing we pay our politicians to say because no other people of equal intelligence can bear to, except this is embedded in a technical document describing how to develop webpages for the iPhone.
CSS rules control the presentation of content, they have nothing to do with its “supply”. The most you could say is that CSS rules might be used hide “high-end web content” though I really struggle to see how this could ever be a real problem because a developer would never want to serve “high-end web content” to a device that doesn’t have the bandwidth to usefully download it or the screen to usefully display it only to finally hide it from the user when it had; and a strategy based on the assumption that content which is never visible is never downloaded is very risky.
This appears to be a manufactured justification. Apple is full of smart people, the only rationalization I can find which makes sense is that Apple didn’t want customers opening their stylish cardboard boxes and turning-on their expensive new gadgetry and launching their petite new browser to see monochrome pages filled with undersized text, if even from a handful of websites. Fair enough. It may have increased their bottom-line, but it’s paid for by every web developer who wants to reliably style their web pages for mobile phones, and it’s really biting us in the backside now that the screen resolutions of high-end phones overlap with those of low-end computers. It was a problem for Apple, but they side-stepped it, and exported it as a problem for (potentially) every web developer in the world.
That Android followed the iPhone down this dead-end just increases my frustration because it means that support for the handheld media type will never improve. Grrr…
I’ve made some minor edits for accuracy
I’ve been meaning to post something about the Android Developer Challenge for a good while, but I’ve been so busy recently (architecting a multi-faceted e-commerce system at the moment) that I’ve had no time for anything else. In fact, I was so busy that the results almost passed me by.
Daisy Garden didn’t win. This was not surprising since I’d had an opportunity to judge a number of the applications in entertainment category. It’s not that I felt there were lots of significantly ‘better’ applications, but that so many of the applications were more suited to the challenge. Congratulations to all the winning entrants. My prediction had been for a music app 1,2,3 in my category and I was almost correct (it was a music app 2,3 instead).
But the results aren’t what prompted this post; I’ve been more interested in how the voting has been structured in both challenges, and I’ve had the opportunity to think about it: my entry into the first ADC flopped, then I joined a team that went on to win, this time round my entry made it to the shortlist but didn’t win - so I’ve pretty much run the gamut of possibilities.
I was mildly critical about the structure of the voting after the first ADC. In my opinion, it pretty much amounted to a map-reduce algorithm in which apps were distributed over judges. The ADC2 was essentially similar and introduced bucketing (perhaps ensure variety?) and pre-filtering with a public vote (to ensure the expert judges had a manageable task, I’m sure).
My basic criticism was, and remains, that such a voting scheme hampers people’s capacity to reach a good judgement because it doesn’t provide a medium through which they can influence each other’s evaluations. The judging process essentially atomizes the judges and fails to take advantage of their human strengths. And I think that understanding this has implications for my field of endeavour: creating software.
I think I’m paraphrasing Bjarne Stroustrup here when I say that software design involves balancing lots of subtle and complex considerations, and the best place to do that is inside the brain of a programmer. If one accepts this, there is an implicit assumption that all of the necessary considerations are known (and will fit into one brain*). I believe this perspective explains a lot about why ‘design by committee’ fails: a team of human’s can’t compete with synapses at transmitting and evaluating ideas. It also explains why ‘elite solo programmers’ may often fail: they can form good judgements but usually don’t have all the necessary data.
In trying to avoid the worst weaknesses of these two extremes, I look to encourage good design by:
With this approach I try both to preserve the clarity that solo-design frequently provides and avoid the narrowness that often accompanies it.
Back to the ADC judging. Forming an unqualified analogy between designing software and judging is application is clearly absurd, but there are similarities, and I think that a panel of judges who freely discussed their opinion about each application before recording individual ratings would provide fairer judgements than may have been the case in the Android Developer Challenge. For example, if there were five judges, and one judge knew that the application under consideration was a direct copy of an existing application, he could share that information with the other judges who could factor it into their rating. Without that exchange of information, the more knowledgeable contribution becomes marginalized.
The point is to target two human strengths: information sharing and individual decision making. Of course, the curse is that this approach doesn’t scale, but I’d love to find one that does, because I’m sure I’d learn a lot about designing software from it.
Thanks to Google for hosting and funding the Android Developer Challenges, it’s been fun.
(*) I think this is the simplest gauge of whether a software project will be successful: If the requirements can’t simultaneously fit into one brain then problems are unavoidable.
