We had 20 minutes to discuss our views of mobile commerce. Being the second presentation we had the opportunity to set the scene and fortunately for us Paul Ramshaw from Hybris 1^st up gave us a great setup. 

Our view of the world is:

That mobile commerce to date has been focused on three primary things

• Having a mobile web presence
• Building an app usually iPhone
• The ability to take mobile orders

This has led to mobile commerce delivering product content through a fairly flat and list driven customer experience. Often the experience is fragmented and inconsistent across web, mobile web and apps.  In the past this has been down to the complexity and diversity of device OS and platforms as well as limited investment in mobile.  The growing adoption of Android and HTML5 as mobile platforms are simplyfing things technically and budgets for mobile commerce are steadly increasing.

Based on the discussions I have had with clients and partners the general consensus is that customers are expecting more from the mobile experience.  Smart phones and tablets are raising customers’ expectations from just quick find / order taking to engaging with  deeper customer experiences that can deliver more than lists of flat product content.  This is opening opportunities for retailers to use more persuasive content and experiences to merchandise their products through mobile devices.

Ecommerce has enabled retailers to combine the elements product, promotion, content and the customer to deliver sophisticated online shopping experiences that engage the customer and drive sales.  Today the mobile world brings the element of context, a factor that enables retailers to personalise a online shopping experience that previously we in ecommerce could only dream of. 

The real challenge for mobile commerce is the ability to deliver the right experience, content and promotions depending on the customer context such as browsing on an iPad while watching TV, checking prices in store or looking for the latest deals while traveling on the train or a thousand other scenarios.

I hope you enjoy the video. I didn’t realise my head looked so round.

to see more videos see  http://www.internetretailing.net/mobile-videos/#self

In our initial experiments we tried ECMA script 4 Harmony as the standard language as due to its similarities to JavaScript and AS3 it would be easy for JS and Flash developers to adopt.  Our experiments converting ECMA Script revolved around conversion to JavaScript using an Open Source system “Mascara JS”.  Our initial results were very promising, however, as we tried converting larger more complex modules the code became very bloated, performance began to suffer and bugs started to appear. 

After further investigations we discovered the Open Source platform Jangaroo which compiled AS3 into JavaScript.  Experiments with this technology were far more successful and we decided to continue to use the Jangaroo platform as a starting point and use AS3 for our standard language. 

This allowed us to compile Flash AS3 projects into HTML5 versions sitting ontop of Interact JS

The Pros and cons for this approach are

Pros:

• Single code base across technologies means better code maintainability and less redundant code.
• Better developer productivity, less focus on nitty gritty aspects of the JS/AJAX code.
• Better testability.
• The generated code is JS so it can still be integrated with hand written JS.
• Ability to use OO constructs such as polymorphism.
• Ability to reuse existing AS3 code faster ramp-up for Flash developers to start developing HTML5 code.
• Ability to use AS3 IDEs
• Does not preclude the use of developing with JavaScript and the InteractJS for purist JavaScript developers

Cons:

• Requires a JS framework layer to run.
• Redundant information in output (with tuning this problem can be dealt with).
• Still have to be aware of the idiosyncrasy of the two languages, however, this can be refined over time.
• There maybe bloat and performance inefficiencies with larger modules.

The 10CMS HTML5 InteractJS FlashBuilder Plugin

As we have adopted AS3 as our standard language for building modules, we have a way of simulating the Flash framework in HTML5 and a method of compiling AS3 code into JavaScript it makes logical sense to create a plugin for FlashBuilder to glue the pieces together.  The approach we decided on for the experiment was to create an export plugin which sent the Flash code to an InteractJS compiler service.  This service compiles the exported Flash AS3 code into a single InteractJS JavaScript file.  Our initial experiments have proven quite successful and we have created a prototype for a FlashBuilder InteractJS plugin.

Performance, Performance, Performance

After working with this approach to HTML5 development now for several months with constant tuning and refinement, it is apparent that using a JS framework which replicates Flash and rendoring everthing to a single Canvas has performance limitations on some mobile devices.  Although this approach has the advantage of allowing the HTML5 modules to be fully independent to the rest of the page similar to Flash and completely replicate the Flash experience,  rendering on the Canvas in this way does not benefit from GPU acceleration on many mobile devices and browsers – a massive drawback for performance.  We also tried SVG as an alternative to canvas, however, it has no significant performance benefits over Canvas and for larger applications it is generally less favourable.  CSS does benefit from GPU acceleration but has no programable interface and has no event handling mechanism.

In the next release of interactJS we have taken all our learning’s and evolved interactJS into a fully mobile optimised version.  So far it is looking very slick and performs extremely well on HTML5 mobile devices and a small footprint.  I’m look forward to blogging about this later.  Until then here are some samples and experiments for Interact JS – remember to use a HTML5 browser and switch off Flash.

No demo list is complete without the particle demo

http://ctodilemma.com/html5/samples/particledemo.html

