Easing the path from design to development – FOWD Workshop

Drew McLellan
@drewm
edgeofmyseat.com (just developers, work with design agencies)
allinthehead.com
webstandards.org

Drew McLellan is Director and Senior Web Developer at UK web development agency edgeofmyseat.com. Prior to this, he was a Web Developer for Yahoo!, and before that primarily worked as a technical lead within design and branding agencies for clients such as Nissan, Goodyear Dunlop, Siemens/Bosch, Cadburys, ICI Dulux and Virgin.net. Drew was Group Lead for The Web Standards Project 2006-08, and has had articles published by A List Apart, Adobe, and O’Reilly Media’s XML.com. He is a proponent of microformats and the lower-case semantic web, and writes at his personal site allinthehead.com and, with a little help from his friends, at 24ways.org.

This workshop will give you practical tips for helping a project smoothly transition from the design to the development phase.

What you’ll learn:

• Layouts – fixed, or fluid?
• How to cope with expanding for larger text and more content?
• Do graphics cope with an area expanding?
• Does each interactive element have a state for with and without JavaScript?
• Does each element have a state for logged in and logged out users?
• How are any custom fonts being displayed?
• Writing error messages
• Form design 101
• Ensuring your Photoshop comp document well organised?

——————————————————————————–

The process from design to development should’t be a battlefield

Dev don’t understand design process & viceversa. Is more about interaction between individuals aswell as between technologies.

Designers should know some dev. basics to inform their work.

What are the biggest issues you’re facing with your design to development process?

