Web Design News 15/06/10

Posted in News on June 15, 2010 by Paul Boag

This week: We look at emerging trends coming from Web Direction @Media including microcopy, HTML5 and CSS3 and inclusive design.

Relly talks about microcopy

The one talk I am most passionate about is Relly Annett Bakers talk on Microcopy. As web designers we constantly moan about the quality of copy produced by our clients and yet make the problem worse by producing poor copy of our own.

The problem is that we think we don’t write copy. However that is simply not true. We are forever writing error messages, instructional text and labels. We are also involved in information architecture where we make decisions about the naming of navigation and page elements. All of this is copy.

Whether you get to hear Relly’s talk at @media or not, it is worth learning about best practice in microcopy. Fortunately there is no shortage of online resources available.

For a start Relly has written extensively on the subject including her 24 Ways post ‘construction of instruction‘.

However this is a subject others are tackling too. Joshua Porter has written a great post entitled ‘Writing Microcopy‘. It is well worth a read and is a brilliant introduction to the topic.

example of microcopy from Joshua's article

Finally Joshua has also created a Microcopy Flickr Group which showcases great examples of microcopy. If you are looking for some inspiration as you write, this is a great place to start.

Bruce and Rachel talks about HTML5 and CSS3

Unsurprisingly this years @Media will be focusing on HTML5 and CSS3 with a number of great talks including ones from both Rachel Andrew and Bruce Lawson.

Without a doubt these are really hot topics and open up a world of possibilities for us as web designers.

Of course this is also a topic that has been done to death online. However because there is so much material it can be hard to know where to start. That is why being able to see a presentation from the likes of Rachel or Bruce is invaluable.

That said, there is some material out there worth checking out.

When most people think of CSS3 they think of border-radius, gradients and shadows. There are literally hundreds of articles dedicated to this subject. However there are also a couple of tools for those of you who cannot face yet another blog post.

The first is a simple tool for generating border-radius code. Simply type in the values for each corner and it creates the code for Mozilla, Webkit and the W3C spec.

The second tool does a similar job for gradients, box shadow, text shadow and transforms.

A tool for creating advanced CSS3 effects

However, CSS3 isn’t just about new effects. As Rachel Andrew points out in her 24 Ways article it can also help you create cleaner code.

As for HTML5, I have seen Bruce talk about coding in HTML5 before and it is well worth watching. He demonstrates just how easy it is to start coding HTML5 today even though the spec is not fully supported across all browsers.

Bruce has written extensively on the subject of HTML5 as a quick Google will testify. However I recommend you check out his website html5doctor and a previous presentation he gave that introduces HTML5. Both provide a great starting point.

Inclusive design

The final talk I wanted to highlight is Inclusive Design by Sandi Wassmer.

Inclusive design is not a term I have come across before, which is why this talk interests me. However according to Sandi it brings together Accessibility, Usability, User Centric Design, Progressive Enhancement and User Experience. It recognises that a ‘one size fits all’ approach is not always appropriate and that we need to provide users with more choice in how they interact with our content.

I get the impression Sandi chooses to talk about inclusive design rather than accessibility because accessibility is so strongly associated with the disabled and in particular those who use screen readers.

In fact accessibility is a much broader subject that includes accessibility for all, even those who still use IE6!

Sandi has actually created a very interesting PDF on the subject of inclusive design that is worth downloading. It will certainly get you thinking in a different way about what it means to make your website accessible.

Web Design News 27/04/10

Posted in News on April 27, 2010 by Paul Boag

This week: Is the homepage dying? Everything you need to know about HTML5 and CSS3. Solve problems rather than add features. And why you shouldn’t be tied to a process.

Everything you wanted to know about HTML 5 and CSS3

There has been so much talk about HTML5 and CSS3 that you could be forgiven for zoning out.

If you are like me, you know it sounds cool. However you are having trouble keeping up with what exactly it all does and if you can use it now.

Fortunately there are a couple of resources that will help bring clarity to the situation.

The first is a presentation that covers advances in Javascript, HTML and CSS. What makes this presentation unique is that it demonstrates these upcoming technologies as well as explain them.

Presuming you are using a good browser (the author recommends Chrome) you will get to see everything from native video to CSS gradients in action. It also comes with code that you can just copy and paste to get started.

The second resource is a compatibility table that shows browser support for HTML5, CSS3, SVG and other upcoming web technologies.

Sample table from the compatibility application

You can configure the table to only show the technology you are interested in (e.g. CSS3). However the nicest thing is that it provides a judgement about whether you can start using that technology today. It also explains why it has made that judgement and what browser is limiting its adoption.

Both resources are worth a look if you want to start adopting these emerging technologies.

The decline of the homepage?

Gerry McGovern returns this week with another controversial post. This time he is claiming the decline of the homepage.

He begins by quoting some figures on the decline in homepage usage:

In 2003, 39 percent of the page views for a large research website were for the homepage. By 2009, it was down to 19 percent.

Another technology website had roughly 10 percent of page views for the homepage in 2008, and by 2010 it was down to 5 percent. One of the largest websites in the world had 25 percent of visitors come to the homepage in 2005, but in 2010 only has 10 percent.

I have no reason to doubt these figures. However, I am not sure they reflect all websites. That said, I do think the principle stands. As Gerry points out…

Years ago people might have thought about getting to the homepage and then figuring out where to go on the site. Now they will use search or external links to get closer to the place they really want to get to. So, for example, people are becoming less likely to simply type “Toyota” into a search and more likely to type “Toyota recall”.

google search

Does that mean the homepage is no longer important? Not at all. It is still an essential navigational tool which users rely on to orientate themselves on a site.

What this post does demonstrate is that political battles over homepage real estate is pointless. The homepage is no longer as critical as it was.

While on the subject of homepage design, I also wanted to quickly mention ‘How To Develop A Homepage Layout That Sells‘. Although not the best article on the subject it does tackle one aspect well. That is the need to prioritise around objectives, rather than allowing features to continually accrue on the homepage.

The process police

I share a lot of techniques, methodologies and processes on Boagworld. From advice on wireframing to top tips for creating an effective call to action. These posts help us to learn and provides structure within which to work.

However it is important that these kinds of posts (whether on boagworld or elsewhere) are seen as guidelines or advice, not as laws that need to be obeyed.

This is something that is covered in ‘The Process Police‘ a 52weeksofux post.

Image of riot policeman

Ryan Rodrick Beiler, Shutterstock

In this post Joshua refers to people he calls process police. These are people who cling to processes as a kind of mantra for improving their websites…

Process is their crutch. The Process Police believe that if they follow the process to the letter, then they’ll be more successful than if they don’t. They use process as a benchmark for success.

However, in reality the world doesn’t work like that…

No process guarantees success. If there were a process that guaranteed happy users everyone would be using it. But design doesn’t work like that: it’s iterative, responsive, ever-changing. You have to react as much as plan. You have to change your process on the fly to react to the marketplace.

Just remember the next time you read an over confident author talking about the ultimate way to produce a persona, that there is no such thing as a perfect way. Take from the article what works for your site and your users, then leave the rest.

Solve problems rather than add features

Let’s face it we all enjoy something new. Designers like the latest design trends, developers want to play with new technology. Even website owners always have endless ideas for new features.

Unfortunately our enthusiasm for the new can get the better of us sometimes and we focus on that rather than meeting the needs of users.

An article entitled “Does your website add features or solve problems?” addresses this attraction towards the new by encouraging us to focus on solving problems rather than adding new features.

iphone

The author sums the problem up perfectly…

This eagerness manifests itself as a superfluous new feature, an implementation that is stimulated by a common misconception that adding more features is a market advantage. This couldn’t be further from the truth.

In reality the solution to users problems often lies in taking stuff away rather than adding it.

The post looks at the benefits of simplifying your website before suggesting some ways you can ‘be a problem solver and not a feature inflator’.

Its a great little post that focuses the mind back on what matters and curbs our enthusiasm for the new.

HTML5 and CSS3 with Inayaili de León

Posted in Development on April 6, 2010 by Paul Boag

More from show 200: Inayaili de León tells us that we can be using HTML5 and CSS3 right now.

Paul: Best talk of the day! Yeah, you can come and join us – you can throw out Drew. It’s really good to have Inayaili on the show. She is one of those quiet yet very significant figures within the web design community, that is there in the background doing some absolutely great stuff. I think she has been writing some stuff for 24 ways recently, which was very good, really enjoyed that, and has got some other great stuff going on, so we welcome to the show Inayaili.

Hello Inayaili.

Inayaili: Hello.

Paul: It’s really good to have you on. Thank you for coming all the way to the … I was going to say studio.

[lots of laughing]

Inayaili de Le%C3%B3n

Image Source

Paul: [exaggerated voice] “Thanks for coming into the studio today”. So, we are going to have a bit of a chat about CSS3?

Inayaili: Yeah.

Paul: I thought I better check that. Ryan? Is that alright for you? CSS3? Yeah, it meets Ryan’s approval as well, so that’s really good. OK, we have kind of been building to this all day really, we have kind of mentioned CSS3 a couple of times.

Inayaili: I don’t know if you have noticed but I think we are halfway, euh…

Marcus: We are, this is halfway

Inayaili: … through the …

Paul: Of for fuck sake.

Marcus: We only have got six hours to go.

Paul: Ooh, whoa.

Marcus: I can’t work out, my recording thing I am doing here, says I recorded seven hours of audio. How can that possible be? Oh, it starts on 1, that’s why.

Paul: Because the whole space time continuum is [???]

Marcus: I answered my question. It starts on one hour.

Paul: I have got far too many windows open here, let me close some.

Marcus: Yes, we are halfway – jipee!

Paul: Wow, that’s worth celebrating. I am getting really cold in here as well.

Marcus: Shut the door.

Paul: Shut the door. Is that alright for a minute. Is everybody else getting a bit nippy? Good stuff. Right. Halfway joke by Marcus. That’s a good idea, as we got a few minutes.

Ryan: What’s that good one, you had …

Paul: Go on Marcus, go on my son. Will you hang a minute, I …

Marcus: Someone actually send me an email with a joke, but I can’t remember if it was any good or not.

Eum, am I allowed to tell a blond joke?

Paul: After I have just been telling everyone off in the chat room, for commenting on people’s personalities and personal appearances, and stuff like that, and then YOU want to tell a blond joke.

Marcus: Eh, eh, peoples … do you want to be more detailed about that at all, Paul?

Paul: No.

Marcus: No? Ok. Euhm, …

Ryan: Why would you [tails of into a giggle]

Paul: Strange Marcus, I don’t understand it. I have only been working with him seven years.

Marcus: No, I don’t want to tell that joke, it’s rubbish.

Paul: Goh, blooming heck, take your time mate. We’ll just sit here.

Marcus: Here we go.

[Cow jingle kicks in]

Paul: Oh, for crying out loud. That, that has to go! That was the thing that was endlessly looping.

[Jingle stops]

Marcus: Yes.

Paul: [reads from the chat room comments] “Paul has an actual egg for a head.”

Ryan: Excuse me, what is your conversation about?

Marcus: An actual head. There is a joke.

Ryan: We can’t keep people from following.

Paul: Yeah, I understand that. Can we kick that person? Actually there are a few people being a bit dumb.

Marcus: I can do a Christmas joke.

Paul: Yeah do … Nooo!

[background laughing]
[...]

Marcus: Blame them!

[giggling]

Marcus: Two men, two snowmen standing in a field.

Paul: Yes.

Marcus: One says to the other: “Do you smell carrots?”

Ryan: Carrots for noses.

Marcus: That’s actually quite a good joke. I know it’s kind of traditional not to have any reaction, but that is not a bad joke.

Carry on.

Paul: Is that it? Can we move on now? Let’s talk about CSS3.

Marcus: Oh no, I am just going to interrupt.

Paul: Let’s talk about …

Marcus: That’s a good set of interruptions.

Paul: You’re not going to interrupt Inayaili, because she is far too nice.

Marcus: No, I am going to interrupt you.

Paul: You can’t do that, it would be like …

Ryan: She came all this way.

Paul: It would be like, I was going to say kicking a puppy, but people get upset about that.

Inayaili: And I brought cupcakes.

Marcus: Yes, exactly.

Paul: And you brought cupcakes. Yeah. That’s made up for the fact that Relly couldn’t be here. In fact we ought to have the cupcakes brought in. I feel they should be coming in.

Right. Let’s talk about CSS3 and get to grips with some of it. Can we start really basic for people, because not everybody has the time to kind of look at CSS specs and read all the articles on it. So give us a really good idea of what kind of things does CSS3 allow you to do.

Inayaili: Well, I think the main thing it allows you to do is to have a cleaner mark-up. So when you are creating your HTML you can have a much more semantic, with less classes, with less id’s, markup. And it allows you to target some elements without adding a class.

Paul: Right. So we are talking about the improved selectors there. Things like the nth child.

Inayaili: Yeah. And then of course there are the other, more visual things: like adding text shadows, and border radius and box shadows and stuff, much more easily.

Paul: Sure. OK. So why, you obviously started talking a lot about CSS3. Why have you got excited about it? Presuming you are.

Inayaili: Yeah. Exactly because of that. I can just create the most, cleaner markup possible, without having to create lots of divs, and lots of spans, and all that mess we used to do before, and so much more flexible. You don’t have to have Javascript to do some things, and especially because I don’t really do Javascript. So I like to do things in CSS – if I can.

Paul: There is an argument, isn’t there, you brought Javascript up there, that some of the things you can do with CSS3, actually begins to kind of stray on the territory of being behaviour, rather than design. You could argue things like hover state is already an example of something that is actually behaviour. So should we be doing those kind of things in Javascript, really? If we are going to be all semantic and all kind of correct about it. HTML is your content, CSS is your design, behaviour is your Javascript. Should actually these things be done in Javascript or is that just a bit [tails off]

Inayaili: I think that, euh, I am going to give the easy answer: It depends.

[Laughter in the room]

Inayaili: But, euh, it really does depend. If it is something, just a nicety, something that is going to be a little detail on the website, it’s not really crucial to be visible by everyone, and it can be easily done in CSS, much easier than with Javascript, then why not?

Paul: Yeah, absolutely. I think it is about pragmatism, isn’t it.

Inayaili: Yeah, exactly.

Paul: You do what the right thing is in any particular circumstance. I mean the other, I guess argument, against doing lots of CSS3 at this stage is one of browser support. Talk us through a little bit where things are with browser support, you know, what supports what and you know what can you start to do. You probably don’t know it all of the top of your head – that’s a really unfair question. But what is, you can be general, fudge it, make it sound like you know what you are talking about [laughs].

That’s what I do.

[Laughter in the room]

Paul: You don’t remember exactly what every single CSS is supported by what version of a browser – or is that just me who doesn’t know stuff like that.

Inayaili: Yeah.

Paul: OK. I’ll shut up at this point. Now then, would you like to answer that question and dig me out of the hole, thank you.

Inayaili: Yeah, well, it’s very hard because Internet Explorer, until 8, still doesn’t support CSS3, CSS3 selectors, so it is quite hard knowing that the most used browser from 6 to 8 doesn’t really support that. So you have to be careful in a way, you have to look at your stats, you have to see what your users are browsing the web with. But I think that most things are supported by Firefox, Safari, Opera and then CSS3 is not supported by IE.

Paul: OK. So how then do you justify doing work with CSS3, when there is so much dogginess surrounding the support, and it is so patchy, and things like that.

Inayaili: Well, in terms … One thing that I really like using with CSS3 is the advanced selectors. They just make your life really, really easy. Like if you are styling text, adding margins to paragraphs, and headings, and stuff like that, you can do it much more quickly with CSS advanced selectors. And if some browser doesn’t have a specific margin or a specific padding it is not going to break the layout. You have to be careful that way. There is also some nice Javascript plugins they have been made recently to support the CSS3 selectors for IE. That is really, really helpful. And I also usually use a tool that is called Modernizr, to [tails off]

Paul: Yeah, we mentioned that earlier.

Inayaili: So, you can kind of, euhm, it’s not having doubled the work, it’s not having to do the CSS for one browser, and then for another browser, with Modernizr you can kind of adapt your design based on which CSS properties the browser supports or not.

Paul: Sure. I mean, you wrote, I just had it on the screen. You wrote an article. This is just a little bit a move away from CSS3, but it does kind of all relate. You wrote an article for 24 ways, euhm, about having a field day with HTML forms. Which I thought was really interesting about some of the new stuff that can be done with HTML5 as well, and kind of combining that with CSS3.

Inayaili: Yeah.

Paul: Do you want to talk through some of that kind of stuff? That was a really interesting article and not everybody has probably seen it.

Inayaili: Euh, about what I talked on the article?

Paul: Yeah. You can’t remember, can you?

[Laughter in the room]

Paul: I wouldn’t be able to, and I can’t even remember what I wrote about this [year?] It’s nothing like throwing a curve ball in, isn’t there?

Marcus: I’ll save you for a minute, because I just love, a tweet from Matthew Panel [spelling?] here, which is: “Jeezes, is this Boagworld stuff still going on? Damn A-listers wasting my bandwith.”

[Lots of laughter]

Paul: Get him on the show. Tweet him back and say “Come on”.

Marcus: Yeah, ok.

Ryan: We can get him on Skype.

Paul: If we can get him on Skype, get him on.

Ryan: Get him to ring Boagworld.

Marcus: He is complaining about the lack of John Oxton on here.

Paul: Ooh, why didn’t we get John Oxton on?

Marcus: Because I can’t think of everything.

Paul: But I rely on you to think of everything. See, I just think it is quite interesting. I have got to say, I have got to be honest with you, that I haven’t, that I haven’t looked massively into HTML5, and CSS3 yet, I kind of know what they do in principle. I have had a little play around with them, but I have not actively used them yet, because I keep feeling it’s not quite there, it’s not quite time. But I think to some degree…

Inayaili: I disagree.

Paul: Yeah. I know you do, and that’s what I am interested in, because I think somehow, I am falling into something I know is wrong, and I know a lot of other web designers feel, they look at something like CSS3 and they go: “Oh, browsers don’t support CSS3″. Like it’s a blanket statement – if that makes sense. You know, that CSS3 has been taken as a whole, you know where some bits of it do have support – which I guess would be your argument, would it?

Inayaili: Yeah. I think people just dismiss it by principle and don’t bother looking at what could be done. They shouldn’t be doing that really. You should definitely …

Paul: I feel told of.

[Inayaili giggles]

Paul: Yeah, but, I mean there are some things that are … It is true it is not a thing set in stone, like box shadow has just been dropped from the spec, so … Has it really?

Inayaili: Yes.

Paul: But I like box shadow.

Inayaili: Yeah, I know, lots of people did. But the specs were just too complicated. There was no consent as to how it was supposed to work, so they just decided to drop it for now. For now.

Paul: For now? But that is a classic example of something. You see that just makes me worried. Because I would have used box shadow.

Inayaili: Yeah, but if you had actually read the specs, you could actually see.

[Consternation and laughter in the studio]

Paul: I feel under attack here.

Inayaili: You could feel that vibe that this isn’t really working right, that well.

Paul: Right.

Inayaili: There were lots of red notes saying: “Is this really right?”, “Maybe we should forget about this for a while”.

And even in other things like: I was just reading the text spec on my way here, and if you go to the spec it says: “we are considering removing multiple text-shadows”. So a text will only be able to have one shadow, and if you actually follow the development… I mean you don’t actually have to read the specs. One very good thing that I actually think people should have to do is at least subscribe to the decisions that are made for the CSS. It is something like every two weeks or something? It’s like a five line post. That only tells you ok, CSS box-shadow has been dropped, and it’s something that will be useful. And if you are interested it is something that you should …

Paul: Because that’s the big thing. You have actually answered that. I was going to come back with an aggressive response, but you have answered that. Which is I think is, the average web designer feels like they are sinking under todays work. They try and keep on top of what is relevant right now, just to keep up, you know it feels like a race web design, you know, trying to keep up all the time. And then you’re turning around and say now we have to read W3C specs. I am not Jeremy Keith, I prefer to put a bullet through my head. You know? And here you are saying that there is actually a nice little summary you can subscribe to. Where can you get hold of that?

Inayaili: If you search for, I think it’s like CSS3 workgroup, or something like that.

Paul: CSS3 working group [typing]. See what we get back. We have got 12 hours to waste so… [laughs]

[reads search engine results]CSS current work.

Ryan: This is the future Paul, it is not a waste.

[Laughter]

Paul: So here we go. Here is the …

Inayaili: There is probably a blog link under navigation.

Paul: “blog“, yeah, I got it.

Inayaili: So, that’s the short summary.

Paul: Oh, that’s the summary? So you can just subscribe to that blog? And you get a nice little summary.

Inayaili: It’s not like you are going to get a five posts a day, it’s very random, I think.

Paul: Now, I have got to say, this is not the most friendly document in the world. I have just read the first line.

Inayaili: You don’t have to …

Paul: [Reads from the document] “CSS WG has no problem with depreciated DOM active”.

Inayaili: No, you don’t have to understand everything. I don’t understand everything.

Paul: Oh, OK.

Inayaili: But some things are relevant and occasionally there are some relevant things, like OK, box-shadow, which has been dropped. And you would have…

Paul: And I would have gone into a panic. An run like: “[Shrieks] I have been using that!”

Inayaili: Yes, exactly.

Paul: So what, I mean that is a big issue. You know. If I kind have gone to a client and designed them a site and I had used box shadow. Sorry, I am being quite pushy over this, but you have been to me, so … And then suddenly that has been removed from the spec and is removed from support in the browser. That site is going to break. And they are going to come back to me, quite justifiably, and say “Why did you use an unsupported, unset in stone piece of technology?”

Inayaili: Euh, well, in that case the site wouldn’t break without box-shadow.

Paul: Yeah, the box-shadows would just disappear.

Inayaili: You just wouldn’t have the shadows. So you have to be careful that way.

Marcus: There is also the argument that if you don’t pay attention to what is happening on the W3C and you don’t contribute to the talks and discussions, then you can’t complain about specification, because you have shown no interest in it, and you have not contributed to any of this.

Paul: You have got to vote, otherwise, …

Marcus: If you are not going to be involved with it, and you are not going to talk about it, then you can’t complain about it.

Inayaili: One thing that is also important to understand, and I was just talking to Jeremy Keith outside, and he agrees, is that you don’t have to use the CSS3 to contribute. It’s very useful if you just go there, if you just try a few things, you don’t have to read the whole thing. That’s quite boring. But if you do your own things, try a few experiments, see how stuff could be used in real life, and then you send them your examples, or you send them your comments with an explanation on why you think something won’t work or something won’t be useful. And that is something the W3C are always looking for, like real examples to base the specs on.

Paul: Yeah, I mean it is difficult, isn’t it? Because, you know, OK, I just keep coming back to this. An everyday designer like, you know, I don’t know, Ed sitting through next door, doing his work in the other room right know.

Marcus: Will he be offended at that? Everyday he designs.

Paul: But he is!

[Laughing]

Paul: Alright, but he is not, he is NOT Jeremy Keith. Do you know what I mean?

Marcus: Nobody is Jeremy Keith.

Paul: He doesn’t, he can’t think conceptually. So what I am saying is that only a certain group of people is getting to really play around with this technology, and really… you know there is people like Andy Clarke, people like Jeremy Keith, that got the time, because of where they are in their careers …

Marcus: They are not being [..] by bullying project managers.

Inayaili: I don’t think it is because they have the time. I think it is because they are really, really interested in what they do.

Ryan: Yeah, outside of work it’s not. It’s not just a work thing, they do it in their own time.

Inayaili: I think if you really, really – I don’t like using this word, but passionate – about what you do, you will have an interest outside of 9 to 5.

Paul: Oh, absolutely, I do agree with that. I do agree with that. I also, there is a question if, you know, do you have to be, I am trying to think of the term, do you have to carry a certain reputation before anybody takes a blind bit of notice of you. You know, if I …

Inayaili: No.

Paul: OK.

Inayaili: The other day I was writing a very short post for my blog about the use of multiple columns in text and I was just doing some very basic examples just to try, just to make sure the example was working, and I was trying in Safari and Firefox and I noticed that one thing, it just wasn’t doing what the spec was telling it should be doing. And I thought: “Oh, maybe I just should report it to both Safari and webkit and Mozilla”.

Paul: Right.

Inayaili: And I just did a quick comment on the bug report website and it was actually like five minutes later it was actually introduced as a bug in Firefox.

Paul: Oh.

Inayaili: So, it doesn’t matter who you are.

Paul: That’s brilliant.

Inayaili: You can contribute.

Paul: So in your experience it’s been a very open process.

Marcus: It’s just about being bothered basically. Isn’t it?

Paul: Yeah.

Inayaili: Yeah.

[Laughter]

Paul: You see. But perhaps, it is just me or not, or a lot of other people, but you just presume you are not really going to get anywhere. You know, that you are just another voice in the crowd.

Inayaili: Yeah.

Paul: Perhaps I am being naive. You have been involved a little bit in this kind of process as well, aren’t you? Rachel? What has your experience been of dealing with these working groups and talking to them, and that kind of stuff.

Rachel: Certainly in the past with web standards project things. I suppose my experience is always been fairly positive. In that I think that generally, groups are just interested in what you have to say.

Paul: Right.

Rachel: You know, I don’t think there is any kind of wall up that says: “No, we only listen to people with this kind of reputation”, or whatever, but you know, …

Paul: Oh, that’s good.

Rachel: I think, it’s … you just have to get out there and start talking about stuff you care about really.

Paul: Right. I think that’s brilliant. You changed my view over that. I made perhaps assumptions that were false in that situation.

Inayaili: And for that example I just gave you, I didn’t have to read the whole spec, just to do my bit, I was just literally reading a very small proportion of the spec, just to write that quick blog post. And I came across a bug.

Paul: So is there any other kind of, moving on from that a little bit, is there anything else you get really excited about CSS3. There are people out there, that are like me, and maybe haven’t done their homework as well as they should be. What do you want to let them know about, that will make them go out there and get them stuck into this, and having a look.

Inayaili: I started to be really excited when I started to understand how CSS3 makes my life easier.

Paul: Yeah.

Inayaili: And, makes clients have to pay less, because you are spending less time dealing with some things that would take a long time, to work cross browser.

Paul: Can you give me a really good solid example of that. You know, what could I do with CSS3, that would make my life simpler.

Inayaili: Well, I am just looking at the example of the 24 ways post. And it just makes your life simpler coding forms in a big way. You can target different types of input and different labels, very easy.

Paul: So, this is using those advanced selectors, you were talking about.

Inayaili: Yeah.

Rachel: And I think another thing that I have certainly found, but I wrote on 24 ways about that as well, is in situations where you don’t have control over the markup. And that happens quite a lot.

Paul: Ahaaa!

Inayaili: Yeah.

Rachel: It’s that, if you are dealing with some CMS for instance, that spits out a load of markup, and you want to put rounded corners on something, or you might want to inject markup into that. But you can still target that CSS3, and have the effect.

Inayaili: Imagine you have a table, a data table, and you want the rows to have different colours.

Paul: Alternate.

Inayaili: Like you want red, blue and green. Red, blue and green. Red, blue and green. You can do that with CSS in like literally 30 seconds.

Paul: Rather than having to put a class on each one.

Inayaili: Yeah, and if you are really worried about “Oh it won’t show up on IE”. You can use one line of jQuery, or a little Javascript plugin and it will work, if you really … It’s not something that is going to affect massively the look of your website. It is just a background colour in a few rows. But it’s just instead of building this very complex Javascript thing, you can do it in CSS like that.

Paul: I mean, that I really, really get. We got a client at the moment where that is a perfect example. They got a website of something like 33,000 pages, it’s a big institutional website. And, you know, we are redesigning their site, and it’s all in a content management system, and all that content has been put in, you know, by various content providers. And we now got to go in, and that content has got to remain the same, but we have to redesign the site around it. So the HTML is staying the same. So it’s a really good example where maybe some of these advanced selectors will be really beneficial. And after all isn’t that what we said about HTML?

The Zen Garden right back in the early days. “You can change the whole look of your site without changing the HTML”, but really, we were fibbing a bit, weren’t we, until relatively recently. You would have to put bits in it.

Inayaili: If you have to go to the table and actually add a class in it for each row, you are doing it wrong. Well you are not doing it wrong, but you are over complicating.

Paul: You are not living the dream.

Rachel: And it is presentational as well. When you are sticking that kind of markup in, in your document it’s actually you are doing it, because you want something, it’s a presentational thing, you want to make striped tables. You shouldn’t have to stick something in your markup to make striped tables.

Paul: Yeah.

Rachel: It’s completely a presentational thing.

Paul: Yeah, completely. Ok, that, you have got me. You have convinced me.

Inayaili: Good.

Paul: You have got me on board. And actually, the bit that gets me most is that it takes us one step closer to that real ability to separate content and style. And THAT I am entirely behind. Especially for some of the, you know, the big clients that we deal with, there websites are too big to be changing huge amounts of content, so that is brilliant. And even for smaller websites, that’s obviously still very very relevant stuff.

Inayaili: But even for a smaller thing. Imagine you have a list of items and you have a margin for every item in it, and you don’t want the last one to have a margin, because it doesn’t need a margin and if it does have a margin in IE6 it is fine, but you can remove that with CSS from all the other browsers.

Paul: The other idea that always gets me, is that when you have a menu item, and you divide the menu item with a border-bottom. I bet you don’t want it on the last one, you can remove it. If it’s there it’s not the end of the world.

Inayaili: Yeah, it’s fine.

Paul: Exactly. Yeah, brilliant. Brilliant stuff. Thank you SO much for coming in and chat about that. Much appreciated and you are hanging around for a bit, aren’t you?

Inayaili: Yeah, I am.

Paul: Excellent stuff. Brilliant.

Thanks goes to Joke de Winter for transcribing this interview.

Zeldman and Ethan Marcotte on the future of the web

Posted in Design, Mobile on March 31, 2010 by Paul Boag

Jeffrey Zeldman and Ethan Marcotte talk about the third edition of Designing with Web Standards as well as discuss the future of the web.

Paul: So, joining me today is Jeffrey Zeldman and Ethan Marcotte from Happy Cog, and they’ve recently released the third edition of “Designing with Web Standards,” which is basically the bible of the web standards community. It’s good to have you both on the show.

Jeffrey: Thanks, Paul.

Ethan: Thanks Paul, it’s great to be here.

Paul: So the first question has to be, we’ll talk about the book in a little bit, then we’ll get on with some more general issues, but starting with the book, Jeffrey, other than the fact that Ethan is obviously a genius in everything that he does, why did you decide to go for a co-author this time around?

dwws website

Jeffrey: So I wrote the first two editions by myself. I was half way through the book and said I need Ethan as a co-author. I didn’t say I needed a co-author, I need Ethan. There were a couple of reasons. I think the principle reason was, I’m now a captain of industry, right? I spend a lot of time flying around, and walking around, and in cabs talking to clients, giving presentations, writing stuff, it’s all great. But I’m not at the front edge writing code anymore. I wrote the first edition of “Designing with Web Standards,” I was doing experimental CSS design work nobody else was doing. And I was like, This is pretty. Well, actually, Eric Meyer was doing more than, well, there were people doing it, but I was one of the first people doing it, and I was going “Look, this is amazing, and it really works!” And for the third edition, I wanted someone really brilliant, really wonderful who is doing that same work, who’s at the forefront now and who is making CSS, jump through it’s own sphincter and all that stuff, so he was the guy. Ethan has a wonderful, funny writing style that I’ve got to say, this’ll sound, it reminds me of mine, and it sounds arrogant, I’m not saying “He’s wonderful like me!” His writing style and mine flowed together so naturally that it’s hard for me looking back, “Did I right that, or he?” I think it was perfect.

Paul: Brilliant. So what encouraged you to write a third edition then? You know is two not enough?

Jeffrey: Well actually, if we still had IE6 as the principle browser that everyone was using, if XHTML 2.0 was still going strong as an experiment that nobody was going to use, there was no [what] working group, there was no CSS3 in the wings, there was no HTML 5 in the wings, we could have waited longer. But, it so happened that during the writing of the second edition, and shortly after the standards community was very upset. It seemed like it was divided between people who thought now we have a stable base of tools and we know what to do, let’s just keep refining our best practices. Another group said that’s all well and good, but we need new tools, we’re very limited in what we can do, in terms of layout. The semantics of HTML are very limited. Well now, all of a sudden, in the last year and a half, HTML5 comes bursting out, like ready to be used and supported in browsers. There are elements of CSS3 that are in browsers. People are all over, not just standards people, people all over, including Microsoft are saying “Help us get rid of IE6.” We have An Event Apart speaker coming from Microsoft, who’s going to spend half an hour, asking our audience to help him get their clients off IE6. So, there’s so much going on after basically eight years in a nursing home. Years of dull, bad, nothing happening, except that everyone got up to speed and pretty much anyone who wasn’t aware of web standards and wanted to be, had those eight years to read the books, make the mistakes, and everybody knew the tricks and all that and now all of a sudden its an all new game. And I think also the fact that people I respected kept saying we’re in so much trouble, we’re going to lose semantics, HTML5 is a disaster, XHTML is dead, that means that people who use XHTML are fools, we’re losing the W3C, the W3C is stifling innovation, and there was so much opinion that was so wild, I thought “Okay, what do I think about this?” and a few blog posts that I had written in response didn’t seem like they were solving anything, it didn’t seem like I could go “Here’s what I think…” that it was over. There’s a lot of ferment, a lot of people who are confused, upset, so let’s figure out what’s going on and see if we can provide some wisdom.

Paul: Ethan, from your perspective, what is it about the third edition that really excites you? What in there is really grasping you, what was your excitement as yuo wrote it?

Ethan: I was a technical editor on the second edition, and started off as a technical editor on the third edition. Just comparing the two books, there’s a remarkable difference between the third and the two prior. I think the biggest one is that, Jeffrey I think you would probably agree, that this edition is significantly more hands on than the first two were. Designing with Web Standards is fundamentally and definitively a conversation starter, for someone who is interested in standards-based web design. And it introduces a whole host of topics pretty authoratively but not exhaustively. I think the first two editions definitely still had to make all the philosophical arguments of, this is why we need to move past table-based layouts, this is why this new techniques really make a lot of sense for the web. Now we are in the position where there are still a lot of people out there that are still acclimating themselves to web standards, but at the same time we do need to start getting more of our feet wet. So the layout chapter has been significantly re-written to actually introduce people to the concept of not only the box model but the float model and some of the drawbacks with some of the different techniques that are out there. The last chapter of the book actually is a pretty comprehensive look at how these three tiers of the standards “cake” or the trifle if we’re playing Andy Clarke for a moment, actually snap together, pretty robust calendar, using just a straight HTML data table. I think there’s a lot of really great stuff in there, I think even the philosophical stuff is still fresh and new to me as a reader, but the hands on stuff is what I’m most excited about.

Jeffrey: I agree. I think we freshened it. Basically, nothing was sacred and anything could come out. In the second edition, that was not the case. The second edition had to keep making some of the same points and had to stick to some of the same examples. In this edition, we threw out many of the examples and language. There were all kinds of regressions in the first and second editions that were interesting, maybe important in some ways, but they didn’t seem as important now to what people are doing. There’s an emphasis in the book in just what do you say to your client or boss who says you can’t do accessibility. What do you say to the person who says we can’t afford user testing or we have to support IE6. Of course they do; they have to support it, but what does that mean? What does that mean in 2010? So there’s still a lot of philosophical stuff upfront but it is short. Unlike what I’m doing in this interview, I wrote short. If I had seven paragraphs to explain something in the previous edition, it was like let’s do it in one. So I think it has a leanness to it.

Paul: Yeah, it sounds like for the vast majority of people who already own one of the previous editions, this feels like a real leap forward that is worth paying the extra money for because of the new state of things at the moment. So yeah, sounds really good.

Okay, I’m quite interested in the way that you described a minute ago Jeffrey the place that we’re at the moment, because there are a lot of people that would say, well, isn’t the work of the Standards movement done, haven’t we kind of seen that adoption that we were looking for both in terms of the design and development community, but also in terms of browser support, is there really still work to do? But from what I’m hearing from you so far, you see there as being a big transition point. Is that right?

