Monthly Archive for April, 2010

How Google will kill Internet Explorer and save the web

Published by Francois Jordaan on April 26, 2010 in Futurology. 16 Comments

Update: This open letter from the EFF to Google makes some of the same points, particularly how Google is probably the one company able to establish an open video standard for the web.

Update 2 (19/5/2010): Steps 1 and 2 in my prediction appears to have happened. Google is open-sourcing VP8 in the hope of making it (in the form of WebM) the standard for internet video. They will transcode all YouTube video to WebM. And Firefox and IE9 (in a half-assed way) have already committed to supporting it.

Update 3 (8/6/2010): Some of the best writing on this topic can be found on Diary Of An x264 Developer by Jason Garrett-Glaser (aka Dark Shikari), especially this and this. In short: he also anticipates the YouTube gambit (“Blitzkrieg”), and would welcome a truly open, patent-free video format for the web to oust Flash, but points out many existing and potential problems with WebM/VP8 that may be its undoing, and does not see H.264 going away. Wait and see, basically.

Update 4 (30/6/2010): YouTube speaks: “While HTML5’s video support enables us to bring most of the content and features of YouTube to computers and other devices that don’t support Flash Player, it does not yet meet all of our needs. Today, Adobe Flash provides the best platform for YouTube’s video distribution requirements, which is why our primary video player is built with it.” So, not soon, anyway.

I’d like to make a prediction. I’m probably not the first to make it, and I may be utterly wrong, but just in case I prove to be right, I’d like to have it on record.¹

I believe Google is planning to kill off Internet Explorer, within the next two years, and I think they can succeed. By “kill off” I mean turn it from the majority browser into a niche browser (<20% for all versions combined.) I believe the strategy relies on Chrome Frame, YouTube, and HTML5 video using the VP8 format.

The game plan

Step 1. It is rumoured Google will soon open-source the VP8 video compression format by On2 Technologies, whom they bought earlier this year. They’ll do so in the hope that it would become the default video format on the web, over Theora (open but technically inferior) and H.264 (superior but patent-encumbered). If they did so, Mozilla, Webkit and Opera browsers, with their fierce competition and fast update cycles, will likely hedge their bets and quickly add support for VP8, in addition to the formats they already support.

Step 2. Google will transcode all videos on YouTube to VP8 format, and serve this as the default to capable browsers. Converting such a vast amount of video is a monumental task, but Google has the resources to do it.

Step 3. Once the release versions of all the major non-IE browsers are capable of displaying VP8 HTML5 video without a hitch², Google will make its final move. Notices will appear on YouTube that they will soon turn off support for Flash, and serve all video as VP8 only. If you use Firefox, Safari or Chrome, you won’t notice a difference. But if you’re using Internet Explorer, not to worry: all you need to do is install a simple plugin: Chrome Frame.

Chrome Frame effectively turns Internet Explorer into Chrome. It still looks like you’re running IE, but the rendering engine has been replaced by Google’s. (Only on request, though: web authors have to explicitly ask for Chrome Frame to be used if available. The rest of the time IE remains unchanged.)

YouTube is Special

YouTube is unique on the web in that pretty much everyone uses it: it is the third most visited site after Google and Yahoo. I would wager that, within a month, some 80% of web users will have visited YouTube, and the vast majority of Internet Explorer users will have installed the plugin they need to continue getting their funny cat fix. Where else would they go? Sure, there are other video sites out there, but none truly compete with YouTube, in terms of volume of content, or audience size.

At the same time, very few people would be able to lambast Google for breaking something that harms their business or access to vital information. Very few people need YouTube, and very few of those will be unable to install the plugin or switch to a different browser.

In a matter of months, the vast majority of IE users will either have switched to a different browser, or installed Chrome Frame, effectively turning it (on demand) into Chrome. IE’s market share (if you look at the actual rendering engine) will collapse from 55% today³ to under 20% (and hopefully much lower).

This will reveal Google’s acquisitions of YouTube, On2, and their development of their own Chrome browser, merely as components in a masterpiece of long-game strategy. Without every one of these components, each monumental and expensive in themselves, the strategy couldn’t succeed. Nobody but Google could’ve done it.

The result

