WebGL: There’s No Turning Back

In Andy Grove’s book, “Only the Paranoid Survive”, he discusses what he calls strategic inflection points.  A strategic inflection points, he says, is a point in the life of a business when its fundamentals are about to change. That change can mean an opportunity to rise to new heights. But it may just as likely signal the beginning of the end.

HTML5 is here.  WebGL is here.  These are mature technologies and they are being adopted.  It is now possible to create high quality applications for the web.  We are about to reach a point of inflection.

The most significant feature of HTML5 for user interface design and development is the <canvas> tag.  The addition of a canvas to HTML provides a place to draw arbitrary two dimensional graphics within a web page.  Using the JavaScript API, shapes can be drawn to the canvas, images loaded and manipulated and entire applications built.

WebGL is the Khronos Group’s GPU accelerated 3D programming standard for the web.  Based on OpenGL/ES 2.0, which is used in accelerated embedded systems, WebGL opens up the way to create GPU accelerated 3D graphics within web pages, in addition to what is available under the two dimensional API.  The result is that HTML5 plus WebGL blurs the line between native and non-native applications.

Performance has always been considered one of the main benefits of native applications, the others being security and access to local services and data.  When people say performance, they generally mean graphical performance.  Once the graphics and 3D, is hardware accelerated, performance of the non-native application will equal the native application, and in some cases may surpass it.

The launch of Google’s Body Browser last week highlighted one way that 3D in web pages can be used.  So now some users are getting their first exposure to 3D applications on the web, and that means a whole lot of developers are going to be interested in developing with WebGL.

The OpenGL API, along with the associated shader language, is low level.  It requires the developer to write a lot of code to achieve a result on screen.  And unless the developer is familiar with the OpenGL rendering pipeline and has knowledge of hardware, it will be difficult to acquire an in depth undersanding of OpenGL and its graphics drawing process as a whole.

To help the process of creating graphical applications more easily with OpenGL, frameworks are often used.  Frameworks come with different emphases and the one best suited depends on the application being developed.  For example the game engine GLQuake was developed to power 1996′s Quake.  A game engine, however, would not be suitable to develop a WebGL accounting system or a video download service.

If developing for the Apple platform you would use Apple’s CoreAnimation framework.  From the Mac OSX Reference Library: “Using Core Animation, developers can create dynamic user interfaces for their applications without having to use low-level graphics APIs such as OpenGL to get respectable animation performance.”

Apple’s choice to pass on Flash in favour of HTML5 makes a lot of sense once WebGL has been brought into the equation.  In fact it would be not at all surprising if Apple brought the CoreAnimation API to WebGL, allowing their developers to leverage the same framework to create applications that will work across all the Apple platforms, iPhone, iPad, Mac and Web as well.

So what about developers on non-Apple platforms?  Ideally they would be able to use a framework that was cross platform, covering the major systems and WebGL as well.  For development of graphically rich 3D applications it would have to cover the main framework requirements being:

• Scalable from small screens (low end mobile phone) to big screens (1080p TV)
• High level, powerful API, to make developement easier
• Flexible, to be able to fit into different technology environments easily
• Provide consistency across application components, applications and platforms

These frameworks  aren’t here yet, but it won’t be too long.  The opportunity for framework guys, like us, is to empower the developers with just such a framework.  Its an inflection point for graphics and user interface.  For the developers, its an easy downhill ride from here.

Above the Commodity Line

The software required to make a sophisticated consumer electronic device like a TV or a mobile phone, is significant.

The lines of code in an operating system or virtualised environment is in the multi millions (Linux is around 6 million lines of code).  The lines of code in a set of base services on top of that, say email, SMS, MMS, or VOD services is equally significant.

These are complex, demanding and expensive systems.  And you know what?  Users care more about the way their device looks, feels, presents and handles.

Its the stuff that the consumer interacts with that is important.  To the user that is.

That is not to say that the stuff under the hood is unimportant.  Quite the contrary, it is vital.  The consumer doesn’t see it though.  It is difficult to understand and impossible for the consumer to value.

The user interface is the single most important factor driving sales of devices and services.  Just look at the iPhone if you don’t believe me.  The user interface is critical, cannot be taken for granted, cannot be side stepped and cannot be skimped over.

Different But The Same Is Familiar

One of the first projects we did for a large multinational in 2001 was the porting and customisation of open source applications for a new concept Linux PDA.  This PDA was way ahead of its time, with Bluetooth, WiFi, landscape mode view, email and browser.  It predated the Nokia 770 by 1/2 dozen years easily.

One of the main applications required was an email client.  Now in 2001, the choice of good graphical-based Linux email clients was thin on the ground.  Bonus points were awarded for calendar and contact management.

We chose Evolution 0.9 for a number of reasons.  We were already headed down a GTK path and didn’t want to start with KDE applications as well, and it did a lot of what we wanted.

It was also attractive to the customer because  it bore a striking resemblance to Microsoft Outlook.  This was also what killed it, you see it the customer didn’t want it to look too much like Outlook!

FFWD -> 2009

There is a lot of familiar-but-different stuff going on.  Two new products that stand out are:

Toshiba’s new TG01:
http://tinyurl.com/bq4w9x
http://tinyurl.com/dalppk

And HTC’s Touchflow Windows Mobile:
http://tinyurl.com/6z7nsm

As you can see, there is an emphasis on taking the standard Windows Mobile offering and customising it with the Toshiba and HTC look and brand.

The same thing is true for Google Android.  When / if companies like Toshiba do make an Android mobile, they will want to create a unique GUI for the same reasons.

Differentiation of product is mandatory, its branding, familiarity and its important.

The key features of a good UI are:

1. Familiarity
2. Ease of use

You see, the customer wants it to be familiar, but not too familiar.  They don’t want a copy of their competitions application, but they want their application to be easily understood.

Its a fine line.

At FST we have found that separation of the GUI from the code is vital.  It lets the customer change the look and feel at will and is what gives our customers their uniqueness.

We have gone to great lengths to create a system that allows the customer to very easily change all aspects of the user interface without having to plunge into the code.

This means small tweaks and big GUI changes alike are easy to execute and don’t require code change.