The new Handcraft is here!

Category → HTML prototyping

HTML prototyping: because the details matter

This week we headed to Brighton in England to give a talk at a UX Brighton event about “Practical Prototyping”. Our talk focused on a couple of topics we’ve talked about on this blog over the past year:

  • Wireframing and prototyping are two different things, even though a lot of people use them interchangeably
  • HTML is a great way to do prototyping because it allows you to focus on the details
  • Handcraft is a great way to do HTML prototyping because it was designed specifically for it

We also decided to create the slides in HTML using Google’s HTML5 slides library. This allowed us to prototype the presentation with Handcraft. Can’t get enough of that dogfood! ;-)

Check out our talk, HTML prototyping: because the details matter – to navigate through the slides, you can use the space bar, the directional keys, or just click on the next/previous slide.

If you came to our talk, we’d like to invite you to try out Handcraft and if you like it, we’ll give you 3 months of the paid version for free so you can dig in. Just send us an email or a tweet and we’ll hook you up.

UX Bootcamp: Prototyping in Code

User experience designer Leisa Reichelt recently tweeted her discomfort with prototyping tools:

Increasingly frustrated by prototyping tools. May have to do HTML5/CSS3 self imposed boot camp after all.
@leisa
Leisa Reichelt

Leisa’s not alone in wishing she could write better HTML & CSS so she could just do prototyping in HTML: designers who code is a growing trend that more and more UX professionals are becoming familiar with.

But learning how to code remains something you need to invest quite a bit of time into. Perhaps that’s what’s been stopping Leisa and others from becoming expert HTML prototypers.

Thankfully Leisa is also pro-active: she’s taken it upon herself to organise a UX Bootcamp program. The first session, Prototyping in Code, is intended for designers who want to pick up the basics of HTML and CSS for prototyping purposes and will be taught by Alex Morris, Anna Debenham and Peter Gasston.

It’s in London from July 22nd to the 23rd and is preceded by an introductory day for designers who’ve never written a line of HTML in their life called Code Fitness. Tickets for the 22nd & 23rd are £299 (excluding a fee) and £149 for the 21st. Sign up here.

Knowing how to code helps you write better prototypes

UIE’s Jared Spool posted a follow-up to his “Why the Valley wants designers who can code” post, which we wrote about last week. His new article, which he says will be the last from him on the topic for a while, covers 3 reasons why designers should learn how to code. His second focuses on prototyping:

Knowing how to code helps you produce better prototypes. The best way to communicate a design idea to your teammates and clients is through an interactive prototype. Producing your own quick prototypes brings your ideas to life sooner, releasing that inner brilliance you’re carrying around and helping everyone see what your designs are really about.

The implication here is that interactive prototypes should be written in code. So by Jared’s definition, an interactive prototype can’t be, for example, an Axure prototype, or a Keynote wireframe with click zones. It has to be code.

We agree. You should handcraft prototypes in HTML. You’ll learn more about the medium you’re designing for, be able to anticipate constraints and possibilities more ably, and become a better designer overall.

See all three reasons why learning to code makes you a better designer over at UIE.

Great prototyping advice: Fail early, fail fast, fail often

Wanna Create A Great Product? Fail Early, Fail Fast, Fail Often is a great article today in Fast Co. Design magazine about the need for prototyping, how not enough people do it, and an overview of various approaches you might consider. For high-fidelity prototypes, Jeremy Jackson has the following advice:

High-fidelity prototypes can take a variety of forms: They can be coded as working HTML, CSS, and Javascript interfaces, or they can manifest themselves as non-interactive motion studies. Choose the technique that best tells your solution’s story and allows to you test any weaknesses in the system.

And there’s a great anecdote here, too:

Thumbplay, a “cloud”-based streaming music service, partnered with Method to design their next-generation app for Web-enabled televisions. Method’s designers and technologists worked together closely to create a fully animated, true-to-life prototype that allowed user testing of key service features and history states. The prototype was easily shared and demonstrated through a Web browser and, ultimately, proved instrumental in validating a number of visual and user-experience design decisions and creating a successful service.

This just goes to show how high-fidelity prototypes really allow you to get as close to the real experience of the final product as quickly as possible.

Read the full article for Jeremy’s tips on how to integrate prototyping into your development process and some awesome quotes by James Dyson and Thomas Edison.

Prototype iOS games in the browser with ImpactJS

Googling for HTML5 game engines returns an ever-growing list (a list that even includes my own multiplayer adventure game engine Sarien.net). One of the more promising engines is ImpactJS ($99). Not only does it allow you to create some pretty cool HTML5 games like Biolab Disaster or Drop, but you can use the browser as a prototyping environment for developing games that run natively on the iPad or iPhone. But this time in ludicrous-speed.

Biolab Disaster. A game built in ImpactJS.

Biolab Disaster. A game built in ImpactJS.

Continue reading →

How the BBC feels about rapid prototyping

In 5 Lessons from Beyond the Polar Bear, BBC information architect Mike Atherton lays out how domain-driven design has changed his and the BBC’s perspective on designing the user experience. Many of his points represent the shift towards designing the holistic experience that web designers are going through at the moment, and late in the article he even goes so far as referring to them as “information experience design architects”. Continue reading →

Tweak, don’t pivot

Back in March we wrote a short post called The Influence of Unintended Use, which highlighted our growing concern over how some people were using Handcraft.

Continue reading →

Slides from our talk at Mangrove

Earlier today we gave a talk at full-service web dev company Mangrove about Handcraft and the way it fits into the production process as a HTML prototyping solution. We thought we might share the slides here.

Fidelity compared with functionality in a graph. HTML prototyping is a line drawn between wireframing (bottom left) and end result (top right).

HTML prototyping lies at the crossroads of two approaches towards developing a website: fidelity and functionality. The higher the fidelity, the more definition and resolution something has, and the more it communicates. But at the same time, websites are interactive and expose some kind of functionality. We compared the two and set out traditional processes (design, wireframing, development and the final result) along two axes. HTML prototyping (and by proxy, Handcraft) is a convenient path between these points.

See the slides below – slide 7 gives you an overview of the above (NB: some of the slides contain some Dutch!)

Many thanks to Mangrove for letting us come over and talk about Handcraft!

Scatter – Ajax without coding

Asynchronous Javascript and XML. With a mouthful of technical geekery, the term AJAX is actually pretty lame (no offence guys) as it mystifies a process that could’ve been described as something my mum would understand:

“Replacing webpage contents without doing a full page reload”.

Sure, Ajax can do a lot more than that, but for the sole purpose of dynamically refreshing parts of a webpage you still find yourself getting jQuery and doing javascript coding.

We think that shouldn’t always be necessary, especially when building an HTML prototype.

Continue reading →

Listen to the ‘i’ in Team

When a development team is made up of different specialities, one or more members are usually responsible for writing top notch quality HTML and CSS. Even though the common goal of the team is to build a kick-ass app or website, the individuals making up the team don’t always have the same path or means to get there. And as there is in fact an ‘i’ in Team, here’s our real life example of why you should listen to this individual and use the right tool for the job.

There is I in "team". Courtesy of Jaco Haasbroek.

There is an 'i' in Team. Courtesy of Jaco Haasbroek.

Continue reading →