And what a future this will win for the web. Look at this demonstration of the capabilities of HTML5 and CSS3, and imagine a world in which every new website can use every part of it. This could be seen as a massive upgrade for the internet. Imagine not needing to support outdated versions of IE anymore. Only if you had to support a significant customer base locked in by IT policy, a rapidly-dwindling segment, would you still need to support IE.

How will this affect other players? It will be a mortal blow against Adobe, with Flash rapidly losing its hold over internet video over the ensuing months. This would suit Apple fine, who are already doing their best to keep Flash off Apple hardware. (They’re currently putting their weight behind H.264, but that’s simply the best option at the moment.) The Flash plugin will likely remain ubiquitous for a while still, but will be increasingly marginalised, and find its place usurped by JavaScript, Canvas and SVG as support for these open technologies become near-universal.

Microsoft can only respond by getting IE users to upgrade to the latest versions as quickly as possible, and add support for VP8 video. This will suit Google and the web just fine, since IE9 promises to be on par with the competition in its support for modern web technologies. But they will no longer be able to act with the hubris of majority market share, and will be forced into a position of playing catch-up to faster-evolving browsers.

For Google, of course, this is essential for its vision of the browser as operating system⁴.

I deliberately did not do a web search to check for other articles making the same prediction, as I wanted to think it through for myself.
Here’s a possible weak point in my argument: Unlike H.264, VP8 currently does not benefit from hardware acceleration (especially important on mobile platforms.) If this proves to be a major factor, the timeframe may need to be longer to allow for the natural cycle of hardware upgrades. (Fortunately this is more rapid for mobile devices.)
http://marketshare.hitslink.com/report.aspx?qprid=3
The front-end of the Internet operating system, that is.

Just Enough Documentation: an ideal web design process

Published by Francois Jordaan on April 21, 2010 in Agile, User experience and XHTML/CSS. Closed

A recent project reminded me how much I like the “just enough documentation” approach, and how inefficiently web design is often done.

Tasked with redesigning an Agile project management web application (to improve usability but not re-brand), I used the following process:

1. Paper sketching for a day or so to get my ideas straight about page and widget layout. This is the best time to explore wildly different alternatives, and make most of the big decisions.

2. Wireframes in Omnigraffle of the key pages. Since the visual style wasn’t changing, I could do high-fidelity wireframes closely resembling the final design. I work on a large format, so there’s ample space to overlay notes and state changes, as well as alternative ideas. The wireframes were shared with the client on a continuous basis for feedback.

Lots of things weren’t wireframed, including less critical pages, and many dynamic states.

3. I did only two pages in Photoshop, in which I did just enough to give me my final measurements, and the few image elements that needed cutting out. I refined designs a little from the wireframes, but most of this I left to the next stage. The wireframes and this stage together took about 5 days.

4. HTML and CSS. Because in my design I was switching from a fixed-width layout to a liquid layout, you can only really appraise the design once you implement it, so it was imperative to get to this stage as quickly as possible. It is also far, far more efficient to fine-tune margins, typography and colours in CSS than in Photoshop. Furthermore, I could quickly mock up most dynamic interactions – of which this app has plenty – in jQuery (which I had not used before but was ridiculously easy to pick up.) How much more effective than doing so in wireframes, where you (and the client) have to imagine how it will “feel” to the user and you can never be sure whether it will work?

By far the bulk of my time – about 2 weeks – was spent working in HTML and CSS. Pages or elements that weren’t wireframed were much quicker to design directly as HTML and CSS, without the duplication of effort. New ideas inevitably arise during this stage, and are immediately incorporated. I occasionally went back to paper or Photoshop or Omnigraffle to work out small details, but there was no need to keep those design documents “up to date” – they had served their purpose. The client was able to appraise the designs exactly as it renders in the browser, and the resulting artifact was also ready to be integrated into their back-end.

Not only could the client and I be confident about how the design will actually look once implemented, I could also ensure that accessibility measures were built in, as well as the ability for it to be easily re-skinned. (As the app is sometimes white-labelled.)

Conclusion

