October 13, 2009

Blog downtime

On vacation... I'll be travelling in China this month, and will not be able to approve comments on this blog. Back online first week of November.

Internet access in China is still uncertain... sites with user-generated content (Twitter, Facebook etc) have been blocked leading up to the 60th anniversary week for the PRC, and then for a media conference in Beijing (yes, that sounds ironic to me too ;-). I'm hoping things will open up this week... if so, I'll be on Twitter, Typepad, and perhaps I'll even be able to revive my moribund Flickr account.

(If you're into walking or urban orienteering, take a look at Chongqing, near Sichuan, and zoom around a bit... with its mountains, rivers, stairs and curved streets, it's said to be one of the easiest cities in the world in which to get lost, before finding yourself again. Fun challenge! :)

October 8, 2009

Oversensitive porcupine, good for the gander?

Not sure I quite believe this... Techmeme is discussing how a file-download service is apparently complaining to Mozilla about a Firefox extension which removes their advertising.

Meanwhile Google Websearch shows that this site is distributing files claiming to be software that Adobe develops.

I hope I'm misunderstanding it. They can't really be complaining that someone else is infringing on their infringements of others...!?

(btw, thanks to Bing Websearch, which does not list these sites which promise to install Adobe CS4 onto your computer....)

Levels of Runtime Predictability

Yesterday Peter-Paul Koch followed up on his testing of browser technologies with a piece examining implementations of one particular browser library, and concludes "There is no WebKit on Mobile -- there's iPhone WebKit, Android WebKit, S60 WebKit (at least two versions each), Bolt, Iris, Ozone, and Palm Pre, and I don't doubt that I've overlooked a few minor WebKits along the way."

I'd urge you to read Peter-Paul's original paper, as well as followup essays by Savio Rodrigues, Stefan Constantinescu, others.

WebKit is an interesting situation. In HTML itself the file format is openly published, and implementers are encouraged to build their own versions. The WebKit project, under Apple governance, openly publishes HTML runtime source code, which is then modified and distributed by device manufacturers.

In HTML, a file format is "open", and implementations vary. In WebKit, a reference implementation is "open", and device-specific implementations still vary.

Flash complements these two. The SWF file format is openly published, same as the HTML file format (although governance of file format improvements is within the Adobe ecology, rather than the W3C/WhatWG ecology). With Open Screen Project we're more in the WebKit range, where Adobe establishes the reference implementation, and partners customize this to their device. Flash Player 10.1 will differ across device based upon device capabilities (screensize, input methods, accelerometer, etc), but I don't expect it to vary in basic runtime capability the way WebKit does.

Is one better than the other? Is WebKit better than HTML, or Flash better than WebKit? I don't think so... each serves different purposes. Apple's donation of WebKit sourcecode helps resolve some of the implementation differences of the HTML/JS/CSS/DOM/etc specifications. Adobe donates a standard Flash implementation to the world's screens. These options are better when they work together, when one doesn't try to be the other. They're different... both good.

September 30, 2009

"... free as in 'Freedom'...."

A consequence of diversity, as described by Matt Asay today:

The problem I have with free-software advocates like Richard Stallman is that they think freedom is the primary reason to use open-source software. It's not. Utility is.

After all, we're not talking about essential human rights here. We're talking about getting work done with software.

Over the past 10 years I and the companies with which I've worked have sold hundreds of millions of dollars in open-source software/services. Not once have I been asked about "freedom." For that matter, I've also never heard a customer gush about reduced vendor lock-in.

To the contrary, I've met with CIOs and CTOs who have explicitly told me that this isn't a top consideration for them. Just last week, in fact, I moderated a panel at LinuxCon in which I asked senior IT executives from leading media companies if vendor lock-in is a primary motivation for using open source. Nope.

They have work to do. They want software that helps them get their work done and gets out of the way. That's what open source does.

(Go to the original article to get the links Matt uses to document this section.)

The above will be spun by some as "Business is Anti-Freedom", but I think a more apt description is "Different strokes for different folks". People are seeking solutions to their own problems... their judgments may be very different than your own.

It's finding ways to accommodate all those differences -- developing multiple options to satisfy diverse needs -- that's a trickier problem than assuming everyone shares the same values.

September 23, 2009

Advanced Support, from Diverse Audiences

Google did an interesting thing yesterday... they extended the Microsoft Internet Explorer browser to dramatic degree, offering Google's own Chrome browser as an alternative renderer within Internet Explorer's windows. Here's where to download the "early-stage open source plug-in", and many opinions are collected at Techmeme.

I haven't investigated the hack's details, and know nowhere near enough to speculate how the project might evolve. But it's significant, to me, for being the first comprehensive attempt to address bringing the "HTML5" ideas to realworld audiences.

A person's browser becomes their habit -- they're loathe to give up surfing efficiency, not quite willing to risk the expense of exploring a new interface. The global surfing public has diverse choice in browsers, and Microsoft Internet Explorer has proven to be a very strong habit for many.