Finger Painting works well on an iPad.

http://ctodilemma.com/html5/samples/fingerpainting.html

Very simple Tower Defence game demo

http://ctodilemma.com/html5/samples/towerdefence.html

10CMS modules – complete 10CMS modules fully content manageable and configurable I have simulated product feeds using XML files.  Flash versions will display when flash is enabled

carousel – using hotspots and slide selectors

http://ctodilemma.com/html5/feelalive/

Lookbook similar to the carousel with polygon selectable areas.

http://ctodilemma.com/html5/lookbook/

We set a series of goals to map out the functional areas of the Flash API into a distinct set of phases for the development of the InteractJS HTML 5 / Flash framework.  The goals / phases were as follows

1. Basic/core parts of the framework such as the sprite graph.
2. Decide on an sprite management approach based on performance and robustness two choices we tested were:
   1. Sprites managed through multiple canvas tags: Result – in Chrome there was a definite performance improvement,  however, in Safari this was negligible.   This approach had difficulties with compositing and a much high RAM usage and also caused crashes on iPads.
   2. Sprites rendered within a single canvas:  Result- on balance provided the most stable and best performing approach. 
3. Replicate a 10CMS merchandising Carousel without data –  this meant implementing the remainder of the display/graphics objects and reproducing the 10CMS SDK in JavaScript.
4. Replicate a 10CMS merchandising Carousel with live product data – this involved building the Flash networking API  in AJAX, we solved the ‘same origin policy’ cross domain  issue by using an iframe to access data from a  HTML/JavaScript file that must be placed on the site of the web service. 

Our investigation into the HTML5 spec for cross domain support found that it involved redevelopment of the web services and it did not seem suitable for deployments into CDN environments.  

1. Testing on iPad – key learning from this experiment was performance of complex animations.  From this finding we kicked of several further experiments which included building an SVG version of visual engine for InteractJS, investigating CSS3 transitions and optimising code for caching and object clean up. Other iPad specific problems included
   1. Canvas default behaviour is the same as an image therefore Touch events need to take precedence over mouse events mouse events to prevent default behaviour such as cut/paste menu pop-ups occurring
   2. In the early version of iSO text didn’t render correctly, however, new OS updates fixed this problem.

InteractJS Visual Engine

The visual engine is the core part of the InteractJS library. It provides an abstract way of defining screen layers which can then be integrated with browser technologies. There are effectively two types of integrations available:

1. Non-retained rendering. In every “frame” the information held within the display tree is used to render a scene. This is how the canvas mechanism works.
2. Retained rendering. This is where the browsers visual hierarchy is used to hold information about the Scene. In this system the visual elements indirectly update DOM objects rather than just internal state. This is how the SVG rendering works but this method could also be used to create visual hierarchies with div tags or other HTML constructs this is on our roadmap for further investigation. 

Sprite Graph

A Sprite graph (or Scene graph) is a way of representing a visual scene in a hierarchy. In the example of the house drawing which contains several nested shapes, if the house is positioned at 40px on the scene X axis and the Triangle is positioned at 10px on the house X axis the triangle is actually located at 50 pixels from the left at the root level of the Scene. This technique of creating a visual tree is very useful for programming visual applications.  Maintaining a Scene graph can be complicated though. If you consider all the visual aspects of a display object:

• Position
• Scale
• Transparency
• Rotation

It suddenly becomes quite a substantial amount of information to process however the canvas object has a visual “stack” which does help.

Summary of Findings

Basic Engine

• Generating one big closure with eval does not help,
• scrollRect does not help performance, clipping. Implementations still seem to do the off screen work.
• Caching to off screen canvas objects, this works nicely in chrome but hurts every other browser. Drawing in negative space is an issue with this technique.

Presentation

• Maintaining a display list is heavy.
• Canvas could really do with a way to extract transformation matrixes based on the current stack.
• Text, there is no word wrap and no multiline. You have to do this yourself! Annoyingly there is an API to measure the width of a text string but that API does not return the height of the text.
• There is obviously no concept of text interaction in HTML5 canvas tag. It is a bitmap. If you wanted to make a selectable text box or similar you would need to implement the entire selection logic.
• Collision detection is tough. To do collision detection on complicated combinations of shapes and lines is complicated. Too complicated to have Javascript do it. This forces you to keep off screen canvases which represent graphic objects which you can hitTest.
• Canvas struggles with hair lines.
• SVG is an alternative to canvas and we can make SVG work with our API. SVG has no performance benefits over Canvas. For larger applications is generally less favourable. There is also greater variation between browser implementations of SVG. SVG is also more difficult to program.

iPad/Mobile devices

• When you put a canvas on an iPad it inherits all the default DOM behaviour of an image. When you click it you get a copy and paste dialog, to prevent this you need to capture the events and swallow them.
• Biggest consideration with mobile devices was one of performance larger images and complex interactions were not perfect and sometimes seemed a bit jerky.

