Responsive design is a hot topic of web development these days, and with a simple (and now well supported) way of handling the one site for all clients model (and I mean clients as in browsers/platforms/devices, not the people that give you money in return for a web site) it should well be.

Redirecting mobile users to /m/ or some other cut-down area of your site is becoming a technique of the past.

Using collections of utilities, such as the excellent 320&up, makes building responsively much easier, and handles most of the gotchas for you automatically, so instead of fretting on the technical side of implementing a responsive build, the challenge now rests on the responsive design and User Experience of the site, I.E. how should these content regions stack up in a mobile view? What is the best way to show this sidebar in a single-column layout? Building it is easy; thinking about how the design should adapt itself is the tricky part.

Rich JavaScript Widgets

So when thinking about how a site should rearrange itself when viewed on a responsive site, part of that thought process should include thinking about what happens to rich JavaScript widgets when viewed on a mobile device. For example, your responsive site may have an attractive tabset that works well when viewed on a desktop or tablet computer, but what about when viewed on a smartphone? Tabbed content generally (although not always) sits with the tabs along the top of the group and while this may translate well for smaller tabsets with just a few tabs, it doesn't work too well where there are a lot of tabs, they simply take up too much horizontal space, and two rows of tabs just doesn't work that well visually.

One thing we can't do is simply hide the content; we used to be able to reasonably decide what people wanted to do with their smartphones, a restaurant website owner for example, could decide that mobile users were likely to just want the street address and contact details, not view the entire set of menus while out and about and could therefore hide a lot of the content that simply wasn't likely to be used. This is most definitely no longer the case; we simply cannot make assumptions about the intentions of mobile users.

Therefore we must make sure all content is available and presented to mobile users in an easy to use way. Coming back to the tabs example then, we may decide that the tabs widget is not going to work and so need another solution. Simply displaying all of the content may not be an option either if the tabset contains too many tabs to show on a horizontally-restricted mobile device, it may contain too much content to just dump on the page. There may be an important area of the screen that is usually visible below the tabs, but which would be pushed too far down the page when all of the tab content is visible.
One solution that meets both requirements of using an alternative widget to display tabbed content, while not making the page miles long is to implement something that works well in a page that is taller than it is wide, something like an accordion, where the content is still available on the page and can be viewed by users that wish to see it.

Implementation

Based on the 320&up model, we want to transform the underlying content differently based on the width of different devices. We would typically specify a set of different breakpoints in our CSS and each time a breakpoint is exceeded, we load a further style sheet, which builds on style sheets previously loaded. To keep this example simple we'll work on just two breakpoints; at least 320 pixels wide gives us a breakpoint for smartphones, while 720 pixels and above gives us a breakpoint for tablets and desktop computers.
We won't be looking at the styling in this example; we're only interested in the JavaScript required to make our widget responsive. We'll use jQuery UI (version 1.8.16) to create the widgets.

We'll assume that the content we wish to work with is in the following format:

 
Content Heading 1
 
 
...
 
...
 
...
 
 

There will be a heading followed by a div containing one or more paragraphs of text. These elements will be repeated one or more times, with the whole lot wrapped in an outer container.

All we need to do to create the appropriate widget based on the width of the viewing device is check the width of the window when the page loads and then make any adjustments to underlying HTML that each widget requires:

(function ($) { var container = $("#content"), width = $(window).width();

 if (width >= 320 && width ", { href: "#" });

container.accordion({ active: false, collapsible: true, autoHeight: false });  } else if (width >= 720) {  var list = $("");  container.find("h2").each(function (i) { var header = $(this), item = $("
");  $("", { text: header.text(), href: "#tab" + i }).appendTo(item);  item.appendTo(list); header.next().attr("id", "tab" + i) header.remove(); }); 

 container.prepend(list).tabs(); } } (jQuery));