• accessibility
• growing
• straight edges
• print designers
• attention to detail
• being purist
• drop shadows
• bypassing design (new reqs)
• lack of care by developers
• utopian view by designers (looks great on the design, but not with real content and real implementation, on the browser
• communicating new techniques
• designers: name your layers!

[youtube]http://www.youtube.com/watch?v=f2mHkQUBEpM[/youtube]

What do YOU do guaranteed?

What is our responsability?
Dev responsible of the implementent, but the designer is responsible for the success of the design. It’s still your design. REspons doesn’t stop when you give your design to someone else.

What we’re looking at

Identifying a web developer: ajax, forms, logged in/out…
Identifying a web dev: all sort of clichés: antisocial, don’t get washed

Yes web developers are geeks

Remember: this is a great asseet to your project. Designers should be pleased that dev. are obsessing over the tiny technical details that add up to make your project successful.

Developers harp on a lot about «can’t do this, can’t do that».
There’s a reason: not just being awkard.

As a designer, you may know that there are allways technical considerations about the product you design (web, box…).
It’s like writing software, but sometimes weven more difficult: the requirements are any web browser.

Just because you see sth working somewhere else, doesn’t mean you had to do it: other people do bad stuff.
Appreciate when your developper adverts you of doing bad stuff.

Sometimes devs responds with ‘no‘ before really thinking. An atribute of devs is lazyness (reusable code). So you need to understand that devs are lazy, and sometimes they’ll initially respond they can’t do what you ask them for.

Best examples of web design and forward thinking, is when people achieve sth that we thought it was technically imposible to be done.

A lot of the every day techniques where imposible once

Flight.
Flash Satay: Embeddin Flash in XHTML Strict pages caused them to be invalid. There was no solution, so devs who cared about valid pages had a problem if forced to use Flash. He spent around two days going between the XHTML spec and multiple browsers, and the W3C validator error mesage… says you’re using Flash Satay, so it validates. (Alistapart, 2002).

As well as being lazy, developers like hard to solve problems

You jut need to motivate them throught the laziness. Dangle the Carrot of Glory. Sometimes a solution can be found.

Don’t let it jeopardise your project.

Devs job is to find the best technical solution. If not, they’ll be judged as not being competent.

Example: images for navigation.

Sometimes a design rquires an exact font or specific typographical control we can’t get with CSS.
Options: images text.
Thew worked on a project wich navigation was in arial:

• user could make text bigger
• links could be quicly edited from the cms
• user style sheet could override the colours if necessary

But the designer came back, the client was not happy because at first, they looked the site on a Mac, that looked like the Photshop. But after, looking on Windows, was awful.

Best over-all solution is a case of weighing up the technical, communication, brand, usability, aesthetics.
So they chose a less optimal thechnical solution – text as images.
But it benefit the overall solution for Windows users.

Technical solution is just a part of the overall solution. Is a big part, but not the only one, and sometimes you have to sacrifice the best technical solution to better serve the end goal.

If the developer says no, it’s their responsibility to help the designer fin a better solution.

Some specs might frustrate the developers, specially when timescales are short, like keyboard navigation, non-javascript version…
It’s because they’re trying to do a good job.
REmember that just as a designer fights for whitespace, devs. fight for eficiency.
If it was a corner they thought they could cut, then they would.

fray.com a story telling website from the late 1990s
They had differnet design for every single story they published
Someone asked  on twitter, for wxamples about good story telling on the internet.
He thought about fray.com/criminal/left, but it was on the nineties. It’s impossible to get past screen 1 of the story, because of the JS. It would have needed to be designed in two states: with and without javascript. It would have be taken longer, but it would still working today.

If you stuck with a bad dev, you need to design for a bad developer.

Ramsay’s Kitchen Nightmares. If the chef is bad, they replace him and that’s it. But not every web company can find or suppport top notch developers.
With crap chefs, Ramsay implements a simpler menu, but with high quality ingredients. Food is designed to be easy and efficient to prepare, but it is still good.

As a designer, use simple ingredients, avoid complex and cutting edge techniques. Just as designing for 1 colour in prunt doesn’t mean you have a bad design.

Principals

Practicality

Can it be built?
There are somethings that are just routine, but others that just can’t be done (text on 45 degrees).

If we would implement it, would it be useful? would the user understands how it works to make good use of it?

Compatibility

Will it / can it work with all browsers?
Most desktop browsers are very capable, but what about mobile? The environement is getting complex.

Is it accessible? Will it cause problems for users of assistive technologies?
Does it pass basic text resize and keyboard naviation tests?
Who are we excluding?

Identify the weakness and adress.

Cost

Time to build – is it worth it?
They had a project, with rounded gradient opacity scallable boxes, with a jpg body background, that were 5 times more hard to build.
What are the alternatives?

Web sites

Tools

CMYK? Someone still doing it, because they still sending them CMYK pictures.

Fireworks, Photoshop, Illustrator, InDesign, Quark, Powerpoint.

Layout

A magazine or package has fixed constraints. So has the web browser, but different ones.We need to know how to deal with them.
It has every dimension. The method you choose has a big impact on how you design and build, so it needs to be considered.
Choose a layout, and consider it in every aspect of the design.

Fixed/fluid/elastic layouts.

Fixed

Examples with fixed layouts, left side, centered…

Designed to fit with a certain screen res.

On hires, it’ll still in the middle.

Minimun screen res required to use the site. Smaller res visitors get horizontal scroll bar.
Main content area shouldn’t be too wide.

1024 isn’t 1024 wide – more like 1000

Pros

Easier to work with images.
Rounded corners don’t have to expand in two directions.
Easier to code.
More control.

Cons

Resized up text can run out of space == short lines.
Need to design for the lowest common res.
On big screens, your site looks really small.
Less control for the user.

Liquid/Fluid

Examples:
UX London.
blog.talkinganimal.co.uk (1 col to 2 cols to 3 cols)

Considerations:

• wich elements expand?
• wich are fixed?
• not all content expand

Pros

makes good use of available space

doesn’t make any assumptions about available space

Cons

Lines of text can become very long
Can take little longer to get right to implement

Elastic

We’re not likely to see elastics websites anymore because is something that browsers will do on zoom by default.

Pros

great for heavy typografy design

Cons

lots of maths

Which one to use?

it depends on the website

It’s tempting to thik that layout zooming makes this a non-issue

Design might be robust and can offer some flexibility. Different, unknown browsers may display text differently, and we can’t test in everysingle browser.

Give and take

Content volume

It’s rare to know exactly wich content are you going to work with. Is fundamental to design for the content, but it could be quite a challenge. Designs cannot be tweadked around any specific item of the content.
Designers must cope with both much greater and mucn lesser vols of contents.

Example BBC News with 2 line title (white text, dark background) so it is unreadable 2nd line that felt down.

Point: build some flexibility on your design. What happens if the title is 2 or 4 lines? The designer might make the desition. Know which points can give and take.

Particular things to watch out for

Any user-generated items like usernames.
You might expect sth like a username about 8-12 characters. But the application allowd 255 characters, so they’ll always someone who will do it.

Consider the possibility that the structure may expand on the future.

Structure needs flexibility.
Is desirable to make changes to the structure, without revising the site’s information architecture more thoroughly.

Text size

Most important principle of web design: we’re suggesting and not dictating how a site should look.

Same font can display differently in different places and platforms.

Increasing text is important where space is limited by the design. In BBC’s case even one world made bigger wouldn’t fix.

You need to design every element thinking that it may increase. (Long username, bigger font-size…).

Make sure to make extended versions of any graphical elements.
Particulary important with navigation tabs, rounded corners…

Fonts

Photoshop, like a mistress, parades a vast array of ropey. But on the web, we have to be a little more restrained in our choice of typefaces.

Purest option: always use available fonts. But we never know what’s available. Arial, Lucida Sans, Trebuchet MS, Georgia.
So use generic font familys: sans, sans-serif, fantasy.

Font matrix. 24ways.org/2007/increase-your-font-stacks-with-font-matrix.

When you can’t use available fonts. It’s really bad to use images for text.
Problems: cannot be copied, resized…

What to do? Use image replacement techniques. Not all are perfect.

Dave Shea has a break down: mezzoblue.com/tests/revised-image-replacement

(Screen readers wouldn’t read the text if we use display:none for hiding the <span> text.)
Text can’t be resized or selected.
But images need to be created.
Hard to make the CMS create the images.

Images aren’t the only way: embeded fonts with Flash (sIFR):

• can be selected and copied.
• text is dynamic, it can be
• real fidle to get it right 🙁
• good for the CMS to create the content
• has performance issures with multiple items per page
• good option on the whole for occasional use

Messaging

Any site has interactive elements.

Include error messages and thank-you messages.

These tipically appear as the result of an interaction so are easy to forget and miss off a Photoshop comp.

Point: Design the messages. They really require consideration. Specially error messages. Think about a complex form that the user didn’t understood. Critically important.

Forms

What gets displayed when the interaction gets successful?
When do they go and see next?

Ajax

Design the javascript/ajax interaction.
The user doesn’t get any visual feedback of the site waiting for a response from the server unless you design it that way.
Consider using a ‘waiting’ or ‘in progress’ spinner.
How do they look?
how do they animate?

Error pages

With luck, these won’t often be seen, but they’re a critical point.

404, server error…

Error places

Relation with the area…
If you don-t design the errors and their placement, developers will do.

Search results

search results or anythig db driven

How much data? (no results, 100 results…)

Paging

kurafire.net/log/archive/2007/06/22/pagination-101

Provide large clickable areas
Don’t use underlines
Identify the current page
Space out page links
Provide previous and next lists
Use first and last links (where applicable)
Put first and last links on the outside
Page count for big listings

Forms

Look of the browser’s default form fields are usually ugly.
Somethings you can do to style form fields and the buttons (althought is not cross-system)
Is not always easy, depending on the style.

If you don’t have lot of space, will be better to use default form controls.

Each form field should have a label.
Each form field should have a submit button.

Custom scrollbars

Not very used (so did before).
Problem: if they’re little.
Size of the scrollbar should represent the lengh of the content.
Custom slipbox (box with the arrows). Difficult when using a keyboard.

Designing to a budget

Publishing is not free (server resources). The design has implications in bandwith costs.

Building is not free (developer resources). It may take a long time to build.

What’s cheap?

• Square corners
• Consistent design (the more common elements -stuff to use-, the less expensive implementation)
• Few templates
• Intelligent reuse

What’s expensive

• Graphically complex (multiple rounded corners, some gradients, opacities, different colours for each section…)
• Every page different
• Customisable backgrounds
• Large images (serving them to the browser)

Think about

• Build costs
• Maintenance costs
• QA cost

Web applications

Logged in / logged out sites

For some items there’s no difference, but there are some that need a consideration about how do they look when logged in or not.

How does the user progress through the suthentication process to arrive back at the task they wer trying to complete.

JS to streamline the by building the interface without JS. Get it working. And then layer that JS on top.

Designers neet to consider both states of any feature they’re designing.

There are four states to design for:

1. logged out with js
2. logged out without js available
3. logged in with js available
4. logged in withous js available

All might be designed because this is how some of your users will interact with the site.

Hijacking

Ajax. Consider how the same can be achieved with basic HTML forms, lnks and intermediary pages. (Flickr avatar options, if js unavailable, when clicking you go to user’s profile page with all those options).

Empty states

What about you hadn’t complete a place of your profile? What would you show when there’s no data there?

POST vs GET

Two ways to deliver the form. (The only way to use POST is to use ajax or a form).

When to use GET?
Normal link. You can request the page as many times as you like.

When to use POST?
Deleting sth.
Designing pages that makes changes.

How to get along

Most of times is most about attitude.
Need a compromise of reaching a reasonable way to do the work.

But the best work often comes out of a longer term working relationship.

The leads should take joint responsibility for delivering the site between them.

Checklist when delivering the design to developers

• is the layout fixed or fluid?
• wich items expand?
• does interactive element have a state with withous js?
• any custom fonts being displayed?
• have you designed errror/success messages?
• labels for form fields?
• is your photoshop comp document well organised (labelled layers, folders)?
• have you provided flat PDFs of each state?
• have you provided a color reference?

allinthehead.com/presentations