CSS3

• CSS3 transitions work very well as they benefit from GPU acceleration.  They perform brilliantly in Safari and Chrome and on devices such as iPads. However, they lack programmability, you can’t interrupt them with code, you don’t get progress events and timelines and you can’t synchronise multiple transitions.   

We have completed the implementation of version 1 of InteractJS and I will be sharing several demos on my next post soon. 

For a quick sneak peek check out the http://www.10CMS.com  home page the interactive module is a 10CMS module which will default to HTML5 when Flash is switched off ionn the browser.

I would also like to give a special mention the Darren Lee at 10CMS who has been vital in the design and development of InteractJS, has spent many hours of frustration with HTML5 browsers and has helped provide some of the content for this post.

10CMS has always been at the cutting edge of frontend technology building interactive merchandising interfaces for retailers. In the past 5 years Flash has dominated the landscape when it comes to developing rich web components and 10CMS has not only adopted Flash as a technology but also built an extensive SDK geared towards rapidly building interactive Flash merchandising applications bringing together the experiences and best practices from previous client projects. 

Although, Flash is a superb technology for delivering rich interactive experiences it doesn’t come without its challenges and the innovation in browser technologies and the arrival of HTML5 seemed to be providing some very exciting prospects for 10CMS. 

The Canvas API investigation

HMTL5 is a set of new features that are added to the HTML4 specification including APIs for 2D drawing (Canvas), media (audio /video), local storage and offline apps.  The most relevant areas to start our investigations considering the functionality required to implement Flash functionality is the 2D drawing Canvas tag.  

Canvas as the name suggests is literally a canvas bitmap with an API for which a developer can use to programmatically draw complex shapes, images and text as well as manage simple animations and styling.  This is a massive improvement for HTML developers as at last they can add configurable complex shapes and animations into HTML mark-up without relying on libraries of images. 

The initial investigation attempted to answer the question –

Can the HTML5 Canvas tag be used to reproduce 10CMS Flash modules which include rich imagery, sophisticated interactions and product data?

The premise we assumed was that all graphical elements and actions are contained and managed within a single canvas, taking the approach of a canvas representing what we would previously regarded as a Flash SWF object.  The implications are that we would not use the HTML DOM model or CSS to affect or style any of the graphical elements.

We set out by first experimenting with the Canvas API / JavaScript implementing the equivalent exercises that most ActionScript 3 developers start with when learning Flash including drawing, simple animation and bitmaps.  We then moved onto to building several interactive modules such as simple carousels and look-books. It was immediately apparent that while the Canvas API contains the rudimentary functions required for drawing and manipulating graphics, building purely with the Canvas API becomes very code intensive and involves building layers of code to wrap and implement more sophisticated concepts such as sprites and layers.

What we concluded from our initial investigations and experiments that simply using the HTML5 Canvas API alone is not suitable for handling the complexity apparent in building rich merchandising applications that are delivered by 10CMS.  What is required is either further development of the Canvas API or JavaScript libraries that provide a framework abstraction for graphical extensions that AS3/Flash developers have become accustomed to.  

The next stage of our investigation focused on searching for existing JavaScript libraries that manage graphical elements in the Canvas tag.  Despite many new libraries springing up with the intention of solving this problem and delivering functionality for advanced 2D drawing, charting and in some cases Sprite management. We found that although these JavaScript libraries provide light weight graphic frameworks they are targeted at specific areas and many were basic, unfinished or inappropriate for building more sophisticated merchandising apps or providing a foundation for the 10CMS HTML5 SDK. 

The best libraries we investigated were

Doodle.JS – http://lamberta.org/doodle-js/

ProcessingJS – http://processingjs.org/

EaselJS – http://easeljs.com/

There are several others listed on JavaScript Open Libraries site

http://javascript.open-libraries.com/utilities/drawing/10-best-javascript-drawing-and-canvas-libraries/

As the CTO of 10CMS I spend a lot of time out of the office meeting clients and demonstrating 10CMS and a reoccurring question I often get is Why use Flash and not just pure HTML and JavaScript? 

The reasons 10CMS originally adopted Flash as a technology are

• The sophisticated graphics and animation tools in Flash can provide a far better interactive user experience which is consistent across browsers.
• Flash provides a secure approach for accessing data from across domains this is crucial for as an important feature of 10CMS is incorporating real-time product information.
• Flash uses the ActionScript language which is more structured and has better IDEs / tools to support development
• Flash reaches 99% of Internet-enabled desktops http://www.adobe.com/products/player_census/flashplayer/. 

This question reflects my views from recent blog postings that highlight the rapid advances in browser technology and that browsers are becoming more of an application platform.  

In response to this I have spent a great deal in R&D mode with the team at 10CMS.  We have been investigating how to replicate the Flash user experiences in HTML5, SVG and HTML4 across browsers and devices.  Although there has been some really exciting progress in HTML5 in this post I will concentrate on the work I’ve done investigation HTML and Javascript. 

