Jun 02 2015
Jun 02

In April 2015, NASA unveiled a brand new look and user experience for NASA.gov. This release revealed a site modernized to 1) work across all devices and screen sizes (responsive web design), 2) eliminate visual clutter, and 3) highlight the continuous flow of news updates, images, and videos.

With its latest site version, NASA—already an established leader in the digital space—has reached even higher heights by being one of the first federal sites to use a “headless” Drupal approach. Though this model was used when the site was initially migrated to Drupal in 2013, this most recent deployment rounded out the endeavor by using the Services module to provide a REST interface, and ember.js for the client-side, front-end framework.

Implementing a “headless” Drupal approach prepares NASA for the future of content management systems (CMS) by:

  1. Leveraging the strength and flexibility of Drupal’s back-end to easily architect content models and ingest content from other sources. As examples:

  • Our team created the concept of an “ubernode”, a content type which homogenizes fields across historically varied content types (e.g., features, images, press releases, etc.). Implementing an “ubernode” enables easy integration of content in web services feeds, allowing developers to seamlessly pull multiple content types into a single, “latest news” feed. This approach also provides a foundation for the agency to truly embrace the “Create Once, Publish Everywhere” philosophy of content development and syndication to multiple channels, including mobile applications, GovDelivery, iTunes, and other third party applications.

  • Additionally, the team harnessed Drupal’s power to integrate with other content stores and applications, successfully ingesting content from blogs.nasa.gov, svs.gsfc.nasa.gov, earthobservatory.nasa.gov, www.spc.noaa.gov, etc., and aggregating the sourced content for publication.

  1. Optimizing the front-end by building with a client-side, front-end framework, as opposed to a theme. For this task, our team chose ember.js, distinguished by both its maturity as a framework and its emphasis of convention over configuration. Ember embraces model-view-controller (MVC), and also excels at the performance by batching updates to the document object model (DOM) and bindings.

In another stride toward maximizing “Headless” Drupal’s massive potential, we configured the site so that JSON feed records are published to an Amazon S3 bucket as an origin for a content delivery network (CDN), ultimately allowing for a high-security, high-performance, and highly available site.

Below is an example of how the technology stack which we implemented works:

Using ember.js, the NASA.gov home page requests a list of nodes of the latest content to display. Drupal provides this list as a JSON feed of nodes:

Ember then retrieves specific content for each node. Again, Drupal provides this content as a JSON response stored on Amazon S3:

Finally, Ember distributes these results into the individual items for the home page:

The result?

A NASA.gov architected for the future. It is worth noting that upgrading to Drupal 8 can be done without reconfiguring the ember front-end. Further, migrating to another front-end framework (such as Angular or Backbone) does not require modification of the Drupal CMS.

Mar 13 2015
Mar 13
The services module comes built into core (standard issue), with Drupal 8, the next generation of Drupal. This shows incredible insight in the Drupal community as we had toward a RESTful web connected through APIs. There are a variety of methods to convert a Drupal or WordPress app to a native app that can be
Jan 02 2014
Jan 02

I took over a Drupal 7 project building a web application for college students to upload original videos about their school, and for schools to manage, group, and share the videos.

It's a startup privately funded by the principal, and we are literally working on a shoestring. My previous experience with media in Drupal led the principal to contact me via LinkedIn.

When it came time to build a video playlist in Drupal Views for JW Player version="6.7.4071" (formerly known as Longtail Video), I found very little useful documentation. In fact, someone suggested that those who know how are not interested in sharing their knowlege. -- but not me smiley

There are a couple of videos on YouTube by Bryan Ollendyke for Drupal 6. But a lot has changed in Drupal since then.

The Goal:

Back to the playlist: Site admins can mark a video featured by ticking a checkbox on the custom video content type. Now I want to display those featured videos as a playlist.

JW Player provides clear documentation about how to embed the player, and how to construct and load the playlist via a RSS feed.

The structure of the RSS file:

<rss version="2.0" xmlns:jwplayer="http://rss.jwpcdn.com/">
<channel>

  <item>
    <title>Sintel Trailer</title>
    <description>Sintel is a fantasy CGI from the Blender Open Movie Project.</description>
    <jwplayer:image>/assets/sintel.jpg</jwplayer:image>
    <jwplayer:source file="/assets/sintel.mp4" />
  </item>

</channel>
</rss>

There are various threads on drupal.org discussing video playlists for JW Player. None of them were particularly useful for me.

I constructed my Drupal View to to create a page display with a URL path and display fields:

jwplayer aml playlist drupal view

I tried using the Views Data Export module (a Drupal 7 successor of the Views Bonus Pack export functions) but it was difficult to create the proper syntax, particularly the xml namespace tag 

xmlns:jwplayer="http://rss.jwpcdn.com/"

I found the Views Datasource sub-module views_xml.module workable - mostly. I could add the namespace tag. The old videos by Bryan Ollendyke suggested the strategy to use the Views field labels for the xml tags like <title> and <description>.

I added the xml namespace in Format: XML data document: Settings:

jwplayer drupal view xml namespace

and set up the root and child syntax there too:

jw player xml root and child settings

But there were still two problems:

  1. The Video module does not expose the derivative transcoded video filenames to Views
  2. The JW Player syntax for the file source <jwplayer:source file="/assets/sintel.mp4" /> does not follow the convention of an opening and closing tag.

I used the Views PHP module to locate the filename from the node nid that was available in the the View. Yes, I could have written custom Views plugins and handlers, but remember: shoestring budget. It only took 3 queries:

$video_fid = db_query('SELECT field_video_fid FROM `field_revision_field_video` WHERE entity_id = ' . $data->nid)->fetchColumn();

$video_output_fid = db_query('SELECT output_fid FROM `video_output` WHERE original_fid = ' . $video_fid . ' ORDER BY output_fid DESC')->fetchColumn();

$video_uri = db_query('SELECT uri FROM `file_managed` WHERE fid = ' . $video_output_fid)->fetchColumn();

$video_source = str_ireplace("public://",$base_url,$video_uri);

return $video_source;

  1. Locate the original video_fid in the field_revision_field_video table
  2. Locate the video_output_fid (a different number generated by the Video module) in the video_output table
  3. Get the video_uri in the file_managed table

