Optimizing HTML email for mobile using progressive disclosure

For the most up-to-date techniques, please view our Guide to Responsive Email Design.

I know you folks are probably well over me talking about Jakob Nielsen (I agree, his site causes most designers to go into meltdown), however his latest Alertbox article gave us a bit of inspiration for yet another mobile optimization for email. This time it involves the use of a mobile stylesheet to display content only when the email recipient prompts for it. This allows the email to be quickly navigated without scrolling the length of the message… Plus it’s pretty darn novel to use, too.

Short emails rule on mobile devices

If you regularly use a mobile device to read email, you’ll know that short messages are far easier to digest than multi-page essays. Mr Nielsen has also recognized the inherit difficulty in navigating long messages, stating:

“We’ve known for 14 years that it’s best to be concise when writing for the Web. Mobile simply reinforces this point and stretches it to the limit. Short is too long for mobile. Ultra-short rules the day.

On the web, many responsive sites convert luxurious long-form into ultra-short for mobile devices by using a technique that Jakob Nielsen refers to as ‘progressive disclosure’. This involves hiding content behind an interactive element like a button or link, then displaying it on-click (or tap). Wikipedia uses it, as do a lot of mobile applications. So… Why not use it in mobile email?

Using CSS to show and hide email content

Lets say we have an email newsletter with multiple articles. In desktop email clients, we want a heading and text to display in each article:

Email in Apple Mail

However on mobile clients, we we only want the heading to display, alongside a show/hide button (which toggles the text). This turns the email into an interactive table of contents, dramatically shortening the message length:

Email on the iPhone

To do this, we’ll firstly need to turn to our HTML code and create an article with a heading, text and a show/hide button. We’ll also add a couple of classes to display the show/hide buttons exclusively on mobile devices. Here’s a simplified version of the code used for each of the articles:

<td>
   <
h4><a href="http://yourdomain.com" class="link">First heading</a></strong></h4>
   <
a href="#" class="mobilehide">Hide</a> <a href="#" class="mobileshow">Show</a>
   <
div class="article">
      <
class="bodytext">
         <
img src="kitten.jpg" style="float: left;" >Pellentesque habitant morbi...
      </
p>
      <
a href="http://yourdomain.com">Read more...</a
   </
div>
</
td

Take note the classes mobilehide, mobileshow and article - these will be handling most of the action.

That’s it for the HTML, so on to the CSS stylesheet found in the head section of our code. First up, we’ll hide the show/hide button when the email displays in desktop and web email clients, by using display: none !important; in our stylesheet:

a.mobileshow, .mobilehide { displaynone !importantcolor#fff; } 

As hackish as it is, we’ve also had to ‘white out’ the button for the benefit of Gmail and Android Gmail, which don’t support display: none; or negative margins. Thankfully, the button links are non-responsive in these clients.

On to the mobile stylesheet, which ensures that the show/hide buttons are only displayed on mobile devices. Included is some nice, webkit-friendly button styling for good measure:

@media only screen and (max-device-width480px{
   
...
    
a[class="mobileshow"]a[class="mobilehide"] {
      display
block !important;
      
color#fff !important;
      
background-color#aaa;
      
border-radius20px;
      
padding0 8px;
      
text-decorationnone;
      
font-weightbold;
      
font-family"Helvetica Neue"Helveticasans-serif;
      
font-size11px;
      
positionabsolute;
      
top25px;
      
right10px;
      
text-aligncenter;
      
width40px;
   
}
   div[class
="article"] {
      display
none;
   
}
   a
.mobileshow:hover {
      visibility
hidden;
   
}
   
.mobileshow:hover + .article {
      display
inline !important;
   
}
   
...

iPhone - show/hide button And if things go well, the result is an email with show/hide buttons that toggle content on the iPhone (pictured).

However, we didn’t get away with it so easily. As newer Blackberry handsets (the ones that support HTML email by default) don’t support the :hover selector, we added an additional mobile stylesheet following the one above, that forces the text sans show/hide button to display in our otherwise mobile-optimized layout. This is done by targeting the exact resolutions of Blackberry displays. We figured adding three device-specific resolutions was enough of a concession, but you can add more to taste:

@media screen and (device-width480px) and (device-height360px), screen and (device-width360px) and (device-height480px), screen and (device-width320px) and (device-height240px{
   
.article {
      display
inline !important;
   
}
   a
.mobileshowa.mobilehide {
      display
none !important;
   
}

So there you have it. We found that this technique works a charm in iPhone Mail and the Android default email client. In mobile clients that don’t play so nice with CSS and mobile stylesheets (Blackberry, Android Gmail and Windows Mobile 7), the text displays, however the show/hide button conveniently does not. If you would like to provide specific styles for Windows Mobile 7, then Jeremy Keith’s technique is certainly worth a shot.

Download the code example

If you would like to try applying this technique to your own email campaigns, feel free to grab the code from GitHub and adapt it for your own campaigns:

View this project on GitHub

A huge thanks to Jakob Nielsen for the advice and Jesse, for bringing this example to life. If you can suggest any improvements to this technique, we’d be delighted to hear them - who knows, progressive disclosure may just be the next big thing in mobile email design!

Posted by Ros Hodgekiss

20 Comments

  • Elliot Ross
    5th August

    Love it! (and a bit jealous we didn’t think of that!)

    This could work really well to help prioritise the message for mobile users, but not drop it out entirely incase the user needs it. Going to have a play with it now :)

  • Ros Hodgekiss
    5th August

    Great to hear from you, Elliot! Would love to know how you go. It’s early days for this technique, so if you come up with any improvements, we’d be pleased to hear them.

  • James
    5th August

    Can I ask why you went with a[class=“mobilehide”] instead of simple .mobilehide?

  • Stig Morten Myre
    5th August

    Hey James, that’s actually a trick used to prevent Yahoo! Mail from applying the mobile styles to the email.

  • James
    5th August

    Ahhh.. that makes sense! :)

  • Anna Yeaman
    5th August

    That’s so cool cheers Ros and Jesse! Just downloaded your template and going to have a play today. Would be interesting to do a/b on hiding content vs. extra scrolling. Just last week I was looking at redsquareagency.com/mobile and loving how you can hit an arrow to display further content, great to know we can do something similar.

  • adam
    5th August

    I’m somewhat new to mobile stylesheets—but am wondering: would stripping out the media declaration allow this to work in a non-mobile email?  My simple test says no (without user holding down mouse on “show” button to simulate a :hover).  Is there a way to do this otherwise without Javascript?

  • Ros Hodgekiss
    5th August

    Hi adam, you could strip out the media query and use it in non-mobile emails, however it would certainly require a few tweaks, like:

    - using the :active (or :visited?) pseudo-class instead of :hover to trigger the toggle action. We’ve admittedly used a bit of a hack here, as :hover isn’t really meant to work in this manner on mobile devices.
    - A lot of testing. Outlook, Hotmail, Gmail and others don’t support :active or :hover, so chances are that this technique won’t work consistently across desktop, mobile and webmail clients. If you can get it to degrade gracefully, it could be worthwhile, though!

    Naturally, we’d be super-keen to see if this can be adapted for non-mobile clients, so if you do try any further testing, keep us posted on the results.

  • David Owens
    5th August

    Wow… this type of email would be auto deleted or ignored on my phone. I don’t want to have to press buttons to read my email. This slows the process down way too much for quickly getting through your mail.

  • Jesse Dodds
    5th August

    @David Owens: It’s certainly not something you’d implement for every portion of your email, but it does allow for useful implementation of hierarchy. For example, with a listing of articles, I would keep the top three main articles shown, and any others could just be listed with the titles and show/hide toggles.

    I for one find it both irritating and distracting when clicking a link, only to be shipped off to a new browser window on my iPhone. I’m definitely less likely to toggle back and forth between the two applications to continue reading. This allows us to give people a gist, and the opportunity to read more without that disconnect of application switching.

    As always, the key is using something like this in moderation :)

  • Brian Sisolak
    5th August

    I recently discovered that in the new Yahoo! Mail in IE7 & 8, <style> tags are getting stripped out when they are in <head> tags. The only solution I’ve found so far is to move the <style> to inside the <body>. Michelle over at EmailOnAcid took a deeper dive into the problem and has more details at http://www.emailonacid.com/blog/details/C13/yahoo_mail_does_not_support_the_style_block_in_internet_explorer_7_8

  • John Faulds
    6th August

    Is there any reason you’re setting .article to display: inline !important instead of display: block as divs are block by default?

  • Jennifer
    6th August

    I downloaded the file and sent test messages to my Outlook and Gmail. It broke on everything except for desktop Outlook and iPhone Outlook Exchange and iPhone Gmail. Anything we can do to make the show/hide links not show up on all devices if it doesn’t work?

  • Ros Hodgekiss
    8th August

    @Brian - Yes, or you can move your styles inline, prior to sending your email campaign. Either do this by selecting ‘move CSS inline’ when importing into Campaign Monitor, or by using an app like Premailer.

    @John - Good question, come to think of it either will most probably work in this example, seeing as we’re not trying to get .article to flow around anything else.

    @Jennifer - As per my response to Brian, did you move the CSS styles inline prior to send? Assuming the code hasn’t been altered, the results should be similar to this design & spam test. Apple Mail is a bit wonk in this example, but testing IRL is fine. Let me know if you have any questions about this :)

  • Jennifer
    9th August

    Ros, thanks for your response! But I do have some questions. I used the Premailer app you linked Brian to, then copy and pasted the HTML into a test and sent it out. It looks the same on desktop as it does on mobile. Does the Premailer strip out the @media queries? If so, do I need to put those back in after I use the Premailer app? Thank you in advance!!

  • Ros Hodgekiss
    9th August

    Hi Jennifer, I just tested a mobile-optimized email in Premailer and indeed, it does strip out @media queries. So yes, you will have to paste them back into the head of the HTML code in prior to send. Alternately, you can use Campaign Monitor and we’ll automatically handle media queries for you *cheeky nudge* ;)

  • Matt
    10th August

    I’m attempting to implement this concept but am running into an issue with links within the show/hide div - specifically the readmore link.  It seems links do not work, they simply cause the .article div to hide again when you try to click them.  For example, using your template, if you change href from #link to an actual link, http://www.google.com for example, and try to click/tap the read more link, it simply hides the div and does not take you to the referenced url.  Am I missing something or doing something wrong?  Help would be greatly appreciated!

  • Pete Austin @MarketingXD
    11th August

    Clever technically. But I would be amazed if it worked except as a gimmick. The main effect seems to be to take space that could have been used for a marketing message and use it for buttons instead.

    I much prefer a short-form email, with concise marketing content, cross-linked to one Web page with a more verbose version of all the content. This requires one extra click total, not one per item.

  • Rhys Harry
    26th August

    On the face of it looks very neat but I think I share the same reservations as other comments, does it actually improve the email or hinder reading it?

    Great for A/B testing click through rates though.

  • BlackBerry Mobile
    24th September

    I think such application will work better on the BlackBerry mobile phones.

Sign up for free.
Then send campaigns for as little as $9/month

Create an account