So you’re a designer or UX professional, and you work with the web. Everyone’s telling you that you need to learn how to code: at a bare minimum, to gain a rudimentary understanding of HTML and CSS. And they’re probably right! After all, if you’re involved with making things for the web, it doesn’t hurt to get your hands a little dirty in the stuff it’s made of. Yes, coding can be intimidating, but have no fear. There’s a nice, easy place to get started: wireframes.
Wireframes have an important place in the design process. They allow us to make key content, UX, and information design decisions without investing premature effort in refining look and feel. But in a responsive design process, the old black and white PDF can quickly become a cumbersome, misleading, throw-away deliverable. Which is why creating wireframes in HTML and CSS can be a great move for you and the project stakeholders.
Now before you start breathing into a paper bag, let’s get something straight. No one’s expecting you to become a web development wizard overnight. Wireframes are stylistically dirt simple, so building them in HTML/CSS is a lot easier than marking up a fully-designed web page. OK, ready? Deep breath—here we go!
First things first: strategy
Like every project, RWD wireframing needs some degree of research and planning. Ideally, your IA work will be fresh on the heels of some great content strategy, setting you up with a plan for real content, information hierarchy, and user workflow.
Once you know what view you’re going to wireframe (homepage, internal page, etc.), get with your writer or content strategist and figure out what the words are going to say on that view. You want the real ideas and words that will end up on the live site (or as close to it as you can get at this point). It would be a shame to come up with all these fancy layouts if it turns out there isn’t content for them to support in the first place.
Meaningful markup
Now that we have content, it’s time to write some semantic HTML! Remember that when you’re first marking things up, visuals aren’t important: don’t make something an h5 just because it should be small. If it’s the second-ranking heading on the page, make it an h2—later, we can make it look smaller with CSS.
In fact, don’t even look at it in the browser yet. Just make the markup beautiful. Make sure the structure is meaningful, and write only as much markup as you need, and no more. Writing really good semantic HTML is a fine art, a perfect balance between accuracy and simplicity.
Once the markup makes sense to you, grab a front-end buddy and get their opinion on things. Getting even a casual peer code review before you write any CSS can save you a lot of heartache down the line.
Talking through your markup decisions has additional benefits, too—it helps keep you and your team members on the same page about style choices. It gives you the benefit of each others’ experience, and naturally moves your team toward a consistent approach. Since you never know who’s going to be working on that code later, it really helps to have a common understanding of why you’re doing things the way you do.
Start your styling engines
Once the content is marked up, you can move on to small screen styling with CSS. Keep the aesthetics to a minimum: a grayscale color palette, basic web-safe fonts, some rules, a generic interface icon set, and a handful of crossed-out FPO images. No need to get fancy, just make it obvious what everything is, and get that information hierarchy clear as a bell.
After you have the smallest screens looking good, moving to paper sketches can be an efficient way to iterate with wider-screen layouts. Quickly jot down how you think that mostly single-column mobile hierarchy is going to shift as the browser expands in width.
The grid system is your friend to aid in quick decisions and “trying things out.” Lots of people like off-the-shelf solutions like Zurb’s Foundation, or you can roll your own like we did at Bearded with our starter-kit, Stubble.
Implementing design patterns
When thinking about what the design will do at various viewport widths, consider the groupings of elements in front of you. How does the navigation work? Is it all one thing, or is it broken into segments? Is it horizontal or vertical? How many nav items will you have to squeeze in there? What else will it be sharing real estate with?
Next you might consider if the site requires a search function. How does that work? Does it have filters, or is it a simple single-field search? Will users need a button to initiate the search request? These sorts of questions will help lead you to more natural, effective layout decisions.
Implementing these elements can be made easier with design patterns (something the ever-inquisitive Anna Debenham discussed recently in her post Getting Started with Pattern Libraries). And when you’re considering the many responsive design patterns that are at your disposal, you don’t have to recall the myriad options on your own. Brad Frost has you covered with his responsive pattern library.
Keep working your way through those groups of elements, and pretty soon you’ll find that they’re coalescing into a full-blown page layout. It may take a few iterations to get all the parts to jibe just right within the larger system, but that’s all part of the process.
One of the nice things about wireframes is that, because of their aesthetic predictability, lots of your styling and markup will be reusable from project to project. Get a few under your belt, and the next batch will be a breeze.1
Fear not, my code-averse friend
If you’re a designer or UX professional, and you’ve never touched a lick of code in your life, fear not. There are resources out there to get you up and running. For beginners, there’s a swell new book simply called HTML & CSS that walks you through the basics while being exceptionally easy on the eyes. And let’s not forget the endless video tutorials of Lynda.com. New technologies can be daunting, but once you get going you’ll be glad you took the leap.
The other side
Learning new skills and developing new processes is a lot of work. And with the web changing so rapidly, it can be tough to distinguish between passing fads and the developments that will help you take that next important step in your career. If you work with the web, however, and the question is whether or not to start coding—I can assure you that we are definitely talking about the latter.
When we build our wireframes in HTML/CSS, we can get a more accurate representation of a responsive web experience—because it is a responsive web experience! The code we generate lets us, our teammates, our clients, and our testing subjects judge our work more intuitively in its native environment.
In the process, you’ll be getting closer to the medium in which you work. The web is, after all, code. And understanding that code means better understanding the limitations and possibilities of your discipline. On top of that, working in HTML and CSS can create actual, useable code that will become the basis of the final web product. Losing those PDFs means one less throw-away deliverable (and less throw-away hours) in our lives. And who doesn’t want that?
via planetweb
0 commentaires:
Enregistrer un commentaire