Posts Tagged ‘End User Development’

Vertical User Experience Platform

July 5, 2012

Whilst discussing what a UXP is and who the key players are with a customer I was asked an interesting question, “is there a need for industry (banking, retail, government …) specific UXP ?”.

My immediate reaction was that the technologies in a UXP were generic horizontal solutions that should be agnostic to the industry they were implemented in. The fact that they were specialised solutions and are not industry specific to me was a key advantage. So why would you want a content management solution or collaboration tool that was specific to banking or retail?

The response was interesting: For many smaller companies the complexity of managing their web presence is huge, even if they buy into a single vendor approach for example using Microsoft Sharepoint they still have a huge task to set up the individual components (content management, collaboration, social tools and apps) and this is only made harder with the need to support an increasing array of devices (phone, tablet, TV etc…).

It seems there is a need for an offering that provides an integrated full UXP that can be set-up easily and quickly without the need for an army of developers. Compromises on absolute flexibility are acceptable provided a rich set of templates (or the ability to create custom templates) were provided, such that the templates handled device support automatically. Further the UXP might offer vertical specific content feeds out of the box.

As in my previous blog “The End of Silo Architectures” using a UXP front end technology to create industry specific apps is a great idea. Such a solution could not only provide the business functionality (e.g. Internet banking, insurance quotes/claims, stock trading) but the technical issues of cross device and browser support, security and performance.

So whilst I can understand the requirement and the obvious benefit, the idea of a vertical UXP to me seems like providing a vertical specific CRM or Accounting package. The real answer is that it makes sense to provide vertical apps and use generic Content, Collaboration and social tools from a UXP. Ideally the generic components are integrated and have easy to configure templates.

As I have highlighted before though the UXP is complex not just from a technology perspective but also from the perspective of skills, processes and standards. The first step for any organisation must be to create a strategy for UXP: audit what you currently have, document what you need (take into consideration current trends like social, gamification and mobile) and then decide how you move forward.

Unfortunately this area currently seems ill serviced by the consultancy companies so it may just be up to you to roll your own strategy.


HTML 5 makes the browser smarter

January 26, 2012

The unsung hero of the web has always been Javascript, without which the standards-based web would be completely static. Javascript enables functionality to be executed in the browser, and has been used to create all sorts of effects otherwise not possible with HTML alone.

In the early days, Javascript implementations weren’t entirely standard, requiring developers to have to write variants for different browsers; this isn’t really an issue any more.

For applications, developers will either use libraries or develop their own validation routines. This Javascript code adds significantly to the amount of code downloaded.

With HTML5, developers will need to write less Javascript, as the browser provides features to do things for itself rather than rely extra scripting.

Validation is the main area of improvement. HTML5 now provides a number of new validation features such as mandatory checking, type checking, range and field length validation. The validation is done within the browser, and developers can opt to decide how to process errors.

Obviously validation has to be repeated on the server for security, to ensure that data hasn’t been hacked in the browser or in transmission. This then means that validation has to be maintained in two places and kept in sync.

HTML5 also provides a number of new input field types such as tel, email, color, datetime. This empowers the browser, by applying it to display a date picker, or a colour chooser for example. More importantly for mobile applications it would allow the browser to show an appropriate keyboard layout e.g. a numeric layout for tel, and an alphabetic keyboard for email type.

There are also a number of new attributes which previously required Javascript such as autocomplete, placeholder and pattern which will prove very useful.

There will be some organisations that will not want the browser to affect their carefully designed user experience; for these people the answer is simple, just don’t use the new features.

For the rest, you will enjoy having to write less Javascript for HTML5 browsers, but of course you will still need to have backwards compatibility for non-HTML5 browsers which will rely on Javascript.

The BBC does a U turn on HTML5

October 12, 2011

Rewind to August 13th 2010 and Erik Huggers Director of BBC Future and Technology blogged that the the BBC were committed to open standards but “HTML5 is starting to sail off course”.

At the time I thought this was a brave statement to make especially as the late Steve Jobs had already announced in April that year and despite a billion app downloads, that HTML5 negated the need for many proprietary browser plug-ins. It was clear at the time this was squared largely at Flash (and possibly Silverlight too).

For me this was a faux pas too far as Huggers continued his blog with statements about proprietary implementations of HTML5 by Apple and fractions of opinions within the W3C and WHAT-WG (who initiated the development of HTML5).

Now fast forward to almost exactly a year later, and Gideon Summerrfield, Executive Product Manager for BBC iPlayer announces the launch of a HTML5 version of iPlayer. Initially this is just aimed at PS3, but will roll out to other devices in the future.

If we take a slight diversion and look at the developer conferences for both Microsoft and Adobe in the last four weeks, both made big announcements about tools and support for HTML5. However committed developers with years of invested skills in SilverLight and Flash were left deflated with the lack of announcements on the future of these technologies.

