Principles of Responsive
Web Design
Responsive Web Design lets you create a single web
application that works across desktop browsers, tablets, and phones. Here’s an
example of responsive web design (from an Adobe
sample):
The driving idea behind RWD is that your web application detects the dimensions and characteristics of the browser and device it is running on and adapts layout and behavior accordingly. That means working well from big screens on the desktop down to tablets and phone-size screens. It also means supporting touch, mouse, and keyboard equally well. This involves use of fluid grids, media queries, browser feature detection, and use of percentages and proportional values in CSS, all of which are explained well in Ethan’s book. A corollary of this approach is that to be efficient you will download smaller media content for a small screen than you would for a large screen.
1. Detection: Sense what you are running on
2. Adaptation: Adapt layout and behavior to what you are running on
3. Efficiency: Deliver appropriately-sized content for efficiency
I can’t help expanding on these three core tenets because the RWD philosophy so easily applies to other key considerations we see in the web/mobile space. I like to add three more: location, availability, and sync. In location, we adjust content and input defaults (and perhaps even language) according to where a user is right now. Just as we detect device characteristics for a fluid layout we can also detect location to give a localized experience. In availability, the user should be able to access the web application no matter where they are and whether or not they are online at the moment. This is more than just being able to render well on any convenient device, it also means the application can intelligently know where to find its back end services (which may be multiply deployed) and can handle temporarily disconnected use. Lastly, sync is vital to making availability a reality so that user information and state can be consistently maintained despite switching between devices and being occasionally disconnected. This means having a well-thought out data and state strategy that leverages local browser/device caching and storage as well as back-end services and storage, possibly across multiple data centers.
4. Location: Detect location and adjust content accordingly
5. Availability: Your web application is always available to you
6. Sync: Data and state consistency across devices
RWD is awesome. What about the back end? You can appreciate how the server side of your web application can play an important role in serving up tailored, efficient content and supporting the web client well. Anders Andersen has a good presentation on RESS, RWD with server-side components. I think if you add cloud computing to the mix and use its strengths, you not only support RWD well but extend it with synergistic capabilities. Let’s see what that looks like.
Principles of Responsive Cloud Design
You might say that on the front end we think about the user whereas on the back end we must also think about the users overall. I’ve written previously about how both web and cloud have synergistic considerations of elasticity and location.
It turns out there is a pretty direct symmetry between the use of RWD on the web client side and what you should do on the back end to support it, especially when using cloud computing for hosting, storage, and other services. Each of the six considerations I’ve described above has a cloud counterpart.
Although detection is a client-side activity, the server can use that information as well as log it for analysis. Analytics will tell you how many users you have, what the breakdown of devices and browsers is, and provide raw data you can mine to analyze behavior. Although you could use an analytics service, you might also choose to store your own analytics in cheap cloud storage where you can add business context to the data.
Adaptation is something
both the web client and the web server can and should participate in. There’s
little point in serving up content that won’t be used, so intelligent serving
based on device characteristics is highly preferable to a top-heavy client-side
approach where unneeded elements are merely hidden from view which is wasteful.
Those who develop in .NET should look at the upcoming .NET 4.5 / MVC4 where
there is a lot of support for device-adaptive serving, mobile views, and jQuery
mobile.
Efficiency is a
major back end concern so that the entire user population is served well. In
addition to serving up appropriately sized media for a user’s device, cloud
computing really shines here. First, there is the elastic scale of the cloud
that allows it to be cost-efficient whether you run at small, medium, or global
scale. Your application can adjust its deployment size based on anticipated or
measured changes in load. Cloud platforms also provide services for caching and
localized delivery of content. In Windows Azure we have the Cache Service, a
distributed memory cache, and the Content Delivery Network (CDN), a worldwide
network of 24+ edge servers that cache and distribute static and dynamic
content efficiently.For location, cloud computing allows you to support a regionally broad or worldwide audience. First, the aforementioned use of Content Delivery Networks senses a user’s location and delivers content efficiently through the use of edge servers and content caching. Second, traffic management can direct a user to the nearest data center. In Windows Azure this service is provided by the Windows Azure Traffic Manager, which can route users to hosted cloud applications based on location or other criteria. A user in Nebraska visiting www.myapp.com might be routed to a North American data center while a user in the UK entering the same URL might be routed to a European data center.
The cloud plays a crucial role in providing access and availability. There’s no greater way to provide universal access than to use the cloud. The redundancy of application servers and storage units combined with intelligent infrastructure and disaster recovery procedures keeps your web application back end highly available. You’ll typically see an SLA of 3 to 3 ½ 9’s in cloud computing platforms. When your application is deployed to multiple data centers, there are failover behaviors you can take advantage of. For example, Windows Azure auto-replicates storage across pairs of data centers, and the Traffic Manager service can perform failover routing to an alternative data center if an application becomes non-responsive.
To support sync, cloud computing is useful in providing backing storage (both relational and non-relational) for web applications. Well-designed web services and the strategic use of identity, sessions, and cookies can allow you to manage state and data even though your user may change devices on you or go offline at times. Cloud identity services such as the Windows Azure Access Control Service let you support logon through one or more web identities easily. When there are multiple deployments in multiple geographies, you may wish to keep some data synchronized across data centers. In Windows Azure, a SQL Azure database can be synchronized with other cloud or on-premise databases using the SQL Azure Data Sync service. Cloud middleware such as the Windows Azure Service Bus can help route notifications and processing tasks. Syncing with social networks also applies here--there are many "clouds" to consider, not just the one you're using to host your application.
The Combination
RWD and RCD together are a force to be reckoned with. They let you create web applications that can be run anywhere and everywhere: from small devices to large, from small-scale to global scale. I consider the modern web to be driven by 4 pillars: HTML5, mobility, cloud, and social. RWD covers the first two and RCD the latter two.
By now, you’d probably like to see an example of web and cloud working together responsively. Here's one, called Responsive Tours (8-part tutorial, source code, online demo).
No comments:
Post a Comment