IWC.com is peppered with interactive modules designed to enhance the user's knowledge and appreciation of IWC's products and practices. At the heart of these interactions is a clean, smart and semantic markup, which provides a baseline experience for lowest-common-denominator browsers and feature sets, while acting as a content foundation for the richer experience supplied to modern browsers. There are a myriad of reasons for this progressive enhancement approach, and in this edition of our series on Building IWC.com, we'll explore the building of some of these interactive elements.

Markup

To satisfy the twin goals of accessibility (a major requirement for IWC.com, and a strong consideration for all standards-based sites built at Odopod), and long-term usefulness (The intent of this system is to remain relevant for 10 years), the markup has to to be as clean and semantic as possible. Assistive technologies can't accurately interpret convoluted html structures, and neither can search engine crawlers. Everyone deserves access to the same content, and a clear, clean, minimal, semantic markup structure is the best way to accomplish that goal. Additionally, HTML semantics and best practices have grown to maturity in a fashion that will likely remain relevant for years to come. While we certainly cannot see the future, content written with semantics in mind stand a good chance of being interpreted as such a long way down the road.

JavaScript Enhancement

The challenge is then to translate this minimal markup into rich interactivity. That's where javascript comes in. We often employ jQuery in our standards-based client-side development projects for a number of reasons (a vibrant, active developer community, drastically reduced cross-browser testing time, built-in animation framework and a lightning-fast DOM element selector engine are just a few), and IWC.com's interactive elements are another perfect candidate. The relative ease with which jQuery allows us to manipulate the DOM means that we can reorder, inject, remove and refractor any element we may need in order to facilitate interactivity, regardless of the of the underlying content markup. It's worth noting that while we do utilize 3rd party jQuery plugins for certain utility operations (color transitions and animation easing methods, for example), we generally write our own application-specific objects in order to keep our code as focussed and efficient as possible.

Slideshow Modules

The large slideshow modules that appear on many pages is a prime example of our approach. At it's base, it's a simple list generated from data entered throughout the CMS. Each list item consists of an image, a headline and optionally some text and a link:

The markup that generates the modules is generated by our CMS

 A quick bit of css and it's styled and ready to present to non-javascript-enabled browsers:

Basic style for the list

Upon loading in a javascript-enabled browser however, the markup is manipulated as necessary to meet the animation and design requirements. the slider segments are dynamically sized based on the quantity, and the timing bar and the indicator arrow necessary to control the slider's actions (which serve no semantic purpose, from a pure content standpoint) are created and added to the page:

The final slideshow module

The only thing in the markup that's necessary to differentiate this from a standard unordered list is a class of 'slider'. It's totally unobtrusive, light and flexible.

Other Examples

A similar technique is used on the front-to-back sliders on the watch detail pages. The control handle is only added after the page renders, and only if both the front and back images are present. In both cases, no extraneous, purposeless, elements are added in the markup.

Front/back viewer with and without JavaScript

The user input forms on the site are another example of this approach. We built full pages with dedicated URLs around these forms as a destination for those who choose to have javascript disabled. Then, for those with javascript, we listen for clicks on the links to those pages, pull the form markup in via ajax, and render it in an overlay, providing a seamless experience. The HTML is only written once, but is available to browsers and users of all abilities.

The sign-in form in an overlay and as a standalone page

These are three examples of how we are using JavaScript and progressive enhancement techniques to provide richer experiences on IWC.com and still ensuring that the site's content is available for all users. While this requires a additional forethought, and a bit of effort, knowing that the content is reaching the broadest audience possible is well worth it.

Want More?

For more about our process building IWC.com, be sure to check out previous posts on IWC and Content Management and Our Approach to Video. Stay tuned for more and as always, we'll do our best to answer any questions you may have in the comments below.