(yes we could use SQL JOIN - but we're only listing a few videos; TODO: rewrite the queries with placeholders for better security)

I considered creating php template files for these Views fields. But since I planned to embed the player in a custom block, I decided the parsing and processing could take place there.

Now we have the video file uri wrapped in tags <php></php> (from the label of the Views php field - it could be any arbitrary label, and we will be replacing it later).

The result of this view is something like:

<?xml version="1.0" encoding="utf-8"?> <rss version="2.0" xmlns:jwplayer="http://rss.jwpcdn.com/"> <channel> <item> <title>Who doesn&#039;t like free dessert?! </title> <description>Manhattan College</description> <jwplayer:image>http://[domain]/sites/default/files/[path]/thumbnail-690_0004.jpg</jwplayer:image> <php>path/690/MVI_4592_mp4_1384800425.mp4</php> </item> </channel>

Notice that it is not a valid XML or RSS document because there are no closing tags for the xml or the rss - but we will fix that later. Also I have used the value of the school field to rewrite the description field; but I might restore the description text in the playlist.

At first I thought I might use the view to write a file to the filesystem so I set the path to sites/default/files/playlists/featured_videos_playlist.rss.xml

Next, I had to get the playlist into the player.

I created a block with PHP code (or you can do it with a custom module and hook_block_info - but you already know I was working fast and cheap):

<?php

global $base_url;

$url = $base_url . "/sites/default/files/playlists/featured_videos_playlist.rss.xml";

$xml = fopen($url, "r");  

$playlist = stream_get_contents($xml);

$playlist = str_ireplace('<php>','<jwplayer:source file="/sites/default/files/',$playlist);

$playlist = str_ireplace('</php>','"/>',$playlist);

$playlist .= '</rss>';

file_put_contents('public://playlists/featured_videos_playlist.rss',$playlist);

?>

<div id="myElement">Loading the player ...</div>

<script type="text/javascript">

jwplayer.key="[put your key here if you have one]";

jwplayer("myElement").setup({

    playlist: "<?php print $base_path . '/sites/default/files/playlists/featured_videos_playlist.rss' ?>",

    listbar: {

        position: 'bottom',

        size: 80

    },

    height: 380,

    width: 420

    });

</script>

The block goes through 7 steps:

  1. Load the JW Player Javascript library
  2. Read the View output with PHP's fopen function (yes it works even though there is no actual file at the uri). I tried file_get_contents, but that failed because there was no actual file.
  3. Create the specialized jwplayer:source file tag from the file uri we placed within the <php></php> labels
  4. Close the rss tag (no need to close the xml tag)
  5. Write the playlist file to the filesystem (tip - use a different filename than the path in the View!!!)
  6. Embed the player in a div in the block
  7. Load the playlist we created

The generated playlist file (for the first item):

<?xml version="1.0" encoding="utf-8"?>

<rss version="2.0" xmlns:jwplayer="http://rss.jwpcdn.com/">

<channel>

  <item>

    <title>Who doesn&#039;t like free dessert?! </title>

    <description>Manhattan College</description>

    <jwplayer:image>http://[domain]/sites/default/files/[path]/thumbnail-690_0004.jpg</jwplayer:image>

    <jwplayer:source file="/sites/default/files/[path]/MVI_4592_mp4_1384800425.mp4"/>

  </item>

</channel>

</rss>

Finally, I used Context to place the block on the desired (home) page. Some additional CSS was required. JW Player is also fully skinnable.

The result may be viewed on the Proud Campus home pageOn that page, and the user pages and video upload page, we are using a simple responsive theme Ember selected via the Themekey module, to be more mobile-friendly. The web site is under active development and has some "rough edges."

Debriefing:

The project I inherited uses the "premium" GoVideo theme by ThemeSnap and the Video module.

If I were to start fresh, I would not have chosen to use them. GoVideo is a good example of how not to build a Drupal application all in the theme templates. I have started to move many of the functions into custom modules. One benefit of purchasing the GoVideo theme is that it includes a key for the licensed version of JW Player. Also, the Video module makes some assumptions and decisions that become tricky to customize. I will replace them with a responsive theme and component media modules, to better configure the file management, transcoding and display of the videos.

However, I think that much of my solution can be useful in general, without depending on the Video Module or the GoVideo theme. Also, we are not using the Drupal JW Player module - GoVideo includes the player's JavaScript library within its theme, and we are loading it in the block from the preferred location in Libraries.

I'm not going to into detail on how the content type is created, it uses the video field provided by the Video module, but the video could have been attached to the nodes in other ways.

I'm also not going to elaborate on the transcoding process; we are using avconv (formerly ffmpeg) on our server. I have used Encoding.com in the past at a client's request, and the Brightcove and Ooyala video management services as well. Eventually we will use Amazon AWS as a CDN for the videos - when we get more funding wink

 

<?php

global $base_url;

$url = $base_url . "/sites/default/files/playlists/featured_videos_playlist.rss.xml";

$xml = fopen($url, "r");  

$playlist = stream_get_contents($xml);

$playlist = str_ireplace('<php>','<jwplayer:source file="/sites/default/files/',$playlist);

$playlist = str_ireplace('</php>','"/>',$playlist);

$playlist .= '</rss>';

file_put_contents('public://playlists/featured_videos_playlist.rss',$playlist);

?>

<div id="myElement">Loading the player ...</div>

<script type="text/javascript">

jwplayer.key="[put your key here if you have one]";

jwplayer("myElement").setup({

    playlist: "<?php print $base_path . '/sites/default/files/playlists/featured_videos_playlist.rss' ?>",

    listbar: {

        position: 'bottom',

        size: 80

    },

    height: 380,

    width: 420

    });

</script>

The block goes through 7 steps:

  1. Load the JW Player Javascript library
  2. Read the View output with PHP's fopen function (yes it works even though there is no actual file at the uri). I tried file_get_contents, but that failed because there was no actual file.
  3. Create the specialized jwplayer:source file tag from the file uri we placed within the <php></php> labels
  4. Close the rss tag (no need to close the xml tag)
  5. Write the playlist file to the filesystem (tip - use a different filename than the path in the View!!!)
  6. Embed the player in a div in the block
  7. Load the playlist we created

The generated playlist file (for the first item):

<?xml version="1.0" encoding="utf-8"?>

<rss version="2.0" xmlns:jwplayer="http://rss.jwpcdn.com/">

<channel>

  <item>

    <title>Who doesn&#039;t like free dessert?! </title>

    <description>Manhattan College</description>

    <jwplayer:image>http://[domain]/sites/default/files/[path]/thumbnail-690_0004.jpg</jwplayer:image>

    <jwplayer:source file="/sites/default/files/[path]/690/MVI_4592_mp4_1384800425.mp4"/>

  </item>

</channel>

</rss>

(the school tag is ignored

Finally, I used Context to place the block on the desired (home) page. Some additional CSS was required. JW Player is also fully skinnable.

The result may be viewed on the Proud Campus home page. On that page, and the user pages and video upload page, we are using a simple responsive theme Ember selected via the Themekey module, to be more mobile-friendly. The web site is under active development and has some "rough edges."

Debriefing:

My project uses the "premium" GoVideo theme by ThemeSnap and the Video module. If I were to start fresh, I would not have chosen to use them. Govideo is a good example of how not to build a Drupal application all in the theme templates. I have started to move many of the functions into custom modules. One benefit of purchasing the Govideo theme is that it includes a key for the licensed version of JW Player. Also, the Video module makes some assumptions and decisions that become tricky to customize. I would have used a nice responsive theme and component media modules, to better configure the file management, transcoding and display of the videos. However, I think that much of my solution can be useful in general, without depending on the Video Module or the Govideo theme. Also, we are not using the Drupal JW Player module - GoVideo includes the player's JavaScript library within its theme, and we are loading it in the block from the preferred location in Libraries.

I'm not going to into detail on how the content type is created, it uses the video field provided by the Video module, but the video could have been attached to the nodes in other ways.

I'm also not going to elaborate on the transcoding process; we are using avconv (formerly ffmpeg) on our server. I have used Encoding.com in the past at a client's request, and the Brightcove and Ooyala video management services as well. Eventually we will use Amazon AWS as a CDN for the videos - when we get more funding wink

Feb 14 2013
Feb 14

Posted Feb 14, 2013 // 0 comments

With Mobile in the forefront of digital government initiatives, laying the foundation for a mobile solution for the Department of Energy (DOE) was a priority. With this in mind, we wanted to meet this challenge for DOE in a way that was efficient and affordable. We saw a unique opportunity to quickly and easily adapt the existing site to be flexible for all devices. This bypassed a long and possibly difficult redesign process, saving our friends at DOE time and money. Tasking a single developer to work with their existing assets and make them flexible, we were able to create a mobile solution straight from their existing website.

Our starting point included a solid foundation - a static, pixel-based, 12-column grid, with some javascript doing additional layout tweaks. We knew that with this as a base, we could create a responsive solution with what DOE already had. Instead of creating a whole new design, we were able to primarily work on the front-end with CSS and not have to add too much javascript or Drupal development to the process.

Our strategy here was to start with the basics - converting the pixel-based grid to a percentage-based grid, to achieve the broadest results in the shortest amount of time. This worked quite well. Our grid was 1000px wide, which made the math quite simple; where it wasn’t we made subtle tweaks to padding and widths to make it work.

Once the grid was made flexible, we started shrinking down the page in-browser, looking for points at which the design and layout broke down. When content got too narrow or the layout just didn’t work, we added additional style sheets at these points, which switched the layout and styling up a little bit to work better. This process is detailed at Web Designer Wall.

We also made some adaptations to the large highlighted “hero” images and image galleries, so that they would provide different size images at different screen sizes, using the Adaptive Image Styles module. 

These techniques brought us most of the way towards a fully mobile-friendly site. There are a few outstanding visual pain points; that’s where we have brought our design partners, HUGE Inc., into the process, asking them to provide additional insight and guidance to this agile solution.

The success of this project is as much in our relationship with the Department of Energy and our passion for innovation as it is in any engineering techniques. We wanted to give them the best, most efficient solution we could, and their trust in us allowed us to experiment to find it.

The payoff for this approach is that, in just 65 hours of development and project conception, we have come most of the way to a fully-realized mobile solution. We are looking forward to completing this project with the Department of Energy, addressing further mobile needs and refinements. Stay tuned for the deployment of this work in the very near future!

We're working to keep Energy.gov as a model government site, not just in its overall presentation but also in how we cost-effectively manage and develop the site. This move to a mobile solution without a complete redesign is a great example of what we're working toward.
-- Robert Roberts, Director of Digital Strategies, Department of Energy

Senior Developer Joshua Turton brings a wide variety of skills to his role at Phase2. A programmer comfortable working on both front-end and server-side technologies, he also brings a strong visual sensibility to his work. More than nine years ...

Feb 07 2013
Feb 07

Design Principles for a Multi-device World

Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction.
— Albert Einstein

I would argue that a huge part of that genius Einstein refers to can be found in clarity of purpose and principles.

We all wind up in those situations where we're focusing on technical details, implementation and points of process, and missing the bigger picture. I confess I've been there far too often. When we find ourselves in those situations as designers, it's important to have some guiding principles we can remind ourselves of and even share with our team and colleagues. Guiding principles can help get everyone on the same page and make it easier to work through the details of process and implementation. They're no panacea, but they've certainly helped me maintain my sanity.

Below I've documented some of my emerging, fundamental design principles. These principles have helped guide me in this brave new world of a bazillion devices and amazing possibilities. Hopefully they'll be helpful to you as you hone your design process, document your own principles, and face challenges along the way.

    The mobile web is important!

    Secret: 98% of the following three paragraphs I learned directly from Luke Wroblewski. If you need help making the case for a focus on mobile, read his writing, see him speak, get in touch with him!

    Why care so much about mobile in our design process? By Q1 of 2012 Apple released numbers that showed there were now more iPhones sold every day than babies born in the entire world (300k babies to 402k iPhones)! That was just iPhones, there were actually 562k iOS devices (which includes iPod Touch and iPad) sold each day at that time. By Q1 2012 we'd also reached 700k Android devices activated per day, 200k Nokia smartphones and 143k Blackberry devices. According to Morgan Stanley Research, by 1990 there were 100M+ desktop internet users. By the early 2000's we had reached 1B+ desktop internet users. Today that number of desktop internet users is only slightly higher than it was in the early 2000's, yet the number of mobile internet users is now 10B+! The number of mobile devices on the planet surpassed the number of humans on the planet nearly two years before Morgan Stanley's research predicted it would, which means mobile is not only ubiquitous, it's growing faster than our expectations.

    But wait, there's more! In Q1 of 2012 Facebook announced they were seeing more people accessing Facebook on the mobile web than from ALL of their top mobile native apps combined! Facebook also released data suggesting that mobile web and app users invested noticeably more time on site than all of their Desktop web users combined. In Q3 of 2011 Nielsen US released their research on mobile users showing that of the millions and millions of mobile users across all platforms, significantly more were using the mobile web as opposed to native apps when given the choice (57M vs 49M).

    Create once, publish everywhere.

    Editorial teams need a singular, simple workflow to produce content once that then gets distributed efficiently and effectively to all device types. Editorial teams need to be focused on content quality, NOT things like device level placement, layout and aesthetic style. When developing your content model, model content types on core editorial and business needs, with an eye towards multi-channel reuse. You can then use those building blocks in the design process. This will ensure that editors aren't forced to become "designers by default". Ideas about form, structure and presentation that create new and more complex processes for editorial teams should be viewed with skepticism and caution. Anything that slows the editorial process, without adding significant content value, damages the core value in your product. A COPE approach (Create once, publish everywhere), with a consistent content model and simple data feeds that can be used by web-based widgets, apps, and business partners, helps facilitate rapid experimentation and innovation. It ensures that experimentation can happen at "the edges" without requiring foundational infrastructure changes.

    Editorial workflow is important!

    It's very easy for design teams to become focused on the consumption experience for content on a website, while completely ignoring how said content is created, reviewed, edited, curated and published. Great consumption experiences begin with great creation experiences. Spend time with the authors, reviewers, editors and publishers early in your design process. Watch what they do. Learn about the content they're producing. Gain an understanding of things like volume (how much of it do they produce), frequency (how often do they produce it) and average length (how much content makes up a single piece) for every type of content they're producing. As a designer, you can't create innovative ideas for new components and interaction methods without really understanding the content, and the best way to understand the content is to spend time with the people who create and nurture it.

    The second part of this principle is that bad or painful editorial workflows create content problems. Also, eliminating editorial workflow pain points makes happy clients. You may not be able to solve all the problems of an editorial workflow process as a designer, but you can play your part in the process by treating it as important.

    Release early and often.

    "Write drunk, edit sober."
    — Ernest Hemingway

    Always err on the side of the simplest viable product for each release (see KISS principle as well as Getting Real). Make quick decisions, make something, find out how users interact with it and what they're valuing. Discover pain points. Adapt. In a competitive market place we need to iterate quickly and fail gracefully. Failing is necessary for innovation, and we can't fail till we try something. Create a culture of rapid experimentation as opposed to analytical paralysis.

    Make existential design decisions based on data, 
not assumptions.

    By "existential design decisions" I mean decisions about whether a particular piece of content or component should exist on the screen. The basic rule here is don't remove things from a mobile experience because you assume mobile users don't want it. Conversely, don't add additional elements to a desktop experience because you assume those users want "enhanced experiences." Begin by delivering one content model and architecture across all devices, and then let real user data drive device specific optimization and customization.

    Mobile users will tell us what they're wanting as they use things (or don't use things). Their interaction patterns, values and preferences can guide optimization and customization, but not until we have them. We need to release something and watch people use it before we form assumptions (see earlier release early and often principle).

    Begin with the basic question of "Is this valuable for users?", not "Is this valuable to users on a particular device type or screen size?". While we may make some assumptions about hierarchical discrepancies from one device type to another, always start from the assumption that if it's important to users, it's important to ALL users.

    It's worth noting that gathering web-based metrics about the behavior of mobile users is easier than logging and tracking the detailed interactions of mobile app users. The mobile web experience can lead the way for us, providing the data we need to understand user values and interactions. Mobile users continue to defy expectations as to what they will do and want to do on their mobile devices. A common frustration for mobile web users happens when assumptions are made about what mobile users do NOT want or need from a desktop experience. It's extremely important that we not limit mobile users based on these assumptions. Creating tailored experiences with unique content models and components for different devices can create significant user experience problems. For example, lets imagine google indexes the desktop version of a website, and provides links to said content on mobile devices based on a search. If those mobile devices then redirect to a tailored site with a limited content model, editing out the content that was searched against, confusion and user frustration ensues. We must never dumb down or limit a desktop experience and call it a mobile experience!

    Design from content outward (not device type or display inward).

    Focus first on delivering the best and simplest possible experience of a complete content model across all devices. Design should begin by uncovering the most valuable type(s) of content, and designing an experience for those. All subsequent displays and views into that content should follow. For example, a news site could begin by determining the most valuable type(s) of news content they provide to their consumers. A design team can then begin researching, wireframing, prototyping and brain storming around the consumption experience of a representative piece of content from each of those types. Once that is fleshed out, the focus can shift to the various structural channels through which parts of that content type are displayed (e.g. a homepage, a top level category landing page, etc.).

    Nothing's more important than knowing what's important.

    "Design is the conscious effort to impose a meaningful order."
    — Victor Papanek

    Design is about helping people understand what's really important and meaningful. That's beautiful. Embrace it! Discover and understand the relative importance of each type of content, the pieces that make up that type of content, and the channels through which that content flows. You can't begin to apply visual hierarchy in design without first knowing the content hierarchy. Design decisions should begin with broad hierarchy evaluations. Develop a components list for each screen (a list of the discreet pieces or chunks of content that exist on the page) and assign a relative hierarchy (e.g. a 1, 2 or 3) to each component in the list. After all that, you can begin to work things out visually with placement, proportion, and style.

    Design mobile first.

    Once again, Luke Wroblewski has shined a spotlight on this and helped me understand it.

    Designing "mobile first" means that we embrace the constraints of a tiny screen early in our design process. We evaluate our content model, components list and hierarchy first with that tiny screen in mind. Once we've established that, we then ask if there are ways that hierarchy changes or interactions can be enhanced for users with screen sizes and bandwidth capabilities beyond mobile. The constraints of the mobile screen size help enhance focus during the design process and keep design teams more closely aligned with whatever the core product value is. It's like packing first in a carry-on suitcase to discover what you REALLY want to bring. Often, you'll find that those extra things you put in your larger suitcase never get worn or used.

    This does NOT mean that the visual experience can't be impressive. Remember, in many ways mobile devices have MORE capabilities than what's common among desktop devices. Things like device positioning, motion, location detection, multi-touch, gyroscope, and audio, video and photo input are common among mobile devices. Design teams may actually create more innovative and rich experiences focusing on mobile first during their design process.

    Optimize, then customize.

    After we actually make and release something, and have real user data to drive the next round of iteration and innovation, we need a way to prioritize that iteration. When both optimizations (e.g. technical solutions to serve up smaller file sizes or more appropriate ad sizes) and customizations (e.g. ideas about changes or enhancements to hierarchy, content or features) are being considered, optimizations should almost always be prioritized over customizations. Great experiences come from the ease and speed with which users can access, interact with, and contribute to content, and that ease and speed are very important. Mobile users continue to defy our assumptions about what they want to do on mobile devices, but they almost always want to do it faster and with greater ease.

    Create and maintain a visual language (NOT a myriad of distinct designs).

    Design teams need to produce a flexible visual language that can provide stylistic guidance across a myriad of screen sizes. There are some formal processes and design tools that can help you do this (e.g. element collages, style tiles, web style guides), but the core principle is to establish a visual language that can allow for quick design decisions across all breakpoints. This approach reinforces the "release early and often" principle above. Having a style guide and other tools to guide visual decisions, rather than a collection of concrete designs tied to specific device widths and scenarios, means that new experimental designs don't have to chart their own course. A design process that takes a tailored approach, providing a myriad of custom static comps can dramatically limit your ability to quickly respond and innovate.

    Dec 11 2012
    Dec 11

    Drupal 8, originally scheduled for an August 2013 release, will from all appearances not just be another version upgrade. There will be extensive improvements on issues that matter to all types of Drupal users. That last sentence doesn't do it justice. Really Drupal 8 will be a quantum leap among Content Management Systems and Web-Application Frameworks.

    Who will Drupal 8 benefit the most, users or developers? This is hard to quantify, but so far it seems that the end user will feel the biggest shift. The most dramatic changes for end users will be a simplified interface for content modification, and improved mobile compatibility. But these are not the only enhancements that are underway for what is undoubtedly the most ambitious Drupal version to date.


    If you can post to Facebook, You can post to Drupal 8

    Posting content will be as easy as it is on popular social networking sites. If you can post to Facebook, you will be able to post to Drupal without any additional training. The usability for site managers is also markedly improved. This is all due mainly to the Spark distribution work which allows in-place editing, see http://drupal.org/project/spark. The goal is that content creators, site managers and end users will have the option to just click what they want to edit on a page, like the title, text, or images and change them directly without having to switch to an administrative editing interface. I know that end users have instinctively tried to edit content just by clicking on blocks of text when given Drupal without any training. This update will make the process of seeing what your changes look like as you compose feel entirely natural.


    Mobile

    Drupal 8 is setup for mobile in multiple ways. The new Drupal is being built so that from the moment of first use, you will be able to interact with your site on both traditional and mobile displays. Additionally, work is underway towards “responsive layouts” which allow site creators to place regions of text, graphics and other elements so that everything appears readable on mobile devices and your laptop, auto adjusting size and orientation to whatever you are using at the time. Mobile apps will also be able to tie into Drupal 8.

    Say you feel like logging into your Drupal site and checking on new comment activity, but you only have your mobile phone. With Drupal 8 you'll be able to do that with an interface that works well with your mobile device; no scrolling around and trying to enlarge text. While much of this is possible with Drupal 7 with extra setup beforehand, we're going to see this become the standard on Drupal 8.


    HTML5 and High-Performance

    Drupal 8 does HTML5, the shiny new version of Hyper Text Markup Language that supports video, audio, better forms, 2D/3D graphics and animation. That's just the start of the great things HTML5 offers and it's with Drupal 8 it's already built in, link: http://www.switched.com/2010/05/11/what-is-html5-and-why-should-you-care.

    Major work is going towards performance improvements in Drupal 8, we'll be blogging later to explain how. To generate pages suitable for a variety of devices it is important for Drupal 8 to be quick, and major progress is already underway to enhance speed, mainly on the “front-end,” and that means on your end-user device.

    Lastly, efforts are being made to include back-end wizardry which allows custom apps to connect to the Drupal database in standardized ways using new and improved Web-Services. Web Services are how different computer devices communicate with each other over the Internet. When you visit somewhere else in the world it is good to speak the language, in this case the computer's language. Improved Web Services allow your Drupal 8 site to communicate better with the world, that is other applications, be they mobile or most anything else which speaks these standardized data languages.


    Other Initiatives

    The other main initiatives, overlooking all the many tweaks and interface improvements are: multilingual, design, and configuration management (and the Views module group is in core).

    If you have a multilingual site, or more to the point, want a multilingual site, Drupal 8 now includes the language systems in core. So adding languages and translations is more like installing or updating modules.

    Designers will also see big changes with the way themes are made using Drupal 8, and given the mobile initiatives this is imperative. The goal here is to make design (theming) work better. The end result is cleaner and more elegant web design.

    There will also be improvements in configuration management. When creating sites, most developers have multiple installations of the site, development, staging and production, or minimally development and production. In Drupal 8 configuration management makes it easier and methodical to maintain these separate installations while simplifying deployment of new code, updates and alterations. Besides the time saved for developers, these procedural improvements will benefit site owners because their site can be better maintained, more stable, and more secure.

    Recently the Views module has been added to core. If you don't know what Views is in Drupal, suffice it to say that now, with a default Drupal 8 installation, site-builders will be able to make complex web applications, similar to many of the popular ones we know and love, like Twitter for instance, without adding additional external modules (of course you may end up adding just a few of the thousands of available modules to add some cool functionality). Yep, it's excellent.

    That's a long list so far and that's just the beginning. Drupal 8 has even more in store for all of us due the large and growing community of ambitious and hard working contributors.


    This blog entry is based on an informal presentation and post-discussions about Drupal 8 given by Darrell Ulm at Drupal Camp Ohio 2012.

    Nov 09 2012
    Nov 09

    Listen online: 

    Jeff Eaton and Karen McGrane discuss the rise of mobile; the challenges of transitioning to reusable content; and Karen's new book, Content Strategy for Mobile.

    Mentioned in this episode:

    Release Date: November 9, 2012 - 10:00am

    Album:

    Length: 31:03 minutes (16.48 MB)

    Format: mono 44kHz 74Kbps (vbr)

    Nov 09 2012
    Nov 09

    Listen online: 

    Jeff Eaton and Karen McGrane discuss the rise of mobile; the challenges of transitioning to reusable content; and Karen's new book, Content Strategy for Mobile.

    Mentioned in this episode:

    Release Date: November 9, 2012 - 10:00am

    Album:

    Length: 31:03 minutes (16.48 MB)

    Format: mono 44kHz 74Kbps (vbr)

    Sep 27 2012
    Sep 27

    Lullabot's Drupal training site turns 2

    It's been almost 2 years since we launched Drupalize.Me and I'd like to take a moment to appreciate some of the site's recent accomplishments.

    Over 600 Videos

    A few weeks ago, Drupalize.Me product manager Addison Berry announced the 600th video posted to Drupalize.Me! Members now get access to over 233 hours of content on an immense range of Drupal-oriented topics from simple content creation to site building tricks and database server performance optimization. Drupalize.Me's most popular videos cover coding for and using Views, using the Calendar and Date modules, configuring WYSIWYG editors, Display Suite, Organic Groups, Drupal 7 module development, and more. The Drupalize.Me team has been really amazing – posting new videos every week and paying close attention to member requests for new topics.

    Over 2,000 Subscribers

    Word about Drupalize.Me has spread and I often see people on Twitter telling one another that for them, Drupalize.Me has become the way to learn and keep up with Drupal techniques. Drupalize.Me has iPhone/iPad, Android, and Roku apps so members can watch the videos on their mobile devices or televisions. Drupalize.Me has also partnered with Acquia to offer discounted memberships to Acquia Network subscribers.

    As word has been getting around about Drupalize.Me, subscriber numbers have been growing and recently crossed 2,000 simultaneous subscribers. We're reaching more people on a monthly basis than most large-scale Drupal events. We couldn't be more excited about the response!

    Drupalize.Me now has a staff of 3 full-time people creating videos, maintaining the site, adding features and handling customer support. This team is augmented by others at Lullabot who step in to help with expert video training, development, design and support. Drupalize.Me now represents more than 15% of Lullabot's budget and has become a great outlet for the Lullabot team to share the knowledge that we've gained building the high-profile websites that represent the majority of our work.

    New Features

    The Drupalize.Me team has been listening closely to subscriber feature requests and we've gotten lots of new features over the past 2 years. They've arranged videos into "series" collections and allow users to watch them consecutively. They've also added curated "guides" collecting videos into linear curriculum for different types of members. They've also greatly improved the user dashboard pages allowing users to manage their queue as well as see the listing of recently watched videos and even displaying a line graph so members can see their progress within the videos they've watched. The team also added the ability to store pause points and allow users to resume from exactly where they left off - even if they're resuming on a different device such as their phone or connected television.

    And speaking of connected televisions, we've got apps! We've got an iOS app for your iPhone/iTouch/iPad which can AirPlay to your AppleTV. We've also got an Android app and an app for the Roku Streaming Player box. You can pick up a Roku box for as little as $50, hook it up to your television, and watch all of the Drupalize.Me videos from your couch. It's a great way to learn.

    Group Memberships

    Drupalize.Me also offers group memberships. If you want Drupal training for your entire group, department, company, or institution, we offer that too. Group accounts greatly reduce the price of individual accounts while still allowing each group member to manage their own video queue, resume videos, and see their own history. We offer both managed group plans and IP-range plans to allow access to all devices at a physical location such as a library or campus.

    Subtitles, Transcripts & Translations

    Perhaps the greatest new features at Drupalize.Me are the ability to offer subtitles, transcripts, and translations for the videos. We have many international subscribers who, while they speak and understand English, sometimes can't keep up with the rapid-fire technical information in the videos. They've been asking for English-language subtitles and transcripts so they can follow along better. We're proud to say that we've added this functionality as well as functionality to provide complete translations with subtitles in other languages! 60 of our recent videos as well as the complete Introduction to Drupal guide already have transcripts and subtitles. And all new videos published on Drupalize.Me in the future will have transcripts and subtitles.

    We're currently looking for volunteers to do foreign language translation for Drupalize.Me. If you're a bi-lingual Drupalist and you'd like to help make bring these Drupal training videos to the world, please contact us!

    Drupalize.Me & Videola

    One of the Drupalize.Me team's biggest accomplishments is building the Drupalize.Me site itself. The team has built a great Drupal-based platform which manages both the permissions and delivery of adaptive bitrate streaming video; recurring subscription billing and administration; video content categorization, listing, and organization; mobile app and IPTV delivery with seamless pause-on-one-device-resume-on-another functionality; and now even multi-language subtitles and transcripts.

    As we've been building Drupalize.Me, we've been funneling this work and knowledge into Videola, a platform to provide this functionality to others wanting to build subscription-based or IPTV-oriented video sites. In short, Videola is a framework for building sites like Drupalize.Me... or like Netflix, Hulu, or Amazon video-on-demand. Videola can do everything that Drupalize.Me can do and more. If you'd like to build a site like this, please contact us and we can talk to you about getting you set up with a Videola site of your own.

    Onward

    Addi and the rest of the Drupalize.Me team have been doing a lot of training at DrupalCons, DrupalCamps, and other events. They've been very involved in the Drupal Ladder project and have posted a series of free videos to help new Drupalers get involved with core development.

    Drupalize.Me recently started its own podcast (which picks up where the long-running Lullabot Drupal Podcast left off). Every other Friday, the Drupalize.Me team is posting a new podcast with interviews and discussions to help listeners keep up with the ever-changing world of Drupal. The team is also constantly upgrading and improving the site and they've got lots of great feature ideas for the future.

    I couldn't be more proud of the work that's been done by Addi Berry, Joe Shindelar, Kyle Hofmeyer, and everyone who's helped with Drupalize.Me over the past 2 years. The site just keeps getting better and better. At this rate, I fully expect that 2 years from now I'll be bragging about their Drupal training neural implants and interstellar 3D streaming. But for now, I'm really happy with where we are – doing great, having fun, and sharing knowledge with people, empowering them to do great things.

    Aug 09 2012
    Aug 09

    Posted Aug 9, 2012 // 0 comments

    Recently we were tasked with taking on the Thomson Reuters Olympics website which involved many intricate components including the task of developing a mobile specific theme for their android users and other non-iOS devices (iOS got a separate app). I was quite excited for this task, as it stepped away from the idea of responsive design and instead focused on a lightweight mobile specific theme and content. There is still plenty of debate whether a website should be responsive for all the devices it’s viewed on, or if a theme specified for a medium is appropriate.

    Mobile vs. Responsive

    In the case of Thompson Reuters Olympic website, it was determined that a mobile specific theme was a better solution than creating a responsive website. The desktop theme has a plethora of widgets in the right rail which wouldn’t translate well to the mobile theme, so the plan of action was to create a single content region with a listing style layout. Although the website is built on the Omega theme at its core, (which is mobile first/responsive), it was primarily used for its HTML5 abilities, built-in grid system, and region configuration. This proved to be a great time saver for the mobile theme with most of the legwork already completed with Omega’s default settings.


    Although the ultimate goal of this theme was to address users on a mobile platform, responsive design was found not to be the correct solution. The amount of content displayed would have hindered a responsive layout and experience, so it was better to have a streamlined solution and go with a mobile theme.

    The mobile theme came together quite nicely with content being placed inside of the main content region and stacked vertically. Custom mobile tagged contexts were used to place the blocks in the appropriate order in accordance to the comp, (more on this later). The custom contexts allowed us to place only the content that was useful rather than serving the user all the content and hiding it via CSS, thus avoiding increased http requests and overall load time.


    Using Custom Tagged Mobile Contexts

    Going back to the custom tagged mobile contexts, there were a few technical challenges which lead us to that solution. The first challenge was the obvious problem of having completely different layouts for the desktop and mobile versions of the site. Creating a separate set of contexts tagged with ‘mobile’ enabled us to place content blocks in the regions that we needed them to be in. The second and more difficult challenge was the complex and multiple layers of caching in place at various levels of the project; Acquia, Akamai and Varnish. Even with the ability of creating a different set of contexts for mobile, there was still a high chance that mobile users would be served the desktop context sets just because of the caching. Switching contexts at the drupal level was not an option because of this factor.

    The final solution, by Team Architect: Tobby Hagler, was brilliant and simply elegant: Akamai was already setup to do redirects to ‘m.’ urls for mobile devices. In knowing that fact, Tobby created a patch for context that would detect the domain (in this case ‘m.’) and call the mobile tagged contexts in the DB and turn those on rather than the desktop context set. Et Voila: a mobile site with the exact content that you want. So rather than device detection, this is a domain detection scheme where we already know the domain will be device specific with ‘m.’.

    Mobile web doesn’t have to be a daunting task by any means. With the proper game plan, it can actually flow together quite nicely. Unfortunately there can always be the curve balls that come into play. Even with reading countless articles on creating mobile specific and responsive websites, sometimes it comes down to the core pieces of the web that give us the biggest headaches. In this case, cache didn’t make the world go round, but proved to be a fun challenge to overcome.

    Josh Cooper’s user interface development skills play a vital role in bringing great design ideas into fully functioning websites.  His specializations in HTML, CSS, Javascript plus his focus on Drupal as a platform, make Josh an ...

    Jun 20 2012
    Tom
    Jun 20

    In February 2012 our team at ConsumerSearch launched the ConsumerSearch Reviews iOS app. This handsome app helps you during your product purchase by providing extensive product reviews, comparisons, pricing information and online and local store product availability. Try it out during your next purchase -- you'll be surprised how much time you'll save in researching the best products.

    Searching for products is possible by keyword search or barcode scanner. We are very proud of our first app that has already gone through several updates and has received positive user reviews.

    cs-iphone-screen-1cs-iphone-screen-1
    cs-iphone-screen-2

    For a development team that historically had a huge focus on PHP and Drupal development, big technology changes were introduced that took us out of our comfort zone.
    Of course we all know about the latest technologies, however making production ready code in a short amount of time is always a risk and a challenge (that we welcome :)).

    I feel that many (Drupal) development teams are facing similar questions when moving to new technologies, so I hope this use case can give developers familiar with PHP and Drupal some quick guidance or fresh ideas. Feel free to ask me questions or provide feedback in the comments section.

    ConsumerSearch is powered by Drupal

    It's no secret that ConsumerSearch has been one of the earliest examples of highly trafficked Drupal sites since it switched to Drupal in 2008.

    We manage to serve our huge traffic load by relying HEAVILY on caching (browser, Drupal, memcache, and Akamai).
    This reliance on heavy caching in order to deliver super fast performance is one of the weaker points of our (and many other) websites, especially in a world where we aim for real time and personalized experiences.

    While creating the architecture and technical specification for our API backend we realized that some drastic changes had to be introduced in order to create a highly performant and flexible API that could serve as a data source for the mobile application and for additional users.

    We eventually settled on the following technology:

    • Drupal as our CMS which handles all the content creation. Drupal pushes updated and new content to MongoDB and Solr.
    • MongoDB as our intermediate storage layer to where we push all Drupal content in a heavily denormalized way. The API application layer queries MongoDB directly.
    • Acquia Search powered by Solr as the search index. This powers search related API calls.
    • Node.js as the API layer. We use Pronto.js for our lightweight, high-performance node.js framework.

    This gives us a nice open source stack that plays very well together in creating a flexible and highly performant content delivery system.

    CS API overview

    As a side note, our team had limited to no experience with Node.js and MongoDB before working on the iOS app. Even today these technologies only account for a very small part of our day to day business. However both solutions proved to be relative easy to learn and master.

    Speeding up and choosing the right technologies

    We've been using Drupal 6 for the past couple of years and benefitted greatly from the flexibility of its content model (CKK), its presentation possibilities (views / templating engine) and the huge amount of contributed modules available (too many to name). However, where these tools have given us incredible speed during initial construction of the site, we have gradually experienced some of the unfortunate drawbacks of Drupal (which are also present in many other Content Management Systems). Some of these drawbacks include:

    • Speed and performance: We need to rely heavily on caching and scale out our web server infrastructure in order to provide speedy pages. Part of the speed problem is the heavy customization of our website (our fault), but also the nature of the Drupal architecture.
    • Module compatibility: As an example, we have a robust deploy process that depends on the deploy module. However, this module is not compatible with the new and recommended Services 3.x module.
    • Module scope: Very often, Drupal modules try to do too much. I have also been guilty of this while, for example, working on the first versions of the Mobile Tools module. If you want fast and lightweight, you want focused modules. Often you have to write the functionality yourself or find a different module/solution.

    Eventually our research on using Drupal as a fast and lightweight API layer came down to the fact that Drupal was just not lightweight, fast or simple enough. It can, of course, be tuned so that it is some or even all of those things, but why choose the hard way when other technologies can give you those features out of the box? We value simplicity and focus within our development team and projects, but Drupal, unfortunately, is just not always simple or focused.

    With speed, flexibility, and simplicity as our goals we made the following assumptions:

    • Storing our data in a denormalized fashion should speed up the the retrieval process.
    • Storing the data schema-less should result in shorter development time.
    • Using very dedicated code should make the application lightweight and fast.

    Further, the API would have the following characteristics:

    • The database should store simple documents with no revisioning (Drupal keeps track of that) since our content doesn't frequently change.
    • The API should focus on getting data from the database -- no write operations needed.
    • The data should be replicated across multiple data centers.
    • The architecture should easily scale out across multiple data centers.

    Denormalization of the data

    Loading content stored in Drupal can be very DB intensive due to the underlying content storage model. Data is scattered in many tables, and when you rely on node references you end up making a lot of DB calls. So we decided to preprocess our data and store complete data objects in a denormalized way so retrieval becomes easy and fast.
    For this we wrote a custom module, loosely based on the Apache Solr Drupal module that publishes some of our content types in a denormalized way in MongoDB. Some of the transformations we performed include:

    • removing fields that were only used internally or specific to Drupal.
    • giving fields Drupal-agnostic names.
    • collapsing some of the CCK arrays (e.g. "field_name[0][value] into "field_name[0]")
    • other content tweaks that made the resulting data object easy to understand.

    We ended up with a series of collections for our primary objects: reports, products, channels, authors, etc.

    MongoDB as a document store

    It did not take much research to determine that MongoDB was an ideal choice as the database to store our denormalized data. Some of our key reasons for choosing MongoDB were determined by the fact that:

    • JSON is the native format to store and retrieve data. JSON is currently the DE FACTO standard for web APIs.
    • as a document store, it is natural for MongoDB to store denormalized nodes.
    • querying MongoDB is easy and intuitive. Although different than SQL it is very easy to dynamically create queries.
    • MongoDB has good driver support in many different languages and inv.
    • it provides easy replication using Replication Sets, resulting in read scalability and fail over.
    • reads and writes are scalable through Sharding.
    • it's lightning fast
    • and on and on.

    While researching other storage databases, we learned that MongoDB isn't perfect at everything, but it is more than good enough for our needs. Some of its missing features include:

    • key-value stores like Cassandra and Reddis can reach much higher speeds.
    • no master-master replication. In our case that would mean having the possibility to have two active master data centers.
    • no document versioning like in CouchDB.

    For each content type that we needed access to in our API we created a MongoDB Collection. We also setup a replication set across our our two data centers with an additional arbiter in a third datacenter.

    The replication set gives us read operations across all the machines in the set, while writes still go to the primary database. In order to scale writing, sharding is the recommended technique.

    Node.js as the API application layer

    While it was clear that Drupal would never give us the required speed for our API (unless relying 100% on cached responses) and that MongoDB was an easy scalable solution to store our data, heavy debating occurred in choosing the application layer for our API. Would we stick with our familiar PHP environment, or would we explore other ways (Ruby, Node.js, etc.)?

    The main high-level requirements for the API in our case were:

    • simple routing of API requests; no templating, CMS functionality, or heavy administration.
    • the ability to handle many I/O operations, including connecting to MongoDB and various third-party data providers.
    • the need to minimize dependencies on the content model in Drupal. For example, adding a field to a Drupal node should not result in changes to the API.
    • the ability to handle JSON well.
    • it needed to be as fast as possible.
    • it must be easy to learn, or at least minimize the learning curve for the team.

    We narrowed the list down to PHP (we all know that one very well) and Node.js (new kid on the block, we heard many great things about it, etc.).
    Node.js has been shown to be really fast thanks to the V8 JavaScript engine also used in Chrome. However, our researched showed that Node.js is not always the best solution for every problem.

    Many of the Node.js related discussion in our team (and elsewhere) focused on the "blocking" versus "non-blocking" nature of Node.js and on its internals. I imagine that this discussion will be one of the most popular ones within teams that are new to Node.js. I'm going to try and summarize these discussions using the following examples:

    1. Node.js

    Node.js uses an event-driven, non-blocking I/O model. This means that I/O bound operations such as external connections, accessing a database and file operations do not block the execution of the main thread. Instead they are executed by a low-level Node.js thread pool and when completed are queued back in the main thread for further handling.
    On top of that Node.js runs by default in one thread on the server that sequentially handles all incoming requests, returning callbacks and non I/O related processing logic. An example would be an algorithmic complex calculation (like a Fibonacci sequence).

    In the following diagram you can see what is happening in a typical Node.js application where:

    • there is one main thread
    • there is a low-level (and very lightweight, low-overhead) thread pool that handles the non-blocking I/O operations.
    • incoming requests and finished I/O calls are put on the event queue and await processing by the Node.js main thread.

    As a result, processing in the main thread can block your entire application (which is very bad). Luckily, workarounds are available to move complex operations out of the main execution thread.

    2. Apache with PHP (Prefork)

    In Apache, when using mod_php and assuming you use Prefork MPM (because PHP is not thread safe), every incoming request spins up a new process in a different thread. This means that if one thread hangs, it will not block the other threads. This is one of the strong benefits in using PHP and Apache.
    However, I/O bound operations are blocking since the execution of further code waits until the I/O operation has finished (see dashed lines). This waiting reserves system resources that are heavily underused. Spinning up new processes also results in overhead on your system.

    In a nutshell, you could say that Apache with PHP could be seen as a safe bet, but not the most performant one.

    In the case of the API, we did not have complex calculations and the main part of the execution consisted of connecting to MongoDB for authentication and getting data back. Node.js was clearly a winner.

    Pronto.js

    For the API we settled on Pronto.js, a great and highly performant Node.js framework developed by long time Drupal developer Matt Butcher while he was a member of our team at ConsumerSearch.
    Pronto.js is in many ways similar to the well known Connect framework. Pronto.js provides an easy interface to create chainable commands to execute on a request.

    Many tricks are used to minimize the blocking nature of incoming requests. We've since made enhancements to Pronto.js that provide non-blocking execution. I'll cover that in a subsequent blog post if it warrants discussion.

    Wrapping it all up

    We have been running this setup now for almost 5 months with no problems. Development was fast and lightweight.
    We experience super fast response times and very low server load. Benchmarks show that we can easily hold 1000 concurrent connections serving 4000 requests/second on two mid range servers. We actually need to scale up some of our testing infrastructure to explore the real limits :) Try our free app and see for yourself.

    Further optimizations we are exploring include:

    Please comment to share your experiences with these technologies or if you have any questions or comments. You can also follow me on Twitter: @twom.

    Special thanks go out to Treehouse Mobile for collaborating with us for creating the iPhone app, and our development team for suggestions and corrections on this blog post!

    View the discussion thread.

    May 22 2012
    May 22

    The short story

    Come and help us perfect and implement the hot new mobile interface design in Drupal 8. Try the prototype on your phone. Also, go to the issue queue.

    The long story

    Over the past six months we've been working on designing the experience of getting to where you want within Drupal's admin interface.

    I originally identified this as top on the list of priorities for the Mobile UX because it's so important. We had a great feedback loop going at the regular mobile and usability meetings and I iterated through a

    Here are some of the cool solutions that came out of this process:

    A redesigned toolbar

    It was obvious pretty early on that we couldn't show all the menu items at once, we need some method of revealing them. What became really interesting was the thoughts on what else we could use the rest of the toolbar space for. The prototype contains toolbar buttons for global functions like search; and contextual functions like filter, sort, and delete.

    A sliding navigation

    Animated transitions between pages is more than just sugar on top. It maintains an association between pages. This has become ubiquitous on touch devices. The prototype took it further by adding a full screen swipe gesture to move back up the navigation tree.

    I also knocked together a very rough second prototype that maximizes touch gestures to create a layered card metaphor.

    Global search

    A nice, friendly, easy to use navigation tree is great but some users want to get around fast. We don't want newbie friendly interface to hold back power users. A global search function works like a teleport, allowing users who know what they want to get there quickly. A proof of concept exists on all pages of the prototype.

    Other less exciting things

    Apr 24 2012
    Apr 24

    Listen online: 

    Kyle Hofmeyer talks with John Albin Wilkins about the Mobile Initiative he is spearheading for Drupal 8. John discusses what this means, what's involved, and how you can help.

    This Drupal Voices was recorded at the 2012 DrupalCon in Denver.

    Release Date: April 24, 2012 - 4:00pm

    Album:

    Length: 7:07 minutes (4.94 MB)

    Format: mono 44kHz 97Kbps (vbr)

    Feb 04 2012
    Feb 04

    Posted by Graeme Blackwood on Saturday, 4 February 2012 at 6pm

    One of the most important and complex aspects of a DrupalCon is the schedule. An enormous amount of work goes into getting it right – from the huge number of session submissions, which have to be reviewed and selected by the track chairs and their teams, to the people whose job it is to carefully consider and decide time slots for all of them.

    Once all of this work has taken place, the schedule then needs to be presented, in print, on meter boards, posters and in the delegate guide, as well as on the website and mobile app.

    With around 70-80 sessions over three days and eight tracks, with three possible skill levels and multiple presenters, all split up into different time slots, and sometimes sub-time slots, presenting this lot is not a simple task. I had some great people working with me on the London schedule and I think we did a pretty good job.

    For Denver, the plan was to take the schedule a bit further, making it responsive so that the layout adjusts to the size of the screen you are viewing it on. This is particularly useful for mobile phones and tablets, on which the user experience would be very poor if the design wasn't responsive. Initially the Denver team were looking at a table format for the schedule, similar to the Chicago approach: http://chicago2011.drupal.org/schedule. This layout is really good, but tables don't do well with responsive design. Tables have no way of rearranging themselves – if the width of the table shrinks, the cells just squash horizontally until they are stopped by the longest word in each. This looks pretty horrible and usually breaks a website's layout on smaller screens.

    DrupalCamp Austin did use a semi-table layout, and importantly, it doesn't actually use table markup, meaning it can collapse. This worked well because the number of sessions in a given time slot was limited. Denver's maximum is seven sessions in a single time slot, which even in a 960 set up, would be really squashing them in on a single row and force them to collapse almost immediately on the slightest resize.

    Drupalcamp Austin's horizontal schedule layout

    So a different method was needed. Initially taking the approach of a mobile web app, I put together an example schedule using Denver's branding to help demonstrate how it could collapse on smaller screens. The main difference in this layout is that instead of side by side, the sessions are stacked, divided by the time slots. The track icons were produced for Drupalcon Chicago and it felt really right to pick them up again for Denver.

    The Denver team then adapted the prototype to fit the website and extended the icon set to cover the new tracks. While implementing, they made some subtle improvements to my prototype, like the track title on hover: http://denver2012.drupal.org/program/schedule

    Drupalcon Denver web app prototype

    There are definitely more improvements to be made. The hit area isn't very large on the sessions (only the title), so it's not always easy to press with your finger; wrapping everything in an a tag would resolve this. The rooms aren't displayed yet, which would be pretty useful to help you find your way around and some of the sessions don't fall into specific time slots, so we are working on adding these soon. Also the filters are yet to be implemented on the Denver site, but it is worth looking at the prototype on a mobile device to see how I envisaged them working.

    This is of course, just one example of a schedule for one event format, but if you are reading this from inside or outside the 'Drupalsphere', I hope you found some of the ideas useful.

    Categories: drupal, DrupalCon, Mobile, Responsive, UX

    Jan 20 2012
    Jan 20

    Quick Mobile Device Detections

    Posted on: Friday, January 20th 2012 by Justin Tsang

    Here are a few ways to detect if the user is coming from a mobile device. Used for redirection, different interfaces, or special cases.

    Javascript:

    PROS: Most common solution.
    CONS: Many mobile devices don't support Javascript or users turn it off.

    <script>
      var isMobile = navigator.userAgent.match(/(iPhone|iPod|iPad|Android|BlackBerry)/);
    </script>

    Use CSS @media handheld or screensize

    PRO: Way to display certain CSS styles for mobile devices.
    CON: Many Cellphones don't support the handheld media type, they display their pages with the screen media type by mistake.

    <style>
      @media handheld{ .icon { display: none; } }

      @media only screen and (max-width: 999px) {
        /* rules that only apply for canvases narrower than 1000px */
      }

      @media only screen and (device-width: 768px) and (orientation: landscape) {
        /* rules for iPad in landscape orientation */
      }

      @media only screen and (min-device-width: 320px) and (max-device-width: 480px) {
        /* iPhone, Android rules here */
      }
    </style>

    Use PHP or your coding language of choice

    PROS: Does not rely on script language or CSS being supported by phone.
    CON: Lots and lots of other potential user-agents that are used by mobile devices may popup in the future. The code will catch some of them but not all later on.

    There is a Google project that shows the specific code which is downloadable here: http://code.google.com/p/php-mobile-detect/

    $is_mobile = $detect->isMobile();

    WURFL (Wireless Universal Resource File)

    The last resort is WURFL which is a software component which contains the descriptions of thousands of mobile devices. It is basically an XML configuration file plus a set of progamming APIs to access the data. For more documentation on how to implement it please read:
    http://wurfl.sourceforge.net/help_doc.php

    Sep 23 2011
    Sep 23

    Scrolling and fixed position on mobile devices for Drupal 6.

    Posted on: Friday, September 23rd 2011 by Erico Nascimento

    Over the last of couple weeks we’ve been working on a mobile site/app, with a very standard layout: a location bar fixed on the top, a menu fixed on the bottom and the content being printed in between. I thought this would be a walk in the park until I realized that Safari on the iPhone doesn’t support scrolling inside divs, and “position:fixed” doesn’t really behave like it does on desktops.

    Thus began my crusade to find a solution. jQuery mobile was my first option, but quickly discarded because it requires jQuery 1.6 and Drupal 6 still using 1.2.6, proceeded to other solutions that always were either an overkill, or badly documented, so it wasn’t until I thought that all hope was lost that I ran into iScroll a javascript library for mobile webkit that is completely independent of jQuery and built pretty much to solve my problem.

    They have modest community supporting the project which is nice and the source files come with a couple different examples that sure help your implementation. We’re just starting the QA process on the app now, but so far it is behaving well minus a few bugs on Android (2.2 & 2.3) and form elements.

    Overall I’m looking forward to see how the project is going to grow. They're beta testing version 4.1 and it looks promising.

    Have you ever ran into the same issue? Why not share the solution with us?

    Have a Happy Theming.
    Erico Vinicius.

    Sep 13 2011
    Sep 13

    Background Reading

    The purpose of this post isn't to explain the concept of responsive design. There are many great resources out there that already do this, most notably Ethan Marcotte's article on A List Apart. Or better yet, read the book; it's a quick read and it's well worth it.

    Nor is it my aim to debate the merits of responsive design. I'm already convinced that this approach is beneficial, and, again, there are so many voices in the community arguing this point that I don't feel the need to chime in.

    Instead, this post will discuss Terrain, a specific Hexagon-based implementation of responsive design in Drupal.

    The Concept

    Both in principle and in practice, I don't like doing the same thing twice. Why add this snippet of code to every new theme I create?

    img, iframe, video, embed { max-width: 100%; }
    

    On one hand, every design is unique, and that is especially true when designing for multiple viewports and browser capabilities. Because of this, "some recommend against using a base theme at all". On the other hand, there is a set of design elements that can be generalized out to most responsive designs. In Terrain, these elements are:

    • Larger links for smaller viewports, making links easier to click on smaller touch devices
    • Max-width settings on images and other media
    • A Fluid grid
    • Single column layout on smaller viewports
    • Larger base font on larger viewports
    • Initial-scale settings to fix automatic resizing

    I've found that starting out with these basic elements saves time when creating a new responsive theme. And with a starter theme in place for Terrain, it's easy to tailor the theme to your specific design.

    This theme is also meant to give users a quick start to responsive design. Fire it up, without changing any configuration settings, and you have a simple, usable, 100% responsive theme.

    Explaining Our Decisions

    Why doesn't Terrain "respond" in Internet Explorer?

    Simply put, we made a deliberate decision not to implement IE support, despite the availability of javascript libraries such as adapt.js and respond.js that were created for this purpose.

    To borrow a quote from Jeffrey Zeldman's "To Hell With Bad Browsers":

    For years, we’ve been taught to be good little web designers, building sites that work in browsers that don’t. Each site we build the old-fashioned way becomes one more dung heap of bad code, one more web destination that will eventually stop working as browsers and standards evolve.

    The longer we do it, the more doomed sites proliferate. Thousands of new sites premiere every day. Most of them are built to support bad browsers intead of standards. It’s an epidemic. Enough already. We finally have good browsers. Let’s use them.

    Even though this article was published in 2001, it still accurately summarizes my view on non-standards-compliant browsers. This doesn't mean Terrain will be unusable or ugly on Internet Explorer 8 and below, it just means that IE8- won't have the benefit of being able to utilize some of the responsive features, i.e. progressive enhancement for more capable browsers.

    Why did you choose a fluid grid / responsive approach (as opposed to adaptive)?

    From an ideological perspective, I wanted my designs to be able to truly respond to their environments, as opposed to creating 3-5 similar designs to "fit" different classes of device. This approach has several real-world advantages, from future-proofing against new sizes of tablets and other devices, to maximizing the use of (very) limited screen space on smartphones.

    Of course there are also downsides with this method, like how much control you might have to concede over your pixel-perfect design. So if having that kind of control over your design is important to you or your project, Terrain might not be a good fit.

    Why is Terrain based on Hexagon?

    If you haven't heard of Hexagon, I highly suggest you go download it and try it out. Hexagon is a powerful base theme by the brilliant Joon Park (dvessel), with features like:

    • Built-in plugin system, with available plugins for Accessible Tabs and Accessible Accordions regions, region grouping, 960.gs, module compatibility, smarter styles, and more
    • Granular separation of files, such as variable preprocess functions
    • Better file caching and overrides

    Building on this framework means Terrain can utilize all of Hexagon's features, while itself staying simple and lean.

    Why does Drupal need another responsive starter theme?

    Like most projects that appear to duplicate functionality, Terrain uses a slightly different approach. None of the responsive starter themes we tried quite fit our needs, so we rolled our own solution. As I mentioned above, we built Terrain to be extremely lean, while still leveraging the functionality of Hexagon.

    Future Improvements

    The first item on my Terrain to-do list is a 7.x version. A close second is a set of usability improvements, including better documentation, a quickstart guide (for both Terrain and Hexagon), and more helpful comments. Code improvements, such as more grid options and HTML5 support, extensible functionality, such as a responsive slideshow feature, and responsive image support are also coming soon.

    Terrain is currently available for download as a 6.x-1.0-alpha1 release on drupal.org.

    Sep 13 2011
    Sep 13

    From the get-go, Square Grid has been intended to offer less. Sometimes less is more, especially so when it comes to front-end web development.

    Square Grid is a Drupal 7 base theme* leveraging the design and implementation power of Square Grid, combined with principles of responsive design. It's been in active development, with new features and the odd bug fix pushed live periodically over the past several months. Here's where the theme stands now.

    More options, still lightweight

    Since its first incarnation, Square Grid has grown a bit – not so much in code but rather in flexibility. It's still pretty lightweight.

    Configurable tools

    Square Grid configuration options are inherited and available to your child theme's settings page. These include:

    Configurable responsiveness options

    Responsive support has been part of the theme since April. Now you can configure whether you want it, and if so how much.

    squaregrid config screen
    You can turn the responsive support on and off.

    However, it's not just a matter of turning responsive support on or off: You have various options.

    squaregrid config screen detail
    If responsive support is enabled, you can choose what grid sizes to utilize in the theme.

    squaregrid config screen detail
    If you do not want responsive support, you can choose a universal grid size for all screens.

    The theme does only what you've planned for.

    Internet Explorer options

    You can decide how to handle Internet Explorer up through version 8, which does not recognize media queries.

    squaregrid config screen detailIE support options can be configured as well.

    Options include one static grid size, or no special handling (in case you want to use a JavaScript-based solution such as Respond.js).

    Simple built-in development aids

    Grid-based theme development sometimes can get quite involved when working on an actual Drupal codebase, not just mockups or prototypes.

    squaregrid config screenFrom Square Grid-enabled theme configurations.

    With these seettings, you can toggle on/off display of the actual grid and rebuilding the theme registry on every pageload.

    Behind the scenes, what you get are:

    A grid for most occasions

    Square Grid grid
    As illustrated here, Square Grid framework facilitates a wide variety of design grids, from 4-column to 12-column to Golden Ratio, all from one grid schema.

    The lightweight Square Grid Theme builds off of the powerful flexibility of Square Grid framework by Avraham Cornfeld. See http://thesquaregrid.com for more on Square Grid concepts, templates and more.

    Lightweight CSS

    The styles predefined in the theme are as minimal as possible, focusing only on page layout. The idea is that you, the themer or front-end developer, will want to control the rest.

    Mobile first architecture

    The theme styles for single-column, optimized-for-smaller-screens layout first, and adds multi-column grid-based layouts in addition for screens 770px and larger.

    Content-first page loading

    Nothing irks more than loading secondary content before the main content. It makes people wait longer to see what they clicked to see, raising click-aways. This theme loads your main content first, then the secondary content.

    Straightforward grid column settings

    These can be overridden in your child theme's template.php. No heavy PHP knowledge is required, and all necessary code is provided.

    No extra extras

    It's tempting to add more bells and whistles, but the goal is not to add complexity or steepen your learning curve with bespoke variables or code concepts.

    There's more on these features and characteristics in the official documentation.

    Not a fluid grid

    Square Grid is not a fluid grid. Why? Because even today browsers do not agree how to render out elements defined with floating decimals. A fluid 35-grid layout would require a grid of %2.857... per grid square, which means that a fluid layout defined by percentages would entail added complexity and possibly some browser hacks, especially when you multiply browser-imposed roundings and truncations by 35.

    Some people still prefer 100% fluid layouts, and that can make sense, especially in some use cases, such as an expert-interface dashboard requiring as much screen-estate as possible. However, if the static grid widths adapt to the screen sizes, the marginal benefits of going 100% fluid are somewhat minimized. Therefore, given the floating point issues noted above, Square Grid, as a base theme, supports multiple fixed-grid widths that offer healthy screen-estate usage for the most-commonly used screen sizes. (Count me in the school of thought that it's all responsive.) An added benefit is that, by defining these break points, the theme renders with more predictability for design purposes. The current 770px-, 980px- and 1190px-width break points in Square Grid Theme cover most larger displays, while still providing comfortable, readable layouts. As screens get larger, we can build upon this paradigm. And we're not ruling out fluid grid definitions altogether. (See below.)

    Road map items

    Here are some things in the works (in no particular order):

    An HTML5 version

    This is already in the works. [Meta issue]

    "Nav last" page structure

    Currently, Square Grid loads the main menu before the content — something I always immediately remake in any child theme. While there are still some naysayers, most agree that loading nav last is best practice for mobile display. This means that Square Grid should load the nav last, just before the footer. How this gets styled for proper placement, though, depends very much on the specifics of the design. That's why I have not done this yet, but I may add 3-4 lines of CSS to handle this. [Issue]

    Configuable column widths

    These would be configurable "sidebar" widths settings, to make it easier for you to just get on with implementing your design. (Column widths are fully workable in the theme currently, but customizing them does involve some code editing to change integer values in the child theme's template.php file.) [Issue]

    1400px-wide layout

    This has been partially implemented (and disabled in code pending completion) and likely will be in one of the next releases. [Issue]

    Fluid layout

    Comments above notwithstanding, this could be an option with potential appeal to some themers. Caveats about variable browser support would apply, of course. [Issue]

    We hope Drupal users working to implement custom designs on their own sites find the Square Grid Theme useful.

    --

    Sep 10 2011
    Tom
    Sep 10

    From time to time I get questions about caching strategies and mobile devices. Definitely when you want to create different responses in the back end based on the device AND you have strong caching strategies, things get very tricky.

    An example scenario in Drupal (but can relate to any CMS) is where you boost performance by storing the generated pages as static files (see Boost).

    These solutions rely heavily on Apache in a way that Apache delivers the static files in case these files exist. Otherwise it passes the request to the CMS.

    In order to provide a way to server different responses to mobile devices I created following Apache script:

      # Detect if a "device" query parameter is set in the request. 
      # If so, the value for that attribute forces the requesting device type.
      # If the parameter is available, set a cookie to remember for which device pages have to be generated in subsequent requests.
      # Assume three categories:
      #  - mobile-high (high end mobile devices)
      #  - mobile-low (low end mobile devices)
      #  - desktop (desktop browser)
      RewriteCond %{QUERY_STRING} ^.*device=(mobile-high|mobile-low|desktop).*$
      RewriteRule .* - [CO=device:%1:.yourdomain.tld:1000:/,E=device:%1,S=2]
      # now skip 2 RewriteRules till after the user agent detection
     
      # If there is no "device" attribute, search for a cookie.
      # If the cookie is available add ?device=<device-type> to the request
      RewriteCond %{HTTP_COOKIE} ^.*device=(.*)$
      RewriteRule (.*) $1?device=%1  [E=device:%1,S=2,QSA]
      #now skip till after the user agent detection
     
      # If no cookie or device attribute are present, check the user agent by simple user agent string matching (android and iphone only here)
      RewriteCond %{HTTP_USER_AGENT} ^.*(iphone|android).*$ [NC]
      RewriteRule (.*) $1?device=mobile-high [E=device:mobile-high,QSA,S=1]
     
      # Detect the user agent for lower end phones (nokia, older blackberries, ...)
      RewriteCond %{HTTP_USER_AGENT} ^.*(nokia|BlackBerry).*$ [NC]
      RewriteRule (.*) $1?device=mobile-low [E=device:mobile-low,QSA]
    

    This scripts makes sure that every request has an extra "device" query parameter that defines the requesting device (desktop/mobile-high/mobile-low). This information can be used by the back end or any caching mechanisms!

    I also added a %{ENV:device} variable so that within the Apache script more logic can be placed based on the device.

    Applying to the Boost module

    The above snippet works together with Boost by replacing %{server_name} by %{ENV:device}/%{server_name} in the Boost apache configuration.

     ### BOOST START ###
      AddDefaultCharset utf-8
      <FilesMatch "(\.html|\.html\.gz)$">
        <IfModule mod_headers.c>
          Header set Expires "Sun, 19 Nov 1978 05:00:00 GMT"
          Header set Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"
        </IfModule>
      </FilesMatch>
      <IfModule mod_mime.c>
        AddCharset utf-8 .html
        AddCharset utf-8 .css
        AddCharset utf-8 .js
        AddEncoding gzip .gz
      </IfModule>
      <FilesMatch "(\.html|\.html\.gz)$">
        ForceType text/html
      </FilesMatch>
      <FilesMatch "(\.js|\.js\.gz)$">
        ForceType text/javascript
      </FilesMatch>
      <FilesMatch "(\.css|\.css\.gz)$">
        ForceType text/css
      </FilesMatch>
     
      # Gzip Cookie Test
      RewriteRule boost-gzip-cookie-test\.html  cache/perm/boost-gzip-cookie-test\.html\.gz [L,T=text/html]
     
      # GZIP - Cached css & js files
      RewriteCond %{HTTP_COOKIE} !(boost-gzip)
      RewriteCond %{HTTP:Accept-encoding} !gzip
      RewriteRule .* - [S=2]
      RewriteCond %{DOCUMENT_ROOT}/cache/perm/%{ENV:device}/%{SERVER_NAME}%{REQUEST_URI}_\.css\.gz -s
      RewriteRule .* cache/perm/%{ENV:device}/%{SERVER_NAME}%{REQUEST_URI}_\.css\.gz [L,QSA,T=text/css]
      RewriteCond %{DOCUMENT_ROOT}/cache/perm/%{ENV:device}/%{SERVER_NAME}%{REQUEST_URI}_\.js\.gz -s
      RewriteRule .* cache/perm/%{ENV:device}/%{SERVER_NAME}%{REQUEST_URI}_\.js\.gz [L,QSA,T=text/javascript]
     
      # NORMAL - Cached css & js files
      RewriteCond %{DOCUMENT_ROOT}/cache/perm/%{ENV:device}/%{SERVER_NAME}%{REQUEST_URI}_\.css -s
      RewriteRule .* cache/perm/%{ENV:device}/%{SERVER_NAME}%{REQUEST_URI}_\.css [L,QSA,T=text/css]
      RewriteCond %{DOCUMENT_ROOT}/cache/perm/%{ENV:device}/%{SERVER_NAME}%{REQUEST_URI}_\.js -s
      RewriteRule .* cache/perm/%{ENV:device}/%{SERVER_NAME}%{REQUEST_URI}_\.js [L,QSA,T=text/javascript]
     
      # Caching for anonymous users
      # Skip boost IF not get request OR uri has wrong dir OR cookie is set OR request came from this server OR https request
      RewriteCond %{REQUEST_METHOD} !^(GET|HEAD)$ [OR]
      RewriteCond %{REQUEST_URI} (^/(admin|cache|misc|modules|sites|system|openid|themes|node/add))|(/(comment/reply|edit|user|user/(login|password|register))$) [OR]
      RewriteCond %{HTTP_COOKIE} DRUPAL_UID [OR]
      RewriteCond %{HTTP:Pragma} no-cache [OR]
      RewriteCond %{HTTP:Cache-Control} no-cache [OR]
      RewriteCond %{HTTPS} on
      RewriteRule .* - [S=3]
     
      # GZIP
      RewriteCond %{HTTP_COOKIE} !(boost-gzip)
      RewriteCond %{HTTP:Accept-encoding} !gzip
      RewriteRule .* - [S=1]
      RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:device}/%{SERVER_NAME}%{REQUEST_URI}_%{QUERY_STRING}\.html\.gz -s
      RewriteRule .* cache/%{ENV:device}/%{SERVER_NAME}%{REQUEST_URI}_%{QUERY_STRING}\.html\.gz [L,T=text/html]
     
      # NORMAL
      RewriteCond %{DOCUMENT_ROOT}/cache/normal/%{ENV:device}/%{SERVER_NAME}%{REQUEST_URI}_%{QUERY_STRING}\.html -s
      RewriteRule .* cache/normal/%{ENV:device}/%{SERVER_NAME}%{REQUEST_URI}_%{QUERY_STRING}\.html [L,T=text/html]
     
      ### BOOST END ###
    

    In your settings.php you should do the following:

    /**
     * Theme array for the mobile categories. The key equals the device category
     * supported by the site.
     * Changing this array configures the mobile theme for a certain device group
     */
    $mobile_themes = array('mobile-low' => 'bluemarine', 'mobile-high' => 'pushbutton');
    /**
     * Check if the device argument is one of the valid devices (this is just an extra check)
     */
    if(isset($_GET['device']) && array_key_exists($_GET['device'], $mobile_themes)){
            $boost_device = $_GET['device'];
            $conf['theme_default'] = $mobile_themes[$_GET['device']];  // set the theme
    }
    else {
            $boost_device = 'desktop'; 
    }
     
     
     
    // We configure the Boost folders to support multiple devices. 
    // This corresponds to the %{ENV:device}/%{SERVER_NAME} string in the apache script
    $conf['boost_normal_dir'] = 'normal/' . $boost_device ;
    $conf['boost_gzip_dir'] = 'normal/' . $boost_device;
    $conf['boost_perm_normal_dir'] = 'perm/' . $boost_device;
    $conf['boost_perm_gz_dir'] = 'perm/' . $boost_device;
     
    /**
     * End configuration for boost 
     */
    

    Hope this gives some inspiration!

    View the discussion thread.

    Aug 16 2011
    Aug 16

    Like many folks who build web sites, we're seeing increased traffic from people with mobile devices.

    In addition to building web sites, we're also geeks, and based on our experience working and playing on the web using mobile devices, we know that people using handhelds want the same information as people browsing the web using a laptop, netbook, or a desktop. Believe it or not, our interests as end users do not shrink or grow in proportion to our screen resolution. As a result, we favor the principles of responsive design as a means to meet the needs of mobile users.

    The terrain mole!

    We've been using Hexagon as our base theme for the last few years. Hex is insanely flexible, designed to work smoothly with Context, designed to eliminate the pain of building subthemes, and has an architecture that supports functional plugins within the theme. Currently, Hex ships with plugin support for accordion regions, vertical tabs, and horizontal tabs. If you want to get a sense of how Hex works with subthemes, grab a copy of VoiceBox and look at how the Dispatch theme interacts with contexts.

    But, because Hex is designed to be extensible (did I mention that Hex is insanely flexible?) it can support other types of plugins.

    For example, a Hex subtheme can use a plugin that supports the 960 grid system with a custom fluid width grid. Along with some other modifications, which we'll discuss in another post, this is the basis for our responsive hex starter theme. A development release of Terrain is now available for download on drupal.org. Get it while it's hot!

    You can also access this video directly on Vimeo: http://vimeo.com/27829604

    Because we believe that one's own dog food is the tastiest, http://funnymonkey.com is now running on a Terrain-based theme.

    Jul 15 2011
    Jul 15

    Recently, I blogged about Drupal's plans to integrate HTML5 into its next release. However, version 8 of Drupal is at least a year away. What's a Drupal dev to do, if they want to start using HTML5 right now? There are a variety of tools and techniques. Let's look at them.

    Drupal 6 or Drupal 7 – Does it matter?

    In a word, “no”. In fact, if all you want to do is use HTML5 elements on your website, you don't really need to use the Drupal tools – themes and modules – to use HTML5 on your site. All you need to do is change the doctype in your theme's page.tpl.php file from:

    to

    html.
    

    Simple, eh? You can now use HTML5 tags like “<video>”, “<audio>”, “<canvas>”, etc., on your pages. For a full list of HTML5 tags and their browser compatibility see: http://caniuse.com/#cats=HTML5. If you are a more visual person, you might prefer this interactive graph by HTML5's Superman, Paul Irish.

    Modernizr

    Better yet, use Irish's modernizr, “an open source, MIT-licensed JavaScript library that detects (browser) support for many HTML5 & CSS3 features” (http://diveintohtml5.org/detect.html). There's a module, available for both Drupal 6 and 7. If you prefer, you can build your own modernizr script, choosing just the elements you want to use to keep your script small, download your customized library, and add it to the head of your theme's page template files with:

    <script src="http://civicactions.com/blog/2011/jul/15/using_html5_with_drupal_today/(path-to)modernizr.min.js"></script>
    

    In Drupal 6, this would be page.tpl.php and in Drupal 7, html.tpl.php. Read the full instructions here.

    HTML5 Sectioning Flowchart

    Semantic Elements

    If you want to use HTML5 semantic elements, you do not necessarily need an HTML5 theme. You can manually replace the CSS “divs” you want to change, in your various template files, with their corresponding HTML5 elements: “<div id=”header”>” with “<header>”, “div id=”main”>” with “<section id=”main”>”, etc. Each theme will likely vary slightly, in how it implements HTML5 semantic elements. If you compare the two Drupal 6 themes, HTML5 Base and Boron, for example, you'll see that Boron turns each “block” into a “section” while HTML5 Base leaves “block” elements as “blocks”. See the handy flowchart from HTML5doctor.com, and this excellent post, also from HTML5doctor.com, for instructions on how and where to use the new semantic elements. For a more indepth discussion of HTML5 semantic elements, see http://diveintohtml5.org/semantics.

    HTML5 Shiv or Shim

    Last in the process of adapting your own theme for HTML5 is linking to Remy Sharp's HTML5 enabling script. What this does is get Internet Explorer to recognize HTML5 elements. All you need to do is put the following in your “<head>” element:

    <!--[if lt IE 9]>
    <script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>
    <![endif]-->
    

    Tada! You've rolled your own HTML5 theme!

    Once you are done, check your work via the HTML5 Outliner.

    Drupal HTML5 Themes

    There are many good HTML5 Drupal themes that, with the exception of implementing modernizr, have done all of the above work for you. If you want to reap the benefits of Open Source community work, use one of them – and apply the time you save bettering it, or working on some of the many modules in development for HTML5.

    Currently, there are almost 600 themes for Drupal 6, and almost 200 for Drupal 7. Of these, for Drupal 6, 17 reference “HTML5”, and for Drupal 7, 20. Almost all of the HTML5-referencing themes are starter themes; that is, they are not designed to be used as is, but as bases from which to build your own theme.

    Drupal 7 Themes

    The most popular Drupal 7 HTML5 theme is Sky. I suspect it is most popular because it's been around, in one form or another, since 2007. I'm not saying it's not a good theme! I've used it, for Drupal 6. It's clean, attractive and can be used as is, or as a base them. It's currently maintained by the Drupal HTML5 initiative leader, Jacine.

    The second most popular is AdaptiveTheme (as of today, Thursday, July 7, 2011 – yesterday, the second most popular was Omega), which, despite the name, does not in fact, appear to be “adaptive”. “Adaptive” or “responsive”, in regard to web sites, generally refers to the use of CSS3 media queries to assign different stylesheets for different sized viewports and devices. Version 7.x.2.x of AdaptiveTheme, according to this page, will incorporate media queries, but until then, there is no AdaptiveTheme Mobile sub-theme for Drupal 7. If you want to use media queries, nothing is stopping you from adding them yourself. AdaptiveTheme includes features: rounded corners settings, RDFa and microformat compatibility, “Gpanels which are drop in snippets for creating multi-column layouts (such as a 5 column footer)”, and optional settings for things like: adding “extra CSS class names via theme settings” and “SPAN elements to menu anchor text”.

    Media Queries

    For an excellent tutorial on media queries, see this Web Designer Wall post. Here's a simplified example of media queries in action, from another Web Designer Wall tutorial, and here's a fine collection of sites using media queries. Oh, and here's the anti-media-queries argument; namely, that media queries do not strip out large images and scripts, thus rendering your web site too large and slow for mobile devices. The answer to that, however, is to use a bit of Ye Olde Javascript.

    Framework simply uses HTML5 structural markup, while Genesis is only HTML5 friendly in the latest development version.

    The now fifth most popular, Omega, is interesting. Firstly, it is an “adaptive” or “responsive” theme using media queries. Secondly, it integrates with a module, “Delta, originally designed to only work with it, that, in concert with another module, Context, allows you to use “different layouts/settings for various portions of a site”. Lastly, another module, like Delta, originally designed for use only with Omega, Omega Tools, allows you to quickly develop a sub-theme using Drush. Omega is rather large: 1.1MB! You could probably throw out all but the base folder and/or a starter kit, bringing the size down to about 350K, however.

    Gamma and Beta are both Omega sub-themes.

    Boron is a minimalist theme based on the popular Zen. Boron also comes in a Boron for Zen flavour. Boron for Zen is only for Drupal 6.

    Panels 960gs (HTML5), Zentropy and MinimalistTheme are all Boron-based. Panels 960gs incorporates the 960 Grid System and Panels module. Zentropy is based on Paul Irish's HTML5 Boilerplate, meaning it is optimized for performance and mobile, among other things you can find out about here.

    LayoutStudio's HTML5 version is in process, while HTML5 Base, a promising theme by Drupal 7 base theme designer, Jen Simmons, is still only available in a development version.

    Plink, like HTML5 Base, looks interesting but is still only available in a development version. Plink comes with media queries, modernizr, “baked in” LESS and a “jQuery Mobile default sub theme for use in mobile switching”.

    Drupal 6 Themes

    If you want to take advantage of the almost 6000 modules that exist for Drupal 6, you might want to forego Drupal 7 for now. Though it appears that there are 17 HTML5 themes for Drupal 6, many are only HTML5 for Drupal 7, or merely reference the term in their write ups. Sky, for example, is only an HTML5 theme for Drupal 7; likewise, AdaptiveTheme, Genesis and Layout Studio. Framework, Boron, Drixel 5, HTML5 Base, modernbird, Boron for Zen and Roots are HTML5. *Whoops, looks like as of today, HTML5 Base is no longer available for Drupal 6, but is available for Drupal 7; only as a development version, though.

    Roots is based on HTML5 Boilerplate and appears to be well thought out.

    There are many good HTML5 starter themes for both Drupal 6 and 7. It's also easy to adapt your own theme for HTML5, or to adapt an existing theme for your specific needs. There does not seem to be a strong front-runner in the HTML5 starter theme arena, comparable to the popular Zen. What HTML5 theme are you using or are you interested in? Why?

    Modules

    For Drupal 6, 26 modules reference “HTML5”, and for Drupal 7, 22. Many of these modules are still in development or not yet available. Let's look at what we have.

    Video is the most popular “HTML5” module for both Drupal 6 and 7. It's been around (sans HTML5) since 2005. Video allows users to “upload video in any format, play video in any format “ and transcode video to the HTML5 friendly h246, Theora and VP8 codecs.

    Second up is Media: Vimeo. This module extends the functionality of Embedded Media Field to allow users to embed videos from the Vimeo video service, “using HTML5 when supported”. Media: Archive provides similar functionality for audio and video served from Archive.org. The Drupal 6 version of Media: Archive doesn't appear to support HTML5. The Drupal 7 version has some HTML5 support and plugs into the Media module.

    Third most used is Elements, which provides a library of form elements: tableselect, emailfield, searchfield, telfield, urlfield, numberfield and rangefields, that a developer can use in their own modules. (Note that the Drupal 7 version does not include tableselect element - this functionality is available via the Drupal 7 core.)

    HTML5 Tools is a diverse set of tools to help developers HTML5-ify their site. You need to install Elements to use HTML5 Tools, whichg is comprised of itself plus a sub-module: HTML5 Forms Tools. Forms Tools overwrites Drupal default forms with their HTML5 counterparts – or will do that. Currently, only email elements on user settings and site configuration pages, the search element on the Search Module, and the search element on the Search Theme Form are ready. Follow the progress of this module here.

    Plupload Integration creates multiple file upload capabilities, and utilizes an HTML5 widget if the client computer supports it.

    MediaFront is a media player who's appearance can be customized without writing code. It utilizes the Jquery Open Standard (OSM) Media Player, which plays many types of media.

    JPlayer integrates the jPlayer JavaScript library with CCK file fields and Views. The jPlayer JavaScript library “provides an HTML5-based player, that uses a Flash fallback.”

    VideoJS (HTML5 Video Player) is another HTML5 video player that utilizes an HTML-based solution to video display: Video for Everybody, and javascript, to cover an optimal number of browsers and devices.

    There are HTML5 modules, and adjustments to existing modules, in development for GeoLocation (I know, I know, not strictly HTML5!), Canvas, processing.js and websockets. There are several graphing modules in development: Visualize, GraphAPI and Rgraph. There's an HTML5 image editor module ready to go. To see all that is available for HTML5, go here.

    It's an exciting space: HTML5 and Drupal. As we've seen, we don't really need HTML5 specific themes and modules to at least get started using HTML5 on our Drupal sites; however, there are many available to help us, and many more in active development. As always, along with having fun, remember to join in: create, share and help develop the modules and themes you want to see!

    Jul 13 2011
    Jul 13

    Note: This blog post was posted on July 13, 2011. Youtube embeding may have changed since then, they claim to still be fixing it and in beta.

    This suggestion is to provide the best user experience when watching a Youtube video on your mobile website. A lot of times it is done incorrectly and users are redirected to either m.youtube.com or it opens up your phone's native Youtube application, which basically minimizes your browser. This pushes users away from your site and basically requires users to hit the back button to get back to your site.

    read more

    Jun 06 2011
    Jun 06

    HTML5 LogoHTML5. If you haven't heard of it, perhaps you've seen the 50's superhero inspired logo (left) which is popping up all over? On May 18, 2011, Drupal creator, Dries Buytaert, announced that HTML5 is not only going to be one of the top five initiatives for Drupal 8, but that the default doctype for Drupal will switch from XHTML to HTML5. What's this mean to you, a Drupal dev or Drupul user? Let's find out.

    1. First of All, What is HTML5?

    A couple years ago, at Google I/O, HTML5 was described as a convergence of HTML, CSS and JavaScript. Since then, it seems, CSS has wandered off to become it's own entity: “CSS 3”, while the HTML and JS elements are gelling into HTML5.

    Basically, HTML5 allows website builders – or perhaps, “web builders” since with HTML5, a single site will become much more hooked into the larger World Wide Web network of sites, interfaces and functions – to embed and manipulate video and audio elements, as well as to draw and/or create graphics through scripts (or “code”), that they will then be able to animate, through scripts. The “hook” into the WWW comes through structural tags being added to the language. Tags like “<header>”, “<nav>” and “<article>” will connect your web page elements to similar elements on other sites. This will allow for more intelligent linking via search engines, and will open up new possibilities for cataloguing the World Wide Web and for communication and/or interfacing across sites. These tags are part of the Semantic Web initiative.

    APIs and DOMs

    Dog, what's up with the APIs and DOMs? Application Programming Interfaces are “sets of rules and specs” that software programs follow to communicate with each other. Microsoft's DirectX is a collection of APIs that allow multimedia and game software to communicate with Windows, for example. Document Object Model is, mainly, the set of conventions that allows JavaScript to interact with HTML, or XML. With tags like “<video>” and “<audio>” these conventions become integral to HTML, instead of the add-ons they currently are: say “goodbye” to the “<embed>” tag!

    Graphics

    “<canvas>” is a new HTML tag that lets you create and animate 2D images using JavaScripts. Integration of Scalable Vectors Graphics (SVG), a type of graphic defined by XML code, is also part of HTML5.

    In essence, a whole bunch more tools just got dumped into the web developer's toolbox; tools that will allow you to make browser-based games, interactions and animations – or web sites that behave like games, interactions and animations. Using a Chrome browser, check out Angry Birds in the browser, and RO.ME, music video-game-website hybrid, for examples of what's possible.

    2. Why HTML5?

    In other words, lots more interaction, animation, video and audio on web sites, as they evolve into much more fluid entities, morphing in size and functionality to display and be used across a plethora of screens and devices, while simultaneously becoming more integrated with other sites, libraries and functions, across the World Wide Web. Think of a tree, pushing down roots and pushing out branches; flowering, bearing the fruit of rich media, and cross-pollinating.

    3. How HTML5?

    "Ohhhh, no. Oh, no, oh, no, oh, no. I have to learn a whole bunch more tags and processes now, right?" Sort of – but not really.

    Firstly, HTML5 is not difficult to learn. You're probably already using CSS3 to add dropshadows to images and round corners on your boxes. Using HTML5 is not going to be anymore difficult than that. One day, you are using “<embed>” to add your video; next, BAM! You are using “<video>” (and of course, stretching, colouring and enhancing your video through HTML5, just because you can).

    Drupal? Drupal, a GUI for HTML, PHP and JS, is not going to stop being that. Imagine HTML5 goodness rolled into the Drupal CMS, with added functionality to allow you to add your own HTML5 tags when and where you wish. You will, in fact, be HTML5'ing before you know you are HTML5'ing.

    Drupal Integration, High Level

    The plan to integrate HTML5 is still being hashed out. Jacine Luisi (or, as she refers to herself, simply, “Jacine”), the initiative leader, describes the main goals thus:

    • implement HTML5 elements that will offer the most benefits to end users,
    • help contributed modules and themes, both existing and new, incorporate HTML5 elements, and
    • allow theme developers to use, or opt out of use of, HTML5's semantic elements,

    These goals will be implemented by:

    • adding HTML5's semantic elements to core templates,
    • simplifying style and script elements, and
    • ensuring that input filters and functions accept HTML5 elements.

    Drupal Integration, Mid-Level

    If you'd like to get involved in integrating HTML5 into Drupal 8, your help is not only welcome, but requested! Here are the main pages to visit, to see what's happening and where you can help:

    Remember, you don't need to code. Documentation, marketing, testing and user interface are just some of the areas in which you can contribute, aside from code.

    The HTML5 Issue queue is a list of tasks that need to be addressed to implement HTML5 in Drupal 8's core.

    At the HTML5 Working Group page you will find discussions, projects, documentation, events and even a job board.

    Discussions include:

    • implementing HTML5 markup and APIs in Drupal
    • adding HTML5 support to Drupal 7
    • getting HTML5 native markup and form elements into Drupal 8 core.

    Projects include:

    Documentation includes HTML5 Myths and the wiki.

    I highly encourage you to read the myths. Here's an example:

    “Myth: HTML5 is not done, we should wait until it's done before implementing it in Drupal.

    Fact: Most of HTML5 is dividable in 3 different groups: "it just works", "degrades by default", and "some effort required". See http://mathiasbynens.be/notes/html5-levels for additional information.

    Also, the WHATWG, the driving force behind HTML5, has dubbed it a "living standard" that is constantly evolving. As such, the version number is less of an issue. The "2022" release date is nullified, and they instead will measure progress in feature milestones. HTML5 will still be documented by the W3C as an official spec, but the WHATWG will keep driving forward progress, simply calling it "HTML". More here...

    Events include many IRC meetings, that you can attend without leaving your computer.

    Lastly, here's a list of resources, largely courtesy of Jacine, to help you get started with HTML5:

    That's it in a nutshell. HTML5 is going to make the web come alive with graphics, movement and communication. Drupal 8 is gearing up to seamlessly bring all of this life into the world's best CMS. Dig in, folks – and get involved!

    May 23 2011
    Tom
    May 23

    Mobile Tools swiss army knife verticalIn a couple of months the Drupal community, and businesses will attend Drupalcon London 2011. An opportunity for us developers to learn about new trends, decision makers to evaluate Drupal and for a lot of Drupal pro's the opportunity to share knowledge with a wider community. I am looking forward to share my experiences on Mobile development with Drupal.

    Each year, I propose a talk about something general called "Mobile Drupal", something I have been working on for a couple of years now and that has mainly resulted in the Mobile Tools module.

    This year I choose to narrow down my proposal to a talk about techniques that Drupal module developers and site builders can use to prepare their existing desktop site for mobile. When you master this, you definitely are able to create a mobile site from scratch. So no extensive talk about javascript frameworks, and mobile user experience/design this year. Although this would also make an interesting session, this is something that goes much wider than just the Drupal community.

    Currently many challenges exist in creating a mobile variant of your desktop site. Since Drupal is mainly desktop oriented, a lot of techniques are put in place to configure 1 display of your site. And to date,thousands of sites have been build with only "desktop" in mind. So how are we going to convert all those sites do mobile without having to rebuild them.
    Under the hood Drupal allows some flexibility to configure your site for multiple display without the need for huge refactoring... And this is what my session will be about.
    Some topics I really would like to cover are:

    • How to easily change formatting of your nodes on mobile?
    • How to make and configure mobile contexts for your pages?
    • How to make panels mobile aware?
    • How to create mobile alternatives for your views while maintaining paths?
    • What modules hook into mobile contexts?
    • How to use imagecache to scale images for mobile?
    • How to create separate mobile navigation, while reusing the menu system?
    • How to cache both your mobile and desktop site?
    • How to make your own device detection and theme switching algorithm?
    • ....

    There are many techniques available that help you in adapting your Drupal site for mobile, so I would like to demonstrate some of the techniques that can fit a 1 hour session :)

    I hope that together with this 'developer oriented' session, we will also see a couple of sessions related to mobile user experience, mobile design and related several mobile frameworks that are around there...

    So if you would be interested in this session, please head over to the Drupalcon website and you know what to do there ;)!

    Bridging the gap between Desktop and Mobile publishing with Drupal

    View the discussion thread.

    May 17 2011
    May 17

    The web game Quizible originated from the popular Microsoft Excel spreadsheet picture based games from the late 90's.

    The Drupal powered site was developed as part of an in-house training month at Ixis. The mobile project came about as we looked for a new way to utilise the data Quizible had collected.

    The Drupal Benefit

    Drupal allowed us to offer users the ability to make their own quizzes and for everyone else to play them whilst achieving a score on the leaderboard. Over the next two years Quizible was featured on Techcrunch, it became popular on social sites such as Stumbleupon and Facebook - gaining over 20,000 users and hundreds of user generated quizzes.

    The quiz data held in Drupal is built on the node system - each question is a single node and in turn a collection of nodes were attached to a quiz node by means of multiple node reference fields. The storage of quiz data like this meant it's very easy to re-cycle the data for other uses.

    Over the years we noticed the Quizible website was being accessed using various Apple iOS devices using the Google Analytics module. Playing a quiz on the Apple iPad was reasonable but the iPhone was awkward to enter text in to the answer box due to the standard iPhone pop-over keyboard.

    The Mobile Interface

    When the mobile development began the alternative frameworks such as PhoneGap and Titanium Appcelerator were very rough and incomplete. So we opted for the traditional route of Apples Objective-C programming language.

    The Apple user interface already has a common image browser control known as "cover flow" in the iPod application. We made use of this and populated it with the images for each question - simply using a different ImageCache preset to resize the original image to fit the small screen.

    Taking on board the problems of text entry on a small screen we devised a new answer input system for the mobile device. The hangman style letter input cut the amount of key presses required to input the answer.

    The Data Integration

    The Quizible mobile game was to be distributed with no quiz data bundle - meaning users could pick what quiz they wanted to try before downloading all the image data. We needed to keep the over-the-air data transfer as small as possible to make it playable over 3G networks whilst players are on traveling to work or idling out in public.

    The Drupal node data is served over HTTP using a combination of the Services package and Views with Views Datasource providing the JSON output style. The iOS application was given an authentication key used to authorise itself against the Quizible RPC server when requesting data. We chose the JSON-RPC server module for encoding the data during transit - this version of the JSON server was selected for its compatibility with the JSON framework for iOS.

    As the Quizible website already has a number of Views configured to return latest quizzes, list of taxonomy categories, top rated quizzes etc we built on these by simply adding a new View Display with a JSON style formatter. These views provided the read-only data consumed by the mobile application to power all its main screen menus.

    The RPC Services provides user login capability and access to actual quiz data - including the answers, hence the need for key based authentication for this data. Score submissions for the mobile leaderboard are also carried out with the RPC service.

    The development of a custom RPC service module was relatively straight forward as it's nothing more than a hook_menu() like structure of methods and associated callback functions accepting arguments in hook_services() and processing data before returning it for encoding as JSON data and sending to the mobile device.

    User Authentication

    We'd built up a considerable Drupal user database over the year - so it was essential we allowed these users to login and use their existing account on the new mobile application. However we didn't have time to create a user registration process for the phone and we still wanted users to be able to record their scores on our leaderboard.

    Facebook connect was the obvious integration, allowing us to provide new Quizible users with a quick way to get going without having to visit the quizible.com site to register for an account. When a user authenticated with Facebook we get their Facebook unique ID and send it to a custom login RPC web service which checked to see if the Facebook ID maps to a Drupal user ID. If a match is found the Drupal $user account object  is returned. If no association to a Drupal user is found, a new Drupal user account is created and a mapping to the Facebook ID is added. The login service then returns the Drupal $user account object back to the mobile application for use with the mobile leaderboard.

    Keeping Score

    Our mobile game didn't have the same user interface as the web based version so the scoring system had to work in a completely different manner. This meant providing a dedicated leaderboard for users to compete on.

    Two types of score leadboard exist - the per quiz leaderboard, and the main global leaderboard. We also needed to keep the score per quiz-question as users could re-visit any quiz to see their previous progress - and the score per question was based on how many right and wrong letters they had guessed so far. We left the per question score calculation to the iPhone app as it would prove to expensive to be calculating this on the server during submission.

    When scores were submitted back to the Drupal webservice it triggered a re-calculation of the users overall score for the global leaderboard, and cleared the leaderboard cache to show the new scores.

    Keeping the leaderboard up to date posed some challenges for us. 

    There was never a definitive end to a quiz, so when should the score be added to the leaderboard? We opted to cache the score in the iPhone application and resync when a user exited a quiz.

    What if the user was off-line when they finished a quiz? The application stores a list of all quizes and scores. The network connection was checked regularly in the background and when a connection is made the scores are submitted back to the Drupal site via a custom webservice. The actual leaderboards are still visible whilst offline by using a HTML5 Manifest cache.

    Performance

    We've read many stories about how iPhone applications had exploded in popularity and killed servers due to traffic overload. The problem was in the back of our mind whilst building the Drupal backend of the iPhone application.

    The main Quizible website is backed by Varnish caching for the pages - but this wasn't possible for the JSON web service calls to be cached so all webservice communication is carried out on a sub domain aliased to the same server. This allowed Varnish caching to be ommitted from the domain and gave us scope for moving the mobile API off to its own front end server in the future if traffic demanded it.

    Launch

    The approval process was mostly painless - the initial rejection from Apple was regarding user generated content of questionable copyright content - mainly Disney and Pixar movie stills (I wonder why? :-) )

    Thankfully Drupal's CCK, Views & Rules tools made it easy to build a Quiz moderation queue, flagging to indicate the Quiz was "mobile friendly", and an email notification system to alert moderators that new Quizes were available for review! After showing our co-operation to Apple the app was approved for sale.

    Our launch timing could not be more perfect - we hit the Apple AppStore Christmas eve deadline perfectly - meaning no other apps would be approved until after the Christmas holidays, giving us some opportunity to get noticed in the new releases ... maybe. 

    Marketing

    The app went live just before Christmas, we submitted a press release and posted various promo codes on popular forums such as Touch Arcade and twitter.

    On the existing Quizible site we decided to redirect users using iPhones or iPads to the dedicated promo splash page by simply checking the useragent of the client. Little tweaks like this have helped to bring in additional sales each day.

    After the initial launch we managed to hit the top 10 in the trivia games category which resulted in a large increase in sales, we also gave the application away for free for one day which saw it jump to number 1 in the free trivia section (and as a knock on effect we went to #1 in the trivia section in Taiwan!)

    Quizible hasn't quite had the success of say Angry Birds but continues to make modest revenue which is nice given the project was initially a proof of concept in Drupal!

    May 05 2011
    May 05

    I was lucky enough to be able to give another presentation at this year's excellent DrupalCamp Nashville, sponsored by Music City Networks, 7 Sudos, Tropo, The Tennessean, and a number of other splendid companies. This year, I decided to present on the Austin Peay State University mobile website that I've been building for the past few months along with the help of interns Jason Bell, Brian Barbour, APSU staff Rollow Welch, Terry Damron, Bill Persinger, and Ryan Forsythe. The site was originally begun in Drupal 6 with a traditional mobile theme, but I decided earlier this year, after seeing a great presentation at DrupalCon Chicago by Treehouse Agency that I wanted to convert the site to use the jQuery Mobile library to make the interface more touch/finger oriented. I think the outcome is a great example of what you can do with Drupal 7, HTML5, some CSS3, and jQuery Mobile.

    My slides are shown below and attached to this post in PDF format. I'm hoping to be able to post a video of the session as soon as I have that in hand.

    Building a Mobile Drupal Site - Presentation Transcript

    1. Building a Mobile Drupal SitePresented by Mark W. Jarrell [email protected]?eetthought.com Twitter: attheshowApril 30, 2011DrupalCamp Nashville
    2. Overview? Showcasing the new Austin Peay State University mobile site (m.apsu.edu)? Talking about development process? How it works
    3. Demo
    4. Why is this site important?? APSU already has native iPhone and Android apps. Needed something that would work for other devices too? Since most administrators are using touch screen devices, still focused primarily on optimizing interface for iPhone/Android? This site is more likely to be used by people who arent currently part of the university e.g., potential students, community members, potential employees
    5. Going Mobile - Methods? A) Keep current site theme same, use separate theme for mobile browsers. Only one URL.
    6. Going Mobile - Methods? B) Keep current site same, add a new mobile site with a separate URL and redirect users to that.
    7. Going Mobile - Methods? C) Restyle current site such that it works better on mobile browsers (CSS3 Media Queries) - See http://bit.ly/dWqtGm
    8. Going Mobile - Methods? We chose: B) Keep current site same, add a new mobile site with a separate URL and redirect users to that.
    9. What was the process?(Executive Summary)? Worked with Public Relations and Admissions to come up with a feature list? Designed initial theme? Originally started building this site in Drupal 6
    10. What was the process?(Executive Summary)? Upgraded content to D7 in January/February? Upgraded theme and custom modules to D7 in February/March? Converted existing theme to be a subtheme of "jQM" theme in April? Added in jQuery Mobile module/library in April? Site of?cially launched this week
    11. Content - What goes into the site?? Whats do we include here in mobile version thats not on the main site? ? Focus: on-the-go users ? Prepared for quick actions (e.g., Request Info, Campus Map, Schedule Campus Tour, etc.) ? Keep everything as "slim" as you can. Try to make it bite-sized. Less text unless it’s a news article or blog post ? Make your forms as short as you possibly can or youll lose them
    12. Whats jQuery Mobile?? http://jquerymobile.com/? "Touch-Optimized Web Framework for Smartphones & Tablets"? Basically gives you ways to stylize your HTML5 content and page elements such that they are easier for ?ngers (as opposed to point & click) to interact with
    13. HTML5? <!DOCTYPE html> (Way simpler than doctypes in HTML4!)? jQuery Mobile only works with HTML5 <section> <article> etc. not necessary to get it up and running.? jQuery Mobile elements are initialized when "data-role" attributes exist in your HTML code? Example: Radio buttons add <?eldset data-role="controlgroup"></ ?eldset> around your buttons ? Demo: http://jquerymobile.com/demos/1.0a4.1/#docs/forms/forms- radiobuttons.html
    14. Page Refreshes? Page loads are done via AJAX-style requests. Browser doesn’t refresh the page when it changes.? Have to add HTML5 elements like <div data-role="content"></div> ...into your page.tpl.php ?le? Allows you to do smartphone style transitions such as wipes from one page to another.? Note: The page refresh method of jQuery Mobile makes interacting with the admin interface tricky. Usually have to type in /admin to get to admin theme.
    15. What are jQM and the jQueryMobile module?? These are developed by Tree House Agency (NJ Drupal shop)? “jQM” is a base theme like Zen, etc.? It modi?es your form elements so that they have necessary data-role information. Also adds some useful classes to your page that you can use in your CSS? Modify these template ?les and drop them into your subtheme
    16. What are jQM and the jQueryMobile module?? jQuery Mobile module - Adds the JS library into your pages ? Also currently includes a patch to make the basic library work with Drupal better ? Get the one at Drupal.org called “jquerymobile” not “jquery_mobile”
    17. Mobile Tools Module? This goes on your main site and controls who sees what? Includes a lot of functionality like: ? Built in mobile browser detection capability ? Theme switching ? Redirection ? Use of external libraries for browser detection such as WURFL and Browscap
    18. Recap? How it works: User comes to www.apsu.edu using a mobile device, gets redirect to mobile site? m.apsu.edu has much lighter content, focused on a user who is on-the-go? Get to use a touch-oriented UI (if their smartphone supports HTML5, JS, etc.). Otherwise, they see more basic HTML version of content.
    19. Recap? Modules & Themes Used ? jQM - base theme ? jQuery Mobile - module & JS library ? Mobile Tools - module for detection and redirection
    20. Further Reading Links? “Mobile Marketing: Strategy challenges for advancement and enrollment” session with Bob Johnson http://www.slideshare.net/bestbob/mobile-marketing-strategy- challenges-for-advancement-and-enrollment? DrupalCon Chicago Presentation from Treehouse Agency: http://chicago2011.drupal.org/sessions/drupal-go-jquery-mobile? Metal Toad article on CSS3 Media Queries (if you’re going that route): http://bit.ly/dWqtGm
    21. Building a Mobile Drupal SitePresented by Mark W. Jarrell [email protected]?eetthought.com Twitter: attheshowApril 30, 2011DrupalCamp Nashville
    22. Need Help?? Consulting? Theming mark@?eetthought.com? Module Development? Training? Migrating a legacy system to Drupal
    Mar 26 2011
    Tom
    Mar 26

    On thursday Northpoint, who recently became an Acquia partner gave a presentation on "Mobilizing Your Organization With Drupal". The webinar was presented by myself and Matt Dorman.

    For who want to review the slides, or missed the webinar, here is the presentation.

    View the discussion thread.

    Mar 22 2011
    Tom
    Mar 22

    logo acquiaFor who is following this blog and the Mobile Tools module, has noticed some spike in my contributions the last days ...

    I would like to have a more even distribution of my contributions, but day to day work brings my focus often for longer periodes to different domains (like the Marthastewart new solr integration).

    However, for the upcoming Acquia Webinar that I will co-presenting this coming thursday, I did an extra effort to work on the module and write some documentation. With thanks of course to Northpoint to give me the time to work on these projects!

    So, if you want to learn more about Drupal and mobile and hear me talking about Mobile Tools, tune in tomorrow to the Acquia webinar:

    If you already have questions up front, you can post them as comments!

    View the discussion thread.

    Mar 21 2011
    Tom
    Mar 21

    Since we all love the Context module so much, I figured it was time to integrate Context with Mobile Tools and create a special Mobile Tools plugin.

    The new dev version of Mobile Tools currently allows you to create a context based on device type (mobile or desktop) or device groups.

    In order to use this functionality, just create a new context and search the context for mobile devices context
    Mobile Tools context

    This can be very practical to configure your regions depending on the device that is accessing your site!

    By creating your own device detection plugin, you can define your own device groups.

    View the discussion thread.

    Mar 18 2011
    Tom
    Mar 18

    Mobile DrupalWith an ever increasing number of users for the Mobile Tools module ( > 4000), I am looking to assemble a list of mobile drupal sites (that use or not use the mobile tools module). I get more and more requests from people asking for examples of mobile Drupal sites.

    If I get a good amount of responses, I will feature these sites on this blog in order to demonstrate the mobile capabilities of Drupal and give readers some inspiration when thinking about their mobile site, functionality and design.

    If you are interested in getting your site listed, please leave the url as a comment!

    To name already a few:

    • ... your site ...
    Feb 14 2011
    Tom
    Feb 14

    As I already have blogged before, if you are using Varnish as a page caching mechanism, Drupal cannot be used to detect the device that is visiting your website.

    Already some examples have been created to detect devices in Varnish and add a header string that allows the Drupal backend to know about the device type.

    This is just a small snippet that I use to redirect mobile users to a mobile url and desktop users to the desktop url.

    # vcl_recv routine
    sub vcl_recv {
      call device_detection;
     
    # other site specific vcl rules follow here
     
    }
     
    # Routine to try and identify device
    sub device_detection { 
    	# Default to thinking it's a PC
    	set req.http.X-Device = "pc"; 
     
    	# Add all possible agent strings
     
    	# These are the most popular agent strings
    	if (req.http.User-Agent ~ "iP(hone|od)" || req.http.User-Agent ~ "Android" || req.http.User-Agent ~ "Symbian" || req.http.User-Agent ~ "^BlackBerry" || req.http.User-Agent ~ "^SonyEricsson" || req.http.User-Agent ~ "^Nokia" || req.http.User-Agent ~ "^SAMSUNG" || req.http.User-Agent ~ "^LG" || req.http.User-Agent ~ "	webOS") { 
    	    set req.http.X-Device = "mobile"; 
    	  }  
     
    	# These are some more obscure agent strings
    	if (req.http.User-Agent ~ "^PalmSource"){
    	  set req.http.X-Device = "mobile"; 
    	}
     
    	# Decide if we need redirection
    	if(req.http.X-Device == "mobile") {
    	  if(req.http.host !~ "m.domain.ltd"){
    		error 750 "m.domain.ltd";
    	  }
    	}
    	else {
    	  if(req.http.host ~ "m.domain.ltd"){
    	  	error 750 "www.domain.ltd";
    	  }
    	}
    }
     
    # Redirection routine
    sub vcl_error {
      if (obj.status == 750) {
        if (obj.response ~ "m.domain.ltd") {
          set obj.http.Location = "http://m.domain.ltd" req.url;	
        } elsif (obj.response ~ "www.domain.ltd") {
          set obj.http.Location = "http://www.domain.ltd" req.url;
        }
        set obj.status = 302;
        return(deliver);
      }
    }
    Jan 12 2011
    Jan 12

    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 Be Sociable, Share!
    Jan 12 2011
    Jan 12

    Previous articles have discussed the conceptual groundwork and setup of mobile sites in Drupal. It’s now time to look at a number of themes and modules which will help you in your endeavours. We’ll also cover a number of custom fixes which can be made to the HTML, CSS and JS in your site.

    Mobile themes

    Funnily enough, the selection of the mobile theme is looking to be one of the least important technical consideration with the whole mobile site. It’s one area where I am not in the best position to comment on the various merits of themes as I haven’t really tested theme all. I went with Nokia Mobile because it seemed to have a solid base, being based on code developed by Nokia. That said, I did have to make a number of changes to it to get it to work in with my site. Be prepared to get your hands dirty with page.tpl etc. The Adaptivetheme Mobile theme looks quite promising, being a sub theme itself it would naturally fit well with a desktop theme derived from the same base.

    Nokia Mobile “Provides different presentation layers to best serve basic devices and high-end smartphones.” Mobile Garland Garland inspired mobile optimized Drupal theme intended to be used with a mobile optimization module Mobile Plugin. Adaptivetheme Mobile Hurrah! A mobile sub theme. “Adaptivetheme Mobile is a subtheme for Adaptivetheme. It is designed purely to build Drupal mobile themes for mobile web devices (for mobile websites).” Mobile “intended to return only clean HTML with no styling (images and styling in content is maintained) .mobi “Display a mobile, portable format.”

    Mobile modules

    There are a lot of options available to you when it comes to deploying modules to help you with your task. I am very much of the mind that modules should only be deployed if they are fit for the task and don’t introduce too much overhead or code you don’t understand. My aim is to keep things as “pure” as possible. In many cases you may be better writing your own custom code if you feel comfortable doing that.

    Many tutorials recommend going with Domain Access and Mobile Tools with Browscap. It is a combination which could work well for you. However, I ended up not deploying any of these modules, chosing to go my own way. I’ll walk through each of the modules, their main features and why I went the way I did. It basically boiled down to the fact that Apache, settings.php and my own custom tweaks got me most the way there.

    Domain Access

    Domain Access is a popular suite of modules which can be used to manage (sub) domains for a (mobile) site. It is exceedingly well documented and structured. It looks to be a high quality module which supports a lot of functionality. Many mobile tutorials speak highly of it and recommend it for mobile sites.

    Knowing relatively little about the module I reviewed its main features to see what it had to offer a mobile installation. From my quick review I have been unable to find anything compelling for the problem set I was facing. That said, if your mobile site is to diverge significantly from the desktop site you may find that some of the customisation features quite useful. There may well be stuff that I am missing and would be happy to be enlightened. The relevant features are as follows:

    • Domain Access: The core module allows for (sub) domains to be registered. This is really just the basic setup for the modules. In order for this to work your DNS and VirtualHosts need to be set up as you normally would for a multisite. ie. each domain pointing to the IP of your Drupal installation.
    • Domain Alias: It is possible to define domain aliases for each registered (sub) domain. eg www.example.com -> example.com. Alternatively, this result could be achieved by adding some aliases in you VirtualHost section in Apache.
    • Domain Theme: Allows you to define a theme for each (sub) domain. Alternatively, if you were using a multisite setup (or some conditional logic) you could set the default theme in settings.php.
    • Domain Config: Offers an extensive set of site configuration options including email, slogan, mission, footer, frontpage, anon user, admin theme, time, cache, menu mappings. Most of these tweaks can be achieved by traditional means. Conf variables can be overridden in settings.php. Custom menu blocks can be placed into regions.
    • Domain Source: Source domain for linking to content. This ensured that some links are rewritten to point to main site. In a mobile setup you would want the site to operate as normal (no rewriting). The duplicate content can be fixed with canonical URL link in the head.

    Mobile Tools

    Mobile Tools is a popular module which has a bunch of handy utility features most mobile sites could use.

    • Detection of UA and redirect based on Browscap and WURFL:Possible to map user agents to themes. More sophisticated if Browsercap or WURFL is used. This redirection should be taking place outside of PHP so I am a fan of doing this in Apache rewrite rules or maybe even a caching/reverse proxy layer. This alternative approach has been discussed above.
    • Block telling users of Mobile site: Helpful but easy to add manually.
    • Panels integration: No doubt very helpful if you are using Panels, as Panels own a path and that’s it. This could be a deal breaker so this could be essential. Personally, I stuck to very simple design so Panels wasn’t an issue for me.
    • Permissions integration: Mobile roles can be used to turn block aspect of the site based on permissions. This is a really good idea and a neat way to turn stuff off.
    • Change number of nodes on homepage: Helpful but could be done with a different view exposed as a block.
    Drupal Support for Mobile Devices [Rachel Scott] Overview of the Mobile Tools module with screenshots. Mobilize Your Drupal Site with Mobile Tools Overview of the Mobile Tools module describing multisite setup.

    Mobile Plugin

    Wide range of features. Tackles some practical isses such as word breaks, scaling images, video embedding, filtering JS. Does device detection and provides own mobile theme. Unfortunately the doc specifies that “Page caching must be off to support multiple themes!”. This warning would put most people off. Does this apply even if two sites are being used?

    Browscap

    A popular module which returns capabilities based on user agent. The module will fetch updates to a database of browser user agents. Integrates with Mobile Tools.

    WURFL

    “The WURFL module helps you in detecting the device capabilities of the mobile device visiting your website.” Integrates with Mobile Tools. Knowing the capabilities of a device at a very fine level of granularity could be helpful if you are into eeking out every enhancement you can. the question is whether you need this level of control.

    Module code vs Theme code

    Adding a mobile version of your site will make you think about code duplication issues. If you have custom logic in your theme for the desktop site then there is a pretty good chance that a large chunk will be copied across to the mobile site. Bad news. Much of what makes it into themes is not 100% concerned with presentation. It’s hard to draw a line but if the code is required for mobile and desktop then it is a good candidate for being factored out into a more central place such as a module. Less code means less work for you in the future. If you do have custom code in template.php then take a look through it and see what can be moved.

    Custom content

    Not all changes can be made in the theming layer, it will be necessary to change and optimise the content served.

    Custom blocks

    Managing block configuration (region, order, title, paths, permissions, etc) is a right royal pain in the you know where, especially if you have a lot of blocks and you need to deploy across dev, staging and production. Going into the blocks admin interface and moving stuff around, editing, saving and repeating gets old real quick. Configuration concerns such as this have been overcome largely though code from DevelopmentSeed. Features to hold logic and configuration for grouped functionality. Features work nicely together with Context, which allows for Blocks to be positioned according to an overarching context. Cool. Context could be the answer we are looking for. It certainly is for a normal desktop site.

    However, when it comes to configuring blocks for a mobile site, Context only knows about the current theme. This is a known issue for Context. There is another module, called Features Extra which possibly offers a way to capture config info for blocks, however it too suffers with themes. AFAICT it still isn’t possible to capture block config with multiple themes. Bummer. I’d be interested to know if there are solutions here.

    In the meantime you can manually configure blocks the old school way but it really isn’t ideal.

    Custom modules

    This is one area I was unable to nail as well. In a few places it would have been very handy if I could have turned off a module dynamically to make the mobile site a bit simpler, eg. colorbox, admin menu. AFAICT there is no way to do this. Tracing the calls during bootstrap, I see that module_load_all() is called very late in the procedure at _drupal_bootstrap_full(). module_load_all() calls module_list() which gets all active modules. It would be great if module_list() could look to conf variables to respect a stop filter of modules. Not going to happen I know, but would be handy.

    This is where the permissions integration in Mobile Tools could really shine. Instead of disabling a module you could control the operation of a module via permissions. Most modules should have permissions limitations on functionality and so can be turned off for the mobile site.

    One way to work around this is to mop up the HTML/JS/CSS in the theme layer. This approach is ugly, error prone and brittle, but does hold some promise. You will find recipes similar to the following around the traps:

    /**
    * Implementation of hook_preprocess_page().
    */
    function mw_mobile_preprocess_page(&$vars) {
    if (!cuf_mobile_is_mobile()) { return; }
    // Strips out JS and CSS for a path.; // http://www.mediacurrent.com/blogs/remove-or-replace-jscss-page
    // WARNING: The code below messes up jQuery Update even when no scripts are
    // replaced. Use at own risk.
    $remove_csss = array(
    //’colorbox’ => array(‘/styles/default/colorbox_default_style.css’),
    );
    $remove_jss = array(
    //’colorbox’ => array(‘/js/colorbox.js’, ‘/styles/default/colorbox_default_style.js’),
    );
    // JS
    $scripts = drupal_add_js();
    if (!empty($vars['scripts'])) {
    foreach($remove_csss as $module=>$paths) {
    foreach($paths as $path) {
    $module_path = drupal_get_path(‘module’, $module);
    unset($scripts['module'][$module_path . $path]);
    }
    }
    $vars['scripts'] = drupal_get_js(‘header’, $scripts);
    }
    // CSS
    $css = drupal_add_css();
    if (!empty($variables['css'])) {
    foreach($remove_csss as $module=>$paths) {
    foreach($paths as $path) {
    $module_path = drupal_get_path(‘module’, $module);
    unset($css['all']['module'][$module_path . $path]);
    }
    }
    $vars['styles'] = drupal_get_css($css);
    }
    }

    In the end I gave up on going down this path because I was running into a problem with jQuery not being updated, leading to JS errors on the page. It was too brittle for me to trust.

    For me, the take away is that you are pretty much stuck with using the some modules if you are sharing the database. You just have to be aware of this when designing the site. The only way to solve this is to place some conditional login into you own custom modules which checck for the site being mobile. If you are using contrib then things will be a trickier.

    You may desire have custom primary and secondary links for the mobile site. If you really have thought mobile first then maybe the menus will be the same :) but there’s a good chance they will be paired down for the mobile site. It’s not possible to easily define two sets of primary menuas, one for mobile and one for desktop. However, Mobile Tools offers a way to map primary/secondary menus to other menus. There are two other options though if you don’t want to install Mobile Tools.

    • Define different menus (eg. Primary Mobile) and drop them into desired region using Blocks. Comment out the primary links in page.tpl.
    • Programmatically set the links in a custom module

    In the end I just programmed these menus in code in my mw_mobile module because the menus had some logic in them for login/logout links:

    /**
    * Implementation of hook_preprocess_page().
    */
    function mw_mobile_preprocess_page(&$vars) {
    if (!mw_mobile_is_mobile()) { return; }
    // Completely hijack the primary menu and set it from code. This allows
    // the primary menu to be managed in features for the desktop site. We just
    // need to oveerride it here.
    $vars['primary_links'] = array();
    $vars['primary_links']['blah'] = Array (
    ;’title’ => t(‘Blah’),
    ‘attributes’ => Array(‘title’ => ‘Blah.’),
    ‘href’ => ‘blah’
    );
    // etc
    }

    Custom Views

    This section really gets back to the “mobile first” and “responsive web design” concepts we discussed earlier. Views are very powerful and there is a strong temptation to make them as sexy as possible, displaying images, extra content, edit links, star ratngs and the like. Step back and take a look at what you are doing. It maybe possible to design a simple display which works well in mobile and desktop.

    Often you really do want to display rich tabular information in the desktop version of the site. In these cases you shouldn’t compromise – you’ll need to create different versions. In these cases progressive enhancement doesn’t really cut it as you want to return more content, not just tweak the presentation.

    If it is a View Block which is giving you grief then just make a mobile version and use that instead. Use the block system to place different blocks for the different themes.

    If it is a View Page then you could be in trouble as the View takes hold of the path and it is difficult to customise that on a per site/theme basis. One solution is to expose the View as a Block (with a mobile version) and then place that block on a Page (node) or menu path you have made. In this case the page is acting like poor man’s Panels. A bit ugly but it works.

    If you are lucky you might be able to define a custom formatter which just returns a blank (or a simple version) if the site is mobile.

    A final alternative is to define View templates which have some conditional logic in them. This is possibly the purest way but I think it could become a maintenance issue. We are trying to minimise duplication and effort – creating new files with extra display logic is best avoided.

    Custom Panels

    I’ll come clean here and own up to not having caught the Panels bug just yet, being content to limit my degrees of freedom. Yes, I am that boring :) Anyway, Panels faces a similar problem as Views Pages in that they are tied to a path which isn’t scoped by a theme (as Blocks are). In this case, Mobile Tools could be quite helpful and showing different layouts for a Panel.

    Custom Variables

    Drupal can be configured with a whole bunch of variables, many of which are available for editing in the site configuration part of the site. Fire up phpMyAdmin and browse the variable table to get an idea of what is available. These variables are site wide and as such will apply equally to the mobile and desktop versions in our multisite setup. It is possible to override these variables for the mobile site by tweaking settings.php. We have already seem this in action for the default theme. You can do it for other things as well. Mobile Tools offers an interface for this but you can do it manually. I have found that only a small number of rarely changed variables need to be tweaked and so settings.php is a viable option.

    $conf = array(
    ‘theme_default’ => ‘mw_nokia_mobile’,
    ‘googleanalytics_account’ => ‘UA-xxxxxxxx-2′,
    );

    Output tweaks

    Mobile devices have special requirements, not all of which could be handled by the theme templates alone. The metadata and content of the sites may need some special work. The Rethinking the Mobile Web slideshow above noted that we need to adjust and compress content to make it palettable for mobile. This is where a lot of that nasty work happens. You’ll probably only run into these issues after testing the site for real. No doubt you will have your own special set of problems to deal with. The http://drupal.org/project/mobilepluginMobile Plugin module plugs some of these holes.

    ImageCache

    You probably have a bunch of ImageCache presets defined for your site, which may or may not be captured in Features config. These presets may be outputting images at a size which is too big for the mobile site. Anything wider than 100px is probably too big. You are aiming to be frugal with bandwidth as well as screen real estate. Time to get shrinking those images. See hook_preprocess_page code below.

    Secure Login

    If you are using the Secure Login module, you may run into difficulties if you have the multisite setup. The way I had Secure Login configured was to specify the URL to redirect to. This URL is of course for the desktop version of the site and your mobile users will be routed to the desktop site after they log in. They may not notice it if URL redirecting is working for mobile users but we would want to minimise redirects such as this.

    It is possible to leave the Secure Login URL blank and then it will apparently use the base_url defined in settings.php. This would be a sensible approach, however, I was having all sorts of path difficulties with ImageCache if I specified these URLs. Don’t know why. Anyway, the easiest solution for me was to stick with the hardcoded URL for Secure Login and then to fix it up in the module.

    /**
    * Implementation of hook_preprocess_page.
    */
    function mw_nokia_mobile_preprocess_page(&$vars) {
    // imagcache images are shrunk to mobile size
    $fix_regions = array(‘content’, ‘right’, );
    foreach($fix_regions as $fix_region) {
    _mw_nokia_mobile_fix_imagecache($vars[$fix_region]);
    }
    // secure login will target the url you entered into the site config.
    // there might be a better way to fix this but we just string replace here
    _mw_nokia_mobile_fix_secure_login_form($vars['content']);
    }

    /**
    * Secure login hardcodes the URL entered in the config: securelogin_baseurl
    * This will be the desktop version of the site. We need to change it to the
    * mobile version. There isn’t an obvious way to do this via code, unless you
    * write your own hook_form_alter but that would usurp the function of
    * securelogin. So we just mop up afterwards. These login pages will be
    * cached anyway.
    * eg https://example.com -> https://m.example.com
    *
    * NB: It MIGHT be possible to leave out securelogin_baseurl in the config and
    * manually set the base_url in the settings.pgp for the site. However, when
    * I did settings like this in the past I ran into problems… can’t remember
    * what they were now… So this might be a solution which would avoid the need
    * for this code.
    */
    function _mw_nokia_mobile_fix_secure_login_form(&$text) {
    if (!module_exists(‘securelogin’)) {
    return;
    }
    $sec_url = variable_get(‘securelogin_baseurl’, ”);
    if (empty($sec_url )) {
    return;
    }
    $new_url = str_replace(‘https://’, ‘https://m.’, $sec_url);
    $pre = ‘<form action=”‘;
    $paths = array(‘/user/login’, ‘/user/register’);
    foreach($paths as $path) {
    $search = $pre . $sec_url . $path;
    $replace = $pre . $new_url . $path;
    $text = str_replace($search, $replace, $text);
    }
    }

    /**
    * Map imagecache presets to smaller presets. This is VERY UGLY because you
    * need to correct for the width and height as well. Sorry to have impinged
    * upon your senses!
    * Adapted from http://groups.drupal.org/node/50678#comment-227203
    */
    function _mw_nokia_mobile_fix_imagecache(&$text) {
    if (!module_exists(‘imagecache’)) {
    return;
    }
    // mappings. ignore: slider_perview, slider_thumbnail
    // old ic, old width, old height, new ic, new width, new height
    $mappings = array(
    array(‘thumbnail_small’, ’83′, ’83′, ‘mobile_thumbnail’, ’75′, ’75′),
    array(‘thumbnail’, ’100′, ’100′, ‘mobile_thumbnail’, ’75′, ’75′), // thumbnail last
    );
    // fix
    $file_url = base_path().file_directory_path();
    foreach($mappings as $mapping) {
    list($old, $old_w, $old_h, $new, $new_w, $new_h) = $mapping;
    $old_path = $file_url .’/imagecache/’ . $old;
    $new_path = $file_url .’/imagecache/’ . $new;
    $old_class_size = ‘imagecache-’ . $old . ‘” width=”‘ . $old_w . ‘” height=”‘ . $old_h . ‘”‘;
    $new_class_size = ‘imagecache-’ . $new . ‘” width=”‘ . $new_w . ‘” height=”‘ . $new_w . ‘”‘;
    $text = str_replace($old_path, $new_path, $text);
    $text = str_replace($old_class_size, $new_class_size, $text);
    }
    }

    Search snippets URLs

    I’m not sure if the following applies to ordinary Drupal search but it certainly does with Apache Solr Search. The URLs for the individual search results were coming back with the fully qualified URL pointing to the desktop site. This was solved by a bit or mopping up in a base feature, mw_base.

    function phptemplate_apachesolr_search_snippets($doc, $snippets) {
    // mobile site?
    $mobi = module_exists(‘cuf_mobile’) && cuf_mobile_is_mobile();
    $url = $doc->url;
    if($mobi) {
    $url = str_replace(‘http://’, ‘http://m.’, $url);
    }
    }

    GMap

    The combination of Location and GMap is a very popular one on Drupal sites. GMap module is currently targetting version 2 of the Google Maps API. Version 3 offers a bunch of new features for mobile devices.

    Google Maps JavaScript API V3 “The Google Maps Javascript API lets you embed Google Maps in your own web pages. Version 3 of this API is especially designed to be faster and more applicable to mobile devices, as well as traditional desktop browser applications.”

    For now users of GMap are stuck on v2 but there is active development in GMap to bring the module up to support v3.

    WYSIWYG

    WYSIWYG textareas do not display properly on some mobile devices. You need to turn them off.

    WYSIWYG on mobile devices Discussion on WYSIWYG issue queue regarding the difficulties faced on a variety of devices. End conclusion appears to be that you need to turn it off for best results.

    How to turn of WYSIWYG? After a bit of poking around I worked out that setting the ‘format’ for the textarea to an empty array was the way to do it. The following code in your mobile module will do the trick for comment and node bodies. If you have other forms which need fixing then you’ll need to do a bit of debugging to suss out what the form_id and element id is.

    /**
    * Implementation of hook_form_alter.
    */
    function mw_mobile_form_alter($form_id, &$form) {
    if (!mw_mobile_is_mobile()) { return; }
    // turn off wysiwyg forms for textareas. you need to manually find the form
    // with wysiwyg and then work out its id and where ‘format’ is.
    //print $form_id['#id'] . ‘ ‘;
    $no_wysiwyg = array(
    ‘comment-form’ => ‘comment_filter’,
    ‘node-form’ => ‘body_field’
    );
    $id = $form_id['#id'];
    if (array_key_exists($id, $no_wysiwyg)) {
    //print_r($form_id);
    $form_id[$no_wysiwyg[$id]]['format'] = array();
    }
    }

    Tabs

    The primary and secondary tabs which appear on the top of the page tend to take up a fair amount of horizontal space and will be the element which causes horizontal scrolling. These tabs can be easily restyled to display as a traditional list. You can also update page.tpl and move the tabs to the bottom of the page so they don’t detract from the main content.

    Flash

    Flash is not going to work in iPhones, iPad and many other devices. It’s also heavy and resource intensive. As such it shouldn’t reallu be used for content or navigation on the mobile site. The exception might be to show video content, however, even in this case there might be better workarounds.

    Suckerfish

    Suckerfish provides dropdown menus which can take up a lot of room. The hover metaphor doesn’t work for touch devices. Best avoided.

    Make sure that links are big enough to clickable: large with enough whitespace around key navigation links.

    YouTube

    Mobile devices such as the iPhone and iPad may have a special app to handle YouTube videos natively so clicking on a link is preferable than displaying an embedded video.

    Advertising

    Yes – ads can be optimised for mobile as well.

    Google Mobile Ads “In May 2010 Google acquired AdMob, a leading mobile advertising network that developed innovative mobile-specific ad units and solutions, to significantly enhance our mobile display ad services for publishers.”

    Testing

    Testing an afterthought? Never :) The fact is that a lot of the hard work is in getting over the config hurdles. once the mobile site is up and running you are going to uncover a bunch of things you never dreamed about. Here’s a quick checklist of things to look out for:

    • UA testing and redirect working.
    • Boost/Drupal Core page caching working.
    • SSL login working OK.
    • Basic functionality and navigation operational.
    • Theming is up to scratch.
    • Site fulfills its goals.
    Be Sociable, Share!
    Jan 12 2011
    Jan 12

    A previous article covered some basic groundwork for mobile sites in Drupal. This article goes on to look at different ways to setup a mobile site in Drupal. It covers single site, multisite, single site with settings.php tweak and the Domain Access module. Caching strategies, redirect rules and other server side settings are also discussed.

    RESTful design of URLS

    REST defines the architecture of the World Wide Web. One of the principles of REST is that a single URI represents a resource and that resource is conceptually different from the representations returned to the client.

    Representational State Transfer “Representational State Transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web. The term Representational State Transfer was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation.[1][2] Fielding is one of the principal authors of the Hypertext Transfer Protocol (HTTP) specification versions 1.0 and 1.1″

    Here’s the passage from Roy Fielding’s thesis (emphasis added) which discusses the differences between resource and representation:

    “This abstract definition of a resource enables key features of the Web architecture. First, it provides generality by encompassing many sources of information without artificially distinguishing them by type or implementation. Second, it allows late binding of the reference to a representation, enabling content negotiation to take place based on characteristics of the request. Finally, it allows an author to reference the concept rather than some singular representation of that concept, thus removing the need to change all existing links whenever the representation changes (assuming the author used the right identifier).”

    A resource is named by a URI. The server chooses the best representation to provide to the client based on headers sent by the client. In this case we are looking at the User Agent.

    If we were to follow RESTful principles then the mobile site should indeed be served from the some domain as the desktop site. ie. one resource, different representations. In this scenario the HTML returned to the mobile client is just a different respresentation to that provided to the desktop site. This is a natural way to design a web app as it means that there is only one “canonical” URI for the resource with no chance of nasty duplicate content issues. From an SEO point of view this is desireable. However…

    Caching, the fly in the ointment

    We’ve just seen that serving different representations from a single URI is a good thing from many perspectives: mobile first, progressive enhancement, REST and SEO. However, there is one reason why we may we may decide to go down the path of using two domains instead of one: caching.

    Caching mechanisms, such as Drupal Core and Boost, used the fully qualified domain name of a URI to determine caching keys. This allows the cache to quickly serve content to different clients without knowing the criteria which decides the representation received by the client, ie. the cache just has to know about the URI, it doesn’t need to decipher the user agent. Currently, if different representations are served for the same resource then the cache will likely become populated with a mix of different representations, leading to chaos. For this reason it is generally accepted that having a separate mobile site on a sub domain is a good way to go. ie. we would have two sites:

    Cache by theme for mobile sites mikeytown2 offering some great advice on Apache and Boost rules. .htaccess Mobile Browser Redirect User Agent processing in Apache to redirect to mobile.

    Some users have solved the caching problem AND manage to serve different representations from the same URI. Going mobile with a news site that Just Works describes how browser detection can be done in the caching layer, in this case Squid, before redirecting the request invisibly to another domain. This is the perfect setup as RESTful principles are maintained and the site is scalable. Hats off. Unfortunately not everyone is running a reverse proxy which allows for this kind of setup. A request looks like this:

    1. mobile client does GET http://example.com/about,
    2. Squid (port 80) looks at User Agent, determines device and sends to http://m.example.com/about,
    3. Boost finds “about” in /cache/normal/m.example.com/ -> Static HTML returned OR,
    4. Drupal serves from multisite -> Dynamic HTML returned.

    mikeytown2 claims that it should be easy enough to add some logic into the Boost rules based on user agent, he just needs to know what they are. So there is a good chance that Boost user’s will be able to server both mobile and desktop from two sites with one URI space. From my understanding of the proposed approach it looks like a single domain will be all that is required.

    1. mobile client does GET http://example.com/about,
    2. Boost looks at User Agent, determines device and uses a different “mobile” device rather than “normal”,
    3. Boost finds “about” in /cache/mobile/example.com/ -> Static HTML returned OR,
    4. Drupal serves from single site -> Dynamic HTML returned.

    A slightly different approach has been described in Mobile Detection with Varnish and Drupal where Varnish sets a header which can then be read in the webserver or Drupal. This is a neat approach as it means that device logic needn’t be repeated in settings.php. The flow described by Morten Fangel is as follows:

    1. mobile client does GET http://example.com/about,
    2. Varnish also sets a X-Device header for the device
    3. Varnish looks at User Agent, determines the device and appends it to the hash for the key
    4. Varnish “about” in cache -> Static HTML returned OR,
    5. Drupal serves from single site -> Dynamic HTML returned.

    Assuming you don’t have Squid, Varnish or a patched Boost to hand you will probably have a setup as follows:

    1. mobile client does GET http://example.com/about,
    2. Apache rewrite looks at User Agent, determines device and redirects http://m.example.com/about,
    3. Drupal Core or Boost finds “about” in cache -> Static HTML returned OR,
    4. Drupal serves from multisite -> Dynamic HTML returned.

    Sub domain vs Different Domain

    If you are going to use a separate site to host the mobile site then you are free to chose whatever domain you like. eg. example.mobi. However, it is generally recommended to stick with using a sub domain of the desktop site. This confuses users less and it is possible to share cookies across sites on the same domain.

    Different theme

    As discussed in the previous article, it is possible to serve the same default theme to both mobile and desktop sites and then progressively enhance the desktop site with some extra CSS. The method proposed in Rethinking the Mobile Web at slide 106:

    <link href=’default.css’ type=’text/css’ rel=’stylesheet’
    media=’screen’ />
    <link href=’desktop.css’ type=’text/css’ rel=’stylesheet’
    media=’screen and (min-device-width:1024px) and (max-width:989px)’ />

    This is a very cool way to design a site as it keep things very simple. Mobile is first and then comes the progressive enhancement. However, this isn’t a pattern which is adopted by most Drupal themes where the presumption is for the desktop theme. If we did take this approach it would preclude us from using the majority of themes designed for Drupal so far. Given this, I would say that our Drupal site will support two separate themes, one for desktop and one for mobile. The general approach is to use a multisite setup. define a desktop theme as default in the GUI and then to override that theme via a tweak in settings.php for the mobile site.

    Multisite setup

    Assume we are using two domains due to caching requirements. How do we serve this content? Drupal does have a multisite feature built in where a single Drupal “platform” can support many different site instances. These sites can share all data, no data or partial data, depending on how they are setup in settings.php. In the case of a mobile site we would want to share all data between the sites.

    One possible setup is to create a directory for the desktop and mobile versions under sites/

    sites/

    • all/
      • modules/
        • contrib/
        • custom/
          • mw_mobile/
      • themes/
        • base_desktop/
        • base_mobile/
        • mw_desktop/
        • mw_mobile/
    • default/
    • example.com/
      • settings.php
    • m.example.com/
      • settings.php

    The only trick to get this work is to manually set the default theme for the mobile site in the sites/m.example.com/settings.php file. For every page request, the config in settings.php will override the default variables defined in the variables table in the database.

    $conf = array(
    ‘theme_default’ => ‘mw_nokia_mobile’,
    );

    If you manually set a value like this you won’t be able to change it in the UI, naturally enough. Make sure the theme is active in the GUI.

    Alternative 1: Single site with settings.php logic

    The above multisite setup will work, however, there is something wrong with it. It will stop you from hosting a true multisite setup where the sites share code but have different databases. This may not worry you if you are only hosting a single site for the platform but it could be important if you want multisites. Imagine a site for Company X served on example.com and Company Y is on example.net. You couldn’t use multisites with the above settup because of the reliance on shared files in default/files.

    However, you can achieve a very similar effect with a single site by using a bit of conditional logic in settings.php for example.com and example.net. The idea is to set the theme based on the domain leading to only needing a single site to support desktop and mobile. Add this to sites/example.com/settings.php/

    $parts = explode(‘.’, $_SERVER['HTTP_HOST']);
    if ($parts[0] == ‘m’) {
    $conf = array(
    ‘theme_default’ => ‘company_a_mobile’,
    );
    }

    You could then support mobile with a pure sites setup with shared code and different databases/files. This is a good way to go.

    sites/

    • all/
      • modules/
        • contrib/
        • custom/
      • themes/
        • base_desktop/
        • base_mobile/
    • default/
      • files/ -> empty
    • example.com/ -> company A
      • files
      • modules
      • themes
        • company_a_mobile
        • company_a_desktop
      • settings.php -> with conditional setting of default theme
    • example.net/ -> company B
      • files
      • modules
      • themes
        • company_b_mobile
        • company_b_desktop
      • settings.php -> with conditional setting of default theme
    multi site a) standard theme, site b) mobile theme – same code and same tables? Discussion of multisite setups.

    Alternative 2: Domain Access

    The Domain Access module, discussed later, can set a lot of this up for you including sub domains, domain aliases and themes. You may prefer to use it for convenience, especially if you like configuring stuff in a GUI rather than settings.php or custom modules.

    Mobile global variable

    Modules are going to want to access a global variable which tells them the device accessing the site: mobile or desktop. There are a variety of ways to do this, some set the variable early, others late:

    1. Custom “X-Device” header set in a reverse proxy
    2. Conf variable set in settings.php
    3. Global variable set by a module during hook_init()
    4. API function offered by a module

    It is possible to do this through the use of hook_init() in a custom module. I tried this but ran into problems with timing and module weight. Sometimes you will want the mobile module to be heavy, sometimes light :) In the end I went with an “api” function in my mw_mobile module which stored a static variable. It should be pretty fast and not to cumbersome. Other contrib modules take an approach similar to this.

    /**
    * An API function in a custom module
    * Efficiently returns whether the site is mobile.
    * Other modules should call it as follows:
    * $mobi = module_exists(‘mw_mobile’) && mw_mobile_is_mobile();
    */
    function mw_mobile_is_mobile(){
    static $out;
    if (isset($out)) {
    return $out;
    }
    // set and return
    if (substr($_SERVER["SERVER_NAME"], 0, 2) == ‘m.’) {
    $out = TRUE;
    } else {
    $out = FALSE;
    }
    return $out;
    }

    This approach is perhaps not the best. It may be better to set a global variable very early in the bootstrap process, in settings.php, so that it could be reliably used by all other Drupal code.

    Cross site authentication

    It is possible to set cookies up so that they will be sent no matter what the sub domain. In settings.php uncomment the $cookie_domain variable and set it to the domain, excluding the sub domain. Please note that this will not work if you are using different domains.

    $cookie_domain = ‘example.com’;

    Redirecting the user to mobile

    When a mobile user hits the desktop version of the site you want them to be redirected to the mobile site. There’s at least three ways to do this:

    • PHP
    • JS
    • Apache

    The first inclination maybe to go with PHP as afterall, we are PHP developers. However, this has the shortcoming of requiring that Drupal be bootstrapped before the PHP can be run, destroying the chance to safely cache the page for anonymous users. It’s slow and ineffective. Doing it in PHP therefore isn’t an option. This is the approach some of the mobile modules take but I think it’s something to be avoided.

    You could of couse do a client side check in Javascript for the client’s user agent. This will allow for caching but has the downsides of forcing a full page download. Also, not every client will have JS enabled. Not really an option.

    The final option of doing it in Apache (or your webserver) is the only viable alternative. I went with a recipe similar to the following in my .htaccess.

    # Mobile: force mobile clients across to the mobile site
    RewriteCond %{HTTP_HOST} !^m\.(.*)$
    RewriteCond %{HTTP_USER_AGENT} !ipad [NC]
    RewriteCond %{HTTP_ACCEPT} “text/vnd.wap.wml|application/vnd.wap.xhtml+xml” [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} “acs|alav|alca|amoi|audi|aste|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-” [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} “dang|doco|erics|hipt|inno|ipaq|java|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-” [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} “maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|opwv” [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} “palm|pana|pant|pdxg|phil|play|pluc|port|prox|qtek|qwap|sage|sams|sany” [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} “sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo” [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} “teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|w3cs|wap-|wapa|wapi” [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} “wapp|wapr|webc|winw|winw|xda|xda-” [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} “up.browser|up.link|windowssce|iemobile|mini|mmp” [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} “symbian|midp|wap|phone|pocket|mobile|pda|psp” [NC]
    RewriteCond %{HTTP_USER_AGENT} !macintosh [NC]
    RewriteRule ^(.*)$ http://m.%{HTTP_HOST}/$1 [L,R=302] .htaccess Mobile Browser Redirect Outlines the approach taken above.

    SSL issues

    If you are using SSL on the desktop version of your site then you have a couple of extra hurdles to jump in order to get it working on the mobile site.

    Firstly, as it isn’t possible to set up SSL for two different domains on the same IP address, you will probably need to rent a new IP address for the mobile version of the site. Sort this out with your ISP. It should cost you between $1 and $3 a month for another IP. They may have instructions for setting up A records, static routing for your IP addresses, etc.

    Secondly, you will also need to sort out another certificate for the mobile site. You could purchase a wildcard certificate for the domain and all sub domains. These cost a fair bit more and will save you from buying a new cert. However, it is probably cheapest to get another cert for the mobile site along with a new IP. You will then need to install the certificate on your server and tweak your site config for the mobile site. This certainly is one of the pains of having two separate sites.

    PositiveSSL from Comodo $10 pa. Gandi Free first year then 12 Euro pa.

    Custom version of robots.txt

    A corollary of having a shared database and file system with a multisite install is that you can’t have custom versions of key files such as robots.txt which sits in the root of your Drupal platform. In the simple case I don’t believe that there is any need to have a different version, however, if you do need to support different versions then you can do it with a bit of .htaccess magic. Place the following code under the mobile redirect rule. Just be sure to add robots.txt to the /sites/%{HTTP_HOST}/files/robots.txt.

    # robots.txt: solve multisite problem of only one robots.txt
    # redirects to file in /sites/files/robots.txt
    RewriteRule ^robots\.txt$ sites/%{HTTP_HOST}/files/robots.txt [L] multi-site robots.txt GDO discussion of this approach.

    Duplicate content, Canonical URLs and robots.txt

    You now have two sites where the mobile site replicates all the content of the desktop site. This is a major issue as search engines such as Google will treat is as duplicate content leading to declines in ranking. We need to sort this out. Google came up with the concept of a canonical URL which can be defined in a link element in the head of the HTML page. In our case the link points back to the desktop site.

    <link rel=”canonical” href=”http://example.com/about” /> Specify your canonical Google documentation on how to define a canonical URL.

    We need every page in the mobile site to support this tag. This can be set in your mobile module:

    /**
    * Implementation of hook_init().
    */
    function mw_mobile_init() {
    if (!mw_mobile_is_mobile()) { return; }
    // Add a canonical URL back to the main site. We just strip “m.” from the
    // domain. We also change the https to http. This allows us to use a standard
    // robots.txt. ie. no need to noindex the whole of the mobile site.
    $atts = array(
    ‘rel’ => ‘canonical’,
    ‘href’ => str_replace(‘://m.’, ‘://’, _mw_mobile_url(FALSE)),
    );
    drupal_add_link($atts);
    }

    /**
    * Current URL, considers https.
    ;* http://www.webcheatsheet.com/PHP/get_current_page_url.php
    */
    function _mw_mobile_url($honour_https = TRUE) {
    $u = ‘http’;
    if ($_SERVER["HTTPS"] == “on” && $honour_https) {$u .= “s”;}
    $u .= “://”;
    if ($_SERVER["SERVER_PORT"] != “80″) {
    $u .= $_SERVER["SERVER_NAME"].”:”.$_SERVER["SERVER_PORT"].$_SERVER["REQUEST_URI"];
    } else {
    $u .= $_SERVER["SERVER_NAME"].$_SERVER["REQUEST_URI"];
    }
    return $u;
    }

    The final thing to resolve is whether to set “noindex” on the mobile site. This definitely an area where there is some confusion on the web. After sniffing around I came to the conclusion that it was OK to allow Google to index the mobile site, so long as the canonical links have been specified. This means that any page rank given to the mobile site will flow to the desktop site and you won’t be punished for duplicate content.

    The outcome is that you can go with the same robots.txt for both sites, ie. robots are free to index the mobile site. There is no need to specify a different robots.txt for mobile. You want the same stuff indexed for the mobile as you do with the desktop.

    The one exception to this would be the files/ directory. A recent core update to 6.20 allowed files/ to be indexed. Fair enough, you want your public images to be indexed. However, you could raise the case that files/ shouldn’t be indexed in the mobile site, given that there is no way to specify a canonical link for these binary files. So, you may well want to support a different robots.txt for each site by blocking access to files on the mobile site. This is a very minor issue and probably not worth worrying about.

    Be Sociable, Share!
    Jan 12 2011
    Jan 12

    Recently I was involved in a project to convert a site into a mobile site for Drupal. During the process I had to overcome a number of problems – problems which pretty much everyone designing a mobile site will have to solve. This series of articles covers a bit of theory, the practical problems and the various decisions I made. Hopefully it will help some of you out. The solutions offered may not be the best or only solution by any means – in many cases you need to decide what is best for your site or setup.

    Get amped for mobile

    In the past it has been easy to not even consider mobile when designing a site or an application. However, there are so many compelling reasons these days to treat your mobile site as a key component of your web strategy. Mobile devices are becoming increasingly popular, more of your users will be accessing your site through a phone or tablet. They will expect a good experience from your site or else will not return. Watching a user attempt to browse your unoptimised desktop app on a mobile device is an embarrassing experience for you and frustrating for the user.

    Drupal in a tablet world [Dries Buytaert] Dries opens up a discussion about the future of Drupal for mobile and tablets. “This all begs the question: in a world of tablets and mobile handheld devices, what do we need to do so that Drupal will be a go-to platform? How can Drupal contribute so as to be a player in the ever-expanding ecosystem of tablets and mobile phones?” Everything you ever wanted to know about mobile, but were afraid to ask [Tomi T Ahonen] A long article which covers the myths and misconceptions about mobile. Very useful for getting your head around just what a remarkable medium it is.

    There are many reasons for choosing to develop a mobile web site as opposed to a “native app”. This doesn’t have to be an either/or decision of course, however, developing a mobile site first is probaly a sensible decision. Firstly, the fractured nature (programming language, feature sets, application stores) of the “native apps” space across the various mobile platforms (iPhone, Android, Blackberry, etc, etc) makes development of separate apps an expensive and time consuming process. WebKit and HTML5 offer a lot of promise for developing richer clients which approach the features provided by native apps. It is interesting to note that Google and Apple continue to support WebKit even though they have their own native app platforms. Secondly, the chances are that you are going to have more visitors hitting your site after searching Google than will download a custom app. Optimising this user experience from Google makes sense.

    Design philosophy

    Before jumping into the nitty gritty of tweaking Drupal up to accommodate a mobile site, it’s worth putting in a bit of groundwork. Planning for and designing a mobile website should involve taking a fresh approach to your site or application. By focussing on mobile, and it’s inherent limitations and features, we can concentrate on what is truely important to users. I thoughly recommend that you take 10 minutes and flick through the following slideshow:

    Rethinking the Mobile Web by Yiibu Slideshow covering the old and new ways of doing mobile. “Progressive enhancement” and “Responsive web design” techniques discussed.

    Of particular interest to us is Slide 43 which covers a soup of considerations we face when designing a mobile site. These are some of the thorny issues which crop up:

    • device detection,
    • content adaption,
    • multiple sites,
    • device capabilities,
    • doctypes,
    • multiple templates.

    There are a lot of issues to deal with and this article will deal with many of them. There is no silver bullet to solving a lot of this stuff. However, we will go into the exercise armed with some solid principles which should serve us well. Slide 125 lays it out for us:

    • mobile first,
    • well structured meaningful markup,
    • progessively enhance,
    • adapt content,
    • compress content.

    Drupal as a platform is pretty good at well structured markup, adaptable content and compressed content. Two themes worth pondering a little further at this point are “mobile first” and “progressive enhancement” as they will help us think about the mobile site in a functional way rather than just as a cut down version of the desktop site.

    Mobile first

    Mobile has traditionally been considered an afterthought, if at all. However the landscape has shifted and it is now vitally important. Luke Wroblewski, a strong proponent of the approach, identifies three key reasons:

    1. Mobile is exploding
    2. Mobile forces you to focus
    3. Mobile extends your capabilities

    Focussing on the mobile platform forces the developer to prioritize the important things. What are the key actions and data for your application? Strip everything away and focus on just that. The end result will be an app which is simpler, easier to understand, just as functional and much better. This brings development back from flashy extraneous eye candy to a functional site which is designed to serve the user.

    Some questions you might ponder. Why are your users accessing the site? What are the likely actions they want to perform? What information do they want to access? What’s the simplest way to do it? Do I need that navigation? Are those icons distracting? Is the page fast to load? Do I need a better algorithm for finding nearest locations…

    Mobile First [Luke Wroblewski] Three reasons why Web applications should be designed for mobile first instead. Mobile First [Luke Wroblewski] “In this presentation, Luke Wroblewski will dig into the three key reasons to consider mobile first: mobile is seeing explosive growth; mobile forces you to focus; and mobile extends your capabilities.” Barcelona: Mobile First Eric Schmidt (Google) talks mobile. Google encourages developers to work on mobile first before desktop. “The phone is no longer the phone, it’s your alter ego. It’s the extension of everything we are. It doesn’t think as well as we do, but it has a better memory…. This is the time for us, now is the time for us to get behind this. … We understand that the new rule is mobile first.”

    Progressive enhancement

    One of the big conceptual advancements in web development in the last seven years has been a move away from “graceful degradation” towards progressive enhancement. Coined by Steve Champeon (of hesketh mailing list fame), progressive enhancement describes a process of starting with the basics and then building up functionality for richer clients. That is, instead of designing for a rich client and taking away bits and pieces for simpler devices, we start with semantic HTML and the progressively add CSS, Javascript and other goodies which improve the content.

    Drupal has been very good in this regard. There is a strong emphasis on producing semantic HTML with no inline styles or Javascript. Inline images for presentation are avoided. Drupal pages rock when viewed with no stylesheet whatsoever. They are pretty pure. The ultimate expression of this is the Stark theme in Drupal 7 which shows the quality of the HTML produced by Drupal.

    However, there is a very strong bias towards designing for Desktop sites. Many recent developments in theming revolve around areas such as 960 grid designs. Further, the use of jQuery as a default Javascript library means that many modules and themes make use of it is presenting a page. This isn’t bad on its own but does present problems when it isn’t easy to turn off. In short, Drupal is in a good position as far as progressive enhancement is concerned but there are a few hurdles to jump.

    Inclusive Web Design For the Future with Progressive Enhancement [Champeon and Finck] The original presentation at SXSW 2003. Graceful degradation versus progressive enhancement [Christian Heilmann] Article from Opera with practical examples.

    Responsive Web Design

    Another meme which has emerged recently is that of Responsive Web Design. Ethan Marcotte wrote a short article for A List Apart coining the phrase which basically describes fluid layouts which work well on a variety of screen sizes. By using floated divs, which are relatively narrow, layouts can adapt to the screen size. The secret sauce here is the use of media queries to serve progressively enhanced CSS to clients with more screen real estate. The “mobile” site is the “default” site suitable for the most basic of clients and the “desktop” site is the enhancement.

    Fluid grids, flexible images, and media queries are the three technical ingredients for responsive web design, but it also requires a different way of thinking. Rather than quarantining our content into disparate, device-specific experiences, we can use media queries to progressively enhance our work within different viewing contexts.

    This approach is counter to the traditional way of theming in Drupal where the presumption is for the desktop site. Currently there aren’t any themes that I am aware of which take this approach. Anyone?. It possibly is an area for experimentation in the future. So while we won’t necessarily be able to immediately make use of the mechanics of the technique (media queries) the basic principle of using floated divs in areas such as Views is certainly one we can make good use of.

    Responsive Web Design [Ethan Marcotte] A Discusses fluid grids and media queries. Outlines a possible future where the default version of the site looks good in all browsers but can be progressively enhanced using extra stylesheets for bigger screens. Responsive Web Design Book [Ethan Marcotte] Learn how to think beyond the desktop and craft beautiful designs that anticipate and respond to your users’ needs. Media Queries “A media query consists of a media type and zero or more expressions that check for the conditions of particular media features. Among the media features that can be used in media queries are ‘width’, ‘height’, and ‘color’. By using media queries, presentations can be tailored to a specific range of output devices without changing the content itself. “ Responsive Web Layout – in anticipation of the Mobile Event [nodiac] One of the few mentions of responsive web design on GDO. Responsive web design – Drupal theming Slideshow which covers the details of media queries with some good advice on being practical within the confines of Drupal.

    Zen of mobile

    In the spirit of the Zen of Python here is my Zen of Mobile. Consider these things when sketching out a design for your mobile site. Import this :)

    • simple is better than complex,
    • fast is better than slow,
    • sparse is better than busy,
    • fewer options are better than more,
    • most important to least important,
    • every element must add,
    • every page to satisfy a single aim.

    Some more practical pointers after looking around at a few decent mobile sites:

    • banner to be frugal on vertical space,
    • search is crucial gateway to site,
    • main content first,
    • single “focus” image for the page is OK,
    • other ancialliary images are distracting,
    • lists are good,
    • primary nav is available but not necesarily at top of page,
    • collapsing divs are good to compress blocks to be readily consumed on single screen,
    • minimise clicks by displaying simple form on that page if user likely to want to take action,
    • minimise typing if possible,
    • homepage gateway to user paths with focus on single key task.
    Mobile Web Design Trends For 2009 Some good tips and screenshots from popular, well designed mobile sites. A Study of Trends in Mobile Design Stats on different approaches taken by various websites. http://www.w3.org/TR/mobile-bp/ [W3C] Best practices to follow when designing for mobile devices.

    Location aware

    Mobile devices have extra capabilities over traditional desktop environment making them more immediate and powerful. The Mobile First section mentioned that mobile devices are superior to normal desktop devices and that apps should take advantage of this. The most obvious is the ability to be location aware. The massive dollop of cream that can go on top of the mobile cake is knowing where your users are. This then enables you to pre-empt many of the tasks the user might wish to carry out at that point in time: where is the nearest store, best deals in the area, directions, etc. from a functional perspective we can better guess what they want to do.

    Modern mobile clients offer APIs which allow developers to ask the user for access to their location. If the user agrees this data can be used to customise their experience. This may mean running custom queries on the DB using lon/lat or querying other APIs such as Google Places or other geo services. Want to carve out a niche for yourself? This could be just the area. I’ll leave that for another article :)

    Supported OS Platforms & Widget Frameworks Outlines the various platforms and the plugins/frameworks/apis to access geo location info from the client.

    Preparation

    As you will be testing the site initially in your web browser it is a good idea to set it up so as to resemble a mobile browser. If you are using Firefox to test the site there are a couple of add ons, both developed by Chris Pederick, which make your life easier.

    User Agent Switcher Allows you to switch your user agent across to iPhone or any other agent you care to define. This is great for testing that your redirect rules are working. Web Developer Tools Has a “resize” feature where you can define widths for 240, 320 and 480 to see what the page looks like on narrow screens.

    Finally, have a couple of target devices around so that you can give the designs a final once over in the wild.

    Be Sociable, Share!

    About Drupal Sun

    Drupal Sun is an Evolving Web project. It allows you to:

    • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
    • Facet based on tags, author, or feed
    • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
    • View the entire article text inline, or in the context of the site where it was created

    See the blog post at Evolving Web

    Evolving Web