Modern Enterprise Applications – A Mobile Web Strategy

In my last post, Modern Enterprise Applications, I started to look at what it takes to build a modern enterprise application.  Technological advances have added complexities to building enterprise application.  The expectations of enterprise users has changed. They expect to be able to use their mobile device to be more productive. They want to have access to the applications on these deviecs  No longer can you get away with developing for a single platform (typically the desktop) when working in the enterprise.

One of the challenges with working in the modern enterprise is how do you target many device while keep development costs at a minimum? The first thing you should do is move as much of the functionality of your application behind the cloud and expose it through services.  Though there have been advances in backend technologies, they tend to be more stable. This architecture gives you the ability to deliver consistent functionality across different platforms. There are different ways to minimize developer costs when it comes to developing UI for multiple platforms which I will is the focus of this post.

Mobile Web vs. Native Application

When your list of target platforms includes mobile devices you inevitably get into the Mobile Web vs. Native Application debate.  That is not the focus of this post.  I will tackle that debate in a different post since that topic deserves more attention than I can give in this post.  So I will assume that mobile web has been chosen as that platform.  For now I will also forego the discussion on how different browsers handle rendering HTML, interpreting CSS, and running JavaScript except to note that you have to keep those differences in mind. There are open source JavaScript frameworks that help you handle a lot of those issues.

HTML is the only true cross platform “native” development environment.  Browsers are everywhere from TVs all the way down to the most basic of cell phones.  If you already have a web application, you are probably thinking “I am also set”.  You can go that route but I am sure the user experience will not be what your users want. In fact that was the strategy at the beginning.  On the bright side you did not spend any money to get there.  You have just alienated those user who haven’t made the switch to smartphones(most smartphones are capable of rendering full site though the experience may not be ideal) which maybe not be a problem in the enterprise).  Outside of smart phones and tablets you will be hard pressed to find mobile device that can handle and site created with HTML 5 and CSS 3.   Strategy Lesson: Map out all the devices that you have to support.  This will be important when we talk about mobile web strategy later.

Client Side vs. Server Side

There are two schools of thought when it comes to building out a mobile web solution. You can build out a solution that serve up pages based on device capabilities. Or you can build a solution that serves up the same page that is adapted on the client. The first strategy happens server side.  You may have experienced this strategy when you go to site xxx.com and are redirected to mobile.xxx.com.  There was some server side magic happening to redirected you to the mobile site.

There are a couple of ways you can accomplish this “magic”.  First you can query the request object to determine which browser made the request but this is currently out of vogue.  Besides any time browser functionality changes you would have to modify your application. Also you would have to remember all the capabilities of every browser, not too much fun if you ask me.  Instead you should serve up pages based upon the capabilities of the device.  The best way to do that is to use a Device Description Repository (DDR).

One of the most popular DDRs is the Wireless Universal Resource File (WURFL) which contains profiles of 15,000 mobile devices with hundreds of capabilities per profile.  Obviously you would not create 15,000 distinct pages.  You would create categories (smartphone, tablet, mobile phone…) of devices and serve up the appropriate page for that category.  Take the list of supported devices you created earlier to build out your categories.  This allows you to provide an optimal experience for each device you support.

The client side strategy is known as Responsive Web Design.  It uses some built in CSS functionality, specifically Responsive Web Media Queries to determine the viewable area. This allows you to develop CSS for different size screens using the same html page, shifting the layout for each resolution.  The Boston Globe site is a good example of this strategy. As the size of the browser changes the page responds by changing the layout.

Media queries happens client side. That means that the whole page is downloaded to the client prior to modification.  That means there might be functionality that is downloaded to the user’s device that they never see.  If that user has limited data plan, you are eating into their allotted bandwidth. Plus you may incur a performance hit over less than optimal networks.  Keep in mind with this strategy you can not query the device for its capabilities. The benefit of this approach is that you only have to build the page once and can reuse it across devices.  Obviously you would have to design the site for each category you plan to support.

Side Note: My post was inspired by this post, Rise of (Small) Machines – A Responsive Example. Here Erik talks about an open source framework to help build responsive sites.  I started to leave a comment but I decided I would write a post instead.  That post started to get too long so now I am writing a series of post!

Hybrid Approach

You may want to consider a hybrid approach.  Responsive web design is great for sites that deliver content.  You can modify the layout of that content for each device category without downloading extraneous content. It not so great for pages where you have to do data entry.  You could use responsive web design to show different data entry fields for different size devices but you are back to eating bandwidth.  Also responsive web design requires browsers to support this functionality.  Most non-smartphone browsers are not capable of this.  If you were using a DDR you could server responsive pages to devices capable of handling them and static html to others.  You could also serve data entry pages optimized for each category without downloading the world.

A note on DDRs.  There are many different vendors out there.  There are even some open source ones.  For a good DDR that is up to date you are probably going to have to pay.  You will want to evaluate the cost vs. repository accuracy to see which one will satisfy your needs.

The User Experience

Remember from my last post that one of the pillars of a Modern Enterprise Application is user experience.  Keep that in mind when selecting a mobile web strategy.  You want to provide the most optimal experience for your users. Make sure that your application should be a “good citizen” on their devices.

Summary

As you can see there needs to be a lot of thought put into developing a mobile web strategy.  I barely scratched the surface but I have hopefully given you a place to start. One thing I hope you got out of this is that the “use html everywhere” is not the “code once use everywhere” panacea that everyone believes it to be.  There is still work to make it truly cross platform.  If I am still going to have to do work to make it cross platform, why did I not build a native application (again discussion for another time).