The Challenge

I choose to investigate how far we can push the HTML4 / JavaScript and CSS technology stack first as it is the lowest common denominator supported by all browsers and standard HTML mark-up has the benefit of being SEO friendly. Based on the assumption that many people have today that HTML and JavaScript can now replicate the Flash user experience I set myself the challenge of replicating in a pure HTML4 standard 10CMS Carousel Module which is fully editable and configurable from within the 10CMS editor Portal. 

The high level requirements

• Multiple linkable slides navigated through slide selector buttons
• Hotspots triggering product details overlays
• Product details taken from live product feeds
• Fade and swipe transitions
• Brand colours (non-selected / selected and rollovers) for hotspots and slide selectors.
• Slide selector options – positions (all four corners), margins, shape and colour
• Hotspot options – shape and colour

The Plan of action

Choosing a carousel was no accident as there are already many open source JavaScript carousel like components out there.  I was hoping that this exercise would be as quick and easy as picking a readymade one off the shelf and a bit of customisation. The only bespoke developments I expect are Hotspots (linkable spots on an image), Product overlays / lightboxes, wiring in AJAX calls to product data services and a few minor visual adjustments. Once I have the HTML4 / JavaScript version of the carousel I will populate it with the same 10CMS content used by the Flash version.  This will be achieved by transforming the content XML file published from the 10CMS portal using XSLT.  The end result should be Flash and HTML carousels with the same user experience and using the same content and configuration.

The Search for a JavaScript Carousel

Finding a suitable HTML/JS carousel close to the Flash version was not as easy as I originally thought after lots of searches, installations and testing I finally settled on a JavaScript gallery component called SmoothGallery http://smoothgallery.jondesign.net/ which uses the Mootools JavaScript framework.  The reasons I like SmoothGallery are:

• Nice transitions including Fade and Wipe
• Lots of configuration options including show hide arrows, fade duration, timed rotation on/off, preloading and element selectors.
• Populates through mark-up increasing SEO
• Browser compatibility
• Written to be extendable
• Open Source license

Bits missing and bits to change

• No slide selectors – has slide arrows instead
• No hotspots /
• No Product overlay pannel/Lightbox
• Ajax data integration
• Remove small carousel browser
• Configurable colours

It’s also worth taking a look at Top 10 Javascript slideshows, carousels and sliders at http://www.catswhocode.com/blog/top-10-javascript-slideshows-carousels-and-sliders   

The technical stuff

Despite having an out of the box carousel there was still quite a lot of work to do to get it closer to the Flash version. 

The first development I focused on was getting configurable slide selectors working. In the Flash carousel the user can select shapes (Circles, square and rounded corner squares), colour, position (top–left, top-right, bottom-left, bottom-right) and margin offsets.

Most of this was achievable in HTML4 / JS / CSS2, however, shapes posed the greatest problem. In the Flash version the slide selectors are drawn which allow for almost any shape, however, in HTML selectors can only be implemented using images.  This means implementing the slide selectors in HTML with either configurable shapes with limited colours or as squares in any colour.  I chose the configurable colour option as it gave the greatest level of flexibility across the component.

The second area of functionality I worked on was configurable hotspots.  These are shapes that a user can place onto a slide image which provide links to product details.  Clicking on hotspots will display product details in a product overlay panel.  Hotspots configuration includes shapes (Circles, square and rounded corner squares) and colour.  Compromises were taken regarding shape and colour as with the slide selectors.  Another complication was that of layering.  Initially the approach was to place the hotspots layer at the individual slide level, however, IE bugs with layers made this way too difficult and I resorted to keeping hotspots in the same level as the base carousel, however,  this does impact how smooth the transitions work.

AJAX calls to a product web service to retrieve product details data was the next thing to tackle.  As I was using the Mootools framework I expected this to be a fairly simple excursive.  The Request object in Mootools provides a wrapper around AJAX to allow developers to use AJAX call, results and data in the Mootools class framework and provide cross browser compatibility.  In practice I found that the request object did not return a Mootool XML object but the native browser XML DOM object meaning I had to extend the Mootools Request object to produce an XML object in the form of a Mootools object as well as dealing with all kinds of AJAX cross browser compatibility issues. 

The fundamental issue when working with AJAX is same origin policy which prevents AJAX calls accessing data from different domains e.g. my component on CTODilemma.com accessing data from 10CMS.com.  The definition from mozilla.org is

The same origin policy prevents document or script loaded from one origin from getting or setting properties of a document from a different origin.

– From http://www.mozilla.org/projects/security/components/same-origin.html

In flash this can be overcome by the web service provider placing a cross domain policy file on their web servers, however, this is not possible in AJAX.  Although there a several workarounds for AJAX cross domain calls they are not particularly clean or elegant, for this project I used a local web proxy as a work around and created an AJAX call to retrieve XML product data from a web service based on a SKU.

The product overlay Panel / Light-box – We have product hotspots and a method of retrieving its product data, the next step is to provide an Overlay Panel / Light-box to display the product details. The product overlay panel was easily replicated in HTML4 and is fully configurable including position, size and which fields to display. 

 The final development involved the tidying up of the JavaScript code which involved removing unused features such as the SmoothGallery inbuilt mini slider carousel and remooz integration.  Also additional configuration parameters were added into the JavaScript to disable features which may be used later such as arrows.

Miscellaneous Issues

Although using frameworks such as Mootools and JQerry helps structure your JavaScript code and provides basic classes in JavaScript they still only really provide methods for working around the lack of OO.  The notation does not follow normal OO practices and used is very specific to these JavaScript frameworks.  This combined with the ability for developers to still write spaghetti code can make libraries very difficult to extend and maintain.

Debugging JavaScript code is far better than it used to be and using Visual Studio you can now break into code execution, however, debugging across multiple browsers is difficult and support for historical browsers can be even more challenging.

The Findings

JavaScript was originally designed to cope with form validation and DHTML through the inspection and manipulation of the browser DOM model. It has not been designed as a tool for managing graphic elements, drawing, image manipulation, sprites or layers.  With HTML4, JavaScript and CSS2 I have found that it is possible to develop very stylish interactive modules based on the same content used by 10CMS Flash modules, however, the lack graphics APIs makes it incredibly difficult for standard HTML4 to fully reproduce the levels of sophistication and polish that are often required for brand sensitive sites. 

If you are prepared to spend a great deal of time and effort refining your JavaScript and implementing workarounds you can eventually reach something fairly close to Flash, but as with most optimisation exercises this process delivers diminishing returns and decreasing levels of productivity.  This is not helped by the unstructured nature of the JavaScript language and primitive development tools.  Even using class frameworks such as Mootools and JQery doesn’t fully insulate you from all the idiosyncrasies of developing for multiple browsers and despite allowing developers to structure code into class like structures the notation can become complex making code difficult to manage and maintain.  Another key consideration developing with JavaScript is same origin policy / AJAX cross domain access when trying to retrieve data from web services.

HTML5 is at last providing HTML / JavaScript developers with graphics APIs through the <canvas> tag.  As the name suggests this element provides a canvas to draw, create and manipulate graphics providing a more elegant and flexible solution for implementing rich interactive HTML experiences.  Although HTML5 is a huge step forward for HTML development advanced graphic concepts such as sprites and layers do not natively exist as part of the HTML5 specification.  For this type of functionality to be replicated for <canvas> relies on the development of supporting JavaScript libraries, many of which are still in their infancy.  A more detail discussion of HTML5 and Flash can be found on this blog post http://ctodilemma.com/2010/10/html5-and-flash-innovating-the-web/.  I will also be discussing the HTML5 research and development activities I have been involved in in later posts.

The Conclusion

Right now no single frontend technology is capable of producing extremely rich sophisticated user experiences consistently across multiple browsers and devices while accommodating search engine optimisation.  Fir the next 6 – 12 months Flash will remain the best option for delivering rich experiences constantly across most browsers.  HTML4 is the lowest common denominator for browsers and can produce a fairly good degraded experience for many Flash modules.  It also provides the best option for supporting SEO strategies. In the future HTML5 will start to replace Flash usage in many areas on a website, but this is dependent on HTML5 adoption and the maturity of its implementation of browsers.

At least for the next year providing rich user experiences that supports all devices and SEO will require a combination of frontend technologies to provide varying levels of degradation across browsers.   In the short term this poses an issue for managing and optimising content and code.

Here is the video for the presentation I did back in September at Internet Retailing Jumpstart. The challenge set was to put together a short presentation (20 – 30 mins) on the important issues retailers will face in ecommerce in the next twelve months and how technology and platforms can help solve these problems.  The 10CMS presentation was split into two parts

• Rory Dennis director of client services introduction and quick run through of 10CMS. Demonstrating how retailers use 10CMS to create interactive merchandising modules. 
• I presented the second half around the 12 min mark discussing the challenges of delivering rich user experiences in a world where everything is changing.

The summary of my section :

• First problem for retailers: Application platforms have proliferated with iOS, Flash, Java ME, Symbain, Windows Mobile and webOS, etc – this requires separate developments across multiple platforms!
• Second problem for retailers: Browser are becoming more like application platforms with the adoption of technologies such as HTML5 – but the implementation of HTML5 standards is not yet consistent across all browsers and the technology lacks supporting frameworks and libraries. Building interactive experiences to support multiple browsers with graceful degradation corresponding to browser capability can cause substantial extra development.
• Third problem for retailers: Web-site and application user experience are converging. The expectations for on- site user experience are changing as the use of  mobile and social applications increases, however, re-engineering a site is expensive 
• The solution: the abstration of user experience form the underlying ecommerce  platform
• Future 10CMS architecture:  How 10CMS will deliver interactive modules and applications across multiple technologies (including HTML5 and Flash)  and platforms form web and mobile web to  mobile and social Appa.

The presentation was concluded with a discussion on the high level road-map and questions from the audience. 

If you are interested in seeing videos for other presentations at jumpstart here is the link to the Internet Retailing 2010 Jumpstart event.

Apps replacing the browser sounds like a simple and logical conclusion but does it really make sense?

The smart phone market grew by 64% annually worldwide in Q2 2010  and has reached 66% of the UK market .  The usage of Mobile Apps is expected to continue to rise as the adoption of Smartphones increases with users looking for applications that fully utilise and show off their new jazzy phones. Apple has seen unprecedented success with the number of Apps developed on iOS for IPhone and iPods exceeding 250,000, and according to AndroLib.com there are now almost 150,000 Android Apps.

A big part of the success story for Mobile Apps is down to the full control over the user interface meaning a more sophisticated user experience which is aesthetic, engaging and responsive.  By comparison websites are constrained by the mobile browser technology and bandwidth.  Also many websites do not have mobile versions that are optimised for mobile interfaces and without design considerations for restricted screen real-estate and orientation or optimised rich digital assets the user experience seem clunky and unresponsive.  A MarketingCharts.com  report state that 69% mobile users felt that the long time to download or play media ranked among their top three barriers, and 66% felt that difficulties finding and navigating to relevant content was a top-three inhibitor.

Another major advantage for mobile applications is their access to underlying phone technologies like the camera, GPS, messaging, contacts and compass.  This means that Mobile Apps can deliver even richer contextual user experiences such as augmented realty as well as sophisticated ecommerce and marketing applications that utilise location based services, barcodes and QR codes.

Smartphone adoption is definitely rising, Apps can be very cool and there is plenty of App development activity, so is this pointing to the end of the Mobile Browser?

Even though Smartphones adoption is growing there still remains a high percentage of mobile phone users opting for feature phones and according to Marketcharts.com feature phone users still make up nearly half of all users accessing mobile browsers.  The same report states that actually Smartphone users are actually driving growth in web browsing.

Developing distributing and maintaining Mobile Apps doesn’t come without its problems as Apps require approval from the third party App Stores such as Apple, RIM App World, Google Android Market and Nokia Ovi Store.  In fact application platforms have proliferated with iOS, Flash, Java ME, Symbain, Windows Mobile and webOS, to name a few.  The growing popularity of the iPad we will soon see new versions of platforms ready to support an emerging tablet market.  For example the soon to be released Android 3.0 Gingerbread provides amongst other things better support for larger screen sizes and many manufacturers are synchronising the releases of their new tablets in preference of this new version of Android.

The issue is not just as simple as Mobile Web or Mobile Apps, but also consideration of which application platforms to support?

Many retailers are currently opting to build iOS apps but for Mobile Apps to completely replace Mobile Web this strategy would have to change. Nokia Symbian continues to dominate the market and sales of smartphones with the Android operating system are accelerating with,886% growth globally in Q2 2010, accounting for 37.6% of the total mobile handset market , not to mention the significant market share of RIM’s Blackberry smartphones.   Ultimately we could be faced with managing code bases to support multiple versions of downloaded Apps for multiple mobile platforms and using multiple application technologies.

So despite the huge success of Mobile Apps the mobile Web doesn’t look like it will be disappearing anytime soon. In fact the recent Orange Mobile Exposure Study   shows that UK mobile media users prefer to access the mobile internet using a browser rather than an App (70% Web / 55% Apps).

So what advantages does Mobile Web have over Apps?

• Mobile Websites are available to everyone who has a mobile phone with a browser.
• The MarketingCharts.com survey found 60% of Mobile Users spend time each week surfing the web. The use of standards for mark-up (HMTL) means that mobile websites are open, allowing search engines such as Google to index and reference specific site content.  This supports a simple user search and browsing behaviour with immediate access to website content requiring no installation.    
• Web technologies such as hyper-links, URLS and Cookies has enabled the development of effective and proven online marketing methods and strategies from paid search to online advertising to acquire customers, promote products and increase brand awareness.  The primary focus for mobile App developers has been on the promotion their Apps for download not necessarily its continued use or assess to content.  
• No installation means no need to support multiple application versions or redeveloping and redistributing Apps to support users changing and upgrading their devices.
• Complete control of websites including updates to content and functionality without intervention from third party Apps Stores.
• Websites are centralised implementations with single technology stacks – To support all users Mobile Apps will require the development and management of separate code bases for each platform.

In summary the number of Mobile users accessing the internet is steadily increasing and users are choosing to use both Mobile Applications and Mobile Web to access content.  Mobile Apps provide very rich and engaging experiences using the native capabilities of Mobile devices and the Mobile Web provides users with the ability to search, browse and quickly access content from any website. 