Jeffrey Zeldman presents

Image Source

Jeffrey: Yeah, I think there’s work to do on two levels. I want to hear what Ethan thinks too. From my perspective, even if none of the changes I mentioned were happening; even if there was no HTML5, no CSS3, no ending of XHTML, etcetera, etcetera, there would still be a phenomenal amount to do in education, because most of the schools that are teaching web design, aren’t doing it right at all. They’re not teaching interaction design, they’re not teaching usability, they’re not teaching content strategy, and they’re certainly not teaching web standards. They’re looking at it as some kind of brain damaged, sub-species of graphic design. They’re telling them “well, you know how to use Illustrator, learn how to use Flash.” I was talking to a man yesterday, very qualified guy, who was up for an academic position at an university in his area. And he didn’t get it; they literally laughed at him. Again, these are professors, people who knew nothing about web design, they laughed at him. But it’s all Flash, we don’t understand, just learn Flash. What is it you’re trying to teach? We don’t get it. So if people could just take the first edition of this book, and some Eric Meyer books, and some Andy Clarke books, and Dan Cederholm, and just spend old ones, and just redo the way web design is taught in the academic community. So there’s that thing. Then, did I say two, there’s three. When I’ve been writing about, at Zeldman.com, when I’ve been writing about what’s going on with the iPad, why did they leave out Flash, is there any upside to that, or talking about IE9 preview, I get a fair amount of, I wouldn’t call it hate mail, cause that’s too strong, but I get a fair amount of people, very strong push back, who either think that Microsoft’s browser is really the platform that everyone uses, so standards should be adopted to it, not the other way around. I still hear that a lot. And I still hear, the way you guys are torturing web fonts and everything like that, just use Flash. So there’s a lot to do there. And then the third thing is for the people that get it and who are on board, as you said, it’s a transition point or an inflection point because the way we use standards is changing. Or rather, the baseline best practice that we have which will last forever and they’re fine, we can now do more with less. We can now use lighter CSS to do some of the things, and lighter markup to do some of the things that required, like now, in the past, I wouldn’t have done rounded corners just because of the ridiculous amounts of silly markup I had to use to do it. Little pieces of images, and using it now, especially with IE9 onboard, also supporting CSS3 rounded corners, put in the rounded corners and eventually, everyone will see them; even though not everyone will see them this year. I also think the whole war about whether it’s ever okay to use pixels as size elements for type takes on a new dimension when text zoom is pretty much dead and page zoom is pretty much the way. Ethan and I disagreed on that and actually, we were going to do an author vs. author thing with our arms crossed, but we just didn’t get it together in time.

Paul: So I want to pick up on that. It’s always good to find a point of disagreement. Who takes what position over this? What’s your position, Ethan?

Ethan: I take the right one. I’ve always been a strong believer in designing to the user’s preferences. Obviously, at some point, design is about setting parameters for the experience. When it comes to font sizing, I’ve always been a firm believer in shying away from pixels, just because of the prevalence of IE6 in the marketplace. That’s really it. Working with large financial institutions or government institutions where that is such an entrenched install, you know, but at the same time, you have to balance that with the accessibility needs of, well, we have some low vision users, or differently abeled users that would actually like to bump up the contrast on this a little bit. I’ve found working with Ems, especially with a lot of Rich Rutter’s excellent work. He wrote a great article for ALA a couple years back that was my go to article on that for a long time.

Jeffrey: The 62.5% solution or the one he wrote after that, how to size text on the web?

Ethan: The 62.5% one was a technique that he used on his blog and then he sort of upgraded it for the ALA article and said that actually basing a font size on 100% for the body gave you a much more consistent display. And really, I’ve just found, and I should state at the outset that I am horrible with math, but I’ve always found that it’s fairly easy to do with a little, just using the calculator app on OSX.

Paul: There are also some great web apps now that kind of do all that hard calculation for you as well.

Ethan: Yeah, and actually I use Textmate as my text editor, and they got some built in calculation stuff which is great, not only for sizing text but I also do a lot of work with fluid grids.

Jeffrey: You have to come to my desk, because I use Textmate too, and I don’t have any of those tools. I know they’re built in.

Ethan: Sure, we’ll do a screen share after this.

Paul: I can see another thing come on. We need to do a screencast of all these tools you have, Ethan.

Ethan: It’s great watching other people work. That’s one of those things that you lose in a virtual environment. I love seeing how people set up Photoshop, or set up their text editor, it’s always fun.

Jeffrey: I used to just sit and watch other people work.

Paul: Well, it’s far better than working yourself, I find.

Ethan: Yeah.

Jeffrey: It was work. That’s my job now.

Jeffrey: I wanted to get back to what Ethan said about text sizing, because I agree with everything that Ethan said. We don’t want to cause accessibility problems. A lot of people are stuck with IE6. All that stuff is true. And in those environments where you know you have a lot of users with IE6, then you know that pixel-based text is out of the question. I just want to stand in; I’m all for usability and the user and all that, but I just want to say a word for the designers for a minute. There are limitations in every medium, this is true. What a designer of a book can say, I’m going to have this be 15 point and this be 12 point, and there’s a mathematical relation between them, and it’s very controllable and I know what the user is going to see. And they can control the leading, and the margins, and everything else, so that there’s this beautiful, underlining, horizontal and vertical grid, and the page feels pleasing, it’s pleasing to look at and it’s easy to read. There’s no reason, because I refuse to let pixels be magnified because of a stupid wrong decision that Microsoft made 12 years ago that we have to jump through our own anuses, and still only approximate the results we want to get. I think it’s ludicrous. When there are so many other browsers out there, and when IE itself is transitioning to the same thing. I think that now that’s page zoom is out there, and it’s out there in IE8, it’s out there in IE7, I think it’s okay. There’s only the IE6 user who won’t be able to, and if you’re designing a book site for designers, if we’re designing The Book Apart website, to promote a book that we’re doing for web designers, I think that would be okay to set in pixels. Because in all probability, people are looking at the site in Firefox or Chrome, IE8 or Safari. It’s a question of knowing your audience. I look forward to the day when we can use absolute sizes, the user isn’t limited because the user can still make them bigger or smaller. And artificially, a sort of limited understanding of what CSS meant, that resulted in an arbitrary decision won’t force us to keep doing crazy things and saying “I’ve got this thing that works now, make it 100.1%, and put that on the body. And then the HTML is 100% of the body.” And everyone I work with does these things and it drives me nuts. And I just want to go, you know what, if I need something to be 12 pixels and something else to be 18 pixels, I should be able to do that without hurting anybody. So I think it’s idealism, and remember I’m not just saying well, I’m going to do this because, nyah nyah, I’ve been asking them to change this for 12 years. Can you change this now? Can you change this now? Can you change this now? Like, have you ever seen SpongeBob? SquarePants? Can you change this now? Can you change this now? Can you change this now? That’s me. They finally found a different way to do it. That’s fine. I’m agitating on behalf of the users and designers. Good design is better for users. Right?

Ethan: I will say that, Jeffrey and I have had this sort of scorched earth, back and forth, a couple times now.

Paul: I was going to say, at some point, I’m going to have to stop the two of you, otherwise this could go on forever.

Ethan: Paul, if you could just play marriage counselor today, that would be a huge help. I will say that, it definitely needs to be driven by the constraints of the project. I worked on a fairly large site, New York Mag, which we talk about a little in the book, NYMag.com. It was basically a very large template production job for me. It was very beautifully design, but very encyclopedic module library that they were going to be building. The producers that were going to be inheriting the work wanted to have the flexibility to like, we’re going to nest module A inside of module B. All the typesetting was going to be done in pixels just because, it was going to make the most sense for them. Because, maintaining a stylesheet that was going to handle all of those contingencies was going to be just a nightmare. But that said, I think Jeffrey and I have our respective biases on that front.

Paul: I mean, a lot of these things turn into religious debates really, were you pick a side, but in most cases, the answer is “it depends.” There are always other factors that need considering.

Talking of browser support and IE6 and that kind of thing, Have either of you guys had a chance to root around IE9? What’s your initial impressions so far?

Ethan: That’s a great question. I actually haven’t touched it.

Paul: Ah, well, fair enough.

Jeffrey: Me either. I really happy with everything that I’ve seen, in terms of their improved standards compliance, just in the last few days that they’ve been public. But we’re a Mac shop, you have the virtual PCs and all that. We haven’t started testing in IE9 yet.

Paul: Fair enough. I just thought I’d ask because…

Jeffrey: It’s a good question.

Ethan: I’m installing it right now. Actually no.

Paul: Now out of quilt.

Ethan: We can clean this up in post, right?

Paul: No, no, no, you’re going to be publically shamed. I haven’t looked at it either. I’m sure some clever people have, obviously not us.

Okay, let’s move on to the subject of what’s exciting you the most on the web at the moment. Jeffrey very briefly touched upon web fonts earlier, and it seems to be something that you’re writing a lot about. Is that where your real passion is now, or is there something else that’s grabbing you?

Jeffrey: I’m passionate about the idea of it. And I would love it to work well and easily just with @fontface. I’m thrilled for Typekit, which is a great tool. I’ve tried three tools now, out of which Typekit is the furthest along, and it’s definitely driving adoption, getting people really excited, it really just works. It’s all great stuff. But for the same reason that I want IE to let me size up something in pixels and let it get bigger or smaller, or whether the user needs to do that or not, I think I have issues with the fact that were so close and yet so far. That fonts are looking bad on the screen and all the issues that we have to overcome.

Paul: So what is your approach at Happy Cog when it comes to web fonts? Are you tending to steer away from them or what’s the situation?

Jeffrey: Ethan, with the projects that you are doing, we’re doing different things. It all depends. There’s some pages where we’re still using sFir and Cufon…

Paul: I never know how to say that either…

Jeffrey: We’ve used some @fontface and we’ve used some Typekit, which is @fontface with lots of support. It depends. We’re not delving into it deeply yet. We’re setting headlines more than body text at Happy Cog, so that gives us lots more flexibility. The body textóthe problem is the type, and the type outside of our favorite browsers. When we look at the stuff in our favorite browsers, we want to weep with joy. But when we look at it in Windows, and some older browsers, and some older platforms, the thing with Windows, it’s a many headed beast. The other issue is that Roget Black, a studio mate here in New York City, described it as there’s this health living guy, but he’s dragging these corpses behind him. Here’s IE9, and you’re like “wow, that’s great.” Then here’s IE8 and it’s looking pretty good, but you got all these old versions of Windows, and all these old versions of Clear Type or no Clear Type at all, and these old versions of IE, and Microsoft has to keep supporting them for like another 5 years. So the handsome salesman is walking along with all these corpses tied to his back and it makes it hard, it doesn’t make it seem like a stable platform yet for type.

Paul: Ethan, is that your experience as well?

Ethan: It is. I mean we’ve done a limited @fontface and that is purely because we really let the design drive the requirements. So many foundries have pretty explicit constraints on what you are able to do with their typefaces. Cufon is just right out in a lot of cases. sFir is actually banned on a couple that I know of. Hoefler & Frere-Jones, who do beautiful work, explicitly allow sFir, but any other conversion of their typefaces is right out. We try to have a lot of discussions upfront with a client when we’re reviewing designs saying that if they’re especially wedded to a particular typeface, here are our options for that. And then we just try to talk to them about what kind of maintenance are they interested in having. I think for most of the headline stuff we do, we’re still pretty comfortable working with sFir. It really just depends on the project, and what the clients is willing to take on.

Jeffrey: I will say if you’re going to go with body type, Typekit seems like a very good solution right now, because the fonts are going to keep changing. If you’re trying to brand your body text, by using a font other than Times or Arial or Georgia, in all probability, the type shop that designed it today is going to change the hinting on it or even redesign the font several times over the next few years as the landscape keeps changing. If you go with Typekit, they’ll just make sure that they’ll swap in the new version, they’ll make sure it happens. Some of the font vendors are saying the same thing; that they’ll do that as well. Like I know that Font Bureau is going to host their own fonts. You can buy them, put it on your own server, and link to it with @fontface and your done. Or you can buy it and let them host it for some kind of fee they’re still working out I think. They will swap in new versions as they rehint them.

Paul: So it sounds like you both have some concerns when it comes to web fonts, which is understandable. So what is it then that fires you up these days? What gets you passionate still about the web and what do you see emerging that still excites you?

Ethan: A lot of the stuff that we cover in the third edition is where my head has been at recently, with CSS3. Dan Cederholm talks about this, like a period of great revisiting. We’re looking at the techniques that we have sort of gotten used to using for the past few years and trying to apply these new technologies to them in kind of exciting ways. So that’s one thing. The other thing; a lot of our projects at Happy Cog have been device agnostic. We’ve started having a lot of clients that are asking not just for a rich desktop experience when you’re browsing their sites, but also with the advent of the iPhone and Apple’s got another little toy coming out shortly I hear…

Paul: Apparently, I haven’t heard much about it.

Ethan: I’ll have to check the rumor blogs on the Internet. There’s been a lot more opportunities for just thinking outside the very strict design parameters that we usually work with. Then just thinking about not just designing for any particular device but a particular context. Because even if you are on a mobile phone, if you’re viewing something on a subway in the morning versus in the middle of the office at 10:30, your environment sort of dictates how you want to interface with a particular piece of content. That’s really what’s been firing me up as a long term proponent of flexible designs, letting the user dictate the experience. I sort of see that as the next step, thinking beyond the desktop.

Paul: Yeah, absolutely.

Jeffrey: It really takes John Allsopp’s A Dao of Web Design to a whole new level. It is what it was all about to begin with. I totally agree with that. I’m also really excited about, in terms of client services, about the more holistic way we’re approaching work today, and the fact that so many clients accept it. In the old days, a client might come and say “I need you to skin this” and you’d say, “Well, who are your users, what are you doing it for, can I see the content, and have you thought about this” and they really didn’t want a strategic partner. They wanted someone who knew HTML and CSS and JavaScript and could design. A competent designer who knew JavaScript and HTML. There’s still clients like that and there’s nothing wrong with that. But what is exciting to me; so we will be talking to the US Holocast Museum in Washington, D.C. and it’s a whole, complete, strategic thinking about “What is the museum experience, is it appropriate to recreate that for the website and if so, how would you do it.” Not in some corny way, like we did back in the 90′s, like “we’re doing a virtual fly through.” But actually what is the emotional experience, what is the educational experience, and then beyond that, how do people use the website differently, who’s coming there, the whole emphasis on user experience and content strategy long before we get to the design phase. It’s really exciting to me as a creative person. I feel like we’re more and more strategic partner to our clients. which I’ve always loved and wanted to be. My very first web design job we got over a competitor was for Batman Forever. The competitor was talking about Batman was going to fly in, this was 1995. Batman was going to fly down a rope, like a Pearl script was going to … and then Batman was going to say “Hi, I’m Batman, blah blah blah, and I just blurted out, “Batman doesn’t talk.” And the client looked at me and I knew we had the job. Because I could think strategically and I could think about the character. I’m not bragging, I’m not really smart. Anyone who actually loves that character and knows the Batman lore knows the Dark Knight doesn’t talk. He just this mysterious presence; he just has to be there, in the background, being cool. I think now, finally, we’re very much partners in that way and I really like that very much. It seems right now there’s so much going on in terms of shared understanding of shared technologies with APIs and shared understanding of how users do things and what they want to do, I really see this sort of confluence happening where things that we think of as games and little kool iPhone apps and so on and things we think of as real, Gowalla, and things we think of as serious tools, like Google Maps; I see this all coming together. I think the whole mashup culture that was sort of trippy and fun a couple of years ago, I think it’s going to produce an approximation of ubiquitous computing on our desktops, on our phones, and everywhere else. I think it’s coming really soon. I think everyone feels that. The fact that we’re talking about putting real fonts on the web is just another part of that, in a way. It’s like how can we create these fully branded experiences and have them interact with each other in a seamless way that just works. It seems like that’s what is happening now and that excites me. And it’s all built on standards. It’s all built on HTML, CSS and JavaScript.

Paul: There’s one last question, we really ought to be wrapping up before very long. As you look now at the web design community that has emerged over the last few years, what do you feel is the biggest lesson that we still have to learn as a community is?

Jeffrey: I would say to respect each other. Respect each other’s choices, respect the client’s wisdom, the user’s wisdom, not to think that we’re the expert.

Paul: I do feel that sometimes we’re impetuous teenagers trying to stamp our authority on the world and say how important we are and how we should be listened to. We possibly need to grow up and relax into our role and not feel the need to prove ourselves constantly by saying we’re right and everyone else is wrong.

Jeffrey: That’s how you get the respect. You get respect by being the grownup in the room.

Paul: Ethan, what about you. What do you think is the big lesson that we’ve got to learn is?

Ethan: I think it’s a corollary to that the first response isn’t necessarily always the right one. I know Jeffrey has been writing a couple of fire inducing blog entries lately, which has been interesting to watch. Obviously, when you’re presented with a crisis of the web, he talked earlier about how the W3C was going to go up in flames a year and a half ago, XHTML2 was dead and we were all going to be working on FrontPage in three weeks. There’s a kneejerk reaction to sort of panic and sort of get your opinion out there. And I do think that a little more research and a little more information can usually yield better results. I think standing back from the crisis for a moment and asking some smart questions can be good sometimes.

Paul: Thank you so much guys. It’s really interesting to hear your perspective on things and get you on the show. All the best of luck with Designing with Web Standards, Third Edition. I’ve no doubt that it’s already broken all records. I hope it continues to do so. Thanks for coming on.

Thanks goes to Dennis Deacon for transcribing this interview.

If you recognise that the mobile web is important and you need help deciding on a strategy, then book a mobile consultancy clinic.

Book a consultancy clinic or contact Rob about a more in-depth review.

Web Design News 02/03/10

Posted in News on March 2, 2010 by Paul Boag

This week: the search for inspiration, using CSS3, ecommerce tips and why the browser landscape in Europe is about to change.

The search for inspiration

I am always encouraging those of you who listen to this show to be more adventurous in your designs. With website owners tending to be conservative and designers jumping on the latest design trend, website quickly all look the same.

Design Instruct has an article this week outlining some ways that you can find inspiration. Other than a recommendation to ‘look to the history of design’ for inspiration, none of the suggestions are that original. Most we have discussed before on the show.

However, there is a second post this week from Smashing Magazine, which is truly inspired. Entitled ‘Find inspiration in uncommon sources‘ it lists some great ideas that you should take a look at. My favourites sources of inspiration were:

Board games
Food
Fashion

These are certainly not areas I have considered looking at before. Infact shortly after reading the Smashing Magazine post I stumbled across this amazing post about food design which I highly recommend. It will certainly inspire.

Using CSS 3 right now

We talked a lot about HTML5 and CSS3 on the 200th episode of Boagworld. Hopefully this has left you keen to get stuck in, especially as these technologies can be used now and not at some future date when they are universally supported.

If that is the case then here are two great articles on CSS3 you should check out.

I would recommend starting with ‘You can use CSS right now’ as it focuses on basic stuff like rounded corners, drop shadows and alpha transparency.

Once you have your head around that, turn your attention to the mind blowing possibilities in the second post. Some of the stuff they cover includes:

CSS only content sliders
CSS only dropdown menus
Image free speech bubbles
3D ribbon effects
Awesome buttons
Letterpress type

Of course these techniques are not universally supported, but as they are enhancements to a site rather than crucial to its operation, that is fine. This is progressive enhancement at its best.

Example of a CSS only menu

Europe set to have a broader range of browsers

We have known it was coming for a while but it looks like the moment is finally here (in Europe at least) – Microsoft now has to offer a range of browsers on its Windows operating system, not just Internet Explorer.

According to Sitepoint this will happen any day now through automatic update and is going to affect every user with IE as their default browser. Sitepoint writes…

The Browser Choice screen will be offered in Windows XP, Vista and 7 to users who have IE set as their default browser. It will be installed through the standard automatic update system.

Following installation, a new “Browser Choice” icon will appear on the desktop and the IE icon will be unpinned from the Windows 7 taskbar. An introduction screen will appear which explains what a browser is.

The user can opt to select later or proceed to the browser choice screen. The five most popular browsers are shown in random order — IE, Firefox, Chrome, Safari and Opera. A further 7 randomly-ordered browsers are available if the user moves the horizontal scroll bar.

The system can download and install any number of browsers.

This will have a massive impact on the European browser landscape. My bet is that the big winner will be Google. Many users will play it safe and stick with the blue E that they know. However, a lot will be tempted by Google because it is a brand they know and use regularly. Expect their market share to jump.

However, I have left the best bit until last – According to Sitepoint:

IE6 and IE7 users will be prompted to upgrade to IE8!

This means whether users upgrade to IE8 or opt for a different browsers we are going to see a dramatic improvement in standards compliance here in Europe.

Oh happy day!

Browser Choice Screen

Ecommerce development tips

I am very conscious that I don’t cover a lot of news for developers on this show. That is mainly because I don’t understand much of what you guys do. However, an article this week caught my eye and I thought I would share it with you.

24 Ecommerce Development Tips appears to be a comprehensive list of technical things to consider when developing an ecommerce site.

The article covers everything from database configuration to handling the complexity of discounts.

24 ecommerce tips

One part that jumped out at me in particular was:

AJAX is fine for checkout, not for product browsing. Don’t load products or product previews in DHTML windows or an AJAX widget. Search engines won’t be able to find them. Which means you won’t sell anything. Which means you’ll go from full time to part time to contract to unemployed.

The reason this grabbed my attention was because it reminded me of my own post on Javascript and ecommerce.

If you happen to be considering building an ecommerce website anytime soon, I highly recommend you read it.

We recently discovered that very few of the big name ecommerce software packages run without the use of Javascript. If that includes your website then you may well be turning away 1 in 20 of your potential customers.

Certainly food for thought.

184. HTML5

Posted in Classic shows on September 23, 2009 by Paul Boag

On this week’s show: We interview Jeremy Keith about the truth of HTML5 and Ryan Carson shares some more advice about building your own web application.

Podcast: Download (27.9MB)

Download this show.

Launch our podcast player

News

Apple and UI design

Whether you are a fan of the Mac OS or Windows, there is no denying that Apple know what they are doing when it comes to user experience design. There is a lot that can be learnt from them whether you are developing a piece of software or even a website.

This week I have come across two sites which perfectly demonstrates just how deep Apple’s knowledge of UI design goes. The first is Finer Things in Mac, which is a site dedicated to highlighting the small details in the mac OS UI which makes it shine. Examples include:

The naming of buttons so they are more descriptive than “Okay” or “Cancel”
The way Time machine changes the clock in the menu bar as you go back in time
The accuracy of progress bars when compared to windows

The second area that demonstrates Apple’s expertise is in how they have chosen to tackle accessibility on the iPhone 3.1 interface. It is hard to imagine that a touchscreen device with only one physical button could ever be accessible to blind users. However, it would appear they have made it happen.

Marco, a totally blind user who works with Mozilla wrote in his post My first experience using an accessible touch screen device:

I must say this was an amazing experience! My fingers definitely need to get used to gestures such as flicking or tapping, or using a rotor. But having an iPod Nano 4th generation helped with that, since moving the finger over the screen like on a dialer felt most like tracking around the iPod’s click wheel. Even the sound the rotor makes is the same.

This amazing result is made possible by Apple’s VoiceOver technology which is extremely hard to describe. However Apple do provide a video that demonstrates the technology in action and I highly recommend you watch it.

Do you need cake if the icing is amazing?

On last week’s show I talked about 3 Ways to Stand Out From the Crowd. One of the things I mentioned as part of that post was Paul Annett’s talk at SXSW called Oh… that’s clever. In this talk he looked at ways to add design delights that excite and amuse users.

Although I am a massive fan of this approach, it can be taken too far. A Sitepoint article entitled: Do You Need Cake if the Icing is Amazing? looks at one example of where this happened.

The article is about the HEMA website where as the author describes it:

The site renders as what appears to be a garden-variety, IKEA-like online store: navigation tabs along the top and popular products displayed in a grid. Yawn. yawn.

That’s when reality seems to break, and strange and wonderful stuff start to happen.

It all begins when a plastic cup tumbles over, bumps the sticky tape, and a domino effect is set in motion. The tape then crashes onto the stapler before squishing the cake, noisily sliding down the xylophone, and knocking over the fluorescent pens like skittles.

This chain of slapstick events continues, drawing ironing boards, blenders, yo-yos, coat hangers, and kettles into the growing maelstrom before eventually breaking out into parts of the site navigation and text.

By the time this sequence of events has all played out, the tabs are torn and frayed, the navigation text has collapsed into a puddle, and confetti flutters about from above. Very, very cute.

The post is an interesting analysis of the pros and cons of this kind of approach. It concludes by saying:

But as sublimely clever as the animation is, I have to wonder if this project, and the buzz it created, has translated into anything particularly useful for the HEMA business.

What’s more, I wonder how many users have ended up feeling disappointed, frustrated, or confused by being unable to find some of the “bread and butter” basics like locating a store, giving feedback, or asking a question.

I have to say I agree. Although adding design delights and easter eggs is nice, it is easy to overstep the line and end up damaging usability and accessibility.

GIT: Your new best friend

If you develop websites as part of a team you probably use a version control system. We do at Headscape and it seems to be common practice. At the most basic level a version control system allows you to manage files, prevent overwriting by multiple contributors and allow rollback to previous versions of an entire site or a particular file.

The dominant player in this market is Subversion but there is a new kid on the block which seems to be getting a lot of press.

Git is a free & open source, distributed version control system designed to handle everything from small to very large projects. Every Git clone is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server.

This distributed approach has a number of obvious benefits, but it would appear this is just the tip of the iceberg. Think Vitamin has published a post entitled “Why You Should Switch from Subversion to Git” which explains the advantages of Git in full.

There is also a detailed introduction to Git on Sitepoint entitled “Git: Your New Best Friend“.

I freely confess that I know nothing about version control systems (that is Dave and Craig’s areas of expertise). However, I have seen a lot of love for Git online and if you are a developer this is almost certainly worth checking out.

Project management and simplicity

Building and running a successful website is about a lot more than having a great design team. It is also about having a visionary website owner who can think creatively and manage projects successfully.

However, being able to manage projects and have time to think creatively about your site can be a challenging combination. Life is simply too hectic.

Fortunately there are two posts this week that might go someway to inspiring and organising you better.

The first is “How Simplicity Can Help Creativity“. It looks at how simple changes to your routine can help grow your creativity. It contains good solid advice, although admittedly some of the suggestions are primarily aimed at writers.

The second is a Smashing Magazine article entitled “How to Find Time For Everything!” This is essentially a productivity post. However, it is particularly aimed at web workers. It covers everything from your working environment to prioritising and planning.

Both posts are worth a read if you find yourself constantly caught up in the day to day running of your website and never get the opportunity to think more strategically.

Interview: Jeremy Keith talks about HTML5

Paul: So we are doing our first interview of the day at dConstruct, and joining us, of course, is Jeremy Keith – hello Jeremy.

Jeremy: Hello.

Marcus: Such a happy hello.

Paul: It is, he’s a happy, jolly person; well known for his jolliness.

Jeremy: It’s true.

Paul: So, HTML 5.

Jeremy: Yes.

Paul: There has been so much talk about HTML 5 recently, we thought, as we’re going to be seeing you, as we’re going to be at dConstruct, we ought to grab you and talk about the subject of HTML 5. Now, I haven’t thought through in a huge amount of depth want I want to cover…

Marcus: Surely Jeremy in cartoon form is want you want to cover?

Paul: Yes, that’s a really good point.

Jeremy: I was really shocked you haven’t prepared.

Paul: Yeah, but actually I managed to watch the cartoon, or read the cartoon.

Jeremy: So that was about you’re level.

Paul: That was about my level, yeah, I felt happy there. So maybe just run through this fundamental issue that XHTML 2 has gone away; HTML 5 seems to be the new thing that all the cool kids like, so what’s going on there?

Jeremy: Okay, well first of all HTML 5 has been around for quite a while; they’ve been working on this, so nothing has particularly changed. Well, Google had their IO Summit thing a few months back, and they came out and said, “We totally support HTML 5, and we think it’s the future”, and suddenly a lot of people got very interested in HTML 5 who hadn’t been paying attention, which is a bit weird. It’s like it’s been going on for ages, but as soon as Google says it’s interesting then people are interested. So that was one thing that kind of sparked a bit of interest in HTML 5 which is kind of good to see. But then the whole XHTML 2 thing was just really bizarre because I hadn’t realised the misconceptions that a lot of plain old working web developers were under about the format. Basically, XHTML 2 has been dead for years, and I thought everyone understood this.

Paul: No.

Jeremy: Okay, so HTML 4.01 was finalised around 2001, and after that W3C said okay, HTML is done, and we think the future is XML based… all these various XML based technologies, and amongst that is XHTML. Now, we all rated XHTML 1, but all that was, was just HTML 4, really. I mean all it is, is just an XML version of HTML. Nothing new was added, it’s all the same elements; everything works pretty much the same. So, really, XHTML 1 is just HTML, and most people used it that way, they would serve it as HTML. This upset a lot of people who thought, “Oh no, you’re serving XML as HTML and that’s bad,” but most of us didn’t care, you know. Browsers rendered it, we were able to validate against it, and that was good. I mean that’s why I use XHTML 1. I serve it as text/html, I don’t care that browsers then treat it as HTML, I get the validator telling me if I forget to close a paragraph, or if I forget to quote an attribute; that’s useful to me as a web developer. But it’s not a completely different format to HTML, it’s just HTML redefined as XML.

XHTML 2 is what the W3C started working on after HTML 4 was finished. XHTML 2 was going to be a complete break; an utterly new format. I mean things like you wouldn’t have an image element, you would have ‘object’ to cover any kind of thing you would put on a page. All sorts of things that really, theoretically, were wonderfully pure and abstract, but practically, just no way anybody’s ever going to use this, because it wasn’t backwards compatible with all the content on the web today.

So there was this kind of split in this W3C around 2004. There was this one particular meeting where the W3C really put their foot down and said, “The future is XML and particularly, XHTML 2. We know it’s not backwards compatible, we don’t care, we’re going to plough forward with this.” And some people in the W3C said “That’s it, we can’t deal with this”, and split off into this separate splinter group (this was Opera and Mozilla at this point), and they called themselves the ‘WHAT Working Group’. Web Hypertext Application something… I don’t know. It’s clearly a ‘back-ronym’ right? They came up with the word ‘what’ and figured out words to go around it.

So, they start work on this thing which they call HTML 5. That’s kind of this buzzword umbrella term to cover one, the next version of the mark-up language we know as HTML, two, XForms which is a good thing that the W3C have been working on to make life better for web developers, but mostly this idea of what they were calling web applications one, which was the idea that we’re moving from documents to web apps, and that’s what real people working on the web really need; fill in the gaps in HTML… We’re working with HTML now to kind of force things to act like applications, we don’t have native things to build applications like, let’s be able to make applications natively so that we don’t have to rely on a plug-in like Flash, or Silverlight, or any of these other non-open technologies.

So that started in 2004. Meanwhile XHTML 2 is being developed at the W3C in the ivory tower where no-one is actually going to use it, and in 2006 Tim Berners Lee wrote a blog post and said, “Yeah we were wrong, we were wrong.”

Paul: Good for him.

Jeremy: Yeah he said, “Actually HTML is still good and is actually the future on the web,” and restarted a charter for the HTML working group. So in 2007, the W3C start work on HTML 5, as in the sequel to HTML 4.

Paul: Corr, this is complicated!

Jeremy: Working with the W… what, working with the WHAT working group?

Marcus: I need a coffee.

Jeremy: I know, I know.

So basically now you’ve got two groups working on this one spec. You’ve got the WHATWG which has a very open process, you’ve got the W3C which is generally more closed, although the HTML working group is more open than most W3C things. A lot of things with W3C happen behind closed doors. Actually with the HTML working group now, anybody can join; it’s a little bit convoluted how you join, but anybody can join.

Meanwhile XHTML 2 was still being developed, you know, down in the cellar they’re working on XHTML 2. But everyone knew, or I assume everyone knew, that it was like this kind of joke really – it wasn’t really intended for working web authors to use on the public web. So earlier this year, finally, 2009, W3C announced, “Oh buy the way, we’re not renewing the charter for XHTML 2″, and most of them went, yeah, no surprise there – really it’s been dead for years.

But a lot of people got really confused, “Oh no I have to change from XHTML to HTML now; I have to change all my mark-up back.” No, if you’re writing XHTML 1, that is basically HTML anyway, and HTML 4 and XHTML 1, those doctypes aren’t going anywhere, your documents are still perfectly good, you don’t have to change anything; everything’s absolutely fine. And what also happened was that some of these people, who were sort of traditionally, as I said, hated it when people like me would serve XHTML 1 as HTML, “Oh no the browser’s treated it as HTML”… They started gloating and saying, “Ah, this is great, this proves that the problem is XML and XHTML in particular, and everyone who ever used XHTML was a fool”, more or less… which really bugged, because like I said, Gareth Rushgrove write a great blog post about this. The reason I use XHTML is to make the validator more powerful, it catches those little things. Basically, it’s like a best practices coding style. So in the same way you’ve got things like JSLint that catches JavaScript coding practices, even if your JavaScript is perfectly valid and will execute, this thing will catch little things which aren’t best practices. That’s what I use the validator for when I write XHTML – it catches little things that wouldn’t be caught if I was writing HTML. So even though I think that’s the reason most developers use XHTML, these people who really looked down on XHTML from the start were like, “Hah-hah, we won!” and were gloating now, and that kicked off a whole shit storm. I’m sorry I shouldn’t say that!

Paul: That’s okay.

Marcus: You can say what you like!

Jeremy: Yeah, so that needed clearing up and a bunch of us were like, “Okay, this is the story and this is what it’s like with XHMTL 2. I know it sounds like XHTML 1, but actually they’re different as chalk and cheese.” I wrote a blog post, and that was okay, and this guy Brad turned it into a comic, and then everyone read it. Then they were, “Oh now I get it – cartoon Jeremy says it’s like cheese, so now I understand it.” No seriously, it did make a big difference, it was more accessible…

Marcus: You must have been happy with ham and hamster…

Jeremy: That I did like; that got quoted on Twitter a lot.

Marcus: Fantastic.

Paul: So this leaves you writing what now? Are you still writing XHTML?

Jeremy: Let’s take sites I’ve built already, so my own personal site, adactio.com, that’s XHTML 1, it has been since 2001, I’m not going to change that. Actually I’ve made a vow not to change my mark-up anyway. Because I kind of assume when people redesign their sites, they change their CSS and they change their mark-up, and I think…

Paul: That kind of destroys the whole point of it, yeah.

Jeremy: So whenever I do a redesign, what I actually do is I add sort of a skin on top. So I’ve got a bunch of skins to my site, I kind of made a vow to myself that even if I’m doing a redesign and think it’ll be really useful to change the mark-up here, but that’s just me personally. Actually at work, and on other projects, I do now use HTML 5.

Paul: Right. Now how does that work, because everybody says, “Well, HTML 5 isn’t supported.”

Jeremy: It’s not ready yet.

Paul: No, exactly.

Jeremy: 2022…

Paul: Yeah, yeah – all of that kind of stuff.

Jeremy: Here’s the thing. If you want to write HTML 5, you take whatever doctype you’re using today, XHTML 1, HTML 4, HTML 3.2, and you change that doctype to ‘doctype HTML’, and there you go you’re writing HTML 5.

Paul: Okay!

Jeremy: So most of HTML 5 is HTML 4. The vast, vast majority of it is exactly the same language, and yet even that is really, really ambitious because one of the things they’re doing is they’re going to define error handling for HTML. Every version of HTML before this, 3.2, 4… All of these previous version, they just defined here’s what authors can do, you’ve got this element, you’ve got that element, boom – the end.

They never defined what happens when you do something wrong, or what a browser should do when it encounters mis-nested tags, things like that. So the browsers have had to kind of invent it, and what happens is that most browsers… Talk to a browser maker and they spend fifty percent of their time figuring out how does Internet Explorer handle this error, and recreating that. A huge amount of time is wasted on this. Or, whatever the leading browser maker is today, how does that browser handle errors? We need to copy that and reverse engineer it. The spec doesn’t tell them how to handle errors. So HTML 5, one of the ambitions is to take HTML 4 and define error handling for everything in it. That alone is massive; massively ambitious. And that alone would take a long time.

In addition, there’s new stuff. So you’ve got this web form stuff, you’ve got new types of inputs, user agents will be able to give us, you know, calendars and sliders and all this stuff, really cool. You’ve got some new structural elements, you’ve got some new rich media stuff like audio and video, you’ve got canvas… So that’s on top of the error handling. So, yes HTML 5 has a lot of new stuff that, frankly, you can’t use today, although a lot of it’s quite well supported, obviously not Internet Explorer, but in a lot browsers, you can use stuff like audio and video, and canvas and stuff like that.

You can’t use all of HTML 5 today, that’s true. But we probably don’t use all of HTML 4 today. For example, if you say, “I’m not going to use a mark-up spec if all of it isn’t implemented in the major browser vendor,” which would be like Internet Explorer, you say, “I’m not going to use a mark-up spec unless Internet Explorer fully implements it.” And yet you would have been using HTML 4 for years. Now, Internet Explorer didn’t fully implement HTML 4 until Internet Explorer 8 when they added support for the abbreviation element.

Paul: Right, okay.

Jeremy: Internet Explorer 7, Internet Explorer 6, Internet Explorer 5, didn’t support HTML 4, if you define support as every single thing in the spec. And you’ve been using CSS 2.1 for years. There isn’t a browser out there… Actually Internet Explorer is the first browser to fully support CSS 2.1, although you could quibble on some stuff, and yet we’ve been using it for years. Because if, ideally, you have to wait until something is fully support until you use it, it’s kind of silly, you just support features. You decide this feature is supported enough that I can use it. Enough browsers support video or canvas that I can use it today. So when people say, “I can’t use it because it’s not ready or it’s not support,” that’s too binary; it’s too simplistic a way of looking at it, because all the technologies we use today, CSS, HTML, are partially support in different browsers – that’s just the way it is.

Paul: Let’s talk about the new structural elements that have been added in to HTML 5. So you’ve got header and footer, and these various other things. I mean obviously you can’t use those as is at the moment because the support isn’t wide enough, is that correct or incorrect?

Jeremy: Well, support’s actually pretty wide in a lot of browsers. What a lot of browsers will do… It’s not so much that they’re supporting these elements, it’s just that they allow you to use arbitrary elements. So in Firefox and Safari, I could write a tag called ‘foo’, and in my style sheets I could say ‘foo, display block, colour red’ and it would work. So if you define working, or support as that, then actually yeah in Firefox and Safari and Opera you can use these new elements today.

Internet Explorer doesn’t have that, Internet Explorer doesn’t let you use arbitrary elements, but there’s a little JavaScript hack you can use to make Internet Explorer behave. In fact we’ve been using this for years with the abbreviation element. If I wanted to use abbreviation and style it in Internet Explorer, in JavaScript I would say ‘document.createElement(‘abbr’)', and suddenly I could style it. It doesn’t make any sense, but then again whatever does with Internet Explorer. So we use the same hack to say create all these new elements.

Paul: Okay, so are you using them at the moment?

Jeremy: No. What I’m doing is, I’m trying to get my head around how these structural concepts work, but I’m not ready to make the move to new elements, and I’m not ready to do client side work that relies on JavaScript, which is what I’d be doing if I used this JavaScript hack. So what I do is, I take the concept, I take the names – header, footer, section – and I use them as my class names. So I’ll have div class equals section, div class equals header, div class equals footer, and it’s partly so I can get my head round how these things work together, and also, it allows me to basically have self documenting code in that when I’m handing it off to developers that are back end developers who are building a system, I often give templates – HTML templates. And I would usually have to write out this is how this class works, and I’d have to comment everything and say the class of ‘foobar’ is used for this kind of content. And now I can kind of say, just link to the HTML 5 spec; header is for this, footer is for that, section is for this, and okay I’m using classes not elements, but the definitions…

Paul: Are the same.

Jeremy: Are the same. So there’s benefit for me getting my head round this new stuff and sort of getting a jump up on what we’re going to be using in the future, and it’s a benefit for documentation because it’s a great big spec documenting all this stuff. So I’m using them but not really in day to day work.

Paul: Because there’s some debate, is there not, about these pre-defined elements, you know, things like footer I mean. I was reading Zeldman about, well footer isn’t what you expect it to be. So potentially, as this is still in draft, you might be using footer in what will ultimately end up being the wrong way because they might change the way footer works and then you’re going to be out of sync with things.

Jeremy: Yeah, but it’s by using these things that you get to know these problems, and flag them up and bring them to the working group. In Zeldman’s thing, he said… So Zeldman asked a bunch of us to get together with him in New York about two weeks ago, because basically we’re all working web developers, we’re all interested in HTML 5, but we’re kind of sceptical of it, so like we’d be hearing conflicting things people say, there’s a lot of rumours going round, we don’t know what to believe, let’s all get together in one room and go through the spec.

We spent two days literally just going through the spec, and figured out how it affects us. And we’re not interested in the browser features, and the DOM stuff and the APIs, we’re interested in the structural stuff; we spent most of the time talking about this and the semantic meanings of these new elements, and that’s where we came against these issues. Like, wait a minute, the content model for what they call footer is totally different from what any working web developer would call a footer. So in our element, footer, you can’t put a nav element, and you can’t use headings, you can’t use H1s or H2s. But you ask a working web developer what footer is, and they point you to Flickr, or their blog they have, you know, “Oh a footer’s where I pull in my pictures from Flickr, and I have other navigation, and stuff like that.” So instead you have a flat footer which has kind of got a bit more popular in the last few years. So there’s a clash there in the semantic meaning of footer in English for most working web developers, and the semantic meaning of footer the element, and that’s something that came out of that meeting, we realised okay, this is an issue. That’s one of the things that we flagged up.

And there’s a few things like that, that when you really sit down and look you realise hang on, these two elements sound really, really similar, why are there two of them? So there’s a section and an article… For historical reasons I can see why they’re different, but they’ve actually evolved over time now to converge and get really similar. So we found a bunch of these things as authors we realised there were issues with, and we’re bringing them to the working group, we’re flagging them up, we’re publishing them, we’re blogging about it. And I think the reason this hasn’t really come to light before, is that most of the people on the list, and in IRC and the WHAT Working Group, they’re kind of hard core developers making web apps. These are the people building Google Wave, and building these big, big apps, and they’re not really thinking so much about the semantic meaning of documents. And also, there’s the browser makers, which is good – you want browser makers involved in the spec so that you know this stuff’s going to be implemented…

Paul: Yeah, of course.

Jeremy: As Hicksy keeps saying, you know, if one browser maker says I won’t implement this feature, that feature comes out of the spec, because otherwise the spec is just fiction, and it wants to be practical. And of course, that means the spec won’t be the best possible spec it could be, but it will be the best possible spec it can be and be implemented…

Paul: …Realistically.

Jeremy: Exactly, realistically. So, there hasn’t been enough working web developers involved in the process, in my opinion. There’s a lot of programmers, a lot of browser makers, not enough just, you know, working web developers. So, recently, Zeldman made this effort, let’s all get together. I’d been researching it a lot, and so I was explaining stuff to them, they were telling me about how they felt about this stuff, there was Eric Meyer there who’s got a lot of history with working with specs, and Tantek was there and he knows about how to read these kind of specs. So together we had a really good group of people, and we were able to come to the consensus that we can all… I mean, we disagreed on some stuff, I’d like to have this feature, and I don’t care about that feature, but there was a core set of stuff we all agreed on that was in the spec: this was confusing, that needs to either change, be dropped, stuff like that, and that would be our concerns. And what I what I’ve been encouraging people to do on my blog, which has kind of turned into an HTML 5 blog…

Paul: Yeah it has, I’ve noticed this!

Jeremy: …Is to get you, the kind of people who would read my blog, to get involved in the process, to get involved in the WHAT WG, and I’ve seen it happening, it’s great. I’ve seen web developers going on the IRC channel asking really basic questions like, “I’m confused by this element, how am I supposed to use it?” And then these people who are writing the spec, having to explain in normal words how it’s supposed to work, and then realising hang on this might be a problem, if I can’t explain it well then maybe this element is going to be an issue, and things like footer are obviously a problem; it’s got to change.

Paul: I read some article which seemed very left field, which was basically saying why is the W3C actually defining things like nav, and footer, and article, and section and all the rest of it? Why can’t we make up our own tags? Which kind of almost brings you back to XML I guess.

Jeremy: Yeah, the idea of extensibility. I think it’s probably John Allsopp’s List-A-Part article you talking about.

Paul: It wasn’t actually, but yeah I was aware of that one as well.

Jeremy: So there’s basically two schools of thought. What you need to provide is a mechanism for extensibility that allows anybody to extend it, and this kind of is the W3C idea of RDF and RDFA, that potentially you could encode any data in the universe, it’s infinitely extendable, and any author can define a vocabulary. And then there’s the other school of thought which is you keep the extensibility deliberately limited, and deliberately centralised to a community, and that people have to cooperate to decide what extensibility is to be used. Now that basically comes from the micro-format school of thought, where you don’t try and encode everything in the universe. You look for what’s the most common use cases, what’s the minimum you need to allow people to encode those cases, and you quantify that. You say we’ll create an element for that because eighty percent of people are publishing it, but we’re not going to create an element for something that’s really fringe, and sort of left field.

And that’s the way the HTML 5 group have gone, it’s like we’re going to keep things scarce and controlled, and if we create a new element it’s for a really good reason; we’ve thought about it, and it’s actually going to help web developers. And if anything, I think they might have created too many, not too few, and it’s only a handful, there’s maybe like ten new elements, you know structural elements, and if anything I think so of them could go.

So there’s these two very different schools of thought, and I was reading a blog post from 2006, nothing to do with HTML 5, it was to do with this idea of namespaces in HTML, which is what you get in XML – allows namespaces to allow you to create your vocabulary, you can put anything in there. It said if namespaces had been allowed in HTML then during the browser wars in the late nineties when this browser was inventing this tag, and that browser was inventing that tag, and it was just this mess of stuff, if there was a way to infinitely extend HTML, it would have legitimised that. They would have been okay with that, and we couldn’t have complained. As it was, they had to sit down in the end and sit around the table and hash this stuff out, because we complained and said, “It’s a messed up landscape and you’ve got some browsers supporting some stuff and some browsers support another thing.”

So, because HTML is limited, you have a certain amount of interoperability, and so I’ve come around to that point of view. That actually I can see the case for extending HTML and we have some mechanisms, we have the class attribute, a fairly limited extensibility thing, and I can see why for your own personal needs you might want to extend HTML, but I do actually think there’s a benefit to having a community deciding what’s the best elements, as long as that community is listening to all concerns, and that includes authors. My concern is that the community isn’t getting enough input from working web developers, but I see that changing. So I’m actually pretty reassured.

Paul: Okay, that makes a lot more sense. There’s one other question that I want to ask before we wrap things up, which is this canvas element. There seems to be a lot of excitement about canvas, but very little descriptions about what it does and why it’s exciting that is accessible to a lot of people, and understandable by a lot of people. Can you kind of summarise the canvas?

Jeremy: The canvas is a dynamic image.

Paul: Right.

Jeremy: The image element is static, and the canvas element is dynamic over time, and it can be interactive. So basically I believe you can have interactive graphs, you can have moving things like animation, you can draw on it and define movements… So it can do a lot of stuff that say, you know, Flash 1 could do, all this basic sort of stuff, and it is very exciting that where you would have needed a plug-in, you can now write an element and write some script, and you don’t need a powerful piece of software to write this stuff, you just need a text editor and everything’s cool.

So that’s good, and it’s already implemented in a lot of browsers; Safari, Firefox – they’ve got canvas, and people have already done really exciting things. John Resic has ported the processing language into JavaScript, processing.js, that uses canvas; it’s amazing. You’ve got this ball bouncing, and lines going, and generative art; all this amazing stuff – no plug-in required, it’s all native to the browser. That’s great. So the spec that defines canvas is for interactive or dynamic images. It is not for text. The spec doesn’t ever say… in fact it will forbid you from using text. But because it can, people have started putting text in there and then dynamically…

Paul: Because doesn’t Google Wave use it?

Jeremy: Err, I’m not sure about Google Wave, I haven’t really checked that out…

Paul: Perhaps I’m getting confused…

Jeremy: But Google is certainly experimenting with canvas with some things. But there’re things like… Have you seen Bespin? It’s this Mozilla project which is basically a text editor in your browser, or a code editor in your browser, and it’s all built using canvas. It’s incredibly powerful, it’s really impressive. But, those bits of text that are in canvas are just shapes to the DOM, there is no DOM saying this is a string, this is an element, it’s just there are some vector shapes, because canvas is just vector. So any piece of assistive technology just sees a bunch of… like there’s an image here of some kind. And you can find some fallback to describe the image, this is a chart showing blah blah blah, but if you’re putting a text editor in there, there’s no way they can interact with it, it’s just impossible.

Now, you could say, “But that’s not the point,” and the spec should maybe say you don’t use it for this, but people are going to use it for that because you can. So you say, okay, then the challenge is, if people are going to use it for that, even if they should be using a different technology like SVG or Flash, if people are going to do that how do we make it accessible, and that’s where there’s a lot of work going on. There’s people at Apple working on this, James Craig, who’s a really smart guy, he’s working on this idea of a shadow DOM that’s in canvas, so there is work on that. I personally think it’s such a big issue, it’s such a big thing, it’s such a powerful thing, I think it might benefit from being split off into its own spec.

Paul: Oh, okay.

Jeremy: Which has already happened with some HTML 5 stuff. Things like storage and client-side database, there’s all this powerful stuff. A lot of that ends up being spun off into a separate spec because it’s like it’s getting too unwieldy for the mark-ups.

Paul: Yeah, yeah.

Jeremy: And I kind of have this suspicion that this might be the case with canvas, because otherwise it may hold up the rest of the spec, and we’ve seen this happen with CSS 3. There were certain parts of the modules that were really important to solve for internationalisation reasons like text modules, but because that one part of CSS 3 was hard to solve it held up all this other stuff like multiple background images and border radius, and it held the hold thing back, and I would rather see things split off and worked on separately than be part of a spec and holding it back. So we’ll see; canvas is a big, big issue.

Paul: So you wouldn’t be doing a huge amount yourself in Clear Left, doing huge amount with canvas at the moment?

Jeremy: No, but that’s not the kind of work we do, it doesn’t really require…

Paul: But then the kind of work you do is the kind of work that a lot of the people listening to this will be doing. Rather than big fancy web apps.

Jeremy: Yeah, what we tend to do is documents that have interactive elements to them rather than applications that sometimes have document-like parts, and I think most people working on the web are like that, you know documents… Some things you want to be more interactive. So there’s other things in HTML 5 I would use, but that wouldn’t be one of them.

I’ll use some of the new input types already, because the default behaviour, if you say input type equals foo, the browser doesn’t know what foo is, it will just display a text input. That’s the default fallback behaviour for every browser. So if you try one of these new things like input type equals search, well in Safari will get this nice search field the same way you get in the Google search part of Safari; you get this nice styled thing with a little ‘x’ in the corner. Every other browser just gets a text input, which is what you would have got anyway. And there’s a few things like that I use today, because there’s no harm and because there is that kind of degradation that works well. But it’s the little things I use.

Paul: So, let’s finish things by saying okay, there’s some people that have listened to this and thought, “Yeah, really cool. I want to be doing some of that kind of stuff that you’ve just mentioned.” Where do they go to learn that stuff? And don’t say the spec!

Marcus: Where do normal people go?

Jeremy: The full spec has got loads of stuff for browser makers; we don’t care about that – we’re not browser makers. Michael Smith at W3C has actually spun off… Parse the spec, take out all the stuff for browser makers, and that just leaves the stuff for authors.

Paul: See, now didn’t that… That was like today that came out wasn’t it?

Jeremy: No, no, it’s been out for a while, but I pointed Zeldman to it and he blogged about it.

Paul: Ah, that’s where I read about it. There we go.

Jeremy: Yeah, because we’ve got this basecamp going for our HTML 5 super-friends group, and err…

Paul: You’re a super-friend!

Jeremy: Yeah, with unicorns.

Paul: Okay, that’s good!

Jeremy: And Eric was saying, “We should create a version for the spec that’s just the author’s stuff without the browser stuff,” and I was like actually that exists and it’s over here and then Zeldman linked to it. If you look at Zeldman, he’s linked to it; I’ve linked to it in my blog a few times as well. So there’s that, that’s really useful for just getting the semantics. Going to the IRC channel and the chat there, there’s also sites like html5doctor.com, that’s people like Bruce Lawson, and Remi Sharp, and these people. You have a question, you write to them, they answer the question.

Paul: Brilliant.

Jeremy: They also get questions from people with genuine medical problems, because they give out good Google juice for the word ‘doctor’.

So that’s very useful for web developers who say, “How do I do this? I don’t understand this element.” Yeah, start using it. I would say you’ve basically got three options today. You can just swap out your doctype to ‘doctype html’ and stop there, and just carry on doing what you’re doing – that’s one way. You can swap out your doctype and start using the class names that are taken from these structural elements, that’s what I’m doing, that’s another way. Or you can be hardcore. Swap out your doctype and start actually using these new elements, and use this JavaScript hack for IE.

So you’ve got these three levels of how far you want to go. I mean, on your personal site you could use that third option, push the boat out and go for it. I wouldn’t really do it on a client’s site yet. So you’ve got those things, there’s a validator, html5.validator.nu, and actually the W3C validator uses that, so you can validate HTML 5 today, and that means you can use Aria roles in HTML 5, which you can’t do in HTML 4 or XHTML and validate at the same time. So that’s really, really useful having Aria and HTML together. So you can do it today, keep up with HTML 5 Doctor, hang out in the RSD channel, and if you’re up to it, join the mailing list, although there’s a lot of talk from browsers makers. It goes way over my head.

Paul: Okay, thank you so much Jeremy, that was really useful. I think that has certainly clarified a lot for me, and I’m sure for a lot of people listening too.

Jeremy: I sew clarity.

Paul: Yes, thank you for passing your wisdom on to us.

Jeremy: Any time Paul.

Paul: Okay thanks.

Thanks goes to Gareth James for transcribing this interview.

Ryan Carson: advice on building web apps part 3

Hey everyone, I’m Ryan Carson, founder of Carsonified.com, the makers of Think Vitamin, DropSend and the events Future of Web Apps and Future of Web Design.

We’ve both failed and succeeded in building web apps so I’m going to share a few tips that we learned the hard way. Hope you find them useful!

Measure marketing success. As developers and designers, we often shy away from marketing as it’s perceived as dirty. This will absolutely kill your web app. So make sure every time you place an ad, send out an email newsletter or ask someone to link to you, use the Google URL Builder and track the results as a campaign in Google Analytics.
Write out the signup steps for your app. Before you even begin wireframing, spend a day jotting down the rough steps that the user will go through to sign up for an account. This helps you spot potential areas for improving the user experience. Make sure to pay special attention to which form fields should be required and what kind of help text you’ll write to accompany the page.
Give away free-upgrade coupons. When we were running DropSend.com, we placed a simple status message at the top of every page of the app. We changed it weekly to make sure people noticed it and we also made it really noticeable with colour. We regularly offered a coupon code which allowed users to upgrade for free for the month and it worked surprisingly well. I think this is because it removes the risk of trying out the more expensive plan. I’d definitely recommend it.
Create content for your potential users. One of the most powerful ways to do marketing for your product is to offer valuable content to your potential customers. This is expensive and time consuming but it’s highly effective. For example, if you’re building a todo list web app, write a blog that offers a free daily productivity tip or GTD hack. Make sure to offer a weekly newsletter – they’re very effective if they’re based on good content (and not cheesy sales offers).
Get your hosting and deployment nailed down. The thing that will haunt you forever is poor hosting and deployment methods. I’d highly recommend that you make a 1-button deployment system that quickly deploys from a development environment to a staging environment and then to a production server. Make sure the database on the staging environment is identical to production, as this will help you spot bugs. I can’t tell you how many times we’ve had trouble because no one except the developer new how to deploy the site. It needs to be easy, bullet-proof, and reversible if things go wrong.

That’s it – hope everyone found those simple tips useful.

By the way, we’ll be discussing other important web app topics at The Future of Web Apps on Sep 30 – Oct 2nd in London. Speakers include Twitter, Facebook, Mozilla, Gary Vaynerchuk, Kevin Rose of digg, Mike Arrington of TechCrunch and more. Feel free to stop by the site at http://bit.ly/fowa-london-09

Creating a Draggable Sitemap with JQuery

Posted in Development on September 1, 2009 by Dave McDermid

A couple of weeks ago I was tasked with building a drag-and-drop sortable sitemap for our in-house content management system. After a number of failed attempts, here’s how we ended up solving the problem.

There are a handful of javascript libraries and plugins available that attempt this task, but none of them worked flawlessly with our HTML. The real issue here is that javascript alone cannot produce a slick solution, the HTML and CSS need to be carefully constructed to ensure that the experience is seamless and pleasant.

The HTML.

Our HTML consists of nested unordered lists, with each list item containing a definition list for the title, page type, publish status, and action links for editing or deleting the page. The feature for expanding and collapsing child pages already existed, making things extra fun.

[html]
<ul id=”sitemap”>
<li>
<dl>
<dt><a href=”#”>expand/collapse</a> <a href=”#”>Page Title</a></dt>
<dd>Text Page</dd>
<dd>Published</dd>
<dd><a href=”#”>delete</a></dd>
</dl>
<ul><!–child pages–></ul>
</li>
</ul>
[/html]

The requirements.

The behaviour had to intuitive for the user, they need to be able to reorder pages and move entire sections to new parents. It had to be clear to the user where a page would end up when they dropped it (ie. between pages or as a child page).

Simplifying the task.

When one page is dropped over another page, there are three possible outcomes. The page can end up before, after or as a child. This gets particularly tricky at the boundary point between the last child of a sub list and the following sibling. If the resulting location of where a page ends up is the difference of a couple of pixels, the user could become frustrated. We decided to simplfy the problem so that a page could be dropped only before items or as children of items. The only limitation here is that you couldn’t easily drop an item as the last child of a list, but this is only a minor issue as moving the last child up would achieve the same result. You can also drop an item on the parent to cause it to become the last child, but this isn’t so obvious really.

This means for each item on our list we now need to identify two areas where the user can drop the page, on the page to be a child, and above the page to be a sibling.

The javascript.

The great thing about jQuery / jQuery UI is how it lets me write the code I want to write, and takes care of cross-browser behaviours and gaps in DOM manipulation. Anyone who has attempted at creating drag and drop functionality for a website will be well aware of the headaches involved in getting everything to work smoothly across browsers. jQuery UI seems to handle this brilliantly.

The first thing I want to do is create a div inside the list item to act as a dropzone for placing items as siblings.

    $('#sitemap li').prepend('<div class="dropzone"></div>');

piece of cake.

To allow an item to be dragged, we simply call the draggable() function on the items that can be dragged.

$('#sitemap li').draggable({
    handle: ' > dl',
    opacity: .8,
    addClasses: false,
    helper: 'clone',
    zIndex: 100
});

As we are dealing with nested lists, it is important that only the definition list inside our list item acts as a handle, otherwise our old friend Internet Explorer can get a little confused over who’s meant to be moving and who should be staying where they are. By specifying ‘clone’ we create a duplicate list item that follows the mouse, while the original item waits patiently for us to decide where it should belong. An opacity of 0.8 and a high zIndex keeps the clone on top of everyone else and slightly opaque. It’s the little touches that really count.

The magic.

$('#sitemap dl, #sitemap .dropzone').droppable({
    accept: '#sitemap li',
    tolerance: 'pointer',
    drop: function(e, ui) {
        var li = $(this).parent();
        var child = !$(this).hasClass('dropzone');
        //If this is our first child, we'll need a ul to drop into.
        if (child && li.children('ul').length == 0) {
            li.append('<ul/>');
        }
        //ui.draggable is our reference to the item that's been dragged.
        if (child) {
            li.children('ul').append(ui.draggable);
        }
        else {
            li.before(ui.draggable);
        }
        //reset our background colours.
        li.find('dl,.dropzone').css({ backgroundColor: '', borderColor: '' });
    },
    over: function() {
        $(this).filter('dl').css({ backgroundColor: '#ccc' });
        $(this).filter('.dropzone').css({ borderColor: '#aaa' });
    },
    out: function() {
        $(this).filter('dl').css({ backgroundColor: '' });
        $(this).filter('.dropzone').css({ borderColor: '' });
    }
});

Ok. That’s a fair chunk of code, let’s break it down.
We only want to accept sitemap list items, we don’t care about other items they care to drop here.
The tolerance specifys the drop item to be the element under mouse pointer, we’re expecting the user to place their mouse where the item should end up.
When the drop happens, this is how we decide what to do:
We set the variable ‘li’ to be the parent of the dropzone (as both the definition list and the dropzone div are children of the list item). This is just for convenience.
When the user drops the page, we need to decide what they landed on, if it has a class ‘dropzone’ then we are placing the dropped item before us. Otherwise we are placing this as a child.
As the item is being dragged around, it is imperitive to give an indication as to where it will end up. We can do this by conditionally applying a background colour to whichever item we are hovering over. For the ‘dropzone’, we instead apply a border colour, as we want it to display as a solid line between the two items.

At this point we can also fire off our update in an ajax post to the server, in order to commit the change.

The CSS.

The secret to the interface working really well is CSS. By making sure we have the right paddings and heights in the right places we give the user enough space to comfortably drop items. If we keep the space around the definition list tight, and apply a 4px border plus 6px height to the ‘dropzone’ div, we give the user 10 pixels of droppable area. This is plenty to guarantee the user will be comfortable. The 4px border gives us a strong, clear indication that the item will be dropped as a sibling.

Extra spice

In the demo you’ll notice the addition of an undo stack. This is a great fall back for when a user moves a page to the wrong place but forgets where it came from. This will be covered in a separate tutorial.

Demo: http://boagworld.com/demos/sitemap

For more info, checkout the jQuery UI docs: http://jqueryui.com/demos/

179. Affordance

Posted in Classic shows on August 18, 2009 by Paul Boag

On this week’s show: Ryan and Stanton are back and we are joined by Mr Marcus Lillington! We talk to Dan Rubin about making your interface invisible and answer your questions about working on multiple projects at the same time.

Podcast: Download (30.8MB)

Download this show

Launch our podcast player

News

RTFM

The first post this week is an article on webdesignernotebook.com from Yaili, in which she has a little rant on the fact that we, web designers, like to complain about how little recognition our profession has, how everyone likes to think they can make a website, and how clients don’t respect our work. But when it comes to actually doing something that could make us a bit closer to any other “official” profession, we’re bored and dismiss it. It’s so much funnier to complain about IE6!

Yaili has made a point of reading through the W3C specifications for CSSS2.1 and 3, HTML 4.01 and HTML 5. While most of us claim to be familiar with the specifications, how many of us – hand on heart – can honestly say they’ve fully read all of them?

The W3C specs are the closest thing we have to a manual and anyone who works in this field should have read them at least once, we don’t have to know them by heart or be able to quote from them, but we should be familiar with what they contain and be able to use them as a reference like any other professional book, as Yaili says, “After all, those specs lay the foundation of what we work on every day, so we should at least have an overall knowledge of them and of what they address.”

I know personally, this post has acted as an encouragement to print off the specs and read them again on the commute.

Structural Tags in HTML5

If you’ve been inspired by Yaili’s encouragement to read the HTML5 spec’s, then the next post might be of interest to you also. The HTML5 specification has added quite a few interesting and useful tags for structuring your markup and will replace many of our typical DIV entries from our code.

Of course this is an audio podcast, so I’m not going to start reading code out for you, but this is a nicely detailed article which explains the new tags such as header, footer, nav, article and aside which you can start using today, and includes a couple of tricks to make current browsers treat them as they should by using the CSS display:block attribute as well as a javascript fix for Internet Explorer.

It’s a nice primer for anyone starting to play with HTML5, so give it a read!

Redesigning your own site

And finally we have an article on A List Apart which touches on those times when you have to deal with your most difficult client. Yourself.

Lea Alcantara discusses her experience and thought process of redesigning her personal site. Your personal site has to demonstrate proficiency in the very latest development and trends in the industry while remaining true to the brand which you may have taken years to establish. Cameron Moll’s mantra of “Good designers redesign, great designers realign” features heavily in this thought process.

The article details Lea’s process from start to finish, explaining certain dead ends – like thinking she could jump right into Photoshop and play – to starting with her branding and letting the design evolve from that. She explains how she consulted with some trusted design friends and urged them to provide objective design analysis instead of personal taste.

While the article is focused on a particular site design I think there’s some good tips in here that we can all take away, or at least keep in mind when we decide to work with our most difficult client.

Interview: Dan Rubin making your interface invisible

Ryan: You did a really good talk this afternoon on “making your interface invisible”.

Dan: Thank You

Ryan: What does that mean then? *Laughter*

Dan: Select all…. delete

Ryan: Hiding the interface from your users

Dan: making you interface invisible, doesn’t mean what it sounds like. Thankfully. It’s about the idea of designing for the experience rather than for the visuals or particular features or anything like that. Making those blend so far into the background that users don’t even notice them. That’s what I mean by making the interfaces invisible.
It’s not a new concept if you do a couple of searches on The Google, you will actually find even A-list apart article back in 2000 covering the same kind of stuff. It just hasn’t seemed to sink in and one of the reasons that I’ve kind of thinking lately is that there just aren’t enough designers and developers talking about it. Usually you here about the concept of it an interface disappearing being talked about user experience (UX folk) designers or usability experts and consultants. A lot of the time designers and developer just don’t listen to people who are the same us, those who don’t do exactly what we do. We do listen to them but we just don’t listen in the same way. So if we only hear the same kind of advice from people who aren’t doing what we are doing it’s easier for us to dismiss it. I think it’s more important for people who do the actual design and do the actual development to be talking about it not just thinking about it, but doing it.

Ryan: You mentioned in your talk your talk was targets at not just people who design interfaces but (I can’t remember how you put it), not just designers who push pixels around who do the actual visual design. I’ve always associated interface design with that.

Dan: The thing that I’ve learned from clients (first of all) and then then I realised it applies to all of us. Is that when people hear the word “design” they think that it’s something visual and it’s not. The concept of design is much more basic, its creative problem solving. I mean it can be called a lot of things, but design isn’t just a purely visual task and you can design thing without any visual element. People who design applications aren’t designing the interface to the application; they are designing the interaction, that’s why we have so many. The answer to that the industry has come up with is to come up with a lot of different terms that your experience designer, that your interaction designer. The reason we have to come up with these terms is that people hear design on its own and they think visual. But that’s a visual designer, a graphic designer an interface designer. If were just talking about the process of design, it’s something that everybody is a part of. Whether you’re a developer, an information architect, an interface designer or you’re an amateur, it really doesn’t matter. Your part of the design process. It’s a much bigger concept, that’s why when talking about the idea of designing for the experience, trying to design the experience itself rather than specific parts of it and making sure those parts blend into the background. People just come away having a wonderful experience. That’s why everybody in the team on a given project has to be a member of the design process, otherwise that won’t happen.

Ryan: In your talk you mentioned mimicking physical interfaces and you were kind of talking about trying translate what we do in the real world into your interfaces and those kind of experiences, it’s that right?

Dan: yeh, well there is this concept that we all know, we all talk about look and feel. That’s a common phrase that’s used a lot. But a more specific concept and term that I recently discovered called “affordance” and it’s been around for ages. It’s not new to people who are cognitive psychologists or who are in product design and it really we do the same thing with interface design. Any that’s designed for the screen, especially if it’s designed to be used like applications are. What we are really doing is designing products and software designers again know about this, but for some reason in the web world we’ve got a lot of people who haven’t come up through the traditional lines of education, which includes a lot of that psychology background. Which is fine as long as we are open to learning this stuff and realising we should know it. It all exists and has been around for ages. It’s basically the principal that allows us to interact with objects and interfaces in the real world, outside of the screen, and understanding that we use the size the shape the texture and constancy of things that we interact with in the real world to know how to interact with them before we touch them. And that’s the concept of affordance. That’s what it’s about those aspects of an elements design and construction or what not, that us to know exactly what to do with it and how we can interact with it. There are a lot of great examples of this in Donald Normans book the design of everyday things, which is a product design book essentials but so many of the principals apply to what we do. Not just interface design but again the design of applications and design of interaction. People are using what we build and that’s no different to people using a product that you’ve designed and engineered. We are designing and engineering what ends up being a total experience, it’s not something we can hold in our hands like a physical product but it’s a virtual product.

Ryan: You mentioned that you shouldn’t have to describe your interfaces; they should be intuitive to use.

Dan: I’m very against instructions in interface design.

Ryan: this leads me catching you taking pictures in the men’s toilets earlier.

Dan: Yes, this could be seen as compromising. But …erm… (Ryan has a little giggle fit) I do that all the time.
What I’ve found once is that now that I’ve started looking outward because I didn’t start as a designer in interface design. I started as a graphic designer and doing print. And so I’m always looking at things in the real world for inspiration. For whatever reason in the past year or so I’ve started actually realising how many direct parallels, 1 to 1 parallels there are in the real world with these interfaces that are all around us, they are just 3 dimensional. We just interact with them physically instead of through the intermediary of the mouse or the track-pad and the keyboard. And really they are not that different and so the examples in the restrooms, they are full of them for some reason whether its public restrooms or private stall in a hotel where something clearly hasn’t been designed to be intuitive and thus it needs printed instruction. It doesn’t mean instructions are bad, there are something’s that are so complex that they can’t be simplified beyond a certain point, so they need some sort of instructional text. But far too often we use instructions as an easy out, where we design something that really should be more intuitive, but instead of going back and redesigning it we put a little help icon next to it (or a little bit of help text when someone hovers over it). Or we will just put up a help page, before someone begins a task, and we expect people to read this stuff. The fact is people notice it’s there, they don’t always necessarily read it but they know it’s there and so it’s adding visual clutter that is probably not necessary. If you redesigned that interaction you could get rid of the need for instruction, you make intuitive there is no need for explanation. I think it’s a good marker in the design process that if you find an element of your interfaces requires instructions then you need to redesign it and keep refining and redesigning it. It may not be a refinement it maybe redesigning it from scratch but if you’re always on the lookout for that, like “Is this intuitive? Does this work without someone explaining how it works?” if you keep on doing that you won’t dig yourself into a hole.

Ryan: sorry I’m just chuckling to myself about your toilet reference. Realising that the last person I interview was Elliot J Stocks and I began that interview with “Hi Elliot the last time I saw you were outside a men’s toilet” (fits of laughter) I’m going to be getting myself a reputation.

Dan: it used to be the water cooler and now apparently it’s the restroom.

Ryan: we have to clear up the reason the men’s toilet reference was because you were taking a picture of a diagram of the showing taps and a description.

Dan: the taps that we are all familiar with now that are motion sensitive that don’t have taps anymore to turn them on and off, you just put your hand under it. And that design is not new it’s been around, I’ve never seen one with instructions because it is intuitive. They haven’t broken this one the one in the restroom here just works but even though I knew how to use it, the fact that I saw that descriptive image and text next to it. And its next to every single sink, it was a distraction. So where I would have been able to just go and put my hands under it, for a split second I was distracted by oh what’s this instruction. It made me think that it was something that I didn’t know how to use and that’s where instructions can be bad as well. Maybe you’ve added it in because you mean well, not because you need the instructions but you think that it will help the user by having them there. That that extra bit of information never hurts and that’s actually the wrong thing to do. It has the opposite effect, it adds clutter. If something is intuitive then you’ve spent the time designing it well that people don’t need instructions, by adding them you are actually making it harder to interact with.

