technology

Style your site for mobile with Drupal 5 and CSS

The following article documents how I went about creating a mobile version of the Art Institute of Chicago’s Collections website in Drupal 5 using CSS and Javascript. I presented this work at the March 2012 Chicago Drupal Meetup Group. Here are my slides from the presentation:


At the Art Institute of Chicago, our museum website is run as two separate pieces. Collections—information on ~50,000 of the 150,000 artworks in our galleries and archives—runs on Drupal 5 and was initially developed by Palantir in 2008. Everything else runs on Serena Collage, a now-out-of-business CMS, and is currently being redesigned in Drupal 7 (*phew!*). I work mostly with our Drupal 5 Collections website.

More of our users are visiting our site on mobile devices. 7.75% of our visitors in February were on mobile devices, up from 3.25% the previous year. These aren’t staggering numbers today, but are inline with global trends. As mobile trends grow, we need to make the experience of these visitors more accessible. Viewing our current site on a mobile device is a little bewildering, with teeny-tiny text and links that you have to zoom in so far to use that they’re essentially unusable.

Our regular site is being redesigned with mobile in mind. With no immediate plans to upgrade our Collections site on the horizon, we needed to think about how we can work-with-what-we-have to satisfy our mobile users today. This led to us taking our current design and laying it out for mobile users—literally hiding content that’s less essential and making the rest bigger and more streamlined. We made an effort not to over-complicate our work so we could get a mobile site launched in a short amount of time (about 3 days of work).

Mobile design

The layout of the mobile site is simpler. We display all the pages in a single column to allow each feature to be as large as possible and provide a simpler flow of information. We silo the content to just our artwork objects. Links to other sections of our website and other related content are removed for now, and will be rethought about post-launch. With the small amount of screen real estate, we put content first. This means navigational items and related links go to the bottom of the page. This is not ideal, and there are definitely sexier ways to address navigation, but in the interest of a short turnaround, we’ll address that post-launch with a thoughtful approach to our users’ needs.

Technical strategy
In the same effort to not over-complicate a new version of our site, we offer the mobile site using the same URLs as our desktop site (www.*, not m.*). All server-generated code for both sites are exactly the same, and we use CSS and JavaScript to change the look of pages depending on the size of your device. There are a number of pros and cons to this approach.

Pros:

  • Since the server-generated code is the same for both pages, we still take advantage of our page caching, keeping with our efforts to keep PHP and MySQL load on our server low.
  • External links to our content (via blogs, social media, etc.) always display relevantly to your device. If someone tweets an artwork and you view the link from your desktop or phone, you always see the most usable layout without us worrying about forwarding users to different subdomains or checking headers on each page load.
  • There is no additional work for our content creators and no change to our content management workflow.
  • Our implementation does not use dynamically generated CSS or Javascript, so we can still take advantage of script aggregation.

Cons:

  • Mobile HTML includes a lot of content that’s not displayed, causing users to download more than they see. This will make our simple pages load slower on mobile devices than necessary.
  • Since we’re not changing the HTML markup, we can’t be super creative with our mobile layout. For our immediate needs, this is fine for us. But if we ever want to get a little fancier with our mobile site, this will not be the most flexible implementation.

Because the mobile world is changing quickly, we release small, quick iterations of our mobile site with the intention of evolving it as we go. With feedback from users we’ll be able to target development work in thoughtful chunks as we move forward.

We also allow users to switch between the desktop and mobile site, so they can still get to content that has been omitted from the mobile site. We follow the assumption that mobile users will want to get to data anyway they can, and will even deal with a desktop site on a small screen if they really want to get a piece of information.

Now let’s take a look at how I implemented our mobile site.

Layout
We primarily use body classes to swap the page layout between mobile and desktop:

<body class="mobile">

All the mobile CSS will be dependant on this body class. This gives us a mechanism to specify a layout that’s not dependent on your viewing device, so we can view the desktop site on mobile and vice versa. There are a number of ways to add body classes in Drupal 5, we create a $vars[‘body_classes’] variable in our theme’s phptemplate_preprocess_page() function that’s a string of all the body classes that should be used, then output those classes in our page.tpl.php.

On each page, we include an addition CSS for the new layout by calling drupal_add_css() in our theme’s phptemplate_preprocess_page() function. This CSS file starts with a wrapper for all its declarations:

@media screen and (max-device-width: 540px) {

This media query limits the CSS in this file to devices whose maximum width is 540 pixels. Device widths are far from standard, so we choose 540 to include iPhone-sized devices (480px) and some larger Android devices. If we want the option to view the mobile site on a desktop, which might be helpful for users with vision impairments, we can leave this wrapper out.

Each CSS declaration uses the body class defined in the HTML markup:

body.mobile * 
{
  float: none;
}

body.mobile #navbar 
{
  display: none;
}

body.mobile .thumb 
{
  float: left;
  padding: 0;
  height: 100%;
  width: 23.33%;
}

This CSS file is where all the design of the mobile site happens. We don’t display elements we want to hide using display: none, and reformat elements to look bigger and cleaner on a smaller screen. Because we’re working with screens of varying widths, we don’t use pixels to size elements. Instead we use percentages, even if they seem absurdly precise, and ems.

So that’s one static CSS file that gets loaded on every page, and gets aggregated with our other CSS for performance sake. Our layout is complete, and it displays on devices with smaller screens.

Toggle between desktop and mobile
At the bottom of each page we include some markup for the user to toggle between the desktop and mobile site:

<p id="toggle-mobile-off">
 [ <a href="#" class="toggle-mobile">View Full Site</a> ]
</p>

<p id="toggle-mobile-on">
 [ <a href="#" class="toggle-mobile">View Mobile Site</a> ]
</p>

In our Drupal theme CSS, we hide these elements using both visibility and hidden. This prevents Javascript show() methods from being able to display these elements on desktop sites:

#toggle-mobile-on,
#toggle-mobile-off 
{
  visibility: hidden;
  display: none;
}

In our mobile.css, we change the visibility option to allow Javascript show() methods on our mobile site to actually work. This is the one declaration we don’t include the body.mobile prefix, because we want this to be the case soley based on device width:

#toggle-mobile-on,
#toggle-mobile-off 
{
  visibility: visible;
}

Now for the desktop site, Javascript cannot control whether the toggle options display, they are always hidden. For smaller devices, Javascript can control whether these options display.

On the initial page load with this CSS both toggle options are still hidden. How do we decide which one to show? Well, that depends on what we know about the user’s preference. By default we want to display the “View desktop site” link. But if a user has requested to view the desktop version of the site, we want all subsequent pages to pull up as the desktop version to make their experience consistent. So we’ll display the “View mobile site” link until the user requests otherwise. We’ll be using some standard jQuery, along with the jQuery cookie plugin.

First we pull the cookie that we set for the user preference:

var mobcookie = $.cookie('mobcookie');

By default, this cookie doesn’t exists and won’t for most users. But in case it does, we’ll check if it’s set to a preference for the desktop site. If it is, we remove the mobile body class and add a non-mobile placeholder, and display the ‘View mobile site’ link:

if (mobcookie == 'moboff') {
  $('body').removeClass("mobile");
  $('body').addClass("not-mobile");
  $('#toggle-mobile-on').show();
}

Otherwise, leave the defaults and show the ‘View desktop site’ link:

else {
  $('#toggle-mobile-off').show();
}

Now let’s add a listener for the toggle links. If either of them are clicked, we can run the same code and just toggle each element, since we’ve already set up a good baseline for whether each is shown. We call the preventDefault() method to stop the <a>link for being followed:

$(".toggle-mobile").click(function (e) {
  e.preventDefault();
  $('body').toggleClass("mobile");
  $('body').toggleClass("not-mobile");
  $('#toggle-mobile-on').toggle();
  $('#toggle-mobile-off').toggle();

Now we set the cookie. By setting it here, we’re only setting it if the user diverges from the default mobile site.

  if ($('body').is('.mobile')) {
    $.cookie('mobcookie', 'mobon', {path: '/aic/collections/'});
  } else {
    $.cookie('mobcookie', 'moboff', {path: '/aic/collections/'});
  }

And then scroll the user to the top of the page after they toggle.

  $('html, body').animate({ scrollTop: 0 }, 0);
});

Here’s what all that code looks like together:

$(document).ready(function() {
var mobcookie = $.cookie('mobcookie');
  if (mobcookie == 'moboff') {
    $('body').removeClass("mobile");
    $('body').addClass("not-mobile");
    $('#toggle-mobile-on').show();
  }
  else {
    $('#toggle-mobile-off').show();
  }

  $(".toggle-mobile").click(function (e) {
    e.preventDefault();
    $('body').toggleClass("mobile");
    $('body').toggleClass("not-mobile");
    $('#toggle-mobile-on').toggle();
    $('#toggle-mobile-off').toggle();
    if ($('body').is('.mobile')) {
        $.cookie('mobcookie', 'mobon', {path: '/aic/collections/'});
    } else {
      $.cookie('mobcookie', 'moboff', {path: '/aic/collections/'});
    }
    $('html, body').animate({ scrollTop: 0 }, 0);
  });
});

The functioning of the toggle between the two versions of the site happens in the browser using only CSS to display the pages differently. Though one of the cons to this method is that mobile devices are loading a lot more markup than they need to, a resulting benefit is that this swapping happens super-quick, since all the necessary elements are already loaded in the user’s browser.

That’s it! As developers, we’re constantly working to keep up with a set of tools that are constantly changing. With this work I’m taking a few small steps to make our users’ experience more usable, in a way that can be easily iterated over as we learn more about our users needs.

Protest the war. On Facebook

Beyond attending rallies and marches protesting the various wars and occupations that the US has been involved in or supported very heavily over our lifetimes (big *auuugh*), there's been a lot of ways technology has been used to give power to our voices, and organize that power in large numbers. Many groups have forms you can fill out with a pre-formatted, customizable letter that will be forwarded to your state or federal legislators, which they'll determine based on your street address. Other web sites have created on-line petitions, making it easier to collect lists of folks supporting a cause without having to go door-to-door. But this? Oh man, this steps it up to a whole other level:

It began with a drive for 20,000 signatures at Rethink Afghanistan’s website, but folks who added their signatures were also given instructions for participating in the Facebook (Facebook) protest.

Hundreds of people have posted the following message or something very close to it to the White House page:

“President Obama, I am one of more than 20,000 signers of this petition from Rethink Afghanistan: ‘In your State of the Union address on January 27, 2010, I want you to provide a concrete exit strategy for our troops in Afghanistan that begins no later than July 2011 and which completes a withdrawal of combat troops no later than July 1, 2012.’ Petition: http://bit.ly/7romlW“

Since a protest like this asks folks to post the comment on the White House's Facebook page, your organization doesn't even need it's own Facebook page to make something like this part of your campaigns!! But what really makes this genius is it makes voicing your dissent more public than a phone call or an e-mail. With those traditional forms of communicating with our legislators, it's one voice being heard by one person. But when you post a message on your legislator's Facebook page, anyone else who looks at the their page--more than likely other folks in your same constituency--could potentially see your comments. Taken more locally, if you (or your organization if you're organizing a campaign) posts messages on your State Rep or City Alderman's Facebook or Twitter pages, other constituents could potentially see your message and say to themselves "yea, that is messed up! wtf?!!"

Is this much more power than we as constituents in a governed body have ever really had before?

URL shortening

I never understood why people use TinyURL until I tried it. Say you want to e-mail a link to a buddy, and it's really, really long. Like http://maps.google.com/maps?hl=en&q=area+51&ie=UTF8&ll=37.243632,-115.811434&spn=0.002046,0.003782&t=k&z=18&iwloc=addr&om=1. You can go to TinyURL.com, copy and paste the long URL into the textbox, and it'll generate a URL that looks like this: http://tinyurl.com/266z5t. A lot shorter, and it points to the same place. Sweet!

A new website has popped up recently that does very much the same thing, but is a little easier to use, URLtea.com. If you go the site and create a shortened URL out of the URL above, it'll create a similarly short url: http://urltea.com/p4i. But with URLtea, you can add a question mark, followed by any text you want to the URL, to let users know a little better what the link is for. So if I wanted, I could send my buddy a link that looks like this: http://urltea.com/p4i?area-51, and it'll still come up. If you try to do this with TinyURL you'll get a 404 error for some reason. Also, they've created a fancy little bookmarklet that you can add to the bookmarks tab of your browser. Using that, if you're looking at a page you want to create a shortened URL for, you don't have to actually open up URLtea.com in a separate window or tab, and copy and paste your URL into the form. While you're looking at the page, just click on the bookmark in your bookmarks tab, and it'll be the same as submitting the URLtea form with your URL. It'll come back with a page with your shortened URL already on it.

But the thing I like most about URLtea, is you don't have to highlight the short URL and copy it to your clipboard. After you create the shortened url, it assumes you're going to be pasting the URL in some other application, and it copies the url to your clipboard for you! That's sweeeeeeet!

South Asian arts in Chicago, all over Myspace!

It all started with a friend Ramona, who created a Myspace page for Kriti. She spent a little time on it, and the next thing we know she's got 500 friends. Hello! For myspace junkie's out there, you might be like 'uh, yea, nikhil, where have you been?' but for a South Asian litereary conference that's only planning its second conference, that's a big deal! So after she had such success with her page, we created a page for Voices of Resistance, a South Asian political arts show happening the same weekend as Kriti. Then I'm like, 'damn, I should make a Myspace page for maahaul,' and another friend was like 'I should create a Myspace page for ThirdI' and Rasaka Theatre's already got a page. So damn, before you know it, South Asian arts in Chicago is all over Myspace!!! :P

VoIP phones

A friend of mine just got a VoIP phone, and my parents were looking into getting one for themselves a few months ago. The cost benefits of VoIP phones are pretty sweet. Because your phone call is basically taking the same path a request to view a web page would take, you can call anywhere in the world for really, really cheap. But security and privacy are still an issue with the new technology.

Although we'd like to assume most companies implement some form of security in how they transfer your phone calls over the internet, there's no standard for security on VoIP as of yet. So it's better to call your VoIP provider to get a sense of how conscious they are about security. Sadly, some of them might not know how you answer your questions, in which case it's better to not use your phone at all for calls where you'll be sharing private information.

"For now, however, users of VoIP products and services that do not fall under the Telecommunications Act will be required to make their own enquiries as to the privacy standards and practices of their VoIP service providers if they wish to be assured of the protection of their personal information and the confidentiality of their communications."
from iLaw based in Australia

"The good news is that VoIP threats are still a largely theoretical issue. So far, few enterprise VoIP networks have experienced anything close to a serious hacker attack. But complacency shouldn't lull enterprise VoIP adopters into a false sense of security."
from voipnews

Some conversations to avoid on your voip phone:

  • Any conversation with your banks, credit cards, or lenders
  • Any automated system that asks you to enter a pin
  • Phone calls you might make on behalf of your work from home

Green spot on the sun

In the past, I've mentioned to a few people the phenomenon of the sun showing a quick green spot as it's setting, due to waves of light bending in the earth's atmosphere. NASA's got an animated gif of a video someone in Italy took of the phenomenon, check it out.

I was in CT this weekend, and I'm still here working from a Starbucks right now cause they have wireless. How sweet is that? Using the laptop my work provided me, I'm able to connect to my Linux box at my office from just about anywhere and still work a full 8 hour day of coding, developing, and testing Java and database code, like I do every other day of the 40+ hour week (since I have a job that requires such, but that should be no surprise). Crazy!!!

Emacs mug

This... is awesome. I saw a buddy at work walking around with this mug, and it's awesome. Emacs is a text editor I use when working on code on Linux, and there are a ton of features it has to make work easier, and this mug is a dandy little reference to some of this features. I know, I'm a dork, but this mug is awesome.

I heard a few tracks off Ghostface Killah's new album today, and it sounds HOT. I do still buy cds, so I might just pick that one up.

Technology and community organizing

Dotorganize just released a report they did after interviewing 400 social change groups on how they're currently using technology, what challenges they face, but more importantly, what they could be doing better. One part of the report I found especially exciting:

"Organizers do not request any sort of universal 'killer app' or mention one runaway toolset. And no two organizations express exactly the same need. We are witnessing a sector that is far too nimble and specialized for a 'one-size fits all' solution, or for a 'one-stop shop.' Social change organizers needs are too varied to render any single tool suite a viable sector-wide solution. As one organizer put it, 'We have no way of combining all of our needs into one package. [We need] customizable integration — at an affordable price!'"

How many organizations out there have their 'prospective funders database' in Microsoft Excel? Or have tried to implement an open-source solution that was either way more than you guys needed, or not enough, and either way, virtually impossible to customize? To me, it seems that both scenarios result in a lack of current development in technology for the non-profit sectors happening without the above stated in mind.

One thing that I've noticed about a lot of open-source technology is that they do try to be everything for everyone, the "next Microsoft Word." from the end-users' perspective, if you try to implement one solution with the intention of tweaking it for your own needs, it's a massive pain to do... so inevitably, we all end up building brand new, custom applications that have 75% already been done before. After more recently working with Hibernate at work and even TextPattern on my own sites, it's been refreshing to see "all-encompassing" software that actually does do most of what I want it to. But in the case of Hibernate, it's a more general framework to accomplish one part of a much bigger project at work. TextPattern is a piece of software that targets a more specific need (content management), and is built flexible enough to handle pretty much anything I'd need to do on a simple website. But it's not very ready to be coupled with other technologies that would manager other more complex types of content (e-commerce, workflow management). Developing with open hooks into critical pieces of the system is more of the next level this report is talking about.

I went to volunteer with SAPAC last night for voter registration up in the Devon neighborhood. Me and the main coordinator of the project went to an elementary school that was having a parent teacher conference to ask parents if they were registered to vote, and register them on the spot if they were up for it. It was pretty fun, it's hard to get people past the initial idea that's I'm about to impose a sales pitch on them, although much less-so than it would have been like if I rang the doorbell to their house. But once I got past that initial discomfort, it was interesting to see how people responded. Some people didn't speak English, and one woman's daughter told me outright that she was undocumented. Many others were still waiting on citizenship, and of those who were able to register, some who new they needed to were ready to just go ahead and sign up, and others seemed still confused on what the point of it all was. One South Asian or Middle Eastern woman asked me "why should I vote, what difference does it really make?" I told her if she didn't vote, then she definitely wouldn't make a difference. After thinking about it for a second, she did sign up. But there was definitely a good mix of attitudes towards the whole political process...

Pics are back on-line

Ever since I redesigned my site, my pics section has been down. Rather than putting the pictures up using the same system I was using before—where I had to manually resize, name, and upload images—I wanted to take advantage of some open source software out there to make that section easier to work with. I went with photostack, whose major feature among many that sold me was that I could zip pictures up into one file, and upload them through a web interface as a new album. It'll create the thumbnails and everything required for the SWEEEEEET interface from there, which also uses Lightbox JS, which is freakin awesome. I love technology. Now I just have to get a camera that works so I can start taking pictures again. It's on.

Going to a farm

Tomorrow night? I'm going to a FARM! Lol, hell yea. Every fall, my friend Kelly invites a handful of her friends to the farm where she grew up, in Walnut, IL (yes, there is a city in Illinois named after a type of nut). I missed Kelly's farm party last year, but I was totally there in '03 and '04. Should be some fun times.

I was watching the US Open last weekend at my girl's place in Connecticut with my parents. (Did you get that? At my girlfriend's house in Cconnecticut with my parents?) and they implemented a new technology to allow players to challenge line-judge calls on whether a ball was in or out. Here's how the USTA summed up the technology in a 'new enhancements' press release sent out a week or two before the US Open:

"*'Instant Replay' Electronic Line Calling*: The most highly anticipated innovation at this year’s US Open—instant replay technology with player challenges—will be available in Arthur Ashe Stadium and Louis Armstrong Stadium. This breakthrough for the sport has been developed to improve officiating while increasing the interest and excitement for in-stadium fans and television viewers."

An article about the technology on C|net credits a British company hawkeye, but I wasn't able to get a huge amount of detail on how the technology was implemented. It seems that Hawkeye had their own cameras set up in places throughout the stadium, and based on what the cameras see they can estimate up to a 2-3mm accuracy where the ball probably hit the ground. When talking about minute details in estimating an accuracy of 2mm, what sort of assumptions are they making when calculating where the ball hit? While watching a match, when they use the instant-replay technology, it's a computer generated graphic of where the ball hit, not an actual photo of the ball hitting the ground. The mark of the ball is an oblong circle, proly to accommodate for the ball stretching when travelling at a high speed, but is the stretched circle a standard mark? Or do they use different amounts of stretching a regular circle based on how fast the ball was actually going? I wonder how many cameras they actually have set up in the stadium, and where they are, and what exactly they're looking at. That would be a sweet tour to take!

Syndicate content