If you’ve been thinking Mobile, I expect you’ve been questioning if it is better to have a dedicated mobile site, or a responsive XHTML site? Well, there are advantages to both, and here is some info to get you up to speed.
First off, the general rule of thumb is that if you have an existing website that you like, then stick with it, and create a streamlined mobile-only version. This also applies if your website has lots of images/galleries, video and/or flash, a complex visual layout, or lots of pages with ample text content. The reality is that a mobile site with lots of content is difficult to navigate and one can get lost amidst too much text, and since bandwith is a major issue with smaller mobile devices, a traditional website’s pages will typically take far too long to load for most users. resulting is time-outs, and a poor viewer experience. That being said, if your site is to be a new one and you are fine with a simple layout, and don’t expect too much content, then yes, a responsive mobile design is a good option to consider.
Ok, so let’s talk a moment about the changes that have come over time. If you’ve been online for a while you surely have noted that website design trends have changed a lot over the years, and with the popularity of mobile devices, it is not surprising that practices are changing still. In the past many layouts were created utilizing a percentage layout (often at 90% or 100% width, center aligned) with each column of content also set at a percentage. In a two columnar layout you might have the left sidebar set to be 25%, and the right content area set at 75%. This would result result in the content area expanding or contracting based upon one’s monitor resolution. After a few years most designers moved away from percentage based layouts since we wanted more control of the position of objects (text blocks, tables, images, etc) in relation to each other. This is especially important in complex visual layouts where every object needs to be perfectly positioned, consistent margins, padding, etc.
In the last couple of years, designs have become much more exacting (and most have become tableless for ADA compliancy), and to achieve this precision, fixed pixel widths and heights by way of “classes” and “ID’s” have been used to define the layout specifics utilizing global styling attributes across the pages.
For example, with a contemporary XHTML 1.0 design you will typically see the layout area divided into the “header”, “navigation”, “sidebar”, “main content container”, and “footer”. Each of these container areas will have its own ID tag to define the type of content that will be added; and within each there will be classes assigned for CSS styling.
With HTML5, you will see these same general layout aspects in place, yet with new names. The purpose here is that by utilizing common names, instead of just ID’s, the browsers/device will know what to expect from a given area. For example, with HTML5 we have the “header”, “nav”, “article”, “section”, “aside”, and “footer”.
The markup for will generally look like the following:
<body>
<header>…</header>
<nav>…</nav>
<article>
<section>
…
</section>
</article>
<aside>…</aside>
<footer>…</footer>
</body>
To be clear, HTML5 is still in its infancy, and not all CSS3 is fully supported yet, so I am not suggesting that all new designs be created with it. But for mobile, it does provide some great enhancements. Also it should be noted that even though HTML5 has defined layout markup, ID’s will still be used, as will classes, since these are needed for targeting CSS for a given layout object.
As I’ve noted in a previous blog post, HTML5 is being used most often for Mobile website development do to the integration of jQuery Mobile. jQuery Mobile is a cross platform framework designed to simplify and enhance the development of mobile web applications by integrating HTML5, CSS3, jQuery and jQuery UI into one organized framework. This framework is compatible with all major mobile and desktop applications and all modern desktop browsers.
A primary advantage is its lightweight size (about 20K compressed) and it uses minimal image dependencies which helps speed up the load time. The major difference from traditional XHTML/HTML is that it uses HTML5 data-role attributes in the HTML markup to act as the trigger to automatically initialize all jQuery Mobile widgets found on a page and accessibility features such as WAI-ARIA are also included to ensure that the pages work for screen readers (e.g. VoiceOver in iOS) and other assistive technologies. jQuery Mobile’s API supports not only Touch events, but also the usual Mouse events typically associated with jQuery, making it completely cross-browser and platform compatible.
The other option of course is to create a website that is “responsive”. A responsive design is quite a bit more involved than a typical website since the primary sections of a page will need to be resized based upon the device’s viewing resolution. This is where targeting the CSS for the device’s screen size comes in.
First, we need to define the layout requirements for each device platform that you wish to target: widths 1024px (Desktop), 768px (iPad portrait), 320px (iPhone portrait), then we need to define a grid structure (wireframe) for each of these widths. For the desktop, your grid may consist of three columns, two for the tablet, and one for the iPhone. Next one would build each page so as to define the proper width of each container for each device; and then you would create a CSS stylesheet that would target each device by changing the width of the layout containers/objects by way of the Class and ID attributed to each. In this case, you will likely target a minimum and/or maximum screen width such as: @media only screen and (min-width: 480px) and (max-width: 767px).
The Navigation will need to be created with a variable (percentage based) width that will allow the buttons/links to get closer for the tablet, yet wrap to the next line in two columns for the iPhone. With large images, you won’t want to provide a fixed width/height as is typical, instead set each to “100%” and the image will size to the image container object, which of course would be defined by the CSS stylesheet for each device. As an example, a tablet might have a the main content areas defined by a class as .container with a width of 758px, and then for the iPhone this same class would be sized to 420px. The image container object would have its own class, say .img, and this would be aligned center and its size would be reduced by targeting the CSS class of the image container for the device, and the amount of padding (space from the image object and the side) will be decreased as the target device becomes smaller. Font sizes will need to be larger on the mobile devices, so the choice is to either set the font size to 100% (which will vary in size depending upon the device’s default settings), or set a font size of say 13px, and then for the iphone target the font size at 300%.
Responsive designs clearly have advantages over regular websites, but the concern is that the load time of a page on a mobile device needs to be fast, and in many cases a responsive design will have too many images, or bandwidth requirements to be effectively viewed by phone users. There are also many add-on options that work with regular websites that would not be easy, or especially effective to implement with a responsive design. These include scrollable frames, many tabular systems, popups, etc. And as I noted, a customized visual design would not work well on a mobile device, and while it is likely possible to have the images disappear for the mobile by utilizing “display:none”, this would only add to the coding requirements that are already necessary.
As many of you know, E. Curtis Designs has a HTML5 Mobile website, which is a slimmed-down version of our main website. We are in the process of building responsive designs now since many of our clients have shown an interest, but it is important to recognize that if your website is graphically intensive, has lots of jQuery, javaScript, or Flash, then you would be better suited to just have a separate mobile website, which we can of course help you with.