If I reflect on the design process on many past projects, most seem ridiculously inefficient. Where UX designers had to exhaustively wireframe every single page and every possible interaction, with complex state diagrams for all the dynamic elements. And to keep the wireframes up to date throughout the course of the project. Where designers had to mock up dozens of pages in Photoshop, with everything finalised to the last pixel (but usually omitting hover effects and never considering liquid layout or browser differences). All the foregoing needing to be done before a client will sign it off and a single line of markup can be written. The front-end developer reduced to an automaton incapable of taste or decisions, who just had to implement the Photoshop mockups to the pixel, and all interactions exactly as specified in the wireframes. It was usually impossible to refine aspects of design or interaction at this stage (everything having been signed off), let alone adding new ideas, despite it being the most fluid.

Obviously this won’t suit all projects or clients. For example, I had the advantage of not starting from scratch, and a client who was prepared to work in this way. It was a relatively small project with few stakeholders. On some projects there may be good reasons for an exhaustively documented waterfall process. But very often in my experience it was simply because it was the only way the agency knew how to work, due to the excessive compartmentalisation of skills, and an inadequate understanding of the meaning of web design. And my, what a lot of time and money it wastes.

Plone Theming or: How I Learned to Stop Worrying and Love collective.xdv

Published by gwilym on April 16, 2010 in Plone, User experience and XHTML/CSS. 2 Comments

Recently I’ve been tasked with looking at how we can improve our Plone theming process.

One of the problems that most teams come across on any web project is how to spend less time doing the basics and more time solving the unique problems that each project throws up. This seems to be especially true when it comes to skinning / implementing user interfaces. No matter what framework / CMS I’ve used (and I’ve used plenty) it’s often hard to square the circle between what we want as output and what is actually produced.

Another aspect that can eat up time is having to implement user interface changes during development. Even with the best sign-off procedures, designs, and by extension HTML templates are often subject to change. With that in mind the key objectives we are looking for in a theming method are:

easily portable between projects.
full control over CSS/HTML and JS output.
working in parallel with the development team.

So lets look at the various theming options for Plone.

“Plone theming is getting a bit complicated”

You’re not wrong. From what I can see you have 2 options:

Write a custom stylesheet. It’s amazing what you can do with CSS, but that alone won’t cut it. We need to able to specify the HTML output to meet our high standards of accessibility and design.
Create a ‘vanilla’ theme product. Creating a Plone theme is not for the faint hearted and to be honest it had me stumped. You really need to have a solid understanding of Plone and Zope to create anything worthwhile and while that is not necessarily a problem it’s certainly not my area of expertise.

I could probably grab some developer time here at Isotoma to help me put together this ‘vanillla’ product, but even that doesn’t answer our needs in the level of flexibility we require. There must be an easier way….

Deliverance / Collective.xdv

The future of Plone theming lies in Deliverance / Collective.xdv and will be at the core of Plone 4 theming (so I’m told). You can start using it now though. (see this excellent tutorial to get started )

It took a little effort to get a working buildout, mainly because I couldn’t get lxml working on my mac (necessary for collective.xdv). So I installed it on an Ubuntu VM which worked just fine.

Once I’d got it working it didn’t take me long to realise the potential of this new way of theming. In a nutshell, it allows you to have whatever output you want. Not only that but it allows template development to happen separately and in tandem with the main development effort.

Let’s have a quick look at how it works. At it’s simplest level you have 2 files: theme.html and rules.xml. The theme.html file is a standard html template and you can write this however you want. It is the rules file where it gets interesting. I won’t go in to the full details (see here for a full description) but here are some examples of what you can do.

Replace content:

<replace content='//*[@id=”content”]' theme='//*[@id=”content-area”]' />

this replaces the element in the theme.html with whatever content Plone produces within #content element.

Append / prepend content:

<append content='/html/head/style' theme='/html/head' />

this adds all the styles from Plone.

Discard content:

<drop theme='/html/head/comment()' />

This removes comments form the theme.html appearing in the site.

It uses Xpath, something that I’m familiar with and very easy to learn. With deliverance it gets even easier because you can use CSS 3 selectors. All-in-all you have a very powerful way of theming Plone whilst having a fantastic level of separation and flexibility.

I’m very hopeful that collective.xdv / Deliverance will be the solution we are looking for and I’m really looking forward to using it on forth coming projects.