So have the sleeping giants finally woke up? It seems like it to me.

However, in the case of the BBC, Summerfield’s blog states that they will also launch new versions of the iPlayer for Flash and Air. This may be a short term decision to wait for wider support for HTML5, but there is little clarity about what they see as the future for iPlayer.

To Hugger’s credit he did foresee the benefits of HTML5 could bring to the BBC in reducing development timescales and having a common skill set.

However I applaud those that have the courage and conviction to take bold steps forward and put their money where their mouth is. The FT is a shining example, ditching their AppStore versions for iDevices and completely moving to HTML5.

There is work to be done on HTML5 and it will evolve for some time yet, but the bandwagon has started to roll and as a good friend of mine said to me at the start of the .com era, “When you see the bandwagon starting to move, you have a choice to jump on, or stand in the way of a tonne of metal !”.

For me it is clear. I’m not standing in the middle of the road, I’m jumping squarely onto the HTML 5 bandwagon. The question is, are you?

HTML5 gets fun, without a plug-in in sight

June 16, 2011

I’ve still not finished covering all the new features of HTML5, but I do think it’s time for a bit of a break. One of the real measures of whether HTML5 will take off will be how well it will support the gaming industry, and indeed here some people have feared that it will not deliver and have continued to back plug-in based technologies like Flash, Java or Silverlight. Well after extensive research it’s time to dispel a few myths
Now it’s not true that there haven’t been some great HTML games already, remember Google’s re-incarnation of PacMan and recently Effect Game’s Crystal Galaxy which will work even in IE6 !

However a number of features like Canvas, HTML5 Audio and WebWorkers are changing people’s perception of what is possible on the web and all without plug-ins ! So here is my top 5.

In at number 5 is, well not a game, but nevertheless a nice use of the new canvas API’s, a remake of the popular windows desktop app, Paintbrush.

At number 4 is another remake of an old classic, Asteroids! Whilst not up to the standard of today’s modern graphics they are a vast improvement over the games original line art graphics, and offers smooth movement and responsive feedback.

Number 3 is Canvas Rider a simple yet strangely addictive game requiring skill and judgement to guide a motorcyclist across a number of different scenes.

Just missing the top spot is Torus a 3D cylindrical version of Tetris.

However in first place has to be Pixel Lab’s Agent 8 Ball, great graphics, fast smooth operation and sound make it hard to believe that this is a browser game without any plug-in support. In fact this video comparison of Flash vs HTML seems to have totally missed this great example too (see comparison of pool game 3mins in). There are many more great examples out there, even for those Silverlight enthusiasts Microsoft has assembled some great examples of HTML5 in action.

So what’s the future?  Well if Google’s demo last year of it’s web version of Quake is anything to go by things are certainly looking exciting ! The future is definitely not solo game play, as Game Closure showed last month when it demo’d a multiplay social game called Popstar Defense.

All the credit for this new world of possibility can’t just go to HTML5/Javascript as technologies because it is the tremendous improvements in Javascript engines by all the main stream browser providers that is giving the games a useful performance boost.
I’ll be covering some of the HTML5 features that enable these games such as Canvas and HTML5 Audio in future posts, enough research for now…  time to get back to work !

Make sure you use a current browser supporting HTML5 features like Canvas to view / play these.

HTML5 gets very chatty

May 26, 2011

The web started birth with very much a “click and wait” experience. Any interaction with the server meant a round trip of data across a slow line and ended up with a page refresh. In the Web 2.0 era things changed dramatically with the exploitation of an API: XMLHttpRequest the foundation of a framework called Ajax. With Ajax web pages could now interact with the server without page refreshes. This was transformational, and especially as bandwidth speeds increased people got very inventive with Ajax and created applications that started to feel much more like desktop applications.

Whilst this created a massive step forward developers were still having to create proprietary approaches, sometimes using plugins, for other forms of communications with the server. Ajax allowed the client to call the server, what about the other way round? And further still how about a server sending a message to multiple clients – either on the same machine but in different windows or indeed to multiple physical clients?

Step forward HTML5 which brings a number of new capabilities for communication. There are plenty of resources that provide tutorials on how to use these new features, the focus of this blog is just to raise awareness of the features and the possibilities they present.

Cross Domain Messaging is one of my favourite features of HTML5 and worthy of it’s own separate article, which I will do in my next post. Essentially Cross Domain Messaging allows you to send messages between separate applications running in separate iFrames, Tabs or even browser windows. It is facilitated by the existing PostMessage api (see next post for more details).

