When software engineers first jump into understanding how to adjust their development techniques for mobile devices, they are bombarded with new tools, design considerations, new terminology, and more. So I will state right up-front, where this article is headed. If you are a .NET developer, more specifically, an ASP.NET developer responsible for web-application or web-site creation, then this article is for you.
This article is not about how to setup an Eclipse Android-enabled IDE or how Views in the Android SDK can best be written to support tablets versus cell-phones. It’s also not about the XCode environment and the nuances of writing Objective-C programming for iPads, iPods, iPhones, and the like. This article is about using your existing skills in ASP.NET for targeting these platforms successfully.
To get started, I feel I should explain the difference between Adaptive Design programming and Responsive Design programming.
Responsive Design -
is the easiest to explain. It simply means that you design your web-sites or applications to adapt to the capabilities of the user’s browser settings. So if a user is working with a cell-phone and a rediculously small screen resolution, then your web-site/application should render itself accordingly to make navigating the content easy and intuitive. If the user is on a desktop, then they should be able to view more than just a single tiny column of content at once.
Adaptive Design -
is the most ambiguous term ever, and essentially refers to how web-developers or web-masters may go about re-using techniques or designs from previous projects, on a new project. Sometimes, I have heard this called “Progressive Enhancement”. The idea is to avoid building all of your images, HTML markup, and CSS from scratch each time you start a new venture.
Examples and Discussion -
To beging with, let’s consider a couple of images from an actual website…
The image above shows a normal website shown at full-screen on a desktop browser with 1280 x 900 pixel resolution. Now let’s consider what the same website might look like if rendered on a tablet instead.
And finally… what would this website likely look like on a mobile-phone with something like 465 x 800 pixel resolution?
So… these images give us a starting point to understand more about what Responsive design and Progressive Enhancement (a.k.a. Adaptive Design) is all about. Obviously, there are a couple of take-aways about each of these 3 screen shots… but let me see if I can summarize a couple of Frequently Asked Questions (FAQ’s) here.
1) Are those 3 separate websites? If not, how is the web developer able to achieve such dramatically different visual appearances from the same markup?
2) How does HTML 5 fit into all of that?
3) How would this type of thing affect my project’s budget… if it is determined to be a priority?
4) What technologies do I need to know about?
Answers to the Questions -
1) These images are not taken from 3 separate websites. They are all, in fact, the same website… and I simply resized my browser in order to capture the behavior of each one at different resolutions. The secret to the behavior is called “MEDIA QUERIES”.
Media Queries are the single most important aspect of “Responsive Design” because they allow a web programmer to query the capabilities and current state of the browser and apply styling accordingly. In the past, HTML4 and CSS2 supported media types at a basic level. A common technique was to apply a different set of styles for a PRINT media versus the SCREEN media. For instance, here is some HTML4 markup that does just that…
<link rel="stylesheet" type="text/css" media="screen" href="sans-serif.css"> <link rel="stylesheet" type="text/css" media="print" href="serif.css">
The idea of the “media” attribute in the LINK tags above, is that browsers will interpret this markup based on the output device. So the browser, if it supports the standard, will render “serif.css” to a ‘print’ output device, but will instead render “sans-serif.css” to a screen output device. (Like the one you’re looking at now!) The details concerning syntax and history of “media queries” can be found here: http://www.w3.org/TR/css3-mediaqueries/
There is one little “gotcha” involved with this approach however. The designer/developer will end up making redundant style sheets for some of the same elements. That being said, how much redundancy occurs depends on the individual needs of your project. Most designs require only a small amount of duplicated styles. Like all things on the web, there are differences that must be taken into account on various browsers. So keep that in mind.
2) The HTML4 specification committee, luckily, was able to foresee the need for a forward-compatible syntax that would support media types that were unknown at the time. So, using the attribute below, is perfectly valid even though 3d glasses are not currently a media type that exists on any computing devices that I’m aware of.
media="screen, 3d-glasses, print and resolution > 90dpi"
So, in this way HTML5 isn’t all that important. However, when we’re designing websites today… we need to think about targeting the HTML5 syntax where possible, and that means we need to think ways to make it backward compatible with the HTML4 browsers available today. (As opposed to continuing to produce HTML4 markup with no thought of HTML5 compatibility.) In order to do this, Media Queries and other techniques are critical. Take the following example :
In HTML5, there are several additions to the number of valid HTML tags.
<header id="top" role="banner"> <h1><a href="/"> <img src="i/c/spring/logo.png" alt="Retreats 4 Geeks" /> </a></h1> <nav role="navigation"> <ol id="event-nav"> <li id="nav-details"> <a href="#details" title="Find out">Details</a> </li> <li id="nav-schedule"> <a href="#schedule" title="Get over">Schedule</a> </li> <li id="nav-instructors"> <a href="#instructors" title="Get facilitators">Instructors</a> </li> <li id="nav-lodging"> <a href="#lodging" title="we staying">Lodging</a> </li> <li id="nav-location"> <a href="#location" title="Get the TN">Location</a> </li> </ol> <p id="nav-register"> <b>Register Now</b> <span class="sold-out">Sold Out</span> </p> </nav> </header> <div id="content" class="vevent" role="main"> <article id="details"> <header> <h1>Join us for </h1> <p class="dates"> <time class="dtstart" datetime="2011-04-08" title="2011-04-08">8</time>– <time class="dtend" datetime="2011-04-10" title="2011-04-10">10 April 2011</time></p> <p class="location">Gatlinburg, <abbr title="Tennessee">TN</abbr></p> </header> <figure class="frame focal"> <img class="inner" src="i/mountains.jpg" alt="" title="Smoky Mountains"/> </figure> <section class="main description"> <p class="intro">This Spring, Retreats 4 Geeks is proud to present three d.</p> <p>If you’re the kind of person who finds conference to build incredible websites.</p> <ul> <li><strong>Top notch training:</strong> Retreats are comprised of </li> <li><strong>Learn from the experts:</strong> With more than 32 years of others.</li> <li><strong>Includes everything but airfare:</strong> You’re here to learn, not to worry about each day.</li> <li><strong>A fantastic location:</strong> Clearing your mind is the first step to learning, Mountains</a>?</li> </ul> </section> </article><!-- / #details --> </div>
Note the presence of HTML5 specific tags such as “header”, “article”, “section”, and “nav”. These are the markup tags you definitely want to become familiar with as you move forward with new web-based applications that may interface with mobile devices. Your new target should be HTML5, and HTML4 compatibility should be considered a secondary priority.
3) The overall budget impact of developing for HTML5 and supporting multiple browsers and hardware form-factors, depends on your teams training and experience in the area of supporting web standards, implementing media queries, and understanding tools that support these standards. ASP.NET MVC is in-place so that web developers may continue to implement compelling web applications and sites, utilizing their current expertise in .NET technologies, with the new HTML5 standard!
So if your team already uses ASP.NET MVC, the budgetary impact is negligible. If you decide that a desktop-type of website is all that is necessary for hardware of all shapes and sizes, then you are obviously able to eliminate any additional training or testing of the website at various screen-resolutions. In that case, your project budget will not be impacted at all. However, if you feel that it’s important to support mobile phone and tablets as first-class citizens of the hardware/browser ecosystem that is the world-wide web, and your team is currently lacking training and/or experience in the field of “responsive design”, you will experience a slight increase in the first several projects that your organization undertake. The amount of increase will be roughly equivalent to the time it takes your team members to learn how to develop media queries, resize and float HTML elements properly depending on the media type, and implement HTML4 backward compatibility for all older browsers as necessary.