Easing the path from design to development
How designers and developers can learn to get along

- Introduction
	- The process from design to development shouldn't be a battlefield
	- All too frequently it does turn into one
	- This is often because developers don't understand enough about the design process
	- And designers don't always know enough about development
	- Designers should know some development basics to inform their work
	- That's what we're spending some time looking at this afternoon
	- But first, who I am?
	 	- Drew McLellan
		- @drewm on Twitter
		- edgeofmyseat.com
		- allinthehead.com
		- 24ways.org
		- webstandards.org
		- But most importantly, I build things.
	- I've spent the last ten years as a developer working alongside designers
		- I think I have a good grasp of how the process should work
		- But enough about me
	- Who are you?
		- Who's a designer?
		- Who does only design?
		- Who does a bit of building?
		- Who does all the building?
		- What we cover today should be useful for all parts of the process
	- What's your problem?
		- What are the biggest issues you're facing with your design to development process?
	- Video
		- What do YOU do guaranteed?
		- The developer is responsible for implementing the design
		- The designer is responsible for the success of the design
		- Guaranteed!
	- What we'll be looking at today
		- Identifying a web developer
		- Principals for evaluating a design
		- Layouts
		- Fonts
		- Forms
		- JavaScript & Ajax
		- Logged in/out states
- Identifying a Web Developer
	- Web developers are a strange breed 
		- All sorts of clichés
			- We live in the dark
			- Frequently don't wash
			- Fairly anti-social
		- Just as there are all sorts of clichés about turtle-neck wearing, pencil twiddling designers
			- They're no more accurate
		- Developers are no different from other office workers really. 
		- A lot of project managers are worse (especially not washing)
		- Yes, web developers are geeks
			- We specialise in the art of geekery
			- Often  this results in obsessive attention to detail for the most boring things
				- Remember:
				- This is a great asset to your project
				- Be pleased that your web developers 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"
		- Be aware: 
		- It's for a reason, they're not just being awkward
		- (well, sometimes they're just being awkward)
		- Most of the time there are good reasons
		- The web is a technical environment in a way some other forms of communication aren't
		- It's like writing software, but sometimes even more difficult
		- Just because you see something working somewhere else, doesn't mean it's responsible for you to do it
		- Other people do bad stuff
		- appreciate it when your developer prevents you from doing bad stuff
		- Developers aren't usually trying to spoil your fun
			- Except when they are.
			- Sometimes they'll initially just respond with 'no' without really thinking
			- An attribute of a good developer is laziness
			- It's this that drives them to have efficient, reusable code
			- The computers should be doing the work, not us, that's what they're for
			- You need to understand that developers are lazy
			- Sometimes this means they'll initially respond and say that something can't be done
				- Really they mean there's no easy way to achieve it
				- Some of the best examples of forward thinking web design is from when people do what can't be done
				- A lot of the every day techniques we take for granted were 'impossible' at one time, until someone sat down and tackled it
					- e.g flight!
					- Flash Satay
						- Embedding Flash in XHTML Strict pages caused them to be invalid
						- There was no solution, so developers who cared about valid pages had a problem if forced to use Flash
						- I was one who cared about having valid pages, and was required to embed Flash
						- No body had actually spent the time to figure out how to get it to work within the spec
						- So I spent around two days going between the XHTML spec and multiple browsers and cracked it
						- We wrote it up for a alistapart.com article, and the W3C validator error message now recommends using the technique I developed.
						- Not an easy problem, but by focusing on it and spending time, we found a solution
				- On occasion, the impossible can be done
				- But it's a hard problem to solve.
			- As well as being lazy, developers like hard to solve problems
				- They also like praise, flattery, glory and beer
				- You just need to motivate them through the laziness and dangle the carrot of glory
				- Dangle the Carrot of Glory
				- Sometimes a solution can be found
					- Don't let it jeopardise the project
					- It could take a lot of time to work through
					- There may be no solution at the end of it
					- There are a lot of things we cannot do, no matter how hard we try
			- Sometimes they'll say no because it would result in a less than optimal solution
				- It's in a developer's nature to push for the very best solution
					- It's their job to deliver the best solution
					- To them, if they deliver something other than the best obvious solution, they could be judged as not being competent 
				- Example: images for navigation
					- Sometimes a design requires an exact font or specific typographical control we can't get with CSS
					- There are a few options for this (which we'll look at) but one is to use Photoshop to make images of the text
					- We worked on a project last year where the navigation links we set in Arial in a mid grey
						- We could happily reproduce this perfectly with CSS
							- The links could be read by search engines (important!)
							- The text could be resized by the user
							- The links could be quickly edited from the CMS
							- A user style sheet could override the colours if necessary
							- It was the best solution
						- The designer came back to us and said that the client wasn't happy
							- There was no difference between the mockup in Photoshop and what was on our screens
							- But we were viewing on a Mac 
							- The client was using Windows, which doesn't do a good job of anti-aliasing text
							- The text looked wiry and ugly, like all the text on Windows
						- My initial reaction was "well, that's just how text looks on Windows"
						- Text was the best technical solution
						- But getting the best over-all solution is a case of weighing up the technical, communication, brand, usability, aesthetics
						- We chose a less optimal technical solution - text as images
						- But it benefited the overall solution for Windows users (most users)
				- It can be hard to get developers to see that the technical solution is only part of the overall solution
					- Technical is a big part, and a lot of the time it carries the vote
					- But it's not the only part, 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 find a better solution that works for both of you
				- Don't be afraid to ask a developer for help
				- Dangle the Carrot of Glory
		- Sometimes developers insist on a lot of stuff that seams unnecessary 
			- e.g. non-JavaScript versions of a thing
			- Making something navigable with the keyboard
			- This can be frustrating when timescales are short 
			- But remember - developers are lazy! 
			- So why are they doing this?
			- It's because they're trying to do a good job
			- Remember that just as a designer fights for whitespace or the correct application of a brand identity, developers are specialist too
			- Good developers know their stuff, they know the best way to do things
			- If it was a corner they thought they could cut, then they would.
		- fray.com
			- A story telling website from the late 1990s
			- Full archive is still online and the content is still relevant and powerful today
			- Each story had a unique presentation
			- http://www.fray.com/criminal/left/
				- It depends on JavaScript
				- That JavaScript was written to work in the browsers of its day, but no longer works
				- It's impossible to get past screen 1 of the story
				- It was built a long time ago, before current best practise was understood
				- Had it been written with what we now understand to be best practise, even if that JavaScript failed, the story would have been readable.
				- It would have needed to be designed in two states, which would have taken longer
				- Development would have taken a bit longer
				- But it would still be working today.
		- Everybody gets frustrated when they're preventing from doing their job well
			- So be aware that when a developer is pushing to do things a certain way
			- They're just trying to do a good job
		- Of course, all this only applies to good developers
			- If you're stuck with a bad developer, you need to design for a bad developer
			- Ramsay's Kitchen Nightmares
				- If the chef isn't great, he doesn't insist they get replaced
				- Not every restaurant can find or support a world class chef
				- Not every web company can find or support top notch developers
				- So you work to the strengths of the people you have
				- With crap chefs, Ramsay implements a simpler menu, but with high quality ingredients
				- The food is designed to be easy and efficient to prepare, cook and serve, but is still delicious
			- As a designer, you need to design sites to the abilities of the developer
				- Use a few simple, high quality ingredients
				- Be good but not fancy
				- Avoid complex and cutting edge techniques
				- Just as designing for 1 colour in print doesn't mean you'll have a bad design
					- Designing for a less experienced developer just needs to embrace the constraints
			- If they can't achieve the required results, they may need some training
				- If they can't respond to training, they may need replacing. (ouch)
- Principals
	- There are a number of principals that we'll keep coming back to and use to evaluate what we're doing along the way
	- Every element of every design needs to be evaluated against these basic principals
	- Practicality
		- Can it be built?
			- There are somethings that are easy and routine
			- But there are somethings which we just can't do
				- Text on 45 degrees
		- If we do build it, will it be useful/usable?
			- Does it actually perform a useful function
			- Will the user be able to understand how it works to make good use of it?
	- Compatibility
		- Will it / can it work with all browsers?
			- Not all browsers are created equal
			- Most desktop browsers in use today a very capable
			- There's a bit rise in mobile use, games consoles
			- Some browsers aren't so great and have limitations
		- Is it accessible?
			- Will it cause problems for users of assistive technologies
			- Does it pass basic text resize and keyboard navigation tests?
		- Who are we excluding?
			- Hopefully nobody
			- How can be build it to exclude no one?	
				- Identify the weakness and address
	- Cost
		- Time to build - is it worth it?
		- What are the alternatives?
- Web sites
	- Layout
		- A magazine layout or package design has fixed constraints
		- The web browser does not have the same constraints - it has different ones
		- These are both a blessing and a curse- you need to know how to deal with them
		- The browser is not a fixed medium. It has no dimensions and every dimension
		- In response, there are some different basic ways of layout out a page
		- The method you choose has a big impact on how you design and build, so it needs to be considered
		- Point: choose a layout, consider it in every aspect of the design, and communicate it to your developer
		- Fixed with / Fluid or Liquid / Elastic
		- Fixed
			- Designed to fit with a certain screen res
			- On hires, it'll sit in the middle or to one side
			- Considerations
				- The minimum screen res required to use the site
				- Smaller res visitors get horizontal scroll bar
				- Main content area shouldn't be too wide
				- 800*600 isn't 800 wide - more like 760
			- Pros
				- makes working with images easier
					- e.g. photos or banner ads whose size you don't control
					- rounded corners don't have to expand in two directions
				- can be easier to code
				- more control
			- Cons
				- Resized up text can run out of space == short lines
				- Need to design for the lowest common denominator
				- On big screens, you site appears very small
				- less control for the user
		- Liquid/Fluid
			- Reflow to use all the available window width
			- Users on hires screens don't end up with a small central site
			- Considerations
				- Which elements expand?
				- Which are fixed?
				- Not all content expands (e.g. images) - how to deal?
			- Pros
				- Makes good use of available screen space
				- Doesn't make any assumptions about available space
			- Cons
				- Lines of text can become very long
				- Not all elements reflow comfortably e.g. images
				- Can take a little longer to get right
		- Elastic
			- Dimensions all set in ems 
			- Columns grow and shrink depending on font size
			- Always the same number of words per line
			- Considerations
				- Largely the same as Liquid layouts
				- You lose the ability to know the exact pixel width of any one column
			- Pros
				- Great of typography-heavy designs
			- Cons
				- hard to get working well with lots of images
				- lots of maths!
		- Which layout to use?
			- It depends entirely on the site
				- the best thing is to know the options and the pros and cons of each
			- Many of the pros and cons relate to text resizing
				- It's tempting to think that layout zooming makes this a non-issue
				- Layout zooming is a red herring
				- It's true that many people solve that one problem of making things bigger
				- But that tells us nothing about our design
				- The property of being able to cope with resized text is more important than the size of the text
				- It tells us our design is robust and can offer some flexibility
					- Different, unknown browsers may display text differently
					- User stylesheets
					- Qe may change the design of our own site in the future
				- This leads us on to...
		- Give and take
			- If any part of the layout is going to be flexible (get wider and narrower as required), consider how any graphics are affected.
			- Images don’t usually look good if displayed at anything other that their original size, so should they behave?
			- Provide separate wider/taller versions of any background images
			- If it’s fluid, which parts expand and which not?
			- If it’s fixed, should it sit in the middle of the window or to one side?
	- Content volume 24w
		- It’s rare theses days to know exactly what content you’re working with when a site is designed
		- Most sites are designed as a series of templates for some kind of content management system
		- Designs cannot be tweaked around any specific item of content
		- Designs must be able to cope with both much greater and much lesser volumes of content that might be thrown in at the lorem ipsum phase
		- Point: build some flexibility into your design. Know which points can give and take.
		- Particular things to watch out for
			- Things like headings (how do they wrap onto multiple lines)
			- Any user-generated items like user names
			- You might expect something like a user name to be 8-12 characters
			- If the systems powering your site allow for 255 characters they’ll always be someone who’ll go there
			- Expect them to do so
		- Consider the possibility that the structure might be expanded in the future
		- Consider how additional items might be added to each level of navigation
		- The structure needs a little bit of flexibility to change over time
			- Even though it’s rarely desirable to make significant changes without revisiting the site’s information architecture more thoroughly
	- Text size
		- Designs must allow for a little give and take in the text size
		- It’s a fundamentally important principal of web design that we are suggesting and not dictating how something should look
		- The same font can display differently in different places and platforms
			- Something as simple as Times will display wider on a Mac than on Windows
		- The main impact of text resizing is the change in how much vertical space copy takes up
		- Particularly important where space is limited by the design
		- Making text bigger causes many more problems than making text smaller
		- Each element from headings to box-outs to navigation items and buttons needs to be able to expand at least vertically, if not horizontally as well
		- This may require some thought about how elements on the page may wrap onto new lines
		- Making sure to provide extended versions of any graphical elements
	- Fonts 24w
		- There are three main causes of war in this world; religions, politics and fonts.
		- I believe the responsibility for this falls squarely at the feet of Adobe Photoshop.
			- Photoshop, like a mistress at a brothel, parades a vast array of ropey, yet strangely enticing typefaces past the eyes of weak, lily-livered designers, who can’t help but crumble to their curvy charms.
		- Yet, on the web, we have to be a little more restrained in our choice of typefaces. 
		- Point: on the web, not every font is available. You need to think about the fonts you use, and how they're going to be displayed.
		- The purest solution is always to make the best use of the available fonts
			- Text is rendered at the browser
			- This means the font needs to be available at the browser
			- But we never know what's available
			- There are a few, common, 'web safe' fonts
				- Arial
				- Courier New
				- Georgia
				- Times New Roman
				- Verdana
				- Trebuchet MS
				- Lucida Sans
			- There are also generic font families
				- sans-serif
				- serif
				- monospace
				- cursive
				- fantasy
			- Font Matrix
				- http://24ways.org/2007/increase-your-font-stacks-with-font-matrix
		- When you can't go with an available font, but must use a specific typeface, you need Image Replacement
	- Image replacement
		- It's fundamentally bad to put text into images
			- Search engines can't read it
			- Low bandwidth (e.g. mobile) users may not see it
			- Assistive technologies can't detect it
			- It can't be selected, copied, pasted
			- It's a world of pain
		- But images give us a way to reliably render type the user doesn't have fonts for
			- So what's a girl to do?
		- There are a number of 'image replacement' techniques to help mitigate the problem
			- None of them are perfect, or as good as using available fonts
			- Most will fail with some combination of images on/off and CSS on/off
			- But they can be a good compromise
			- Dave Shea has a break down http://www.mezzoblue.com/tests/revised-image-replacement/
		- The principal is something like this
			- <h1>Hello world</h1>
			- <h1><span>Hello world</span></h1>
			- h1 span { position: absolute; left: -9999em; }
			- h1 { background-image: url(hello-world.gif); }
		- This works.
			- Screen readers and search engines can access the text
			- Text still can't be resized or selected
		- But
			- Images need to be created
			- This is unhelpful with content managed sites
				- Tt's hard to have a CMS generate high quality images of text
				- (not impossible, but hard)
		- Images aren't the only way
			- Flash enables us to embed fonts
				- And then render text on-the-fly
			- It can be selected and copied
			- And otherwise used just like images
			- But the text is dynamic - it can be read in from the page
		- sIFR (Scalable Inman Flash Replacement)
			- Requires Flash Player, CSS and JavaScript
			- And a copy of Flash to embed the font
			- It can be a fiddle to configure
			- But the results are good and it works well with CMS-generated content
			- Has performance issues with multiple items per page
			- But is a good option on the whole for occasional use 
	- Messaging 24w
		- Any site that has interactive elements, from a simple contact form through to fully featured online software application, involves some kind of user messaging.
		- error messages when something goes wrong
		- success and thank-you messages when something goes right
		- These typically appear as the result of an interaction, so are easy to forget and miss off a Photoshop comp.
		- Point: Design the messages
		- Forms
			- consider what gets displayed to the user if they make a mistake or miss something out
			- what gets displayed back when the interaction is successful
			- What do they see and where do they go next?
		- Ajax
			- 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 
			- give the user some visual feedback of any background processes
			- How should these look?
			- How do they animate?
		- Error pages
			- consider the big error pages like 404
			- With luck, these won’t often be seen, but it’s at the point that they are when careful design matters the most.
			- Not found page
			- Service down / unavailable page
		- Placement
			- where should errors appear
			- what's their relationship to the page around them
			- what's their relationship to the user's actions?
		- If you don't design the errors and their placement, your developer may throw in something awful.
	- Data listing
		- Lots of sites are driven by data
		- That data needs to be designed
		- e.g. search results or anything db driven
		- How much data?
		- Paging
			- Page count
			- Previous
			- Next
			- First? Last?
	- Forms 24w
		- The look of a browser’s default form fields and buttons can sometimes jar
		- It’s understandable that many a designer wants to change the way they look
		- Depending on the browser in question, various things can be done to style form fields and their buttons 
		- (although it’s not as flexible as most would like).
		- A common request is to replace the default buttons with a graphical button.
			- This isn't always easy, depending on the style
		- If the layout is very precise, or if space is at a premium, it’s always best to try and live with the browser’s default form controls.
		- Remember:
			- Each form field should have a label
			- Each form should have a submit button
		- Labels
		- Submit buttons

	- Custom scrollbars
	- Designing to a budget
		- Publishing is not free (server resources)
		- Building is not free (developer resources)
		- What's cheap?
			- Square corners
			- Consistent design
			- Few templates
			- Intelligent reuse
		- What's expensive?
			- Graphically complex
			- Every page different
			- Customisable backgrounds etc
			- Large images (download)
		- Designing burdens into a site/app
			- Build cost
			- Maintenance costs
			- Delivery costs
			- QA costs
- Web applications
	- Logged in / Logged out states
		- When designing any type of web application or site that has a membership system
		- The design will need to consider how any element is presented in both logged in and logged out states
		- For some items there’ll be no difference
		- For others there may be considerable differences
		- Should an item be hidden completely not logged out users?
		- Should it look different in some way?
		- Perhaps it should look the same, but prompt the user to log in when they interact with it?
		- What form should that prompt take on?
		- How does the user progress through the authentication process to arrive back at the task they were originally trying to complete?
	- JavaScript
		- JavaScript to streamline the user interface and make everything just that touch more usable
		- A good developer will start by building the interface without JavaScript
		- Get it working
		- And then layer that JavaScript on top
		- Designers need to consider both states of any feature they’re designing
		- There are four states to design for
			- Logged out with JavaScript available
		    - Logged in with JavaScript available
		    - Logged out without JavaScript available
		    - Logged in without JavaScript available
		- These all need to 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, links and intermediary pages
	- Empty states
	- POST vs GET
		- When to use GET?
		- When to use POST?
	- Popup windows
		- Usually prevented by popup blockers
		- Consider Lightboxes / modal overlays instead
- Cost is big
	- People forget that web design has cost involved
	- Easy to think that because it's digital it's free
		- Costs from development time
		- Costs in resources serving a design
		- Cost in people's time viewing it
			- In a recession people in work are busy
			- Winning work is more critical, so good comms is key
			- But that's not about development
	- Everything should be evaluated in terms of cost
- Workflow
	- Working together
		- One of the most dangerous situations for a web project is if design/development becomes a battle field
			- Unless designers and developers work together, problems are resolved with the wrong sort of compromise
				- What's the wrong sort of compromise?
					- It's when you're having to juggle people, rather than the technical or creative restraints
					- You shouldn't be choosing solutions based on how someone on the team might react or feel about things
					- Just as you don't want to be designing a site in green because it's the CEO's favourite colour
						- You want to be choosing colours based on how you're trying to position the brand, etc
					- You don't want to have to design your forms to output validation errors all at the top, because your developer doesn't want to reconfigure the CMS
						- And everyone's scared of him
						- You need to weigh up the benefit of having the errors next to each field, along with the time it'll take to change the CMS
					- Compromise based on technical or creative restraints
				- You need each team member willing to do whatever needs to be done to achieve the best result
					- You can't get to that if you're in conflict
				- A lot of that is just about attitude 
					- e.g. a design is presented with inline errors on form fields
						- DEV: you can't have the errors inline, they have to be at the top, otherwise I'll have to rebuild massive sections of the CMS!
						- DES: *humph* Well they have to be inline! All at the top is crap. The CMS is crap. You suck. Rah.
						- DEV: You suck. Your mum sucks.
					- The conversation would better go:
						- DEV: we can't put the errors inline with the CMS at the moment. Making the changes to do that will probably take more time than we have for this project.
						- DES: That's a shame - it really helps the user if errors appear as close to the mistakes as possible. Is there anything we can do?
						- DEV: I'll have a look. It's possible that I could get the errors to the top of the right /section/ of the form rather than all together at the very top.
						- DES: That'd be a good option if that's possible - I'll revise the designs to see if we can make that work.
					- End result is a reasonable compromise without blowing the development budget.
		- Be a team
			- There's no one right way or wrong way to work
				- The only wrong way is the way that's not working for you
				- We work in a situation where we team up with design agencies
					- Often we never even meet the designer whose work we're building
					- But the best work often comes out of a longer term working relationship
				- It's not necessarily bad to do your design and development in distinct phases
					- It can have advantages
						- Technical constraints don't impact creative work too early
					- It can have disadvantages
						- The designer needs to be a bit more technically clued up
				- If you work in a situation where both designers and developers are in-house, it can work well to team up
					- Have your lead designer and lead developer (which may be the only designer and developer) pair up
					- The leads should take joint responsibility for delivering the site between them
					- Make yourselves a team, you're both responsible for the entire outcome
					- They should meet early in the project and then work together on achieving the solution
	- Specification documents
		- Having some documents in place can make sure everyone is clear on the goals
		- Requirements document
			- How will content be managed?
			- By whom?
			- How do people make contact
			- Does the site run ads?
			- How will success be measured?
			- Where will it be hosted?
			- What information is collected?
		- Functional specifications
			- A functional specification describes how a product will work entirely from the user's perspective.
			- It doesn't care how the thing is implemented.
			- It talks about features.
			- It specifies pages, navigation, messaging, and so on. 
		- Technical specifications
			- A technical specification describes the internal implementation of the program.
			- Your developer may draw this up for larger or more complex projects
			- It talks about data structures, relational database models, choice of programming languages and tools, algorithms, etc.
			- Boring stuff
	- Handing files over
		- Provide separate wider/taller versions of any background images
		- Group and label your Photoshop layers
			- make it easy for a developer to see which need to be turned on and off to get to isolate parts of the page and different states of the design
		- Provide a PDF of each page and state
		- Provide a colour reference
			- RGB values of all the key colours used throughout the design
			- Without this, the developer will end up colour-picking from the comps, and could potentially end up with different colours to those you intended.
		- Photoshop is an unfamiliar tool for a lot of developers
			- Make it easy for them to not make mistakes
			- Be the expert of your own domain and help your colleagues out when they’re out of their comfort zone.
			- That goes both ways.
	- Checklist
		- Is the layout fixed, or fluid?
	    - Does each element cope with expanding for larger text and more content?
	    - Are all the graphics large enough to 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? (and does the developer have the font to use?)
	    - Does each interactive element have error and success messages designed?
	    - Do all form fields have a label and each form a submit button?
	    - Is your Photoshop comp document well organised?
	    - Have you provided flat PDFs of each state?
	    - Have you provided a colour reference?
	    - Are we having fun yet?