XMLHttpRequest has also been upgraded to support Cross Document Messaging. This now means that an application can communicate with multiple servers. For example imajine a News page that contains an article about Japan, the page may have separate sections containing local weather and currency rate updates. Previously the page would have been built up with content from different sites at the server end, now it is possible to do this from the client. A further enhancement to XMLHttpRequest is the addition of Progress Events. Previously when a request was made to the server there was only the “readstatechange” event, which was limited and no implemented consistently across browsers. Now there are several more meaningful and useful events (loadstart, progress, abort, error, load, loadend) that can be processed

Another constraint the web has faced has been the ability for servers to send messages to clients. The most common example being stock markets feeds. Typically developers have created a polling mechanism to get updates from the server at regular intervals most likely using XMLHttpRequest. This creates unnecessary load and traffic to the server. HTML5 also introduces the concept of Server Sent messages using the EventSource interface.  This is basically a publish and subscribe approach: the client subscribes to a message event source, and the server code publishes messages to those subscribers.

XMLHttpRequest and Server Sent Messages are uni-directional messages, but what if you need bi-directional messages: the ability for either the client or server to send/recieve messages? Well HTML5 also has an answer for that with WebSockets (note it is possible to achieve bi-directional messaging without WebSockets, but it is much more difficult, unreliable and network inefficient)

WebSockets is a large topic, however the key point to be made here is that it is a more efficient and standard mechanism for enabling bi-directional messaging. The first step in the process is establishing a handshake between the client and server, this is done by upgrading from http protocol to the websocket protocol. Where websocket communication provides a significant advantage is that once the handshake is established, communication between client and server is free from the heavy load of http headers! Http headers can reach 2k in size, which is a massive overhead if the message is only 10 bytes.

When you compare this to applications that have implemented a polling approach you can see that WebSockets are not only more efficient in message size but can significantly reduce unnecessary traffic created by polling and reduce latency of updates (created by the polling time).

Using WebSockets today does require a server of which there are many available, and of course like all HTML5 features browser support varies and hence needs to be checked.

This post aimed to key you a flavour of some of the key new features that enable web applications to become more chatty and in doing so not only make applications faster, efficient but richer and more dynamic than we have been used to. I believe just these features alone could drive a new generation of web applications across many industries like gaming and financial services. Could this be Web 4.0 ?

HTML5 knows where you are!

May 12, 2011

A few years back I was deemed a heretic by many of my colleagues and friends  when I suggested that HTML5 will remove the need for writing many mobile applications. I was pummelled with questions like:

  • But how will they work offline?
  • Are you saying a browser user experience can rival a platform native one like Apples?
  • You do realise that most games require “threading” how you going to do that?
  • What about storing data locally, can you do that?

I was able to fend of most of these, but the one I couldn’t at the time was about accessing the device applications like Camera and GPS. Well things have moved on and whilst I am no longer deemed a heretic there are still some corridor’s whispering doubt.

One of the big features of mobile technology used by many apps is the phones location and location based services and application have already been through a huge hype cycle.

Under the catch-all banner of HTML5, although it is a separate subspec, the W3C Geo Location working group are making location based applications a reality for web developers. It has been around a while and hence is fairly mature and stable now.

A device (even a desktop) can provide location information in a number of ways:

  • IP Address (this is typically the location of the ISP rather than your machine, but ok if you simply want to check which country the user is in)
  • Cell Phone triangulation (only fairly accurate, very dependent on the phone signal so could be problematic in the countryside or inside buildings)
  • GPS (very accurate, takes longer to get location, dependant on hardware support and can be unreliable inside buildings)

Location data can also be simply user defined: however this is dependent on the user entering accurate information.

Of course one of the key concerns will be privacy but the spec covers this with an approach that the requires a user to give permission for location information to be passed to an application. Note the application can only access location information through the browser and not directly e.g. from the GPS device. Hence the browser enforces the user permissions for access.

The Geo Location API allow for both one off request to get the users current location or for repeated updates on the user’s position, developers write simple callback routines for both approaches. The key information provided includes: latitude, longitude and accuracy. Accuracy is a %value of how close the longitude and latitude values are to the user. Depending on the device you may also get additional information such and speed, heading (direction of travel) and altitude.

As per any quality application you process errors accordingly, especially responding to a failure to get hold of location data because of signal issues or other reasons. Hence retrieving location information is fairly simple, the real hardwork is in processing that information and that requires good old fashioned quality programming ;o)

This specification presents a huge opportunity for web developers to create applications once deemed only the domain of platform specific code, and I for one am very excited !

HTML5 What’s in it?

April 21, 2011

In my blog about HTML5 confusion I never really answered the question on everyone’s lips “Exactly what is in HTML5 ?”. And guess what I’m going to skip the issue again and just follow the categorisation of features as per the W3C as they have very pretty logo’s for each category and mainly because it’s important to know what can be done with HTML5.