Mobile Apps are not replacing the Mobile Web as they preform different functions for users. it’s more important to understand how each of these technologies provides value to users and how the technologies support each other in symbiotic relationships.  For instance, John Lewis has launched a mobile optimised version of www.johnlewis.com before developing any specific Mobiles Apps as they plan to capture requirements for an App that’s focused on an experience that supports the overall customer relationship.

The key focus for website owners looking to mobile should be on optimising their website and assets, analysing the device/application platform requirements of their customer base and understanding how Apps can support their customer experience.

I was extremely fortunate to have a great panel

Simon Harrow CTO Kiddicare.com – explained in detail how Kiddicare.com is using social networking to support their entire business from buying and customer service to promotions and recommendations.  Simon led a passionate and engaging discussion regarding mobile and how it will be the primary device for ecommerce in the future.

Andy Houston Marketing Director of Venda – discussed how Venda’s clients are using social networking in new and innovative ways such as Jimmy Choo’s find a trainer hunt using Twitter and Foursquare.  As always Andy is a veritable fountain of knowledge churning out some extremely detailed and interesting facts and analysis about the use of mobile across Venda clients

Mark Adams Commercial Director of Portaltech – provided the steady voice of reason putting some rigour and method around when and how to use social networking – “focus on what you are trying to achieve and not just create something because everybody else is”.  Mark used the same logic when it came to Mobile advising to look at your traffic profiles before building apps for specific devices. If iOS is 80% of your traffic why build Android Apps?

Mark Allardice Creative Director of Pod1 – Brought his creativity to bare on social networking discussing the LK Bennett Facebook application which uses user generated content as well as other exciting projects such as incorporating social content from Facebook and Twitter directly into ecommerce sites.

It seemed the social and mobile theme carried on throughout the day in the later presentations and in chats with other delegates and visitors.  I have a particularly in-depth alcohol fuelled discussion about social shopping with two creative directors Mark from Pod1 and Steve from Venda -  Is adding a standard shopping experience to a Facebook page really going to work?  I think we agreed you needed to do more than just replicate your shop in Facebook and to look at how you can embed a shopping experience within the Facebook framework and how Facebook users really use their apps – being a consummate Facebook gamer and seeing the constant stream of strange posts on my wall for fortune cookies, hugs, gifts, magical tokens and to join some medieval alliance, I can see how fitting a marketing message for a sale might need a bit of creative thinking.

I also really enjoyed the Michael Robinson, Head of Ecommerce for Anthropologie slot where he described how Anthropologie created unique shopping experiences in store even using scented candles. Another interesting point was the mixing-up of products to create a jarring experience of discovery.  Looking at a shirt and finding you may also need a new rug.  An experience he relates to rummaging in a car boot sale.  Also every Anthropology store in the US is an individual boutique.  The challenge they found is trying to replicate this online, Michael explained that Anthropologie uses techniques not available in store such as using rich media and imagery.   There were interesting points of how Anthropologie have organisationally incorporated the online functions into the main function lines – online marketing reports to Marketing director etc, unlike many other Bricks and Clicks companies that silo their online channel. 

The controversial quote of the day is Web is Dead and will be replaced by Apps from Jimmy Hale ATG. He believes the use of mobile and the rise of applications will see the use of web sites diminish.  In the presentation I gave a couple of weeks ago at IR Jumpstart I concluded that users are expecting websites to behave more like apps and technologies such as HTML5  and Flash are moving browsers towards being more like application platforms, therefore the web will evolve not dissolve.

All in all Internet Retailing was pretty cool this year and was very well attended, with some useful insights from the presentations and workshops.

Next up Ecommerce Expo – I don’t understand why ecommerce events occur when retailers are in their busiest time.

Is the arrival of HTML5 spelling the impending doom of Flash.  Is Flash a dead technology that should now be banished from all websites.  Or does the ‘H’ in HTML 5 stand for Hype. 

If you take Steve Jobs opinion http://www.apple.com/hotnews/thoughts-on-flash/ and his damning statements of Adobe and Flash particularly when it comes to mobile devices the world as we know it is coming to an end with Flash disappearing into obscurity, replaced by the newest kid on the block HTML 5.

“Flash was created during the PC era – for PCs and mice. Flash is a successful business for Adobe, and we can understand why they want to push it beyond PCs. But the mobile era is about low power devices, touch interfaces and open web standards – all areas where Flash falls short.” 

“New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too). Perhaps Adobe should focus more on creating great HTML5 tools for the future, and less on criticizing Apple for leaving the past behind.”

The response from Adobe’s CTO Kevin Lynch defends Flash and with reassurances for the continued development and innovation in the flash platform while also fully supporting the advances in HTML.

“The productivity and expressiveness of Flash remain advantages for the Web community even as HTML advances. The Flash team will drive innovation over the coming years as they have over the past decade to enable experiences that aren’t otherwise possible. With the ability to update the majority of Web clients in less than a year, Flash can make this innovation available to our customers much more quickly than HTML across a variety of browsers.”

