Archive for March, 2011

Does HTML5 mean the end of Silverlight: Yes

March 31, 2011

If you’re like me, you might have a dream that surfers will soon not have to rely on plug-ins to enjoy browsing the web. For fellow dreamers, the forthcoming and latest round of browser wars might lead to a better web experience rather than yet another plug-in based nightmare.

Microsoft has recently had to grin and bear the pain, while its dominant Explorer browser has seen its market share attacked by a series of platforms, including Mozilla Firefox, Apple Safari – and most notably – Google Chrome. With market share now hovering at round 60% (see further reading, below), it’s almost as if the top guys at Redmond have suggested that enough is enough.

The result is a return of the browser wars, with Microsoft set to preview the final beta of Internet Explorer 9 (IE9) in September. Chrome is clean, simple and fast – and expectations will be that IE9 provides a much quicker browsing experience.

Initial signs look good. Graphics performance is enhanced and hardware is accelerated. But the real story is the heavy use of HTML5, showing that researchers in Redmond also feel the next generation mark-up language is the best way forward for development.

“The future of the web is HTML5,” suggested Dean Hachamovitch, the general manager for Internet Explorer in a blog post earlier this year (see further reading). With Apple and Google also throwing their weight behind HTML5, much debate has rightly centred on the tricky situation facing Adobe’s video plug-in Flash.

But Microsoft’s support for HTML5 potentially creates another set of circumstances and another high profile conflict. This conflict surrounds Silverlight, a web framework that integrates multimedia and graphical elements in a single environment.

More intriguingly, it is Microsoft’s own framework – and, since April 2007, it has formed the backbone of the provider’s presentation framework. So, where does Microsoft’s support for HTML5 leave Silverlight? That, for web developers, is the key question.

Online publication The Register recently referred to the clash as “The Silverlight Paradox”, suggesting that a high quality and HTML5-ready IE9 will surely make many of the features of Silverlight and Flash redundant (see further reading).

Such a paradox, however, is fraught with complications. IE9 might look like it provides new fuel for Microsoft’s browser battle, but the true level of optimisation will not be clear until web developers get their hands on beta.

As The Register article suggests, legacy requirements mean the use of plug-ins will persist for many years – even if IE9 delivers everything it promises. But the move towards HTML5 shows that the captive strength of plug-ins is waning and businesses must develop web platforms with capability across all levels, from the desktop through to the mobile. The new web experience is emerging.

Further reading:

Does HTML5 means the end of Flash?

March 24, 2011

I am almost starting to feel sorry for Adobe Flash. First it was Steve Jobs, now everyone is starting to recognise the inherent limitations of the proprietary multimedia platform.

The Apple chief executive took a swipe at Flash earlier this year, suggesting the development tool is poorly designed, has security concerns and is ill equipped for the mobile age.

Action was tough, with Apple banning Flash from its iPhone in 2007 and its iPad in 2010. I wrote in November that the attractiveness of the platform would undoubtedly be affected by Apple’s decision (see further reading).

That would have been bad enough. But then it seemed everyone else turned up to give Flash a good kick in its multimedia platform. Such a backlash centred on the next-generation we framework HTML5.

Microsoft, a long-time defender of its own development framework Silverlight, has started to show open support for HTML5. Google has added HTML5 support for video playback and Facebook, with Facebook also going with the standard to provide video on Apple devices.

Such moves help illustrate how organisations are keen to break away from third party plug-ins. What once seemed normal, even convenient, now seems painful – users and suppliers want everything at once and they don’t want to rely on yet another multimedia platform.

It’s been a tough fall from grace for Flash. As well as the aforementioned ability to view movies, Flash also boasted a range of other snazzy and original features. Like video, Flash was able to support rich graphical applications and games. Once again, its originality has been trumped by HTML5.

Where Flash once offered a means to cross-browser reach, HTML5 provides a standards-based approach that is hooking in vendors and removing the necessity to rely on plug-ins.

HTML5’s additional ability to support the running of applications offline provides another significant benefit and a further break from a reliance on workarounds like Flash, Google Gears and Microsoft HTML Applications.

In short, HTML5 has the big backers and the big technology. It is a standards-based approach to web development that is paving the way for portability and accessibility, regardless of location, browser or device.

In comparison, Adobe Flash looks a bit old hat. No wonder Steve Jobs felt so frustrated. The only question is why, in the future, anyone would choose to go with Adobe Flash?

Jobs will not be alone in swerving away from Flash and towards HTML5. Get ready to switch lanes now.

Further reading:

Does HTML5 spell the end of Portals?

March 17, 2011

The portal has just about always been the future of the web. A home page of information that helps bring links and information together, proponents have stated for more than a decade that the portal represents the key gateway to knowledge. As a concept this will persist, but as a specific technology well I believe soon, it will simply seem like a pathway to the past.

The reason is simple: HTML5. The last twelve months have seen HTML5 transition from a next-generation-maybe to the probable future of the web. Big companies, such as Apple and Microsoft, have been open in their support of the framework. In short, everyone has started to recognise the huge momentum behind HTML5.

But before we look at why HTML5 represents a death knell for yet another legacy technology, let us first understand why people use portals. The first reason is UI consistency; portals provide a nice easy way to provide a common look and feel across all portlets (applications).

The second reason, interoperability. Enterprise portals and public web portals – such as Yahoo! and iGoogle – allow organisations and individuals to run multiple apps, bringing together disparate apps running from different servers into a single browser window. These apps maybe running on very diferent server platforms, but once the app is viewed on a portal page, the user is none the wiser that it is actually coming from a different source.