The W3C have identified 8 categories of new functionality / capabilities offered by ” HTML5” which can be found here, they are:

Create “smarter” documents for users and machine readers
RDFa, Microdata, Microformats, richer semantics/structure

Offline and & Storage
Ability for web applications to store data locally and run offline.
Application caching, session and local storage, Indexed DB

Device Access
Allow applications to access device features such as GPS
Geolocation API, more to follow including gesture events

More/better communication options between server & browser
Websockets, Server pushed messages, Cross document msgs

Add and control sound and video on your sites
Audio/Video elemts and API’s

Graphics and Effects
Draw and animate 2/3D rich graphics
SVG, Canvas, WebGL, CSS 3D

Performance & Integration
Asynchronous communication and processing
WebWorkers (threading in browser), XMLHttpRequest L2

Improved styles, transforms, effects and fonts
CSS3, WebFonts (Web Open Fonts Format – WOFF)

Whilst the graphics and simple descriptions are quite cool what concerns me is again the ambiguity:

  • HTML5 is more than HTML (its CSS as well, but what about Javascript?)
  • XMLHttpRequest is performance and integration whereas it is actually this feature that created “web 2.0” by enabling asynchronous communication between browser and server, the cornerstone of Ajax.
  • In the categories above where does the Forms validation improvements fit in? (probably in semantics, but I feel this should have it’s own category)

There’s clearly a tremendous amount of really excellent work going into HTML5, it has sound principles and gaining strong momentum – especially in the mobile world. However this has to be balanced with the fact there is still lots of work to do, ambiguities to be ironed out and getting all involved parties and bystanders to sing off the same hym sheet should all not be underestimated.

The finalisation of the specification (when it becomes “candidate recommendation”) is expected sometime in 2012 by the spec’s main editor, Google’s Ian Hickson. However to be a W3C Recommendation status requires “two 100% complete and fully interoperable implementations” and this Hickson believes will happen around 2022 or even later.

However the bandwagon and gravy-train for HTML5 has already started rolling and is gaining momentum, I would say only the foolish will not hop on board. IMHO it is only a matter of when not IF for HTML5. Question is what will you do?

HTML5 prepare for specification spaghetti?

April 14, 2011

For those that have been tracking HTML5 for a while I’m sure life is crystal clear, for those that have not well lets just say you may need some help navigating your way through over 900 pages of documentation which is duplicated by two separate standards organisation and further confused by media journalists and industry analysts.

First a quick step back into history: 1991 Tim Berners Lee publishes “HTML Tags” basically the first publication documenting HTML. However it was not until 1995 with the publication HTML 2.0 that a standard was born by a working group in the Internet Engineering Task Force (IETF). Fast forward again and W3C took over HTML in 1996 but it was not until 2000 HTML became an international standard (ISO/IEC 15445:2000). In 1999 the W3C issued HTML 4.01.

In 2004 a working group consisting of individuals Apple, Opera and Mozilla formed the Web Hypertext Application Technology Working Group (WHATWG) to look at the evolution of HTML. The WHATWG believed that much more evolution was required and their views were in contrast to what the W3C was doing with Xforms in 2003. The WHATWG set out on their own to define HTML’s destiny. However in 2006 the W3C took an interest in participating in their work and both groups have been working together since.

Simple right? So they are both working together on HTML5 specification and are going to publish a spec soon? The answer to this question is not so easy, so we have to break up the question.

Yes they are both working together. However the specification(s) being worked on by the WHATWG cover broader technical ground than the specification for HTML5 being proposed by the W3C (e.g. Canvas 2D, Microdata, Cross document messaging). In addition to this the HTML specification developed by the WHATWG is a subset of their “Web Application” specification which covers additional topics (e.g. WebWorkers, WebStorage, WebSockets…).

Essentially the W3C have divided out some of the work that the WHATWG are doing as separate specifications/standards. The good news is that we are told they are both working from the same source. The relationship of the various documents are neatly summarised in the FAQ’s of the WHATWG website (see link below).

All clear now? At the start of this article I alluded to other parties adding to the confusion, mainly the Press and Analysts. Some of this stems from the various sub specs created by the WHATWG and W3C, but also by the grouping of the evolution of other separate but related technologies like CSS and Javascript. In an attempt to help their clients clarify the situation technology analyst Gartner describes this superset of standards with the catch-all term “Modern Web Technologies”, however I am yet to find a single definition of all the standards their terminology encompasses.

As I sifted through sites and wiki’s everything was going so well until the W3C launched their HTML 5 logo programme saying that it was for : “general-purpose visual identity for a broad set of open web technologies, including HTML5,CSS, SVG, WOFF, and others”… doh ! Back to the drawing board then.

Oh well ignoring all that noise, there’s only the small matter of reading through over 900 pages of specification(s) .

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 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: