Tag Archives: Multiple pages

10 Reasons why I prefer Fireworks CS4 to Photoshop for Web Design

Posted in Design on by Leigh Howells

Leigh Howells (a designer at Headscape) shares why he has decided to make the transition from Photoshop to Fireworks.

I have been a Photoshop user for over sixteen years, ten of which have been in a production web design environment. I’ve got used to the way it works. I’m used to its feature set and how it does what it does. I’ve worked happily within that framework and mostly not digressed unless my requirements have been to design a logo – where a vector illustration package like Illustrator has come into its own. More recently, however, I’ve begun to feel like I’m actually using the wrong tool for the job, in some ways like using a word-processor to replicate the work of a spreadsheet.

Just after Adobe’s CS4 suite was released, I decided to have another look at Fireworks – a package I had looked at a few times in earlier versions, but repeatedly given up on – each time falling back to Photoshop. I played with it, and I was impressed by a lot of what I was seeing. I persevered with it and started producing much of my my day-to-day work in preference to Photoshop.

1. Multiple Pages (with Master Page)

A Photoshop file consists of a single image with multiple layers. A Fireworks file on the other hand allows multiple pages with multiple layers per page. When working on a multi-page mock-up for a site design, the advantages of having all your assets contained within a single file are enormous. Although having 5 different PSD files may be workable initially, once edits and changes are required, for example changing text in a consistent header or footer, things can soon get messy and time-consuming as changes have to be made across all files. It’s also very nice that each page can be a different size, perfect for the different sizing which is often required between home pages and content pages.

As well as having multiple pages within the Fireworks .png file (the native file format) the powerful Master Page allows you to define consistent template elements which appear across all other pages. This is very powerful for defining a consistent header/footer which appears on each page and only needs to be edited on the Master Page to be updated across the design. A single page can also be detached from the Master Page if there is a unique page requirement.

2. Symbols

Symbols allow you to define an element or group of elements into a single object which can then be used all over your design across all your pages. This symbol can then be edited in a single place and all changes are reflected throughout your document. Imagine a graphic for a bullet icon which is used in many places across the design. To change the colour or shape of the icon within Photoshop may require lengthy manual editing and copying and pasting across multiple files. But with a multi-page Fireworks document using symbols, the change is only required in a single place for all the icons to be changed instantly across the design. This is a very powerful feature enabling design tweaks which may have otherwise been abandoned due to the time and effort involved.

3. Styles

Styles are to Fireworks as a CSS style sheet is to a web page. An items fill, stroke, font and effects can be defined into a style. These styles appear on the styles list and can be applied to other elements in the document. The real power lies in the fact that these styles can be amended and the changed cascading across the multi-page document automatically. Imagine a style of image with a particular border and drop shadow used in many places which you decide would look better with a different border colour and no drop shadow at all. If you have defined this image with your own style a single update will change all instances without all the pain. Like with symbols this can be a huge time saver whilst encouraging design experimentation and consistency.

4. Vector Objects

Fireworks offers the same basic tools as Photoshop for Bitmap editing but also has many extra vector tools. Lots of vector shapes are welcome with many control points for creating stars, polygons and regular shapes. In addition the Autoshapes panel provides a more diverse collection ranging from stick men with moveable bones, to clocks, calendars and title blocks.

My personal favorite or at least the one I have used the most so far, however, is the humble rounded rectangle which has control points for individual corners making a single rounded corner on a rectangle a simple task compared to Photoshop.

I also like the precise pixel control over each of fireworks elements in the Properties toolbar which makes sizing of images and vector objects a breeze to set to required sizes.

5. Libraries

Both symbols, styles and vector shapes can be saved for re-use and collected into useful library resources. In addition Fireworks ships with a common library of useful objects including buttons, browser and application elements for both Mac and Windows look and feel. A number of pre-defined styles are also provided ranging from Chrome and wood styles to more useful line shading and tool-tip styles.

6. Grouping

In more recent versions of Photoshop layer groups have allowed you to virtually group objects together. Though this works well, it requires a certain level of organisation moving individual layers into folders manually. Unfortunately, I have never liked working this way. I like to work quickly as inspiration guides me without having to laboriously put everything into layers and name them. Though the layer group model is still present in Fireworks it allows you to quickly select individual elements and group them together. The necessity to name layers is lessened by the fact they can be directly clicked on as in most vector packages, unlike Photoshop’s right click and ‘guess the layer’ (which didn’t get named!) method.

7. Interactive Gradients

Fireworks’s Interactive gradients are a simple enhancement to what is already available in Photoshop, but the gradient being used has control handles allowing it to be moved and sized within the object. A very simple enhancement but it works well and allows fine control and becomes particularly useful with using rectangular shading styles.

8. Web Layers

The web layer allow you to quickly add hotspot areas and links between the pages in your Fireworks document, or external URLs. Whilst being useful for linking together simple wireframes, it can also be applied to fully designed mockup pages illustrating how a finished site may navigate.

Fireworks’ initial conception was to help designers produce quick web sites with its ability to output html, rollovers and interactivity. All those features are still there and whilst you may not want to use the code it produces for final sites, for outputting your designs as an interactive mockup site, for example, Fireworks does a great job of exporting your images and html.

9. 9-Slice Scaling

This scaling technique can be applied to bitmaps aswell as to vector objects. This allows intelligent scaling as can be seen in the bitmap below; the four lines define vertical and horizonal sections on the image which will scaling areas when the image is resized, leaving the remaining areas untouched. This can be applied to dialogues boxes, headers, scroll bars, anything which you would want to scale, but to scale non-uniformally.

10. Small learning curve

Lots of things are just the same as in Photoshop – lots of keyboard shortcuts, tools palette – windows, toolbars, panel layouts etc. It all mostly feels the same and I have got to grips with it intuitively moving from Photoshop.

In addition to these ten points, Fireworks is also cheaper than Photoshop!

Some things I don’t like so much

Though I love Fireworks so far, I have some niggles. These may be due to my lack of experience, but then if that’s the case maybe my main niggle is the fact they aren’t obviously overcome!

1. Masks

These aren’t quite as intuitive as Photoshop yet. I have always been a big fan of quick masks in Photoshop; i.e.; pressing ALT between 2 layers making the lower layer mask the layer above. Though layer masks are the same, and there is the ability to paste bitmaps within objects using ‘Paste Inside’, these don’t work quite as freely at the moment.

2. Text Anti-aliasing.

I can’t quite put my finger on it, but the anti-aliasing of text isn’t quite as good as Photoshop’s yet. Even thought there is actually more control with the ‘Custom Anti-Alias’ panel – which allows you to edit parameters, sometimes text can look decidedly ropey at smaller sizes without lots of twiddling.

3. Performance

I can’t quite put my finger on this one either, but Fireworks doesn’t feel as solid as Photoshop. Maybe this is familiarity, but I feel like I’m working from within a piece of carved granite whilst inside Photoshop’s windows. I don’t have that feeling with Fireworks yet, but maybe it will come. (I also don’t know how many of the occasional memory problems and crashes have been due to running a pre-release version on Windows 7).

4. Snobbery

This is a terrible reason for not using one piece of software over another. However, I feel it’s very valid and I’m yet to tell a client I will provide them with Fireworks .png files rather than Photoshop PSD files (although multi-layered PSDs can be output directly from Fireworks). Maybe there is a fear your reputation as a designer is at stake if you aren’t using ‘the big and mighty Photoshop’. Maybe you fear you will not be taken as seriously, like in the old days of DTP using Pagemaker instead of Quark, or sequencing music in Cakewalk rather than Cubase or Logic.

Conclusion

To be honest, I’m not 100% happy with either product for web design work. I still prefer and am more comfortable with some of Photoshop’s familiarity, but I’m enticed by all the other features that Fireworks offers to make life easier and production more streamlined.

I guess the conclusion if you own both is obvious; use them in tandem. Use Photoshop for image editing, and more advanced image correction and manipulation, and use Fireworks for layout mockup of complex web sites which may end up with hundreds of layers. Note that with Photoshop installed, Photoshop’s layer filters are directly accessible within Fireworks in addition to Fireworks own filter options (which have all the basics; drop shadows, glows etc. etc.).

I eagerly look forward to future updates to Fireworks and wonder how the two products may diverge further now that they are both under Adobe’s wings. Although I wish they would change the name from Fireworks, to something like ‘Webshop’ as I keep mixing up Fireworks and Firefox both in conversation and launching the wrong application all the time! But maybe that’s just me.

115. sxsw

Posted in Classic shows on by Paul Boag

On show 115: Lessons learnt at SXSW, Garett Dimon on form design and how to find usability test subjects.

Download this show.

Launch our podcast player

News and events | Lessons learnt at SXSW | Garrett Dimon on form design | Listener feedback

News and events

Microsoft launches beta of Internet Explorer 8

The big story over the last couple of weeks has been Microsoft’s release of Internet Explorer 8 as a beta. This has sparked a flurry of posts from various bloggers on the pros and cons of the new release. However the two that caught my attention were Kevin Yank at Sitepoint and Roger Johansson.

In short, IE8 looks like an impressive update with significant improvements in standards support. It would appear we can finally say good by to HasLayout, while at the same time welcoming decent CSS table support. This will open up a lot of possibilities for layout.

There are too many updates to go through here so I would encourage you to check out "what’s new in internet explorer 8" over at the MSDN blog. You might also want to look at the Internet Explorer 8 readiness toolkit that tells you all you need to know about the new browser.

Designers agnst

There seems to be a lot of designer angst flying around the tubes this week including two posts on A List Apart and one at ideas on ideas.

As designers we seem to spend too much time fretting over the creative process, always looking for inspiration and techniques to improve the quality of our work. Andy Rutledge piles on the pressure in a fascinating article about creativity where he redefines the word. A second post on A List Apart twists the knife further by arguing that as designers we need to be superhuman obsessives, willing to work late into the night to produce the truely exceptional.

It maybe the case that to be a truely outstanding designer we need to live in a world of unrealistic personal expectations. However, personally I like the down to earth reality of "Six suggestions that can make you a better designer." In this post Eric writes…

Your project doesn’t have to do everything. It doesn’t have to win awards, make you look good, or have a wry subtext. Getting something simple to work is hard enough. Concentrate on the basics, and see if your idea holds up when shown to the audience.

In my opinion there is too much written about being outstanding and not enough on just being better.

Usability challenges associated with web applications

The final story of the week is a post by Jared Spool. Jared is a truely exceptional usability expert and I can highly recommend his Podcast. He is also an excellent speaker that I had the pleasure to hear again this year at SXSW.

The reason I mention him is because of a post entitled "3 important usability challenges for designing web applications." What I find so refreshing about this post is that it focuses on the web applications we all have on our sites rather than the trendy web 2.0. apps we hear so much about.

Sites like delicious, gmail, of even the up and coming getsignoff (shamless plug!) are somewhat unusal in terms of web apps because the whole site is the app. Most web applications are a part of a greater whole. They are contact databases on corporate intranets or ticket reservation systems on airline sites.

The challenges associated with these types of web apps are different from their trendier cousins and Jared addresses these problems in his post.

It is definately worth reading if you have web applications on your site.

Back to top

Feature: Lessons learnt SXSW

Marcus shares his impressions of SXSW and the lessons we can all learn.

Back to top

Interview: Garrett Dimon on form design

Paul: So joining me today is Garrett Dimon. Good to have you on the show. How are you?

Garrett: Pretty good.

Paul: Now I have to say I’m really excited about having you on the show because I have to say I’ve become a bit of a fan. I’m sorry to admit this and I know it’s horribly embarrassing when people say things like this to you. But ever since you’ve released your website which so impressed me I’ve been kinda following your work since then, some of the stuff you’ve been doing. You’re everything I’m not. You’re minimalistic, you’re clean and considered and well thought through while I’m chaotic, over the top and brash. That’s why I’m attracted to your work I think because you’re the
opposite of me.

Garrett: Everything I do from my apartment and everything is just the less I have, the simpler things are, the better things seem to turn out for me.

Paul: If only I could live that way. I’m just not… my brain just doesn’t function in that way. But that’s really cool. So I wanted to get you on the show to talk about forms of all things. It’s something that we’ve touched upon a couple of times in the show but mainly as passing comments in news stories and things like that. In actual fact a couple of the times we have mentioned it, it’s your name that’s come up. It seems to be something that you write a lot about from time to time. You see different articles popping up in different places. Why forms? What is it about forms that seems to attract your attention?

Garret You know it’s hard to give an answer. I really don’t know. But in thinking about it probably my first bet is that I really don’t consider myself to be a designer per say in terms of the more traditional, more artistic design orientated type of visual designer. But with forms it’s more about the interaction design and the more logical aspects of design which are things that definitely work better in my head. So how do you write error messages; how do you label fields; what order do they go in; how should they be grouped; do they go on one page or two pages. Some of the more logical, more interaction issues. Then using what little design knowledge I have to supplement that and make it visually easier to digest the form and see and understand the pieces of it. Basically to me it’s basically the one thing that I feel like I can comfortably design and layout because there’s a lot more to it than just the aesthetics.

Paul: Yeah that kinda makes sense. Why do you think forms are so important in a way? It’s obviously something you consider important but there doesn’t seem to be huge amounts written on the subject. What is it that makes them worth of that kind of attention as far as you’re concerned.

Garrett: I think part of the reason is precisely because they don’t get enough attention. Any real attention you see to forms, I haven’t seen it recently but it’s how do you skin your forms to completely control how they look. Which to me is one of my huge pet peeves. It seems like such a waste of time. To worry about what the forms look like in the browser as opposed to how they actually work, I’m thinking if you’re going to invest the time worrying about how your forms looks it’s probably better to spend that time worrying about how they are going to work. Are you using the right form field for that job and some of the more critical things about forms. Really forms, especially now with web apps being what they are, forms are such a huge part of your everyday interacts. Things like efficiency, learnability, accuracy, all the vasts of usability that matter. It’s not just a matter of “Is this form efficient?”. Well it’s easy to make an efficient form but it’s not necessiarly going to be something that somebody else could learn and use or you might be able to learn it but will you remember how to use it next time you come back. Balancing all the different kind of vasts of usability that Nielsen identifies and really working them out so that you don’t dumb the form down so that it’s so simple that anyone can use it that it’s just a cumbersome process to fill out. Really kind of massaging it with all those things in mind.

Paul: You’re right when you say that in the world of web applications certainly forms are amazingly important but they pretty much appear on every site. It’s hard to thing of a site where they don’t appear.

Garrett: Well you think about a magazine site or anything like that where it’s more content orientated, it’s definitely a lower priority.

Paul: Yeah but you’ve still got contact us forms and things like that.

Garrett: Yeah, comment forms and…

Paul: Ok. So you touch there on the fact that one of your pet peeves was the fact that people worry about the design of their forms rather than how usable they are. What over common mistakes are you seeing from people about how they design and implement forms?

Garrett: I think there’s a whole slew of them and I think a lot of it is just worrying about the wrong things or not giving thought to things that matter. My main reason with the designing the form fields is that people are used to seeing form fields and what they look like in their browser, in their native rendering. Sure as a designer having pixel perfect control would be nice but I would hope that most of us who are now designing on the web would have forgone that state of mind where we have to have complete control over everything, it has to look exactly the way we want. A lot of time not only is it a waste of time but it actually hinders usability when those form fields don’t look like what someone expects a form field to look like or button for that matter. When the design becomes design for design’s sake it actually hinders usability in addition to just wasting time. When I initially started developing things it was all about consistency because consistency is easier to implement. If every form field looks the same, behaved the same, is the same size etc. it’s easier to implement because you use the same CSS and you don’t have to put as much thought into it. So while consistency is valuable there’s definitely an aspect of context that a lot of people don’t necessarily pay attention to. In some situations, I think 37 Signals have done a good job on this, they’ll make some fields larger than others relative to the size. In particular in Backpack, their headings aren’t just a form field they are actually bolder and look a little more like a header. They are a little larger font than the body of the note. It adds a little bit of context so that it’s more intuitive as to what the purpose of that field is. There’s a lot of different ways to do it. That’s just one of the more tangible ones. Basically the mistake being focusing too blindly on making everything consistent when there are appropriate situations to break the rules and use context to make some changes. Another one is just dumping a whole form onto the page without breaking it up into logical sections or groups. A lot of times people are afraid of making a form any longer visually because of scrolling. While you don’t want somebody to scroll 80 screenfuls, scrolling one versus eight screens is neligable.

Paul: So you wouldn’t suggest splitting forms across multiple pages then?

Garrett: Well there’s definitely context for that if it’s appropriate. Amazon is a great example there because you’ve got your payment screen and your address screen. It actually can be a fairly complex process but the time you’ve selected several addresses or updated an address, updated a payment method, changed the items in your cart. As you’re jumping around the different screen’s you definitely wouldn’t want all that interaction to try and be contained on one screen. It depends on the size of the form and the context of the form and how interactive it can be, how many potential branches off of that path are there to take. Another would be poor labelling. A lot of the time people label things. This goes back to just naming conventions in general. Just basic information architecture stuff. Whether it follows a corporate naming convention that may not be the right word for somebody that’s not inside the company wall or just simply flat out the wrong word for international [???]. Really anything. Just not putting enough thought into the label. The first thing that pops into your head isn’t always the right thing. Using the wrong kind of inputs so a lot of times whilst… and I have no idea in the world why people would do this… People who for instance who use checkboxes when they won’t use radio buttons and instead they write Javascript to control the radio button. Checkboxes as if they were radio buttons. Thinks like that where I just have no idea what these people were thinking in some of these situations. Just a lot of things like using a radio button or having a yes/no radio button where a checkbox could work. Multiple select lists which are an absolutely terrible interface element to use because a lot of people don’t know you can control+click. If there are small lines and you accidentally slip off that control key and click on a new one, it’ll select that new one and erase all your other selections in that list. There’s different things that kinda get abused and misused in situations where they really aren’t necessiary. A much simpler solution usually exists.

Paul: Yeah. I’ve seen the radio button, checkbox problem and it’s always very amusing.

Garrett: And vice-versa. Where it’s radio buttons and they try and make them checkboxes just because they think it looks prettier sometimes.

Paul: How bizarre.

Garrett: Which I guess is another great example – over using Javascript in forms. It’s one of those things. I don’t know where I heard it but the best description I ever heard of Javascript, Ajax or any of that stuff is that it’s really a spice. If you’re cooking you wouldn’t just dump a whole bottle into your pot. Or you wouldn’t start with a bottle of curry and dump it into a pot and say “OK, now what are we going to make?” You would decide what you are going to make and then think “You know this could really use a bit of curry here”. A lot of people just don’t use Javascript as a spice. It really starts to define the experience and in a lot of situations actually makes it worse or more confusing.

Paul: I presume you would encourage some use of Javascript for example. Things like doing some client side validation as long as it falls back on a server side validation. That kind of thing.

Garrett: Yeah absolutely.

Paul: OK so let’s turn that question around. We’ve been talking very much about the mistakes that people make, but what advice would you provide people about approaching forms? What are the things that they should be doing rather than shouldn’t be doing? I know that in some ways this is going to overlap but is there a particular approach that you take?

Garrett: One of the biggest things I guess is when ever; doing consulting for custom applications or things like that a lot of times we don’t realize that a lot of the complexity from forms comes from the complexity of the business. Whether it’s somebody doing markup or somebody designing a form, a lot of times you know if a business analyst or whoever creates these form requirements and says “here you go design this form.” It has 100 fields and this is out contact form and 80 of the fields are required. A lot of times people just say “okay, it’s my job to implement this. In my experience a lot of business analysts aren’t really familiar with principles of the web and what makes sense. A lot of times the real effort to creating a good form is in educating everybody else about what would be involved. Pushing back in situations like that. Not in a bad way but in a very professional productive way. “You realize that this is going to be a really bad contact form. Nobody’s acutually going to use it. I’ve even heard response like “That’s the point. If people contact us we have to take time a respond to them.” The problem isn’t with the form there, its with underlying things. Obviously that’s a little bit of an exaggeration. The idea is that the best place to start with forms and any kind of interaction like that is with the principles that are underneath there kind of guiding it. With the issue tracker that I am developing, I started out parring back the process of what’s the lifecycle of an issue. Trimming out parts that I didn’t think would really be necessary. I was just looking at it in the context of the lifecycle. I hadn’t even thought about what are the forms going to look like? How am I going to communicate this lifecycle within the context of the application? When it came down to the point when I had to explain how that actually worked, because I had trimmed the proccess and the lifecycle down so much, and it was only 3 steps really, I was able to translate that concept directly into the interface. If I had never actually gone and trimmed the lifecycle down and it had 6 different states that were very cross dependant and this state only is an option when you are in this state… It gets so complicated that even if I could express it in an interface, the code to build it would have been so absolutely unweildly that I could have never created a natural and intuitive inteface. So, I guess really challenging the underlying things rather than just thinking about the things on the surface. And then really just look at every form on it’s own. In it’s own light. What is the goal of this form? Should it be laid out like a traditional form? With one set of “label” “field” all the way down the page and a submit button. Should there be other buttons? Another thing when, I have a fairly consistent model that I am using when I am designing forms in my new application. The main form is for submitting issues and that one form is probably going to get 80% of the useage in this whole system. That and commenting. In the context of submitting issue alot of times you will be in a meeting capturing things as people are talking, capturing issues cause it’s an issue tracker. You want to be able to capture and issue, save it, and move on and capture another one really in kind of rapid succession. So I added an extra button at the bottom that I wouldn’t put on any other page, cause it doesn’t make sense, to save and add another. So it immediately saves that one and takes you back to the data entry screen. You can just continue in a circle and just keep on adding and adding. So really looking at forms and thinking about how are people going to be interacting with this? What are they doing in the real world while they’re using this form? Are they copying data from another application into here? Are they in the middle of a meeting just capturing items in rapid succession. What are they doing? Are they just quickly jotting it down from their iPhone? Understanding that context helps illustrate ideas and different sublte variations that you can do to forms and make them very very practical without adding a whole bunch of extra overhead on the implementation.

Paul: I remember you wrote an article at one stage redesigning eBay registration form. When you wrote about that you talked about the fact that this is a registration form. It is a one off form, and all of the ways that that then informed the way that you built the form. How it affected the positioning of things, and the layout and things, simply because it wasn’t going to be a form that people were using again and again. That’s the same kind of context that you are talking about.

Garrett: Yeah exactly. There’s always a different context to a form and it matters. It is easy to overlook it but that context, and really any design for that matter, context is so important but it is something that…I think that main reason that people don’t pay as much attention to context is because it requires a lot of extra work. A lot of times it’s easier, and it makes sense for kind of a first pass, to make every form look the same. It takes a lot more work to go through and re-invent the wheel every time you look at a form even though, re-inventing the wheel is probably a little bit extreme, to really give it some custom attention. Some tender loving care, just takes a lot more effort that lot of projects don’t have time for.

Paul: You mentioned earlier 37signals that you liked some of the stuff that they were doing. Are there any other good examples out there of forms that you really think are getting it right and are worth us having a look at?

Garrett: Probably the one thing that always jumps to my mind any time anybody asks me about forms is all of the work that Luke W is doing. I hate trying to butcher his name. The stuff that he is doing and hopefully his upcoming book is just really incredible. In depth. He’s done a lot of eye tracking research about label placement and button placement and he’s talked extensively about primary and secondary action buttons. All of his stuff is really incredible.

Paul: So where can people find out about him?

Garrett: I always just google for Luke W to get to his site. Functioning form is his blog. He’s the first hit for Luke W.

Paul: I’ll add it to the show notes. People can get to it via that. That’s interesting. I must admit I hadn’t hear of him so I’ll definitely check that out.

Garrett: He’s one of the, I don’t know his exact title, but he works at Yahoo and he’s got a plethora of presentations about form design and all of the kind of stuff. Really sharp guy.

Paul: And he’s writing a book you say as well?

Garrett: Yes he is for Rosenfeld Media. It’s due out early 2008.

Paul: Excellent. So just to finish us off. A little bit of bile at the end of the interview. Is there any forms that you want to name and shame? Any site that do things really badly that we can all go and laugh at and sneer at?

Garrett: You know that’s a very tough thing to do.

Paul: (lauging) So many out there.

Garrett: Well there are so many out there. But at the same time too there are a lot that seem like they could use improvement but they’re companies that are investing a lot of money and research to improving their forms. So I’m hesitant as an outsider, somebody who isn’t exposed to some of that data, to try and call them out, when they’re probably acutually right on the money. The top two that come to mind that I know are successful are eBay and Amazon. I think Amazon succeeds on the interaction design of their buttons and the flow of their checkout is natural and intuitive but I feel like a lot of their page designs, and it could be a very intentional thing in order to, although I hate thinking that Amazon would acutually do that, to kind of trap people and confuse them almost. If you look at each page in and of itself I think there is a lot of design things that they could make adjustments to that would make the pages easier to understand and comprehend at a glance. I feel like right now their design of their checkout process, or most of their site in general, is very busy and intense. It’s difficult to focus on one element because there’s so many elements. There is very little very intuitive page hierarchy within each page. And they’ve made leaps and bounds, watching the site evolve over the years. But, it still feels like there’s a lot more room for some design consistency for them to introduce. They’re slowly getting there. eBay is another one who, I know they acutually, I forget their CEO’s name, but she declared 2008 the year of user experience at eBay. They’ve acutually invested a lot in trying to improve their forms and really their user experience period. eBay is one that I’ve only successfully purchased something on there once and everytime I try to swim through there I get lost and just give up. Too me any situation like that is just begging for help. I think any form, even the best of the best, even 37signals, everybody is still learning. This is all so new that even the best forms have so much room for improvement. Even my stuff, I come a month later and say “what was I thinking there?” There’s so much work that needs to be done. I think that Luke’s work that he’s doing is probably some of the best and most important work that we’ll see in forms in the near future. He’s starting to really put down facts about what really is good and bad and why it is good and bad. Up until now most of us have just been pontificating based on “well this form is hard to fill out because of errors.” Or you know, the form breaks, or the error message isn’t helpful. Very obvious things. He’s tracking the much more subconcious things that until now nobody’s really dug into and made claims about. It’s kind of a cop out on your question.

Paul: No No. You gave two example there and you gave constructive reasons why they should be improved or could be improved. No I don’t thinks it’s a cop out. You’re just so much nicer than I am. You didn’t go for the jugular that was the only thing. Garrett it’s been great to have you on the show. I think that you’ve given us some real good hints to get going I guess and make some imrovements. It was good to talk to you.

Garrett: Yeah likewise.

Paul: No doubt we’ll get to talk again soon before too long. Especially when you’re issue tracker comes out. We’ll have to get you on hear all about that.

Garrett: Yeah. I’m hoping it will be sooner rather than later but it’s definitely tough to balance the feelancing and paying the bills and making progress on it.

Paul: I know exactly how you feel, we’re doing the same thing at Headscape at the moment. It’s always difficult. Client work is so tempting because it pays the bills here and now.

Garrett: Yup, exactly.

Paul: Okay good to talk to you and we’ll talk again sooon.

Garrett: Sounds good.

Thanks to Lee Theobald for doing the transcription

Back to top

Listeners feedback:

Finding usability test subjects

Our audio question comes from Clare who asks…

"Where do you find your test subjects for more formal user testing"

It can be hard to find good test subjects and I am not aware of any agencies out there that source people for you (although I am sure somebody will correct me).

I think it is worth stressing that finding users who match the demographic of your target audience is not a huge concern. As Steve Krug points out in his book "Don’t make me think" most problems are encountered by any user. That said, where possible it is good to find people that roughly match the specification.

To be honest our approach it is very adhoc. It normally consists of both Headscape and the client scrambling around to see who you can find. The client often has "tame" customers they can ask and we fallback on family, friends and other clients for recommendations.

I should also say my local church has been very handy! A church seems to have a good cross section of ages and backgrounds and an advert in the church newsletter often does the trick. Equally advertising in your local newspaper can attract people, but you have to be willing to pay for their time.

Accessible tables

This week’s email is from Daniel and takes the form of a recommendation rather than a question…

"Could you cover the tips discussed in this article [about accessible tables]? I have seen a lot of tables on the web. Almost none of them uses any of these tips."

The article Daniel is refering to can be found on the Opera developers site, which is a great resource covering all aspects of web development (not just stuff relating specifically to Opera). The specific post looks at how to markup data tables in an accessible format. Since designers have stopped using tables for layout they have become largely ignored. However, if not marked up correctly they can prove a real problem for speech readers. A simple table such as this…

Day AM PM
Monday Meeting Travelling
Tuesday Free time Meeting

…can become impossible to understand when read back because it is read in a linear fashion…

Day, AM, PM, Monday, Meeting, Travelling, Tuesday, Free time, Meeting

However, if marked up correctly it suddenly makes sense…

  • Day Monday AM Meeting
  • Day Monday PM Travelling
  • Day Tuesday AM Free time
  • Day Tuesday PM Meeting

Great find Daniel. These are tips we should all be implementing.

Quick and dirty wireframes

Posted in User experience on by Paul Boag

I am currently in the process of wireframing an internal project that we are working on at Headscape. It occurred to me that despite the fact that wireframes are a fundamental tool of web design, they are not something I have spoken about before.

What is a wireframe?

Fundamentally a wireframe is a tool for rapidly prototyping a website. They roughly approximate the layout, content and hierarchy of a web page as well as the relationship between pages. Effectively you are building a rough version of the site.

Wireframes don’t look attractive. They are not designed as such. Rather they give a sense of how things will be organised on your site. In many cases they lack colour and imagery, although there is no reason why they should. However, they do show visual hierarchy through layout, font size and shading.

Example wireframe

What benefits do they provide?

So why produce a wireframe? Well there are a number of good reasons…

  • They act as a reference point for the designer to work from, demonstrating the relative importance of various screen elements.
  • They can be used to test with. This enables you to ensure users can navigate a site and find key content on a page.
  • They help flush out the details of a site that are often missed. These include things like password recovery and error handling.
  • They help to define interactive elements such as AJAX and Javascript in a way a static Photoshop mockup cannot.
  • They help the client to visualise how the site will work.
  • They identify navigational issues which need resolving.

How to create a wireframe

Once you have recognised the benefit of producing wireframes the next question becomes how exactly do you build them? The answer is largely dictated by two factors; the time available and the complexity of the website.

If you are really strapped for time then simply sketching out some key pages is better than nothing. Even these can be used in testing and shown to the client. However, a sketch does not show interactive elements or the relationship between pages.

If you have a little more time you could produce key pages in a tool like Omnigraffle or Visio. Better still is powerpoint which allows you to link multiple pages together, so creating a basic navigable site.

However, probably the most common way to build wireframes is using HTML. Of course the downside of this approach is that it can take longer if you are overly precious about your code. Personally, when it comes to wireframes I prefer the quick and dirty approach. I create my HTML wireframes using the WYSIWYG editor in Dreamweaver, churning out the pages through a mixture of CSS and tables. I don’t care what is going on under the hood. All I care about is that I can get a sense of how the site would work.

Taking this somewhat cavalier attitude to HTML wireframes is not without its drawbacks. Because the underlying code is a mess, ultimately the wireframe has to be thrown away. A better approach would be to use nice clean semantic code which can then be reused for the final build. However, in my experience this rarely works in reality. The only time I do use this approach is when building a site on our content management system. In such situations it is as easy to rapidly produce pages in the cms as it is in Dreamweaver.

The key to wireframes is for them to be quick and disposable. Wireframes are the place for you to experiment and try out new ideas. They are the place for testing and adaptation, not for being overly precious.

If your site is a simple one then using sketches or a tool like Visio will probably be enough. However, if it is more complex with a lot of pages or interaction then consider using an HTML wireframe. In short use the right tool for the job!

Show 84: Maybe

Posted in Classic shows on by Paul Boag

On this week’s show: Paul explains why Headscape does Design Testing, Marcus talks about growing your web design and Mark Buckingham provides an introduction to Search engine optimization.

Play

Podcast: Download (24.1MB)

Download this show.

Launch our podcast player

News and events

Pagination 101

I came across a great post this week that provides a solid introduction to producing pagination. If you haven’t come across the term pagination before it refers to the navigational elements that allow you to move through multiple pages of results. They often include links marked previous and next or numbers to allow you quickly to jump to a specific page of results.

We use pagination all of the time and most websites seem to have them. However, they are an overlooked function that doesn’t get the attention they deserve. The post I found this week, entitled pagination 101, explains to the reader through examples what make pagination work. Although I am not convinced I agree with everything written here it generally provides some very sound advice.

Personally I love posts like this that cover very basic stuff. It helps remind us not to get so caught up in the cool stuff that we neglect the fundamentals.

Free CSS based design course

John Allsopp and Maxine Sherrin have released a free online course that introduces people to CSS based design. If you are still to make the switch from table based design or are finding the change challenging then I would highly recommend this course.

We are not talking about a short introduction here. Rather, this is an in-depth course that builds up over a series of weeks into a comprehensive guide to building with standards. Not only does the course tell you how to build with standards it also explains why which in my opinion is just as important.

Zeldman says no to Maybe

I wanted to quickly mention a post I saw from Jeffrey Zeldman this week. Its not exactly earth shattering stuff but it caught my eye nevertheless. Zeldman, suggests that it is probably a mistake to use 5 star ratings on websites or indeed any other option which allows a neutral answer. The problem is that if you allow people to rate something between 1 and 5 they will often rate it as a 3 because 3 is the most neutral response.

As Zeldman points out this problem is a lot broader than just 5 star ratings. It also applies to any response that allows for people to be uncommitted. Given a choice people will normally take a neutral stance.

As I said, this wasn’t an earth shattering post. But, what it did drive home is that web design is as much about understanding your users psychology as it is about good design or clean code.

IE Net render

I came across a site this week called IE Net Render that takes free instant screengrabs of your site displayed on IE 7, 6 or 5.5. This is a great way to see how your site is rendering on IE 6 or 5.5 once you have upgraded to 7. Its also damn useful if you are a mac or Linux user.

Of course, there are similar services out there but most of them charge and those that don’t are incredibly slow. What impressed me about IE Net Render was the speed with which it returned results. The only draw back is that it does not return content below its artificial fold.

Paul’s corner: Design testing

Headscape has always used design testing as part of its development process and yet we seem to be in the minority. We are often met with a lot of skepticism about the benefits of putting a design concept in front of real users as well as questions about how the process works. As I have received two emails on the subject over the last week I thought it was about time I explained the idea properly.

I have blogged about design testing. How we do it and why we think it works?

Marcus’ bit: Growing a web design buisness

Got this question from Andrew:

Last year I started my web design business from a back bedroom with very little experience and an old copy of Dreamweaver! I’m pleased to say I’m still here and the business is growing steadily. Your forum and podcasts have been invaluable and offered loads of great advice and support and no doubt helped many others in my position so thank you!
My question for you both is have you any advice on managing the growth and development of a web design business? As a one man band, when is a good time to take someone on, or could I realistically work with freelancers all the time? It seems that to take someone on is very costly (not just in terms of skills) but if I want to expand the business and our services for clients I can’t do it alone. Should I hire someone who can do everything, or someone who can sell leaving me to do design and development work? What are the pitfalls that I should look out for?

Any thoughts or insight into your experiences would be really helpful.

Interesting question, and one we have a lot of experience of but… one I feel I need to add a caveat to. What I am about to say is my personal opinion and does not constitute legal advice!

Ok, the easy bit first:

Sales people

Bless ‘em… we had enough bad experiences of sales people during our tenure at our previous company to know that the only people who reliably sell the services of a web design company are the people that own it.

I’m not saying there aren’t any good sales people out there, just that selling quite highly priced solution based work does not fit well with the standard sales ethos. Sales people like products. They like products with set prices (that they can cut). They like having demonstrable ROI.

Design, in particular, is very hard to put figures to. I can’t tell a company that redesigning their site will boost sales by X or Y percentage. I can talk about brand values and the importance of conveying quality online but I can’t put hard figures to it.

Most web design sales involve responding to a tender with a lengthy proposal and subsequent pitch that is tailored for that particular prospective client. It usually draws from all aspects of the business – design, technical, consultancy – and therefore needs someone with a good understanding of the business to put it together. I.e. the company owner/director.

Who to employ

Headscape currently includes the following general production roles:

  • Designer
  • Developer
  • Project manager
  • Information architect
  • Testing facilitator

Again, the directors tend to share IA and testing with the project managers. Project managers are invaluable members of any team but if you are looking to employ your first member of staff you need to get a designer or developer on board first.

Look at your own skills and see where you’re lacking. Maybe filling the gaps is the right way forward. However, that may only be appropriate if you’re looking to take on more complex work and simply doubling up on what you already have may be the most prudent move. Often, a new project win will point towards who the right person is.

When we started we had Paul doing design and some technical work, Chris doing project management and me doing sales. At the time, we had a great client that kept firing Flash work at us. We outsourced a couple of times but eventually ended offering a permanent position to one of these guys (he is still with us, as is the other guy who we outsourced to then!).
You mentioned hiring someone who can do everything – Chris, who was the first guy to join us, is a bit of a jack-of-all-trades so was perfect for us at the time. As we have grown though, we have looked for more and more specialist people.

Permanent or freelancer

Taking on freelancers can often mean the difference between being able to deliver a job or not. However, they are expensive and will badly erode your bottom line if you do it all the time. So, ask yourself – if I had an employee instead of a freelancer over the past X months, how much would I have saved?

Employees are a responsibility though and need looking after . One thing we have learned over the years is that happy staff make for more productive and more effective staff. As we have mentioned recently, Headscape has started encouraging everyone to spend a few hours each Friday afternoon working on anything they like. We get together monthly to present our ideas to each other – best idea wins something cool.

But sometimes you have to have to be prepared to make some very tough decisions. The bottom line is that the company always comes first. One final point though – and in the words of the late, great Douglas Adams – don’t panic! It is very easy to see things as much worse than they actually are.

Ask the expert: Mark Buckingham on SEO

This week we have Mark Buckingham on the show from netseek.co.uk to introduce us to the world of search engine optimization.

Mark helps dispels some myths surround SEO. He discusses best practice and talks about specific techniques such as keyword density and link popularity.

To be honest I felt like we only just scratched the surface of the subject of search engine optimization and would be keen to speak with Mark again. Its such a massive area that it is hard to know where to begin. So, if you have any specific questions you would like answered on SEO then drop me a line at [email protected] and I will get Mark back on soon.

Book recommendations

Finally, I just wanted to let you know that I have finally sorted my act out in regards to my reading list. One of the most common emails I receive asks me if I can recommend a book or what I am currently reading.

Now, I posted a list of recommended books ages ago but I never got around to updating it. Well I have finally done so and also gone a step further by creating an RSS feed of any books I read (be warned these will not all be web design related).

I promise to keep both the post and RSS feed up to date from now on!

Getting online forms right

Posted in Design on by Paul Boag

At the end of last week, I was integrating an online survey into a client’s site. It started me thinking about how difficult it can be to get online forms right. In this post, I outline just some of the many things you should take into consideration.

With the exception of the home page, online forms are probably the biggest challenge to us as web interface designers. This is largely because online forms require a higher degree of interaction than any other part of a site and so there is more room for error.

Web Forms Checklist

With that in mind, here is my checklist for designing an effective web form:

Make a form look like a form

Too many designers mess with form fields so that it is nearly impossible to identify them as editable. Sure, form fields can look ugly but there visual appearance helps people identify them as a form. Some styling is fine but don’t make them unrecognisable.

Stay focused

Everybody hates getting spam. We are suspicious of giving out personal information online for fear that the information will be used to send us junk. Do not ask users for information that you do not absolutely require. They will tend to see anything extra as an invasion of their privacy and an attempt to spam them.

Keep it short

Marketing departments have a habit of wanting to know everything about their visitors. The result is that forms become overwhelmingly long and users just don’t bother completing them.

Turn long forms into applications

Once an online form goes beyond two screens, it’s often a sign that the underlying functionality is better supported by an application, which offers a more interactive user experience.

Provide timescales

If the user cannot see how long the form is, they will assume it takes a long time to complete. In many cases, they give up before they begin. Reassure the user that the form will take only a few minutes of their time.

Inform of progress

If a form is split over multiple pages, the user can be left wondering how many more screens there are to go. I have seen people give up only one click away from finishing! By telling them how much of the form is left, you encourage them to persevere.

Only show relevant fields

Some fields in your form maybe conditional on other answers given. For example, you may have a question "Do you have children?" and a second question "How many children do you have?" Obviously if they answer no to the first question then the second becomes irrelevant. Make your form appear shorter by either combining these questions or only revealing the second one if they answer yes to the first.

Use the mandatory fields sparingly

Forms failing to submit properly because mandatory fields were not completed can be an annoying experience. It is therefore advisable to use required fields only when entirely necessary and to mark clearly, which fields are required.

Avoid re-entry

There is nothing more annoying than constantly inputting the same information. Store users details so that reoccurring fields are pre populated. Also make sure that information is not lost if the user accidentally navigates away from the page.

Clear validation

It can often be hard to spot which fields you failed to complete correctly. By clearly marking the problem fields, you dramatically improve the user’s experience.

Avoid reset buttons

Personally, I don’t think it is worth having a reset button on a form anyway, but when you do ensure you don’t put it near the submit button. It is very easy for users to click the wrong one and find themselves back at square one.

Highlight the current field

On long complex forms, it can sometimes be hard to spot which field contains your cursor. Use CSS or JavaScript to highlight visually the current field.

Ensure a logical tab order

Many visitors use the tab key to move between fields in a form. Make sure the fields tab through in a logical order and where possible remove tabs from elements such as labels or links where that interrupts the flow of the tab order.

Use fieldsets and labels

Usability for speech and text browsers is dramatically improved by marking up your form with the relevant fieldsets and labels.

Place labels before fields

Because visually impaired users cannot see a form field, they are reliant on the label associated with the field to describe it. However, if the label appears after the field they are not told what the field is for until they have moved past the field itself.

Offer an incentive

Because forms often require users to part with personal details, they are naturally reluctant to complete them. Users need a clear incentive to part with their information. What that incentive is depends on your site. For some it could be as simple as access to site features such as a forum, for others it might be an entry into a price draw or a free reward of some kind.

Explain the need for information

When you are requesting personal information, explain why you require it. For example, if you request an email address for an ecommerce purchase, explain that it is required for informing the user of their orders status and nothing more. If you don’t explain, they will presume the worst.

Clear help

For more complex fields make sure you provide clear instructions. For example if you require the security number from a credit card, explain where this can be found and what part of the number you require.

Saving forms

It is generally good practice to allow users to save forms and return to them later. This is particularly true of longer forms where the user might have to look up some of the information required.

Your opinion

So, that is my checklist for designing forms. Did I miss anything? Do you disagree with anything I have said? Let me know what you think.