The Livetyping Blog

  • Size DOES Matter: How Responsive Designs Often Get It Wrong (and How to Fix It)

    Responsive web design is awesome. Just look at how it has swept the web design world in the last couple of years. But it is not a panacea. We can't just build a site responsively and leave it at that, without using our brains a bit. (Meaning that we need to get into the mobile first mindset.)

    One example of this is when a page looks great on the desktop, but on a small screen, it turns into an interminably long strip of content. Just want to get to the footer to find a link to the support page? Good luck.

    I appreciate that many sites use a CMS, and that any technique that requires additional markup to accomplish its goal may well require changes to the CMS and the workflow of the content authors and editors. However, even in such cases, it may be useful to consider these approaches just for specific pages (such as the homepage).

    Let's take a look at a few different ways to get around the overly-long-content problem.

    Just put less stuff on the page.

    Do you really need all that content on one page? In the spirit of mobile first, maybe splitting it up into multiple pages would work better for both small and large screens. Filament Group's homepage is a nice example of how not to overload your homepage with too much crap:

    Filament Group's uncluttered homepage
    Filament Group's homepage

    Just hide stuff

    Some content may just be luxuries that you can't afford on small screens. One solution is to simply not show it at all on smaller screens.

    The responsive version of the BBC News site uses this approach. The ads that appear on large screens are not shown on small screens. Also, the "Watch" section shows three items on large screens and just two on mobile:

    The BBC News "Watch" section on a large screen The same section on a small screen
    The "Watch" section of BBC News on large and small screens

    And on big screens, there is a "Most watched/read" section that isn't shown at all on small screens:

    The BBC News Most Watched/Read section
    The BBC News Most Watched/Read section—gone on small screens

    Accordion

    Instead of showing all the content, show a heading and a control to expand it. Most sites that do this just do it for some of the content on the page.

    coolblue.nl's store selector on desktop The same selector on mobile
    The store selector on Dutch ecommerce site Coolblue on big and small screens

    Wikipedia's mobile site takes a similar approach:

    Wikipedia accordion closed Wikipedia accordion open
    Wikipedia's mobile accordion

    Teasers

    On small screens, show the start of a piece of content, then show a link to the full content. This could either take you to a new page containing the full content, or expand (or load) the content in-place. (Having a separate page has a downside—content is duplicated, which means having to maintain two copies of the content, or using some kind of include mechanism.)

    The App Store on iOS is a good example of the latter approach—by default, you get a short version of the content, with an ellipsis and a "more" link. Tapping on the link shows the full content.

    A truncated app description from Apple's iOS App Store The full version of the same app description
    Truncated and full versions of the description of an app in Apple's iOS App Store

    The App Store simply truncates the content to a fixed length. A variation would be to have a hand-crafted teaser. This could be a tl;dr version of the content, or a hand-picked extract. (For sites using a CMS, this could be tricky though.)

    Amazon does something similar with product descriptions on its mobile site:

    A product description on Amazon's mobile site The same description, expanded
    Teaser and full versions of a product description on Amazon's mobile site

    The How

    If you're using Foundation or Bootstrap, you can show and hide elements depending on screen size by simply adding classes. If you're not using a front-end framework, you can add some media queries to your CSS to achieve the same results.

    You can use this technique for straight showing and hiding, for replacing regular content with a teaser, and for replacing content with the same content contained within an accordion.

    The Specifics

    Hiding stuff

    Bootstrap has what it calls responsive utilities that let you show and hide elements depending on viewport width. Just apply the appropriate classes. Foundation has its visibility classes that work in much the same way.

    In addition to showing and hiding stuff based on screen size, Foundation also lets you show and hide based on device orientation and whether the device is determined to be touch-enabled or not. (Modernizr does the detection here. It tells you whether the browser supports touch events, which is not necessarily the same as knowing whether you are dealing with a touch-enabled device.)

    This is handy—you can use touch as a proxy for other device capabilities, such as the ability to upload files other than images (so you can hide those file upload controls where you know they'll be inappropriate).

    If you're not using a framework, you can roll this behavior yourself using media queries. For example, you can add a hide-on-small class to the elements you want to hide on small screens, and add a media query rule like this to hide them:

    @media (max-width: 640px) {
        .hide-on-small {
            display: none;
        }
    }
    

    If you have elements that you only want to display on small screens, you'll need a second class (say, show-on-small) and a second media query rule:

    @media (min-width: 641px) {
        .show-on-small {
            display: none;
        }
    }
    

    Teasers

    To implement teasers, you need three things:

    • A short version of the content (which will be displayed for all screen sizes)
    • The remaining content (which will be displayed by default on larger screens, and hidden on smaller screens)
    • Something that users can click or tap on to to show or hide the extra content

    Put all the content in your page, with the appropriate visibility classes (see above) so that the additional content is hidden on small screens, but not on larger screens. At the end of the short content, add the link for showing/hiding.

    Then add a little bit of JavaScript so that when the user taps the link, the additional content gets shown.

    Here's a simple example. Check out the source code on GitHub here.

    (My version has "Show more" and "Show less" links, with JavaScript to show and hide the right one.)

    Note that if your shortened content is a specially-crafted summary, rather than just the first part of the larger piece of content, you'll need to toggle between it and the whole of the larger content, instead of just showing and hiding the remaining content, as I've done here.

    Accordion

    Animation showing accordion on small screens only
    Regular content on larger screens, an accordion on smaller screens

    If you want to replace your regular content with an accordion on small screens, you need to duplicate the content. You'll have your regular content, and the same content within the accordion.

    Foundation includes an accordion, as does Bootstrap. If you don't like these (or if you're not using a framework), you can use jQuery's accordion. (Note that you will need to include both the jQuery and jQuery UI libraries in this case.)

    Again, you can just use the visibility classes to hide the regular content and show the accordion on small screens, and vice-versa on larger screens.

    If you're uncomfortable with the idea of having to duplicate your content, fear not! There are things you can do to avoid it. Foundation has a component called Interchange that is intended to be used to insert different content (from external files) depending on the screen size. But you can also use it to insert the same content more than once on the same page.

    Another way to do this is to use a templating language. These let you pull pieces of content into your page from separate files. They are usually used to do things like adding the same footer to all the pages in a site. But they're good for this sort of thing too. Some of them are a bit complicated and have quite a learning curve. But for simple stuff, check out Brace Tags—it's very easy to use.

    (Note that templating usually means you have to run a script at the command line to actually put all the pieces together. There are ways to automate this, though.)

    My example uses the Foundation accordion. It also uses Interchange to avoid the content duplication issue. By default, the Foundation accordion isn't animated, but you can make it animated with not much effort, like this. Both of these examples are on GitHub here. (For more information, see this page.)

    Conclusion

    If you design or build responsive sites, apps, or prototypes, you will probably run into the too-much-content problem at some point. I hope that the techniques suggested here will help you overcome it.

    If I've missed other ways of handling this (or if you have any other feedback), I'd love to hear from you. I'm @martinpolley on Twitter.


    If you enjoyed this post, you should sign up for my newsletter to make sure you don't miss the next one. (You also get a free lesson from Livetyping, my HTML prototyping course for UX designers.):

    Sign up for the newsletter

  • A Thing for Showing Your Design on an iPhone without an iPhone

    So. I wanted a thing that would let me show people what my designs look like on an iPhone, but in the desktop browser. Especially HTML prototypes that only live on my machine. So I cobbled this together:


    (Open in a new tab.)

    Note: If you're viewing this on your phone, the above probably looks a bit rubbish. But it's not meant for use on a phone, so that's OK.

    I know it's not the same as viewing stuff on an actual device (or even on an emulator). But it's perfect for me.

    If you think it's useful, you can grab it off GitHub and use it too.

    (Thanks to 99designs for the transparent iPhone image.)

  • How to Steal

    "Good artists copy, great artists steal."

    So said Steve Jobs, attributing the words (incorrectly) to Picasso.

    It's my firmly-held belief that stealing is A Good Thing. I don't mean you should try to saunter out of your local supermarket with a bottle of expensive Scotch secreted in your trousers. Nor do I mean that I think it's OK to rip off the entire visual design of a site and use it on the one that you are designing.

    I mean that stealing a good idea and using it your own design is good for you and good for the idea. This is how good ideas spread. Take the archetypal example: pull down to refresh, first introduced in Tweetie by Loren Brichter. Twitter bought Tweetie and it became the official Twitter client for iOS. And the pull-to-refresh pattern has been copied by just about every feed-based app out there.

    Another example is the swipe-from-edge gesture that many apps (including Apple’s own Mobile Safari) use to let you go back to the previous page. This gesture (originally from Blackberry, I believe) has become so ubiquitous that it’s downright annoying to come across an app that doesn't use it.

    How ideas spread

    Of course, it's not just gestures. Every commonly-used control, widget, or pattern started off as an innovation that spread by copying. Others never really worked well enough to be copied, and died out. It's like Darwinian evolution. The fittest ideas live to reproduce (get copied), while the weaker ideas become extinct.

    So how do we find out about these new species? And how do we go about copying one once have discovered it?

    Finding good ideas

    One way is to expose yourself to new things as much as possible. Try out new apps and sites. Look at what people are doing on Dribbble. (It's mostly visual design stuff, but if you dig, you can find some interesting things, such as this.) Follow other designers on Pinterest and see what they are pinning. (Like this.) And when you come across something interesting, grab it and stick it somewhere. Bookmark it. Take a screenshot and put it in a dedicated Flickr album. Put it in Evernote or Dropbox. You could even Pin it.

    Another way is to regularly check out some of the many pattern libraries. See the new things that are being added. (There are quite a few libraries like this.)

    But then what? You're working on a design and you think “That new pattern that I saw on <wherever> would be perfect for this!” How do you actually go about incorporating it into your design?

    Using a good idea

    Well, it depends. If you’re at the sketching stage, it’s only limited by your sketching abilities. But if you're wireframing or making a prototype, it really depends on the tools or technology you’re using, and the platform you're designing for. If you're using OmniGraffle or Photoshop, you can probably make a visual representation of it, maybe in the form of a storyboard of some kind. But it's not ideal.

    If you're using something like Axure, you're going to have to try and find the widget or pattern in one of the existing libraries, or figure out how to make it yourself.

    If you're designing a mobile app, you'll probably want to get cozy with a developer who can put something together in code. (Though Facebook's Origami looks promising for this sort of thing.)

    But if you're designing something for the web, and making prototypes in HTML, then you're in luck. Especially if the thing you want to copy also lives on the web. That means that it's been done. It's technically feasible. And because web sites and apps work the way they do, you can pick them apart and see how they work.

    How, exactly? Read on, friend.

    The web makes stealing easy

    Every browser lets you view a web page's source. And these days, all browsers include tools that will let you dig into this source code and really figure out how it works. (Chrome has its Developer Tools. Safari has its Web Inspector. Firefox has its Web Developer Tools. And even Internet Explorer has its F12 Web Developer Tools.) There is also a large number of browser extensions that provide similar or additional functionality (such as Firebug for Firefox).

    So let's run through a quick example.

    Stealing: a practical example

    Mailchimp is a service that lets you send email newsletters. One thing that sticks out about it for me is its form controls. Instead of the standard browser controls (which look different on different operating systems), it uses custom elements. As well as looking nice and being big and easy to click, they look the same on PC, Macs, phones, whatever.

    So how do they do it? I opened up Mailchimp in Firefox (where I already have the Firebug extension installed). Their radio buttons look like this:

    Nice, eh?

    I right-clicked on one of the radio buttons and selected "Inspect with Firebug". The CSS for the <input> element didn't tell me much, but I noticed that when I hovered over the radio button, some extra classes were being added to the <div> that contains the <input>:

    (Firebug highlights things that have just changed in yellow.)

    This suggests that they're actually using this container element to make the radio buttons look and behave the way they do, rather than trying to do anything to the <input> element itself. And the classes that are being added all start with dijit. What the heck is Dijit?

    Well, it turns out that Dijit is the UI library for Dojo, a JavaScript framework (kind of like jQuery, which has the jQuery UI library). Poking around on the Dojo site, I found something called the Dijit Theme Tester. It has nice-looking radio buttons (that don't look like system radio buttons):

    But they don't look like the ones in Mailchimp… Looking in Firebug again, I can see that the <div> in question is getting a background-image applied to it:

    This image is what's called a sprite. It's a single image file that contains a number of separate images. Here, I can see that it contains images for all the different states of the radio button, as well as the same for checkboxes. Here's how it looks full-size:

    If I go back to Mailchimp, I can see that they use a different sprite:

    Here's what that looks like full-size:

    As you can see, this is how they make the same Dijit radio buttons look different (that is, better).

    Enjoying your ill-gotten gains

    So if you wanted to do something similar in your own prototype (or production site/app for that matter), you now know that you can use Dijit and make your own sprite image to customize the way it looks.

    But please, don't just steal the Mailchimp one. That would be wrong :). (Especially as Mailchimp are nice enough to explain how their forms are made over here.)


    If you're interested in HTML prototyping (because so many UX job postings are asking for front-end coding skills these days), you should check out Livetyping, my HTML prototyping course for UXers.

    And if you like stuff like this, you should sign up for my newsletter:

    Sign up and get a free sample lesson by email

  • Sharing Is Caring: the Best Ways to Share Your Prototypes

    Someone asked me the other day how he could view his HTML prototype on his phone. (It was only on his computer at that point.) He asked if using GitHub was a good approach. It is, but it's not the only one.

    There are two main reasons why you might want to be able to make your prototype viewable on a computer or device other than your own. First, if you want to check how your design looks and behaves on a different sized screen. (And much of the time browser wanking just doesn't cut it.) Second, if you want to show your design to someone else. This might be a colleague, a client, or a user in a usability test.

    These are two very different things, but they are two things I often find myself need to do, and some of the solutions apply to both scenarios, so I'm lumping them together for the purpose of this post.

    So, there are a bunch of different ways you can do this. Here goes!

    Emulators

    An emulator is an application that runs on your computer and pretends to be a particular device. There are emulators for both Android and iOS, but these are both aimed at developers, and are supplied as part of each platform's development kit.

    For just checking out prototypes, they are probably overkill. But there is a simpler alternative: the Opera Mobile Emulator.

    A prototype in the Opera Mobile emulator, simulating a Samsung Galaxy Note

    This lets you see what a prototype (or any site, for that matter) looks like in the Opera Mobile browser on a wide variety of smartphones and tablets. And it plays nicely with prototypes that are just a bunch of files on your computer—you can just paste the file path into the address box. It's not exactly the same as using a prototype on an actual device with that device's own browser, but it's pretty close.

    Adobe Edge Inspect (and similar tools)

    If you just want to be able to check out your design on your own phone or tablet, Adobe's Edge Inspect is a useful tool. It has three components: an application that runs on your computer, a browser extension for Chrome, and an app for your iOS or Android device.

    Once all three are up and running, you can connect from your device and see the same page that is open in Chrome, and if you interact with the page or reload it, it is updated on your device as well. It's handy, but I have experienced connection problems on occasion.

    Edge Inspect is currently free if you just want to connect one device (though you need a free Adobe Creative Cloud account). If you want to connect multiple devices, you need a $9.99/month subscription.

    The are several alternatives, such as Ghostlab (paid, Mac only) and Remote Preview (open source, cross-platform), that look like they're worth a look. (I've only used Edge Inspect, so I can't comment on whether these two are any good or not. If you've used them, let me know :)

    Dropbox

    If you copy a prototype into the Public folder of your Dropbox, you can then share the link with anyone (including yourself, so you can view the prototype on your phone).

    Note that opening it from the Dropbox app on your phone won't work. You need to paste or type the link in your browser.

    This is probably the easiest option on this list.

    Use an online code editor

    There are a number of online code editors available, such as JS Bin and Codepen. (JS Bin is my fave.) You can copy and paste your prototype's HTML, CSS, and JavaScript into one of these, then open it up on your phone or share the link with someone else.

    For example, it just took me about two minutes to paste the code from a simple prototype into JS Bin. (I also added Foundation from JS Bin, and deleted the bits that referenced my local Foundation files.)

    This is the result:

    A prototype in JS Bin

    Now I can open http://jsbin.com/kaqira/3 on my phone (or email it to someone, or whatever):

    The same prototype in JS Bin, viewed on my phone

    One advantage of this approach is that if you’re discussing the design with someone, you can make changes right then and there and see them reflected in the output.

    GitHub Pages

    GitHub's Pages feature lets you host static websites inside GitHub repositories. GitHub is free (unless you want to do things like have private repositories). All the prototypes I create are static—they don't rely on a server or a database. So this is quite a handy way to put your prototypes online so you can share them with others (or look at them on your phone).

    There's a bit of a learning curve, but this page does a pretty decent job of explaining what you need to do. Just select "Project site" on that page, and it will guide you through the process. I followed their instructions, then used the GitHub desktop app (Mac, Windows) to add my prototype's files and commit them to my repository.

    Here's what that same prototype looks like, hosted as a GitHub Page.

    Amazon S3

    Amazon's Simple Storage Service (S3) is typically used by web applications for storing files (for example, photos that users have uploaded). But you can also use it for hosting static sites. Which means you can upload your prototypes to it for viewing anywhere, by anyone.

    Now, this option is not free, but it is ridiculously cheap. To give you an idea, I host this website on S3, along with a few other things, and it never costs me more than a couple of dollars a month.

    Getting it set up is not exactly simple, but if you follow the instructions to the letter, you'll be fine. You do need a domain name, though. Otherwise, you won't have a URL through which to access your prototypes. You also need an Amazon account (but who doesn't already have one of those?).

    For me, setting up additional storage for prototypes in S3 was easy, as I already have the capcloud.com domain name. I just set up a new storage area (a "bucket", in S3 lingo), set up a subdomain called projects (through my domain name provider), and linked the two together. Here's that same prototype, yet again, on my S3-powered project site.

    To upload files, you can use S3's own upload page, which is pretty good, or if you're used to using FTP, you can use a service like Cloud Gates to upload with your favorite FTP client.

    Other options

    These aren't the only options open to you. Others include setting up a web server on your own computer. But this is a bit of a hassle, and making it so that people outside your local network can access it is a pain.

    Another is to pay for web hosting and (for example, here or here) and upload your prototypes to the web host (usually via FTP). But it's still a hassle and costs more than the most of the other options we've covered.

    Privacy

    All the options I've described (except for emulators and Edge Inspect) put your prototype in a place where anyone with the right URL can access it. This may not be desirable. Sure, you can give the URL only to the specific people you want to share it with, but there's nothing stopping them giving it to someone else, whether intentionally or not.

    If this is important to you, a couple of the options are going to be better bets for you.

    If you have a paid GitHub account, you can make repositories private. This lets you control who can access them. They do need to have a GitHub account though. The cheapest plan costs $7/month and lets you create up to five private repositories.

    If you pay for web hosting, your site's administration panel will usually let you make individual directories password-protected.

    And the winner is…

    The simplest and easiest option has got to be Dropbox. If you're already a user, you just copy your prototype into your Public folder and you're done. And even if you don't already have a Dropbox account, setting one up is easy and gives you 2GB of free storage.

    If you're already using one of the other services, like GitHub or S3, then you're already past the initial barrier to entry, so using it for hosting prototypes as well is an easy step to take.

    I hope you found this useful. If you know of any other ways of doing this that I've missed, ping me on Twitter: @martinpolley.


    If you're interested in HTML prototyping (because so many UX job postings are asking for front-end coding skills these days), you should check out Livetyping, my HTML prototyping course for UXers.

    And if you like stuff like this, you should sign up for my newsletter:

    Sign up and get a free sample lesson by email

Page 1 / 8 »