Ryan: its weird (repeated… 3 times?) weird occurrence isn’t it. You also mentioned looking at desktop application design and translating that to the web, I found that really interesting. Can you talk about that a little bit?

Dan: yeh, there is a lot we can learn about interface design from the desktop. We can’t do everything on the web and even with things like adobe air and flex we can’t do everything we can do we can when building desktop applications. The thing is that basic interface conventions have been around a lot longer than any of our interface conventions, that we tend to think of being created on the web. The fact is that they haven’t there are very few things that are web specific. One of the things being the silly little Mickey mouse hand icon that we mouse over a link, that’s one of the main examples that I gave. In the desktop we have a much more precise pointer mouse or the default mouse pointer rather (the arrow) whether you’re on a Mac windows or Linux it doesn’t matter. It’s consistent, it has a very specific point, you know at the very tip of that there is one pixel that we use to interact with whatever we are clicking on. It’s much easier to use and target something accurately. Whereas the Mickey Mouse hand is more vague, there isn’t a single point that is clearly defined in the icon and on top of that it only appear once you’ve already began your interaction with something. Developers and designers we tend to work with the web and applications very differently than most users. We’ll mouse over things because we want to see whatever hover effects there are, we appreciate maybe the idea of discoverability in an interface more than the average user. Whereas a regular user (if I can make such a general statement) will look at an interface and without moving their mouse around, they will decide what they want to interact with before they then go and interact with it. So if the only way of knowing something can be clicked on is mousing over it and seeing that hand icon appear it’s not intuitive. Something can easily be missed and so what I suggest is to take a cue from the desktop and only use that hand icon for what it was originally designed and that’s hypertext links. So if you’ve got a link that you’ve underline in your text on a webpage or in a web app, as long it’s an underlined text link in the body of text use it, leave it as the default. Everywhere else if you use that default mouse pointer it’s much more like using a desktop app and it’s much more precise and it forces you to design something that looks like you can interact with it before the mouse ever gets near it.

Ryan: do you think people are just possibly used to the mouse cursor changing to the pointer, and if you took that away, that could possibly have a detrimental effect rather than a positive effect?

Dan: I don’t think so, I think we are as the creators of the web. But based on the fact that I still see some users trying to double click things on the web for instance, that is a connection that none of us on the web “we don’t do that”, and that in some instances that we should. There are some instances through JavaScript where we can do that, basically if a convention exists we should try and use it because it makes for more intuitive experience. So if we have an interface in a web app that require folders for instance, and that are folders that are more like on the desktop rather than a list in a sidebar, it makes sense that we if it was a desktop app that we double click it. We wouldn’t just do a single click, so let’s make that web app respond with a double click because that’s what people tend to expect. The mouse point, that Mickey Mouse hand isn’t something people expect, because it doesn’t happen until they have already made a decision. Maybe they are used to it appearing but it doesn’t affect their decision making process and because of that if you eliminate it what you will find is people won’t notice it’s gone. You will be designing thing people know they can click on and all they are interested in is mousing toward it and clicking on it. If it looks clickable they won’t expect that cursor to change as much, otherwise people would not be able to switch from using a web browser to using a regular desktop app because that hand never appears. If they were reliant on that they wouldn’t be able to use the web for an hour and then use a regular menu-ed app, they would be confused about how the cursor wasn’t changing but that’s not how people work.

Ryan: I think as well how many times have you seen people where they look at a file structure and expect to be able to right click on a folder and have all the options that you normally have. And just because that’s they are familiar with.

Dan: exactly and that’s what I talk about learning from the desktop, that’s the kind of thing that I’m talking about. The desktop has been around and creating these conventions for a lot longer than the web has. Users have been using desktop apps longer than they have the web, maybe you can find younger users who are coming to the web first and barely using desktop apps, it doesn’t mean they don’t use their operating system, they do. They use their web browser too. Those are the first thing they interact with when they start up the computer. Until we get to the point where (and I hope this point doesn’t come) if we had a device that was only a web device and had no other interface than the web then maybe you could make an n argument for it. But I think that would be a bad thing, I would rather see the web and the desktop come together as far as interface conventions and how we work with them in applications. Rather than being web applications, I would rather see them just being applications and when you use them you don’t think about if you’re using something that’s running in a web browser or that’s communicating with a remote server rather than your hard drive. You’re just using an application to do a task, there shouldn’t be a distinction and I don’t think that users have as much of that distinction that we do as developers. We like to think that there is a huge difference between a web app and a desktop app, but the for users it’s likely they don’t think of it in those terms. This is where I complete this task they don’t think that Gmail a web app it’s not a necessarily a web email app it’s their email. It’s their inbox, that’s how they think of it and we have to understand that’s how users perceive what we do. It’s a very very different way to look it.

Ryan: Especially as the barriers are disappearing, things like adobe air for tweet deck and emailing to outlook and mail. And the walls are just fading away.

Dan: Which is a good thing, as those walls fade away we need to as practitioners on the web we need to take as many cues as possible from the desktop and help make that transition more seamless.

Ryan: you mentioned a few resources in your talk, and I bet you can’t remember them…

Dan: Actually I can. I remember…
Jared (I would remember him anyway) – he has uie.com has excellent resources about all sorts of things about usability and that’s ultimately …that’s what this is all about usability. The article I refer to at the end of the talk of Jared’s was one he published the exact same day that I came up with the description for the idea of this talk that I gave today. So it was an odd moment and it’s about the exact same thing that this talk was. Keeping your interface invisible.

Ryan: and your talk previously

Dan: well yes we have been doing work with Jared, we have been very lucky to do a couple of workshops with him. It’s always fun to share the stage with him; it’s even fun to chat with him over dinner because you always learn something. You always come away with a smile on your face even if all you learned was how to laugh and enjoy his magic tricks with the card deck. It’s always enjoyable, so hes a great resource, his site is great resource. And UIE as a company is great resource if you’re looking for information about user testing, usability it’s the place to go. And the article is very recent so look on his site and you will see it on the list of articles a specific lot about invisible interface design and the experience.
I also reference Steve crouges book don’t make me think, which is awesome, excellent, funny, good, and thin. All the things a book should be. Educational, easy to read and short.

Ryan: plane flights worth it isn’t it

Dan: exactly yes, if you don’t have it you will get it and read it and find yourself going back to it again and again and dog ear it and mark it up like crazy and you share it around and sometimes don’t get it back.
And the other book by Donald Norman, the design of everyday things. It’s really a product design book but it’s useful for anyone who deals with designs that are meant to be used by someone else.

Ryan: have you seen thedieline.com product design website.

Dan: no I haven’t

Ryan: it may have been Elliot J Stocks last time he was on I believe it’s just the thedieline.com And it’s looking at product design. They release a series of particular products like an aerosol can or packaging for a toy and look at all different packaging. It’s really interesting.

Dan: I will have to look it up.

Ryan: it’s a really good site

Dan: I eat that stuff up because the more I look outside of the web the more I find that everything that we are doing, that we feel like we are discovering for the first time has already been done. A lot of it has already been done, especially the basic concepts of product design or we talk about information architecture all the time, but we didn’t invent the term. It’s been around for decades and possibly even decades before the web was around. And it comes from architecture and way finding enviromatnetor graphic design, these are concepts that people have been thinking about for a lot longer than we’ve been thinking about them. Possibly for a lot longer than some of us have been alive. I think it puts what we do into perspective; first of all there is a wealth of information and knowledge out there that’s been proven which can help convince us and our clients. If we are going to someone and we are explaining the idea of information architecture to them and we’re not just explaining it as something new in particular for the web. This thing has been around since before the web was even thought of that making it a whole lot easier to gain credibility with clients. It’s not just information architecture it’s so many of these basic principles of interaction, they are all basic psychological principles of human interaction really.

Ryan: what was that word you’ve been using all day again?

Dan: affordance – look it up its good stuff.

Ryan: ok Dan, well thank you very much for taking the time to interview you.

Dan: thanks for letting me ramble on

Ryan: it’s been a pleasure to see you again

Dan: always. Thank you

Much thanks goes to Andy Kinsey for transcribing this interview.

Listeners Questions

Stories of our failures

Dinu writes:

Looking from afar, established agencies like yours seem to be almost perfect. However, I’m sure you’ve had to deal with missed deadlines, over-booking, etc. I would like to hear about some of these #fail stories (just to get a “you are not alone” feeling for the rest of us), and also to know how you managed to overcome these common pitfalls.
Hope this question gets a chance of being aired.

Thanks and stay awesome….

Transcript coming soon…

Working on multiple projects

Emil Sundberg writes:

Hi, I’m running a small web agency and I just found your podcast. Great show!

We’re a small team, 4 people, doing web development for clients and use Basecamp/Backpack/Highrise/Campfire (yes we’re 37signals addicts) and I think it would be interesting to hear you talk about how you work with your team in the big picture, not an individual project. How do you plan multiple projects with a limited staff? Who’s deciding what’s most important and what should be done next. Do you use and planning tools or an Excel/Whiteboard?

Transcript coming soon…

169. Type

Posted in Classic shows on June 10, 2009 by Paul Boag

On this weeks show: Paul talks about the power of story telling and shares some tips for “getting in the zone” and Mark Boulton joins us to talk about web typography.

Podcast: Download (24.8MB)

Download this show.

Launch our podcast player

Housekeeping: Jobs and Projects

Whether you are looking for a freelancer to build your latest web project or a permanent addition to your web team, the Boagworld forum is now the place to go.

We have added a new jobs category which lists web design projects and jobs free of charge. So, whether you are looking to post a job or pick up some work you should take a few minutes to check it out. Right now there are jobs for…

A web project manager
A joomla expert
ASP.net developers
PHP developers
And much more.

News

Coding like its 1999

This week Cameron Moll has posted “Coding like it’s 1999“. The reason for this witty title is his decision to return to using HTML 4 and pixel font sizes, both of which were best practice in 1999.

The post is essentially a justification for these two decisions and he puts forward a very convincing argument for both. He credits his decision to move back to HTML 4 to Dave Shea who recently wrote a compelling argument to drop XHTML. Dave writes…

Six years ago, many of us thought XHTML would be the future of the web and we’d be living in an XML world by now. But in the intervening time it’s become fairly apparent to myself and others that XHTML2 really isn’t going anywhere, at least not in the realm that we care about…. I’m not ready to start working through the contortions needed to make my sites work with an HTML5 DOCTYPE yet, which leaves me with the most recent implemented version of the language…. [U]ntil I get a better sense that HTML5 has arrived, 4.01 will do me just fine for the next four or five years.

As for the decision to move back to pixel based typography, Cameron writes…

However, recent versions of every major browser — Safari, Firefox, Google Chrome, Opera, and yes, Internet Explorer — now default to page zooming instead of text scaling… What does all this mean? It means px can again be considered a viable value for font-size. It means the difference between setting text with absolute units or setting text with relative units is negligible for users. For you and me, however, the the difference is substantial. The burden of calculating relative units throughout a CSS document is replaced by the convenience of absolute units — 14px is 14px anywhere in the document, independent of parent elements whose font-size may differ.

Although at Headscape we still work with XHTML, we have moved back to pixel base typography and I suspect will do the same with HTML. I do not think it will be long before most web designers follow suit.

The power of words

Problogger has published a post that demonstrates the importance of our words. It shows how the words we pick can have a real effect on how users act. Word your copy carefully and you could substantially increase conversion.

Interestingly the post does not demonstrate this through example of good website copy. Instead it looks at the language used by successful waiters. The article takes three phrases often used by waiters and explains why they are so powerful. The phrases are…

“Our chef recommends”
“Everyone else has ordered… and they love it”
“So gentlemen, is everything delicious?”

From these three phrases he raises the following points…

Invoking the power of a higher authority will influence decisions - For example using a testimonial from an influential figure.
People believe in safety in numbers - “If others like something then surely I will too”. For example highlight your most popular products or articles.
Positive wording generates a positive feeling – For example “Thanks for subscribing to my email feed! I hope you find every post as exciting as the one that made you subscribe”.

It is an excellent article and there is a lot more detail than I have covered here – make sure you check it out.

10 tips for creating a more usable web

The Web Designers Depot has published “10 Tips to Create a More Usable Web“. Its not exactly the most original post and we have seen similar posts from Smashing Magazine in the past. That said, it is still a worth while read.

The problem is that it is so easy to forget best practice when it comes to web design. There is just so much to take into account as we design a website that we can easily overlook things. Articles like this may not necessarily teach us anything new, but they do bring to the fore best practice that may have been pushed out by more recent issues such as WCAG 2 or web typography. We can never be reminded enough of the principles of usability.

This particular list includes…

Creating active navigation
Clickable labels & buttons
Linking your logo
Increasing the hit area on a link
Adding focus to form fields
Providing a useful 404 page
Using language to create a casual environment
Applying line height for readability
Utilizing white space to group elements
Being accessible

As with all good list posts, each point is accompanied by a brief explanation and some nice examples. Check it out.

Four quick tools

I conclude today with a quick round up of various tools that have been released this week. Its a bit of an eclectic mix but they are all worthy of note…

Google Page Speed – Page Speed is an open-source Firefox/Firebug Add-on. Webmasters and web developers can use Page Speed to evaluate the performance of their web pages and to get suggestions on how to improve them.
EntityCode – HTML entities are HTML code that is used to display special characters such as the £ sign. However, remembering them all can be tricky. EntityCode is a useful reference that lists some of the most commonly used HTML entities in a very swish AJAX driven format.
Google Web Elements – Google Web Elements allow you to easily add your favorite Google products onto your own website. Widgets include calendar, conversations, custom search, maps, news, presentations, spreadsheets and Youtube news. All of these widgets existed previously but have now been brought together on a single site.
Adobe BrowserLab – Adobe BrowserLab is a browser compatibility service that provides designers screenshots of their pages on leading browsers. There has been a lot of excitement around this one, but I was not overly impressed. Sure the interface is nice and Adobe are a big name. However, the service only offers screengrabs (not interactive sites) and only for a limited number of browsers. In my opinion there are better services out there such as Litmus’ Alkaline.

Interview: Mark Boulton on web typography

Paul: So, the next in our series of interviews from the Future of Web Design is with Mark Boulton. Hello, Mark.

Mark: Hello there.

Paul: So… we interviewed you on boagworld, didn’t we, about… quite a while ago.

Mark: It was a while now, January?

Paul: Yeah

Mark: Something like that.

Paul: Something like that, yeah.

Marcus: What, that long ago?

Paul: Well, in internet terms, that’s forever.

Mark: That’s forty years ago.

Paul: So, at the time, you were just embarking on this odyssey of doing a redesign with Drupal, or you were part-way through it. And we were talking about this very unusual approach of ‘Hey’, you know, we normally discourage people, don’t we, from doing any kind of, don’t show your design to a group and you were showing it to thousands of people.

Mark: Yes, yes.

Paul: And you talked about how great it was going to be and there was this slight fear and trepidation in your voice at various times. How’s it gone?

Mark: It’s gone really well.

Paul: Has it?

Mark: It has. It’s gone really well. It’s been terrifying on a daily basis. Posting comments for… you know, registered users on drupal.org are about 400-500 thousand.

Paul: Right.

Mark: A fairly active, passionate community; a lost of these people have invested time, money and have businesses riding on Drupal. So, however, the vast majority are really in favour of what we’re doing.

Paul: So what, how did it work in practice? You know, were you uploading designs to a blog and just saying: ‘Hey, have your say’ or was it more structured than that?

Mark: It was more structured than that; it wasn’t initially, I mean we’ve learned some painful lessons along the way. But it was a very distributed approach, so we’d have a Twitter group, we have, sorry a Twitter account, we’d have a flickr group, YouTube groups, our own blogs – mine and Leisa Reichelt’s.

Paul: Right.

Mark: We’d have drupal.org, which is the main kind of Drupal page, but we’d also have groups.drupal.org where you can create your own little groups and we’d have a group there.

Paul: OK.

Mark: The view is that, so if we just posted things to Drupal, if we just spoke to the Drupal audience, we’d get a very slanted feedback on what we were doing.

Paul: Of course.

Mark: So, the idea was that we would touch on all sectors of the, kind of all bits of the audience. And then we’d, we were working weekly iterations on a 12-week schedule.

Paul: Right.

Mark: Which was killer.

Paul: Yeah.

Mark: We would not do that again and we would release material, whatever that would be; mostly it was HTML prototypes, fairly lo-fi, and we’d release them on a Thursday and then we’d sit on our hands

Paul: And watch.

Mark: And watch, yeah, with trepidation.

Marcus: Dealing with hundreds of thousands of comments.

Paul: How did you deal with that?

Mark: Yeah, we, we…

Marcus: Ignore them!

Mark: At first, I mean, there’d be the odd occasion where you’d get flamed and things could get personal and nasty and the&helllip; of course, the natural, human reaction would be to get in there and defend yourself and, but we, after a couple of times of trying that, which didn’t work, we didn’t, we really had to walk away from the computer and…

Paul: Yeah, I think that…s a good lesson for anybody running a community or interacting with people.

Mark: Absolutely, I mean the first lot, you know, if you post something up to a community, your first day’s worth of comments are setting the scene and then the following days from that trends will start to emerge &endash; repeated themes &endash; and that’s what we were watching for. So, we’d spend maybe four days, through till the Monday, just watching, you know, over the weekend, which was quite nice because we could do other&emdash;have a life…

Paul: Which is always good.

Mark: Yeah. And then we’d go back over the comments on the Monday and try and establish some themes that we agreed with and we put forward into the next iteration.

Paul: Right.

Mark: But it’s probably worth saying at this point that it was not a design by demo… it was not a, kind of, a democratic process.

Paul: No.

Mark: Because you just end up with mediocrity, I mean, kind of a little bit of a dissing WordPress here, but what WordPress are doing with the voting.

Paul: Right.

Mark: That’s not really our approach. Our approach was… we had a clear design vision.

Paul: Right.

Mark: And we pretty much stuck to that, but it was the way that you presented the material and gathered the feedback, that’s kind of steering that vision.

Paul: Yeah, so did you learn lessons about presenting the material and how to do that?

Mark: Yeah, we’re still doing that, we’re still on a kind of weekly basis.

Paul: Because that’s always the big thing isn’t it? You know, you can’t just take a design, show it to people and say: “What do you think?”

Mark: No, just go: “Here you go” No, which we did early on and it was a disaster.

Paul: Yeah, I can imagine.

Mark: Yeah, it was. It was like: “What do you think of this? I’ve got some ideas for the logotype.” “It’s rubbish!” You know, hundreds of comments.

Marcus: And they all start arguing with each other, no doubt?

Mark: Yeah, and it was… so, you have to put something in place to ask for specific feedback; that’s where we got to. So, it was, if you’re posting up an iteration which involved heave change to the masthead design, we’d steer it like: “What are your thoughts on the navigation? You know, do you think this works, do you think that works?” And wherever possible, we’d validate our design direction with testing and research anyway.

Paul: OK.

Mark: But, recently we’ve been starting doing videos.

Paul: Right. Which is quicker, I’m guessing.

Mark: Kind of, a little, er… yeah, it is. It’s been good.

Paul: I guess, I mean, the videos, did you, so you’re talking over the top of the videos and…

Mark: No, no. I mean, it’s literally we’d… so, I’d come up to London and I’d work with Leisa in the British Museum, or whatever, and after a morning, we’d have a Flip and I’d just video the two of us talking about stuff.

Paul: See, I think that’s really good, because it makes people think twice before criticising, because there are real people behind them.

Mark: They see you as a real person. Absolutely.

Paul: So, there’s probably a benefit to that.

Mark: I think there is, I think… a lot of people hated it. And a lot of people hate the…

Paul: Yeah, but a lot of people hate everything.

Mark: Yeah [All laugh] A lot of people hated the distributed approach because they couldn’t keep track of everything, but i’s not…

Paul: Which I can kind of understand.

Mark: It’s not really their job to keep track of it, they can if they want, they know where everything is and, sorry if it’s difficult, but that’s the way it is. So, this time around we set up a bunch of Yahoo pipes, and things like that to aggregate everything from all over the place and just pop it in a WordPress blog.

Paul: Right.

Mark: That’s the approach that we’re doing for redesigning the back-end, and that’s working pretty well, because people have a framework in which to feedback, they’re not going hunting for everything all over the place.

Paul: I’m guessing that people are even more opinionated about the back-end than the front-end?

Mark: Oh, massively! A lot of people don’t really care about the drupal.org website, I mean it’s looked terrible for years and it’s not done them any harm, so a lot of people are saying like: “Well, why bother?” But Drupal’s almost, kind of, on a tipping point, I think; there’s a lot of big commercial companies using it and it’s important, but the back-end is been developed by developers for developers.

Paul: Ooh, painful.

Mark: Yeah, so to go in there and say that the user experience is broken, which is what we have said, has been interesting.

Paul: Right.

Marcus: Because they know it backwards, I guess.

Mark: Well, they know it backwards and they’re comfortable with it. THe thing with the Drupal, as a system is that you download it and you install it and then you hit this brick wall really hard and then you have to spend six months of a pretty steep learning curve to even get a rudimentary site online. And that’s, we’re trying to flatten the curve. But a lot of developers don’t really understand the need for it.

Paul: That’s developers for you!

Mark: That’s fine. [All laugh] I’m fine with that.

Paul: So, I mean, this is quite an unusual approach that you’ve taken here and it makes a lot of sense because, you know, Open Source software, it has to be an open and collaborative process and all the rest of it. Do you, would you ever do this again and if so, would you only do it with Open Source stuff, or do you think there’s a value in doing it with non-Open Source stuff?

Mark: I think there’s a value doing this with communities, where communities have a vested interest, either financially or with time spent in the community to take that community on board and redesign it for them; I think it’s pretty disrespectful. So, I think it would work for communities, you know, the social side of the web is ever increasing and I think this approach would work for the majority of that, but it takes a certain type of thick-skinned designer to take it on the chin, because it goes completely contrary to the way that designers are schooled and the way that we practice our craft every day, is that we’re the problem solvers with the years of experience and we’re the experts and here’s our solution, it doesn’t work in this sense.

Marcus: Can I ask a sales-y question?

Mark: Yeah.

Marcus: Because I don’t know how you won this work. Was that the differentiation that gave you the… this is what we’re proposing to do?

Mark: Er, yeah, I believe so, yeah. It was the kind of the loose, almost by the seat of our pants agile approach and the fact that we were not ingrained in a process and we were quite happy and willing to break it apart and completely.

Marcus: Because it’s going to take a long time, isn’t, and most clients want it, you know, can you do it in a week?

Mark: Oh yeah, the drupal.org redesign isn’t due to go live for another few months and our involvement was four months.

Marcus: Sure.

Paul: Right.

Mark: So, yeah, it takes a long time, it’s a lot of effort but, from a sales point of view, we’ve now taken on more of a, so we use to work pretty strict waterfall, like a lot of agencies did, and now we don’t, we work, I wouldn’t say we were agile because agile can be as restrictive as waterfall, just a different name. But we work a very iterative design process now and are finding that our clients are loving it because they’re getting involved right away, there’s no time wasting on functional specifications and weeks and weeks and weeks of scoping; it’s getting in and solving the problem, and from a financial and a business point of view, it’s a very scalable model, so you have x number of days at a certain price on a sprint and you can expand and contract that process according to scope and budget. It does require quite a leap of faith by the client, to say: “what, you mean you’re not giving me a fixed price?”

Paul: Yeah, that’s the hard sell.

Mark: I’m like: “No” And that is hard but I’ve found that a lot of clients you sit down and you talk them through it; they can see the advantages.

Paul: Because we’re not at that point, are we?

Marcus: Er, not with new clients. Old, you know, existing clients will accept it because they trust you, but it’s always this… I mean, I don’t know, would I… say, if I owned a business and I was going to hire someone I didn’t know, even if I could see that they’d done a lot of good work etc. etc. it would be like: “Ooh, I don’t know if I could do that” You know.

Paul: Difficult.

Mark: So, a lot, so, in those instances and there have been a few, then phasing comes into it, you know and let’s see how a few sprints go and if you like how it’s going at this price, let’s expand it out and…

Paul: Yeah.

Marcus: Interesting stuff.

Mark: So, yeah, it’s interesting.

Paul: So, you like to do things different, don’t you [all laugh] you know.

Mark: Wherever possible.

Paul: Yeah, and talking of which, you’ve just given an interesting talk about web typography that’s got a bit of a different slant on the whole subject of web typography. Talk us through a little bit, you know, give us a potted version of your talk.

Mark: A potted version is 20-25 minutes. So, this week there’s been a lot of discussion online, based on Comic Sans.

Paul: Right.

Marcus: Right.

Mark: Comic Sans is evil, apparently.

Paul: Yes.

Mark: I don’t think it is evil.

Paul: OK.

Mark: I think it’s the victim of being used in the wrong context for years and years. And I think that, so there’s also been a lot of talk about font embedding, you know people are crying out for it, it’s why sIFR exists, and all of that. The technicalities of how it’s going to work with browsers and manufacturers and the font foundries aside, is it actually a good idea?

Paul: OK. [all laugh]

Mark: And I mean that from the point that the majority, the vast majority of typefaces have been designed for a particular reason and they are primarily designed for print usage first and screen usage doesn’t get a look in beyond the preview of the screen font. Now, Georgia and Verdana and a bunch of the Microsoft ‘c’ fonts have been designed the other way around. They’ve been designed for screen first and print second. Now, we’re constrained by those typefaces and that’s actually a good thing.

Paul: Because it makes sure you’re using typefaces designed for the purpose.

Mark: It makes sure you’re using the right tool for the job. Font embeddign could be opening the floodgates to a whole world of pain, I think, in terms of type, and it’s not the designers that will be at fault, it will be, you know, the people who are going to suffer are the users of the sites.

Paul: So, is there a… I mean, surely that shouldn’t preclude font embedding, but perhaps there is an opportunity here, I don’t know, to limit font embedding to fonts that are enabled for the web, and open up a whole new business.

Mark: Could be, exactly, could be. I haven’t really thought beyond my twitchiness of this being a good idea. I haven’t really, I would like to think: “I don’t think this is good” but, I think the crux of my point is moving beyond font embedding, is to actually, the reason why fonts in other tools, which has led to the usage of Comic Sans is because the tools that people can use don’t allow them to make good design decisions.

Paul: Right. While some constraints do.

Mark: So, with some constraints and some steering, can help, so why not as designers, why don’t we get our heads together and think about how we can, kind of, scaffold that experience for people. How can we make, because every one’s a designer now.

Paul: Yes, for better or worse.

Marcus: Even me.

Paul: Yes, Anna wants to talk to you about your design for your band website, we won’t dwell on that now, in the middle of an interview.

Mark: Everybody’s a designer and everybody’s, you know, someone who uses Comic Sans because they think it’s fun and quirky is right in doing so, but what they’re not considering is their audience, and the context that it’s used and all of that. So, that’s pretty much the, my talk in 3 minutes.

Paul: The crux of the argument. I mean you did in your talk go on and discuss the role of typography more generally, which I thought was quite interesting as well, share a few of your thoughts about that.

Mark: About how I see typography as a craft and that kind of thing?

Paul: Yeah, and how it fits into the whole process and the relationship between design and content and that kind of thing.

Mark: So, it was split down into 4 really. This talk was quite good, it was quite therapeutic, in a way, because it made me really answer a lot of tough, ask a lot of tough questions of myself as to what do I think typography is, on the web, to me, what is it personally. With that is type as kind of structure, which, you know, is a lot of information architecture, really, that to me that is typography; it is type as language, how typography is married with content and how the, we’re in a world on the web where designers are designing systems for content to go into.

Paul: Yeah, template-based design.

Mark: Exactly, and they’re divorced from the content, you know, divorced from the language, in that sense, typography’s quite hard to do, good typography anyway; then there was, what else was there? Type as process, so the Jesse James Garrett’s levels of user experience, with the idea that typography in that instance is relegated to the surface plane, which is the visual plane, you know, it’s: “make this look nice” typography; to me that isn’t typography.

Paul: So, what is typography?

Mark: Typography goes deeper, typography goes deeper than how something looks, it is how information is structured, it is how information in understood, it is how words and language is conveyed.

Paul: Can you give some examples of that, because that’s quite, you know, it sounds very good, but it’s quite hard to get your head around maybe.

Mark: Yeah, OK, so it’s, what’s that quote: “You cannot not communicate”

Paul: Right.

Mark: No matter what you do, you’re saying something to somebody, so your choice of typeface says something about the words that you’re writing.

Paul: Yes, it does.

Mark: If, as a designer, you don’t know what those words are, how can you communicate the message?

Paul: Yeah, I mean it goes back to Comic Sans.

Mark: To Comic Sans, exactly, and that’s one of the difficulties, there’s been a lot of talk about art direction on the web, and I see that as the biggest barrier to art direction is that designers are divorced from the content.

Paul: I mean, this is almost quite depressing.

Mark: Yes, really I…

Paul: It’s not really happening.

Mark: Sleepless nights!

Paul: It’s not happy idea, because, I mean, fundamentally, that isn’t going to change, we’re not going to get into a situation, you know, because rightly want to be able to change and update and alter content on their own website and that makes a lot of sense, which means even if you have the content up-front, it may change further down the line. I guess maybe the tone doesn’t.

Marcus: I was going to say you’re looking at tone here.

Mark: The tone, you’re looking at branding and you’re looking at designers being involved right at the offset.

Marcus: And I think that is better now than it was even two years ago.

Mark: Oh, it is, yeah, it is, yeah, absolutely.

Marcus: I mean, we are looking now at involving copywriters, we are pulling copywriters, we’re talking to our clients about employing copywriters through us, that’s new.

Paul: And from the start of the process as well.

Mark: Yes, right. So, we’re doing the same, we’re looking at employing content strategists rather than actually writers, more from a branding perspective, because that kind of stuff, you know, doesn’t really change, depending on the words that you, the values of the client are still communicated and it’s aligning, it’s the designer’s job to align the typography, not just the font, but the way the information is structured and working with a copywriter to make sure the typeface matches the tone of voice. and all of that is a package. So, that’s what I mean about the surface plane; typography shouldn’t be relegated to: “choose a typeface and away you go”

Marcus: Yeah, I mean, that’s the big thing isn’t it, that’s for me, what I’ve taken from this is your, is the font, the typeface has to match the message, basically.

Mark: Yeah, absolutely.

Marcus: It has to fit with the branding.

Paul: OK, good stuff. I mean, that’s yeah, you’re doing some really interesting stuff. I love the way you’re pushing, kind of, what is the conceived wisdom in lots of areas, which I don’t suppose you think you’re doing, you just stumble into these things, obviously.

Mark: Yeah, I did. Getting together this talk was one thing, this talk did not pan out the way I thought it would and to question the very notion of font embedding is quite a…

Paul: Because our whole culture really is built around the idea of choice, more choice is better, but actually that’s not always the case.

Mark: Yep, so I mentioned that in my talk.

Paul: Oh, did you?

Mark: About the jam stall, have you seen this?

Paul: Yeah, yeah. That classic, tell that story, that’s a good one.

Mark: So, there’s a couple of psychologists, a few years ago did a study where they had a jam stall and they had 26 varieties of jam and nobody bought any and then they reduced the jam varieties down to six and sales increased by 10 and it’s just the choice.

Paul: You could almost be overwhelmed.

Mark: Well, yeah.

Paul: Even as a designer you can, you can open up Photoshop, look down that font list and go “crap!”

Mark: So, this is where I showed a screengrab of TinyMCE and that, out of the bag, has 82 choices for a user, so WYSIWYG isn’t great in those terms, but there’s something within there which is, as designers and the design community could build on, which is this notion of styles and how you can use the styles to create a cascade, through your typography, through your design, so we’d limit the end-user’s choices, but not in a bad way, constraints are good.

Paul: No, I mean, the way we now work, because we use our own content management system with our own adapted WYSIWYG editor it, we’ve taken a third party’s and messed it around, that basically we only allow, by default, obviosuly sometimes clients disagree, but we only allow them to mark up the content semantically, so they’re not at any stage picking fonts, because that’s the designer’s job, they’re just describing what the content is, whether it’s a heading or a sub-heading or whatever else, which, you know, obviously, you know, ensures that design style goes through, but also makes it much easier to use for the user as well, they’re not having, you know, a plethora of options and buttons to deal with, so…

Mark: But it goes beyond the web, I think, and this is what I was thinking as I was going through this, the reason why Comic Sans is all over the place is because Word makes it easy for you to make those bad design decisions, so it goes beyond that and content management systems in 10-20 year’s time could look nothing like what we’ve got now and if we don’t think very carefully about this notion of choice, then we could be in a real mess.

Paul: Yeah. Well, certainly we’ll be in a real mess anyway.

Mark: But, you know, a lot of people would push back on that and say: “What’s your problem? That’s fine. Mess is fine.” I don’t agree.

Paul: A little bit of mess is alright. No, I see where you’re coming from and, you know, I think there is a lot of value in that. I think I would personally still like to see font embedding, but I wouldn’t object to that being limited. I mean, one of the big problems to font embedding, as I understand it, and I’m not as knowledgeable on it as you, but is a licensing problem. So, if we have a new generation, I just look at the font industry, you know, the people that produce fonts and go: “Look, you’re missing a trick here, you know, you could create a whole new range of fonts, designed for screen, licensed for the web, and there we go.” So, if that’s what we end up with, I mean, that’s great.

Mark: That would be great, you know, if we got the calibre of typefaces like the new Microsoft ‘c’ fonts, and we got, you know, a library of 40 of those to use, 50, that would be awesome. If we ended up with a way of embedding up to, you know, Bitstream’s library’s what 28000 fonts, you can choose what you like, I don’t see that as…

Paul: Not so good.

Mark: Not a good thing.

Paul: I mean, even as somebody, I mean, I went to art college and, you know, obviously I had to study typography as part of that, I still feel overwhelmed. When I, I know some people absolutely love, you know, going to some of these foundries with all these different fonts and they spend hours picking through and it’s like buying shoes for, no I won’t say women because that will be sexist but, you know it’s almost like an addiction. For me, it just overwhelms me.

Mark: Yeah, no, I’m the same, I’m never, and this is one of the great things about the web is the restrictions in the typeface you can use because it makes you think more about typography beyond the font choice.

Paul: Yeah, which is only a tiny part of typography.

Mark: Exactly, and it makes you really push typography, and people are still pushing Georgia and Verdana and there’re still pushing it and they’re still making great looking sites. Font embedding can only confuse all that, unless it’s done in a pretty structured way, but like you say, the licensing is one big hurdle to get over.

Paul: Well, that was probably the most eclectic interview we’ve ever done, covering lot’s of random subjects,but very good, thank you for coming on the show, Mark.

Mark: No, thank you very much for having me.

Thanks goes to Simon Douglas for transcribing this interview.

Listeners feedback

Storytelling

Mark from Taunton writes:

I run a rather dull corporate website for a company who builds and sells pre-fabricated timber houses. It is a competitive market and although a lot of users visit hardly anybody contacts us for a quote. To be honest, I have lost any enthusiasm for the site. Can you help!?

I could answer this question by focusing on the importance of repeat traffic on conversion rates. We could look at generating repeat traffic through the use of articles, newsletters and offers. However, we have covered nurturing repeat traffic before. Instead I want to look at the power of story telling as a way to engage with users.

Users considering purchasing high value products and services have a number of generic questions…

Can I work with these people?
Are they experts at what they produce?
Can I trust them?
Is the product or service of sufficient quality?

In short any corporate website that sells a product or service should be about the product and the people. One way of focusing on these two things is to tell the story of the product/service. In Mark’s case this would progress through the process of designing, manufacturing and building a pre-fabricated timber house. At each stage you would introduce key people involved in the process – the account manager who deals with the customer, the architect, the project manager, the builder etc. The story could even be the experience of one particular customer and so end with a testimonial from that customer. These people could be interviewed on video or profiled in the copy. Either way it gives the user the chance to see the expertise and personalities behind the business. It builds trust and demonstrates the quality of your product and people.

