Prototyping in the Browser

Celý článek

Prototyping animations and interactions is vital for a number of reasons: they can make your interface feel deceptively fast, they can help focus the user on a specific task, and they can provide a better sense of the current state of your application. Is data being loaded? Is something now unclickable? How long do they have to wait until they can perform an action?

At Gusto, I’ve been working on a lot of tiny interaction details and prototypes lately for these very reasons — sadly there’s not much that I can show you all in detail just yet. But, I think the process of how I’m doing this is far more interesting than what I’m actually working on so that's what I'm going to share here.

The problem I’ve faced with prototyping animations comes down to the tools because they ultimately feel restrictive to me. Whenever I’ve experimented with them in the past, I feel like one hand is always tied behind my back. It could very well be that I’m not using them correctly, but I feel that none of them really mimic browser behavior quite right and, although I’ve been fascinated to watch tools like Framer, Marvel, Zeplin and Principle gain traction, I don’t think they’re for me. At least not yet anyway.

In my opinion, the best way to prototype a lot of interactions is still with plain ol’ HTML, CSS and (gasp!) a sprinkle of jQuery when I need it.

How I’m prototyping today

With my recent project, I decided to invest a little bit of time into CodePen to help our design team quickly prototype things. Here’s what I built:

See the Pen Gusto Prototype: Header by Robin Rendle (@robinrendle) on CodePen.

No really, that’s it. It’s just a simple prototype that looks like our app.

It’s a pen with all the HTML for the app navigation — and it contains all the CSS, too. This way, a designer at Gusto can fork that pen and start writing HTML and CSS to experiment with a specific bit of UI without all the added pressure of having to write production code. It’s important to note that this prototype isn’t for figuring out UX, as tools like Figma and Sketch do a much better job of that. Prototypes like this are mostly useful when figuring out finicky UI interactions like tables, spreadsheets and dropdowns — components that can get complicated real quick.

To make this prototype, I simply copied and pasted all of the HTML and CSS from our web app into a new pen. (In the future, we should probably have a system where we’re always prototyping with the latest up-to-date code from our app but, for now, I think this is a fine starting point.) This pen contains all of the menu and navigation items we need to make it look like the Gusto app. We have a a separate pen for the footer which closes off all the divs that we open up in the header. Lastly, we have one more pen that imports those two other pens like so:

<!-- HEADER -->
[[[http://codepen.io/robinrendle/pen/481a88853820067752e28cdb479c91f3]]]

<!-- HTML GOES HERE -->
<h1>App Prototype</h1>
<p>You can fork this pen and write all the HTML and CSS you need to prototype interactions and explore ideas right here in your browser.</p>

<!-- FOOTER -->
[[[http://codepen.io/robinrendle/pen/0dcaa93954f06f4d03b7e23e8ea54cac]]]

See the Pen Gusto Prototype: Full by Robin Rendle (@robinrendle) on CodePen.

What’s that weird syntax with all the [[[ ]]]? That’s the HTML Include syntax for CodePen. If we put the URL of a pen in between those brackets, CodePen will fetch the code from that pen and place it straight into this new pen. That’s it! Pretty sweet, right?

To wrap things up, I wanted to make a couple of notes about what I’ve learned with this new setup.

Lesson 1: Prototypes should be super easy to share

Ideally, prototypes are easy to share with other designers and engineers, exceptionally fast to get setup, and don’t require prior training or expertise — and Codepen is perfect for that. I like this setup for a bunch of reasons. For one, we don’t have to teach designers CoffeeScript like we have to with Framer and we don’t have to run React or Vue workshops to get them up and running with a complex prototyping app.

Yes, folks do need to learn how HTML and CSS works to make prototypes like this but I think learning the very basics of those two languages is vital for a designer working on the web anyway.

Lesson 2: Bad code is a-okay

Here’s another thing I recently learned while doing prototyping: bad code is okay at this stage. In fact, we should be writing terrible, unforgivable code when prototyping in the browser. We ought to write the sort of CSS and HTML that would keep Harry Roberts up at night because clean, maintainable code gets in the way of the design process when the focus should be on iterating as quickly as possible.

To be quite honest, I don’t care about front-end best practices when I’m making these prototypes — I don’t think about BEM, semantic HTML or even performance. Oh, and I certainly don’t care about the most proficient way to render a React thingamijig.

As long as we ditch all of that prototype code and start from scratch later, and as long as there’s step to break the design into components and ensure that those lego pieces are maintainable, well documented, and highly performant in our production environment, then I believe that writing bad should not only be allowed, but actively encouraged.

This leads to my final takeaway.

Lesson 3: Designers and developers should always translate their code

I reckon that the first time a designer and/or front-end developer writes code, it should never be in a production environment. Having the leeway and freedom to go crazy with the code in a safe environment focuses your attention on the design and making it compatible with a browser’s constraints. After this, you can think about grooming the code from a hot, steaming heap of garbage into lovely, squeaky-clean, production-ready poetry. Translating the static mockups into an interactive prototype is the first step, but it’s vital to have a next step to enforce your code standards.

Does your app use BEM? How should you abstract each of these components into separate files? What do you call all of these new components that you’re introducing into the design system?

I believe all of these questions are easier to answer once you have that interactive prototype. And I would highly recommend that designers and front-end engineers alike experiment making little tools like this. It might feel a little odd at first, but I promise that it will produce much better work in the long run.

The post Prototyping in the Browser appeared first on CSS-Tricks.