Web apps are probably the closest programmers are going to get to the “write once, deploy anywhere” ideal. These apps are best suited for users that need to collaborate, share, publish and/or distribute data. Often, the “heavy lifting” for a Web app is done on the server side. They’re available anywhere there’s a Web browser and an Internet connection. This makes them ideal for a BYOD environment. No matter which device a user is carrying, it will have some form of browser. That probably means HTML5. It is, of course, naïve to assume that by simply using HTML5 your app will be automatically useful on all devices. But with a little planning and the right tools, your app can be accessed by a wide variety of devices. What follows is a collection of tools and techniques that may help you in designing Web apps for a BYOD world.
Two Approaches
There are (at least) two approaches a developer can take when planning the HTML5 features used for a Web app: first, the "least common denominator" or, second, "best effort." In most cases, you’ll actually use a hybrid of the two, but you’ll probably lean more toward one than the other. The
least common denominator approach establishes a minimum set of requirements. As long as a browser/device meets those requirements, the app will function properly. The app makes no effort to exceed those requirements, meaning that it looks and feels more or less the same no matter what browser or device is being used. Training, support and help screens can be standardized. The app is usually easier to maintain because there is only one UI code base. The down side of this approach is that users with more capable devices can be frustrated with the imposed limitations. By setting a fairly high standard for the minimum requirements, these limitations need not be serious. The following resources can help you determine which HTML5 features you might want include in your app when taking the least common denominator approach.
The
best effort approach establishes a set of desirable app features and functionality. The app then uses a variety of approaches to determine if and how the browser/device can deliver those features. In this approach, the app needs to try to detect a feature before using it. If that feature is not available it defaults to another, “almost as good” feature. The biggest problems here are complexity and maintainability. The following resources can help you learn how to detect features and potentially plan alternatives when features are missing.
Making Feature Choices
Broadly speaking, users will access your app via one of three types of devices: a desktop/laptop, a tablet or a smartphone. A desktop/laptop can be expected to have a fairly decent sized screen, a keyboard and a mouse. Tablets usually have a decent screen size, but limited input capability. Smartphones have small screens and limited input capability. So, when designing your app you’ll usually be trading off features to balance between portability and functionality.
Server Side Choices With ‘User-Agent’
If you’re using the model/view/controller pattern, you may see your app as “the model” and the device as simply a view and controller. You may want to create a desktop view, a tablet view and a smartphone view of your app. The
W3 HTTP protocol definition specifically provides a way for the browser (user agent) to identify itself to the server to allow your responses to be tailored to a particular agent.
The User-Agent request-header field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations.
By detecting the user agent before sending the view to the browser, you are able to provide the potential for best use of the user’s device. The following resources can help you analyze the User-Agent request-header field so you can detect the type of browser and device your users’ have and serve them the appropriate UI.
Frameworks
A framework is a collection of code libraries, documentation and examples that allow app builders to get a head start. When you choose to use a framework, you sacrifice some level of design flexibility in exchange for a productivity boost. A “lightweight” framework usually solves one or two problems, while a full framework may dictate an entire design methodology. What follows is a collection of frameworks you might want to consider when building your app.
Responsive Grids
In this context, the term “responsive” means that the Web page “responds” to the browser’s size and orientation. A “responsive grid” is a very lightweight HTML/CSS Framework, with very little (if any) accompanying JavaScript. For Web apps, the idea is that you lay your website UI out on a grid and the framework wraps and resizes the page based on the browser’s screen size and orientation.
Because there is little, if any, JavaScript in the responsive grids listed above, they are only about layout, not functionality.
Responsive Frameworks
The responsive frameworks listed here add functionality and typography to a responsive grid. They are full featured and have been well thought out and documented. However, choosing one does lock your app’s look at feel to that framework for better or worse. They are seldom compatible with one another, and potentially have conflicts with other libraries. However, the productivity and feature boost you get from using them is often worth it.
Mobile Web Frameworks
These frameworks are targeted specifically at mobile Web apps. Most are optimized for use on smartphones with good support for tablets. They’ll work for desktop browsers but don’t look like desktop apps. They don’t expect or fully utilize keyboard or mouse activities like “hover.”
Additional Mobile Web Resource
One of the realities about mobile devices is that their connection to the Internet is often slower and less reliable than that of a desktop. These sites provide guidance on how to create a better experience for offline Web apps.
Desktop Frameworks
These are “full” frameworks that don’t take into account the features or limitations of mobile devices. However, in most cases they still work well.
Summary
When designing Web apps, you need to balance between feature availability, screen size, input limitations and connection reliability. As BYOD becomes more commonplace, Web apps are increasing in importance, as is this balancing act. The resources listed here can help you make appropriate design choices to handle the variations between devices.
