About a month ago we had just created the basis for our responsive design, see Hur bygger man en sajt som fungerar både på mobil, tablet och desktop – på respektive form factors villkor?. Time to give an update on the progress.
The areas that we have been working on are markup & semantics, http requests, amount of loaded KB and screen size adjustment.
On the markup and semantics front we have made additional switches from a traditional <div> structure to one of HTML5 tags (we where happy that the <time> tag was re-introduced). Our timestamps are printed in a humanized format, see timeago – a jQuery plugin.
We also added support for schema.org and microformats.org/ on images and author information. Tests width Google Rich Snippets Testing Tool indicate that it will give added value in search results. Schema.org and RDF also has a draft pending that seems interesting.
With regards to keeping the amount of http requests down we use regular methods like sprites (depending on how big you have to make the sprite, it might actually also save a good deal on total KB size) and media querys combined with a script loader to only load relevant CSS styles and JS per device. @bengoodyear created a script for loading the share buttons only when the user indicates that he or she wants to use them. An additional nice feature is that on mobile you will be able to click the share buttons individually, thus removing the need to load them all.
Images has the biggest impact when considering amount of loaded KB. This is the reason why we load a small thumbnail (16:9) as the default image. If the screen size is big enough a bigger image will load automatically. To avoid a “jump” when the bigger image is loaded we added the size of the bigger image in the CSS, so what the end user might be able to see (depending on loading speeds) is that the image goes from being blurry to sharp. The right CSS for our set of four layout widths is applied with media query.
We built a custom solution as we have our home-brew Image Management System that we connected to Drupal. If you are using Drupals own image field, you might want to check out Responsive images module.
With regards to the amount of loaded CSS files I tried out Responder module – a good solution if you want to add a responsive design to a current theme. In our case since we are using Omega Responsive HTML5 theme and have added our own solutions it does not look like a module we will add.
The markup generated by Drupal and its modules is not the best, there is a lot that does not need to be there, thus adding both unnecessary KB weight, accessibility and styling issues. This is something we are still working on, and I assume we will have to make some kind of compromise.
Responsive videos is also a bit of a challenge. In our case we need to support Arenan, Youtube and Vimeo.
There is a new version of Arenan being launched next year, and we are working with the implementation of that one. A big improvement will be made on how it is embedded. It will now be added as a background in a div, that is replaced by a Flash player when the user clicks the play button. Sorry, no HTML5 video support yet due to rights management issues.
This means that we can also get a small size image for each video/audio clip, and re-size it the same way we re-size images.
Currently we are experiencing problems with the size of the video, when it actually starts playing. This is something we are working on together with the team building the new version of Arenan.
Right now we are looking at using Fitvids module on all iframes to add the scaling ability to Youtube, Vimeo and other embedded materials. Might be that iframe as a target tag is to broad We will have to test and see, would have been nice if Vimeo and Youtube added a class name to their embed code, so that you would be able to target them.
With regards to the set of four widths we are using, the styling has progressed nicely. It takes a while to start thinking mobile first, but when you get a hang on it it comes naturally. The interesting questions that arise then are what kind of differences do you want on the different devices? Do you want bigger images if you are using a tablet? These are the kind of questions we are thinking about, and will test on users to see what the final version will look like.