Third, portals allow portlets to communicate and share data. This is a powerful feature that allows one application to “tell” another about anything. For example you may in one portlet find a person, once selected it “tells” another portlet who the user found. That second portlet might now show that persons account details, without the user having to do anything. Of course that interaction can happen with multiple portlets at the same time, powerful !

So, people use portals for UI consistency, application interoperability and application interaction. But the hype surrounding portals has dived since the dot com days of the late 1990s. Analyst Gartner reports the portal provider market has narrowed considerably, dropping from more than 50 vendors in 2003 to fewer than a dozen in 2010.

This brings us neatly to the future direction of portals – and the inevitable rise of HTML5. Portals are convenient, but they are also a pain. Small app windows mean only limited information can be shown.

Portals came out of an era when running one browser window sapped computing power. Now users can easily run multiple sessions, so why limit your information horizons to a collection of small windows?

HTML5 helps to overcome technical concerns, too. New APIs within HTML5, such as cross document messaging, mean information can be communicated in a secure manner regardless of the source domain. Consistency, meanwhile, can be addressed by CSS, which helps ensure the look and feel of HTML5 documents.

With a free HTML5 offering benefits across the key selling points of the portal, why would users choose to pay for and implement a separate technology? As HTML5 continues its march to glory, they will not.

Does HTML5 mean the end of the road for Gears, HTA and Flash?

March 10, 2011

Web standard HTML5 contains loads of great features, from video playback to drag-and-drop. But the best bit, and currently one of the least talked about elements, might be the capability to run apps offline.

The normal web experience is hindered by connectivity. Users can typically access web apps while they have a connection to the internet. Once offline, individuals lose access to email, calendar or notes. There are, of course, workarounds. Google Gears, for example, allows users to navigate compatible sites offline and synchronise when back online.

Microsoft HTML Applications (HTA), meanwhile, is a Microsoft Windows formalisation that provides a web-like experience offline. And Adobe Flash can also be run offline, allowing users to run Flash-based content.

Such workarounds are OK but they are also a bit messy. People want the same experience online or offline; they want to get hold of – and manipulate content – regardless of location and they don’t want to be hindered by platform specific technologies or plug-ins.

HTML5 provides that standardisation. Its two–pronged approach re-connects the user through an SQL-based interface for storing data locally, and an offline cache that helps ensure apps are always available (see further reading, below).

With regards to availability, HTML5’s application cache mechanism provides the ability to have a fall back page for rendering pages when offline. It also provides a means to update cache dynamically. The key, here, is client-side management.

And without wanting to bang my own drum too loudly, it is a rhythm I have been hinting at for a long, long time. I blogged two years ago (see further reading) about client-side management as a method for keeping data in the browser, rather than the server, and as means to reducing memory and processing requirements.

“If only it was supported as standard by the browser rather than having to use hidden fields,” I concluded – and now that day is fast approaching. HTML5 creates a standards-based method for creating local apps that run offline.

As mentioned earlier, HTML5 also provides the ability to store data locally through a client-side SQL database. A series of apps could potentially work with this database, providing a new level of accessibility and integration.

The total approach represents a huge step forwards for web development. It also signals that the end is nigh for proprietary workarounds like Gears, HTA and Flash. HTML5 is the future and web developers simply must get with the program.

Further reading:

Getting apps to cope with different screen sizes

March 3, 2011

Take a ride on public transport and it’s like a game of spot the smart phone. Instead of passing time by reading a paper, more commuters choose to spend time connecting, searching and playing on their web-enabled devices. Soon we will see more and usage of tablets adding to the mix of screens. Then at home and in coffee shops we’ll soon see intereactive web TV’s when screens will get much bigger.

Much has been written, including by me (see further reading, below), about the challenge of trying to write apps for different platforms because of their different operating systems. For the business and its developers, differences in operating systems can be frustrating. Designing a successful iOS app is only half the battle. What about Android, Windows, Linux and BlackBerry?

Worst, however, is still to come. While analysts and experts concentrate on the problems of designing for multiple operating systems, they also often miss out another – potentially bigger – problem: screen size.

The increasingly crucial challenge for app developers is how to get an one to display appropriately across a range of screen sizes without having to recreate pages for different platforms. And that is a real challenge.

Large vendors have already talked about how to cope with the trend. Microsoft created its “three screens and a cloud” vision, which concentrates on how software experiences will be delivered through cloud-based services across PCs, phones and TVs.

Now Google is preparing to join the action, too. In December, details of Google’s next version of the Android operating appeared on the web (see further reading). The supplier started demonstrating how the system, referred to as Honeycomb, will work across multiple form factors.

More specifically, the system promises support for higher resolutions and boasts a frame-based interface that should allow the apps to run on a phone and a tablet, while being perfectly optimised for both. The result is that developers should be able to create one application that works on a number of screens.

Apps will have fragments that a pltform can choose to run depending on screen size and apperance. The result is something like a best-fit solution; an approach to technology that will allow the user to have a consistent user experience across multiple platforms.

That is also an approach that is familiar to edge IPK, with our edgeConnect system dividing a solution into numerous components that are called on-demand. The result is maximum performance and a series of components that can be used and re-used to reduce development cost.

Dealing with multiple screens can seem an added complication to the problems associated to dealing with multiple operating systems. There is no need to panic, however. Vendors are taking steps to design component-based systems for the mobile platforms of the future.

Further reading: