The Livetyping blog

Bootstrap: not the solution to every problem

2016-05-07T00:00:00+01:00

How to deal with the fiddly shit

Responsive frameworks are awesome. Whether it's Foundation (my favourite) or Bootstrap (most other people's favourite), they really do save you a lot of time, effort, and pullling-out-of-hair. Using one is real standing-on-the-shoulders-of-giants stuff.

But they're not perfect.

You will always run up against something that they just can't help you with. And then you're on your own. Just you, whatever HTML and CSS knowledge you have, and Google to fill in the gaps.

This post covers one such problem that I had to deal with recently, and shows you how to overcome it. (This isn't one of those "These three easy steps will solve all your Bootstrap woes" posts. There are lots of problems like this, each with its own solution. Or several possible solutions. If you're wrestling with a different problem, send me an email or a tweet and I'll try to help.)

The problem I was having (with Bootstrap, so I'll use that here too) was that there was content that was displayed in a modal dialog, but sometimes the content was too wide—a very long string with no spaces or other natural breaks, and by default, it just ran out of the edge of the modal. And it was generated content that I had no control over, so I couldn't just insert some spaces. Oh, and there was also a Bootstrap label at the beginning of the line of text that had to be handled correctly too.

It looked something like this:

(View on JS Bin.)

So I had to figure out how to make it wrap. This should be easy. There are a couple of different CSS properties that you can use to force text to wrap. word-break seemed to work best:

.modal-header
{
  word-break: break-all;
}

And it seemed to do the trick:

(View on JS Bin.)

But I don't really like the way the text on the second line starts under the label, instead of lining up nicely with the text on the first line. Surely it should be easy enough to fix that, right?

I mean, we should just be able to use Bootstrap's responsive grid. We can just nest another grid in there. And…

(View on JS Bin.)

Aughhh! No! That's not what I meant! Why is it like that?

Ah, I see, it's that close button. It's not even part of the row that we added, but because of the way it's being positioned (using a float), it's messing things up. Maybe if we try putting it in its own column?

(View on JS Bin.)

That's a lot better. But something still isn't right here. Look at the label. The text wasn't that small before, was it? (I'll save you the trouble of going back and checking—it wasn't.)

If we take a look at the label in Chrome dev tools, we can see its font size is 75%:

But 75% of what?

Well, before, it was 75% of whatever our heading 4's font size was. Now I suppose it must be 75% of the base font size, which is presumably less. So. What to do?

We could go and figure out the font size for h4 and apply that to this label. Or we could just wrap it in <h4> tags. (And we have to add the same class as our existing h4, otherwise it gets some margins added to it which makes it look crap.) How's that?

(View on JS Bin.)

One other annoying thing. There's a big gap between the label and the text. Maybe the two columns we gave it were too much. Would just one work?

Well, kind of. But it's touching the text. And on smaller screens it really doesn't work:

Also, if the label text is a bit longer, it will make the label wider, which will also screw things up. Which highlights the point that you need to know the actual content you're going to be displaying and set up your layout with that in mind.

In fact, on small screens it would probably make more sense to make the label stack above the text—it's a better use of space. So maybe we should use the small (col-sm-) or medium (col-md-) column classes instead of the extra-small (col-xs-) ones I used to make sure that happens:

(View on JS Bin.)

And now we have yet another problem. The "x" close button is now in the wrong place. (Like I said, fiddly shit.) So let's think, what can we do here? There are a couple of things that come to mind. One thing that Bootstrap lets you do is to change the order of the columns depending on the screen size. But I've always found this to be very unintuitive and hard to get my head round.

A more pragmatic approach might be to say, OK, on a small screen, that tiny "x" is next to useless, and anyway we've got a close button, so let's just hide the "x". Bootstrap's responsive utilities let you do this (by adding the hidden-xs class to the div containing the button):

(View on JS Bin.)

I'm pretty happy with the way this looks now. In the next post, I'll go through an even more fiddly and annoying problem. And if you're wrestling with something fiddly too, get in touch—maybe I'll be able to help.

If you found this useful, and you don't want to miss out on other posts like this, sign up for my newsletter.

The Easiest Way to Set Up a Static Prototype/Site

2016-04-30T00:00:00+01:00

Often, when you're building a prototype or a simple (maybe static) website, you'll find yourself making a bunch of static HTML pages that you link together. And most of the time, there are things that are the same on every single page. The header. The footer. An email signup form. Etc.

There are many different ways of avoiding the bother of having to copy and paste this common content between pages (not to mention what a pain it is to edit every single page whenever you need to change something).

When I was looking for a solution to this problem, I found that most of these ways are quite complicated. There are static site generators like Jekyll, Pelican, and Octopress. (And many, many others.) There are the templating languages, such as Handlebars, Mustache, and Jinja2. And there are powerful but complex frameworks like AngularJS that come with this of functionality built in.

I've looked at all of these at various times and for various reasons, and I was left gibbering – they were all complete overkill for what I was trying to do. Their learning curves just weren't worth it.

And then I found Brace Tags. All it does is pull pieces of content into HTML pages. That's it. Nothing more.

Let me show you.

Let's say you've got a web page that looks like this:

<html>
<head>
    <title>My homepage</title>
</head>
<body>
    <h1>Welcome to my homepage</h1>
    <p>Look at all this content!</p>
</body>
</html>

And you want to add a footer to this page (and to all your other pages). You create a folder called _partials in the same folder as your HTML files and create a file containing your footer markup in it. Call it, say, footer.html. Something like this:

<footer>
    <p>Copyright &copy; Martin Polley 2016</p>
</footer>

Then add one line to the first file to pull in the footer, so it looks like this:

<html>
<head>
    <title>My homepage</title>
</head>
<body>
    <h1>Welcome to my homepage</h1>
    <p>Look at all this content!</p>
    {% include _partials/footer.html %}
</body>
</html>

Then you run Brace Tags on it by typing tags build at the command line in the folder containing your files. It assembles the pages and puts them in a folder called _site. That's it. Dead simple, with a minimum of faffing about.

The thing is, it only runs on OS X or Linux. But I'm on Windows at the moment, so I've set up a virtual machine running Linux just so I can run Brace Tags. It's worth the hassle of setting up a VM to have access to such a simple, useful tool.

If you found this useful, and don't want to miss out on more like it, sign up for my (rather irregular) newsletter.

Which designers should do what?

2016-04-24T00:00:00+01:00

I really like this post from Louise Downe at the UK's Government Digital Service. It lays out very concisely the different type of designers they have, what each one does, and, most importantly, why they think that's the best way of doing things. Obviously, this is what works for them—YMMV…

This is the sort of thing that makes me proud to be British.

Start learning to code... and why maybe you shouldn't

2016-04-23T00:00:00+01:00

I've been known to go on about how designers should learn to code. As if it's a universal good. Always true for everyone.

But maybe that's not the case. Maybe it's more nuanced than that... Peter Merholz thinks so. And he's a pretty smart guy. Lots of experience in the field. In a recent blog post, he says that the whole "Should designers code?" argument "fetishizes tech over other crucial design skills."

His point being that we've been putting too much emphasis on designers being able to code, at the expense of other, no less important skills. IA. User research. Writing, IxD. Etc.

And he's right.

Being able to code and being kind of flaky in these other, core UX design skills doesn't make you a good designer. Maybe it doesn't make you a designer at all. But if you have basic competency in these core areas, then you can choose to focus on an area that interests you, and make that your thing. (After all, UX is such a broad field that no-one can be an expert at everything.)

Maybe that will be interaction design. Maybe it will be content strategy. Maybe IA. Maybe user research.

Or maybe coding.

Being able to code lets you create prototypes that work and feel like the real thing. And maybe they will become the real thing, which means you'll be able to see the design through to delivery, and make sure that what was designed is what actually gets built.

And if it is coding, then you could do worse than take a look at my Livetyping course.

Can You Prototype Native Apps in HTML?

2015-04-07T00:00:00+01:00

A thought has been bouncing around in my head for a while now: prototyping in HTML, CSS, and JavaScript is all well and good for web sites and webapps. But what about native apps (iOS and Android)? Can you prototype them in HTML?

Obviously, there are things that HTML prototypes (and webapps too for that matter) can't do that native apps can. The browser on your smartphone or tablet just doesn't have access to all the capabilities of the device and the OS that native APIs provide (e.g., location data, accelerometer, system notifications and so on).

Aside from this though, is there any reason why we can't do this? If you use a responsive framework, layout is a cinch. You can even change your page layout depending on device orientation. And we now have things like off-screen menus and independently-scrolling sections.

But one place where native apps really shine and provide opportunities to delight is in the sphere of animation. Most webapps don't attempt the fancy stuff that some native apps do.

So I decided to do a little experiment. I picked an animation from a native iOS that I figured I should be able to replicate without too much difficulty, and tried recreating it in HTML, CSS, and JavaScript. The animation I chose is the one that the Tumblr app uses when you tap the new post button.

When you tap the button, an overlay appears over the current content, and six buttons (one for each type of post) come flying up from below the screen and bounce into position. Immediately after this, a "Nevermind" button slides up at the bottom of the screen. If you tap one of the buttons, the six buttons fly up off the top of the screen and are replaced by a photo selector, text entry area, or whatever. If you tap "Nevermind", the buttons fly off and the overlay fades out so you're back where you started.

I decided to just replicate the "Nevermind" action. (I didn't bother getting every last little detail right—I used numbers instead of icons for the buttons, the buttons themselves are a bit small, etc.)

I used Foundation for layout and Julian Shapiro's excellent velocity.js for animation. The result looks like this (try clicking New):

(In some mobile browsers, this doesn't display correctly. So you might want to open it in a new tab.)

And here's a video showing the original Tumblr animation, my version in a desktop browser, and my version in Mobile Safari:

I think it's pretty convincing. There's a "but" coming though…

And this is it: but there are limitations. For example, the overlay that the Tumblr animation adds also blurs the content that it covers. This is easy enough to do in CSS, and you can animate the blur using velocity.js. It looks great in a desktop browser, but in Mobile Safari, it makes the animation a bit clunky.

And this is a fairly simple animation. Other, more complex animations that require more processing power will most likely perform more poorly in mobile browsers.

So is this a viable approach? It depends what you are trying to do.

If you want to show people your prototype on the desktop (maybe in something like my iPhone viewer (code), then it works great. If you want to actually show it working on a smartphone, then you may run into performance issues, depending on what you're trying to achieve. (If you have a newer phone than mine, it may work better.)

I'll definitely be experimenting more to see what works and what doesn't.

If you want to poke around in the code, it's on GitHub.

And if this pushes your buttons (sorry), you should check out my upcoming workshops, which will cover this and oh my goodness so much more. If you're a UX designer and you want to learn how to make stuff like this, give it a look.

The UX Designer's CSS3 Cheat Sheet

2015-03-26T00:00:00+00:00

A while back, I put together an HTML5 cheat sheet for UX designers, which seemed to go down rather well. But what's HTML without CSS? Not much. So now I've made another cheat sheet, this time for CSS.

Grab your copy here. I hope you like it! (If you do, I'd realy appreciate it you'd share it.)

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

2014-09-29T00:00:00+01:00

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 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 "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—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.

The store selector on Dutch ecommerce site Coolblue on big and small screens

Wikipedia's mobile site takes a similar approach:

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.

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:

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

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.):

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

2014-09-14T00:00:00+01:00

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

2014-07-28T00:00:00+01:00

"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:

Sharing Is Caring: the Best Ways to Share Your Prototypes

2014-07-23T00:00:00+01:00

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:

Wind of change: are we finally starting to agree on how UX should be done?

2014-07-21T00:00:00+01:00

I originally sent this out as a newsletter, but I think it deserves to be a blog post too.

A few weeks back, I sent out a newsletter about some of the great stuff Peter Merholz has been writing recently on the best ways to "do UX" in a organization. (Should UX be a separate function? Or should designers be embedded in product teams?)

In the last couple of days, I've seen a few more posts that address the same issues.

Dan Brown (of EightShapes) wrote a piece on Medium about the importance of design systems, and wondered why many organizations don't seem to have such systems in place. He asserts that the biggest barrier is designers' position in the organization. And then goes on on to say that the typical "service bureau" model, while effective, is ultimately limiting. That the whole organization needs to "get" design:

To have a design system is to have a pervasive language of design, one that everyone in the organization speaks natively.

This put me in mind of the fantastic stuff Leisa Reichelt has been writing recently about strategy. A lot of her writing comes from her experience working at the UK's Government Digital Service, the team tasked with the "digital transformation of government". No small task, but one that they seem to be doing incredibly well.

GDS has its own blog, where Ben Terrett recently wrote a post that echoed Leisa and Dan's points. Here are a couple of choice quotes:

We don’t have a UX Team.

... user experience is the responsibility of everyone in the team.

These things all seem to be pointing to one thing, despite the diversity of types of organizations they relate to: that UX is strategic, and it needs to be the concern of everyone in the organization.

Something else caught my eye in that GDS post:

We don’t make wireframes or photoshop mockups ... We’re making a Thing, not pictures of a Thing.

And, directly related to this:

All of the designers can code or are learning to code. ... it’s important to belong to a group with shared skills and experiences. This helps people develop their skills, support each other and build a strong culture with shared standards.

Which aligns with what I've been banging on about for ages: that UX designers should learn how to code, and by the way, here's my course that will teach you to do exactly that :)

Forms—The Complete Guide—Part 4: Selection-dependent Inputs

2014-06-19T00:00:00+01:00

In which we take a look at selection-dependent inputs, and see that they're a lot more simple to put together than they look.

Forms. They're often the bane of users' online lives. But it doesn't look like they're going away any time soon. So its up to us, UX designers, to make them as smooth and easy to use as possible for our users, while still reaching the best business outcomes.

If we prototype our forms, we can get them in front of users earlier and get feedback sooner, which we can use to iterate our designs. Previous posts in this series covered form layout and alignment, input types, and grouping and inline help.

In this, the fourth post in this series, we take a look at selection-dependent inputs. (I've also seen it referred to as "responsive enabling" and/or "responsive disclosure"). All this means is changing the fields that the user sees depending on some selection that they have made or some information that they have provided. For example, if we're asking the user for their postal address, we might have a field where they can enter (or select) the country that they live in. Then, depending on the country, we can change the other fields to match the standard address format for that country.

Note: "Responsive enabling" refers to having one or more fields that are disabled until the user makes a particular selection, in which case they become enabled, allowing the user to interact with them. "Responsive disclosure," on the other hand, hides the fields, and makes them appear if the user makes a particular selection. I don't recall seeing many forms that use responsive enabling of late, but I'm sure it's useful in some circumstances, so I'll include an example.

Responsive enabling

I think one of the reasons that this pattern has fallen out of favor in recent years is that it can be distracting. You have all these disabled fields, and they just take up space and draw the user's attention away from the stuff that matters unless they click on a particular checkbox (which may only be relevant for a small percentage of users).

One benefit is that things stay put. In you use responsive disclosure to make fields appear and disappear, the content below them suddenly jumps downward, which can be jarring and disorienting. But nowadays, it's easy to animate transitions like this, which can reduce the problem.

Anyway, in some cases, responsive enabling is going to be the right approach (where there aren't too many disabled fields, and where it would be confusing not to show them), so let's press on with an example.

In this example, we're going to let the user opt in to receiving text messages from us to let them know about special offers. You would typically find things like this at the bottom of an order form. We'll have a field where they can enter their mobile number, which will be disabled until they click the opt-in checkbox.

After you've set up a new Foundation project (this post explains how), add this HTML just after the opening <body> tag. (We're not going to waste time prototyping the whole form—we'll just prototype the bit we're interested in.)

Somewhere within the page's <head> tags, add this <style> block:

The result looks like this:

What I've done here is not very complicated. Like in the previous posts, I've used Foundation's grid to lay out the form. In the second line of the HTML, I'm just squishing the form down into eight of Foundation's available twelve columns, and adding a two-column offset to center it on the page.

The first bit of actual content is a paragraph to show where the actual form fields and labels would go if this was a real form.

Then we've got a row containing a column that takes up all twelve columns. (small-12 columns means it is twelve columns wide on small screen sizes and anything bigger, i.e., all screen sizes.) This contains the checkbox <input> (with id and name) and its label (which uses for to link it to the checkbox, so that you can click on it to toggle the checkbox too).

After that, there's another row that contains two columns, for the phone number <input> and its <label>. Notice how this divvies up the available space differently for small and medium (and bigger) screens.

For small screens, we've got a three/nine column split, so together they fill up all the available width. But on medium-and-up screens, they are three and six columns wide. This is to prevent the <input> from being ridiculously wide on larger screens—Foundation makes each input 100% of the width of the column that it's in. (By default, if the number of columns doesn't add up to twelve, Foundation scoots the last column over so it is right-aligned. I've added the end class to stop this happening.)

The label gets the right class to right-align it, and the align class to align it vertically with the <input>. It also gets an ID so we can style it and do stuff to it. And the <input> gets the appropriate type (tel) and the disabled property to make it disabled initially.

The CSS in the <style> block in <head> just applies some styling to the placeholder text that shows where the real form fields would go and makes the "Mobile number" label grey so it looks disabled. (You can add the disabled property to <input>s, but not to <label>s—you have to style these yourself so they'll look disabled.)

It looks OK so far. The phone number input is disabled, and its label looks disabled too. But it doesn't get enabled when you check the checkbox. For that, we need a bit of JavaScript. Not much, just a smidge.

At the bottom of the page, right before the closing </body> tag, add this <script> block:

This is pretty similar to what we saw in the last post. All the code is inside the jQuery $(document).ready() function. So it will only get run after the page has finished loading.

Within $(document).ready(), this part of the first line selects the checkbox:

$('#cb')

that is, the element with the ID of cb, then this part:

.on('change', function(){

calls the on() function to detect when its state changes. The three lines within the curly braces ({}) specify what happens when this change event is detected:

In the first line, this bit:
```
$('#mobilelabel')
```
selects the label for the phone number field, which has an ID of mobilelabel, then this bit:
```
.toggleClass('disabled')
```
calls toggleClass() on it. This adds the disabled class to the element if it doesn't already have it, and removes it if it does. This is the class that gives it the grey color, so removing it switches it back to its default color, black.
The second line declares a variable called checked. Then this part:
```
$('#cb')
```
selects the checkbox again and then checks whether it is checked or not like this:
```
.is(':checked')
```
This gives us an answer of true or false. The ! reverses this value. If it is true, this makes it false, and vice-versa. Then this value gets stored in our checked variable. I'll explain why we need to reverse the value in a minute.
The third line selects the phone number input, which has an ID of mobile, like this:
```
$('#mobile')
```
and calls prop() on it to set the value of its disabled property. And the value we give it is whatever we just stored in our checked variable. This way, if the checkbox is checked, checked gets a value of false, which we use to set disabled to false. (Actually, I used trial and error to know whether I needed to reverse the value or not! I like to think of this kind of thing as being pragmatic.)

In fact, disabled doesn't take a value—an element either has the property or it doesn't. But behind the scenes, jQuery correctly interprets us giving disabled a value of false and simply removes the property.

Now checking the checkbox enables the input, so it looks like this (and unchecking it disables it again):

You can see it in action here.

Responsive disclosure

For responsive disclosure, we're just going to take the previous example and change a couple of things. Here's the HTML:

The only changes that I've made here are to remove the disabled attribute from the phone number <input> and to remove the disabled class from its <label>. And I've added a new ID, mobile_container, to the row <div> that contains them so that I'll have something to attach behavior to.

The CSS is a bit different too:

Gone is the rule for styling the "disabled" label, and in its place is a rule that hides the row <div> that contains the phone number input and its label by giving it a display of none.

As you can see, when the checkbox is unchecked, the phone number input and its label are nowhere to be seen:

To make them appear when you check the checkbox, we need to modify our JavaScript:

This is much simpler than it was before. All we've got now inside the function is one line, which toggles the visibility of the <div> that contains the phone number field. Using the toggle() function means that whenever the state of the checkbox changes, we either show or hide the phone number field. We don't have to check the value of anything, store things in variables, or any of that stuff.

Now when we check the checkbox, the phone number field appears:

(You can see a live example here.)

If we had additional content below these elements, it would jump down when the phone number field appears. It doesn't take up much space, so it doesn't jump very much. But imagine if what we were making appear was a whole sub-section of the form that takes up half the height of the page. Pushing the following content down by so much can be very disorienting.

It's worth taking a minute to look at how we can use animation to make changes like this more palatable. We'll add some more content after the phone number field, then add animation and see how it looks. Add another <div> containing some text below the hidden one, so it looks like this:

Now let's change our JavaScript to include animation. Luckily, in this case, it is very easy indeed. All we need to do is replace the call to toggle() with a call to slideToggle(), so it looks like this:

Instead of just showing or hiding the element, slideToggle() makes it appear by sliding it down from the top, or hides it by sliding it up. Try it out here.

We can control various aspects of how this animation happens. For example, we can make it faster or slower by putting a value (in milliseconds) in the parentheses, like this:

slideToggle(1000)

This example shows this slower version in action.

Another thing we can do is control the flow of the animation (what is referred to as its easing). By default, jQuery animations start out slow, speed up in the middle, then slow down again at the end. We can change this by doing something like this:

slideToggle({easing: easeInCubic})

Note that to use additional easings like this one, you need to include the jQuery UI library by adding these two lines near the bottom of the page (before the <script> block that contains our code):

This starts off slow, like before, but speeds up and then doesn't slow down—it just stops abruptly, as if it had hit a wall. Try it here.

We're off on a bit of a tangent here, but I'll just show you one more before we move on to the next thing. There are 32 different easings available in jQuery, and each one gives the animation a slightly different feel.

For example, look what happens when we change the easing to easeOutBounce:

slideToggle({easing: easeOutBounce})

Take a look here. Fun, isn't it?

More complex scenarios

Sometimes we are faced with more complex scenarios than just disabling or enabling part of a form, or showing and hiding it. Often these more complex scenarios involve replacing one set of inputs with another depending on what the user selects. The example that Luke Wroblewski uses in his book is a "contact me" form, where the user can choose to be contacted via email, phone, SMS, or IM. When the user makes a selection, the form changes to show just the relevant fields (email address for email, phone number for phone, and so on).

There are lots of different ways that a form like this could work. You could have the initial selection as tabs, with the appropriate form fields inside each tab. You could have a drop-down list for email, SMS, etc, with the form fields right below it. You could have radio buttons for the initial selection, with the relevant fields appearing either below the radio button group or below the selected option. You could even go with a progressive-enabling-style design, with a disabled set of fields after each radio button, with the appropriate set of controls being enabled when the user selects one of the options.

(And, of course, there are lots of other scenarios where one user selection changes something else. One that you see pretty often is two drop-down lists, where the first is for selecting a category and the second is for selecting a sub-category, or an item within the selected category. So on a site that lists second-hand cars, you might have one drop-down list for selecting the brand, and a second for selecting the model.)

I could show you how to prototype one of these, but that wouldn't help at all with any of the others. And if I were to show you how to prototype them all, you would soon lapse into a boredom-induced coma. So what to do?

Is there some common thread can we draw out of all these different scenarios? Maybe there's some technique can I show you that will be useful in prototyping all of these? Well, there isn't really. All I can do is give you some pointers, which will hopefully help you to avoid some wasted effort:

Be lazy.

There is the way that a proper programmer would do something, and then there are shortcuts. We're not writing production code here, so it doesn't matter if we cut corners. What matters is that it walks and quacks like the real thing. Or even just enough like the real thing to be moderately convincing. So going back to the example I just gave of a pair of drop-down lists, the proper way to build something like this would be to populate the first list dynamically using a list of car brands that you request from the server. Then, when the user selects a brand, you would make another server request for the list of models for the brand, and use that to dynamically build up the list.

But for a prototype, you might not even need all the possible car brands and their models. It might be enough to have half a dozen brands, and a few models for each. And instead of dynamically populating each <select> element with the appropriate <option>s, you can put six separate <select>s in yout HTML, one for each brand, hide them all to start with, and just use JavaScript to show the right one depending on the brand that the user selects.

Learn a few key things in JavaScript/jQuery.

You don't need to know everything there is to know about JavaScript and jQuery to be able to do useful stuff with it. The ones I find myself using most often are:

Event handlers. Mostly, this means using jQuery's on() function to detect when the user does something to some element, and performing some action when they do.
Chaining. Every function gives you something when it's done. (In programming parlance, it "returns" it.) You can then do something with the thing it returns. So if you call the find() function on an element like this:
```
$('#myelement').find('li');
```
find() returns the <li> element that it found (if there was one within #myelement for it to find). So then you can do stuff to the <li> by chaining another function on the end, like this:
```
$('#myelement').find('li').hide();
```
hide() returns the element that it just hid, so you could, if you wanted, tack on yet another function to the chain to do something else to it. (But we won't.)
Simple conditional branching. The if and if ... else constructs let you ask "is this thing true", and if it is, to perform some action. (else lets you do something else if it isn't true.)
Slightly less simple conditional branching. When you've got something that can have multiple different outcomes, each with a different action to be performed, if becomes an overly-complicated way of doing things. The JavaScript switch statement is perfect in these situations. It's ideal when you've got something like a drop-down list with several options, and you want to do a different thing for each selected option.
Making stuff appear and disappear. We can use show(), hide(), and toggle(), as we've seen, to make stuff appear and disappear. And we can either supply additional arguments to these functions to animate them (and to control things like the speed and direction of the animation) or use special functions like slideUp() and slideDown() (and slideToggle(), which we saw above) to do the same thing. There's also the animate() function, for when we want full control over every aspect of an animation.

Look stuff up.

The jQuery documentation is pretty good. If you know the name of the function you're trying to use, it tells you everything you need to know about how to use it. And if you don't know which function you need, it has category pages that list all the functions for, for example, getting from one element to another, or for inserting, removing, and manipulating elements. (Note that jQuery is an addition to JavaScript. Some things, like if and switch, are part of JavaScript, not jQuery, so you won't get very far searching for them in the jQuery docs.) And if you Google for the thing you're wrestling with, you'll usually end up at Stack Overflow, the Q&A site for programmers. 99.9% of the time, your question will have already been asked and answered. For example, I wanted to know the correct way to find out if a checkbox is checked or not. So I Googled jquery checkbox get value, clicked the first result, and got the information I needed from the top answer. Easy-peasy.

Don't be afraid of doing it "wrong".

For anything you want to do, there are going to be several (even many) different ways to do it. Does it matter which one you choose? For a (disposable) prototype, it doesn't. The only thing that matters is: does it work or not? If it works, it's "right". I'm sure a "real" programmer would take one look at most of my prototype code and snicker to himself under his beard. But it serves the purpose for which it is intended, so it doesn't matter.

Having said that, I do have a couple of examples that you can take a look at. The first shows a different form depending on what you select in a drop-down list. The second changes the contents of one drop-down list depending on what you select in another. Use the View Source option in your browser to see how they work—they don't do anything particularly clever.

Conclusion

Changing parts of a form depending on what the user selects is pretty powerful. We can use it to hide complexity from the user and make our forms more simple to use. It means we need to learn a bit of JavaScript, but we can do a lot with a little. I think it's well worth the effort.

This was originally published on Boxes & Arrows on 27 May 2014.

If you liked this post, you should really check out my upcoming book, Prototyping Forms. Just like this, only more and better!

Forms—The Complete Guide—Part 3: Grouping and Inline Help

2014-04-29T00:00:00+01:00

Forms are important—they're the most common way to get information from our users. But just making wireframes of a form misses a big piece of the picture—what it's like to interact with it. An HTML prototype of a form, on the other hand, can look and behave just like the real thing.

In the first post, I showed you how to lay out a form and align the labels the way you want, using HTML and Foundation.

In the second post, I showed you all the different input types you can use.

In this post, I'll show you how to group your inputs and how to provide help to the user while they're filling out the form.

To make the most of these posts, I strongly encourage you to get your hands dirty. Type in the examples and then check them out in your browser. This gets it into your brain, and your fingers, more effectively than just copying and pasting (or worse, just reading).

Grouping

When you've got more than just a few input fields, it makes sense to organize them into logical groups, which you then separate visually. This makes the form less intimidating—it looks more like several small forms than one long one.

Let's make a shipping details form similar to the one we created in the first post. This time, in addition to the shipping address inputs, we'll add an extra input for the user's email address, and we'll split the phone number and email address out into a separate group.

The most obvious way to do this would be to add a second <fieldset> with its own legend, and put the phone and email inputs in there.

Let's try it. In the index.html file of a new Foundation project (see this post to find out how to set that up), add this:

It's OK, but the result looks a bit busy (view larger):

There's just a bit too much to process here. We don't need quite so many visual elements to separate the two groups. We could abandon <fieldset>s and replace the <legend>s with headings, but that would be semantically less correct. It would also affect the form's accessibility.

A better approach would be to tweak the CSS a bit to reduce the visual clutter. Let's create a new stylesheet and link it up from index.html.

So open up a new file in your text editor and add this CSS rule to it:

Call the file form.css and save it in the css folder. Then add this line to index.html:

How's that? (View larger.)

It's certainly cleaner. We could leave it at that. Or we could do some other things to further emphasize the grouping.

For example, we could put a thin horizontal line (<hr/>) between the groups:

Or we could give each group a background color:

Whatever works for you.

Inline help

Sometimes it's not 100% clear from a field's label what the user is meant to enter in the field. Maybe it's something that is simply too long to explain in a short label, so we need some additional text to help the user out.

A well known example is the credit card security code, which is often labeled as something not very helpful, like "CSC" or "CVV". Even "Security code" may not be obvious to some users. So we need to provide the user with an additional explanation somehow.

There are several different approaches we can use:

We can have a big lump of explanatory text at the top of the form. These often get ignored though.
We can supplement the label with additional text (usually in a smaller font size) for fields that need it.
We can use the placeholder attribute to give the user an example of the type of information required and its format.
We can have some help text that appears automatically when a field (or one of a group of fields) gets focus.
We can put an icon next to the label that displays help text when the user clicks on it or hovers over it.

The first one is not usually a good idea, so we won't bother with it. The second one is technically very easy to do, so we'll skip that too. And we've already seen how to use placeholder.

So let's tackle the last two.

Automatic inline help

Let's say you're designing a form that lets the user order a piece of clothing, a t-shirt, for example. They need to select a size, but you want to direct them to your sizing chart if they're not sure. So for just this one field, we're going to have a piece of help text that appears when the size control gets focus.

This is a bit like what eBay does on the password field on its registration form:

(Actually, in a scenario like ours, it's more likely that the "form" is just a couple of fields on a product page that allow the user to select size, color, and quantity.)

Our "form": page structure

Let's go ahead and build a prototype product page for our t-shirt. We're going to make it look like this:

It's got a title (the name of the shirt) at the top. Under that, there's a nice big photo, with additional photos that you can see by clicking the thumbnails on the left (though we'll fake this part— it's not important here). And to the right of the photo, we've got our form, consisting of inputs for choosing the color, size, and quantity, and an "Add to cart" button.

Only the size selector needs inline help, which we're going to display to the right of the selector. But when do we we want the help to appear? I think it's best if we show it both when the selector gets focus, and when the user moves the pointer in the general vicinity of the selector. That way, it will work well on both touch screens and when you've got a mouse and keyboard.

The first thing we need to do is get our basic page structure set up. We'll start out with an empty Foundation index.html file (refer back to the instructions in this post for that).

Obviously, in a real design, you're going to have global navigation, a footer, and all kinds of other stuff on the page. But here, we're just prototyping the essentials.

For our title, we need a row <div> containing one column that takes up the whole of the available width. (Not the whole width of the page, but the usable area in the middle, which by default in Foundation has a maximum width of 1000 pixels, and which gets shrunk down and rearranged responsively for smaller screens).

To achieve this, we give the <div> containing the heading classes of small-12 and columns. This means that for screen sizes of small and above (i.e., all screen sizes), we want it to take up the whole of the available with (all twelve of the available twelve columns).

So we need to add this to our index.html, right after the opening <body> tag:

Next we need another row <div> that will contain the rest of the content. Within this, we need three column <div>s: one for the thumbnails, one for the big photo, and one for the form:

Here, I'm using placehold.it to generate placeholder images, instead of using real images. (They have instructions over there that explain how to size the image, how to change the text, and so on.)

Here, the small- classes divide up the twelve available columns into three, with widths of one, five, and six columns respectively (for all screen sizes). The <div> for the form is empty at the moment, so we can't see anything there yet:

Things look a bit scrunched up, so let's add a bit of white space. In the last post, I showed you how to put CSS rules in a separate file and link to it from index.html. But for the sake of speed, this time, we're going to put the rule in a <style> block in the page's <head>. Within the <head> tags, add this:

This just adds top and bottom margins to the title, and gives all the images a bottom margin.

The actual form

Now for the actual form part of the page. This is also going to need some structure. Because we want to position the inline help to the right of the size selector, what we need to do is divide the form up into four row <div>s: one for each control and its label, and one for the "Add to cart" button.

Within each row, we'll divide the space up into two equal columns, one for the control, and one for the help (where needed). So let's add this within that third, empty <div>:

Notice how each row has only one columns <div>, except the second one. This is where the size selector will go—it's the only one that needs a column to contain the inline help. And the whole thing is enclosed in <form> tags, because, well, it's a form.

But until we add the actual controls, we can't see if it's right. So let's do that now. Add the <label>s, <select>s, <option>s, the <input>, and the <button> so it looks like this:

Nothing here that we haven't seen before. (Except I've explicitly set the value of the quantity <input> to 1, a sensible default I think.)

And how does it look? So far, so good:

This looks OK, but the form elements could use a bit of white space between them. So add this rule, again between the <style> tags in <head>:

This just adds bottom padding to each row. Now the only thing we need to add is the inline help itself. Oh, and there's the little matter of making it appear and disappear when we want. We'll get to that in a minute.

First let's add the HTML. Inside that empty <div> (the one right after the size <select>), add this:

This uses Foundation's panel and callout classes to style it, plus some inline styling to make it a bit more compact. (Any bigger, and it'll make the row taller, which means things will jump around when we show and hide it.) It also has an aria-live attribute so that screen readers will be aware of the content when we make it suddenly appear on the screen.

This is how it looks now:

Now we need to hide it, so we just add display: none; to the existing style attribute of the inner <div> (the one with the panel and callout classes), so it looks like this:

Next, we need to show it and hide it. The only way to do this is with JavaScript. This is more like "proper programming", but don't be put off by that—I'll do my best to make it simple and easy to understand.

JavaScript: show help on focus

First, we need somewhere to put our JavaScript code. Normally, you would keep it in a separate file, so you can reuse it in multiple HTML pages. But for simplicity, we'll add it in a <script> block at the bottom of the page, a bit like what we did with the CSS rules in the <style> block earlier.

Now, jQuery is included with Foundation, so that's what we'll be using here. All the code we'll be writing will go inside jQuery's $(document).ready() function. This means that whatever we put inside it will only get run once the page has loaded.

To start with, we'll add some code that shows our inline help <div> when the size <select> gets focus. (This happens when the user clicks or tabs to it. Or when they tap on it on a touch device.) So add this <script> block at the bottom, right before the closing </body> tag:

Do not be alarmed! This may look a bit intimidating, but if we take it piece by piece, you'll see there's not a lot to it.

The <script> tags tell the browser that what's inside is Javascript. The $(document).ready() function, as I explained, tells the browser to run the code inside it only after the page has loaded. The real meat here is what is between the curly braces (i.e., after $(document).ready(function(){ and before });).

Let's look at the first bit:

$('.field_row input, .field_row select')

This says "Hey, jQuery, find any <input> or <select> that is a child of something with a class of field_row."

jQuery uses the exact same selectors (and ways of combining them) as CSS. So that's one less thing to learn. (I covered the very basics of CSS, among other things, in this post.)

So just like in CSS:

A period means it's a class name. (So .field_row means any element with a class of field_row.)
A hash (#) means it's an element ID. (So #size_selector means the element with the ID size_selector.)
Two selectors separated by a space means the second one must be a child of the first for the selector to apply. (So div input means any <input> that is a child of a <div>.)
A comma means "or". (So input, select means any <input> or <select>.
You can combine selectors in other ways. For example, div.field_row means a <div> with a class of field_row.

OK, on to the next part:

.on('focus', function(){

This says "For whatever we just selected, do something when it gets focus." on() is what's called a function. A function is just a chunk of code that has a name that you can use to run it (to "call it", in programming terms). (The period means "Call this function on the thing we selected.")

on() looks out for an event, and does something when that event occurs. In this case, the event is focus. You can tell on() to look out for other events too, like click or mouseover.

Everything between the last (opening) curly brace after function() and the closing curly brace here:

});

is the code that actually gets run when on() detects that one of the selected elements has been given focus. That's this line:

$(this).parent().parent().find('.help').show();

What this says is:

Take the element that was clicked (this).
Find its parent element. (In this case, the parent of the <input> or the <select> is the column <div> that contains it.)
Find that element's parent. (In this case, that's the row <div> containing the <input>/<select>.)
Within this element, find any element with a class of help. (That's the inline help <div>.)
Finally, show it.

This technique, where you call one function after another like this, is called chaining. It can save you a lot of work. (The alternative would be to store the element you get in step 2, then (step 3) call parent() on what you stored, then store that, and so on and so on.)

Phew!

Now if you click on the size <select> (or tab to it), the inline help magically appears. But it doesn't go away when the <select> loses focus.

JavaScript: hiding help when the selector loses focus

Luckily, to make this happen, we can just copy our existing code and make a couple of small changes. Copy the three lines of code (the ones that call on()), add a couple of blank lines below it, then paste them in. Now just change focus to blur and show to hide. The code you pasted in should now look like this:

If you try it now, you'll see that when the <select> gets focus, the help appears, and when it loses focus, it disappears again. Great! But it's not enough. Earlier we said we want the help to appear on hover as well. This isn't a problem— a few more lines of code will do it. But where do we want the hover to work?

JavaScript: show help on hover too

Here, our help text contains a link (to a page that doesn't exist, unless you feel like creating it). If the help appears when you hover over the <select>, when you go to click the link, it will disappear as soon as your pointer leaves the <select>. Which is not very nice.

We need to make the hover work for the element that contains both the <select> and the help, that is, the row <div>.

So let's add some more code within our <script> block:

This time, the selector is simpler, because we're just targeting the rows (that is, the <div>s with a class of field_row). (You may be wondering why I'm using this class, which applies to all four rows, instead of just sticking an ID on the one row that contains the help and use that here. The answer is that this way is more flexible—if I want to add help for another field later, I can just add it to the HTML and it will work, without having to change anything in the JavaScript.)

Instead of on() after the period, this time we've got a function called hover(). In contrast to on(), where we specified one piece of code that was run when the event was detected, here we need two: one that tells jQuery what to do when the hover begins, and one that tells it what to do when it ends. That's why there are two function(){}s.

The code for hover start goes inside the curly braces in the first function(){}, while the hover end code goes in those of the second. To make things easier to read, lets split it up onto separate lines, like this:

Now we can just put the code that actually does stuff in those two blank lines. This code is going to be exactly the same as for the focus and blur events, except here, we don't need those calls to parent() to navigate up from the field to the row <div>, because we're already there. So add the necessary lines to make your code look like this:

If you try it now, you'll see that hovering anywhere in the size row makes the help appear, and when you move away, it disappears. Yes!

Except what happens when the size <select> has focus, and then you hover and move away? No! The help disappears! That shouldn't happen!

JavaScript: actually, don't hide it when the hover ends, in this one specific case

So, what to do? Well, what we need to do is check if the <select> has focus before we hide the help (at the end of the hover)—and if it does have focus, we do nothing. For this, we'll use JavaScript's if construct. This lets us check if something is true, then do something. (And if it's not true, we can either do nothing or do something different.)

So change your code so it looks like this:

What's going on here? The only new thing here is that we've wrapped the line that hides the help in an if block. The line inside the block only gets executed if the bit in the parentheses after if is true. Let's take a look at that expression:

!$(this).find('input, select').is(':focus')

Ignore the exclamation point for a moment. this is the row <div>. Within this <div>, we're using find() to get either the <input> or the <select>, and then we use the is() function (which checks if an element has certain attributes) to check if it has focus.

But this gives us an answer of "true" if the element does have focus. But we want to to hide it only if it doesn't have focus. That's where the exclamation point comes in. It means "not", and simply reverses the result of the expression—true becomes false and false becomes true.

And now it works. (You can see it in action here.)

User-triggered inline help

You'll be relieved to hear that user-triggered inline help is much easier to set up. All we need to do is take the prototype we just created and make a few changes (mostly removing stuff).

Adding an icon

First off, we need to add some kind of icon that the user can click or hover over to bring up the help. There is a set of Foundation icons that you can use just by adding one line to your page's <head>:

Let's add an "i-in-a-circle" icon to the "Size" label. Find it in your HTML and change it so it looks like this:

The fi-info class on the <i> element is how we specify which icon we want. (Other icons get fi-something-else, like fi-heart for a heart or fi-flag for a flag.)

The Foundation icons are an icon font. This means that you can style them just like text. You can make them bigger, change their color, add shadows, whatever. For now, we're just making the icon a bit bigger, making sure it lines up with the label, and changing the pointer to a hand so that it looks clickable.

Note that the <i> can't be inside <label> because clicking the label gives focus to the <select> (because of the for attribute that links the two). If we put the icon inside <label>, clicking it the same as clicking the label.

Also, we need to set the <label>'s display to inline-block (instead of the default of block) to force the label and the icon to stay on the same line.

New JavaScript for new behavior

Now, how do we want it to behave? If we make it so that the help only appears when you hover over the icon, then we're in the same situation we would have been in if we'd made it appear when you hover on the <select>—when you go to click on the link in the help, it disappears before you can.

There are a couple of things we can do. We could introduce a delay, so that when the pointer moves away from the icon, the help does not disappear immediately. The other alternative is to make the help appear when you click on the icon, and have some way to dismiss it. Since we've already seen how to make things happen on hover, let's go for the click-triggered help this time.

Within our $(document).ready(), we can get rid of all the code and replace it with this:

Here, we're targeting the <i> element with a class of fi-info (our icon), and we're telling the on() function to look out for click events on it. When it detects a click, we want it to start at this (the icon), go up two levels in the page hierarchy (by calling parent() twice), which takes us to the row <div>, and then call toggle() on it.

toggle() is rather clever. It hides the element if it's visible, and shows it if it's hidden. This means you don't need to keep track of its visibility. So that's less work for us. And it gives us a way to dismiss the help—you just click the icon again (which is nice and symmetrical).

And that's it. (See it for real here.)

Bonus learnings! Or I came for the forms, but stayed for the RWD

If you look at either of the above examples on your phone, you'll see that it's just the same thing, but squished down and misaligned. This is a bit of a shame. Foundation is a responsive front-end framework—we can use it to change the layout on smaller screens to something that makes better use of the available screen space.

Above, we used small- column classes for everything. This means that the defined layout is used for small, medium, and large screens. All we need to do is change the classes a bit to tell Foundation how the page should be laid out on smaller screens.

Here, we're just going to have two layouts: one for small (phone-sized) screens, and one for medium (tablets) and large (desktop) screens.

In our small layout, what we really want is to just have everything stacked vertically: first the title, then the thumbnails, then the big picture, then the form. We can get this by just changing every small- class name to medium-. (What this means is that Foundation does something with the column widths we give it for medium and large screens, and treats it as if we didn't specify any column widths at all on small screens—when you don't specify column widths for elements, Foundation makes them full width and stacks them vertically.)

On smaller screens, that looks like this (code):

That's pretty good, but I think it would look better if the thumbnails were below the big photo instead of above it. Foundation has classes you can add to make this happen.

The way you do it is like this. First, you change the order of the elements so that they appear correctly at small screen sizes. Then you add classes to move them left or right on larger screen sizes.

Let's swap those two <div>s so they look like this:

Now we need to add push and pull classes to move these two columns to the left and right so that they are in the right positions for medium and large screens. Adding a push class pushes the column to the right, while a pull class pulls the column to the left.

So we need to add the medium-push-1 class to the <div> that contains the big photo to push it one place to the right. This will leave the first column free for the thumbnails. Then we add the medium-pull-5 class to the <div> containing the thumbnails to pull it five places to the left, into the first column. This part of the code should now look like this:

Now if we look at it on a small screen (or shrink down our desktop browser window), we can see that the thumbnails are now below the big photo, just like we wanted (real example here):

And at larger screen sizes, the layout is just the same as before.

Conclusion

We've covered quite a lot of ground in this post. Stay tuned for the next post, where we'll look at responsive enabling and responsive disclosure.

This was originally published on Boxes & Arrows on 22 April 2014.

If you liked this post, you should really check out my upcoming book, Prototyping Forms. Just like this, only more and better!

Forms—The Complete Guide—Part 2: Input Types

2014-04-05T00:00:00+01:00

Forms are one of the most important parts of any site or app—they are the most common way for our users to give us the information that we need to help them do what they want to do.

But in many instances, we design forms statically, often as wireframes. But so often, what makes or breaks a form is what it's like to interact with it. When the user clicks on a particular radio button, some additional inputs appear. How does that happen? More importantly, does the user understand what just happened?

Things like this are next to impossible to explore using static deliverables. But with a prototype of a form, it's easy. And with a prototype form made in HTML, you can make it look and behave exactly like the real thing. Which means that once you've validated it with users, you can be sure that it can be implemented so that the appearance and feel are just the same.

This series does not try to explain what your form should contain, how the fields should be grouped and laid out, where to put primary and secondary buttons, and so on. There are lots of great resources out there that do that already. (Like Luke's and Caroline and Gerry's books. Or Justin's article.)

No. What this series does is give you the how. You've already figured out what you think your form should contain and how it should behave. These posts will give you everything you need to know to make a prototype of your form in HTML, something that looks, works, and feels like the real thing. Which you can then use for usability testing, for getting stakeholder buy-in, and as a living specification for developers.

In the first post in this series, I showed you how to lay out a form and align the labels the way you want, using HTML and Foundation.

In this post, I'll show you the different types of inputs available to you and how to use them.

To make the most of this post, I strongly encourage you to get your hands dirty by actually typing in the examples and then opening them in your browser to see how they look and work. From personal experience, this gets it into your brain, into your fingers, much better than just copying and pasting.

Input types

There are several different HTML elements that are used in forms. Buttons get their own element (<button>), as do drop-down lists (<select> and <option>), and multi-line text inputs (<textarea>).

But most form elements are the <input> element, with a type attribute that specifies what kind of input it is.

Let's look at them one by one.

If you're following along and actually typing this stuff in, you need to set up a new Foundation project, open up its index.html file, and delete all the sample content (see this post to find out how).

Then add an empty <form> element and the necessary Foundation layout elements.

Once you've got that set up, you can just add each example within the <fieldset> tags, after the <legend> element.

Note: In the code samples below, you'll notice that all the <input> elements have both a name and an id. Why is this? It's because you need the id to be able to identify individual HTML elements (to style them with CSS, etc.). But for a real form, you need name so that the data that gets sent to the server will be labeled correctly. These aren't proper forms, they're just prototypes. But it's good to do it properly from the start. So the rule of thumb is: for <input>s, use both id and name, and give them both the same value. (An exception is radio buttons—I explain why they're different below.)

Text and its variants

Text

An <input> of type text is just a simple input field. There are no restrictions on what the user can type in it (though there are attributes that you can add to do things like limit the length of the field's contents—see below).

Password

An <input> of type password behaves exactly the same as a text input, except that whatever you type in it is obscured.

Email

An <input> of type email is the same as a text input, except that on phones and tablets, the keyboard that is displayed has @ and dot keys as standard—you don't have to go digging for them:

It also gives you validation for free. If you enter something other than a valid email address and then submit the form, the browser will do something like this:

(This is true for desktop browsers anyway. Most mobile browsers don't do this yet.)

URL

The url <input> type is similar to email, except here you get a keyboard layout with slash and dot keys (and maybe others, such as .com).

Again, desktop browsers validate these automatically:

Phone number

The tel <input> type, as we saw in the previous post, gives you a phone keypad on smartphones:

Number

The number <input> type doesn't restrict what you can type, but on smartphones (the iPhone, at least), you get the regular keyboard, switched to numbers-and-symbols mode:

Different desktop browsers render this input differently. In IE and Firefox, it looks the same as a text input, but in Chrome and Safari, it gets spinner controls for increasing and decreasing the value:

You can set minimum and/or maximum values, and a step size. These affect the behavior of those spinner controls.

Autosuggest

Empty:

Typing:

You can use an <input> with a list attribute paired with a <datalist> element to get something that is kind of a cross between a text input and a drop-down list. As you type in the input, a dropdown list shows you matching options. You can click on an option or use the arrow keys and Enter to select.

Other types

There are a number of other <input> types that were introduced with HTML5, but most of them are not widely supported yet. These include color and various date and time inputs, such as date, time, datetime, datetime-local, week, and month.

For now, you're better off using things like the jQuery Datepicker.

The rest

Checkboxes

If you give an <input> a type of checkbox, you get a checkbox. These usually have their label to the right. For checkboxes, the for attribute is particularly important—it makes the label clickable—clicking it is just like clicking the checkbox itself. Adding the checked attribute (which doesn't take an argument) makes the checkbox checked when the page loads. For a prototype it doesn't really matter, but a checkbox in a real form must have a value attribute.

Radio buttons

Like checkboxes, with <input>s of type radio, the label usually comes after the input. And for and checked work the same here too. Here though, be sure to give all the radio buttons in a group the same name attribute—this tells the browser that they belong together, and that only one can be selected at a time. Again, like with checkboxes, every radio button must have a value.

Sliders

An <input> of type range gives you a slider. Like with number, you can specify a minimum, maximum, and step values. But this control is not hugely useful on its own—if precision is not an issue, you can probably get away with just adding text before and after the <input> to show the maximum and minimum values. But in most cases, you'll probably want to provide some sort of feedback so the user knows what value they have selected.

This is not difficult. It requires a tiny bit of Javascript, but you'll see in a minute that it's really no big deal. We just need to take the existing bit of HTML and add an <output> element to show the value. And we add an oninput attribute to the <input> to tell it what to do when its value changes.

In this version, the <input> and <output> elements are in separate columns, and I've given the <input> a width of 100% so it will stretch to fill its column:

The little bit of Javascript that is the value of oninput just sets the value of the output (range_value.value) to the value of the input (range_input.value). (range_value is the <output>'s ID, and range_input is the <input>'s ID. Adding the dot and value just means “the value of the value attribute of the element with this ID.”)

Drop-down lists

Closed:

Open:

Drop-down lists are not <input> elements—they are made up of a <select> element containing a number of <option> elements.

This is fairly straightforward. One thing I've added here though is the first <option>—it prompts the user what to do, but is not actually an option they can select. (The selected attribute means it is what is displayed in the closed dropdown before the user interacts with it.)

Without this option, "Option 1" would be selected by default. Usually we don't want anything to be selected by default.

Textareas

A <textarea> is like a text <input>, except it lets you enter multiple lines of text. Like all the text-like <input>s, its width is 100% of the column that it's in.

As for height, there are two ways to set this. One way is to set the height in CSS (or directly on the element by adding a style attribute). The other way is to use the rows attribute, like I'm doing here. This makes the <textarea> tall enough to fit six lines of text.

(The style="height: auto;" attribute is to get around a bug in Foundation. If you set the height to a specific value instead of using rows, you won't need this.)

Buttons

Most forms have buttons that you have to click to send the information you've entered to the server. Some also have a button for a secondary action, to cancel out or to reset the form (though some argue that such secondary actions are usually a bad idea).

Here, the buttons are <input>s of type submit and button. (submit is a special kind of button for submitting a form.) The right place to put these is after the closing </fieldset> tag.

The Submit button gets a class of button to make it into a nice-looking Foundation button, while the Cancel button also gets a class of secondary to make it visually less prominent.

Foundation also lets you use the <a> element for making buttons—just give it a class of button. It also lets you do stuff like make buttons smaller, give them rounded corners, and so on, just by adding classes.

Other clever Foundation stuff

Foundation lets you do some clever things that the standard HTML elements don't let you do.

For example, you can combine an input with a label to get something like this:

You can see the code for that here.

You can also combine an input with a button to get this:

The code for that one is here.

Important attributes

I mentioned a few attributes along the way, like id and name, checked for checkboxes and radio buttons, min, max, and step for number and range type inputs, and so on. But there are some others that you need to know about:

autocomplete

Browsers try to help us by automatically filling in form fields for us when they can. But sometimes this is not appropriate, for example, for sensitive information such as bank account and credit card numbers (and even passwords in certain cases, though beware of being annoying with this one).

Setting autocomplete to off for an input tells the browser not to fill it in automatically.

autofocus

On each page, you can give one (and only one) form control the autofocus attribute. This field will get focus when the page loads, so the user can start interacting with it without having to click in it or tab to it.

disabled

A control with the disabled attribute gets greyed out and you can't interact with it. This may be because it's not relevant unless some other control has a particular value. (For example, if your form has a "How did you hear about us" section with radio buttons, the last one might be "Other", with a text input so the user can type something that's not in your list. It makes sense to make this input disabled unless "Other" is selected. I'll cover this sort of thing in more depth in a subsequent post.)

maxlength

Text-type inputs (text, email, url, tel, etc.) can have a maxlength attribute. This lets you specify the maximum length in characters. Most browsers won't let you type any more once you hit the limit. This is handy for things like phone numbers, which can't be longer than a certain number of digits.

multiple

The <select> element and <input>s of type email (also of type file, for uploading files, which I haven't covered here) can take the multiple attribute. This lets you select multiple items in a dropdown or specify multiple email addresses, respectively.

Notice how the <select> is displayed differently when multiple selection is enabled.

pattern

pattern tells the browser what an acceptable value looks like. I'll cover this in a subsequent post when I talk about validation.

placeholder

The placeholder attribute puts hint text inside the <input> (or <textarea>), to give the user an idea of what they need to type. It disappears when you click in the <input>. Some sites use it to indicate which fields are mandatory and which are optional.

IMPORTANT: Do NOT use this instead of a <label>. It is very bad from both accessibility and usability points of view.

required

The required attribute means that a field is mandatory. It doesn't change its appearance (an asterisk doesn't magically appear next to its label), but if you submit the form without filling it in, you'll get a helpful message:

tabindex

The tabindex attribute (which has a numerical value) determines the order in which controls get focus when the user presses the Tab key.

If you're doing something weird with your form layout such that the inputs are in a different order on the screen than in the page source, you should use the tabindex attribute to make sure that focus jumps to the right input when the user tabs between them.

Special considerations

On phones and tablets, there are additional challenges that we face. How often have you come to sign in or register at a site on your phone and seen something like this?

On m.hpdirect.com, as I'm typing in the User ID field in the login form, my phone is automatically capitalizing the first letter and wants to correct what I'm typing to words it has in its dictionary. So now I have to tap the little "x" to dismiss autocorrect, and go back and change the capital "M" to a lowercase one. Grrr.

For fields like this, there are two attributes that we can add to turn off this antisocial behavior: autocorrect and autocapitalize.

They both take the same values: on and off. By default, they are on.

Conclusion

Hopefully you now have a pretty good idea of the building blocks that you can use to create your prototype forms.

In the next post, I'll show you how to group inputs into logical (and less overwhelming-looking) groups and how to provide help to users while they are filling in the form.

This was originally published on Boxes & Arrows on 25 March 2014.

If you liked this post, you should really check out my upcoming book, Prototyping Forms. Just like this, only more and better!

iOS-style Buttons

2014-02-17T00:00:00+00:00

So I got a bee in my bonnet about the buttons on iOS 7 that change color when you tap them. You know, like the ones on the screen unlock keypad and the phone dialer.

I love the way that they are animated: the color change happens almost instantaneously when you tap, but the fade out happens more slowly.

I figured this should be doable in HTML/CSS too (with a bit of jQuery to help). So here is the result (in Foundation, of course). (It's in a frame—you can scroll it.)

(Or view the example not in an <iframe>.)

I think it works pretty well.

The standard button is light colored, for use on dark backgrounds. There is a dark class that makes the button darker, which is good for lighter backgrounds.

And just like Foundation's built-in buttons (shown above for comparison purposes), adding the disabled class makes the button appear disabled.

I haven't gone the whole hog and made matching classes for all the different Foundation buttons (different sizes, rounded corners, different colors, etc.)

If you want to use it yourself or just try to figure out how it works, you can take a look at the source or view it on GitHub.

I'd love to hear your thoughts and any questions you might have. Ping me on Twitter: @martinpolley

And if you're interested in how to steal/copy other people's ideas, I'll be explaining how in an upcoming post. (If the idea makes you feel a bit uneasy, think about it like this: copying is how good ideas spread.)

Make sure you don't miss it—sign up for my newsletter over there on the right.

Forms—The Compleat Guide—Part 1: Layout and Alignment

2014-01-13T00:00:00+00:00

UPDATED 21 Jan 2014: After some nice folks pointed out that my examples were a bit lacking in the accessibility department, I added for attributes to associate labels with inputs, fieldset and legend instead of a regular title, and added an explanation of why labels inside inputs are really not a good idea.

UPDATED 30 Jan 2014: I added a section to explain how to take advantage of responsive design to rearrange the form depending on the screen size (right-aligned labels on big screens, top-aligned labels on small ones).

UPDATED 12 August 2014: The three subsequent posts in this series were published on Boxes and Arrows: part 2, part 3, part 4.

Forms can be tricky. They are one of the most important parts of any site, but they are easy to get wrong. There are so many things to think about:

What information do we actually need from the user?
Which are the right input types to use?
Is that true for mobile too?
What should the different inputs be called?
How should they be grouped?
What should the titles of the groups be?
Do we need help text?
Where does it go?
When should we show it?
Do all of the inputs need to be visible all the time?
How and when should we validate?
How should we highlight errors?

And so on and so on.

This series of posts doesn't answer all these questions for you. There are lots of great resources out there that already do that. (Like Luke's book. Or Justin's article.)

No. What this series does is give you the how.

How to do what though? How to prototype a form in HTML, so that you can put something together that looks, works, and feels like the real thing. Which you can then use for usability testing, for getting stakeholder buy-in, and as a living specification for developers.

You know how you want to lay out your form. This shows you how.

You've decided that right-aligned labels are right for this form. This series explains how to do that.

You know that when the user enters something invalid, you want a message at the top of the form and to highlight the problem input. There's a post that's got you covered.

Layout

If you've read any of my previous posts, you'll know I'm a fan of Foundation, Zurb's front-end framework. Its responsive grid makes laying out pages a cinch. And the same is true for forms.

I'm not going to explain how to download Foundation and set up a project. You can refer back to this post for that. I'm going to assume you've got a project set up and are sitting in front of a text editor with index.html (from Foundation) open, the default content deleted, and ready to start adding your own stuff. (I'm using Foundation 5.0.2, the latest version at the time of writing.)

So let's say you're designing a form where the user enters their shipping address. You want it to look like this:

No worries! All we need to do is add a <div> that has the Foundation row class for each row of the form, and for the row that has two inputs, we just add a <div> with the right number of Foundation columns for each input. Add this to index.html:

Which comes out looking like this (this is embedded, and you can scroll it):

Open in a new tab

OK, what did I do here?

This is a form, so we've got a <form> element wrapping everything else. Inside this, there's a <div> of class row. In Foundation, you have rows that contain columns.

Then there's another nested <div> with a class of large-8 small-centered columns. All this does is squish the form down a bit horizontally. It's not necessary at all, but without it the form is really wide.

Next we've got a <fieldset>, which groups the form items together, and a <legend> that gives the group of elements a title.

After that we've got the actual meat of the form: <input> elements and their <label>s. Each such pair is just a <label> element immediately followed by an <input>. This stacks them one above the other. (A bit later, we'll see how to do left- and right-aligned labels.)

Notice that each <input> has an id, and that its <label> has a for attribute with the same value. This is important for accessibility—it tells screen readers what belongs to what so it can read things out correctly.

Most of these pairs are wrapped in <div>s with a class of small-12 columns. This tells Foundation to make them twelve columns wide. (The Foundation grid is based on twelve columns, so this means it takes up the full available width. And because Foundation is mobile-first, we use small-12, which applies to both small and large screens, then if we want to do something different on large screens, we add a large- class as well. Here we don't, so small- is all we need.)

The only row that isn't like this is the one containing our State/province and Postcode/zip <input>s. Here, we've got two <div>s, one eight columns wide (small-8 columns), and one four wide (small-4 columns). You can divide the space up whichever way you like, but the number of columns mustn't be more than twelve. It can be less, but then you'd have a gap on the right. (Try it and see.)

All the <input>s have a type of text, because they are for entering text. Except for the phone number <input>, which has a type of tel. In desktop browsers, this works exactly the same as a text input, but on mobile devices, you'll get a phone keypad instead of the normal keyboard:

If you open this up in a browser, you'll see the layout is just how we want it. And if you make the browser window narrower, the layout is maintained.

If you want the layout to change on small screens so that all the fields are full-width, change the classes for those two columns from small-8 and small-4 to large-8 and large-4:

That tells Foundation only to make them side-by-side columns on large screens. On small screens, they'll be stacked one above the other. Check it out here. (Opens in a new tab.)

Label Alignment

Let's reuse the layout example to play around with the alignment of the labels. There are several different options for label placement.

Top-aligned:

Left-aligned:

Right-aligned:

Labels inside inputs (which lots of folks agree are a bad idea):

The form already uses top-aligned labels. So how do we do the others?

Simple, we just use Foundation columns again. Let's start off with left-aligned labels.

Left-aligned labels

We just need to change our markup to look like this:

All I've done here is put two columns in each row instead of one as it was before. I've given the labels two columns width and the inputs ten columns. And where we had two columns before for State/province and Postcode/zip, now we have four: two for the labels and two for the inputs.

Note that I've added the align class to the labels. This is a Foundation class that makes the labels line up vertically with the inputs. (Try removing it and see what happens. It's not pretty.)

Here's what it looks like now:

Open in a new tab

Right-aligned labels

To make the labels right-aligned, all we need to do is add the right class to each label:

Which looks like this:

Open in a new tab

Responsive jiggery-pokery

It’s all very well having a form that looks just the way you want on a big screen, but using the exact same layout on a small screen doesn’t always work. (Try opening the last example on your phone—it looks rubbish.)

We can use Foundation’s responsive grid to make it work better on small screens. In that last example, we used the small- classes to set the width of the labels and inputs. That means that this is the way we want them to look on small screens and anything bigger than that.

If we change small- to large-, what will happen is that we will get this layout (labels and inputs on the same line) only on large screens (i.e., above 1024 pixels wide). On smaller screens, the labels will be above the inputs, just like in the first example. Try it yourself and see what happens when you shrink the width of the browser window.

The width at which it jumps from an all-on-one-line layout to a stacked layout is a bit too wide though—the side-by-side layout works just fine on tablet-sized screens as well as desktop-sized ones.

So what we need to do is use medium- instead of large-. This means that for medium (tablets) and large (desktop) screens, we get the right-aligned labels (or left-aligned, if that’s what you want), and on small (phone) screens, the labels are top-aligned.

But if our labels started out right-aligned, they stay right-aligned even on small screens. And that’s just wrong:

Foundation doesn’t give us a way to handle this, but if we dig a little under its responsive skin, we can make things work the way we want.

Responsive designs use CSS media queries to rearrange their layouts depending on the screen width. All we need to do is add one media query to our CSS to make it all better.

Create a file called form.css and save it in your project’s css folder. Add this to the new file:

And somewhere inside between the <head> tags in index.html, add this line:

This CSS rule looks a bit intimidating, but all it says is this: if the width of the browser viewport (i.e., the width of the content area of the browser window) is 640 pixels or less, apply this rule.

And the rule that gets applied in this case says to align the label text left and to float it left as well. (Originally <label> was floated right and its text was right-aligned.)

Why 640 pixels? Because that is the width (the “breakpoint”) at which Foundation changes the page layout for elements that have a medium- class. (There's another one at 1024 pixels for large-.)

This is how it looks:

Large/medium:

Small:

Open it up in a new tab and see how it behaves when you change the width of your browser window.

Labels inside inputs

To put the labels inside the inputs, let's just take our first alignment example and remove the labels. Then for each input, we'll add a placeholder attribute that contain the label text:

Here's how that looks:

Open in a new tab

It's nice and clean, but once you start typing in an input, the label disappears, which can be problematic. And the lack of labels is a real problem from an accessibility perspective—screen readers typically don’t read placeholders like they do labels.

What lots of sites do is have regular labels and use the placeholder attribute to show you the kind of thing you're meant to enter in each input. Freckle, the time-tracking app, does this to good effect:

Conclusion

That will do for now, I think. In the next post, I'll be showing you how to group inputs. I'll also show you all the different types of inputs that you can use.

Make sure you get it by subscribing to the feed. Or better still, by signing up for my newsletter below.

If you liked this post, you should really check out my upcoming book, Prototyping Forms. Just like this, only more and better!

The Four Minute Prototype: Adding Interactivity

2013-11-04T00:00:00+00:00

In my last post, I showed you how to prototype a fairly simple web page (with responsiveness baked in!). This time, I'm going to show you how to add some interactive stuff to the page.

What we're going to do is to take our existing, static page and add a contact request form. What's interactive about a form though? Well, this one will use the selection-dependent inputs pattern—it will have a drop-down list where you can choose how you want to be contacted, and the form changes depending on what you select.

The first thing we need to do is to add a new <div> with the right Foundation classes to hold the form. We want to put it in that right column, right above the ads. Currently, that piece of HTML looks like this:

The way we've set it up is so that the ads get hidden when we're on a small (smartphone-sized) screen. But we don't want our form to get hidden. What we need to do is nest another Foundation row/column structure in here so that we have two rows (each of which takes up all 12 of the available columns).

And we move the hide-for-small class from the container (large-3 columns) <div> to the row that contains the ads:

If you open this up in your browser you'll see the placeholder text above the ads:

And if you resize the window down to smartphone width, you'll see that the ads disappear but the placeholder text doesn't:

So far, so good.

Now we can get on with the actual work—adding the form. First, let's replace that placeholder paragraph (the one in the <p> tags) with some introductory text. And right after that, we'll throw in a drop-down (a <select> element containing <option> elements) that lets the user choose how they want to be contacted.

Notice that I've wrapped the <select> in a <form> with a class of custom. This tells Foundation to use its own styling for the select instead of the standard look. This means it matches the other form elements we're going to be adding.

And there's also a horizontal rule (<hr/>) to separate the form from the ads:

We also need a bit of CSS:

The first rule here styles the "Contact me via…" label that is the first item in the drop-down. (If you look in the HTML, you'll see that the first <option> has a class, which is what we use in this rule.) This fake option means that nothing is selected by default. Which is A Good Thing.

The second rule just adds a bit of top padding to the intro text.

If you open it in a browser now, you'll see we have a drop-down list with the right options:

But it doesn't do anything yet. The next thing we need to do is add the forms. We actually need three forms, but we'll make it so that only one is visible at any one time. So right after the <select>, add the first form, like this:

This is just a <form> element containing a bunch of <label>s and <input>s. A few things to note though:

The <form> has a class of hbd. We'll be adding a CSS rule in a minute to hide this by default. (And soon, we'll add a little bit of Javascript to show the right form depending on what you select in the drop-down.)
The first two <input>s have a type of email. On the desktop, this is exactly the same as an <input> with a type of text. But on iOS (and Android too, I believe), when you tap on the <input>, you get an email-specific keyboard layout, with @ and period keys, but no space bar.
The last two <input>s are the Submit and Cancel buttons. The first one has a type of submit. This is a special kind of button that tells the browser to send the contents of the form to the server. Here, it's just a prototype—we're not sending anything anywhere. But it's better to do it the "right" way.
The buttons have classes to give them the right size (small) and to indicate which one is the primary action and which one is secondary (secondary for Cancel). And I've used Foundation's column classes to make them (together) the same width as the <input>s. And I've made the primary action button a bit wider than the secondary one.

Which looks like this:

Now let's add the other two forms. Add this right after the form we just added:

These are pretty similar to the first form, except for a couple of things:

These both have a class of custom. Without this, the <select> wouldn't get the nice Foundation styling.
In both forms, the phone number <input> gets a type of tel. Like the email <input> we saw before, this changes the keyboard layout on mobile, this time to a numeric keypad.
I've used the names of the mobile providers where I live for the SMS form. If you like, you can use your local providers instead.

But now if you look at the page, all three forms are visible. Let's add some CSS to hide them all:

This rule applies to elements with that hbd class, which we added to all three forms. Now if you check the page, you shouldn't see any forms.

The only thing left to do now is add a little tiny bit of Javascript to show the right form when you select something in the drop-down. First we need to create a file to contain our Javascript and link to from index.html.

Just like we did with the CSS file back when we were first creating the page, create a new file called 4min.js and save it in the js directory. Now add a second <script> element right after the existing one that pulls in the Foundation Javascript file, down towards the bottom of index.html so that it looks like this:

Now in 4min.js, add this:

This says "when the page finishes loading, run whatever code is inside the curly braces."

So let's add some code in there to do what we want:

This binds an event handler to the <select> with an ID of contact_select. It does a what to the what now?!?

That's just fancy programmer-speak for "It tells jQuery* to watch the <select>, and when its value changes, to do something." (The value of the select changes when we select one of the options.)

* jQuery is a library built on top of Javascript that makes lots of things much easier than trying to do them ourselves with just Javascript.

(The bit between the slashes and asterisks is a comment. It's a good idea to include comments like this, so that other people can figure your code out, and so you can remember what it does when you come back to it later.)

So what do we want it to do when the value changes? Well, that depends on what we select. A Javascript switch statement is perfect for this—it lets you specify what happens for a limited number of alternatives:

Here, $(this) just means the element that the handler function applies to (the <select>). And val() is a function that tells us its value. The period in the middle says "For the thing before the period ($(this), the <select>), call this function that belongs to it (val()).

Now we need to tell it what to do for each of the options. Let's start with email:

This new bit says "If the value (that val() gave us) is 'email', find the element with an ID of email_opts, and show it (i.e., make it visible). Next, find the element with an ID of phone_opts and hide it. And the same for the one with an ID of sms_opts."

Now we just do the same for the other two possible values:

For each one, we just show the form we want and hide the others. Notice that we've also got a fourth case here called default.

This is for when none of the others apply. Here, that only happens if the user clicks the "fake" "Contact me via…" option. If that happens, we just hide all three forms.

And that's all there is to it. You can see the finished example here.

If we wanted to flesh it out a bit more, we could wire up the buttons to actually do something. When the user clicks "Submit", we could hide the dropdown and the forms and replace them with a thank-you message. And maybe "Cancel" could clear the form. (More likely, we'd get rid of it altogether.)

This is really just the tip of the iceberg when it comes to what you can do with HTML, CSS, and Javascript. Livetyping, my HTML prototyping course for UXers, will teach you how to do tons more things like this, including more form stuff (highlighting invalid values, for example), drag and drop, animation, and more. You should check it out.

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

The Four-Minute* (HTML) Prototype

2013-10-10T00:00:00+01:00

* OK, that's a lie—it will take you a bit longer than four minutes. But much less than you might think!

Prototyping in HTML has lots of benefits, and many would argue that it's even better than prototyping in a dedicated tool like Axure. For example, you are prototyping in the same material as the finished product, with all the same capabilities and constraints, instead of faking it.

But it's hard to know where to start, and easy to get put off by the perceived complexity. This post will show you that it's not that hard—you can get up and running in a matter of minutes.

Standing on the Shoulders of Giants

The first thing to be aware of is that you don't need to start from scratch. Other people have put a great deal of effort into creating frameworks that we can use to save ourselves lots of time and effort. The two best-known frameworks are Twitter's Bootstrap and Zurb's Foundation. They both do very similar things, so for our purposes, it doesn't really matter which one you choose. (If you're interested in finding out why you might choose one over the other, check out this post.)

I'm going to show you how to make your first HTML prototype using Foundation, because I know it better.

An HTML prototype consists of a bunch of files: HTML, CSS, Javascript, and images. So the first thing to do is to set up a place to put them. I find it quite convenient to put stuff like this in Dropbox, so go ahead and make a new folder there called "prototypes". In here, you're going to want one folder for each prototype, so make another folder called something like "my first prototype".

Now we need to grab a copy of Foundation. Go to the Foundation download page and click Download Foundation CSS (the big blue button under "Default CSS"). Unzip the downloaded file and copy its contents into your "my first prototype" folder. The file called index.html is the one that contains the actual content: what's going to be the actual "meat" of our prototype. If you double-click it now, it'll open up in your browser, and you'll see it's just a Foundation demo file.

We need to get rid of all the existing content so we can replace it with our own, so open up index.html in a text editor. (You can use Notepad (Windows) or TextEdit (OS X) for this, but you're better off with a proper text editor. I like TextMate 2 for OS X (it's free), but there are plenty of free and paid alternatives for both Mac and Windows, such as Coda, Espresso, Sublime Text, Textastic, Notepad++, etc.)

Now find this bit:

Delete everything starting from that first <div> tag all the way down to this bit:

Delete up to and including the closing </div> tag, but leave the <script> alone.

Now we can get to work! But what do we want to make? Foundation has a bunch of ready-made page layouts for things like a news feed and an online store. I could show you how to download one of these and change a couple of things, but I don't think that would really prepare you for making a prototype of your own. So …

Let's Do It Properly

Let's take an actual website and try to replicate it as an HTML prototype. Five A Day is a site that showcases five web design articles each day. Their "Today's Five" page is a good example of the kind of thing we are often called on to design. It's not too technically complex, but it does have a nice responsive design that changes the layout and shows and hides stuff as the screen size changes.

Here it is on the desktop:

And on an iPad Mini:

And finally, on an iPhone:

As you can see, as the screen size gets smaller, the columns get narrower and then switch to a stacked layout. And some of the elements on the page (like the ads) are hidden on a phone-sized screen. Foundation makes it easy to set up our page like this.

Top Navigation

First, let's add that top navigation. After the opening <body> tag, add this:

If you've never made anything with HTML before, this might look a bit daunting. So here's…

A Quick HTML Primer

(If you know a bit of HTML already, you can probably skip this bit.)

HTML consists of elements, which are written by wrapping content in tags ("marking it up"). A tag is the name of an element enclosed in angle brackets. So <p> is a paragraph tag. There are opening and closing tags. <p> is an opening tag, and </p> is the matching closing tag. So a complete paragraph element looks like this:

<p>This is a paragraph.</p>

Elements can be nested inside each other. So we can nest a link (the <a> element) inside our paragraph, like this:

<p>This is <a href="http://
en.wikipedia.org/wiki/
Paragraph">
a paragraph</a>.</p>

<p>This is <a href="http://en.wikipedia.org/wiki/Paragraph">
a paragraph</a>.</p>

The browser displays this like this (indented to differentiate it from the article text):

This is a paragraph.

Here the opening <a> tag looks different from the opening <p> tag—it has an href attribute. This specifies what the link links to (in this case, the Wikipedia page that explains what a paragraph is).

Looking at the chunk of HTML above, we can see that we've got a <div> with two more <div>s nested inside it. (A <div> is just a generic container element.) And each of these <div>s has several links (<a> elements) nested inside it.

The links all have href attributes (though they don't actually link anywhere—the hash character is just there to make sure that the HTML is valid).

And each <div> has a class attribute. We use classes to target elements in CSS so that we can position them and control how they look. In this case, the classes are ones that are defined in Foundation—they tell Foundation how to position them.

One more thing that you need to understand before we get back into it is that there are two different types of HTML element: block elements and inline elements. <div>s and <p>s are block elements, and by default, they get positioned one below the other, in the order in which they appear in the HTML. (You can change it so that they are positioned next to each other instead, which is what we are telling Foundation to do here.)

Inline elements (such as <a>) are inline elements—they are placed on the same line as whatever comes before and after them. So the adjacent <a> elements above all get placed on the same line.

OK, that'll do for the primer, for HTML at least.

This HTML uses Foundation's 12-column grid to split the links in the nav into two groups. The left group is seven columns wide and the right one gets five columns.

Now open the index.html file in your browser. (You can just double-click it.)

It doesn't look like much yet, does it?

Let's add some CSS to make it look a bit better. First, create a new file called 4min.css in the css directory. Now add a second <link> element right after the existing one within the <head> element in index.html so it looks like this:

This tells the browser to use the rules in 4min.css to style the page. Now add this to your 4min.css file:

Like with the HTML above, this probably looks like Greek to you if you haven't played around with CSS before. (If you have, you can skip this bit. And if you're Greek, sorry for the confusion.)

So, here's…

A Quick Two-minute Intro to CSS

CSS consists of rules. (The above CSS contains two rules.) A rule consists of two parts: a selector and one or more declarations.

The selector (the bit at the beginning, before the first curly brace) says which element(s) the rule applies to. This can be an element name (like div or a), an element ID (signified by a hash symbol, for example, #topnav, which is the element with the ID of topnav), a class (signified by a period, for example, .row, which is an element with a class of row), or a combination of these.

So you can have a selector like div.row, which is a <div> with a class of row. Or #topnav a (like in the CSS above), which means any <a> element within the element with the ID of topnav. There are other ways to combine selectors, but let's keep things simple for now.

The declarations (the bit inside the curly braces) tell the browser what styles to apply to the element(s) identified by the selector. There are too many to list here, but they basically tell the browser what the selected element(s) should look like and how it should be positioned.

The format for a declaration is the name of an attribute (for example, background-color), followed by a colon, then the value for the attribute (for example, white or #FFFFFF, which is white expressed in hexadecimal), and ending with a semicolon. So a declaration to set the background color for the selected element to white would look like this:

background-color: #FFFFFF;

The first of these two CSS rules tells the browser to give the element with an ID of topnav (our top navigation) a black background (#000000 is the hexadecimal code for black), top padding of 1.5 rems (that is, one and a half times the width of a capital "M" for the browser's default font size), and bottom padding of one rem.

The second rule makes the text of the links (the <a> element is a link) white, instead of the blue that Foundation gives them, and adds a bit of padding to separate them.

Refresh the page in your browser and you'll see it already looks a lot better:

Except for a couple of things… The black bar should really stretch the full width of the screen. And the links on the right should be right-aligned. These are easy things to fix though.

To make the links go all the way to the right, we just need to wrap them in a <span> element with a class of right, like this:

They're still not all the way over to the right, because we gave all the <a>s right-padding. We can fix this by adding another rule just for these links:

This gets rid of the right padding and adds left padding instead.

The other problem is that the width is being limited by the row class (which maintains a consistent width for all "row" container elements). So what we can do here is nest another <div> within the existing one and attach the row class to that instead of to the <div> with the ID of topnav:

This looks much better:

Header

Next we need to add that header. So after the topnav <div>, add another <div> with an ID of header:

Here, we're using the same structure as with the nav to make sure that the element we're going to apply the styling to (the <div> with the ID of header) is full-width. And within the <div> that actually contains the content, we're using three different heading levels (<h1>, <h2>, and <h3>) to give us different sized text.

There's something else here we haven't seen before: & and —. These are what are called character entities. They let us include characters in our content that can't be easily typed (e.g., an em-dash) or that have special meaning for HTML (like angle brackets, and, like here, the ampersand).

Now add this to the CSS file:

The first rule applies a dark grey background color (#222222) to the header (the <div> with the ID of header) and gives it some padding. This padding declaration is different from the ones we used for the nav—instead of separate declarations for top, bottom, left, and right, this form lets you do it all in one declaration. This one says "add top and bottom padding of 1 rem, and left and right padding of zero".

The second rule has commas in the selector. Each item in this comma-separated list is actually a selector in its own right. The rule applies to all three selectors, so its declarations are applied to three different elements: <h1>s in #header, <h2>s in #header, and <h3>s in #header.

All the declarations do is set the text color to white and make the text centered. Which looks like this:

Obviously, this doesn't include all the fancy webfonts that the actual site has, but that's not really the point here.

Main Page Content

Next, we need to add the actual content. Five A Day's page layout has a column on the right containing ads that takes up about a quarter of the available width. And the other three-quarters is taken up by the five article summaries.

So we need to add another "row" <div> that contains two column <div>s: the first (left) one is nine columns wide and the second (right) one is three columns wide. Actually, there's a bit of whitespace between these two columns, so we'll make the left one eight columns instead of nine.

We need to add an extra class, right, to the second column, because if we didn't Foundation would put it immediately after the left column, with the remaining one column of space to its right.

The two <div>s also get IDs so we can target them in our CSS if we want. (IDs are the right thing to use here, because we can be sure there is only going to be one main content section and one ad sidebar in our page.)

Now we need to add some content.

Let's start with the ads. There are five of them, each with a header, an image, and a bit of text. So inside the ad_sidebar <div> that we just added, let's add five identical <div>s, each with a class of ad_container and containing a level five heading (<h5>, about the right size), an image (a placeholder image served by the placehold.it placeholder image service), and a paragraph of text:

Now it looks like this:

And now the five article summaries. Each of these is just a heading, a bit of text, and a button. But these aren't two simple columns—if they were, the summaries wouldn't line up horizontally:

But they do line up. (Unfortunately, the heading overlaps the button. We'll try and make sure that doesn't happen in our version.) Foundation has two types of grid for arranging stuff like this. With the "regular" grid, you set up rows, and within each row, columns.

The other type of grid (the "block grid") is a bit more flexible—it lets you take any number of items and automatically arrange them into rows, where all you need to specify is how many items you want per row. It's good for when you're not sure how many items you are going to have.

Let's use the block grid here. All we need to do is put our content in list item elements (<li>s) within an unordered list (<ul>), and give the <ul> the appropriate Foundation class. So add content within the large-8 columns <div> so that it looks like this:

The individual items are pretty self-explanatory, except for the buttons, which are links (<a>s) with a class that tells Foundation to make them into buttons. The class that we've given to the opening <ul> needs a bit of explaining though. It tells Foundation to arrange the items in a block grid, with two items per row.

Try changing 2 to a different number and see what happens:

large-block-grid-2:

large-block-grid-3:

large-block-grid-4:

Pretty cool, huh?

Footer

Now let's add the final piece of content: the footer. On Five A Day, this contains a heading, a search box, a bunch of category links, and copyright info and social links at the bottom. We're going to add something similar, except for the links.

On Five A Day, these are in alphabetical order, but arranged in an across-then-down format, which is really hard to parse. We're going to do it properly: down-then-across. If we wanted to do this automatically, so that the content gets arranged into flowing columns containing equal amounts of content, no matter how many items we have, then we'd have to bring in the big guns and do it with Javascript.

But this is just a prototype—we can fake it and do it manually.

So this is what we add:

Whoa! That looks like a lot! But apart from the lists of links, there's not a lot going on here.

We've got the same row and column <div>s that we've already seen. Nothing new there. (But notice how the <div> containing the search button is seven columns wide. We could have made it narrower, but this way we're not required to think… We just make sure the number of columns adds up to twelve, that's it.)

The "Categories" heading has a seach box (an <input> element with a type of search) with a button right after it, on the same line.

The lists of links are just unordered lists (<ul>s) of <li> elements, each of which contains a link.

And after that we have a row containing a horizontal rule (<hr/>) and then the copyright stuff and social icons. Again we're using a span with a class of right, like in the top nav, to tell Foundation to push the icons to the right edge.

And here's the CSS to make it look right:

The first of these rules just sets the backround color of the footer, gives it a bit of padding at the top and bottom, and sets the color (for text, etc.) to white.

The second one sets the color of the "Categories" heading to white. (The first rule doesn't affect this heading because Foundation's CSS sets the color specifically for each heading style, including <h4>.)

The third rule gives the search box a bit of top margin to make it line up with the heading.

The fourth rule does the same for the button, and also removes the underline from the link (see the fifth rule).

The fifth rule makes the links white instead of blue, and adds an underline to them (to override Foundation's CSS, which removes it).

And the sixth rule sets the color of the <li>s to white (if we didn't do this, the text would be white and the bullets would be dark grey) and pushes the bullets inside the element's rectangle (by default it's outside).

Mobile Decluttering

Now all we need to do is make sure that the right stuff gets hidden on small screens. If we look at Five A Day, we can see that when the screen gets down to smartphone size, the ads disappear, as well as some of the links in the top nav.

Foundation's visibility classes let us hide and show stuff depending on the screen size. The hide-for-small class is the one we want to use here. We'll just add it to the column containing the second set of links in the top bar (see the first line)…

… and to the ad sidebar (again, the first line):

Now if you resize your browser window down to phone-like proportions, you'll see that the ads and links disappear:

The finished example is here, if you want to take a look.

Conclusion

I hope that this post has succeeded in showing you that creating an HTML prototype is really not all that difficult. If you use a framework like Foundation, a little knowledge of HTML and CSS will get you a long way.

"But this isn't a proper prototype," I hear you say, "It's just a static web page—it doesn't do anything."

Fair point.

Which is why you'll want to stay tuned for my next post, where I'll show you how to use Javascript to add some interactivity to your prototypes. (UPDATE: Here is the sequel—The Four Minute Prototype: Adding Interactivity.)

If you really want to learn all the ins and outs of this stuff, you should check out my Livetyping course.

And if you like stuff like this, you could do worse than signing up for my newsletter:

Stuff You Can Do in an HTML Prototype that You Can't Do in a Wireframe or Comp

2013-04-07T00:00:00+01:00

Caution: This post includes animated GIFs. Some people find these annoying (especially when, like here, they're not even funny).

There are plenty of good reasons to prototype your designs in HTML. (I posted a roundup a while back. And this post by Leisa Reichelt puts it even better.) But one of the most compelling reasons is that there are things that you can do in a prototype that you simply cannot do in any static deliverable.

Here are a few examples.

Animated Transitions

An animated transition to show that something has been removed makes the change less jarring and makes it more obvious what just happened.

Selection-dependent Inputs

With Javascript, you can easily change the contents of one input control based on what the user selects in another.

Inline Validation

Again, Javascript lets us do things like compare the values that the user inputs and alert them if the values don't make sense. (You could just as easily use it to make such a mistake impossible.)

Drag and Drop

jQuery makes it extremely easy to turn a simple list of items into a list of draggable items.

Responsive Layout

Yeah, yeah, I know—the only people who do this to their browser windows are designers. But the point is, if you build your prototype using a framework like Foundation (other front-end frameworks are available), not only can you lay out your page very easily, that page is automatically responsive—it works on any screen size. (Though it's up to you to make that work in a way that makes sense for users—just letting the content get reflowed doesn't always cut it.)

Conclusion

These are just a few examples of things you can do in an HTML prototype that simply can't be done in a wireframe or Photoshop comp. (There are many more.) Which means things that must be documented to supplement the wireframes/comps. Which means things that are open to interpretation. And to mis-interpretation. If you're not already prototyping in HTML, you should be thinking about it.

If you want to learn how to build prototypes that can do stuff like this, check out Livetyping, the video course that teaches you how to create interactive prototypes using HTML, CSS, and Javascript. (All these examples are from the course.)

The Best of Both Worlds—Mixing Bootstrap and Foundation

2013-04-04T00:00:00+01:00

This site is built with ZURB Foundation, which is awesome. But when I was adding this blog to the site, I decided I wanted the stuff in the right column to stay visible all the time. (If you're reading this in an RSS reader, head over to the blog to check it out.) Foundation doesn't really have a component that does that (except for a sticky top nav bar, which doesn't help me). But Bootstrap does have a component that fits the bill.

You can see the component in action on the Bootstrap site here. As you scroll, the nav on the right gets pinned in place. That's exactly what I wanted. But this is Bootstrap and I'm using Foundation. What to do?

Well, it turns out that lots of things in Bootstrap (such as this) are implemented as standalone modules. (The same is true of Foundation.) Which means you can just grab the relevant file and start using it on your own site. So that's exactly what I did. All you need to do is grab the file and put it in Foundation's Javascript folder. (I just copied it and pasted it into a new file.)

Then you can include it in your page, add one line of code to your $(document).ready() function to attach the behavior to the relevant element, and you're done. Almost done anyway. In the case of this specific module, you need to add a couple of data attributes to the element's HTML and a couple of CSS rules, but nothing too complicated.

I also had to tweak a few things to make it work properly. For example, my footer was really big, and this made it hard to get it to behave correctly, so I made the footer a bit smaller. And because Foundation's grid is more fluid than Bootstrap's, I had to make the element that gets pinned fixed width.

But if you're OK making compromises like these, you can achieve quite impressive results. So if you're already using a particular front-end framework, don't be afraid to borrow from one of the others. It works, and you'll always learn something new in the process.

The Best Framework for UX Prototyping in HTML

2013-03-21T00:00:00+00:00

While I was putting together Livetyping (my online course that teaches UX designers how to create prototypes in HTML, CSS, and Javascript), I used Foundation for the prototype that I showed how to build. But Foundation isn't the only front-end framework out there. So I decided to take a look at a couple of others to see how they compare. Enjoy.

If you're prototyping in HTML, CSS, and Javascript (or just thinking about it), you probably already know that using a framework can save you a lot of time, especially if your design needs to be responsive. (And these days, with a few exceptions, there aren't many reasons to make a design non-responsive.)

But how can you know which one is best, without downloading them all and trying them for yourself? This post aims to save you the hassle by explaining the pros and cons of each from a UX prototyping perspective.

The Contenders

The two most popular frameworks are Bootstrap, originally created at Twitter, and Foundation, created by product design company ZURB. There is also a dark horse candidate called Skeleton, which was created by Twitter designer and former ZURBian Dave Gamache.

What Are These Things, Actually?

All three of these frameworks let you lay out web pages on a responsive grid. This means that you can make your design work well on any screen size. If that's all you need, Skeleton fits the bill. (Bootstrap and Foundation also do this, but they bundle in a lot of extra stuff too.)

But for all but the simplest prototypes, you will almost certainly need more than just layout. The questions you need to be asking are What do we need? and What do we know?

If you need things like tabs, nicely-styled buttons and forms, standardized navigation components, consistent typography, and so on, then both Foundation and Bootstrap come with stuff that makes adding these things easy and fast (and they will look consistent too).

If you know how to do these things yourself (and want to), Skeleton could be the answer.

How They Look Out-of-the-Box

Skeleton

Skeleton on the Desktop

Skeleton on iPhone

Bootstrap

Bootstrap on the Desktop

Bootstrap on iPhone

Foundation

Foundation on the Desktop

Foundation on iPhone

What You Get in the Box

Skeleton

Skeleton gives you a responsive grid, some basic typography, and some simple form and button styling. That's it.

Bootstrap and Foundation

In terms of feature lists, there is a lot of overlap between Foundation and Bootstrap. I won't list them all out here because others have already done a better job than I would (scroll down to UI and Widgets at the bottom of the page).

In short, they both provide a responsive grid, nice typography, improved form styling, and pretty much any UI component that you might see in a modern webapp. So instead of listing them out here, I'm going to point out some of the differences between the two:

Bootstrap comes with a set of 140 (naturally) icons. Foundation does not include icons, but ZURB have created several icon fonts and a set of social icons (as separate products) that you can use.
Foundation has iOS-style switches, which are a nice alternative to checkboxes.
Both Bootstrap and Foundation have visibility classes, which let you show and hide elements depending on the screen size. Foundation goes one step further by adding visibility classes for device orientation and touch support.

This means you can do things like:
- Replicate the pattern seen in many iPad apps, where a sidebar is displayed in landscape mode and hidden in portrait.
- Show affordances on touch devices that usually only appear on hover.
Bootstrap seems to offer more built-in options for styling tables.
Bootstrap includes iPad-style popovers.
Bootstrap comes with animated transitions for fade in/out and slide in/out.
Both Foundation and Bootstrap have wizards that let you customize their framework before you download it. Bootstrap seems to have more things you can customize, which may or may not be a good thing.
Foundation has 13 templates for common page layouts that you can download from their site. Bootstrap comes with eight example pages included in the download.

But maybe the most important difference between the two frameworks is that Bootstrap is much more style-heavy than Foundation. This means that you see lots of sites that are very recognizably built using Bootstrap. For prototyping this may not matter so much. After all, what we are prototyping is not the visual design, it's the layout and functionality. But on the other hand, if the way things look by default draws too much attention to itself, that may be a disadvantage.

As someone cleverly put it in an answer to a Quora question about this:

It is like the difference between buying a custom Lego kit or buying a bunch of Legos on eBay and then trying to build something from the kits that you scrapped together.

Other Factors

Up-to-date-ness

Foundation and Bootstrap are both being actively developed, and new versions are released frequently. Skeleton, on the other hand, has not been updated in months. But since what it does is relatively simple, and because it is not engaged in a feature war with the other two (just the opposite, in fact), this may not matter in the slightest.

Popularity

Now, you don't want to be a sheep and just go with the one that everyone else is using. But popularity does matter. It matters because Bootstrap is attracting people to develop other products that are based on it. And some of those could be quite useful to us.

Protostrap lets you put prototypes together more quickly by using PHP to reuse content. It also includes some enhancements to Bootstrap, including a fake authentication layer, a way to handle missing pages gracefully, an iOS tab bar, a carousel with touch support, more icons, and more.

Jetstrap is webapp that lets you lay out Bootstrap pages visually, without having to write any code.

There does not seem to be anything similar for Foundation yet.

Under the Hood: Less and Sass

Both Foundation and Bootstrap let you work in plain ol' CSS. But they both use a CSS preprocessor that lets you do more powerful things (and keep your code simpler). Bootstrap uses Less, while Foundation uses Sass. If you know what these are and have a preference, this may sway your decision.

Documentation

Another important factor is how easy it is to learn each framework. For this, you'll be relying on the provided documentation.

Skeleton's documentation is understandably sparse. There's not a lot to explain here, but the docs do a perfectly acceptable job of explaining it.

Foundation and Bootstrap both have very good documentation, but I think Bootstrap has a slight edge here.

Conclusions

Is any one of these head-and-shoulders above the others, a clear winner? No. All three frameworks are very competent.

So which one should you use? The answer is a typical, designerly "It depends".

Each one just has a different emphasis, so which one is right for you depends on what you're trying to do.

Do you mind all your prototypes having a similar look and feel? Maybe that's even a positive in your eyes. If so, Bootstrap is a strong contender.

Do you prefer to impose your own look and feel on your prototypes (not necessarily a proper visual design that approximates a finished product, but maybe one that looks more wireframe-y)? Foundation could be the one for you.

Do you have strong CSS and Javascript skills and want complete control over both the way your prototype looks and how it behaves? Then check out Skeleton.

"But which one do you use?" you ask. Well, I use Foundation. Why? Because I started using it before I'd even really heard about Bootstrap or Skeleton or had a chance to try them out.

And now I'm used to the way Foundation does things. I know how to do what I want in Foundation, so even if one of the other frameworks might be "better" for a particular project, I'm probably better off leveraging my existing experience with Foundation and bending it to fit the needs of the current project than to invest the time required to learn one of the others.

But if I was starting from scratch and trying to decide which one to use today, I'd probably discount Skeleton because Bootstrap and Foundation both provide so many useful extras. Using the provided components is much faster than reinventing the wheel and doing it yourself.

What it really comes down to is this: Can you live with Bootstrap's style-heavy approach? And will the same framework be used in production? (This may not be your decision to make…) If so, then it's more work (not for you, but still) to override Bootstrap's styles to make it look the way you want.

When NOT to Prototype

2012-11-14T00:00:00+00:00

As I've been putting together Livetyping (my HTML prototyping course), I've been thinking about situations when you shouldn't prototype stuff (interface elements, interactions, whatever). This two-by-two chart sums up my thinking:

When something is hard to explain, but easy to code, you should code it. When the opposite it true, you should explain it instead (maybe using something like Polypage to add annotations directly to your prototype). These seem to be no-brainers.

But the interesting bits are the other two rectangles. If something is easy to explain and easy to code, what should you do? And what if it's hard to explain and to code? Well, it depends. And the “it depends” is similar for both cases.

It depends on why you want to prototype this particular bit of the interface. Is it just to communicate how it works to developers and stakeholders? If so, explaining is probably the best route.

But if it's so you can test your design with users, it may be worth putting in the extra effort to code it, especially if it is used in any important flows. Of course, if you're in the hard/hard rectangle, you may have to collaborate with your developer colleagues to bring it to fruition. (Thinking about it, this flavor of “it depends” applies to all four scenarios—if it has to be in there for testing, then it has to be in there.)

There are other axes to take into account, of course, such as the relative importance of the thing you're contemplating prototyping, and the novelty of the element/interaction, but I've found this to be a useful tool for thinking about this stuff.

What do you think? Ping me on Twitter and let me know.

Time to Dump Wireframes 2: The Turning Tide

2012-11-11T00:00:00+00:00

If you're still not convinced that prototyping is better than wireframing (even after reading this?!?), here are a couple of great articles that were published recently that you really must read.

In the first, Sergio Nouvel gives a good overview of the pros and cons of each of the different fidelity deliverables that we are used to producing. He then goes on to make a compelling argument for starting out with lo-fi mockups, then going straight to "wireframing in the browser", which has a number of advantages:

With CSS frameworks, basic layout is a breeze.
Your deliverable is responsive-ready.
You can take advantage of what the browser does by nature.
It’s truly interactive.
The scalable nature of CSS enables easy, live changes.
You don’t need proprietary software or a powerhouse machine.
Everything you do saves you time later because you are building the real thing.

Absolutely! Go check it out on UX Magazine.

The second article, by Leisa Reichelt, is a punchy, tour-de-force list of reasons why prototyping beats the pants off wireframing. It's a really quick read—already condensed down to its essence—so I won't ruin it by trying to summarize it here. Just take the two minutes and go read it over on The Pastry Box Project. It's really good.

Happy reading :)

How To: Prototype an Animated Notification (à la Twitter)

2012-11-08T00:00:00+00:00

Tip: Switch to full-screen, otherwise you won't be able to see a damn thing :)

This is a short excerpt from Livetyping, my self-paced video course that teaches you (the UX designer) how to prototype in HTML, CSS, and Javascript.

You can buy Livetyping here.

Recording Mobile Screens—Another Option

2012-10-16T00:00:00+01:00

Recording the screen of a mobile device is not an easy thing. You can build a fancy test rig, with cameras and so on. But it's expensive and cumbersome. There are iOS apps that let you record the screen. But the ones I've seen are either buggy as hell or require you to jailbreak your device.

But today I came across another option. AirPlay lets you mirror your iPhone or iPad's display on an Apple TV. But you can also mirror it on a Mac, using a product called AirServer. The company that created it promotes it as a way to play multi-player games with your friends on a nice big screen.

But with your device's screen mirrored on your Mac, you can use screen-recording software (like Screenflow, Camtasia, or Morae) to record it. Which, for user testing, is pretty damn handy. (The image above was captured from my Mac's screen.)

(Disclaimer: If you use the above link to download and install AirServer, my free trial gets extended by three days. Just so you know.)

Learning HTML Prototyping—Where the Hell Do I Start?

2012-09-03T00:00:00+01:00

OK, so you've read what various UX thought leaders have said or written about prototyping in HTML (or more generally about UXers being able to code) and you're convinced that HTML prototyping is an important skill. Maybe you want to improve the collaboration between you (the designer) and your developer colleagues. Perhaps you want to improve communication with stakeholders. Or maybe you want to get your designs in front of your users earlier.

If you're a freelancer, it could be that you are looking for ways to raise your hourly rate. Or maybe you're an in-house designer who's looking for a better job and who sees the value of having this important skill on your résumé.

But where do you start?

The following is my attempt to show you the alternatives that are out there. I hope it helps you find the way that best suits you.

Disclaimer: I have included Livetyping, which I created. Yes, I think it's great. But I recognize that different people learn in different ways. If self-paced, screencast-based learning isn't your bag, I'm sure you'll find an alternative here.

Workshops

There have been several HTML prototyping workshops run in various locations. A good example is UX Bootcamp's Prototyping in Code, an intensive three-day workshop that has been run twice in London, UK.

Pros:

It's aimed specifically at UX designers.
It's good for procrastinators and others who struggle with self-paced learning.

Cons:

It's a bit pricey (£299, which translates to $475).
It's only any use if you live within a reasonable distance of the venue.
It's not available right now. You'll have to wait for the next one to be scheduled.

Books

Hundreds of books (maybe even thousands) have been written about HTML, CSS, and Javascript. Here are a few notable ones:

HTML5 for Web Designers, by Jeremy Keith
Designing with Web Standards, by Jeffrey Zeldman and Ethan Marcotte
CSS3 for Web Designers, by Dan Cederholm
Responsive Web Design, by Ethan Marcotte

There is also Todd Zaki Warfel's book, Prototyping: A Practitioner's Guide, which touches on HTML prototyping, but does not go into much depth.

Pros:

You are spoiled for choice.
Books are relatively cheap.
There are some great books out there.

Cons:

It's hard to know which books to buy from the huge selection available.
None of them are really tailored for UX designers who want to learn how to prototype in HTML.
Not everybody likes learning from books or has the necessary self-discipline.

Online Video Courses

There are dozens of sites that offer screencast-based courses. For example, Lynda.com has lots of courses on just about any tech-related subject you could mention, including ones on HTML, CSS, and Javascript. There is a lot of good content out there, but most of it is not aimed specifically at UX designers. It's more for people who want to become web designers or web developers.

Pros:

They are typically self-paced, which is great if that works for your learning style.
The cost is usually reasonable.

Cons:

They aren't tailored for UX designers.
You need to do your research to find the right courses.
You end up wasting time learning stuff that's not really relevant for HTML prototyping.

Free Online Resources

Where do you go to find almost infinite resources about web technologies? The web, of course! Again, the quantity of information available is staggering. You can get all the information you need, but there are two problems: finding it, and being able to tell the good from the bad.

A few selected resources:

Pros:

Cons:

It takes a lot of time to find the right resources and work through them. How valuable is your time?

Livetyping

Livetyping is a series of screencast lessons that teach you prototyping in HTML, CSS, and Javascript at your own pace. It is tailored for UX designers and doesn't include stuff that you don't need to know.

Pros:

It's tailored specifically for UX designers.
It's great if you can't dedicate a big block of time all at once.
You can work through it at your own speed.

Cons:

Not good for procrastinators or those who struggle with self-paced learning (though it's probably better than books in this respect).

Conclusion

HTML prototyping is a valuable skill that is in demand. There are many different ways to get this skill—some will suit your own personal learning style and how you value your time better than others. Best of luck!

You can get Livetyping here.

The UX Designer's HTML Cheat Sheet

2012-07-15T00:00:00+01:00

While I was creating my Livetyping course, I realized that HTML5 might look a bit intimidating to some. It has over 120 different tags, which is a lot to get your head round. But in practice, when making interactive HTML prototypes, I only ever use a small subset of these.

So I made a cheatsheet containing just these commonly-used elements. Enjoy!

If you've got any suggestions for improving this cheat sheet, I'm @martinpolley on Twitter.

Livetyping is an online course that teaches UX designers how to make interactive, clickable prototypes using HTML, CSS, and Javascript.

Should Designers Be Able to Code?—Cennydd Bowles

2012-06-22T00:00:00+01:00

In my recent post about why UXers should learn to prototype in HTML, CSS, and Javascript, I missed out the one person whose opinion prompted me to write the post in the first place.

In April, Andrew Travers and Matthew Solle interviewed Cennydd Bowles for the London IA podcast. They asked him whether he is "a unicorn that codes" and whether he thinks that it is something that's important. Here are the edited highlights of his reply. (In the original audio, this bit is from 17:44–20:18.)

I firmly believe that it's a strong benefit to a designer who is working on the web to know HTML and CSS. They're not difficult, they really aren't. Javascript optional. If you know the basics of Javascript, if you know how to, you know, thrash around a bit of jQuery, then that's definitely going to be helpful for prototyping and so on.

There are two reasons, I think, why I think it's useful to be able to code as a designer in our domain. The first is it gives you an understanding or an appreciation of what's possible. And equally, what might be possible in six months' time, or what might be possible if you're able to kind of poke the developers hard enough and say "Go on—you can do it! Let's find an innovative solution."

The flipside of that is also that you know enough to call a developer's bullshit. I love developers and I miss working with them as closely as I used to. But I think they would admit that occasionally they can be a bit obstructive, if they feel they've been left out of the loop or if they're being forced to, you know, do something unreasonable in a silly timescale. And there can be sometimes a strain of the developer community that says "No—can't do that. Nope, not possible. Have to go away and do it again."

If you know your stuff, and you say "Well, actually, I've got a jQuery plugin here or something that can do that for you," I've already saved you half the effort, then sometimes that can help realize your design—get past that kind of resistance.

The second reason why I think it's desirable to be able to code is simply just because it helps the design process. Particularly for interaction design, I'm a big fan of trying to design within the medium. Now I don't mean design in the browser—that's maybe something we could talk about later—but I'm not a big fan of that, in terms of visual design and layout and so on. But I am a big fan of it in terms of the interaction design—how things respond to input.

And I think the sooner you can get that kind of design into its native state, be that on an iPhone, or on a telly, or in a web browser, then you can get a better understanding for whether it feels right, because so much of interaction design is about feel and rhythm and flow. The only way really to get that in front of people is to try and prototype it yourself. And I find HTML prototyping really adds something to what I can do. It helps me make the right design decisions, because I can get those interactions out, I can get them tested, and then I can iterate on those quickly.

Livetyping is an online course that teaches UX designers how to make interactive, clickable prototypes using HTML, CSS, and Javascript.

Time to Dump Wireframes

2012-06-18T00:00:00+01:00

Most of the work we do as UX designers is either for the web, or related to it in some way. The things that we design are often web sites or web applications. And even if they aren't, web technologies are finding their way into more and more things: native iOS apps, Android apps, even desktop software.

And the web is a-changin'. Gone are the days when all you needed was a desktop web site or application with a fixed width of 960 pixels. These days, there is a vast range of different devices and screen sizes that you need to think about. And that range is only going to keep getting bigger.

If you're still using static wireframes to design this stuff, you are doing yourself (not to mention your client, employer, and/or colleagues) a great disservice. Wireframes just aren't up to the job of showing subtle interaction details—the things that make the difference between an application that is a delight to use and one that frustrates and annoys.

And even if you're using a more sophisticated prototyping tool, you're still not doing yourself any favors, because these tools don't allow your designs to adapt to the multitude of different screen sizes that are out there.

Many of the most respected people in our industry have been voicing the opinion for some time now that designers need to be able to code and that prototyping in HTML, CSS, and Javascript is a Good Thing. This article highlights some of the arguments they have been making.

37signals have been vocal proponents of this approach. In this post from back in 2008, Jason Fried explained why they don't make mockups in Photoshop, instead preferring to "go right from a quick paper sketch to HTML/CSS."

In an interview with Johnny Holland magazine in 2009, Todd Zaki Warfel, author of "Prototyping: A Practitioner's Guide" gave some compelling arguments for prototyping.

I can also give our clients examples of how prototyping enabled us to uncover hidden problems, explore design solutions, and make informed decisions prior to launch that we simply couldn’t have done without prototyping…

Prototypes are about show and tell. They’re a visual way of communicating the design of a system. First and foremost, they communicate your design…

In nearly every case in the past three years, prototypes have become our documentation. … It still takes less time to build a prototype and write a 20 page supplemental spec than it would to write a 200 page spec and get consensus on it.

Any design based on a written spec is a design based on theory. A design based on a prototype is a design based on experience and practice.

I think another significant insight is that reactions we get to from our prototypes from clients and customers is far beyond anything we were ever able to achieve with wireframes and static Photoshop visual comps.

… my preferred prototyping tools are paper, pencil, pen and HTML/CSS with JavaScript.

In 2010, Aza Raskin wrote a blog post that also touched on the subject.

The most powerful tool for creating empathy as a designer is prototyping. It meets the rest of the team half-way, is the second most persuasive artifact (the first being a narrated video of the prototype), and gives you a sense of what’s hard and what’s easy to implement. Having thought through the edge-cases and being able to speak an engineer’s language gives you street cred. You don’t need to be a great coder, but you should at least be able to get your idea across in in HTML and Javascript.

To design is to inspire participation. To do that, you need to be respected. For that, you need to be a designer-coder.

In May of 2011, Jared Spool wrote the post that really opened up the can of worms.

Interestingly, it isn’t the designers who get to decide if coding is a valuable skill. It’s the hiring managers. And right now, based on today’s jobs market, it’s pretty clear where they stand. Many want to hire super designers—designers who can also code.

… those designers who have proven, practiced coding skills can demand a higher salary than those who don’t.

This provoked a flurry of responses. Matt Nish-Lapidus added to the career and team fit aspects that Jared covered:

I firmly believe that in order to do good design the designer must work with their materials. We can’t continue to just make pictures and flat representations of the things we’re designing. There is a time in the design process for making pictures, but it should be about generating ideas and refining them. There is no way to know what your web site, app, or other software, will actually be like without making a realistic version of a working interface.

Jenifer Tidwell agreed with most of Jared's arguments, but cautioned that "organizations often value coding skills more than design skills. And when that happens, and you have two skillsets, which one do you think will get used more? Yeah."

Nathan Curtis of EightShapes recorded a podcast with UIE around this time, and made a great point about the start-up cost of prototyping.

… once that start-up cost has been paid, whether it’s a day of prototyping or even a four hour chunk here, a six hour chunk there. Then things start to really move quickly. That’s in part because our ability to re-use and re-factor different things becomes a lot easier. As opposed to, "Well, you want to make the header twice as large." In HTML we just change the height from 50 pixels to 100 pixels.

But in a wireframe, suddenly we’re caught going into 16 different files, having to move everything else on the page down, and all of those seemingly subtle changes end up costing a lot, too.

Jack Moffett brought up an important point—knowing how to code increases your scope of influence.

So for me, the ability to code is less about earning “cred” and communication, although I’m sure it has helped with both, and more about dependency and scope of influence. I am less dependent on the abilities and attention to detail of the developers, and I now have greater influence over the entire course of a project. As a result, the final product is better.

These posts also sparked interesting debates on the IxDA mailing list and on Quora. Despite a few dissenting voices, most seemed to agree that being able to code prototypes is a valuable skill for a UXer.

So now you're convinced that you need to be able to prototype in HTML, CSS, and Javascript. But where do you go to learn this stuff? Most of the information available on the web is aimed at web designers. Much of it is irrelevant for our needs.

A number of workshops have been put together to teach UX designers how to code, but they're only any good if you live close enough to the venue to attend. There are short webinars available that show you the why, but that aren't long enough to go deep on the how.

Now there is a better alternative. Livetyping lets you learn at your own pace, wherever you are. It assumes no previous knowledge of HTML, CSS, or Javascript. And it's tailored to the needs of UX designers. You won't waste any time learning stuff that you don't need. By the time you're done, you'll be able ditch static wireframes and lengthy spec documents and replace them with lovely, shiny prototypes.

Livetyping is now available! Go check it out.

Do Tools Matter?

2011-03-14T00:00:00+00:00

Michael Angeles has an interesting post over at konigi.com about how our tools are not important.

"Don't let anyone tell you that the tools you choose are wrong or inappropriate. Find the right design and keep winning."

This got retweeted a lot. I read it and found myself agreeing. I even retweeted it myself. But since then I have been thinking about this a fair bit. And now I'm not so sure.

I think he's missing something by only talking about one side of the tool question. The side that deals with working through a design. As he writes, "There are no good or bad tools for finding the right design." But there is another side to this. And that is concerned with what we do with the things we create using our tools.

And there I think there are not insignificant differences in fit between the actual deliverable and the thing we want it to do for us. As Bill Buxton has said on many occasions "Everything is best for something and worst for something else." And we use the deliverables that we create for several different things: To show to our designer colleagues for the purposes of collaboration and critique. To show to stakeholders, for the purpose of getting buy-in. To share with our developer colleagues so that they will know what to build at the required level of detail.

A wireframe is good for working with design colleagues. A video walkthrough may be the best thing to show to stakeholders. And a high-fidelity HTML prototype may be better for communicating to developers than an annotated wireframe.

Maybe I'm stating the obvious here. What do you think?

Better vs Familiar

2010-08-14T00:00:00+01:00

While reading #1 here (which recommends using familiar user interface paradigms for learnability), I couldn't help thinking about Loewy's MAYA principle (most advanced yet acceptable) and this from Dieter Rams:

Things which are different simply in order to be different are seldom better, but that which is made to be better is almost always different.

We need to strike a balance, but would should keep Rams and Loewy in mind as we do so.

My iPod Is Ignoring Me (and I Like It)

2010-08-04T00:00:00+01:00

I just noticed that sometimes, my iPod Nano ignores my commands.

The play/pause button plays or pauses when you press it. A long press of the same button turns the iPod off. But what if my press is not quite long enough?

Well it turns out that the iPod is designed to ignore my ambiguous command, rather than risk doing the wrong thing. Did I mean "pause"? Or did I mean "switch off"? Interpreting this wrongly could be quite annoying.

So ignore me. It's a good thing sometimes.

Dusty Digital Albums

2010-07-21T00:00:00+01:00

I was thinking about how we relate to our music. And specifically how this has changed with the move from physical media (vinyl, tapes, CDs) to digital music that has no physical manifestation.

In the old days (eight, ten years ago) you would have CDs on shelves. Maybe some old tapes and vinyl albums in a box somewhere too. Your CDs might have been organized alphabetically. Or maybe by genre. Maybe even by color.

But if you are like me, the stuff that you listened to most often would be the most easily accessible (for me, that means the top shelf). The stuff I listened to less often (or never) would be on the lower shelves. And some would even be in a box in a cupboard or in the attic, gathering dust.

But these days we have iTunes. And all your albums are there, on an equal footing, as it were. Sure, you can order stuff by number of plays or date last played, but it's not very elegant. (Try ordering by plays and see what a mess it makes of cover flow—it doesn't show an album once, but once per song.)

Maybe we could take a cue from the physical world, as Apple is urging us to do when it comes to designing iPad apps. Perhaps cover flow could have shelves.

The top shelf would contain the albums you have listened to the most, but somehow taking time into account too. An album that I listened to continuously for two months three years ago but have hardly listened to since would drop down to the second or third shelf. Maybe an album like this would accumulate a layer of dust, which I could choose to blow off now and again by listening to the album.

And why limit it to music? Why not books as well? Why not movies? Why not games? And what about documents? Spreadsheets even?

Transitions and States

2010-03-24T00:00:00+00:00

Wow! Buxton was right. The transitions are just as important as the states (if not more so).

As I play around with jQuery (+HTML + CSS, obviously) as a prototyping tool, I'm finding that I really need to play around with the details of the transitions to make it obvious what is happening (something that it is hard to do in my head, for me at least).

For example, in my prototype I have a thing where you can add new rows (like adding attachments in Gmail). But I'm constrained for vertical space—there's only space for four rows. So I have set it up so that when there are more than four rows, this part of the screen gets a scroll bar.

Having a newly-added row simply appear works fine when you have unlimited space, but with scrolling it gets awkward. What happens if the new row is out of view? Well, we should automatically scroll so that this new item is visible. But this kind of sudden transition is a bit jarring and disorienting.

I found that animating the addition of the row and the automatic scrolling makes it much more clear what just happened, and where things have been moved to. (I must just stress that this is animation done sparingly and not for its own sake.)

What did I learn? That when you're at the prototyping stage, you really need to roll your sleeves up and get your hands dirty to find out exactly how to best handle subtle transitions like this.

Fitts's Law for Asymmetric Targets (Like Tabs)

2009-06-29T00:00:00+01:00

Since I started putting together my entry for the Mozilla Labs “Reinventing Tabs” challenge, I have been thinking about Fitts’s Law. Here’s what I have been thinking: does the shape of the click target affect the ease of acquisition?

More simply put, is it easier or more difficult to acquire a rectangular target that is (say) three times as wide as it is high than a square target of the same area?

And also, does the orientation of the rectangle make it easier or harder to acquire? (That is, does it make any difference whether the rectangle’s long side or short side is facing towards the pointer?)

Why does this matter? Well, if you have a bunch of tabs stacked up the left side of the screen (as in my entry), the answer could mean that they are easier or harder to click on than regular tabs of the same size that are strung out horizontally above the content area.

And now I have found a paper that contains the answer. At least, it contains the answer to the second part of my question (about orientation).

If you want to read it, go ahead, but here is the money quote:

... when possible graphical widgets should be extended along
the more frequent movement direction. ... horizontally enlongated widgets, which are often due to the labeling in English words, should be placed on the left or right rather than the top or bottom edge of the desktop interface.

But there is a caveat:

However, the average horizontal movement distance is somewhat longer due to the landscape display geometry in most computers.

In plain English, tabs that are stacked at the side are easier to acquire than ones of the same size and shape along the top. But because monitors (especially modern wide-screen ones) are wider than they are high, this advantage may be mitigated (or even outweighed) by the extra (average) distance that the pointer must cover.

The Livetyping blog

Bootstrap: not the solution to every problem

How to deal with the fiddly shit

The Easiest Way to Set Up a Static Prototype/Site

Which designers should do what?

Start learning to code... and why maybe you shouldn't

Can You Prototype Native Apps in HTML?

The UX Designer's CSS3 Cheat Sheet

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

Just put less stuff on the page.

Just hide stuff

Accordion

Teasers

The How

The Specifics

Hiding stuff

Teasers

Accordion

Conclusion

Sign up for the newsletter

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

How to Steal

How ideas spread

Finding good ideas

Using a good idea

The web makes stealing easy

Stealing: a practical example

Enjoying your ill-gotten gains

Sign up and get a free sample lesson by email

Sharing Is Caring: the Best Ways to Share Your Prototypes

Emulators

Adobe Edge Inspect (and similar tools)

Dropbox

Use an online code editor

GitHub Pages

Amazon S3

Other options

Privacy

And the winner is…

Sign up and get a free sample lesson by email

Wind of change: are we finally starting to agree on how UX should be done?

Forms—The Complete Guide—Part 4: Selection-dependent Inputs

Responsive enabling

Responsive disclosure

More complex scenarios

Be lazy.

Learn a few key things in JavaScript/jQuery.

Look stuff up.

Don't be afraid of doing it "wrong".

Conclusion

Forms—The Complete Guide—Part 3: Grouping and Inline Help

Grouping

Inline help

Automatic inline help

Our "form": page structure

The actual form

JavaScript: show help on focus

JavaScript: hiding help when the selector loses focus

JavaScript: show help on hover too

JavaScript: actually, don't hide it when the hover ends, in this one specific case

User-triggered inline help

Adding an icon

New JavaScript for new behavior

Bonus learnings! Or I came for the forms, but stayed for the RWD

Conclusion

Forms—The Complete Guide—Part 2: Input Types

Input types

Text and its variants

Text

Password

Email

URL

Phone number

Number

Autosuggest

Other types

The rest

Checkboxes

Radio buttons

Sliders