A unified and consistent user experience with the various digital apps a group can offer (public website, e-commerce website, mobile online sales, tablets, etc…) is an increasing concern of many large retailers or services companies, so as to effectively brand themselves and leverage a common IT infrastructure.  As the world of back-garden-apps is slowly dying, moving towards a analytics-driven and mobile-driven strategies, it is important to deliver new features to all channels in a safe and consistent manner.

Responsive Design

As a designer or as a developer, having a single unified codebase for mobile, tablet, and desktop websites is really a healthy place to be. The best way to achieve that is to apply a responsive design, where the client-side presentation layer takes care of resizing and re-arranging the layout depending on screen size and resolution (using a combination of JavaScript and CSS ).

Responsive Design – Mobile First

As the picture above suggests, you should start with designing for the smaller devices, because it is easier to scale up to larger devices than down for smaller screens. As an example, trello.com is a one-page pure JavaScript application. Another good one is the support.skype.com pages. If you read this post on a desktop resize your browser window and you will see.

Centralised Content and Services

A less elaborate technique, but probably more mainstream, is to centralise the management and access to the content (CRM) and transactional data (back-end services e.g. REST or Web API) for your portfolio of digital channels. If you make sure that all apps access the content and business logic in the a consistent way, then it will be easier to provide new products and services without writing a lot of platform specific code.

Centralised Backend Services

Adaptive Mobile and Desktop Views in HTML5

A problem I recently faced was how to limit code duplication when porting a set of existing HTML5 pages designed for large screen sizes to mobile devices. It was on a ASP.Net stack, with CSHTML views, client-side JavaScript controllers (JQuery and Knockout), and server-side MVC4 Controllers. Because we did not use adaptive design and implementation techniques, we knew that most screens would require a new view. But we wanted to only re-write the code that was absolutely necessary, leaving the JavaScript and MVC4 Controllers unchanged. To achieve that we used a very cool new feature of ASP.Net MVC4 called Display Modes. The idea is simple: based on a condition evaluated at runtime and for each HTTP request, the framework will decide what view to render. For instance, the URL https://internetorder.dominos.com.au will render home/index.html on a Desktop, and home/index.mobile.html on a Mobile. The implementation is based on a global dictionary (the C# term for a hash table) of available display modes that is created when the application starts. Each key is a string that identifies the display mode, e.g. mobile or tablet. That is, it could be left2right and right2left if arabic support is what your are interested in. In my project, we initialised the display modes as follows:

if ("facebook".Equals(configuration.DomainApplication.Name))
{
      PrependDisplayMode("mobile", context => true);
}
else
{
      PrependDisplayMode("desktop", context => true);
      PrependDisplayMode("mobile", context => 
        context.Request.Browser.IsMobile && 
        context.Request.Browser.IsNotTablet);
}

The first if statement initialises the app pool with an always-on mobile display mode. In our case, it meant that the site was displayed in a Facebook app, for which only the mobile mode was suitable due to some Facebook tabs size restrictions. The second conditional block is more interesting. In non-Facebook mode, we set the display mode to mobile only for mobile devices and not a tablets (Note: we used 51Degrees for user agent detection). Indeed, we wanted to use the desktop views for tablets as we purposely designed them to work on them. Hence, the code above pushes the desktop mode to the top of display modes stack, and then pushes the mobile one, which will therefore be evaluated first when a request comes in. With that in place, the only thing left to do was to re-write any screen that did not display correctly on a mobile. The screen grab below presents some of our project files, showing the desktop views Index.cshtml alongside the mobile ones Index.Mobile.cshtml.

ASP.Net MVC4 desktop and mobile views