Finally, the story based approach helps the user imagine themselves going through the process and therefore helps them picture working with your organization.

Getting into the zone

Paul wrote a question aimed at Elliott Jay Stocks in our forum that I would like to respond to as well. Paul wrote…

As a designer, I feel times when I am very creative, others when I know an hour infront of Photoshop will be useless. So, fellow designers how do you make yourself get into the zone. I imagine this is even harder for freelancers, or maybe easier actually, as you can pick and choose hours to work.

Like most people I find it very hard to artificially force myself to be ‘in the zone’. However, I have learn’t over the years that there are some things you can do that increase the chance of it happening. These are…

Change your environment – If inspiration is hard to come by I often find that a change of scenery can be a massive stimulus. Go and work in a different room, a local coffee shop or even in the middle of a field. Anything to kick start your creative juices. In my younger days I was even known to work under my desk or on top of a wardrobe.
Use a different approach – Another similar approach to changing your environment is to change the way you are tackling the task. If you are trying to design a site in Photoshop move to pen and paper. Try designing just in black and white or reduce your design to simple boxes. Often approaching a problem from a different angle sparks inspiration.
Create distractions - Everybody always advices that you remove distractions to ‘get into the zone’. However, personally I find this leaves me staring at a blank page until my eyes bleed. An opposite approach that has worked for me is to actually add distraction. For example I will set an alarm for 10 minutes. After that 10 minutes I force myself to take a 2 minute break. These short spurts of creativity seem to work for me and the breaks are a frustration that make me hungry to get back to work.
Take a break – Proper breaks are important too. Sometimes you need to walk away from a problem before the solution comes to you. It has taken me a long time to accept that some of my best work on a problem is done when I am not consciously thinking about it. If I get stuck I find that watching some TV or going for a walk is a very effective way of putting me ‘in the zone’ when I return.
Go with the flow – Finally, it is important that when inspiration strikes you run with it until it has been drained dried. Even if you find yourself in the zone at the end of the business day, do not stop working. Cancel meetings if you need to but make sure you keep going. This is the time when you need to remove distractions and just go with the flow.

161. In or Out

Posted in Classic shows on April 14, 2009 by Paul Boag

On this week’s show: Paul announces Micro-Boagworld, we discuss the pros and cons of outsourcing web work and see what recommendation the Boagworld forum has to offer.

Podcast: Download (20.2MB)

Download this show.

Launch our podcast player

Housekeeping

For a while I have been toying with the idea of doing a Micro-podcast that works in a similar way to Twitter but with audio. It would provide the opportunity to share hits, tricks and reviews too short for the main show. My problem was that I needed an application which made this as easy as posting a tweet. Anything more and it would prove too demanding.

Fortunately a new iPhone application has launched that does exactly that. Called AudioBoo it allows you to record 3 minute audio snippets that then get posted to a website, twitter, facebook and a podcast feed.

I am therefore pleased to announce Micro-Boagworld…

View Micro-Boagworld posts here

Subscribe to the RSS feed here

News

Pricing and projects

Alyssa Gregory has written two good posts this week both relating to the pricing of web projects.

The first post tackles the notoriously difficult subject of How To Estimate Time For A Project. After all, time is money.

Estimating how long a project will take is tricky and although this post doesn’t provide any magic formulas it does provide good solid advice.

As well as considering the obvious deliverables Alyssa also recommends time for project management, reviewing work, debugging and client turn around. Finally, she recommends adding a buffer for the unexpected.

Of course, she doesn’t discuss how all of this time translates into your final price. How much you charge is a matter of conjecture. However, in a second post she does explore a related subject – How To Raise Your Rates.

In this post, she handles the sensitive subject of how to tell a client that you will be raising your rates for future projects. She suggests five techniques you should employ…

Give Notice
Set a schedule (make increases annual for example)
Make it fair (keep the increments small and manageable by the client)
Send it in writing
Balance it out (Balance your increase with an incentive – e.g. a special, a one-time discount)

Its all good advice and important too. As your skills and experience increase, you will need to ensure your rates reflect that. Knowing how to hand those rate increases is vital if you want to keep your clients happy.

IE8 and IE6

Microsoft have announced that IE8 will be released via the Windows Automatic Update starting on the third week of April.

The final version of the browser has been available since March and yet adoption has been sluggish. Hopefully Automatic update will change this trend significantly. However, it does not guarantee universal adoption. Although the update will be marked as important users will not be forced to upgrade. In fact Microsoft has released a blocker toolkit so corporate users can avoid the update entirely.

Worst of all, it is likely that the update will impact the numbers using IE7 more than IE6. IE6 users tend to be hold outs and are unlikely to upgrade now when they did not upgrade to IE7.

The only hope is that many IT departments have a policy of running a version behind the current release. If that is the case, the arrival of IE8 may encourage some of them to adopt IE7.

The entire web design community is keen to reduce its level of support for IE6 and hopefully this update will allow that. In fact, another post this week entitled – 10 Cool Things We’ll Be Able To Do Once IE6 Is Dead – points out just what a wonderful world it would be.

Once IE6 is gone we will be able to…

Use child selectors
Make full use of 24-bit PNGs
Use attribute selectors
Use a wider range of display properties
Use min-width and max-width
Throw away 90% of CSS hacks (and 90% of the reasons for needing them!)
Add abbreviations that everyone can see
Trust z-index again
Save time and money
Enjoy ourselves again!

Simple and impressive design techniques

Last week I was doing a consultancy clinic with a developer who wanted advice on designing his website. He was a great coder but did not have much experience designing.

Although I recommended The Principles of Beautiful Web Design by Jason Beaird it would have been great to point him at the latest Smashing Magazine post – 10 Simple and Impressive Design Techniques.

This post has some easy to implement techniques that are ideal for developers trying to improve their design skills. Techniques include…

Adding Contrast
Using Gradients
A Better Use of Colour
Improved Letter Spacing
Changing Case
Use of Anti-Aliasing
Adding Imperfections
Implementing blurring
Careful Alignment
Trimming the Fat

Read the whole articles for more details and great examples of these techniques in action.

Influencing user behaviour

A big part of good design is guiding the user to complete the actions you want. Influencing user behaviour can be achieved through a variety of techniques. However, it can often be hard to know where to begin.

One resource that might help you influence user behaviour is The Design with Intent Toolkit. This is essentially a printable ‘cheat sheet’ that suggests a variety of techniques you can apply to your projects.

The techniques do not just apply to web design but all aspects of design. Consequently not all of the techniques will apply. However a lot do, ranging from the use of metaphors to setting up good default options.

Some of the techniques contained in this cheat sheet are also beautifully demonstrated in another post I wanted to mention. Entitled 12 Excellent Examples of "Lazy Registration" it addresses the problem of user signup.

Essentially it is a post that showcases methods for getting around the problem of user registration. As the post itself says…

Signup forms have long irked the casual visitor. During the process of discovery, nobody wants to stop and fill out details before they can "unlock" the rest of the site’s potential.

It has certainly been my experience that signup forms are a barrier and so it is interesting to see how different web applications have overcome the problem.

Feature: When to outsource web work

Your in charge of your organisations website. It has become moderately successful and now you have a decision. Do you hire a full time web designer or outsource to a web design agency?

Read the full article

Listeners feedback:

In this week’s listener feedback section we look at a series of recommendations from the Boagworld forum…

A good introduction to Javascript

Jake writes: I’m curious as to whether or not anyone on the forum has strong opinions on a good introductory javascript book? And by introductory I mean something that’s more about initial learning steps such as syntax, etc. and then talks about best practices.

Doug answers: You might want to look at one of the books out for coding in jQuery, if you’re planning on going in that direction anyway. As for how to learn javascript I usually push people towards Lynda.com.

Matt also replies: Awesome book – DOM Scripting – I’d start with this before jQuery as I think you need some javascript knowledge to use jQuery to its fullest.

A good but free survey tool

Simon asks: I want to create some simple(ish) survey’s to get clients to fill out after a training session. I know of some paid for solutions, but does anyone have any suggestions for any free tools?

Laura replies: For something short, I’d use the survey function on PollDaddy. You can get up to 100 responses, and I think ten questions. Ten isn’t many, but you can do conditional branching for free, which is rare, and good.

I’ve also used SurveyMonkey before, it’s clean and simple.

A review of Clicktales

Peter shares his experiences of Clicktales…

On the recommendation of Paul, I tired out ClickTales.com; and I have to say the results have been interesting (sad, in my personal case) to say the least.

For those of you not in "the know", or missed episode 141, ClickTales is an app that lets you record and review the actions of your website’s visitors. And I’d agree with Paul: inexpensive, revealing, but limited in essence because you can witness what a user goes through.

In my case it was most effective because my results have been telling me that I should redesign my website’s structure completely… so I decided I should start from scratch all together and redesign. :)

Web Design for ROI

Bill reviews Web Design for ROI by Lance Loveday & Sandra Niehaus…

Each year I find one or two books that really stand out. This book, Web Design for ROI, changed the way I look at current eCommerce projects and helped me identify better strategies for building web sites.

Rich adds: I agree this is an excellent book.

Not too much new for a seasoned pro like myself, but I did still learn a fair bit and I’d recommend it to anyone with an interest in websites that make money.

Pro Paypal e-commerce

Finally, Ian shares an extensive review of the book ‘Pro Paypal e-commerce‘. Ian writes a very thorough review but here are a couple of highlights.

I thought this was a great read. It’s not often you finish a book and feel confident you have all the information you’re going to need to complete your project. The book isn’t just technical but also has lots of useful nuggets on business practices and background on payment systems in general for those that are unfamiliar with them at this level.

I feel confident in recommending this book to anyone who is involved with developing E-commerce systems or is going to be in the future. The author Damon Williams has a very readable style that is mercifully faux-humour free but never dull and explains everything clearly and concisely and despite its relatively low page count at 260 pages or so, still manages to cover a lot of ground without ever feeling as if it’s being too terse.

For more reviews about everything from web design books to software visit the Boagworld forum. We are also going to do some cool new stuff on the forum over the coming weeks. Keep an eye on it. We have already added a Jobs category for those of you who are looking to hire a web designer, so be sure to check that out.

160. Education, Education, Education

Posted in Classic shows on April 8, 2009 by Paul Boag

On this week’s show: We speak to Aarron Walter about teaching web standards. Ryan Carson starts a series on web applications and Paul talks about remote user testing.

Podcast: Download (30.2MB)

Download this show.

Launch our podcast player

Housekeeping

A couple of quick pieces of housekeeping to kick off with…

Huge thanks to Ryan Taylor, Paul Stanton and Sarah Parmenter who did a stellar job standing in for myself and Marcus on last week’s show. They were actually far too good and I have already started receiving requests that they become the permanent hosts! Anyway, if you didn’t hear last week’s show then make a point of downloading it.
My second piece of housekeeping is a quick plug for Bamboo Juice, a grass roots conference taking place in Cornwall on the 24th April. Myself and Jeremy Keith are just two of the speakers in what will be a packed day. It’s so good to see smaller conferences like this springing up outside of London and so I would encourage as many of you as possible to attend. Best of all its only £99 (£79 for Boagworld listeners!)

News

To be honest, what with SXSW and my week’s holiday I am feeling completely out of touch with the web design world. Fortunately, Mr Stanton is continually updating our twitter feed with juicy stories. I have therefore picked 4 that caught my eye.

How to create a great web design CV

Poor old Smashing Magazine. People do like to tease them (myself included), but they write some damn useful articles. A recent example that caught my eye was ‘How To Create A Great Web Design CV and Resume?‘.

This post is essentially two articles in one. It starts by asking 10 designers to design a hypothetical CV for a fictional individual. Each designer writes a short paragraph about their chosen approach and you get to look at some nice examples.

The second part of the post provides 10 useful tips for creating a great CV. Suggestions include…

Make it printable
Have a summary
Link to online projects
Show your personality
Keep it simple and understandable

For the complete list of tips read the whole post.

Its a good post, but I am not sure whether producing a ‘designed CV’ is entirely necessary for web designers. If I was hiring a print designer then I would expect a CV to look impressive. However, if I am recruiting a web designer I think I would be just as happy receiving a cleanly designed CV that links to a stunning portfolio website.

There are a lot of differences between designing for the web and print. It is possible to be good at one and not the other. Therefore, a printed CV doesn’t tell me much about a persons capability as a web designer. That said, a well designed CV isn’t going to hurt your cause!

Design: Make it Memorable

One tip that could have gone in the Smashing Magazine article, is to make your CV ‘memorable’ and not just ‘flashy’. This picks up on the theme of a post over at 37 Signals entitled Designers: Make it Memorable.

The post talks about the difference between making something visually appealing and actually memorable. Too many sites are impressive but fail to leave a lasting impression. At one point in the post the author writes…

I started to recall those amazing Flash Sites of the Day. You know those sites that get passed around via IM in your office on a slow day? Simply amazing design and programming. Problem is: I can’t for the life of me remember what those URLs were much less the company/product that was being featured! Isn’t that the point with those sites? That the impact should be profound so that you remember Product or Company X?

This is a lesson that all those involved in the web design process need to learn. Whether we are designers or website owners, we have a tendency towards thing that provide the wow factor. However, often it is the thing that makes us go wow we remember rather than the message being communicated.

Statistics and website owners

Our next article of the week is an ‘all too brief’ post on web stats entitled How to Sell Statistics to Clients.

The post focuses on a common problem – most website owners know they should be tracking website statistics, but don’t really know what they are looking for. In fact the author writes…

In my experience, the loudness or frequency of a person’s request for web statistics is inversely proportional to their understanding of them.

That has often been my experience too.

He goes on to identify three ways that we as web designers can help rectify this problem. These are:

Providing cheat sheets that help the client understand terms like ‘hits’ ‘page views’ and ‘unique users’.
Add web metrics training into the budget of your projects.
Provide summaries and reports for the client on key metrics such as conversion rates or sales.

To be honest this is a much bigger problem than can be covered in a short blog post. Too many website owners think that having Google Analytics will solve their statistics needs. However, having the data is not the same as understanding it. If this information is misread it can lead to bad decisions about the future development of a site.

Specialist vs. Generalist: Who Wins?

The final post this week is of interest to pretty much everybody who listens to this show. It asks which is better – the Specialist or the Generalist.

This is an important questions for both web designers and website owners. As web designers we need to know whether we should be specialising in a specific area of web design. It is important for our careers and our businesses.

As website owners we want to know whether the pain of dealing with multiple specialist suppliers is worth the increased expertise you would receive over a generalist.

It has to be said the article is written mainly from the web designers perspective. However, I think there are lessons to be learnt for all sides.

The post outlines the pros and cons of both approaches, but ultimately comes down on the fence when it says…

There are advantages to being in both groups, but I think the only way to be truly successful is by being a little of both. You can be a specialist, but in order to be able to develop a profitable business, you may need to be able to supplement your specialty services with some add-on services that may not be exactly in line with your focus.

Personally, I think it depends on how you define specialist. The type and level of specialisation can vary massively and the way you position yourself will define your success. For example, you may specialise in a certain discipline (e.g. Ruby on Rails development) or in a specific market (Higher Education).

Ultimately, whether you are a website owner seeking an agency or a web designer forging a career, it is all about balance.

As a web designer, if you specialise too much you will not find work. If you generalise you cannot differentiate yourself.

As a website owner you want a web designer who is enough of an expert to deliver an outstanding solution, but you do not want so many specialists that your project turns into a nightmare.

Interview: Aarron Walter on Interact

Paul: Hello, and so joining me today is Aarron Walter. Good to have you on the show, Aarron.

Aarron: Thanks for having me.

Paul: And the reason we have Aarron on the show is because he is going to talk about a new initiative.. is ‘initiative’ the right word, Aarron?

Aarron: Yeah, yeah.

Paul: Let’s go with that. A new initiative from the web standards project, called Interact. Now, let’s kick off, Aarron, by maybe you telling our listeners a little bit about what Interact is.

Aarron: So, whilst Interact is an open curriculum framework, basically we’ve been recognising that the Web Standards Project has been around for a long time and we’ve done a lot of things to try to get standards into industry. And to a certain degree we’ve made some big triumphs in that respect, but there are still a lot of websites out there that aren’t following standards and people that are sort of behind. And we saw the Achilles heal as to why that’s not happening, as really, education. So, you know, our medium’s really young and it hasn’t really found it’s bearings with how we’re going to marry industry and education, so whilst Interact is a curriculum that has a series of courses that teach not only web standards, but best practices.

So there’s of course the stuff that you would expect from WaSP which is the front-end development courses that teach progressive enhancement and semantic markup and that sort of thing. But we have six learning tracks that include foundations; there’s a course in there that’s like an intro to internet concepts and how people can use the internet to teach themselves and use RSS, that sort of thing.

So there’s front end development, there’s a design track, there’s server side development, there’s user science and then there’s also professional practice. So what we’re trying to do is create a collection of courses that are very modular, to try to get these into schools. And we recognise that not every school is just going to take the entire curriculum and integrate that into their program. You know, if you’re a Computer Science program maybe you’ll take a course or two, if you’re a design program you’ll take a course or two, or even just grab the assignments or look at our competencies.

Each course is based on competencies, which are the things a student has to master before they can pass a course. And then the evaluation methods: So each course has assignments, it has exam questions, it has readings that come from Operas own web standards curriculum – we’ve been collaborating with them. It has textbooks, it has pretty much everything that an educator could need to teach a particular topic.

Paul: Okay, so is this something that is then aimed entirely at educators, or if somebody wanted to get into web design and they were trying to learn it in their spare time, could they just go to this and use it in isolation by themselves?

Aarron: To some degree, I guess they could, but Operas web standards curriculum is really learner-centric, so if you’re trying to teach yourself, that’s probably the place to go. But ours is very much focused on educators, because we feel like there’s a lot of great resources out there on the web if someone wants to teach themselves, but there’s not a lot of great stuff for educators to get stuff into their courses.

Paul: So, when you say ‘educators’, I mean what kind of level are we looking at here? Earlier you mentioned schools. Are we talking about school age, or are we talking about higher education? What are we covering here?

Aarron: I’d say our primary target is higher education, colleges, universities, even training programs to some degree. But we are also seeing some of our content in high schools as well and we’d like to see that more. Especially foundations courses like the web design one course or the internet fundamentals course. If students could go into college with a solid foundation, then they can start to focus more on "What can I do with these techniques?" than theory and concept.

Paul: So is this design to be fairly international or is it quite U.S centric in the way that it’s written.

Aarron: We want it to be very international and the people that have worked together on this are from lots of different places. We’ve got some folks in Europe, Canada and of course some folks in the U.S, so it is in an international group that’s coming together and we’re actually working with WaSPs ILG group – that’s the International Liaison Group. And we’re working on, this year one of our big goals is to try to get a lot of our content translated to different languages.

Paul: Okay, so there will be multiple language versions of all of this as well at some point?

Aarron: That’s the direction we’re heading, yes.

Paul: So, I mean, how did this come about in the sense of, you know, well, how did you get involved in it for a start and what was the motivation behind it?

Aarron: So, I’ve been teaching for the past ten years in different schools in the U.S and colleges and universities, but I’ve also been working in the industry as well. And I got on WaSPs mailing list, I just joined the mailing list and started to talk to some folks and then they invited me to join – it was a year ago, I guess it was at the very beginning of 2008 – and so I joined the education task force who created the Interact project. And basically there were ideas about the curriculum and I’d heard lots of people say "Yeah, what we really need is, you know, education’s way behind" and they’re happy to point fingers and "We need a curriculum", but it just never was really transpiring from anyone coming from the industry and so we kind of just decided we need to do this. And I’ve helped create curricula before as a faculty member at the Art Institute of Atlanta and so I had some ideas and we had a really great group of folks that are in the education task force – people that are educators and people that are experts from the industries. So, yeah.. actually South by South West was where this all started, which is pretty amazing, of course there are lots of great people there. So Glenda Sims, who’s one of the heads of WaSP these days introduced me to Chris Mills from Opera who was working on his project and we kind of had some drinks at the Geeks Club bowling event and we just kind of went crazy talking about these ideas. And Steph Troeth then Leslie Jensen-Inman and we all had these ideas, and then we just set a goal for ourselves in 2008 at South by South West and we said "In a years time, we’re gonna be back and we’re gonna have a curriculum." and that’s what we did. This year we launched our curriculum at South By.

Paul: That’s quite an impressive turnaround for the amount of information that’s in there. How did you draw everything together? Where did it all come from?

Aarron: Well, we met every week online and we talked and we established a course template, which really helped us. The stuff that we really needed to put in these foundation courses, we all know what needs to go in there. It’s just a matter of getting around the pedagogy or the educational part of it. So we developed a template for assignments, a template for a course and a template for learning modules which are basically like, you know, a teacher could teach a concept like let’s say, HTML forms in a weeks time. So we developed those templates and then from there we just assigned courses to different people and we used a wiki and we just met regularly and.. I gotta say, you don’t have to have a huge group to develop a curriculum.You just have to have a few people who really have their heart in it and.. we have some amazing folks, so..

Paul: So, what kind of response are you getting so far from H.E institutions? Are they interested in adopting it? If they are, how are they going to go about that, because, I mean, my impression is that it always takes forever to get a curriculum approved at a university or whatever. So I’m just interested in how that process is going.

Aarron: Yeah, education is.. one of it’s benefits is that it’s slow to move, so once it gets a solid foundation it keeps that solid, but you know, one of it’s drawbacks is that it’s slow to move. And so we’ve got some schools that are really excited about it and generally the folks that.. you know, it’s only been a couple of weeks that this has been live, we’ve got some folks that are really excited about it and those are folks that were kind of headed in the same direction themselves. So we’ve gotten some responses from schools in Europe and some schools in the United States that are interested in pulling some stuff in. And we have a school that’s looking at using a lot of our content right now. So we’re in the early stages of trying to get this out there. I think the easiest part is building the curriculum, because we know what needs to go in there. The hardest part is getting it into schools. So one of our strategies is to get the endorsements of folks in the industry, so we’ve gotten endorsements from Google, from Yahoo, from Adobe, from W3C, from Opera, from Mozilla – they’re all just super excited about what we’re doing and that sort of brand recognition can help us get our foot in the door with schools. And of course going out to conferences, we’ve got folks at the European Accessibility conference right now, talking about it, so we’re just trying to get out there and let people know.

Paul: Excellent. That sounds brilliant. I mean, I know that a lot of people that listen to the Boagworld podcast – there’s a large number of students that we’ve got listening and I often get complaints about this, that what they’re being taught at university bears no resemblance to what they’re hearing on this podcast. And I’m hoping that that’s because the podcast is right and the university is wrong and not the other way around. So if they’re listening to this and they’re getting really excited about it and, you know, they’ve gone to your website and they’re seeing the curriculum – I’ve got it on front of me now and it does look really exciting – how do they make this happen in their institution? What would you encourage them to do?