http://blogs.adobe.com/conversations/2010/02/open_access_to_content_and_app.html

As in politics what’s really going on in the technology world is being overshadowed and hidden by hype and spin.  The confusion and uncertainty is being further exacerbated by the extreme views HTML and Flash zealots.  Something that seems to happen a lot in technology I remember the heated arguments of Java and Microsoft developers.

HTML5 in simple terms is a much needed clean-up of the HTML language and the addition of several new elements and APIs.  The two key elements which have many fixated on as the Flash killers are <canvas> and <video>.  These elements do bring some much needed richness to HTML but on their own they are no real replacement for Flash just yet. 

The <canvas> element is a bitmap which can be written to using APIs.  However, concepts such as sprites and layers that are needed for rich interactivity and are supported by Flash do not natively exist as part of the HTML5 specification.  Implementing this type of advanced functionality relies on the development of sophisticated JavaScript libraries, many of which are still in the infancy.  Doodle.js is the most notable, which does effectively replicate part of the Flash API for sprites and layers. Developing some basic examples myself, I found many of the developer’s examples and demos for Doodle.JS were taken from exercises in Flash developer books for ‘making things move’.  Unfortunately, the last I looked the Doodle.JS project was dormant,

The most significant about the arrival of HTML5 is innovation as it breathes life back into the HTML and browser based applications.  Competition also keeps Adobe on its toes pushing it to innovate further and to continue to stretch the Flash platform which we can all agree are great things for our industry regardless of which camp you are in.

Flash is not dead, not yet, I believe it will take 12-18 months for

• HTML 5 languages to be fully implemented by all browsers
• HTML 5 browser penetration
• Creation and adoption of JavaScript libraries for sophisticated interactions
• The ramp up of the developer community

In the meantime Flash and HTML will continue to live together as they have always done.  We will see some highly publicised HTML5 implementations targeted at specific devices, HTML 4 / JavaScript implementations replacing some basic Flash implementations and Flash continued to be used for slick interactive web applications as well as being pushed as a standard platform for Mobile applications.

I believe the final outcome is for Flash to be focused in new areas such as providing a much needed standardised platform for mobile application development.

In the last two years there have been a series of mergers and acquisitions that have completely changed the landscape of search vendors.  This only goes to re-enforce the point I made previously that search in retail is commoditized and reached a level at which innovation in functionality is left to smaller iterative improvements, and the future for search is to not as a stand alone service but as an integral component of a larger vision for ecommerce. 

But how have all these Acquisitions played out and what can we expect from retail search in the future?

• Fast was the first to be acquired by Microsoft back in 2008 and since then there has seemed little focus on retail and more focus on SharePoint integration.
• Mercado was acquired by Ominture which made sense in the pursuit of closing the loop for personalization and merchandising.  However, Omniture was recently acquired by Adobe and my discussions with Omniture now leave me unclear to what their actual roadmap and strategy is.  It seems that the Ominiture product set will remain as a suite of loosely coupled products (e.g. Mercado, sitecatalyst). Adobe has it all the components necessary to create an extremely interesting story for retailers around personalization, merchandising and search.  However, at the moment this story is left to the imagination of retailers and system integrators.  What is needed is a clear strategy and roadmap for all their commerce related products such as Mercado, Omniture and Scene 7.
• Fred Hopper’s price point and licensing model has enabled it to gain a lot of traction in the SME commerce market, however, it was also acquired very recently by SDL who also own the Tridion CMS. SDL PR and marketing are boasting that the acquisition of Fred Hopper adds targeting and marketing to their portfolio with SDL releasing a Fred Hopper and Tridion integration called SmartTarget in Q2 this year.  This acquisition may allow SDL to sell Fred Hopper into other markets and enable SDL to enter the ecommerce and retail market, but whether the combination of Tridion and Fred Hopper will provide any additional value to retailers or whether there will be any new innovations remains to be seen.
• Autonomy, which is rarely considered for retail search also acquired the Interwoven CMS.  This fits well with its overall strengths in unstructured content and I have seen no further indication that they will focus any further attention to commerce and retail.
• Endeca is now the last man standing in terms of big pure play search.  Endeca competitors seem to be suffering from a loss of focus and pace which is usual following any M&A activity.  This along with recent developments including page builder and the SEM modules has placed it above its competitors in commerce and retail search.  Their recent strategic alliance with the Hybris who provides an eCommerce and Product Information Management (PIM) platform show that Edenca continues to invest in commerce and retail.   The interesting thing about the strategic alliance is that it is not just about marketing, in fact Endeca and Hybris have created a joint development team working at integrating the two platforms.  If done right this could bring some exciting new developments across all search and eCommerce functionality.  It will also be interesting to see how they deal with the usual clash over which system will control the front-end and user experience.