capcloud | Martin Polley

Learning HTML Prototyping—Where the Hell Do I Start?

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:

• http://diveintohtml5.info/
• http://www.codecademy.com
• http://www.w3schools.com/html/default.asp
• http://css-tricks.com/

Pros:

It doesn’t cost anything (except time).

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.

Or sign up below for news about Livetyping, HTML prototyping tips, and more.

Livetyping Is Live!

Livetyping, my video course that teaches you (the UX designer) how to prototype in HTML, CSS, and Javascript, is now available!

So if you’re ready to start improving collaboration with your developer colleagues, communicating better with stakeholders, and getting your designs in front of users earlier, you should sign up.

Oh, and did I mention that designers who can code are in demand and can make more money than ones who can’t? Well, now I did.

The UX Designer’s HTML Cheat Sheet

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.

The course will be launching very soon. Sign up and I’ll let you know when it’s about to launch.

On Academic Achievement

matthasafaceforradio:

“It really troubles me when people use academic achievement as a means of measuring intelligence. You’re basically saying that somebody who is able to successfully jump through hoops and be submissive to authority is the height of intelligence, rather than looking at somebody’s capacity to think independently and creatively. I think that you can tell a lot more about somebody’s level of intelligence by sitting down with them and having a five minute conversation rather than looking at some letters on a piece of paper which, essentially, are meaningless.”

— Source (via -retrograde)

(Source: -retrograde, via mantocaveman)

Should Designers Be Able to Code?—Cennydd Bowles

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.

The course will be launching very soon. Sign up and I’ll let you know when it’s about to launch.

Time to Dump Wireframes

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.

Progress?

So anyway, I haven’t done much on my webapp lately, but now I’ve decided to pull my finger out. I originally started playing around with Google AppEngine for the back-end, but I realized a couple of things.

First, I’m not going to get very far, nor learn very much, just by copying and tweaking Google’s example code.

Second, using AppEngine ties you in to Google. You can’t easily move elsewhere. So I figured I’d be better off not going that route.

So I’ve decided to take a step back and refresh my programming “skills”. On the recommendation of my friend Idan, I’m working my way through Learn Python the Hard Way. Which I’m rather enjoying. It’s not really a Python book. It’s more like an introductory programming book that happens to use Python.

We’ll see where it leads…

Bookmarklet, Part II

That bookmarklet is shaping up quite nicely. Shame it doesn’t actually do anything yet :)