Aarron: So, this is the interesting thing – that so many of us have complained about a problem, but there aren’t a lot of people that will take that complaint and turn it into action. So if you’re a student or if you’re an educator what we need you to do is, there’s a page that’s called Advocate Standards (http://interact.webstandards.org/advocate/) – you can get to it from the homepage of http://interact.webstandards.org. It kind of just describes what standards are, why they’re relevant to you and we need people to share that information with their teachers, we need people to share just this website with their colleagues and show them the testimonials of the people who believe in this and want students to come out of schools with these skills. So we need people to act in a bottom-up sort of way, you know, grass roots. Take this to your classroom, take this to your teacher, take this department chair and just let him know. That’s the most powerful thing that people can do right now.

Paul: I mean, what I’m quite excited about from looking at this curriculum is that it contains a lot more than "Here’s how you code in X language" or whatever and even has got more in it than just design and user experience stuff. All this stuff about professional practices is very exciting too. Could you perhaps tell us a little bit about that?

Aarron: Yeah, so professional practice, we want people to not only get the concrete skills of "I can code a standard compliant page" or "I can construct a usable website", but we want people to be able to present their about their work and you know, be able to survive in a real career in the web. And so professional practices is going to have a series of courses to do that. We’ve got some pretty exciting ones that are coming up. There’s ‘writing for the web’ – it’s going to be a really cool one, that Alan Hussain from a List Apart is going to be creating. And we have a presentation course that’s coming down the line. So, we’ve got a number of those coming up.

Paul: That’s quite interesting, you just said something that I hadn’t grasped which is that there’s more to come here. That this isn’t the end of the line. It sounds like you’ve got lots more that you’re still developing. Is that right?

Aarron: Yeah. We call it a living curriculum, because you never write a curriculum and then you’re done. Especially in our industry, things change so fast. is what of course we’re going to be working on this year. Our design track is light right now and we want to try and address that ASAP, so we’ve got Dan Rubin and Ethan Marcott, are working together to create a foundation design course, that is specific to what web designers need to understand. And we also have Dan Mall is going to be helping us with a Flash course and Aral Balkan is also going to help us with some flash stuff too. We have a lot of stuff going on this year for new courses, so we hope next year at South By when we see everybody that we’ll have a brand new stack to add to Interact.

Paul: Excellent, so do you kind of envisage, from an institutional point of view that, like we were saying, it takes a long time for a curriculum to get approved and that part of the problem has always been that, by the time it’s approved it’s out of date, when it comes to the web. So is the idea that you’re going to get institutions to buy into the Interact curriculum in its evolving nature so that they always get the most up to date version of it. Is that the kind of plan? They’re not grasping one moment in time from it, if that makes sense?

Aarron: Yeah, exactly and we want to take some of the hard work out of being a teacher. I speak from experience, there’s so many things you have to keep track of and trying to keep pace with a lot of changing technologies and concepts, that’s hard on top of the umpteen other plates you’re spinning. So that’s exactly what’s going to happen, is that our courses, they’re not chiseled in stone, they’re published on the web, they’re in an expression engine and we’ll change those as they need to be changed. But that said, we need to strike a balance, because we can’t be chasing every new technology all the time, we have to evaluate and there has to be foundational concepts that remain steady. Separation of presentation and content, that’s steady foundation concept. But new technologies or techniques, they might change.

Paul: Okay, I mean, the whole area of education and web design is massively exciting and there’s so much going on at the moment in so many different fields. I mean, from your perspective, what else out there is really exciting you at the moment that you’re seeing.

Aarron: There’s so much, I just feel like last year that I just saw so many companies, organisations, individuals that, it seems that everyone just was pissed and they just walked out their house and they were headed in one direction until it was like everyone sort of meets up in one big mob. And so, what Opera’s doing, what Chris Mills has done with the 55 articles that he’s brought together and edited for Opera Web Standards Curriculum, that’s huge. Those are all rolled into WaSP Interact as our recommended reading, so that was fantastic. Yahoos Juku project, if you’ve heard of this it’s quite amazing. Nick Fogler, who’s the running Juku – Yahoo actually has a training program, where they bring students that are not employees, they’re not hiring them. They bring them in and they train them to be front end engineers over the course of a few months. And they’re doing it because they’re trying to solve this problem on their own. So, we’re talking with them about how they’re solving problems and looking to collaborate and discuss what we can learn from them. John Allsopp who runs Web Directions (the conference series), he brought myself and Chris Mills and Steph Troeth together with a number of other experts and we did Ed Directions, which was a day long workshop that taught teachers how to teach these concepts in their classroom. So there’s just so much stuff that’s happening right now and that’s just the tip of the iceberg.

Paul: Exciting stuff. It sounds like it’s a really good time and it’s great to have you on the show. How you manage to fit all of this in alongside earning a living too is quite beyond me, but it’s really good that so many people are volunteering and pitching in. That’s great. Okay, let’s get you back on the show, I guess in a years time and sees what’s changed. But thank you very much for coming in now and I will talk to you again soon. Thanks.

Aarron: Thanks for having me.

Thanks goes to Andrew Marquis for transcribing this interview.

Listeners feedback:

We have two emails this week dealing with two totally unrelated subjects.

Remote user testing

Our first email is from Steve. He writes…

Catching up on past podcasts, I listened to the episode on User Testing (#150). A method I’ve used that I haven’t heard tossed around much is remote user testing using a screen sharing program like GoToMeeting.

I used this for usability testing of our Intranet and it has several advantages:

No need for people to come to central testing facility, or you to go to them.

The user is at their own computer, so more comfortable.

Ability to record the entire session (screen and audio) so others can look at it later.

Tester can conduct testing while in his underwear only (I didn’t do this, but you could.)

What do you think of this method?

Sounds interesting although it would not be my preferred approach.

It’s easy to become a snob when it comes to usability testing and so let me make it entirely clear – any usability testing is better than none.

If you have no budget for user testing, test on friends and family. If time is tight, test on a colleague sitting nearby.

In the same way, if you are having trouble arranging sessions then use Steve’s approach. Something is always better than nothing.

That said, I do have some concerns with remote testing. These include…

It sets a minimum bar of technical competency. A user has to be able to connect to the system in order to participate. I know this would have been beyond the capabilities of some test subjects I have worked with.
It is less personal. Face to face usability testing puts users much more at their ease and allows you to build a relationship that facilitates honest feedback.
It does not allow you to read non-visual signals. Users will often pull a face or shift their positions when they are frustrated. As a facilitator you need to be able to see these signals and ask what they mean.
You are not seeing exactly what the user is seeing. You can only see their screen. You cannot see other distractions such as TV in the background. You cannot see the position of their keyboard and mouse. You have a limited field of view.

My preferred approach is to test in people’s homes. Not only are the users more relaxed, you also get a unique glimpse into their world. You see where they access the web, you learn about their home environment and even gain a better understanding of their character.

However, we do not always live in a perfect world and so would definitely use remote testing if better options were not available.

Finding a job

Our second email is a rather despondent one from Andrew…

I have one question, In the past you’ve talked about hiring new for staff, but as far as I can tell you’ve never discussed how to look for a job. I’m currently looking for a career in the industry, but I can’t get a resume to any company or even talk to someone of said company. Almost all the businesses I’ve approached (or at least tried to) either work from home, are no longer at that address, or no longer in business, and actually are just freelancers. And when I find a job posting online its for someone far more experienced then I am. I’m completely demoralized.

You have my sympathy Andrew and I have to say its a tough time to to break into any new sector including web design.

I am also probably not the best person to answer this question. I have been completely unemployable for some time now due to my ill defined skillset and opinionated character :)

So, I am going to try something different with this question. If you have some advice for Andrew, post a comment below. That way we can get the Boagworld community helping each other.

In the meantime here are a few random ideas from me…

Give up on the cold calling technique. Randomly contacting agencies is largely a waste of time. You have to get amazingly lucky to contact an agency who happens to be currently recruiting.
Try for an internship. Admittedly you will not get paid, but it is a foot in the door. You get a chance to improve your skills and also get to know the people in the industry within your area.
Be willing to move. There are jobs out there but they are often further a field.
Put yourself in a neat little box. Potential employers need to know what you do. Are you a designer, a coder or a server side developer? Companies don’t know what to do with people who know a bit about everything.
Start networking. The best place to find job opportunities is by attending conferences and meetups. Even if you cannot afford the conference itself, turn up at the parties and stand in the halls. Just get yourself out there.
Register with recruitment agencies. As an employer I hate recruitment agencies because they cost me money. However, we do still sometimes use them and it doesn’t cost you anything to be listed with them.
Ensure your website is perfect. The first thing I do when I look at a potential employee is check out their website. Their site has to be outstanding. It needs to look amazing, be well coded and rich with great content that demonstrates a passion for the web.

Hopefully that helps Andrew and keep an eye on the comments for more advice.

Series: Building A Better Web Application by Ryan Carson

Ryan Carson: Hi I am founder of Carsonified a small web company in Bath, England. I am an American as you can probably tell, as for living in England I have been here about nine years. So a little bit of history about us real quick so you know who I am. I have a computer science degree and I have been involved in building four web apps and we are building a fifth truvay.com which will be released later in 2009, and we have sold two of our webapps dropsend.com and heyamigo.net. So the stuff that I am going to share with you today are lessons I have learnt the hard way basically as we have built web apps.

So the first thing I want to talk about is the Admin area that you will build for your web app. What a lot of people don’t know is that the Admin area is really the key to good customer service. If you haven’t enabled really easy customer service then it makes it hard to actually please your customers when they have problems so the first one to make sure you build into your admin for your web app are one click refunds so if someone calls and complains and says hey I am having trouble this month I am really frustrated please help you want to be able to just go into the admin do a search for their email address, their name or their company or anything and bam one click and refund their last invoice and what this does is it gives you, it gives you the ability to just make them happy right away. With a lot of web apps these days on recurring billing you will probably be charging people 5,10,15, $20 a month so losing that amount of revenue in return for really making a customer happy is super important. So make that easy for yourself to refund that money.

The second thing I would make it easy to do is have one click password reset that automatically sends out email with the new password, so with Dropsend it was really hard to reset people’s passwords and that was the number one request people had problems with, they couldn’t remember their password. So if I was to do it again what I would do is I would actually build the admin so I could forward an email from somebody presuming they had sent it from the email address of the account, forward it into Dropsend or the admin and it would automatically know that what it needed to do is reset the password for that email and then it sends out a new one so literally you do not even have to visit the admin area to reset someone’s password you just forward an email that would be amazing, so that’s the way I would do it next time.

The next thing I would do is also doing a one-click resend invoice. So a lot of people they don’t understand they can go into their "My Account" area of a web app to see their past invoices and what they will do is they will just email you and say hey you know I need last month’s invoice. If it is hard for you to find that or send that it is going to make you less likely to help that person so I would do a search on the email address show a list of invoices bam one click and it emails them a pdf version of the invoice. That’s another, that leads me onto another area that I would like to talk about that is invoicing. If you are doing recurring billing sort of every month billing your customers make sure that you are not re-inventing the wheel I would recommend a web app called Spreedly.com and what it is basically it is a web service for recurring billing they have done all the hard work, written all the code, the code for the Dropsend recurring billing was at least I think 1200 lines of PHP and it was good solid code but it was really hard and painful to write. So I would recommend don’t re-invent the wheel use a service like Spreedly because it is making calls to an API if later you decide you don’t want to use a service like Spreedly any more that layer has been abstracted out so you could replace it with your own billing system or another one and it won’t kill you, but I would say hands down don’t rebuild reoccurring billing it is a real pain in the ass.

The last tip I would say about your admin area is make sure that it is easy to give your customers credits. you want to be able to login search for an email address and just give them, hey I want to give them five bucks towards next month, ten bucks just to make them happy and you will have lots of happy customers. So that is my five minutes of tips, thanks Paul for letting me be a part of this. Take care Bye.

159. Special Guest

Posted in Classic shows on April 1, 2009 by Paul Boag

On this week’s show: The northerners are back with special guest host Sarah Parmenter.

Podcast: Download (29.1MB)

On this week’s show: The north erners are back with special guest host Sarah Parmenter. We answer your questions on how to quote for projects and whether using off-the-shelf software is wrong and we have a chat with Sarah on her experiences in the industry and the difference between developing for clients and developing for yourself.

Download this show.

Launch our podcast player

News

Alkaline

Our first story for is a new product by the guys over at Litmus, you may have come across their Browser and Email testing apps before and they’ve just released a new Mac app called Alkaline, this is a Mac front-end to their online browser testing suite and lets you test your website designs across not only 17 different Windows browsers which they mention on the site, but also all of the Mac and Linux browsers that the online Litmus services test against.

Alkaline grabs screenshots of your site rendered in all major browsers, the number of which depends on your chosen pricing plan, It’s free to test against IE7 and FF2 and if you need to test across all browsers, it’s available under the standard Litmus pricing plan which offers both individual and team monthly subscriptions, and a handy day-pass if you only do this kind of testing every now & then. Litmus also stores a history of your screenshots so you can see the evolution of your design and also reports your HTML and CSS errors.

There’s plugins available for Textmate and Coda, and you can preview the sites right inside Coda 1.6’s preview window, however because Alkaline grabs screenshots of your pages it’s not possible to do any live updating of CSS and see the results in all browsers.

Paul at Litmus also informed me that throughout April, they’re offering full access to the Litmus service for free on Weekends, so on Saturday and Sunday you can test across all the browsers (using Alkaline or the Litmus site) and all the email clients, even if you only have a free account.

16 design tools for prototyping and wireframing

It’s no secret that prototyping or wireframing can really help in the overall design process, and there’s now a wide range of tools on the market that aim to help you in this process. A recent Sitepoint article lists 16 of these tools and rates their usefulness.

The list of tools is good, convering favourites such as Omnigraffle, Axure and Balsamiq to other applications which can be used to wireframe such as Powerpoint or Keynote. If you’ve not looked into these kind of apps before then do check it out, they also lists the price of the apps so you’re sure to find something within your budget.

10 Lessons every freelancer should learn

If I remember rightly, I came across this link from one of the people I follow on Twitter and it covers some killer tips on how to be a better freelancer, covering everything from self promotion, organising your workflow, finding time for your own projects, keeping motivated and how to charge appropriately, this is a must-read for anyone considering freelancing, or indeed those already in the freelance world.

Some great tips come in the way of keeping customers happy and generating repeat business and I’d like to squeeze in a forth link here to another Sitepoint article (sorry) which covers how to upsell additional services to clients as a freelancer you should be looking at maximising the amount of money you can make from each project through added services, whether it’s packaged services such as hosting, logo design or business cards.

I don’t really freelance but I do manage a couple of small sites I built on a freelance basis, and I get recurring revenue by hosting them on a small reseller account. I’ve also been able to tempt the customers into paying for a years hosting rather than a monthly cost by rounding the amount down to an even figure, which while it’s only a couple of pounds cheaper, always got chosen.

Interview: Sarah Parmenter on the difference between developing for clients and developing for yourself

Ryan: OK, so onto our interview section and what we are going to do today is an off-the-cuff interview with you, Sarah, er, so for people who don’t know who you are, er, do you want to introduce yourself.

Sarah: Sure, my name’s Sarah, I’m based in Leigh On Sea in sunny old Essex and I own a company called ‘You Know Who Design‘ that’s been going for about nearly seven years now, um, and I just do web development and sometimes I dabble in a bit of graphic design. Um, when I started off when I was younger, it was more graphic design than web but now it’s purely web and, er, yeah, it’s what I love doing.

Ryan: Right, OK, and we think a good topic to have a chat with you about would be the difference between developing for clients and developing for yourself.

Sarah: Yup

Ryan: So, er, let’s start off. Do you give yourself time to work on personal projects?

Sarah: I do, but not as much as other people do; whenever I see on Twitter, there’s a lot of people who have a lot of personal projects on the go and it generally tens to be on a Friday as well (all laugh), you see Twitter on a Friday, generally full of people, um, doing their own stuff but I tend to, if I’m doing something I tend to, maybe, give myself a couple of hours if I’ve got a spare, if I’m waiting for a client to get back to me on something and I can’t proceed with anything. I put client work first, and I don’t know if that’s a good thing or a bad thing, but that’s the thing that pays the bills, so, um, they always come first and if I’ve got a bit of downtime, I’ve always got projects that I want to work on, but possibly haven’t got the amount of time to dedicate to them as I’d like. I think it’s probably the case with everyone.

Sarah: Yeah, absolutely. You get some time, don’t you, through work?

Paul: Er, well we did sweet talk our boss into giving us 5% time, which was supposed to be like Google’s 20% time, where they get a whole day to work on personal projects, if it benefits the company.

Sarah: Really?

Paul: Yeah, well we got, like an afternoon on a Friday, which is kind of sidelined at the moment.

Ryan: To spend in the pub (laughs)

Paul: That’s personal projects, I’m sure. No, it’s kind of sidelined at the moment, we’ve got some major projects on which are taking up all our time with some heavy deadlines, so we’ve had to shuffle that. Hopefully we’ll start to get that back over the summer and work on some cool stuff instead of the business stuff.

Sarah: I think it’s rea
lly difficult, because obviously your client stuff does have to come first, and even if you’ve dedicated an afternoon or a couple of hours, if something comes up that morning, or if you’ve got a problem that needs sorting, unfortunately, it’s just the way it is, your client work has got to come first.

Paul: Yeah, pays the bills.

Sarah: I mean, a lot of personal projects, a lot of people’s personal projects, do end up very lucrative for them, and you could argue that it’s just as lucrative to just go along with your own personal projects, but I think in general, most people would find that their client work would, er, would have to come first.

Paul: We’re trying to convince our boss to let us build, er, an iPhone app

Sarah: Really?

Paul: and sell it on the app store. He’s not having none of it, because we’ve told him we all need iPhones to test it on, he just won’t buy them for us.

Ryan: and a mac to develop on

Paul: a Mac to develop on, yeah. For some reason, he’s not warming to the idea.

Ryan: he can’t understand the thirty grand, you know, outlay to…

Paul: We’ll easily make that in a day on the app store (all laugh), I keep telling him this.

Sarah: the app store!

Paul: Yeah, the app’s 50p, you know…

Ryan: Er, completely sidetracked there, erm. What differences do you find, er, between developing for clients and developing for yourself? What major differences do you find?

Sarah: I find, when I’m doing stuff for myself, I’m actually a lot less decisive on stuff. I sort of, because I’m immersed in, maybe my own branding, or sometimes it’s really good to look at it from an outsider’s point of view. If you’re doing stuff for clients, I think sometimes it’s easier to look at stuff and go ‘well, that needs to go there and that needs to be there to catch someone’s attention’ or you need to move that or make that a different colour, and when it’s your own stuff I think you tend to be either really creative and you don’t really care if you get stuff wrong, or if, do you know what I mean? It’s more, sort of… the boundaries aren’t there, you’re not time-constrained, there’s no brief, you just go off on one, doing whatever you want, whereas with client stuff, there tends to be a bit more, erm, what’s the word, consistency across everything, and I find, personally, when I’m doing my personal stuff, I could sit in front of Photoshop pushing something from the left-hand side of the screen to the right-hand side of the screen for two hours, wondering whether it looks right or not, whereas if it’s a client site, I think ‘right, I have to make a decision on this – where would this go, or where would it be best placed, and you make a decision and you move on, because otherwise the more time you, you take going backwards and forwards is, er, less money that you’re earning, so I think I tend to be more decisive with client work and with my own I tend to be a bit more, erm, easy-going and, er, possibly a bit more creative, in the sense of trying things that I haven’t tried before. Erm, yeah, I think it’s just good to be (pause – all laugh).

Paul: I think personal projects give you time to play with the stuff that you wouldn’t normally risk putting into a client’s site, things that might take you a week to figure out.

Sarah: That’s what I, sorry a man just walked past my window in a pair of shorts, as I was answering that question, which completely put me off,

Ryan: Was it an ugly man, or a good-looking man?

Sarah: No, he was an old man.

Ryan: Oh, right. OK

Sarah: I wondered if he had dementia or something, and he thought it was summer.

Paul: Was he in just a pair of shorts?

Sarah: Yeah

Ryan: A pair of shorts and a smile?

Sarah: No, and a newspaper.

Paul: Strategically placed.

Sarah: It just completely sidetracked my thinking pattern, then.

Paul: That’s OK.

Sarah: Oh, sorry.

Ryan: Where were we? So, which do you prefer, developing for clients, because obviously you’re doing that every day, or do you prefer developing for yourself?

Sarah: I actually prefer developing for clients, erm. I prefer getting a brief and thinking ‘right, how can I best interpret this brief, and get the objectives that they want, er, they want to get out of this website, how can I do that in the best possible way?’ Whereas, I think that when you do stuff for yourself, you don’t necessarily write down a brief as strict as you’d get when a client is sending through something. So, I, I actually prefer developing for clients, I really like, I don’t, I really like doing all the end, getting to the end product with a client. I think I get more satisfaction out of that than I do when I’ve done it for myself, because I still look at it in a very critical point of view, I still think, ‘oh well, maybe I could make those buttons a slightly different hint of green and it will look better’; whereas, with client stuff I think it’s just all about decision making, I think you tend to make more decisive decisions with client work than you do with your own. You think of your own as an ever-ongoing project that you can forever tweak and make changes to, whereas with client stuff you, once it’s live, it’s pretty much. You might get to update…

Ryan: Yeah, it’s difficult to come back, isn’t it?

Sarah: Yeah. Exactly. So I much prefer developing for clients, when they’re nice clients!

Ryan: Yes, we only like the nice clients.

Sarah: Yes, we all like nice clients.

Ryan: But do you think personal development time is important, do you think it’s important to develop your own projects?

Sarah: Yeah, I do I think it’s important from the sense of being, when I personally do lots of my own stuff, I find that I tend to be a bit more, erm, creative, in the sense of I’ll try stuff that I might think ‘oh, that’ll look awful, I won’t bother doing that for a client site’, but I might try it and actually surprise myself and think ‘oh no, actually, that’s a really good technique to use’ or do something a bit different because you’re not constrained by time when you’re doing stuff for yourself, necessarily. But I think, I do think it’s really important to do your own, your own thing, because I think it’s also a learning curve, you might try out different systems to use, you might decide to learn something, you might decide to use something like, if you’ve never used WordPress, you might decide to go and bolt WordPress onto your site just to see how you get on with it, you might try different apps. I think it’s important, because it frees the mind to use other things that you might not necessarily get to use when you’re in an office environment or, or perhaps even day to day because you don’t have the time to learn it, so I do think it’s important, but I don’t think it’s the, er, the be all and end all of everything.

Ryan: I think, er, a good tie-in question, not specifically about developing for clients and, er, yourself. Erm, keeping it with blogs and stuff, do you allot yourself a, like, time to read your feeds and, er, things like that, and to keep up with them, because I’ve been so busy in the last two weeks, my feeds have just gone like – you know when Google Reader says ’1000+’ and that’s it, it’s just stopped counting, it’s gone ‘look man, give up on these feeds, you’ve passed a thousand.’

Paul: You need to declare feed bankruptcy, I think.

Sarah: I tend to do this really annoying thing, where if someone posts a good link on Twitter, I’ll open it up in a browser window in a tab, and then if someone else posts, I’ll open that in another browser tab, so I’ve got about 100 tabs open in Firefox that I never get round to, to looking at, which slows the whole thing down and end up having to then bookmark them in a little folder called ‘Interesting Links’, that I never get around to reading.

Ryan: When you look back, they’re four years old and completely out of date.

Sarah: Yeah.

Paul: The shocking thing, because I do the research for the, the Boagworld news and push it all through the links, I probably churn through 150-200 feeds a day (Sarah: gasp), which is so many feeds that I haven’t got time to read them, which is shocking; I get so much information, so many good things that I’m pushing out to other people, that I just don’t have time to read them, there’s too much information.

Sarah: Do you skim-read them?

Paul: I do, I skim-read, I usually read the first few paragraphs, just to see what the article was about, clip out the interesting bits of text for the previews and then send it on it’s merry way out of Twitter and then I’ve written a function that, every time someone clicks a link on Twitter, it kind of lets me know, tracks back and so I can see, right, which… and I watch it, I’ve got live stats and streaming on one of the spare monitors, so as this link goes out onto Twitter, I can see it being read, so I can actually what’s actually what the people are reading, what’s been interesting that way, instead of me thinking ‘that’s genius, we’ll use that on the show’. It’s actually kind of crowd-sourcing information like this.

Sarah: Yeah, that’s a better way of doing it, isn’t it? It’s more productive.

Paul: Yeah, but I do the same, it’s like something I really want to read, I’ll open it in a tab and I’ve got the permatabs thing on Firefox, so I’ll set it so that I can’t delete it until I’ve read through it, but usually it just ends up there for weeks.

Ryan: I tag them in Delicious, so I’ve got like tutorials and stuff that I think ‘oh, that looks fantastic’ and I’ve got a ‘to try’ thing, which is slowly increasing in number and I never sit down and have a go through the tutorials or anything like that.

Paul: Yeah, I think the key is to follow a few key, key things and not try and follow too much information, and then just look at what everyone else around you, the people that you respect, in what they’re sending out and try not to get overwhelmed because there’s a lot of information out there.

Sarah: Dead right, there’s so many, it seems to be a new thing on Twitter to actually post those sort of links, day in, day out, which is really handy because there’s a lot of people who have a lot of good stuff on Twitter.

Paul: Oh twitter.com/boaglinks is the premier source of all this information, of course.

Sarah: Of course! (all laugh)

Ryan: Er, OK, so I think the final question to you, then Sarah, is, erm, what inspires you to pursue your personal projects?

Sarah: Erm, oh, that’s a difficult one. I kind of get inspired in strange places, when I came back from the Future of Web Design and Future of Web Apps, I kind of get inspired by other people, not necessarily the apps that they’re producing, or work that other people are producing, but I sort of feed off other people’s energy, strangely. If other people come away from something really, erm, excited about something, I tend to think ‘oh, yeah, that sounds like a good, like when Adobe Air came out, that was a kind of a buzz around that for a while and it got me thinking ‘um, what can you develop with that that would, you know, might be interesting to other people or that other, that other web designers might want to use?’ but that’s kind of what happened with my own app, Olive, it’s kind of on the backburner at the moment, but there was a problem that came up at work and it was coming up time and time again and I thought ‘there must be something out there that actually addresses this issue of, of erm, client management, so went around, couldn’t find anything and then ended up building it, and it was actually built more for me, rather than other people and when I sent it out to a few people, they really liked, and got into using it and, erm, it’s just kind of handy if you build something that’s, that’s great for you, but equally other people find interesting as well. It’s, erm, it’s a win-win, really. I mean, I use it all the time, and there’s other people who do as well, bu
t at the moment it’s, er, needs a lot of updating, because I’ve been so busy with client stuff, but maybe I should have put that first, but clients pay the bills unfortunately.

Ryan: Absolutely, absolutely. I think I, erm, I think I overthink things, so I think to myself ‘oh, I’d love, love for this to exist’ and then I think to myself ‘I could spend the next three years developing that’ and, and someone would do it better than me, you know and just finding time as well.

Paul: Yeah, I think it’s right what Sarah says, you’ve got to scratch your own itch, you’ve got to find something that you would want to use so much that you would spend that amount of time to build it, and then if it’s for you, it doesn’t really matter that much if no one else wants to use it because it does something that you want it to do.

Sarah: Exactly.

Paul: And it’s a learning process, you can choose any language. If you want to learn a new language, if you want to learn Django or Python or something, you could build it in that, just to learn that language, erm, and then send it out in the world, see if people use it.

Sarah: Exactly, that’s kind of what happened. I was learning quite a bit about Ruby at the time, because Olive, Olive’s built on the Ruby on Rails platform and it was so interesting just to get an insight into how different developing with Ruby is compared to PHP. That was just worth it in it’s own right, really because I find that I learn much better with real world examples rather than looking at a load of code. I find that if, if I ever get something like that, I have to take it apart, almost, and then try and work out how to put it all back together so that it works. I think I learn better by doing that and a lot of people do. If you going on to any of the tutorial sites now, there tends to be a lean towards developing an app or something small; I think on the Nettuts at the moment, website – do you guys know that one?

Ryan: Er, yes.

Paul: Yes, ah the Nettuts, oh yeah.

Sarah: Yeah, there’s a, there’s a sway towards actually building like login systems from scratch and things like that on there, where it’s actually showing you the code and then showing you how it works in real world situations which I think is really good, for me, I don’t know about you two, but I personally prefer picking stuff apart (laughs).

Paul: Yeah, absolutely. I usually start at the very lowest common denominator, like a user access system, and I’m learning CakePHP now which is, kind of a Ruby clone for PHP and instead of using their in-build methods which will do it all for you with build this, just write these classes and it’s like ‘No, it’s like the most basic thing I can do in this language, let me learn how to do it’, and I’ll learn that way.

Sarah: Yeah, yeah, that’s, I think when, erm, when I looked at using Ruby for, er, for Olive, I didn’t build it, it was built by a guy, a brilliant guy, Adam Cooke, but I was still really interested to know how it would work and how Ruby is different and the first thing I did was built a, erm, a basic recipe, sort of database thing with, it was off of a tutorial site and I think it’s great if it gives you just a little bit of insight into something that you might not have already realised or known about building your own stuff, then I think you have that sort of passion to go forward with it, you have that confidence to then think ‘oh, well I’ve done that tiny thing, maybe I can do something else with it. Whereas, if you’re doing it for clients, you don’t, you wouldn’t really venture into using another programming language that you weren’t comfortable with on a client site, unless you were a bit silly.

Ryan: Absolutely, absolutely. Paul told me a really funny thing, in between, er, when he told me he was learning CakePHP. He said, I’m trying to remember what it was that you told me, it was ‘if Ruby’s French, CakePHP is French with an English accent’

Paul: Yeah, its kind of the same, just not quite as elegant.

Ryan: Yeah, I thought that was fantastic, that was so fantastic, I made it into, I have some rotating quotes on my web-site, and that made it into my quotes, that was fantastic.

Much thanks goes to Simon Douglas for transcribing this interview so quickly!

Listeners Questions:

Is Using Off-The-Shelf Software Wrong?

Jon Writes:

I guess my question is about the use of off-the-shelf software. I must admit I feel slightly uncomfortable using it at all. As a decent sized agency of 9 people, with our own very capable developers, I can’t escape the nagging feeling that we are “cheating” slightly by using an off-the-shelf platform at all. Although we adhere strictly to licensing requirements, most of our customers do not know that their stores are powered by what is essentially a ready made system, which we then skin, configure and populate.

What are your views about off-the-shelf stuff and the pros and cons of using it on client work?

Thanks and keep up the good work!

I think the main source of your discomfort is the fact that your clients don’t know you are using off-the-shelf software for their projects, which raises the question why not?

Your clients have approached you to provide them with a service they cannot perform themselves. Whether that is building a system from scratch or integrating and customizing an third-party system to meet their needs, you are still the expert.

There are very powerful off-the-shelf e-commerce systems, blog engines and CMS’s that should be thought of as weapons in your arsenal rather than “cheating”. Explaining to your clients why you are going to use a particular system for their project can be hugely beneficial. It shows that you don’t want to waist their time and money re-inventing the wheel.

Therefore, the pro’s are:

It meets there project aims
You are experienced with the system
It’s supported by a third-party team of developers who are dedicated to that one product and includes a vast community of other users who support each other
It can be implemented in a shorter period of time than building from scratch (i.e. cheaper for the client all round)
It’s a tried and tested system (You could even give your client a list of other successful companies that are using it)
It is also more than likely that a third-party product that has been around for several years is a more reliable and robust system than the one you develop in a couple of months.

That said there are always inherent risks in using anything third-party, whether it be API’s, frameworks, libraries or software and I have a general rule of thumb that I try to always adhere
to:

Don’t implement something you don’t understand!

If it breaks, it costs you time and money to fix the problem, and that’s once you’ve diagnosed what that problem is. The longer it takes you to fix the higher the risk that your client is going to lose confidence in your ability to deliver.

So take the time to do some dissecting and learn how to use your tools as fully as you can prior to implementation.

How do you price and quote different projects?

Jamie who’s just started up his own web development company is having trouble working out how to price and quote different projects and wonders if we have any tips that we’ve found helpful when quoting for clients?

One of the hardest things when starting out, and even for established businesses is finding your feet with pricing. I think the biggest lesson I learnt is not to under-quote just to gain the business, even though you are in need of clients. It makes no business sense to work for peanuts, you’re better holding off for a client who respects the work you do and pays honestly for that work rather than being a design machine churning out work just to make ends meet.

The other important thing I learnt in my first year of business is, clients who barter with your prices are generally bad news. We’ve all heard it, “if you can do this one at x-amount we have plenty of other work in the pipeline we want to use you for” – while this sounds tempting, 9 times out of 10 the promise of the further work never comes off, even if it does they would normally expect further work at the “cheap” price they paid you before, as you accepted it so you must be happy to work for that right? Wrong.

I always find it helpful to ask the client for a ballpark figure prior to laying out the full proposal, this negates you wasting time putting together the proposal of cost plus terms and conditions only to find the client wants to build ebay on a budget of £300.

I also find ballpark figures helpful because I find it easier to provide the client with options, even if they have a relatively small budget there is normally still something you can do, even if it is very basic – but it gives you a starting block to explain if their budget was a bigger they could bolt on a CMS system or have a better shopping cart, then explain the benefits of those. You’d be suprised how much the budgets are then increased by.

It’s all about providing the client with the best solution for their project at the end of the day, and if you think the best solution would be bolting on Expression Engine or the like, you need to give the client the choice to do this and expand their budget if necessary rather than cut them out of the equation because of it, it’s all about educating the client.

156. IE8

Posted in Classic shows on March 11, 2009 by Paul Boag

On this week’s show: Ryan talks to Andy Clarke about Internet Explorer 8, Paul looks at how to simplify your site, and Michael argues that marketing should run the company website.

Podcast: Download (27.7MB)

Download this show.

Launch our podcast player

Housekeeping

Don’t forget our SXSW coverage

Just a quick reminder that next week is our live boagworld show from SXSW. If you are attending the conference please sign up on upcoming and come along. If you aren’t then you can watch via uStream. The show is being recorded at 6.30PM (CST) at the Hilton Hotel, Room B.

Whether you can attend or not we would love to receive your questions for the panel. Email them to me ASAP!

You can also follow coverage of SXSW on the boagworld website, so check that out too.

A Website Owners Manual Discount

For those who don’t already know I have now finished the ‘Website Owners Manual‘. This means the book is moving into production where they give it the final design and replace my terrible illustrations. Hopefully this process should be finish by July when the book will finally be released.

However, the entire draft manuscript is available now in ebook format for those who cannot wait. Also with Manning’s early access programme you can preorder the printed book and get a copy of the draft ebook to read immediately.

To further sweeten the deal you can get a massive 40% discount if you use the code ‘AUPROMO40‘ at checkout.

To order go to boagworld.com/websiteownersmanual.

News and events

If only IE played nice

Let’s kick off with two posts that really makes you wish IE played nicely!

First up isFluid Grids, an A List Apart article that discusses fluid layout and the limitations of IE. In particular it focuses on IE6 and its failure to allow page scaling. When combined with the smaller resolutions of many netbook PCs, it is apparently that fluid layout remains an ongoing requirement for many sites.

The article takes you step by step through the process of creating a fluid grid system. Although it is very comprehensive, it does involve some serious maths and leaves you with an even deeper hatred for IE.

The second post I wanted to mention is written by Rachel Andrew and is entitled Developing CSS for IE6 and 7. This is a great introduction to building websites using CSS and surviving to tell the tale!

The emphasis is on the development process and how to address common IE problems. It is a very pragmatic article that is not afraid to mention the use of conditional comments and hacks. In fact in many ways it is the total opposite of a recent post on Sitepoint entitled SitePoint » 5 Reasons to Avoid CSS Hacks and Conditional Stylesheets. That post borders on naivety.

Its nice to see a resurgence of posts on CSS. They disappeared for a while and yet I believe there is still room for improvement in how we build sites.

Why Friends Reunited Failed

In last week’s show I talked about the harsh truths of running an online community. If that was relevant for you, then you should visit Andy Budd’s site and read this insightful post – Why Friends Reunited Failed

In his post Andy compares the failure of "Friends Reunited" compared to the success of Facebook.

The gist of Andy’s argument is two fold. Firstly, the site provided little to keep users coming back. Andy writes…

So with Friends Reunited once you’d registered, seen what your old friends were doing, connected with the ones you’d wanted to and had a laugh at the (hopefully) tragic lives of your childhood tormentors, there was very little reason to stick around.

Second, they decided to charge for membership, thereby changing the relationship…

Charging for a service changes the whole dynamic of a site and causes people to game the system in order to get the maximum return on their investment. So it becomes less of a community and more of a commercial relationship. Like a lot of commercial relationships, once the value runs out, people will stop paying and leave.

Its an interesting read and helps emphasis the importance of providing tangible value to your users.

WordPress overload

As you will know if you follow me on Twitter, I am currently in the process of moving Boagworld from Movable Type to WordPress. The primary reason for the move is WordPress’ vibrant development community. There are literally thousands of plugins available and endless tutorials and supporting material.

Although Boagworld does provide some marketing benefits to Headscape, it is still a side project. As a result, the time I can invest in it is minimal. Plug-ins allow me to add functionality and make usability improvements with minimal effort.

Interestingly as I have been making this transition, I have noticed a substantial increase in the number of WordPress related posts in our news stream. I am not sure if this is because I am more aware with them or Paul Stanton thinks I need a bit of help. Either way they have been useful reading.

Three in particular have caught my attention…

11 Non-Traditional Uses of WordPress – A great little post that demonstrates the flexibility of WordPress. It shows the blogging platform being used for everything from a Wiki to Contact Manager.
More than 10 "Must Have" WordPress Plugins – A collection of plugins which helps (among other things) to keep your content fresh, improve SEO and manage comments.
15 Useful Twitter Hacks and Plug-Ins For WordPress – Some great code snippets and plug-ins that allow you to do everything from encourage people to tweet your content to create an entire twitter page.

Interview: Andy Clarke on the release of IE8

Ryan Taylor: Joining me today is Andy Clarke. Hello, Andy.

Andy Clarke: Hi, how are you doing?

Ryan: Not so bad. And we’ve asked you on today to talk about the upcoming release of Internet Explorer 8.

Andy: Browsers, my favorite subject!

Ryan: Yes, well you seem to blog a lot about browsers at the minute, you seem to be talking a lot about Internet Explorer 8 especially.

Andy: Well, I’m kind of a bit of a grumpy old bastard, really, when it comes to browsers. And, so the topic of the moment, certainly of the last couple of weeks has been what are they going to do with IE8.

Ryan: Yeah, so should we be excited?

Andy: I don’t know whether we should be excited or whether or not the thing is a little bit of a anti-climax, to be perfectly honest. I think that there’s a huge difference between people like me who develop websites for normal people out there, conusmers who use the internet, and people like me who are aware of standards and passionate about CSS and maybe thinking about progressive enhancement and some of these other things. A huge difference between people like me and the army of people I know who work inside corporate environments. People who develop big banking finance applications, for example, where Internet Explorer is usually the vehicle that people access that content with. And I think that for those people, IE8 is a big deal. Particularly over what happened with IE7. So I think that for those kind of people, it’s going to be a ride again. But for people like me, you know it’s kind of a bit of a non-event, to be perfectly honest.

Ryan: And do you think they’ll start changing the way that they build websites because of IE8 then?

Andy: There’s an interesting kind of back story that goes on with what Microsoft did with IE, and generally speaking a lot of the problems that they have in developing that browser come because the people who build applications that are predominantly used by IE8 are not the people who are generally standards-aware. And this is why Microsoft has gotten themselves into so much trouble in the past when they have, let’s face it, done the right thing in improving the browser, particularly with IE7. And of course IE6 was famously full of colourful bugs, and all credit to the guys at Microsoft, who I know fairly well, in, you know they were very passionate about getting those things fixed. But of course when IE7 comes along and people that developed code for IE6 all of a sudden found their applications breaking, they didn’t look in the mirror and think, “Why is this stuff breaking? Is it my code? Is it something that we’ve done wrong or that we need to fix?” They blamed Microsoft. And Microsoft has this big thing about not releasing something that is going to, say, break the web. Well it won’t break the web, but what it might do is break applications and break websites that were based on a broken browser. So it’s not a simple issue, unfortunately, and this is something that Microsoft struggled with for quite some time, and I know that they’re going to be struggling with again in IE8.

Ryan: You mentioned that the way that you build websites for your blogs isn’t going to change, but CSS tables are going to be available in IE8. Do you think that we’re going to see CSS tables more widely spread and adopted in web design?

Andy: I’m sure we are, I mean I’m always really pleased whenever there’s a piece of CSS that’s more widely adopted. IE in itself has been dragging its feet about CSS tables behind all other browsers. I think that, where appropriate, yes CSS tables are going to be useful, but I think there was a lot of excitement, I think wrongly, to do with CSS tables, in people thinking that all of a sudden we had a good way, or a new way of making CSS layouts. Something that was perhaps more reliable than using floats of positioning, and I think that the more and more that I look at that, the more I think that it’s essentially going down a wrong and a backwards route, if we think that mentally we start thinking about table cells again. What we do is we again start to tie what we see on the screen, in terms of the presentation, to form the structure of our markup, and that is always, always wrong. CSS tables do require that we order markup in a certain way, just like HTML tables did, and I think if people start to go down that route, then I think they’ll soon find that really there is absolutely no advantage, in effect, in replacing HTML table layouts with a bunch of divs and other structural elements and styling them like tables.

Ryan: Ok, so there’s going to be some improvements in IE8 over the previous browsers, but they’re introducing this compatability feature. Can you explain what that is? And share your views on it?

Andy: Aw, the famous compatability feature. Well, for those people who haven’t been following this thing for a while, and this goes back to what I was saying at the beginning about Microsoft’s core market, they have to be very careful that they aren’t seen as the ones who are, in their words, breaking the web when they fix some of the problems that they introduced before. So a little while ago they introduced this idea of using a meta element which would essentially tell the rendering engine inside of IE which version of IE that you wanted a page to look like. So, for example, if you were to use the IE7 meta tag inside the head of your document, IE8 would render your page as if it were IE7. Which, of course, is a great idea for these people who build these enormous IE-based corporate applications, because they don’t have to worry about IE8. They can simply stick this plaster on, this band-aid on, and go away and think “Great, I don’t have to think about IE8 now.” It gives them a little bit of breathing room. Now Microsoft originally wanted to introduce this thing as an opt-out process. Basically, the browser would render like IE7 unless you told it that you actually wanted it to render like IE8, which was completely backwards. So, a bunch of people – Jeremy Keith was the most eloquent as always – argued that this was a complete crock of shit and would essentially hold back any incentive for people to move to a better way of working, to use CSS and markup in better ways because of IE8. So Microsoft changd their minds, and they made it an opt-in rather than an opt-out. And
certain people took credit for them making that decision. I think only Microsoft know why they made that change. But interestingly in the last couple of weeks, it came to light over on the IE blog that they’re introducing this compatability feature which would essentially mean that anytime anybody pressed the “View in IE7” button, or used that feature, it would talk back to Microsoft. And then Microsoft would compile a list of sites that people clicked compatability-mode on, and then automatically, and perhaps without the viewers asking if they’d already opted into this thing, the browser would then hit a certain site and render as IE7 rather than IE8. That’s an interesting thing. A lot of people have been talking about the standards implications of that, and about the incentive for corporates to switch to coding in better ways. One of the things that hasn’t been talked about much is the privacy thing, the privacy angle. Essentially your browser is talking back to Microsoft in Redmond every time you look at a page. So I wonder, I’m a little concerned about this. I can understand why Microsoft do it, and I can understand why they want to try to find a way of not upsetting their core marketplace. And Chris Wilson, who’s a friend of mine and head of the IE team, wrote on Twitter, “Well can you think of a better idea for our customers, so that they don’t think,” I’m paraphrasing here, “so that they don’t think that we’ve broken the web when we launch a new browser?” And my answer to that is – it’s not your problem! If you make the browser, if Microsoft make the browser the best they can possibly make it, with the best of their efforts, and they are really smart people, then if websites break in IE8 that’s not their problem! It’s a problem for people like me, and it’s a problem for website owners and web designers that need to make their sites work in IE8. So I think, again, Microsoft are kind of barking up the wrong tree, but I can see why they have to think that they do it.

Ryan: Okay, well IE8 is also missing a few of the other more popular CSS3 selectors that are available in other browsers, like border-radius and things like that. Is this a setback for CSS3?

Andy: No, I mean it’s a shame that Microsoft haven’t introduced more of the CSS3 features to date, it’s frustrating for me because I do like to do the whole progressive enhancement/progressive enrichment type of thing, that I can’t have something that looks fantastic in Safari or Firefox, or possibly Opera, looking as good in the browser that obviously most people use. But I think that there’s a bigger issue here in that there’s a technique available for browser makers, to implement some not quite ready features of CSS3 at the time that they choose. That’s this whole kind of “-moz, -webkit” thing. And it’s a very good way, it was designed obviously for browser makers to test implementations of CSS3 properties so that then they wouldn’t break when they switch to the real thing. So if you do –moz border-radius, you could then switch to border-radius and it would do the same thing. So it’s a great way for people to be able to test these features. The interesting thing, though, and this is the wider issue, is that there’s no strategic plan, either from the browser makers or, most importantly, from the CSS working group, where they plan in a timetable implementation of these new features. Now we’re not talking about the big design of CSS, and when are we going to get new layout features and things like that, but simple things like for example CSS columns? Webkit implements CSS columns, Mozilla implements CSS columns, but they do it independently, they do it when they want to on their own timetable, and what I’d really like to see is for these browser makers to get together and say “You know what in September, we’re going to introduce these columns across the board, and in October, or in our next release, we’re going to implement this across the board.” I would like to see them working together so that actually we can start to look at different implementations of, for example, columns. We can look at them in Firefox and we can look at them in Webkit, and we can go “He gets it right, that one’s slightly wrong” and then they’ve got a playing field to work on. And it’s much wider than the overall kind of “Is IE going to implement this or not?” The wider issue there, as I keep going on about over the years, is the whole process of developing CSS3 and the role of the working group.

Ryan: Yeah, it’d be nice if they’d collaborate on more things, not just CSS! So there are some new government guidelines in place which you blogged about recently for cross-browser testing. Is this going to affect the way you approach building websites, especially now that IE8’s coming out, and with looking at IE6 and all that. Are the guidelines going to affect you in any way?

Andy: Day to day, probably not. First of all, because I don’t build websites for government institutions. I don’t tend to do any kind of public sector stuff, for various reasons. And these are guidelines for government websites. So no, in terms of them affecting me on a day to day basis, no, because irrespective of my clients, I try to push as hard on the CSS progressive enhancement thing as I can. I think it’s very, very interesting and it’s a nice and mature approach that whoever’s drawn up these guidelines is taking, to actually understand that websites don’t need to look the same in every browser, and in fact they shouldn’t look the same in every browser. I think that’s a mature approach, and I think the one thing that these guidelines will do to help me is when, on the rare occasion, I perhaps haven’t explained something properly to a client and they come back to me go, “Do you know what? I’ve looked at this thing in Firefox and Safari, and it’s got these rounded corners on the boxes, but I’m looking at it in IE7, and they don’t have rounded corners. Why is this?” And then the whole topic of progressive enhancement comes up, and sometimes people get it, and sometimes people don’t. But actually having something there as a little bit of a thing in your armory, to be able to say, “You know what, websites aren’t supposed to look the same in every browser, and if you need more than my opinion on that, then take a look at these government guidelines.” Then yeah, I think that’s really, really good news for people who want to take this approach with CSS.

Ryan: Ok, that’s great! Thanks for coming on the show, and good talking to you.

Andy: Yep, my pleasure, nice to talk to a northerner for once, rather than that soft southerner that I sometimes get to speak to.

Ryan: Haha, okay, thank you very much.

Andy: He’s naught but a shandy drinker, you know that!

Ryan: He is but a shandy drinker.

Andy: Take care, see ya.

Thanks goes to Jason Rhodes for transcribing this interview.

Listeners feedback:

Should the web team sit under marketing?

Michael from Leeds recent me the following email which I want to share with you. I am not sure I agree with everything he says, but he puts together a good argument and I thought that was worth sharing.

I just wanted to drop you a line about your blogpost, 10 harsh truths about corporate websites that you featured on your podcast as well. I was sat listening to that and wanted to pick up on harsh truth #1.

You and Marcus were debating the issue of separate web divisions and whether web responsibility should lie within IT, marketing or your preferred option of a separate web division.

There is no doubt in my mind that a corporate website has to remain the responsibility of the marketing department. There is no other place for it.

The role of marketing is to assess a market and identify a need. Marketing then drives product development and the positioning of the product, developing the messages that convey what the product or service does. The final step is to choose through which channels these messages are best put in front of the target audience.

The website is part of that communication mix. The website for any business needs to be created with a view to acknowledging that a problem exists and convincing the visitor that it has a solution. It then needs to convince that visitor to act. Where else then can the website sit? Who else should be approving the messages the website conveys?

Where I think you guys are coming from (and your experience is not one that is alien to me after over ten years in digital on the agency side) is this. Often the person in marketing responsible for the website doesn’t have the knowledge, vision, experience or perhaps understanding to brief, specify, approve or even give a valid opinion on whether a website does the job. That is a problem with marketing, and not a reason to set up a separate web division.

I believe wholeheartedly that marketing needs a digital specialist within it. If a website is to be developed in-house then a specialist team (certainly not in IT) should be developed, but responsibility for the website needs to remain under the control of marketing. Just because someone in marketing hasn’t done a TV commercial before doesn’t mean that IT should handle that project!!

Even in seemingly non-commercial websites such as charities or universities there is a communication message and the comms team (marketing) is still responsible for the story and positioning.

My feeling therefore is that if a client doesn’t have the skills in marketing it is beholden on us as the agency to guide them through the process. I’m sorry to say though that many web agencies have a lack of marketing skills and can’t relate to the marketing team.

If you need finally convincing about this, think back to the copy interview you did with Relly in issue #154. In writing copy for the web and indeed for any medium Relly needs to understand what a product or service can do. She will be guided by a brief from marketing, not IT, not the web team. As an integrated agency we have five copywriters and the words are the message, the visual is the support and the dramatisation of that message. The copywriter is a key member of our web team.

Hope you find these thoughts interesting.

I debated as to whether I should respond to what Michael has written. In the end I decided not to. I want to leave it to you guys to decide what you think. In either case it is probably something we will be unable to influence, so to a large degree the debate is academic. Nevertheless Michael makes some good points which I can respect.

Keeping it simple

The second listener contribution this week is from Oliver in Kent. He writes:

One of my latest clients (I won’t mention who) has the website from hell. It is far too complicated and full of pointless unintelligible content. I have tried to encourage him to simplify things but with little success. You have spoken about simplicity before, but I was wondering if you might be able to provide some advice on how to get this client to throw out some of his pointless content.

It is a good question and needs answering in 3 ways. You need to understand the lure of complexity, how to identify it and finally how to go about reducing it.

In fact this questions led to a blog post entitled ‘3 secrets to simplicity‘.

155. Attitude

Posted in Classic shows on March 4, 2009 by Paul Boag

On this week’s show: Paul asks if web designers have a bad attitude. Marcus talks about contracts and we take a look at working with browsers.

Podcast: Download (27.6MB)

Download this show.

Launch our podcast player

Housekeeping

I have a couple of pieces of Headscape news I would like to quickly mention.

First, Headscape has some office space we are looking to rent out. If you are looking for a small office in the Hampshire area and like the idea of working alongside us, then check out our video tour of the Barn.
Second, Headscape is also recruiting. We are looking for an enthusiastic, talented developer to join our team, working from of our offices in Hampshire. For more information see the job advertisement on Boagworld.

Finally, just a quick reminder to sign up to attend the live recording of Boagworld at SXSW. We would love to see you there.

News and events

For much more web design news follow boagLinks on twitter or signup for our RSS feed.

Atlas wows FOWA

FOWA Miami has been in full swing over the last week. The line up of speakers was impressive as always. However, judging by Twitter one session stole the show. That was the guys from 280 North showing off a new product called Atlas.

Atlas is built on Cappuccino, an open source framework that makes it easy to build desktop-like applications that run in a web browser.

280 North have already demonstrated the power of Cappuccino with the release of 280 Slides, a browser based version of Keynote.

However, Atlas takes things to a whole new level. In essence it provides a GUI environment within your browser to build powerful desktop like applications. It allows you to build Cappuccino applications without writing code.

When you first watch their video demonstration it really blows your mind. I in no way want to take away from what they have achieved. However, after I got over the initial impact, I realised I had seen this before – It looks very much like Adobe Flex.

Now anybody who listens to my show knows I am not a huge fan of flash. However, I have to wonder if Flash is not better tool for building complex web applications. I can see no real advantage to building it in Cappuccino. In fact as Drew points out in ‘The cost of accessibility‘, Atlas throws up all kinds of accessibility considerations, even if you ignore the fact it is built on Javascript.

Watch the video of Atlas in action, read Drew’s post and then compare it to Flex. Once you are done, post your thoughts in the comments. I would love to hear what others think.

Safari 4 is out in beta

So while we still patiently wait for the arrival of IE8, Apple have gone ahead and released its first beta of Safari 4.

Available for both the PC and Mac, Safari 4 has some impressive UI improvements and a considerable bump in performance. Apple claim that their new browser is 30 times faster than Internet Explorer 7 and more than three times faster than Firefox 3.

When it comes to UI and features Safari 4 ‘borrows’ heavily from Firefox and Chrome. New enhancements include…

Top Sites, an attractive display of frequently visited pages
Full History Search, where users search through titles, web addresses and the complete text of recently viewed pages
Cover Flow for history and bookmarks.
Tabs have been moved above the menu bar in a direct rip off of Chrome.
Smart Address Field, that automatically completes web addresses
Smart Search Field, using Google Suggest
Full Page Zoom

For us web designers, Safari 4 brings 3 key benefits…

It is substantially faster especially for Javascript heavy websites
It is the first browser to pass ACID3 so its standards support should be excellent
It has built in web developers tools, which are essentially a rip off of Firebug.

Generally the browser has been well received, although I note that Andy Clarke has expressed some concerns about the UI, especially in regards to tabs. He wrote…

Tabs in a real-world filing cabinet don’t change size according to how many files you have. Don’t mess with the metaphor.

I can see where he is coming from and have to agree. However, most of Andy’s comments are minor niggles and overall this is an impressive improvement. For more personally, safari now stands head and shoulders above other browsers.

Cross browser testing

Although the arrival of Safari 4 is exciting, it does bring yet another browser to test on. Increasingly browser testing is becoming unbearable.

To make matters worse it is not always easy to run these browsers side by side. IE is famous for being terrible in this regards. However, it is not alone. Even running Safari 3 and 4 together takes some hacking. Fortunately a post this week entitled: ‘How to run Safari 4 beta and Safari 3 on the same mac’ explained how.

There are also a growing number of services that aid in the process of browser testing. As with everything on the web, the problem is finding them. Luckily a website called the Freelance Folder has brought 7 testing tools together in a handy list.

Some of the services are free, others are paid. Some provide screenshots while others allow you to navigate your site. All allow testing in most versions of modern browsers.

The list includes…

Read the whole post for reviews of each service listed above.

jQuery browser fixes

Unfortunately no amount of testing is going to make up for the shortcomings in browsers. Whether it is a lack of border-radius support in IE or Firefox failure to render text-shadows, every browser has its limitations. In fact there are quite a few things that it would be nice if any browser did.

Fortunately Javascript can help overcome some browser limitations and even enhance them where they all fall short.

Of course, the downside is that plugging these holes is a lot of work. That is unless somebody has already done it for you. That is why I was so excited when Stanton pointed out ‘15 jQuery Plugins to Fix and Beautify Browser Issues‘.

This post lists 15 jQuery plugins that provide some incredibly useful browser enhancements such as…

Rounded corners for IE
Get browsers to display columns of equal height
Cross browser text shadow
Fixed position footers
Preloading images
Fixing IE overflow problem
Increase the size of click targets
Vertically Center An Element

A word of warning – Using third party plugins is fine if they are coded well. However, use too many and they may conflict causing problems. Use with caution and with a light touch!

Feature: 7 Harsh Truths about running online communities

In ’10 harsh truths about corporate websites’ I highlighted some of the problems I perceive in how companies run their websites. However, many organisations are not content to simply run a website, they want to run an online community too. Read More

Listeners feedback:

Contracts and legal stuff

I went to have a look on the forum for a good question and found this posted by Dave:

I am in the process of sorting out contracts and legal stuff. I came across this article – http://24ways.org/2008/contract-killer – from 24 ways and Andy Clarke and I think it is a fantastic example of a contract which is well written and doesn’t sound too stiff (if you know what I mean). Does anyone else have any examples or tips when writing a contract.

Why have a contract in the first place?

Bearing in mind I have never actually had to refer to one of the hundreds of contracts Headscape has produced in the past seven years, this is a fair question.

The main reason is that it focuses both parties’ minds on the job and what is required to make that job happen. It’s a kind of comfort blanket too knowing that if anything does go wrong, there’s a bunch of stuff in place to help resolve it.

How do we do it?

We split all of our contracts into two separate documents: a ‘Statement of Work’ and ‘Terms and Conditions’.

The Statement of Work is simply a description of the project written in ‘standard’ English. Roughly speaking, it’s a more solid version of the original proposal replacing, for example, ‘We could design X’ with ‘Headscape will design X’. It covers tasks, responsibilities, testing, technologies, project management, timescales, pricing, payment milestones etc. Basically, it is a detailed outline of the project that could be compared to the ‘Schedule’ of some contracts.

We have a standard set of terms and conditions that ideally (from our point of view) just simply refer to the statement of work in question therefore binding our terms and conditions to that particular project.

Our terms and conditions are written using fairly legalistic terms. Though this can sometimes mean that our clients, who may not be versed in legalese, have to take advice on what we’re proposing, I can’t remember a single complaint. I guess what I’m saying is that this appears to be the norm and taking legal advice on any contract, written in plain English or legalese, has got to be a good idea.

I agree that legalese can by irritating. Although I can understand a fair amount of it, it has taken a long time for me to learn even the small amount that I do know.

I once had a lawyer tell me that, when he was attending a class at law school on the subject, the teacher said that legalese existed only to allow lawyers to charge the rates that they do. I think his tongue was in his cheek, but on reflection, this actually makes sense if you view legalese as a kind of legal code that takes years of study to master.

I’m not sure. I guess my only concern in producing a contract using layman’s terms is if it is dismissed in the event of a dispute.

Our terms and conditions include the following:

The date of the contract
Who the contract is between (actual legal entities)
Definition of terms
Obligations
Deliverables
Payment
IPR (who owns what, what they can do with it, and when)
Confidentiality
Liability (often the biggest sticking point)
Default
Termination
Communication
Governing Law (which country’s law applies)
Signatures of the parties (most important!)

It’s not a fight – be prepared to negotiate

It is quite rare that our terms and conditions come back with no amendments. We believe that responsibilities and liability are evenly balanced but often a client’s lawyer will disagree. A cynical person might say that they are looking for issues to justify their fee, but it is possible that a particular point may not be right for some clients.

For example, we include the line “The Contractor shall have the right to incorporate, in a readily viewable location, a credit and hypertext link in the Deliverables.” In other words we can have a ‘Web design by Headscape’ link on the site. Some clients object to this and, if so, don’t make a big deal out of it. Just go with it.

However, there are times when you will think certain amendments or additions to the contract are unfair. Be prepared to stick to your guns but make sure you explain why. If you’re in any doubt, take legal advice.

Some organisations will flatly refuse to sign our terms and conditions and insist that we use theirs. From our point of view this is not ideal because these terms and conditions are usually created for contractors that have absolutely nothing to do with web design. They often talk the physical delivery of deliverables and the like but, experience has suggested to me that these contracts, generally speaking, are all very similar. The only thing that we insist upon in these cases is that the statement of work is referenced in the client’s terms and conditions.

Make sure the damn thing is signed!

Bearing in mind the effort that is put into creating these documents, always make sure that they are signed. This sounds obvious but I have had the odd clients over the years that, to avoid their internal legal team, has given the ok on the documentation but always found an excuse not to sign it.

It’s easy to say ‘well, we’re getting paid’ in these situations but, if things go wrong, you will
not have a leg to stand on.

So, in summary, contracts are good for everyone and worth investing effort in them and make sure you take legal advice if you’re not sure what you’re a client is asking you to agree to.

Three secrets to simplicity

Posted in User experience on March 3, 2009 by Paul Boag

Many website owners damage their sites by continually adding features and content when they should be simplifying. In this post I reveal why that happens and how to simplify your website.

In my post ‘5 options when website budgets get slashed‘ I explained that many organisations waste money adding ever more functionality and content to their sites when they should be simplifying. Unfortunately it is much easier to add content than take it away. But why is that?

The 3 lures of complexity

In ‘10 harsh truths about corporate websites‘ I outlined 3 reasons why website owners shy away from removing content…

A fear of missing something – By putting everything online website owners believe they are giving users easy access to everything they need to know. Unfortunately, with so much available, it is hard to find anything.
A fear users will not understand – Whether it is a lack of confidence in their site or their audience, many website managers feel the need to provide endless instructions to users. Unfortunately, users never read this copy.
A desperate desire to convince – Many website managers are desperate to sell their product or communicate their message. Text becomes bloated with sales copy that actually conveys little valuable information.

However, I think there is more to it than that. First, there is a general laziness. It is easy to leave content online. It takes effort to remove it. Second (and more importantly) there is a desire to please users. If a user asks for a feature or piece of content, we feel obliged to provide it.

3 questions that encourage simplicity

Adding functionality requested by users is not always a good idea. You need to ask 3 questions…

How many people are asking for it? – If only a few people request a piece of functionality, there may not be the demand to justify the time and money.
Who is asking for it? – If it is not being requested by your primary audience then you should probably not be building it.
How will it affect others? – With new functionality comes complexity. Will that functionality confuse some users? Will it distract from your main call to action?

What then do you do if your site has become overly complex? How do you achieve simplicity?

3 steps to achieving simplicity

According to ‘The Laws of Simplicity‘ there are three practical ways you can simplify anything, including your site. These are:

Remove elements
Hide elements
Shrink elements

Let’s look at how these steps work in practice.

1. Remove

Headscape Website

The first step to simplifying your site is removing unnecessary content. This is by far the hardest step for the reasons I have outlined above. However, it is necessary as Steve Krug explains in his book ‘Don’t Make Me Think.’ He identifies two benefits of removing content…

It reduces the noise level of your site
It makes the useful content more prominent

Removing content really does make a difference. We applied these principles to our own website at headscape.co.uk and saw a significant increase in conversions (those visitors who request a quotation for our web design services) and some amazingly positive feedback on the site itself.

In fact we took the principle so much to heart that we went from a 40+ page site down to a single page! Of course, that kind of radical approach is not for every site. However, even removing some content can make a huge difference.

2. Hide

Unfortunately, it is not always possible to remove as much as you wish. Sometimes you need to keep content to serve secondary audiences. That is where hiding content comes in.

It is important to cater for secondary users, but you do not want their content to distract or confuse your main target audience. Instead of removing their content, you can hide it deeper within your site or within the interface itself.

Menu on the Wiltshire Farm Foods website

An example of this is a recent homepage redesign we completed for Wiltshire Farm Foods. Most of their sales come from 6 categories of meals. However, they also offer a number of other categories. On their old homepage the 6 main categories were lost among the other categories. Users felt overwhelmed by choice and sales were lost.

One option would have been to reduce the number of categories to focus on the 6 big sellers. However, this would upset a sizeable secondary audience. So instead, we hid some of the categories under a show more link. This meant that their secondary users could still be served, without overwhelming the primary audience.

3. Shrink

Finally, there are occasions when content can be neither removed or hidden. This is often because the content is of critical importance to a secondary audience and needs to accessed quickly. In such cases the content can be shrunk.

Take for example University websites. Their primary audience is almost always prospective students. However, they also cater for staff and existing students. These people need quick access to intranet tools such as the institutions address book. The solution is to add a small inconspicuous link on the homepage that takes them quickly to this content. By keeping the link small (shrunk) the site serves their needs without distracting or confusing the primary audience.

A similar approach was used on the Wiltshire Farm Foods new homepage. However in this case the content was actually shrunk.

Because of the elderly demographic it was important that we provided lots of help to new users. We therefore wanted to dedicate a substantial amount of homepage real estate to meet their needs as they arrived. Our solution was this…

WFF get started guide

Unfortunately this became distracting once the users were familiar with the site. It became a usability hurdle. One solution was to remove it. However, this would make it impossible for users to refer back to if they became stuck. The next option was to hide the content elsewhere (for example in the help section). However, previous usability studies of this demographic showed they develop ‘habits’ in the way they navigate. If we moved these links that they relied upon, it could prove confusing.

Our final solution was to shrink the content. So instead of moving or removing it we simply collapsed it…

WFF get started guide, collapsed

This meant the content continued to be accessible but did not become a distraction or take up too much real estate.

Conclusion

Although the ideal scenario is to remove content, it is also possible to simplify in other ways.

This should not be mistaken as an excuse to avoid removing content. However, you could use hiding and shrinking as the first step towards removing. If these techniques do not alienate your users, then it maybe appropriate to remove that content entirely.

Whatever the case, we should all be looking for ways to improve our sites by simplifying rather than adding more and more content.

154. Top Ten

Posted in Classic shows on February 25, 2009 by Paul Boag

On this week’s show: Relly Annett-Baker talks about good copywriting, Paul learns how to be a more efficient designer and we look at the ultimate website launch checklist.

Podcast: Download (31.8MB)

Download this show.

Launch our podcast player

Housekeeping

SXSW

Boagworld is doing loads of good stuff surrounding this years SXSW. The full details can be found here. However, the highlights are…

A live Boagworld show on Saturday 14th 6.30PM at the convention centre – With guests: Andy Budd, Daniel Burka, Joe Stump and Jeremy Keith. Please sign up on upcoming or follow via uStream.
The Great British Boozeup on Monday 16th at 7:30PM at Shakespeare’s Pub – An evening of great beer and an all British soundtrack. Again please sign up on upcoming.
Boagworld SXSW coverage – Instead of spamming both twitter and your RSS reader with content from SXSW, we are bring it all together on one handy streaming page.

So whether you are actually attending SXSW or not, hopefully there will be something for everybody.

News and events

The ultimate website launch checklist

Making a website live is a scary process. There is so much that could go wrong. However worse still, there is so much you could forget. When it comes to launching a website, you can’t afford to take chances.

Well, BOX UK has been compiling a website launch checklist that takes some of the risk out of the process. This list includes everything from validating your HTML to announcing the launch on Twitter.

If you are responsible for launching websites, then this post is a good starting point for your own checklist.

Mr Budd is on fire (not literally)

Normally when I write about the news, I focus on specific posts that have appeared over the last week. However, instead I want to draw your attention to Andy Budd.

In case you are one of the three people who haven’t heard of Mr Budd,let me give you a quick summary. Andy is a user experience specialist and founder of ClearLeft – an agency that does a mixture of web design work and training. Andy is also author of CSS Mastery, an excellent book that I highly recommend.

The reason I want to focus on Andy is because he has really started to churn out some superb posts recently. Although an accomplished author and speaker, Andy has written less on his blog over the past year or so. However, in this last week he has released two cracking posts.

The first is entitled "Don’t treat your website like a commodity" and focuses on how we approach the market. It warns against trying to artificially create a need for your site. Instead he suggests shaping your site around user requirements.

The second is entitled "Is your website like a leaky bucket?" and is in many ways a continuation of the previous post. In this one he warns against the mentality of continually driving new users to your site and instead encourages us to focus on retaining the users we already have.

With these kinds of quality post coming from Andy again, now is the time to add him to your RSS reader (if you have not already).

A win for the generalist

I am very much a jack of all trades and master of none. Others have accused me of ‘having enough knowledge to be dangerous’.

In the world of web design, specialists are the order of the day. As a result I am beginning to feel obsolete. However, perhaps that is a false perception.

If like me you are a generalist, then you may draw comfort from ‘Bringing Holistic Awareness to Your Design‘, a post on Boxes and Arrows. In the article they explain that if you want to build websites that score high in user satisfaction, you need a team with a good general understanding. In particular they wrote…

The more each team member understood the business goals, the user needs, and the capabilities and limitations of the IT environment "a holistic view" the more successful the project. In contrast, the more each team member was "siloed" into knowing just their piece of the whole, the less successful the project.

Now, the article does not apply that specialists are wrong. It merely points out that in order to build a successful website you need to see the bigger picture.

It goes on to identify 5 ways that you can ensure your team keeps this broad perspective. They are…

All team members conduct at least some user research
Team members participate in work and task flow workshops
Team members share and discuss information as a team
Team members prioritize information as a team
Team members design together in collaborative workshops

This is certainly something we have begun to take on board at Headscape and we would encourage you to do the same.

Interview: Relly Annett-Baker on Copywriting for the Web

Paul: OK, so joining me today is Relly Annett-Baker who is a copywriter over at poppycopy.co.uk. Hello Relly, how are you?

Relly: Hello, how are you?

Paul: So here we are, on the phone, after a false start.

Relly: I know, it’s good for an internet-based podcasting that we end up using the phone, but there you go. It’s reliable, I like it.

Paul: Yes, all that digital technology, it’s nothing but trouble. Good old analogue.

Relly: Yes, analogue beats everything.

Paul: OK, so we’ve got Relly on the show today to really talk us through some of the kind of fundamentals of copywriting, and copywriting specifically for the web and how we go about doing that. So, Relly, I guess the best thing to do is start with the absolute fundamentals here, and we’ll start by asking you what do you think makes good copy, how do you define good copy?

Relly: Erm, good copy starts with good writing, which sounds, you know, really obvious, but erm, really, unless your spelling and your grammar and your sense is not there, you’re not going to write good copy. So, that’s, you know, the start of it, so if you’re going to write copy, make sure you can write prose well, to begin with. Erm, beyond that, it’s then about… The difference between copy and normal writing is that you’re selling something, essentially, whether it’s a service or, er, an actual product, or, erm, even, you know, just an entire, just an idea. Erm, so, it’s about benefits, rather than specifications. A specification is, you know, what you put into your brochure when someone wants to know whether a dishwasher is going to fit in their kitchen. But, the benefits is much more about the time they’re going to save and be able to spend with their family, using your fantastic, very quick, very efficient dishwasher. Erm, and the other thing that good copy should do, above everything else, is entice a reader to investigate. Especially on the web, your copy has to earn it’s place; it has to earn an extra second of eyeballing, because people just scan on, we get so much information thrown at us, especially on the web, that your copy need to be clear enough that it can be easily understood and also enticing enough that someone wants to stick with you and find out more, rather than flick on to the next thing they can look at.

Paul: Umm. I mean, you talked there about "especially on the web", what do see as being the, kind of, primary differences between writing for the web and any other medium?

Relly: I guess the biggest difference is that print mediums are fixed, that’s why we have different editions of books or magazines that come out, whereas the web is fluid, so, the difference between wikipedia and the Encyclopaedia Britannica, and there are pros and cons for both of those mediums, erm, that they use, but mainly that you can alter things as you go, nothing’s ever sort of set down as "right, that’s what we said and we can never go back and change it". So, erm, the other thing is the web is used primarily for people that skim-read a lot of information and use it to gather information before they decide to go on and request a brochure or find out more about what it is that you’re offering. It’s usually the first point of contact for people looking up, so it needs to make a good first impression, erm, and as such it also needs to communicate what your company is like, what sort of, you know, erm, formalities you have, erm, how big you are, how small you are, and how you like to operate and convey that, er, which print very rarely needs to do, it’s often, by then, erm, when a print brochure comes into someone’s hands, they’re already aware of your brand and they’ve got a better idea of who you are.

Paul: Mmm, I mean, there’s the kind of one issue that often comes up with the differences between the print, er, printed medium and the web, is that, you know, that because people scan, copy on the web should be kept short. I mean, is that something that you would agree with? I know that I’ve seen, you know, some articles written on A List Apart written before, that say "no it’s not about the length of the copy, it’s about how engaging it is". So, I’m quite interested in your opinion on that.

Relly: Yeah, I would very much agree, that it’s much more about, erm, engagement rather than length. Often with print, you get told you have, you know, space for 250 words and that’s how long your copy has to be. With the web, your copy can be as long as it needs to be, but that’s not necessarily as long as you’d like it to be. But as long as you can keep people engaged and keep them with an interest to keep on reading, get more information about you, and then, er, essentially they can read 5000 words about you, but if they don’t press the button at the bottom that says "get in contact" or "ring us" or "do something", then that’s kind of all for naught. What you want is to, erm, your copy to be long enough to persuade someone that they want to take the next step and get in contact with you and make a, you know, make that step towards doing business with you.

Paul: Mmm, I mean you talk, you’ve talked a lot about engagement already, how do you go about engaging people as you write copy? What kind of tricks and techniques are there, or is it probably a lot more complicated than that?

Relly: (laughs) Erm, I wouldn’t say it was the sort of thing where there’s, erm, there’s one way to do it; there are different, different, erm, styles and it really depends on your audience. Erm, often when we think of copy we think directly of advertising, and when we think of advertising we think of billboards. Billboards have, literally, two seconds to engage you and fix a message in your head. So, they have to have a certain amount of shock-value, and that’s usually accompanied by a large image that ties that together. The web is a very different beast in that respect, in that you’re making a one-on-one relationship; you don’t have to talk to everyone in the street, you can concentrate on who you think your best customer is. You do research about you customers and your users, and then you write for them, and you write in a way that’s going to, erm, keep them reading. Erm, so it comes down to a lot of research about who you’re writing for.

Paul: Mmm, that’s really interesting, you talk about writing for a specific person or, er, a specific group of people, because, it sounds then like you guys suffer from the same problem that designers would suffer from, when a client turns around and says ‘our target audience is the general public’, and they won’t narrow it down any. So, er, is it fair to say that you’ve got the same need to prioritize audiences that a designer would have?

Relly: Absolutely, you cannot write something that is going to engage everyone all the time, you have to know who your audience is. Erm, and that often involves doing, you know, research that, erm, the clients themselves don’t necessarily take on as part of the need for copy, but, erm, often the product tells you what sort of copy you need to write. If you’re, erm, writing about a teddy-bear shop, it’s quite obvious that you’re not generally writing for a, sort of, you know, middle-aged, managerial businessman; you’re writing for either, erm, older women who collect them, or younger children and therefore you’re writing for parents. But when you get into services, it gets a bit more complicated and so you have to do more research about the people who make contact currently on the website, if there is an existing website, or, you know, what business they’re going for and who actually makes them, makes that next step, you know, and who predominantly makes up their sales; those are the people you should be writing for. I often say to, erm, to people who are writing, who are starting to write their own copy, to have a style guide and to practice that – try writing a letter to your best customer; obviously, you don’t have to send it, but, you know, as if you were going to address them, face to face, what would you talk about and how would you introduce your product, and what specifically would they be interested in about it. And once you’ve practised writing about your products in that manner, it feels difficult ‘coz it feels like you’re cutting off 50% of your potential audience, but if you can target on, you know, the 10% that make up your actual, erm, sellable audience, then your erm, your returns will be much higher.

Paul: Mmm, very interesting. I like the idea of getting people to practice by writing a letter. I can imagine that works very well. Let’s talk about, umm, some of the common mistakes when it comes to copywriting, ‘coz let’s face it, you know, the majority of websites aren’t, er, produced and written by, you know, er, trained copy-writers, or even (Relly laughs)… they’re either written by, erm, the designer when he gets completely fed up with waiting for content from the client, or it’s written by the website owner. Umm, in either case, you know, they’re not obviously as experienced as you, so I’m interested in some of the really bad mistakes you see coming up again and again.

Relly: Erm, the obvious one is when people take their brochure copy and just move that straight across to their website and say: "that’ll do, that’s perfect, that’s exactly what we want."

Paul: OK, we we always say that, why is that wrong?

Relly: Why is it wrong? Because, erm, your brochure should really be for when people have made contact with you and have an interest in your product. So then you can, you can work on selling them, you can, you can work on, er, getting past any of the objections that they might have, through a longer length of copy when they’re ready to address those issues, when they’ve already seen the positives. So, erm, your website should be… As an example, if you take, erm, say a hotel that’s, erm, setting itself up for events, or weddings, what a bride wants to see when she goes to the website is she obviously wants to see pictures of a lovely wedding, but she wants to know how the day is going to work for her, and why it’s going to be her, you know, perfect day. A bit further along the line, she wants to know how much glass hire is and how much it costs, you know, to have rooms in the hotel and she can be really direct in those. But, initially that first bit of copy needs to be one simple paragraph explaining why your hotel is absolutely perfect for her wedding day, as far as she’s concerned, the biggest day on the planet, and you have to make her feel she’s the most important person. Once she’s, once she feels like she wants to make the contact and book, the brochure can explain in far more detail what the liability insurance is, what the room size is; she needs to have a rough idea of these things, but they don’t need to be laid out for her, then and there.

Paul: Mmm, are there any other mistakes that you see quite a lot?

Relly: Yeah, people don’t revise or keep on top of their copy; so they kind of treat it like it’s been printed, and that’s it, they can’t ever go back and change it, or they feel they can only change it if they also change the design.

Paul: Yeah.

Relly: We’re starting to get past that a little now, erm, companies are getting a bit more used to the idea of blogs, and so they can keep updated in that respect. Erm, other mistakes people often end up writing for their client or their boss, rather than the actual audience, which goes back to, you know, what we were saying before, which is, you know, that’s a difficult one, everyone faces that where, you know, their boss says: "I think it should be like this", and if you know better, that’s, you know, that’s you having to then lay out why I think this works better because. Erm, but don’t, you know, be afraid to make the point that you are writing for the audience, the people that are going to buy and here are their needs and here are their requests, and this is how the copy has addressed that.

Paul: Umm.

Relly: And, I guess the other thing is that, erm, people (laughs), people who, er, don’t write very often, they fall into two categories, erm, especially with designers, this is so true, that designers either did art at school, because they wanted to get out of essay writing (Paul laughs) and therefore they haven’t written anything for a long time, and so they’re a bit rusty and they kind of need to maybe practice a bit before they lay something out and, you know, maybe hand it onto someone else and say: ‘does this make sense to you? Can you, can you read this out of context and understand, you know, where I’m going with it?’ Erm, I often talk about, erm, people using, er, text readers for the same thing; you know, I know they’re used in website design to check, erm, accessibility, that someone, you know is, er, able to have the text read to them and understand what’s going on they should be able to navigate around the website. It goes perfectly well for copy as well, copy is very much part of your navigation: it’s the information you’re imparting to that person. So that’s always a good way that, you know, if someone, if someone can read or be read the copy out of context and they get, you know, 70%, 80% of the idea of what’s going on, then you’re on a, you know, good track that way. Often you find that people, the other thing that happens is that people start writing and they get so excited about the fact that they’re writing, the prose just flows from them, like they were actually Lord Tennyson reincarnate (Paul laughs) and they come to the end and they’ve built up to a massive, dramatic conclusion (Paul laughs) about why their product is the best thing since sliced bread and actually that dramatic conclusion generally needs to be the opening statement, because it’s what catches hold of people and gets them to read onwards.

Paul: I mean is, I’m fascinated by this whole area of kind of trying to create a tone in your copy, er, because I’m not a copywriter, I write quite a lot, but in the sense of blog posts and things like that and so, whenever I’m writing, I’m writing in my own voice, if that makes sense. But, obviously when you’re writing for another site, when you’re trying to reach a very specific audience, when you’re writing within that tone of the website, that’s a very different kettle of fish and I’m interested in how you do that, how you go about setting a tone; how you go about sticking to a tone, you know, how do you do it? (laughs)

Relly: Ah, the creation of a style guide is very, that’s probably most important here. There are two things that I recommend when, umm, coming up with the, sort of the voice, the tone for a site, is to think about the persona of who that person is that’s writing, that’s especially true if you have multiple people who are writing as the same person, erm, often you find this now with companies that have begun to use Twitter streams and so on to communicate stuff and they they need to remain the same person, the, erm, NASA rockets do that very well, Discovery and the rest of them, they they’re able to communicate very well, both scientific facts and just, you know, prosaic information about the fact they’re bored of sitting on landing pads, launching pads and things like that and it’s quite nice because it’s able to communicate a human voice to something that essentially is a very complicated machine, erm, and the way that they’ve done that is to think: "well, if I, you know, it I was going to be a person talking about these experiences, what would I say?" and sometimes, you know, the most complicated, fascinating machine on earth, saying the most mundane things communicates more about their team that it could do than take a very long, scientific specification of what they were doing. So, it’s again going back to understanding your audience. NASA have understood that their audience on Twitter, they’re not space buffs, they’re people who are gererally interested, because most human beings are interested when a rocket goes up to space, it’s, you know, it’s an amazing thing, it doesn’t matter if you’re 6 years old, or 36 years old, it still seems, you know, astounding, that it happens. So, they’ve gone back and they’ve thought about, you know, how can we communicate to people every day and they treat the rockets as if they’re just people hanging around doing their jobs. just like everyone else uses Twitter. So, the first step is to understand your audience, and it takes a certain amount of, erm, it is quite cool to say but dissection, it is cutting out the people that you don’t want to talk to; people often know who their customers aren’t, even if they can’t quite focus on who their customers are and who their customers are becomes clearer with more and more research. Erm, a lot of what a copywriter does as research, right at the beginning, crosses over with information architecture, it’s a lot of looking at, erm, how best can we communicate these points and who really needs to know them and in what order? So you kind of, you go back and you assess, so this company is, erm, is selling er… they might be selling, we used dishwashers and washing machines earlier, so who’s the primary researcher and purchaser? It’s probably going to be, erm, it’s split probably 50-50 between female and male, as for the initial research, but they’re probably going to be above the age of 24, averagely; they’re probably going to own their own home and they might well have children and that gives you the sort of insight to the sort of family life that they have and what they, therefore, want to get out of that product. Erm, so then it’s erm, then it’s a case of looking at, I often go back then to erm, manufacturers, look how manufacturers’ websites work, how they describe their own products; what sort of visual advertising they’ve used to communicate these things and how that can be translated into words, what benefit are they selling with the visuals, often if I’ve been supplied visuals for the website, they can tie in together quite well. And then I create a persona, the person that is writing, you know, being the person who is writing for the website. So sometimes I’m a middle-aged man, sometimes I’m a teenage girl, sometimes, you know, I’m a cool, skating dude, it really, you know, it really depends on what, erm, angle I’m going for

Paul: Sure.

Relly: With the copy. I keep a swipe file, which is basically things that I take from magazines, from newspapers, from other advertising literature, from books, from articles, that I think has been written really well and I take it away and I say, I kind of take it apart and say: "what about that headline functions so well?" and "what about, what is it about this piece that talks so well to the audience that it’s that it’s going for?" that, erm, that’s especially good if, even if you’re not the target audience and you’re still engaged enough to read it; that’s, you know, often quite fascinating. One of my favourite places to, erm, take, er, hints and tips from, of all places, is the Daily Mail and the Sun (Paul laughs), believe it or not, because they are so good at putting across an emotive idea in very few words, there is nothing like a Sun headline for giving you a kick in the pants, for feeling, you know, and often you read it and you find yourself, erm, agreeing with the statement, out of hand, before you pull yourself back and go: "now hang on, no, hang on this is the Sun, I’m going to read this story first before I make up my own mind." (Paul chuckles) But, you know, they’re very good at doing that, and, erm, I mean it’s not ideal for everyone’s website, obviously, but to have the ability to do that, to take just a few words and make an emotive statement is really useful in copy, because what you want people to do, more than anything else, is feel that they must do something about getting hold of your product, they must find out more, they must buy it then and there, they must, you know, whatever is appropriate, you know, you’re not going to find many people who are going to one-click buy a conservatory so that’s not necessarily, you know, going to work so well, but you might well be able to get them to arrange to have someone to come round and measure for a conservatory and that’s the next step to getting them to do what you want them to do. Copy is all about behavioural management, essentially.

Paul: Yeah. I mean, it’s got a lot in common with design, you know. As I hear you talk, there’s so much overlap. I mean, but what’s so fascinating is that, you know, a client will spend a fortune on design and they will spend a lot of time and effort and forever express an opinion over look and feel and design, yet they don’t seem to want to invest money in writing good copy and they’ll say things like, you know: "content is king", yet they, there is this perception, I don’t know, is it a perception that they can do it themselves? Why isn’t it? Why is it so hard?

Relly: I don’t know. We, we poor copywriters, we are the Cinderella’s stepsisters of the web design world. Er, it’s especially true in web design, more than anywhere else that I’ve seen, erm, probably because the medium is that much newer, that, and it sprung out of interactivity, as opposed to, erm, books are about staid reading and advertising sprung from that; television and radio sit somewhere in the middle, but essentially it’s a written script, sometimes with pictures added. The web is a different medium altogether, it’s much more about doing, interacting and as more and more social media stuff springs up, you know, that’s more and more true and don’t get me started on the amount of companies that have got terrible facebook pages and so on. Erm, but again, it is that belief that it can be done by yourself; that’s not necessarily, you know, not true, you know, people can write their own copy, in the same way I can design a website – it might look like a dog’s dinner when I’m done, but I can do it. It depends, I can, I can start off, to turn it around, I know enough, I have enough of a little, you know, little amount of dangerous knowledge, to be able to put a blog up, design my own blog header in Photoshop and upload it and be able to update my blog day to day, but that doesn’t mean to say that I’m necessarily ready to design a site for a, you know, big multinational company that wants to sell direct from its website to multiple places around the world. The same goes with, erm, with copywriters. I think partly the reason that we get so little investment put in at the beginning of projects is that, erm, we’ve come to see creating a website as a visual thing, clients very often ask about how a site looks and they don’t care so much about how it works underneath, providing it works, which is the equivalent of asking a baker to bake an amazing cake and you get it delivered and it’s four tiers and it looks fantastic and it’s got these, you know, subtly crafted sugar-craft dancers on top and flowers trailing all around it and you cut it in half and it’s sawdust. And, you know, the copy very much does come under the sawdust category, we kind of get a bit left behind because everyone can write a bit and it doesn’t take that much, erm, knowledge to at least lay out something that makes sense, erm, I think it does kind of get neglected; erm, I often sort of say to people that, you know, that the copy is as much part of the navigation and the function of the site as anything you do with the menu buttons or whatever else, erm, and what we really need to do is to have designers… there are some designers who have the attitude that whatever happens after sign-off is no longer their concern, so the amount of sales that happen, whatever else, that’s not their problem, they’ve done their bit, they’ve designed a site, it works and it goes out. Whereas, really what we, what you’re then doing is designing for your client, erm, a very pretty picture-book of all their products, but that’s not necessarily a sales tool, so we need to look now much more at, erm, at websites as sales tools for companies and to people, you know.

Paul: So, I mean, where’s the line here, mind, because, umm, you know, I can imagine website owners sitting listening to this now going: "well, I mean she seems to be suggesting that we get a copywriter to write absolutely everything on our site", umm, but, you know, when you get into the realms of, you know, corporate blogs and things like that, I mean it’s going to cost a fortune, is it not, to get a copywriter involved at every stage. Where should a copywriter be involved, where shouldn’t they be involved, how do they fit in to the process?

Relly: Right, that’s a really good question. I don’t believe for one minute that you need to have, unless you have a site that need constant updating, you don’t need to have a content editor on-site all the time; in the same way that you don’t need to have a website designer on-site all the time, unless your website is constantly evolving. If you have a web team and your content changes a lot, then you might well want to think about getting a content editor in.

Paul: OK.

Relly: If you run an online shop and you change a few products a week, and you might introduce a few new products, er, via an email marketing, whatever, you might want to consider how much of that you want to give to a copywriter. If you’re updating a company blog and you’re sending, occasionally send out, erm, emails to old clients and invitations to new clients, you probably don’t need to get a copywriter, unless you feel it’s a better use of your time, and I think that it is the division a lot of the time, is that if you’re, if something really needs to sell, if it needs to make an impact, erm, I guess you wouldn’t find an advertising agency going ahead and taking on a billboard campaign, without getting a copywriter in, or their own in-house copywriter; it’s not going to be the managing director going: "well, we’ve got the artist to do this fantastic picture and we’ve bought all the advertising space, we’ve got a whole campaign rolled out, so I’d better think what we’re going to put on the, er, on the advert then." It just doesn’t work like that and that’s exactly, that should be exactly the same with your website. If you’re looking to launch a new campaign, if you’re selling something specifically, if it’s going to make a big difference to the way your company’s going to go, you want to get professionals in, and in this case it would probably be a copywriter would be the professional that you require. Erm, you know, you probably wouldn’t want to go and fiddle with your own plumbing, unless you have a very deep interest in DIY. It’s the same thing. Erm, but on the flipside of that, is that it’s, copywriting isn’t some arcane art that people can’t learn, in the same way that most people started learning web-design by sitting down in front of a computer, you know, bashing something out in Frontpage and going: "well, that kind of works", and then four years later cringing at what they’ve done. I think it’s very much the same for me, when I started writing copy and content, I was a radio producer and I have been responsible for some the worst chart hits in history (Paul laughs), you know, ascending to the chart because of the copy that I wrote, you know, to persuade people to buy the singles, you know, the competitions that we came up with, you know; it was my job, it paid my bills, buy I can’t say, you know, getting the cheeky girls to number 1 is my proudest achievement.

Paul: Oh dear.

Relly: And I was at least partly responsible for that (Paul laughs). I have to take my part in history on that one. Erm, you know, again it’s that thing, you know, anyone can go back and do it if they want to learn, you know, how to write copy. Just be aware that your first few attempts probably want someone to look through, but don’t be disheartened if you get to the end of it and think: "that’s not really what I wanted." You can always go halfway with a copywriter; I run workshops where I go into companies, talk to them about what their needs are, help them come up with a style guide, so they can say: ‘we’re going to write, it’s going from really simple stuff, like we’re going to have abbreviations and we’re not going to us the Oxford comma (Paul laughs), if that’s of any interest to any of you punctuation geeks out there, erm, right through to these are the sorts of people we’re addressing, these are there interests so we’re going to work these into this piece of copy, and, you know, I can then work with your staff members who will continue to write and then you’ve got, you know, a trained battalion of copywriters in-house ready to write things for you, on your behalf. And that’s often, you know, I often say to people that it’s not impossible to write copy, it just takes time to do it. As with anything else, it takes time to code a website well, properly and so that you can make a job out of it, it’s exactly the same with copywriting, but nothing stops you from building those skills up as you go.

Paul: That’s brilliant. That’s absolutely brilliant. It’s really good to hear a copywriter’s perspective on all of this stuff, because I don’t feel there’s enough really said about that part of the website and it’s been great to have you in on the show, Relly, and I really appreciate you taking the time.

Relly: Thank you very much.

Paul: So, thank you very much.

Relly: Thank you.

Thanks goes to Simon Douglas for transcribing this interview.

Listeners feedback:

Being a more efficient designer

Adam from Wales has written in with an interesting question:

Adam: With the economy tanking and client’s squeezing budget, can you give us any tips about being more efficient so we can turn around projects quicker.

It is a good question and one that got me thinking about creativity and its relationship with productivity. I also thought a lot about myself and how I work. All of this eventually led to…

10 Tips for Efficient Design

10 tips for efficient design

Posted in Design, Mobile on February 19, 2009 by Paul Boag

Being a good designer is not always enough to survive hard economic times. You need to be efficient too.

I don’t want this to be another ‘recession’ post. Sure, being more efficient in the way we work as web designers, makes us more competitive and keeps us employed. However, that is not the only reason we should endeavour to ‘work smarter’.

Working as efficiently as possible brings other benefits too…

More time – The faster you can turn around work, the more time you have for personal projects, family and friends. I don’t know about you but this is a major motivator for me.
Better promotion prospects – It takes more than good design skills to be promoted. You need to demonstrate that you are proactive and efficient in the way you work. Management will value you more if you generate a higher return.
Increased profit – If you are a freelancer it is all about maximising profit. The smarter you work, the more money you earn. It’s that simple.

So how can you be more efficient and begin to work smarter? Here are 10 tips that will get you started.

1. Use snippets

Let’s start with the obvious technical stuff. First make sure you have a library of code snippets that can be easily reused. These could include Eric Meyers CSS Reset or your own code for dealing with common HTML content such as news listings or pagination.

These libraries of snippets provide two benefits. First, they save a lot of typing. However more importantly, they ensure consistency across projects. Because you are using the same code for each project, all of the IDs, classes and structure remain consistent. This will save a lot of time when trying to remember why you built something in a certain way or how it works.

2. Use a Javascript library

In a similar vein to snippets I would highly recommend you adopt a Javascript library. Personally, I am a huge fan of jQuery because it is designed for those familiar with CSS. It is also amazingly easy to learn and very lightweight.

Using a library like jQuery has proved a massive time saver for me. It has allowed me to avoid endlessly battling with browser inconsistencies (at least in Javascript!) and avoid reinventing the wheel.

jQuery (like most Javascript libraries) also supports a large number of plug-ins produced by third parties. These too can be a massive time saver. However, a word of warning – be careful using a plug-in you do not fully understand. The quality of plug-ins varies massively and if you discover a problem with one, you can waste many hours trying to fix it, if you do not understand how it works.

3. Configure your tools properly

Often in our haste to ‘get on with a project’ we fail to take the time to prepare properly. One example is in how our software is configured. We settle for working with tools ‘out of the box’ when some minor modifications could improve our efficiency.

Photoshop is a good example of this. It has all kinds of configuration options from keyboard shortcuts to palette layout. Take a few moments to set these up for your workflow, and you could save hours of unnecessary clicking over the long run.

Look at whatever tools you use to build websites and consider how their interface can be tweaked to your needs.

4. Have one system for tasks

For fear of reinforcing a stereotype, designers tend not to be the most organised people. Not only do we need to organise the structure of our software tools, we also need to do the same for our projects.

Fortunately, not all of us have to manage entire projects. However, we do all have tasks that need completing. How we organise those tasks can dramatically affect our efficiency.

A common mistake with task management is to have tasks spread across multiple places. Some tasks exist as emails, some in a todo list, still more in a notebook or on your mobile phone. The result is that things get overlooked.

In order to efficiently manage your tasks they need to be gathered into a single central location. For me that is a task organiser called Omnifocus, which syncs between my desktop and iPhone.

Tasks are still collected using multiple methods. However, once a day I transfer them to Omnifocus. If I attend a meeting and take physical notes that include tasks, I put the notebook into my in-tray until I can add the tasks to Omnifocus. If I receive an email with a task, I drag that email into Omnifocus. Ultimately everything ends up in Omnifocus.

By being this regimented about the way I organise tasks, I ensure nothing ever gets missed. I also avoid wasting time trying to track down the details of a task I have lost.

5. Embrace and manage admin

Part of the problem we face is that answering email and organising tasks feels like a waste of time. Its not ‘proper work’. This is especially true when the pressure is on and deadlines are tight. We arrive at work in the morning and launch into our projects without checking our task list. The result is that we prioritise the wrong work and miss deadlines.

I begin each day by doing two things. I answer and file all my emails (I always achieve inbox zero). I then review all of my tasks and identify the ones that I wish to complete that day.

However, I don’t stop there. I have designated admin time. Once I am done my morning review I close my tasks and email until lunchtime. I focus solely on work and avoid admin entirely. This prevents email and other admin from interrupting the flow of my production work. It keeps me focused.

6. Distractions must die

Of course it is not just email that distract us from work. There is instant messaging, Twitter, Facebook, RSS and… lets face it… the entire internet!

Don’t misunderstand me, some distraction is good. I have a very short attention span and so if I work on a single thing for more than about 30-40 minutes I start to ‘zone out’. However, there is a difference between ‘having a break from work’ and ‘getting distracted’.

Every 40 minutes or so I will take a 5 minute break and fire up Tweetdeck or Google reader. What I try to avoid is keeping these applications permanently open (although with twitter I have to confess I often fail).

By leaving an application open that can distract you with notifications (‘You have a new tweet’, ‘You have mail’, etc.), you risk it interrupting your flow of work. These constant micro-interruptions make it hard to ‘get into the zone’.

7. Keep a tidy environment

Distractions extend beyond your PC as well. Your work environment can also have an impact on efficiently.

If you work from home, endeavour to keep your personal and work life separate. Ensure you can close the door on the rest of the house and that the rest of the family know not to interrupt. Also if possible, try to keep your working area separate from the rest of the house. A garage or loft are ideal. I used to work in a small room directly between our lounge and kitchen. It was impossible to focus on anything with the constant noise from the two rooms.

Pay attention to your desk as well. Keep it clean and uncluttered. This reduces distractions but also creates a better mental state conducive to work. Ensure your physical files and disks are easy to find. Knowing you took some notes that are in a notebook somewhere does not make them easy to find. This is especially true when your desk is three feet deep under paper work!

Personally I scan what notes and physical paper I can. What I have to keep in physical form, I file in a single filing cabinet organised alphabetically.

8. Avoid multi tasking

There is a myth that multi tasking makes you more efficient – it doesn’t! As designers we like to ‘flit’ from one thing to another. However, ultimately this is damaging to productivity. We need to learn to focus on a single task and follow it through to completion.

As I have already said, I find it hard to focus for any length of time. In order to help me focus I break my tasks down into smaller ones. That way I rarely have to do one thing for too long. Take this post for example. To write the whole thing from beginning to end would take a couple of hours. That is longer than I could focus for. So, in order to stop me getting distracted and jumping onto another task, I break it down. This post was made up of three tasks…

Once I complete one task, I switch to another project for a while. Once I have completed a task on that project I may switch back to this post.

Although this is a kind of multi-tasking, it is more structured and ensures I spend as long as my attention allows on each project. I do not simply drift between projects.

Depending on your character this might be too extremely. You may find it easy to concentrate for extended periods. However, if you struggle to concentrate, do not use multi-tasks as an excuse to be distracted.

9. Don’t do excessive hours

Another widely held myth of productivity is that the longer you work, the more you get done. After all, on face value this makes sense. However, I sincerely believe this is not true, especially if your job relies on you generating ideas and being creative.

Obviously we have to put the hours in, if we want to pay the bills. However, do not allow your boss or clients to force you into excessive hours. The occasional all-nighter is one thing, regular 12 hour days is another.

It is incredibly easy to get burnt out as a web designer. You are expected to continually be creative, as well as keeping up with one of the fasting moving sectors on the planet. Things are continually changing and evolving and it is a struggle to stay current.

Working long hours damages your capability to take on board new information and cripples creative thinking. Ensure you limit your hours and book regular holidays. Do not push yourself too hard or you will fail to deliver.

Finally, accept your natural cycle. When you are ‘in the zone’ work every hour God gives you. However, you must also accept that sometimes you need to just stop and rest. Don’t feel guilty about the days when you hardly do anything.

10. Communicate better

I would like to end this post with possibly the best efficiency tip of all – If you want to avoid wasting time, learn to communicate better.

So much of our time is wasted because of miscommunication and misunderstanding. How many times have you had to redo a design because you misunderstood the client or showed them work too late in the process.

Take the time to really engage with the client and understand their requirements. Make sure that you include them in the design process and show them work often and early.

Finally, use tools such as gallery sites, mood boards and sketches to ensure everybody has the same understanding and is working towards the same goal.

By effectively communicating with clients, you can potentially save days on each project that would have been wasted on reworks and amendments.

If you recognise that the mobile web is important and you need help deciding on a strategy, then book a mobile consultancy clinic.

Book a consultancy clinic or contact Rob about a more in-depth review.

153. Harsh

Posted in Classic shows on February 18, 2009 by Paul Boag

On this week’s show: 10 harsh truths about your corporate website, Ryan reviews FreeAgent and Paul highlights the differences between print and the web.

Podcast: Download (20.3MB)

Download this show.

Launch our podcast player

Watch the behind the scenes video

Housekeeping

Consultancy Clinic

I wanted to followup on the consultancy clinic idea I mentioned a few episodes ago.

As you may remember I was toying with the idea of doing one-to-one chargeable skype calls for those who want my advice. I get so many people asking for help that I am unable to answer them all. After all, I have to work for a living!

A consultancy clinic would allow me to help people with their web strategy, while at the same time keeping the Headscape directors happy! Instead of having to commission a full blown consultancy project, you can just have a chat with me on a pay-as-you-go basis.

Anyway, the reason I bring it up again is because I have decided to go for the idea. I have launched a consultancy clinic website, where you can get more information and book an appointment.

However as well as wanting to pimp the service, I also wanted to mention the site itself. I decided to use this as a test case for the graded browser support I wrote about recently. I have therefore written a blog post outlining the approach I used on this site and how it worked in practice.

Even if you are not interested in the consultancy clinic, you maybe interested in how the site was built.

FreeAgent Discount

The guys over at FreeAgent are offering a 25% discount to all boagworld listeners until the end of Febuary. Just enter the code newfac when subscribing and the discount will apply for 6 months. Find a review of FreeAgent later in the show.

News and events

Feature fatigue

This week Gerry McGovern writes about what he calls the ‘Hidden power of content‘. In fact it is mainly a commentary on a Time Magazine column about buying habits.

You maybe wondering why I mention it here? Well for two reasons.

First, it is an interesting post for those of you who run ecommerce sites. It talks about how your product copy needs to focus on more than features, if you want to encourage long term satisfaction in your customers.

Second, he writes about the idea of feature fatigue. This is very relevant to all website owners and something I touched on recently in my post ‘5 options when website budgets get slashed‘.

We love to add more and more features to our websites, but that is not always the right decision. Users have become overwhelmed with features and are looking instead for simplicity and ease of use.

Read the post for yourself and ask how it applies to your site.

Striking font stacks

I am increasingly excited by typography on the web. Not because of the possibility of font embedding or techniques like sIFR. No, what really excites me is the work being done right now using font stacks.

The beauty of font stacks is that even if a user doesn’t have your preferred font, it can still display an alternative.

A lot of designers have been working hard to help us squeeze the most from the fonts installed on our machines. Huge amounts of research has been done on common fonts, as well as the best stack combinations. The trouble is this information is spread all over the web.

However, this week Paul discovered an excellent post that brings all of this research and best practice together. ‘Striking web sites with font stacks that inspire‘ is a great post that not only lists the latest thinking on font stacks, it also provides some incredibly inspiring examples of them in use.

If you are looking to become a great designer then understanding font stacks is essential. This post is an excellent place to start.

Tips for improving your HTML and content

Our final featured post this week is ‘5 Top Tips to Beautify Your HTML and Enrich Your Content‘ by Mike Brown over at Sitepoint.

HTML is a deceptive language. On the surface it is amazingly simple and anybody can be writing HTML in a few minutes. However, the longer you work with it the more you discover the variety of ways in which it can be implemented – some good, some bad.

This post shares some very basic best practice for working with HTML. Advice includes:

Using short URLs
Being consistent in your markup
Minimize uses of class and id attributes
Add title attributes and other metadata to enrich content
Use comments and whitespace to help readability and ease maintenance

All basic stuff but ideal for beginners and a useful reminder when the rest of us get sloppy.

Feature: 10 Harsh Truths About Corporate Websites

We all make mistakes running our websites. However the nature of those mistakes varies depending on the size of your website. As your site and organisation grow, the mistakes begin to change. This post addresses common mistakes in larger organisations. Read More

Listeners feedback:

Review: FreeAgent

Way back in show 131, Stanton and myself answered a listeners question about project management and invoicing applications, and I mentioned FreeAgent in my line up of apps that I thought you listeners would be interested in.

I’m now going to discuss the app in more detail, as I’ve been really getting into it and using it to it’s full potential.

FreeAgent is a fully featured online accounting tool wrapped in a sleek, comprehensive and easy to use interface. It’s aimed at Sole Traders, Partnerships and Limited Companys, they offer a free 30 day trial to get you started and after that there’s a price plan ranging from £15 – £25 a month at the time of recording this review.

I’m a simple code monkey and the thought of managing my taxes and invoices sends shivers down my spine. So I love that FreeAgent just takes me by the hand and guides me through the whole process.

Accounting is project based, which doesn’t suite everyone, but that really depends on your personal preference.

You simply start off by creating a client, then you assign a project to that client, you add timeslips to the project and using your hourly rate FreeAgent tells you what you’ve earned and what you owe the tax man and the whole thing is pretty much that simple.

As I’ve said it’s fully featured, you can create invoices, manage expenses and mileage, upload and analyze your bank statements, create a login for your accountant, view real time profit and loss reports the list goes on and the guys are constant adding new stuff.

Even if you decide you don’t like using FreeAgent after you’ve signed up you have the option to export your data at any time and try something else, so there’s no fear of loosing anything.

This week sees the launch of a redesign to freeagentcentral.com and the FreeAgent app itself and I’ve been one of th
e luck ones to get a sneak peek behind the scenes and I can tell you that the guys have been putting a lot of effort into improving the general interface based on user feedback. They’ve refreshed the colour scheme to make things easier on the eye for long term use and restructured some of the navigation to make moving from projects, time tracking and invoicing much more intuitive.

In my opinion it’s definitely worth a look so if you want to know more about FreeAgent head over to freeagentcentral.com, watch the 2 minutes video introduction and take the tour. They’ve even got a number of demo’s so you can go in and play with the app before you sign up. Even more incentive to have a look would be the 25% discount the guys are offering to all boagworld listeners, just enter the code ‘newfac‘ when signing up for a free trial and the discount will last for 6 months once you subscribe.

The difference between print and web

Jake Knight asks a brilliant question, that I am amazed we have yet to address on the show.

Jake Knight: What are 5 things you would want any print graphic designer to know first and foremost about designing for the web?

So it is a top 5 list you want? You have been reading too much Smashing Magazine! Okay here goes – The top 5 things every print designer needs to know about the web…

Let go of pixel control – One of the hardest things for print designers (and marketeers for that matter) to accept that you do not have pixel perfect control on the web. Different browsers, resolutions, monitors, operating systems and video cards all alter the way your site is displayed. Add to this the users ability to change font sizes, colours and browser dimensions, and it becomes impossible to have the control you get in print.

Don’t be afraid of the code – Many print designers shy away from coding HTML. They rely instead on a ‘techie’ to handle this side of things. That is a mistake. To really get to grips with the web you need to understand how it works. HTML/CCS/Javascript all shape and influence design (for better or worse). Also, it really isn’t that hard. HTML in particular is a very simple language.

Web Typography is not so bad – Okay so you haven’t got the freedom of print, but typography on the web can be just as creative. By using font stacks, line spacing, and kerning you can create truly gorgeous typography. Also when you just have to have a particular font, there are techniques such as image replacement and sIFR. If you are a typography bluff and want to discover what is possible, check out Richard Rutter’s blog.

It is an interactive environment – One of the most common mistakes of print designers is to focus on aesthetics and forget usability. The web is interactive and web design has more in common with signage design than brochure design. Your job is to help users complete tasks, not just to produce attractive design.

Your skills are transferable – Everybody goes on so much about the differences between print and the web. It is easy to get demoralised and conclude you could never make the switch. However, in reality most of your skills are transferable. Layout, colour theory, typography and composition are just some of things that are universal no matter what the medium.

So there you go Jake, 5 nuggets of advice for anybody considering moving into the web from print.

Our First AIR App

Posted in Development on February 13, 2009 by Paul Boag

With Adobe AIR now up to 100 million downloads, being utilised by big name players such as the BBC and increasingly invading our desktop Headscape decided to give it a go.

This is a guest post by two of the Headscape developers – Craig Rowe and Dave McDermid

Setting up

Adobe Air is Flash + WebKit + SQL Lite on the desktop. As a Flash developer you can dive right in and use the Air extension for Flash to publish your beautifully crafted swfs and AS code into an installable cross platform desktop app. However, the flash projector has been around for a while doing similar things and we wanted to put our hard earned web development skills to productive use. So we went the HTML/Javascript route.

The SDK is free for download but Aptana provides a rather neat eclipse based IDE in which to work. Handily the new project wizard allows you to import a multitude of Javascript libraries making it incredibly easy to get a new project up and running with your preferred initial setup (we went for jQuery).

The Problem

To make the exercise worth while we needed a real world problem to solve. Trivial examples usually do very little other than increase your ability to copy/paste example code and do your best fireworks night ‘ooo’ ‘ahh’ impression at it. Instead, we chose to add to our server admin experience…

As loving, caring web developers we actively monitor all our servers, and most of our live websites. For a while this was a DOS script, this was then migrated to a Bash script on a Cron job. It worked great, but required a computer science degree to maintain. So here was our problem: we needed a pretty, maintainable and reliable app to monitor websites. All it had to do was let us know when one disappears or throws a nasty error.

Download and try our site watcher AIR application

The Journey

Step 1: The wireframe

A new Adobe AIR project in Aptana comes with an html file named after your application which acts as your main program window. Creating a basic layout with a few buttons, titles etc can be done in a snap. The html, css and javascript are dealt with in exactly the same way as if intended to be deployed as a website (with no browser compatibility worries as we are only targeting the Adobe AIR WebKit rendering engine).

Step 2: The magic

The wireframe identified the main viewer as comprising of an unordered list of sites, each with their current status and edit/check/remove links. This list needed to be persisted, but editable by the user.

If this was a website we may be looking to server side scripting and a database of some nature. However, we had only jQuery and the air libraries. Although SQL Lite was an option we decided it was an over complication for what is a relatively simple, first AIR app. So, knowing that we could use jQuery to manipulate a DOM and the air libraries to save and open local files we opted for XML as a data source.


<?xml version="1.0" encoding="utf-8"?>
<sites>
<site address="http://www.headscape.co.uk/" status="200" frequency="30">
Headscape&#146;s website
</site>
...
</sites>

Looking back into our application html file we can see that we are given a readLocalfile() function that returns the string contents. This can then be passed into a jQuery object and manipulated in the usual way.

[The canny among you will notice that this readLocalfile() function is merely a few calls to the flash filesystem classes (using the AIR aliases). In fact at some points I directly call the flash library rather than using the AIR alias. There’s no functional difference, I’m just used to the flash namespaces]

With this ability added to the jquery ajax capabilities the application flow could be easily envisaged as follows:

On DOM Ready read the local xml file
For each site element in the xml create an LI element with the appropriate display and action elements
Fire off a jquery ajax call for each site
Use the response code to formulate a class for the LI to change its display
Fire off any notifications if the response code has changed i.e. e-mail, notification window, twitter post
Set a timeout before checking again
On window close parse the unordered list back into xml and write it to the persistent file

The Stumbling Blocks

Viewing the source of an installed AIR app can be done by nipping into program files (or Applications for the MACs amongst us) and looking in the application name directory. Here you will see the html, css and javascript files that make up the app (so we can continue to learn from others deployments just as we would with a website).

A brief look at the sitewatcher source and the flow described above becomes immediately clear. ‘Sitewatcher.html’ is our main form and it includes script.js as the main driver of the application with the #sites ul as the main containing element. The rest is GUI. ‘PopulateUIfromXML()’ directly completes steps 1-2 and fires off the 3-6 process via ‘CheckSite()’. However dispersed within this are the unusual non-front end website development bits, so we’ll look at those now:

Acting as a System Tray App

Many AIR apps, particularly those to do with notification (twitter, yammer etc) seem to want to run as system tray applications, we were no different.

The process of doing so is relatively easy, and encapsulated in the appropriately named SetUpSysTray() function of script.js. Essentially what we need to achieve is an override of the minimise behaviour, the setting of an appropriate icon and the associated window toggling behaviour.

Window.nativeWindow gives us access to the OS window holding our html window, and we can listen to events on it in much the same way. ‘nwMinimized’ is set to fire on display state changing and, if being minimized, instead docks (hides) the window and prevents the default behaviour.


if(air.NativeApplication.supportsSystemTrayIcon)
window.nativeWindow.addEventListener(runtime.flash.events.NativeWindowDisplayStateEvent.DISPLAY_STATE_CHANGING, nwMinimized);
function nwMinimized(nativeWindowDisplayStateEvent) {
if(nativeWindowDisplayStateEvent.afterDisplayState == runtime.flash.display.NativeWindowDisplayState.MINIMIZED) {
nativeWindowDisplayStateEvent.preventDefault();
Dock();
}
}
function Dock() {
window.nativeWindow.visible = !window.nativeWindow.visible;
}

This works fine but on its own will actually just hide the window from view/the taskbar leading the user to have to use task manager to close it. To ensure that an icon for your application sits in the system tray we need to set an icon for the nativeApplication (the mere presence of which will cause windows to display the app in the systray).

Back to SetUpSysTray() and we’re using a content loader to load the icon graphic into memory, with an iconLoadComplete handler waiting to do the work:


var iconLoader = new runtime.flash.display.Loader();
iconLoader.contentLoaderInfo.addEventListener(air.Event.COMPLETE, iconLoadComplete);
iconLoader.load(new air.URLRequest("../icons/AIRApp_16.png"));
function iconLoadComplete(event){
if(air.NativeApplication.supportsSystemTrayIcon){
air.NativeApplication.nativeApplication.icon.bitmaps = new Array(event.target.content.bitmapData);
air.NativeApplication.nativeApplication.icon.tooltip = "SiteWatcher";
air.NativeApplication.nativeApplication.icon.menu = new air.NativeMenu();
// Create Menu Items
var openCommand = new air.NativeMenuItem("Toggle");
openCommand.addEventListener(air.Event.SELECT,function(event){
Dock();
});
var sep = new air.NativeMenuItem("", true);
var exitCommand = new air.NativeMenuItem("Exit");
exitCommand.addEventListener(air.Event.SELECT,function(event){
air.NativeApplication.nativeApplication.exit();
});
// Add Items to menu
air.NativeApplication.nativeApplication.icon.menu.addItem(openCommand);
air.NativeApplication.nativeApplication.icon.menu.addItem(sep);
air.NativeApplication.nativeApplication.icon.menu.addItem(exitCommand);
}
}

We simply set the native application icon to be the bitmap data before finalising the sys tray setup by creating a menu to appear on click.

Note for MACs: The minimised event listener is not applied if the system does not support system tray icons. This is to avoid confusion on MACs where a minimise goes to the MAC dock anyway.

Notification Windows

So the app can now run in the system tray and use jQuery to check the sites listed in an XML file at regular intervals. However we need a process of notification. The App could be running on an actively used machine in which case we want messenger style pop-ups. Or it could be running on a separate machine/server from where we want it to send e-mail/other notifications.

In the case of window notifications we took a short cut and used some example code from Adobe Developer Center. This is encapsulated within the DisplayManager.js and Message.js files. Display Manager acts as a queue, dequeuing and displaying on a timed basis if the user is present. This is an important requirement as you do not want a user missing a notification prompt merely because they were away from their desk for a while. It can be easily achieved via the USER_IDLE and USER_PRESENT air events – in this case stopping and starting the poller.

‘CheckSite()’ simply queues message HTML when the response code received is different from the previously stored code. When the queue poller is running (the user is present) the message is dequeued and displayed via Message.js.

At this point it is worth remembering that notification windows are no different to any other native window. It’s just a name we’re giving to the way we are using native windows. They therefore have their own events, contents, position etc and this can be seen by the Message.js code where a new chromeless, transparent native window is created and its contents loaded from the message.html template.

The display process is then as follows:

Message.js stores the message content in a variable on the new window
MessageScripts.js, then running once the message.html dom is ready, sets a listener on the HTML_BOUNDS_CHANGE event before setting the message variable content as the body – ultimately firing the bounds change event
This event is handled by setting the native window height to match before firing the layoutComplete event
On hearing this Message.js makes the window visible, finds an appropriate resting position (in relation to any other messages) and animates it in.

E-mailing

A key feature of any site watcher is to let us know when something bad happens. The combination of emails and an email-to-text service allows us to be notified the minute we spot trouble. This was easy enough in the bash script, using sendmail on the Mac. Not so straight forward for an AIR app. We can’t run sys commands and there is no built-in SMTP server. The solution is to use sockets in AIR. A little hardcore, but it keeps the solution nice and tight.

Anyone who’s sent an email with telnet will know that the principle of SMTP is, as the acronym suggests, simple. Adobe gives us plenty of clues for opening sockets and listening for messages. All we had to do was make sure we sent the right info. There are some restrictions in opening sockets from scripts outside the application sandbox, but for our purposes it worked a treat. With a little trial and error we were firing off emails left right and centre.

The icing on the cake was adding twitter support. With a one-line AJAX call in JQuery and a little config it was a no-brainer. This allows us to keep an online audit in the form of a private tweet stream. For people who check twitter more frequently than their email, it’s handy for notifications. If Twitter let us UK folk receive updates via SMS again then we can ditch email-to-text in favour of Twitter.

Step 3: The makeover

One of the nice benefits to working in the web-kit world is being able to use some CSS3 styling such as rounded corners. So we went to town. The more design that is CSS based and the less that is image based the better.

JQuery UI allowed us to make the entire list sortable in a sweep of the mouse, and the prefs popup tabbed in a blink (suddenly there was heaps to customise!).

The End

Hopefully this post has given you an understanding of how quick and easy it really is to make a useful AIR application. We’ve shown how you can implement a system tray application that utilises notification popup windows and sends e-mails as well as uses local files as a data store. This is not intended as a best practice discussion. It was our first AIR app and developed in a very small amount of time as a proof of concept and so that we could share our experiences with you. We welcome any feedback.

Download and try our site watcher AIR application

A demonstration of graded browser support

Posted in Design on February 12, 2009 by Paul Boag

In my post ‘Effective Browser Support‘ I explained how we should not be looking to make sites identical in all browsers, but rather focusing on usability and accessibility. In this post I demonstrate how that works in practice.

I recently launched a new Headscape service called the Consultancy Clinic. As part of this launch I created a small single page website. Let me use this site to demonstrate how graded browser support can work.

Remember – the idea of graded browser support is to support all browsers so that your site is usable, accessible and at least reasonably attractive. With that in mind lets start with the lowest common denominator.

Starting with the basics – HTML

All web browsers can support HTML. So as a bare minimum I needed to ensure my new website was usable and accessible in raw HTML format. To test this I used the free Lynx Viewer and it returned this…

Consultancy Clinic site viewed in Lynx

So far so good. But what about those browsers who think they understand CSS but don’t render it properly?

The pretenders

Unfortunately when it comes to CSS support things are not black and white. Although some browsers support styling flawlessly, others think they know what they are doing when they do not.

Poor implementation of CSS is the curse of older browsers. Browsers like Netscape 4 and IE 5 offer very limited CSS support and badly implementing what it does provide.

Instead of ignoring these browsers I create a basic CSS file which does some simple formatting. Instead of compromising the design to accommodate the limitations of these browsers, I deliver a simplified version which is usable and accessible.

Consultancy Clinic Website viewed in IE 5

As you can see the design focuses on some simple layout and typography. That way it avoids anything IE 5 may have trouble displaying correctly.

Dealing with IE6 and above

The next step was to create a more sophisticated design for browsers such as IE 6,7 and 8. These browsers understand CSS well but lack some of the more modern enhancements.

It was necessary to hide this enchanced stylesheet from ‘the pretenders’ who would render it badly. To do this I had to use a CSS hack, which was unfortunate. However, older browsers now completely ignore it.

How I did that is outside of the scope of this article. However if you want to know, view the source on the site and look for default.css.

This new design now renders perfectly well in the more modern versions of IE.

Consultancy Clinic website in IE 7

A watermark image is highlighted in this screenshot

There are however, subtle differences between the versions of IE. For example IE6 does not support transparent PNGs and so in IE 6 the watermark on the form does not appear. Although it would have been possible to force IE6 to display this image, it was more sensible to simply not show it. After all the watermark is an embellishment to the design, not a fundamental part of it.

The bells and whistles

Finally I have added some further embellishments to the design for more advanced browsers. For example both Firefox and Safari support border-radius. This allowed me to add curved corners, which are simply ignored by browsers who do not support that style.

Consultancy Clinic Website in Firefox

I was even able to go a step further in Safari because it supports dynamic shadows.

Consultancy Clinic website in Safari

Conclusions

Design enhancements like drop shadows and rounded corners are important, but not to the same degree as usability and accessibility. With finite time and budget, we are better spending our time making sure the site is usable on all browsers rather than getting it looking identical in a few.

With the time I saved not trying to force IE6 to display a rounded corner correctly, I was able to ensure the site looked good in older browsers with a limited understanding of CSS.

Once you accept that your site will not look identical in all browsers, you will be able to build sites faster, cheaper and ensure a broader range of devices can access them. Surely that is worthwhile?