The conclusive article on a four part series on mobile sites in Drupal. Previous articles have discussed the groundwork, setup and code required for setting up a mobile site in Drupal. It’s now time to reflect on a few of the challenges thrown up and the best way forward.
Gaps
Given the above discussion there are a couple of missing pieces to the mobile jigsaw puzzle as I see it.
Device vs Theme
There should not necessarily be a one to one mapping from device (mobile, desktop) to a theme. This certainly is the pattern within much of Drupal (theme blocks, theme caching strategies). This pattern is achieved by making sure that theme_default conf variable is defined in settings.php. The theme is the switch for customisation. However, if this assumption holds we will never see single “responsive web design” themes developed for Drupal as they rely on a single theme to serve to multiple devices.
Global variable device
It’s important to have a device variable easily available to all code. The best approach would be to set a well known variable in conf in settings.php. This could be based on a header extension (x-device), a regex on the UA, a cookie, the URL or a combination of them. The important thing is that is is an agreed upon variable.This variable is then available for all conditional tests in modules as well as to Context. Both the mobile and desktop versions of the site could be driven by a single progressively enhanced theme.
Context
The Blocks UI is dated and on the way out, to be replaced by Context or other solutions. Context works well for controlling Blocks but it does have troubles with supporting theme based configurations.
In the issue queue for Context there has been some discussion around using Theme for a condition. IMO it would be great if Context could support a “conf variable” condition so that it would be possible to add conditions to check for a “device” global variable set in settings.php. It would then be possible to trigger Block reactions based on this variable. This would free up the possibility of a single theme supporting both sites.
Module loading
Being able to control the loading of modules would be a helpful addition. This would allow for turning off whole slabs of functionality not needed for mobile, providing a much better solution than mopping up HTML, JS and CSS in the theme layer. This would require changes to core so I can’t see it happening. in the meantime we have Mobile Tools and permissions.
Better caching
Upgrading caching layers to handle a “device” prefix to the key would enable a single domain to be used for serving the site. Boost is heading down this path already. There are other solutions available for Varnish.
Progressive themes
And finally we need some themes to experiment with responsive web design. From a practical perspective, my project had some slight annoyances because I was using two very different base themes: Fusion and Nokia Mobile. Translating my mobile subtheme across from the Desktop version was beset with a number of issues mainly to do with regions and bespoke features within the themes. If theme designers could supply a mobile counterpart for their desktop themes life would be easier. Even better if some themes were designed with progressive enhancement in mind.
- Write up guidelines for mobile themes
- A brief discussion on implementing a mobile theme for Zen.
Up and running
If you want to get a mobile site up and running today then my recommendations are:
- Think about mobile first and the core actions and data for your users.
- Setup two sites, either multisite or with a settings.php conditional. Caching should work well with this.
- Put User Agent mod_rewrite testing in Apache to handle redirects.
- Some reverse proxy foo can serve one canonical domain if you know how.
- KISS and be frugal with your module choices. Mobile Tools is a good option.
- Select your mobile theme carefully and ideally match it up with the desktop theme.
- Spend time on tweaking content in a custom module. Be a firefighter for a while
. - Test.
I think there is a kernel of another idea in these articles as well and that is for a full adoption of a mobile first strategy for building websites in Drupal. With some small changes in mindset and code outlined above it should be relatively easy to do. This would allow the development of progressively enhanced themes, served from a single domain. The information architecture of Drupal would be improved significantly because we need only one site, one theme, are more RESTful, just as scalable, with simpler CSS, simpler SSL and simpler DNS and no duplicate content issues. Nirvana.
Resources
Some bedtime grazing…
- Mobile Group
- GDO group.
- Training video (217M)
- “The first part of the training, which is an overview of basic theory of building mobile-accessible websites, is followed by a practical, hands-on component that steps through the practice of making mobile websites with the popular Drupal framework.” Interesting discussion from Drupal Everywhere: Making Mobile Websites with Drupal but not all solutions would be considered best practice.
- mobiForge
- “The world’s largest independent mobile development community”
- Programming the Mobile Web [Maximiliano Firtman]
- Book from O’Reilly, 2010
- Mobile Design and Development: Practical Concepts and Techniques for Creating Mobile Sites and Web Apps [Brian Fling]
- Another book from O’Reilly, 2009
This article is the final of a four part series on mobile sites in Drupal.
- Mobile Drupal (part 1): The groundwork
- Mobile Drupal (part 2): Site setup
- Mobile Drupal (part 3): The code
- Mobile Drupal (part 4): Conclusions
Feel free to comment if you have any other tips, recommendations or corrections.
8 Comments
Wow! Awesome series. I have just been through this process and am impressed with your documentation and thoroughness. I would love to see a BOF at DrupalCon if you are going….
Thanks
Hi Jared,
I started out writing up a few observations and then the darn thing blew out a bit! I’m based in Sydney, Australia so probably won’t be making it to DrupalCon. Maybe one day though…
Thanks for the feedback. Put the thoroughness down to having a bit of spare time over the holiday break
cheers Murray
Interesting article, but please use “read more” scrolling takes too long and moves other equally interesting articles off the landing page.
Sorry about that Slowhand07. These were my first articles on the Planet and I didn’t realize that would happen. I have now changed the feed to be shorter. It might be fixed up if the Planet reads the feed again..
Thanks a million. Just scanned the whole thing and plan to refer back many times. I really appreciate you laying this out. Now, to the coffee shop.
Really great work, nice of you to be so exhaustive in your writeup.
When you question how to handle device identification and mobile response in a module or the theme, I wonder if it might be better addressed by Drupal core? Perhaps Drupal 8 could could take on some of the API functions such as you’ve written in your custom code.
Hi Ben. I think that setting an explicit “device” early in the bootstrap process in a standard way would be very beneficial. So yeah, that’s possibly something for the core in Drupal 8. The page caching layer has a role to play here as well as it needs to be aware of the device if it is to serve up targeted content on the same URL. If things are to be consistent then the caching layer needs to have the same logic as whatever core is using. So, I think that one way through it is to get the caching layer to set a device header extension “recommending” a device. In the absence of this recommendation core could then set a device global. Of course different sites will require different levels of granularity for the device setting. Some sites may not care, others would want mobile/desktop and others may need to know mobile/tablet/desktop etc. This could be something handled by a hook. Having a standard global and a hook to alter it would be very beneficial I think.
Great article. Thank you for sharing.
One Trackback
[...] This post was mentioned on Twitter by Drupal Planet and others. Drupal Planet said: Cruncht: Mobile Drupal (part 4): Conclusions http://bit.ly/fc7s6d [...]