Google Chrome Frame is (from what I understand) respectful of the current user experience... people don't need to risk their existing browser habits and efficiencies, yet can still explore something new.

I like that. It's like the Adobe Flash Player... a capability which can be invoked across a wide range of HTML engines... an invisible addition, uniting browser choices.


There's a wry aspect to the news too, of course... in 140 characters: "So Google's using a browser plugin, to advance WhatWG's 'HTML5', which tries to do what plugins already do, coz plugins are bad. Is that it?" Seemed to have struck a chord.

There's no need to seek direct conflict. People have been improving browsers for fifteen years, and while growth is slow, it is steady. No need to bash plugins when announcing new feature sets.

Plugins enfranchise minority browsers... the De Facto Web is a more accessible scene than If Plugins Never Were. Objecting "because it is a Plug-in" is as empty a phrase as objecting "because it 'IS' proprietary." No need to be a hater or a killer. It's too weird to hear closedness coming from those evangelizing openness.

So, welcome Google, to the challenge of cross-browser plugins -- improving the capability of diverse consumer installations, by cooperating with their choice of browser configurations. Glad you're here, it's a little less lonely now. ;-)


(Hmm, matter of fact, why isn't there much talk yet about making an Ogg Theora set of plugins? Seems to make sense, so that sites which prefer opensource codecs can accommodate diverse audiences without making content developers sweat the multi-encoding. Here's a request from May 2009: "If you're actually seeking browser support for patent-unencumbered codecs, expanded local storage, drawing engines and such, then why aren't you making plugins for other browsers? If it's because 'plugins are not first-class citizens in the browser', then [please] improve your plugin support and cross-browser homogeneity so that they are." Why shouldn't "open codec" people make cross-browser plugins too?)


Comments are turned off on this entry, due to past history on the topic. If you'd like to do your own blogpost, then including the phrase "Advanced Support, from Diverse Audiences" in the text will let me find it find it fastest in the search engines, thanks!

World Wide Web... legacy content?

We're familiar with workstation display screens, and are coming to grips with pocket-sized display screens, and next year we'll start seeing "digital home" screens.

What types of interactions will we have through The Internet, sitting back a few feet away from a large entertainment screen, remote control in hand?

Take a look the photo in Jessica Hodgson's WSJ article on upcoming Internet TV models. It shows a future TV with a slide-out tool bar, little application widgets available. The looks don't matter at this point -- think of the function.

You'd want to customize the types of info you can call up. Probably a notification system of some type, IM presence, caller ID, a webcam to the front door, various personal services. You probably wouldn't want to dig into a big document on that big screen -- more like quickly monitoring changing world conditions, connecting to others.

Would you want to use a web browser? to surf the Web? to pull up pages which were designed to fit a certain laptop sized screen? to have the ads and the sidebars and the third-party widgets that today's WWW pages possess? Take a look again at that photo... would you want browser panes and all up on that screen?

I don't think so. It would be good to have access to a WWW browsing tool, but the numberless millions of today's WWW pages were explicitly designed for laptop display screens. The very network effects which led to the fast growth of WWW content over the past decade make the viewing not quite satisfactory with other types of digital display screens.

Your mobile phone has a WWW browser. It's indeed handy. But if you have the choice of a fullsize screen, this is much handier. Or if the site has a parallel version designed for a small screen, then that's handier too. It's useful to be able to Surf the Web on a small screen, but the bulk of the content on today's WWW is not very friendly to unexpected display devices.

Now, the web tech itself can make the crossover across devices, I think... shouldn't be any reason why hypertext markup and JavaScript couldn't drive a good TV display too. But the World Wide Web of content, all those pages, all those sites... it's hard for me to picture that as being as much fun eight feet away from the screen with a keypad.

Web tech... that's a different subject than WWW content. That content was tuned for one screen. In a multiscreen world, we have to figure out how to migrate the useful parts of this legacy content.

If you've got a work screen, a pocket screen, and a home screen, it would be strange if they all showed the same thing. The World Wide Web's current content is largely designed to be displayed upon a workstation screen. It's legacy content.

September 16, 2009

Animation for accessibility

Google Street View has a wonderful little animation which shows how the service works, from capture, to scan, to detail-removal.

Looking at it, you wouldn't know it was made by the Google Maps team in Japan, which has had particular privacy concerns with the service. Aside from the credits there is no Japanese, no English, no Russian or Romanian -- no spoken language, just sequential visual imagery.

Yet the meaning of the message comes across, without text. More importantly, the affective content of the message comes across too -- it's cute, compelling, leaves you with a good feeling.

We'd still need a textual representation, for people with low visual acuity or who use devices which don't have adequate display screens... it's hard to get away from the need for multiple representations of a message.

But this Google Street View animation may be one of the clearest examples of how motion graphics assist understanding, in a way that text alone cannot. We humans do learn visually. That's why animation aids access.

[Thanks to Veronique Brossier for the link!]