Lessons from the O2 failure

Posted in User experience on July 7, 2008 by Paul Boag

I don’t want to start ranting about the debacle that was upgrading via the O2 website, from my iphone to the iphone 3G. However, there are a couple of things we can learn about good site design from their mistakes.

Like most of the British population (or so it seemed) I tried to upgrade my first generation iphone for the new iphone 3G. Following the instructions I received from 02 I went to their website and then spent the next 2 hours battling to place my order. This horrendous experience raises some interesting points.

Load test - If you are expecting shit loads of people to hit your site at the same time then run some loading testing against it!
Don’t cause a panic – Announcing there is limited stock and that you are going to sell on a first-come-first-served basis is going to cause a rush.
Provide alternatives – Don’t force users into only purchasing through a website. Allow them to purchase via phone or store too.
Keep it simple – The whole process could have been streamlined. Adding a text message as a method of authentication was unnecessarily complicated and caused problems.
Avoid AJAX – On a site that is going to be hit by heavy traffic, avoid using unnecessary AJAX. It was impossible to jump to the appropriate place in the process. Instead I was forced me to start from scratch each time the page hung.
Use cookies – By using cookies they could have saved me considerable time entering my information again and again.
Clear messaging – Despite completing the process I am unsure of whether I have an iphone coming or not. The site needed to make it clear whether an order had been successfully placed.
Error handling – When things went wrong with the site it didn’t respond elegantly. Some carefully written messages could have cleared up a lot of confusion.
Better labels – One label asked me if I wanted a bolt on package. It didn’t explain what that package was or what answer was required. It just gave me a blank text box. What was I supposed to type into it? Should I leave it blank? Why was it a text box and not a dropdown menu? Was this the reason my submission was failing?
Email confirmation – It would have been nice to receive an email confirming or rejecting my order.
Waiting list – For those who failed to place an order before the product ‘sold out’ there should be an alternative. Never turn a customer away. Either offer the chance to pre-order with an estimated delivery date or at give the change to register to be informed when new stock arrives.

Update: Alex made some excellent additional points in the comments and I wanted to mention them here too. He added to my already extensive list:

Get a CDN or virtual servers – If you’re expecting a lot of traffic in a short time, look to share the load. Think about placing your critical functions (such as an online shop) onto a platform that allows you to deploy additional servers on demand (often called Virtual Private Servers) – such as Amazon S3 or similar. If you can’t change onto something like that – you can still help your server by moving images, CSS and javascript onto another server, or even a CDN. A Content Delivery Network (CDN) is a network of servers that contain copy of your key files to help spread the load.
Have a backup plan (or have two!) -
If you have something really high-profile, have a backup plan, or two! In this case, O2 DID have a back-up plan… they had a ‘failover’ site… which was a simple one-page form to take down customers details. The only problem was it didn’t work when it needed too… it failed too!
Brief your call centre -
Knowing that some customers were likely to experience trouble accessing the site (or even just getting confused placing an order), you should make sure that you brief your call centre staff – put on extra staff and make sure that they can take orders too, and know what to do.
When I called O2′s customer services, they couldn’t offer any help as ‘upgrades were online only’. Additionally they couldn’t check if my 3 times I put my credit card details in were registered (they weren’t as it happens).
If all goes wrong… the call centre is your last line of defense, and O2 dropped the ball here too.

Update 2: Well, the iPhone 3G has now launched in the UK and O2s website continues to fail users. This time Apple was forced to turn away customers from their stores because they were unable to register them with the O2 site. The reason why: The O2 website would only work in Internet Explorer. This provides us with yet another lesson to learn…

Build for your audience – Consider who your target audience is and what requirements they have. In particular consider their accessibility need to make sure you never turn away people wanting to give you money.

All in all it was badly handled and I am pissed off. Can you tell!

118. Geo

Posted in Classic shows on May 20, 2008 by Paul Boag

On this weeks show we look at geocoding, Tom Coates talks about Fire Eagle and find out how we achieved the tabbed menu effect on the Headscape website.

Download this show.

Launch our podcast player

News and events

New tools for web designers on the way

A few months ago the guys over at clear:left put up a holding page for an application called Silverback. Exactly what Silverback was became a topic of much discussion and a considerable amount of buzz.

This week Andy Budd has finally revealed exactly what Silverback is on his blog. He describes as…

An OSX application to help people run their own low-cost Guerrilla usability tests. It captures screen activity, records audio and video from your built in iSight, and then composites it into a handy Quicktime movie for later use.

I have been fortunate enough to play with an early beta and I have to say it’s a great idea. It has the edge on other "screen capture” programs because it is designed specifically with usability testing in mind. For example, you don’t need to export the movies as soon as they are recorded. You can save them until you have finished a day of testing when more time is available.

If you ever do user testing get yourself over to the Silverback site and signup for the beta.

It would of course be remiss of me not to mention GetSignOff.com as we are on the subject of tools for web designers. Like clear:left Headscape have been developing an application and this week we provided our first walkthrough showing exactly what it does.

In essence GetSignOff is a web application that allows you to present designs to clients in a more professional manner, manage the feedback you receive from them and organise the multiple iterations of each design.

To really get a sense of what it does you need to view the screencast so be sure to check it out.

Effective online delivery of video

There can be no doubt in anybodies mind that online video is huge. It has taken a long time to arrive but with broadband so widespread it is now a reality. Increasingly users are expecting video content from websites and it is up to us as web designers and owners to deliver.

Delivery is fairly straightforward when you can use sites like YouTube or Vimeo. However, that is not always possible. Constraints on size and quality can make these services unsuitable. Not to mention their over demanding terms of use. So what do you do if you are forced to host and deliver video yourself?

My advise is to read an excellent article on the Digital Web Magazine that looks at the various approaches for delivering video over the internet. It explains concepts like progressive download, RTMP streaming and HTTP streaming. It is a superb source of information for anybody who has to host and deliver their own video content.

Some Javascript slight of hand

Our next story is some slight of hand by Robert Nyman.

I find myself increasingly using Javascript to show and hide content. However, being a well behaved standards designer I have to be careful how I build pages. I avoid hiding content with CSS because if I do and Javascript is disabled, users have no way to show the content again. Instead I use Javascript to hide the content so that if it is disabled the hidden elements will show by default.

The downside is that you can get flashes of content because Javascript has to wait for the page to fully load before it can hide content.

Fortunately Robert has come up with a nifty little workaround where he uses Javascript to load a CSS file, which in turn hides the content. This happens before the body has been loaded avoiding the flash of content.

If like me you occasionally suffer from content appearing when it should not, then bookmark this approach for later use.

Overcoming creative block

Our final news story today is a post on overcoming creative block. Creative block is something we all suffer from whether our job is perceived as being a creative one or not. Every job requires some degree of creativity and we all know what it feels like to stare blankly at a computer monitor unsure of where to begin.

This post provides a list of excellent tips on how to overcome brain freeze from going for a walk to throwing away the piece you like most. It really is a superb read. Another one to bookmark for the next time your creative juices fail to flow.

Surprisingly he has missed my number one technique, sitting on the toilet… or is that just me?

Feature: Location Aware

The web is full of exciting innovations at the moment. However, it is geocoding that personally excites me the most. In this weeks feature I explain what it is and why I believe it offers so much potential.

Interview: Tom Coates on Fire Eagle

Paul: Ok, so joining me today is Tom Coates from Yahoo. Good to have you hear Tom

Tom: Nice to be here

Paul: So I’ve just been hearing from Tom that he’s got a massive line up of interviews to do for a product that he’s been involved with called Fire Eagle. So he’s talking to the Guardian, the BBC and lots of important people, but thank you for sparing a few minutes to talk to us too. We’re very honoured.

Tom: No problem at all.

Paul: So, lets kick off for those who haven’t come across Fire Eagle before. I think you talked about it at dConstruct last year.

Tom: Yes

Paul: That was when I first heard about it, perhaps you could tell our listeners a little bit more about what it is, and what it does.

Tom: So Fire Eagle is a service that helps you share information about your location, online. So that’s both for people, and more importantly for different sites and services. The other side of it is that it sort of fixes a problem with the development community for the use of applications that use your location. In that it makes that process much easier. So in principal, it means that from a user’s perspective, you can capture information about your location and use it in lots of different places. And from a website owners perspective you can start to think about how your service can respond to someone in the world without having to do a lot of donkey work.

Paul: So it’s not primarily, in itself, like another web application like Twitter where you’ve got to sign up for and take part in it? I
t’s more of a API framework type of thing.

Tom: Well, when you think about it, it is both, because if you think about it as a place to sort of store information about your location. We give you the tools to go in and update that information, decide who to share it with, and manage that information. So in some ways it’s like your location preference page, which helps you control that information. So yes you do sign up for it, it uses a Yahoo ID, the same one you use for Upcoming and Flickr, but really, once you’ve started capturing your location or sharing it with particular services, you don’t really need to come back. We’re not trying to build a sexy fun service for day-to-day use, but we’re trying to make something that makes it easier for you to build, and other people to use, services.

Paul: OK, so how exactly does the service work Tom. I’ve seen other location based stuff where you have to do horrible things like enter grid references or terrible stuff like that. How do you use Fire Eagle?

Tom: What you do with the site, is you go to the site, and you log in with your Yahoo Id and you do a simple terms of service thing, which asks how often you want to be reminded that you’re sharing your location. From that moment on you’re up and running. The simplest thing to do, is go to a web page called where am I, and you can type in your address and, we will work out where you are in the world, and we’ll plonk it on a map. Now that in itself isn’t terribly interesting. So the interesting thing about it, is that we’ve opened up the API’s so that anyone in the world can build something that could update your location, and anyone in the world could build something that could use your location. So we have an application gallery, and you could go along to that, and on that at the moment there are services like Navizon, which work out where your location is by nearby wifi signals. Or Loki which is from SkyHook the same people who power the iPhone location thing, and Dopler and all kinds of stuff. You can tell those services that you’re OK sharing that information with Fire Eagle. So I have an application on my phone at the moment from Navizon that works out where I am every 10 minutes and tells Fire Eagle where I am. So that location just sits in Fire Eagle and then I can decide to share it with people. So as an example a plug-in for movable type that Ben Trott has built and that means that you can put on your blog, a little map of where you are right now which is quite fun. What we do is, to help maintain your privacy, you choose which services you’re comfortable with sharing your location with, or get an update from. You can say to what level of granualarity you’re comfortable sharing with it. So you can say, just share my city, or my state (if you’re in America) or your neighborhood or your exact point. Then you can hide information at any time, or delete all information in the system.

Paul: Oh, OK.

Tom: So basically it means that you would go and find one really good way to get where you are, or lots of little ones all around the place that compliment each other, and sort it out into the middle of this little repository of data, that you can then say, yes I’d like to use this on Flickr, or on Facebook, or on moveable type, or wherever.

Paul: So the way you’re describing it is that there are multiple entry points into it, where you type in your exact location, weather it’s your mobile phone updating it?

Tom: Yes

Paul: You know I even noticed from looking at the site that you can now Twitter your location in.

Tom: Yes

Paul: And that there are multiple output points, where it’s going to Movable Type, or to wherever else.

Tom: Yes

Paul: So what type of things are we going to see with this. What are you expecting people to develop? Is there any cool stuff at the moment that you can tell us about?

Tom: Yeah, well there are a fair number of cool things that have already come out, which is kind of interesting. I mean one of the things on the engineering side – so there is a bit of a problem with location based services, and everyone’s been talking about it for a very long time, you know they have all these kinds of things that you couldn’t find friends more easily, or find out things about your neighbourhood or whatever. And the problem is, and has always been, that it’s quite hard because what you have to do is, every time you want to use an application like that, you have to install another application on your phone, or go through another extended rigmarole about how to do it. So our plan is that we take that away, so what you basically do is you find any piece of software that gets your location usefully, and you install it, and it updates Fire Eagle. So from that moment on any application in the world that is Fire Eagle enabled can go and get that. So any website in the world could respond to where you are, without ever having to build the thing that works out where you are. So some examples – Navizon as I said is this lovely little application that runs on most mobile phones, captures your location. There is a thing called Fire Bot, which is a Twitter Bot, and on that one you can do a Twitter direct message, with a text string of where you are. So you can say I’m in San Francisco, or I’m in London, or I’m in.. as I am now, at Yahoo’s offices at 125 Shaftesbury Avenue. And you can type that in and you can then share that with all the applications you’re comfortable with. We’ve also taken Cell ID information, so if you have a mobile phone, many of those on a technological side expose the Cell ID. So that’s the tower, or mobile phone mast kind of thing. Quite a lot of people are doing interesting mappings based on that. That in particular is at a very early stage so we don’t actually get much good information from that, but, you know we do take in all different types of data. You could have a GPS log coming from a mobile phone, or anything that could get long/lat coordinates, or anything that could get text string of the place you’re in. On the other side, is the things that could use it, which is where the fun starts. There are all kinds of things that people have built. And more coming. So there is a service that Leonard Lin, the founder of Upcoming made for us, called FireBall, and FireBall was particularly useful in San Francisco in the last couple of weeks because of the Web 2.0 Expo that was out there.

Paul: Oh yeah.

Tom: And the idea with that was you could either send a Twitter message of where your location was, or if you were getting it from FireEagle, it would automatically use that. And at any point you could say "Where are my friends” and it would go to Twitter, find out all your Twitter friends and plonk them on
a map for you. And you could do that on the iPhone as well because it would send you a file that could then be opened by the Google maps thing. So you could literally call your little maps thing on the iPhone and it would say "Here’s where all your friends are”, which is really lovely, and really nice, because it’s all about your friends there.

We’re building a Facebook App, this is no particular secret, we’ve talked about this before, and its going to be one that means you can decide to share your location on Facebook with your friends, which is going to be quite fun. A guy called Simon Willison who I used to work with, who has built a thing called WikiNear. There are over a million geo-coded articles in Wikipedia, which basically means someone has put in the longitude and latitude of where the thing talked about in the article is. So Simon’s thing is a little web page for your mobile phone, and you bring it up and it says "Here are the 5 nearest interesting things to you”.

Paul: Cool!

Tom: Which is pretty fun, so you can wander around London and here’s the British Museum and you can click on that to go to the media wiki page to talk about that.

Um, there are other things like that, I mean LightPole is a little company that we’ve been working with. They’re doing things like local services around you, which again is mobile phone focused. A company called Outside.In, they do things like try to work out where all the blog posts and news stories are about, and they can bring that information to you if they know where you are – and they are going to get some of that information from FireEagle – which is really cool. So as I said we’ve got this Moveable Type thing. So there are all kinds of stuff that is going on at the moment. We build these wonderful little widgets, which I really like, they are for OS 10, and one of them is a little updater. You can type in your location, press a little button and it will update it to FireEagle. One of them tells you the weather where you are right now. So if you travel a lot, it will give you the weather forecast of where you are. And one of them shows you nearby flickr photos, so it just goes and gets those geocoded photos from Flickr and gives you every day a little photo montage of all the cool things that are going on around you. So lots of interesting new uses really.

Paul: It’s interesting you mentioned Flickr. I mean you can imagine the reverse of what you just described with Flickr, so if your location is been taken each time, it would know the location where you took that picture and geo-code that picture on Flickr. Is that the kind of thing that you’re planning to do?

Tom: I mean there are a lot of really interesting uses based around geo tagging. So whenever I write a blog post, it would be really awesome if my Moveable Type blogger could go and look up on FireEagle where I was, and say "This article was entered here”. So you could say "What do you think about Gordon Brown in Edinburgh” as apposed to "What do you think about Gordon Brown in London” or "Wales”, and that would be really fun as a good way of slicing through this enormous amount of blog posts that are out there.

Twitter messages as well, that would be lovely – it would be really great if every time you wrote a Twitter message they went and grabbed your location, and you could say, well I want to explore the public conversations going on in my neighborhood right now. That would be lovely. Um, and with Flickr as well, when you click on a photo on your phone, uploading it immediately. If you havn’t got the location on that device, being able to get it from FireEagle would be really useful. And you know obviously whatever amount of information they can get, so perhaps FireEagle only knows you’re in London, that’s still useful – you know you can still help people find photos just because they are in London. Or if they are at an exact point that’s also good. The only thing about Flickr is that often people take photos and upload them later. And at the moment because we want to make sure that we’ve thought about all the implications, and we don’t want to weird any one out, we’re making sure that we don’t keep any ones history.

Paul: Oh Ok

Tom: So it’s literally just your current location we look after for you.

Paul: Ah, that’s good.

Tom: Yeah we’ve talked to a lot of people about this, and we have been very careful about the privacy and control. These are the two watch words of the project. We are incredibly conservative, we don’t want to worry’s any one out. So at any time you can press a button to hide your information. Information will still come into FireEagle, but it won’t go out. Or you can delete all your information on FireEagle at one time, so we won’t keep any records at all if you do that. At the moment we don’t keep any location history at all – any tracking, or location history there. And we even by default will send you an email once a month saying "Are you still OK sharing”, and if you don’t reply to the email, or you don’t click on the link in the email, then we’ll stop immediately. It’s just so there is no risk of you doing anything, you know, accidently, exposing it in ways you’re not comfortable with.

Paul: I mean when I first heard you talk about this it struck me as hugely exciting, that location based information is an area that I’m massively excited about. And I think there is so much potential to add a new level of context, you know, on the data that we see on the web. Something that has been very much lacking since the beginning. And there is so much potential here, for pretty much anyone listening to this show, whether you’re a design or a web site owner.

Tom: Yeah

Paul: So where would people start to find out more information about this. Where’s the good place to begin?

Tom: OK, so one of the parts of the project that took surprisingly the most time, was actually making sure that the documentation was really good. At the moment it’s an invitation only service, so we have a few thousand people using it and testing it at the moment. We’re opening it up to more invitations pretty regularly. It’s only been out in the wild about 6 weeks. So if you’re interested in using FireEagle, just go to the website, put your email address in the box, and over the next few weeks we’ll be sending out more invitations.

Paul: And what’s the website address?

Tom: Oh, it’s FireEagle.com

Paul: OK

Tom: So that should be nice and easy to find. On that site, if you can get an invitation, and if anyone spots us around the
place, ask us, because we have little cards we can give out. There is extensive documentation on how it works, that really falls into two big chunks. Partly it’s this use of this new standard called OAuth. Which is a really good way, meaning sites can talk to each other on behalf of users, and you can set your preferences around that. So getting your head around OAuth is really useful because so many services – I think Google and Yahoo have both announced that there is going to be support for OAuth as a standard now. So that’s really great, we’re all really happy about that. And the other side, is the FireEagle APIs themselves, which are very simple, sort of three main ones. 1. Where is the user. Again, all of this only happens if the user has given explicit permission for this service to see it.

Paul: Sure

Tom: One is update the location of the user, and one is ambiguous query, so such as, you say you’re in London, which is great, but there are hundreds of London’s in the world. So there is one service where it says "which London” and you can say "this one”. So they are the three core queries , it is very very simple. We have another couple of ones, for particular web services, to bring back users of my application within that particular area, like SOHO or London.

Paul: Yep

Tom: Another one, bring back the hundred who have updated their location most recently. So just think, just to make it easier for developers to build useful services.

Paul: Cool, that just sounds really exciting, and I can’t wait to see some of the stuff that is developed in the future. Tom, thanks so much for coming on the show.

Tom: No problem, I hope that was useful

Paul: That was incredibly useful, and I’m sure there will be a lot of people hounding you for invites, well there probably already are thousands of people hounding you for invites. Have you got any idea when it’s going to go "Full Open”?

Tom: Yes, I do have an idea when it’s going to go full open.

Paul: But you’re not going to tell me.

Tom: Well its within the next couple of months. We want to make sure we’ve had conversations with some really interesting people, so that we have some really cool stuff to show off at the same time. So you’ll just have to wait and see on that line I’m afraid.

Paul: Oh, so that’s really exciting and thank you again for coming on the show.

Tom: No problems. Cool.

Thanks to Nathan O’Hanlon for transcribing this interview.

Give Away: Fire Eagle Invites

So as we mentioned in the interview, Fire Eagle is currently in beta, but if you can’t wait for the full release and want to get playing with it right away your in luck. We have around 20 invites available for boagworld listeners. To claim one, e-mail [email protected] with the subject heading of "Fire Eagle Invite" and Ryan will send you your code, while stocks last…

All tickets have now been claimed!

Listeners feedback:

Tabbed menus?

David Bridle writes: How did you get the tabbed menu to work in the headscape website?

When writing the answer to this question, it turning into quite a lengthy explanation. So I wrote a blog dedicated to it, which can be found here.

Location aware

Posted in Development on May 19, 2008 by Paul Boag

The web is full of exciting innovations at the moment. However, it is geocoding that personally excites me the most. In this post I explain what it is and why I believe it offers so much potential.

I am definitely not an expert on geocoding but I have been aware of the idea for a long time. I first encountered the concept back in the late 90s. At the time it entirely passed me by and I couldn’t see why the person explaining it was so excited.

“Just imagine the possibilities if every file had a location stamp like it has a date stamp”

I obviously lacked imagination. It all felt too theoretical. Too far off.

Later the concept was reintroduced to me, but this time all I saw was a world of adverts being pushed to my mobile phone as I walk by the local starbuck. Who wanted that?

The lightbulb finally switched on when I heard Tom Coates speaking at d.construct last year (Download Tom’s talk: MP3). He talked about a project he was working on called Fire Eagle that allowed applications to pass your geo location back and forth.

Geocoding is a reality now

Nine months on and I have finally got to play with Fire Eagle. I no longer need imagination to see the potential, it is no longer far off. Geocoding is here and boy am I excited.

For me the real power of geocoding comes because of mobile devices. Once your mobile knows where you are the possibilities are endless. My iphone for example lacks GPS but it can work out my position based on cell towers and wifi networks. This enables me to do lots of things…

I can attach my location to twitter posts and see other twitters nearby. (via Twinkle)
I can upload photos with location information and see other photos taken from my current location. (via iFlickr)
I can view wikipedia entries of nearby locations.
I can broadcast my current location to my blog.
I can see which of my friends are nearby (presuming they too broadcast their location). (via Navizon)
I can find local restaurants, events and other points of interest.

All of that I setup for myself in a couple of hours. I haven’t even scratched the surface of what is to come.

The website owners perspective

This is not just something consumers should be getting excited about. It offers huge potential to website owners as well, because it provides users with new ways to access their information.

Consider for a moment what information you hold that is location specific. Do you have physical outlets (or other points of interest) that could be geocoded so users can easily find them? Maybe the content on your site relates to a geographical location (for example a university website). Or would users find it useful to know where you wrote a particular page of content (maybe a travel blog)?

I am the first to admit that geotagging is still in its infancy. However, there is no doubt it is on the cusp of going mainstream. Consumers have adopted car navigation systems very quickly and are familiar with adding points of interest (at least where speed cameras are concerned)! It will not be long before that experience makes the leap to mobiles.

It maybe premature to add location information to your data. but it is certainly the time to start thinking about what information you have that could be geotagged.

For more on geotagging and fire eagle listen to our upcoming interview with Tom Coates on show 118.

115. sxsw

Posted in Classic shows on March 19, 2008 by Paul Boag

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

Download this show.

Launch our podcast player

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

News and events

Microsoft launches beta of Internet Explorer 8

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

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

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

Designers agnst

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

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

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

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

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

Usability challenges associated with web applications

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

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

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

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

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

Feature: Lessons learnt SXSW

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

Interview: Garrett Dimon on form design

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

Garrett: Pretty good.

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

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

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

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

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

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

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

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

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

Garrett: Yeah, comment forms and…

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

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

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

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

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

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

Paul: How bizarre.

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

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

Garrett: Yeah absolutely.

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

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

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

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

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

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

Paul: So where can people find out about him?

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

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

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

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

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

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

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

Paul: (lauging) So many out there.

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

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

Garrett: Yeah likewise.

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

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

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

Garrett: Yup, exactly.

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

Garrett: Sounds good.

Thanks to Lee Theobald for doing the transcription

Listeners feedback:

Finding usability test subjects

Our audio question comes from Clare who asks…

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

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

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

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

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

Accessible tables

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

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

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

Day	AM	PM
Monday	Meeting	Travelling
Tuesday	Free time	Meeting

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

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

However, if marked up correctly it suddenly makes sense…

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

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

114. Forum

Posted in Classic shows on March 4, 2008 by Paul Boag

On show 114: Should designers stick to designing? What goes into a usability test script, and we talk to Alex Mogilevsky from Microsoft about Internet Explorer 8.

Podcast: Download (32.8MB)

Download this show.

Launch our podcast player

News and events | User testing scripts | Alex Mogilevsky from Microsoft | Listener emails

News and events

Before we look at the news I want to share a bit about boagworld. There is so much happening with both Boagworld and Headscape. If you are interested read my random news post.

However, for now I just want to mention the forum. For a while now the forum has been experiencing technical difficulties. Fortunately that is behind us and I want to encourage you all to check it out.

I can honestly say that the boagworld forum is the best forum I have ever been involved in. Not because of anything I have done, but because of the awesome people on there. They are so amazingly helpful and I have never seen a flame war or newbie bashing.

Please take a few minutes to sign up. Even if you don’t regularly participate, you can at least add your location to our listeners map :)

Instant mobile sites

I want to mention a website called MoFuse.

I have talked before about the importance of the mobile web. With a new generation of internet enabled phones we need to “moblise” our sites quickly.

MoFuse makes the process painless. It takes your RSS feed and tailors it for different mobile devices. For example an iPhone user would receive a different experience to a WAP user.

As well as RSS you can add static pages and customise the design. It is an impressive service and the basic setup is free.

I should stress that this is not an ideal solution. It does not replace a carefully crafted mobile site. However, it is a good starting point, especially if all you want is a mobile version of your personal blog.

And yes, I did create a mobile version of boagworld (m.boagworld.com) that allows you to stream the podcast on your iPhone.

Layout, do’s and don’ts

My next news item is a post by Andy Rutledge on bad layout conventions. He highlights two problems.

The first is three column layouts where the main content is framed by two side columns. Andy argues this creates several problems and demonstrates how things could be improved by taking the Apple store (which uses this layout) and redesigning it so that the two side columns are to the right of the main content.

The second problem is organising different sections of information into long vertical columns of varying lengths. This requires a lot of scanning and scrolling. Again, Andy demonstrates the problem by fixing it on an example site. He uses a horizontal approach where the sections span the width of the page rather than being sorted vertically.

At the same time Andy posted this article, the guys at Web Designers Wall posted some inspirational grid based designs. Interestingly I saw the Web Designers Wall post first and was inspired by the list of sites. However, after reading Andy’s post I returned and noticed the problems Andy has identified. Suddenly my opinion was changed.

I recommend checking out both posts. They will change the way you view layout.

jQuery for designers

At the beginning of the year I said designers should learn Javascript. I have also said in the past that we should avoid frameworks and learn Javascript from scratch. However, Christian Heilmann challenged this assumption in our recent interview.

This week I found a tutorial aimed at introducing jQuery to designers. What I read blew me away. Not only is jQuery small (approximately 29kb) it also reduces the amount of code I need to write considerably. It will quickly earn back those extra bytes.

However, what I love most is that it reads like CSS. To find elements by tag, class or id you don’t use getElementBy as you would in Javascript. Instead you specify it in the same way as CSS using # . and tag names.

Finally, it makes animation easy. You can slide things around, change their opacity and much more. Check out the extensive documentation to learn more.

Although I haven’t used it on a project yet, it is looking hopefully.

Feature: User testing scripts

I have talked before about the benefits of user testing. I have discussed how to user test on a budget. Now, I want to look at some basics that go into every usability test script.

Expert interview: Alex Mogilevsky

Before we get to the interview with Alex it is worth saying that he contacted me a few days after this interview saying that it could be out of date by the time of broadcast. He was of course correct as last night Microsoft announced that IE8 will be standards compliant by default. Although I still do not have a problem with Microsoft’s previous position, I know a number of people disagree with me. It is encouraging to see Microsoft listen to the community and change its approach accordingly. I am sure they will have to endure criticism from other quarters for this decision and we need to encourage them.

Paul:Okay, joining me today is Alex from Microsoft. Now Alex have you noticed how I avoided trying to say your surname there? How do you pronounce it? Ah well I haven’t got a hope have I? I’m doomed. But it’s good to have you on the show anyway. Now it’s really nice of you to come on. We thought it’d be good to get you on the show to talk a little about IE because I understand that that’s what you’re currently involved with. But before we get on to that can you give the listeners a bit of a background as to who you are and what you do and kind of how you ended up being involved with IE

Alex: Uh yeah I’m at Microsoft for about 15 years now and I worked on all kinds of projects from word to publisher and IE now. I first worked on it at the end of A5 so it is my, technically it is my fifth version of IE although the real big one that I worked on was IE 5.5.

Paul:Oh okay.

Alex: I have a reason to not like .5 version (of IE) because that was really a big project for me and I have to explain that it was 5.5.

Paul:(Pauls laughs.) Yeah it may be a .5 version number but it was massive to you. I get the idea. Well obviously um part of the reason that we got you on the show today is to talk about version targeting. But we also want to talk about a lot of different things as well. How you see the browser developing in the future? What the futures of browesers generally is? But let’s kick off with the subject of version targeting. Did you expect the kind of level of reaction that you got off of the back of this?

Alex:It was surpising to see huge negative reaction from people being published. I don’t know there were probably hundreds and hundreds of comments on IE blog. It’s hard to find the positive one. When you talk to somebody who is actually creating content for the web I get a little time to explain the concept is, everybody agrees that well there is some content there, there has to be a way to figure out what the author was thinking when they were creating it. So you should be kind of marking that content with some clue for the browser to render it properly. It is quite amazing to me that people who disagree with version point fingers at Microsoft. That it is totally Microsoft’s thing.

Paul:I mean it’s interesting isn’t it, cause one of the reasons that people said that Microsoft introduced versioning was because there was such a kind of kick back over IE 7 breaking the web, as it has been put. Um Would you think that IE 7 has been perceived as a failure within Microsoft? Many people seem to have thought of it, you know, there is this perception that is the way it is perceived in Microsoft. Is that actually the case?

Alex: Well. It depends on how you define failure. I think from one point of view it didn’t do enough from another it did too much. So go with what everybody ask us. We go and do more standard, and we didn’t get standard enough. It’s not 100% of standard but the little that we did broke so much that we really learned the hard way that we can’t make any progress without doing something about not breaking exsisting web.

Paul:Do you think that with the kind of issue, you know, one of the main comment that I’ve read about the version targeting is the fact that by default um, that you have to kind of opt into version targeting in effect to opt out of it. That by default it will render as IE 7 for time and memorial. Do you think that that’s likely to change before the release of IE 8 or is Microsoft fairly set on that now?

Alex: I don’t think we have any other option. What would that option be, is go and visit every website on the web and opt it out and then carefully figure out which ones are actually designed to work with IE 8 even though they couldn’t have possibly known what it means.

Paul: So do you think that it would be too much of a burden on people out there creating websites, that when they’re seeing a problem and they’re saying why does IE 8, you know, break my website. Telling them to just add another single line of code, you know, do you think that’s asking too much?

Alex: Well I think any assumption like assumes that every site out there actually has a person who understands why it is what it is and is actually capable of fixing them. The vast majority of people publish and they don’t know what a version is. They don’t know if their site is in Quirks mode or standards mode. They look at this as a browser bug. But, maybe there is something that is relying on a bug in previous browsers where old browsers were compatable in being non-standards.

Paul:I’m in agreement. I think you’ve come up, I mean it is a compromise what you guys have come up with, but as compromises go I think it is a very good one. I think it’s much more important to keep the web an environment that anybody can put information up on without having to be an expert in web design. If that means as professional web designers we’re slightly inconvenienced that seems to be a price worth paying from my point of view. But let’s move on from version targeting cause we’ve talked about it far too much on the show. Let’s talk a little bit about the process of developing a web browser. I think for a lot of web designers we’re entirely on the side of, obviously, you know putting things into a web browser. Getting things to render correctly. How do you go about creating a web browser? What’s involved? What should we be aware of?

Alex:Well a web browser is an enormously complicated thing. There is a reason that new browsers don’t show up too much. You have to build at the same time a decent editor, a rendering system that can render almost any kind of text and graphic. It has to be fast. It has to have object model. It has to parse a variety of different things. And is has to be compliant with a standard which is a book of at least 2 or 3 inches thick if you count HTML, CSS, and object model.

Paul:You say that developing a browsers is hugely complex and obviously it is, and that’s part of the reason that browsers don’t come around very often, or updates to browsers. But, on the other hand we do seem to see other browser manufacturers moving much quicker than Microsoft. Why is that? Why does there seem to be slower movement out of Microsoft than elsewhere.

Alex:I’m not sure that much quicker is the right way to describe it. The reason a lot of browsers are way ahead of Microsoft in a particular standard support is I think for two reasons. First we actually care about standards and we are nice people.

Paul:(laughing) You’re implying that no one else is nice and no one else cares about standards. I’m sure that’s not true.

Alex:No not really. This is how this happened. When we started working on browsers, which was, IE 1, 2, 3, 4 in the 90′s, there wasn’t so much of a standard. There was some idea you can mark text with tags in angle brackets and it will render somehow. So a b means bold. Eventually some kind of defacto standards developed. Every site was built for Netscape and it was important to be like Netscape. It was pretty much a standard. So when we built a browser at that time we were trying to be as compatable with that standard as possible. Then what happened, Netscape just went away for a few years and we were left alone. There was nobody to compete with. That is a hard place to be. You have to be compatable with the web. You can’t break anything. How do you make progress at that time. There was no versioning. At that point we decided to be nice and return the favour to other browsers and we went away for 5 years and were sitting for 5 years on the beach and letting everybody else catch up.

Paul:That was really generous of you. That was a wonderful thing. That’s a good answer I like that Alex.

Alex:Now everybody’s caught up we can be in the game together.

Paul:Okay. So now that everybody’s at the same level you’re going to go for it majorly. So that brings us quite nicely on to the future of browsers. You know, particularly IE 8. Obviously you can’t really tell us anything that isn’t already publicly known and I wouldn’t expect you to. But, not everybody that listens to this podcast already knows all that is publicly out there about IE 8. So tell us what kind of direction you’re going in. How are you going to compete with these other browsers out there now that they’ve caught you up?

Alex:Well the biggest thing to know about IE 8 is it is back. We have a real team of people who is really serious about building a good browser. The biggest investment in this one is obviously standards. That’s the biggest thing that everybody was unhappy about with the previous versions. We get as much as we can of good standards support right here. We are making major investments in CSS 2.1 doing whatever it means to be compatable. Interestingly enough it has to be defined what it means to be compatable, to say that you are compatable. We are doing as much as we can in this area. There will be a lot of exciting user interface features there. But I don’t think I can tell about that because I am really a core technology person and I learn about our UI implements from demos.

Paul:Fair enough. So, internally are you working towards a deadline of any description over this? I presume we’re not talking about another 5 years here? We’re talking about a much shorter period of time.

Alex:Definitely it is way closer than 5 years.

Paul:(laughs) That’s good. You want to narrow it down any from that or am I pushing my luck?

Alex:Yeah I don’t think I can have a number. Unless it is publicly known and I haven’t checked in the last couple of days. But you are going to see it pretty soon. I am going to set your expectations pretty low. Don’t expect this to be done in quaters because what we are doing with new standards layout it isn’t crazy and insane trying to rewrite things like this in less than 10 years.

Paul: So you’re suggesting that before too long we might see a beta. You’ve obviously come under a bit of an attack from Opera and they’re have been several comments about that. And then you’ve come out and said that you’ve done that acid test. How big a deal really is that in the real world? Do you think it is a fair test of a browser?

Alex:Well it is an acid test. As I understand in chemistry it checks the presence of a chemical, right? I guess it is a variant like that. I spent days taking this apart and figuring out what every line means and what features do you have to have, and how are they supposed to work to render a particular pixel in a particular place. It is quite and interesting test in the way that it tests very few features but it test the features in corner cases of intersting features of a standard. So you would assume if you get that far, if you manage to render text at all and you render Acid 2 you are in really good shape.

Paul:So is is fair to say…The danger is, and I have heard some people say this, with IE 8 you’ve just been going after being able to say yeah we pass the Acid 2 test. You could kind of develop those things in isolation. My hope, and I suspect your hope as well, is that you’re going to go beyond that. It’s almost inconsequential that you passed the Acid 2 test. It’s part of a broader aim to introduce better standards support. Is that a fair comment?

Alex:Yes it is. It probably would be not unreasonable to have another browser that doesn’t have an particularly promise but passes the Acid 2 test. We are really trying to be as close to standard as possible.

Paul:Let’s broaden it out cause we’ve kind of picked on IE quite a lot here. Let’s broaden it out to talk about where browsers are going generally in the next few years. I mean, what do you think we’re going to see happening in browsers generally?

Alex:Well from my point of view as standards and layout, I see actually multiple browsers being 100% compatable with CSS 2.1 which most helps both browsers and standards to really get into the new steps. We’ve heard a lot of criticism on standards not moving. Like CSS 3 some people are saying that trying to make sense of all the different parts of CSS 3 what is the next step there. In my opinion I am as unhappy with CSS 3 not moving as designers are. For this to move you have to have a solid ground of the previous version not only being a solid standard but also being supported properly. Then addding every little feature to CSS 3 become important because now we can have several implementations of that. As far as standards go I am really looking forward to the world after IE 8. And there are all the different directions of being mobile. Bringing more of the technologies into the browsers that they can perhaps take a bite out of flash or out of .pdf. Where you can have real content that was unthinkable for a browser a few years ago. Into every place that has a good browser. So I’m really optimistic. One thing to understand about developing a new browser is it’s exciting who writes is how has it. But for a web designer it is like making wine. Something happens today that will actually make the difference in the life of a web designer 10 or 15 years from now. Whatever is being shipped today, everybody you care about now has this one.

Paul:What we need you guys to do is drop support for IE 6 really quick cause then we can use it as an excuse to drop support as well.

Alex:This goes back to versioning a little bit. There is 3 kinds of versioning. There is versioning of a standard, version of a browser and version of a document. The version of a document is something that we are not going to drop ever. If something is written for IE 6 today 100 years from now we will still want to render it this way right? We wouldn’t go to the library and throw away all the books that are older than 100 years.

Paul:That’s a very good point.

Alex: In this sense many pages today are in Quirks mode. Google is in Quirks mode. If you try to render it in 100% standard it will look a little different. It will look quite odd by the way.

Paul:That’s a whole other discussion. Google and it’s standards support. What about typography? Are we going to see some improvements on that front? I mean we’ve noticed some of the other browsers starting to support web fonts and things like that. Can we expect a similar thing from IE?

Alex:IE supports font embedding for several versions now. There was an extremly complicated discussion within the standards group on how do you create a standard for downloadable fonts that can be standardized but is also friendly to font manufacturers. To people who own fonts. It’s easy to implement a hyperlink to a font that will be downloaded and used. Then it encourages to just put fonts out there, which you’re not supposed to do.

Paul:Obviously this isn’t down to Microsoft cause this is the whole standards group discussing this. That strike me as no different than what we do with imagery at the moment. Images can be pirated and that’s somebody’s intellectual property. It’s kind of just the way things have been. Do you feel that their is a kind of tightening up on things like that. Like people are more concerned about that then perhaps they were in the early days?

Alex:It is a good comparison of the difference of, whats the difference of an image or a song or a movie or a font. It is just so much more expensive to build a font. It is so easy to share if you just put out a file that if we make it easier to share we will just business model for a lot of small design companies who just build fonts. So we have to be very careful on how exactly it is being done. I think we are fairly close to be able to come up with a workable standard. We’re just not there yet.

Paul:Okay. So that is something that will probably turn up at some point but not necessarily in IE 8.

Alex:Well if that standard is embedded OpenType it is already there.

Paul:Yeah that’s true. Let’s just touch on briefly another kind of criticism that really hasn’t been aimed at the IE group but Microsoft as a whole, which is this whole issue of Office. The latest version of Office. I know a lot of people who are passionate about HTML emails who were deeply disturbed to see that the latest versio of Outlook doesn’t use IE’s rendering engine. Can you give us any kind of insight into what happened there? I mean obviously it’s not your area but it does affect you guys to some degree.

Alex:I wasn’t part of this decision but I can very well understand how that happened. When Office 2007 was being planned IE team pretty much didn’t exsist. We completely rebuilt the team for IE 7. I am not joking that we were 5 years on the beach. IE team stopped exsisting after IE 6. People went off doing their own different things. Of people working on IE 7 and now IE 8 there is litterally a handful of people who worked on IE 5. Maybe even less. It is a brand new team. When Office 2007 was being planned in 2003 there wasn’t anybody to talk to. The biggest concern about HTML email is security. So even is somebody wanted to build in IE 8 currently in a product to read email it would put a major requirement on IE to be able to be able to open all of these emails securly. If you take browser security and application security for things like Outlook it is a multiplier. It is way harder to build it that way. So I think that is totally sucks that you can’t send HTML email but I think that they decision that they had to make in Office 2007 was really difficult.

Paul:Interesting stuff. It’s been great. I’ve really enjoyed chatting with you Alex. I feel like I’ve got a little bit more of an understanding of what’s gone on inside of Microsoft and where things have gone. It sounds like a big part of all of this was your own success. That because other browser manufacturers disappeared and you were kind of left alone there wasn’t the kind of investment internally within Microsoft to keep things moving forward and it’s had ramifications. It’s very interesting.

Alex:Yeah. Thanks for talking to me. I have to say that you have a great podcast. I’ve been learning a lot from you. You don’t even imagine how much you yourself have on the future of internet. Just putting together this show.

Paul:(I can just see Paul’s head growing) Oh well thank very much Alex. I’m sure I’m not that important really but I’ll pretend I am. Thanks very much for coming on the show. We’ll get you back in the future. Perhaps once IE 8 is out in beta. You can talk a little bit more then. That would be fun.

Alex:I would love to. Thank you.

Listeners email:

Implementing RSS

Our first question is an audio question about RSS. It asks what tools exist for adding RSS to a clients website.

The simplest solution is to use a blog. Whether you use Movable Type, Word Press or Blogger they will all generate an RSS feed. Blogs are also easy to update and can be customised to integrate with the rest of your site.

However, a blog might not meet your clients requirements. For example, they might wish the RSS feed to link to a non-blog page or even a third party site. One option is to use a social bookmarking tool like Delicious. This creates an RSS feed of all links added. Alternatively you could use a desktop application such as FeedForAll. FeedForAll is a cross platform application that allows users to easily create, edit and publish RSS feeds. It also comes with a PHP script that converts RSS into HTML via PHP. This is ideal for embedding RSS into your website.

Hope that helps.

Should designers just design

Our next question comes from Travis…

I have recently been asked to join a web development/design team as their full-time UI designer. My responsibilities would include the UI design only and not css, html ajax, etc. I know the basics of css and html and have designed standards-based sites from scratch, and am eager to learn more code to further my skill set. I have been discouraged from learning code while in this new position, and focus on the UI design. Do most web design firms share this same structure?

Excellent question Travis and one that causes much lively discussion. Infact Cameron Moll asked the same question and the last I saw there was 114 comments!

My answer is that designers should be able to code. Personally, I don’t believe you can be an effective interface designers without an understanding of the underlying code and the constraints of HTML and CSS. I respect those who say that design shouldn’t be constrained by technology. However, in the real world its more complicated.

Setting that debate aside I would suggest that not knowing code is going to damage your career. Personally I would not hire somebody who cannot build as well as design a site. Consider your next job and whether you can afford to stay somewhere that actively discourages you from expanding your knowledge of the web.

To leave an audio comment for the show skype “boagworldshow” or call +44 20 8133 5122.

113. Hiring

Posted in Classic shows on February 27, 2008 by Paul Boag

On show 113: Christian Heilmann on common Javascript mistakes. Marcus talks about hiring new staff and Paul shares his journey into screencasting.

Podcast: Download (29.9MB)

Download this show.

Launch our podcast player

News and events | Hiring new staff | Christian Heilmann on common Javascript mistakes | Listener emails

A quick request. We are really in need of some more transcribers to help with the interviews we do every week. The team we have are doing an amazing job but it would be great to spread the load.

If you feel you could help once in a while please drop me an email and I will add you to the list.

News and events

Highly extensible CSS

A while back Cameron Moll released a tantalising screencast of a seminar he was running on Highly extensible CSS. Website today need to be ultra-flexible, dealing with changing content, multiple devices, and user customisation. Cameron’s presentation aimed to teach designers and developers how to build interfaces capable of adapting to the unforeseen.

Unfortunately, I didn’t get the opportunity to attend. I was therefore excited to discover that Cameron is about to cover the same subject in a series of four posts on his website, all for free!

So far he has only posted the introduction. However I am really looking forward to the whole series. For now just check out the screencast and see if it excites you as much as it did me…

Video tools

Talking of screen casts I have actually been working on several myself at the moment. We are in the process of redeveloping the Headscape website and have decided to include a couple of demonstrations and presentations.

This means I have been in research mode and I thought I would share what I have found. Firstly, I have discovered a great screencasting tool called Screen Flow. This Leopard only software stands head and shoulders above anything else I have tried on either Windows or the Mac. It is amazingly easy to record and edit your screencast and has some great built in effects. My favourite feature is that it will capture from both a web cam and the screen at the same time. This allows you to cut between video and the screen or even overlay a video feed on top of the cast.

Once I had recorded my video I started to look for somewhere to host it. Although I would be foolish not to put it on Youtube where it will get the most exposure, I didn’t want to use Youtube when embedding on my site. The quality on YouTube is poor and you are limited over length and size. With this in mind I looked at a number of competitors. The winner for me turned out to be Vimeo. The quality is superb, they are much more flexible over length and time, but most of all they provide links to the original file and allow you to customise the interface.

So, if you are looking to create a screencast I highly recommend Screen Flow and Vimeo. Also, if you are looking for tips on how to make an engaging video then check out Ryan Caron’s tips over at Carsonified.

Microformat boost

The last thing I want to mention in this week’s news segment is the growing interest we are seeing in Microformats recently.

For a start Firefox 3 is going to have built in support for Microformats, which will be hugely significant in itself. However the guys over at Yahoo! are doing some interesting stuff in the area too. Yahoo! Micro Search is a new way of viewing search results that include all kinds of metadata including microformats. According to David Peterson at Sitepoint this could allow Yahoo to really challenge Google.

I am not sure whether that is true or not, but I do know it is a great time to start using Microformats. If you want to get started then check out Microformats.org or for you more advanced users have a look at this interesting demo of compound Microformats.

Feature: Hiring new staff

Marcus shares his thoughts about taking on web design staff for the first time.

Expert interview: Christian Heilmann on common Javascript mistakes

Paul: As I said at the beginning of the show, joining me today is Christian Heilmann. Hello Christian, how are you?

Christian: Hello Paul. Why it’s quite fun cause it’s Valentines day & I’m stuck with you as a date.

Paul: Well I’m sorry that you had to ah to endure me on Valentines Day but I’m sure you’ll survive. And um yeah… so basically, the reason that we’ve got you on the show today is we want to talk a little bit, a little bit about javascript. Now we’ve talked a lot of times about javascript before and it’s not a new subject, but I kind-of um… felt it would be worth touching on the kind-of common mistakes that we’re seeing a lot in the world of javascript at the moment. I think um… you know obviously javascript is very in and there’s load of cool stuff being done with it but not always in the wisest ways. Um… and then on top of that, so there’s this kind-of group of people that are doing quite advanced stuff with javascript with maybe not considering all the ramifications of what they’re doing. And there’s another kind-of group of people which are people like myself that go ‘Ewww… look at that, that’s cool I want to start doing things like that.’ And so you know a little, a little knowledge is dangerous as they say, and you know we’ve picked up books like Jeremy Keith’s scripting book and read that and now we think that we can, we can build javascript applications and are kind-of hacking things together. So I thought lets spend a few minutes looking at those, those kinds of issues. So um um… maybe probably a good place to start off if you don’t mind Christian is what advice you’d give to somebody starting to learn javascript so that, so that they kind of avoid some of these mistakes you know from the get go. What good principals, good foundations should they be working on?

Christian: Um… the main foundation is that javascript is a language in its own rights. It’s uh uh… you can not take any other knowledge and try to apply it on to javascript and this is where the two angles actually come where people that come from a higher programming language background trying to find the same principals that apply there inside javascript

Paul: Um hum…

Christian: Or people that come from CSS design background, basically think that it’s as easy as applying a CSS selector to an element that everything will be matched magically…

Paul: Yeah…

Christian: … and not realizing that there is an impact on speed and an impact on how the browser actually finds these things and what kind of mistakes the browser does. The main thing to remember about javascript is ah… there are many different ways of javascript, there are many different environments where it’s applied. So there is lots of really clever things being done right now with javascript, even on the service side and inside frameworks and inside API’s. But there’s also, in the end you would run it in a browser sooner or later. And if that’s where you are going to work the best advice is actually to not trust javascript ever and to actually um… enhance with it but not really rely on it.

Paul: Um hum…

Christian: So if there is a window print link, then this link should be generated with javascript and not just be an ‘href’ javascript window print because if somebody doesn’t have javascript or for some reason javascript’s broke, or the engine doesn’t work in your environment then you click the button and nothing happens. And there’s nothing worse than uh promising an end user something that you don’t deliver in the end.

Paul: Yeah.

Christian: The other thing is that uh… when you start from javascript, one of the first things to remember is that you should always learn the if statements and learn that they’re your best friend. Like never do: ‘apply something’ BUT IF ‘something’ THEN ‘apply something’. So if you…

Paul: Umm…

Christian: Try to access a heading with an ID for example, and then you don’t just do: HEADING ID ‘something’ = ‘something’… cause it might not be there.

Paul: Yeah.

Christian: So basically test for it, before you apply it. When you follow this principle through with all of your programming, this kind of defensive programming, then you will (we will) definitely write good javascript in any programming language really. Over the years when you get more and more experience you just learn more and more ways how the technology that you use fails…

Paul: Mmm…

Christian: …rather than actually succeeds. So you learn how to avoid the biggest pitfalls.

Paul: I mean, you always hear this thing don’t you about um… that not all browsers support javascript or that not all users have javascript turned on. I mean how real a problem is that? Is that being overly cautious to worry too much about that kind of thing or is it a real problem? Are there actually a lot of users out there that… that don’t have javascript for one reason or another?

Christian: It’s impossible to say. Its statistics and it’s a bit like flash. When you when you look at flash statistics and you hear like a 99% have it enabled on the Adobe side, then you’re like ‘Oh yeah really.’ because these are the only stats that you find…

Paul: Um hum…

Christian: …the company that delivers that is a bit like… yeah, I think that the Microsoft help pages with have a lot of hits from people with Windows.

Paul: Yeah.

Christian: So um… it’s not really a problem I don’t see the problem at all. I see the problem of people… uh, architecting and designing applications around the premise that javascript will be there, and everything will be happy and work.

Paul: Mmm hmm…

Christian: If you write your applications like javascript does not need to be there, but is nice when it’s there and actually makes it a lot smoother, then you don’t have a problem…

Paul: Mmm…

Christian: I don’t buy this whole argument of like… oh AJAX is so cool because we don’t’ have much traffic on our servers any longer. It’s like yeah, but you never know the environment that javascript is run in. It could…

Paul: Mmm…

Christian: …my mobile phone, it could be it could be an iPhone, it could be it could be an old browser. I just bought myself this eeePC that doesn’t have much memory. It’s uh… you can never expect the end user to actually cater their hardware to your needs…

Paul: Mmm…

Christian: So it’s pretty… it’s pretty unsafe to actually rely on it. So even if the statistics are ridiculously low, it doesn’t really matter because you don’t want to deliver a bad practice and deliver a bad experience to users.

Paul: Mmm…

Christian: And then there’s, of course, the SEO problems as well. If you have a navigation that’s dependent on javascript and doesn’t show anything – or you make elements clickable that shouldn’t be clickable, then you won’t have search engine spiders following these links and your sites won’t be indexed.

Paul: Mmm…

Christian: Same with accessibility. When you make something clickable that is not clickable by default, like a ‘span’ or a ‘div’ or whatever, then you can not expect a user agent actually to allow people with assistive technology or people that use a keyboard to use the same application because browsers are just not clever enough for that.

Paul: Mmm. So what about people, um… starting out as absolute beginners – what are the most common mistakes you’re seeing them make when they start out doing javascript?

Christian: A lot is copy and pasting and hoping that nothing breaks…

Paul: (Laughs)

Christian: …and ah… also um… a lot of it is skimming tutorials. A good tutorial writer will tell you a lot in the paragraphs between the code examples.

Paul: Mmm.

Christian: And um… just going through the code examples and trying to figure out what’s going there yourself and copy and pasting it does not really make you a good developer. This information was put there for a reason and actually explains you the smaller bits that you need to know about the language. ‘Cause most of the javascript errors that actually happen in the real world is not because you did a coding mistake, but because you made an application mistake that you expected a browser to do something. Or you expected an application to give you the right information back, where as you didn’t test for it. So um… I think trusting tutorials and uh… just copy and pasting code without actually knowing what it does is a very dangerous thing.

Paul: Mmm… Would you apply that same principal to frameworks? You know and not under… if you don’t understand what a framework is doing then it is probably best to avoid it.

Christian: Well it’s a matter of what it does. I mean uh… the last few years in web development have become a lot more transparent than before and that’s… Firebug is actually to blame for that.

Paul: Mmm…

Christian: It’s great because you can look at code that is generated by javascript or a backend application and you always know, you can always analyze the whole document ñ what’s doing on there if you know your Firebug. That’s another thing that I would actually tell any developer that would start with javascript to get his head around it’s like java… uh… Firebug is a great great way to learn from other people’s mistakes and also to monitor what’s going on in your scripts all the time. When it comes to library’s, that’s a bit of a different story because um… I had a bit of foot in mouth moment there when I proclaimed in the past that most library’s are bloated and unnecessary and um… now I am part of a library…

Paul: (Laughs)

Christian: …and uh I’m also I also talked to media AJAX to a lot of library developers and I realized that all the libraries do the same thing. All of them actually make the pain and the uncertainty that is browsers out there bearable for you.

Paul: Mmm.

Christian: So um… if you don’t understand what the source code of jQuery is, or the source code of the YUI is that does not mean that you shouldn’t use it.

Paul: Okay.

Christian: Other people have had that problem before you and loads and loads of people find bugs and submit bugs and help these libraries get better. So now a days if you are a new javascript developer I would basically say that you have learn the syntax, you have to learn the standards like what does DOM scripting mean, how does event handling work – but by all means if you go into a production please please use a library.

Paul: Oh okay.

Christian: Because that one take the cruft of all the fixing and uh… hacking that you have to do to make something work away from you.

Paul: Mmm.

Christian: It’s a matter of what you do. I mean if you’re doing a high traffic Twitter clone, or whatever, that runs an error application then you might have to these fixes – but you’re not necessarily going to do that as a new beginner.

Paul: Okay yeah… that that’s a very different opinion than I’ve heard in the past and it’s quite interesting to hear the other side of the argument. It’s good. So what about… what about dangerous people like me? So you know… where I knew nothing about javascript but I decided: ‘Yeah, I really need to learn this’. So I got a couple of books, I’ve read a couple of books and I’m kind of up and running but I’m not… you know I’m not a developer. I’m not somebody that’s an expert. You know… what other kind of common screwups you’ve seen people like me make?

Christian: Um… It’s tricky to say. It’s like most of the time, what these kind of people do is also try to solve problems that other technologies have with javascript.

Paul: Mmm…

Christian: Which is sometimes cool, but sometimes it’s also thinking about there’s a reason why that doesn’t work. So um… I mean the classic is… the classic is like rounded corners and things like that. There are loads of javascript rounded corner solutions which on the outskirt look like they are really clean solutions. This is also might be to put a class on a ‘div’ and to put a bit of javascript in and then everything has rounded corners and there’s no harm done.

Paul: Mmm.

Christian: That the javascript needs to inject a lot of HTML and probably is slow doing so. It’s the other side of the story it’s uh… I think people like you, that are just enthusiastic about it and basically want do it are not necessarily savvy of the implications that it has.

Paul: Yeah.

Christian: So the uh… the information that we need there is that we need a lot more tutorials on um… how javascript impacts performance. And we are starting with that already in the development network and other people are doing that as well, but there are lots of mistakes being done as well there. The other problem that I see with people that have just started with javascript, is they apply… they find one solution, they find one library then they become the biggest fan of that library then everything else is rubbish.

Paul: (Laughs)

Christian: And uh… that is a very dangerous attitude as well because you will not be, you will in your career work for different clients that will use different libraries as well. So you shouldn’t make yourself dependent on only one but understand what the benefits of each of them are and where you should apply them.

Paul: Um huh.

Christian: And how they actually make your life easier, or how they make your life less easy, than another competing product. So the implications there is that a lot of people use these newer libraries, or newer ways of using javascript, to actually make javascript behave like their favorite language or their favorite technology. That’s why people went nuts with every javascript library came up with the CSS selectors.

Paul: Yeah.

Christian: And that’s great because now I can go fifty levels deep in my CSS selector and the javascript finds what’s in there. While this is already an indicator that your HTML is not necessarily good structure

Paul: (Laughs)

Christian: …and it also means that if you change your HTML in the future you also have to change that path, or if you don’t change that path then your javascript will break.

Paul: Yeah.

Christian: And a lot of libraries break silently as well. So instead of just getting the error in your face that you’ve basically screwed up, you will not know what’s going on and will wonder what’s going on.

Paul: Mmm.

Christian: And when that happens that’s normally when people, like you, fire up emails to the library developers and tell them that their product is rubbish.

Paul: (Laughs) Yeah… I can’t disagree with that. That’s the kind of thing that I’d do probably. Um… what about, I’ll tell you the one thing that I’ve come across is that… I’m kind of competent enough to write functions to do a lot of the things that I need to do. Nothing really complicated, I couldn’t build anything too sophisticated, but you know enough to get me by. But then as I’m kind of looking at other people and what they’re doing um… a lot of them are using object orientated type techniques in the code that they are writing. There’s me hacking away with little functions and there seems to be some transition across object orientated approach when you kinda hit a certain level… you know why, what’s the benefits of that? Why do people take that kind of approach?

Christian: (Laughs) Um… It’s been very beneficial in other languages, and other environments, especially when the environment is rather sophisticated.

Paul: Mmm.

Christian: Then ah… you seen for example action script. Action script has been as much as a hacky javascript. Yeah, look what I can do if I do it this way language and now with the Flex frameworks, and Adobe opening up more and more to the java world, um… it’s getting more and more into structured ways. And the structured ways are hard to understand for somebody who is not from that background.

Paul: Mmm.

Christian: And I can safely say that, I’m not myself. So I um… I have a lot of problems with like properly, or massive structures, and frameworks. But when you see people do proper action script, for example, or do Rhino applications for the server in javascript, or some of the things that are happening with javascript 2… that there is a reason for that and the reason for that is the scalability is just so much bigger.

Paul: Right.

Christian: It’s uh… basically you can extend an object and I can reuse a class and I don’t have to worry about that. It’s like I start building these little small components, all of them in themselves tested and unit tested, and I know they work. And then I can build a bigger application from them.

Paul: Mmm.

Christian: Basically without really needing to know to test these things ever again.

Paul: Yeah.

Christian: That’s how things like PEAR and PHP and Perl libraries work as well. It’s people extending these kind of already existing bits, and bobs, rather than starting from scratch every time.

Paul: Mmm hum.

Christian: Most of the time for the little web development things that we do like the AJAX form or the Constentina navigation that’s not necessarily needed, but when you write a library for example, and it grows, like YUI is growing or like jQuery is growing as well… then you need to adhere to these standards ’cause otherwise everyone will just submit their own code in forms that are just terrible.

Paul: Yeah.

Christian: And there’s not much magic to it. I mean I get annoyed when I see javascript guys going on stage and saying like: ‘Well guys, this is a function and when it’s an object it’s a method and…’ and why should I know this? Well you should know this because you need to communicate with other developers as well sooner or later.

Paul: Umm hmm.

Christian: And these people speak that lingo and rather than you having to explain yourself for 15 minutes you could communicate in 3 minutes.

Paul: Mmm.

Christian: And that gives you more time for lunch break.

Paul: (Laughs) …or drinking…

Christian: So the worlds of hard core programming and javascript are actually getting closer and closer and seeing some of the things that browser vendors come out with and some of the other software that builds on web technologies that is being built at the moment, I don’t think that we can actually rely on our being the cool cookie web developer anymore.

Paul: Mmm.

Christian: It’s a bit like we have to have broaden our horizons the same way that backend people have to broaden their horizons when it comes to using javascript, but you can only make someone understand your problems when you understand how they tick.

Paul: Mmm.

Christian: Otherwise you start preaching to the choir.

Paul: Yeah. Okay here’s the last question to wrap up with. I’m going to open it up and let you rant uncontrollably. What are the worst mistakes that you’re seeing at the moment made with javascript, just generally.

Christian: Uh. The worst mistakes that I see are that people write little scripts for tasks over and over again.

Paul: Okay.

Christian: The same task and I see them actually tying the interface a lot to the javascript. So…

Paul: What do you mean by that?

Christian: Instead of making a javascript that actually creates the things it needs, there will be HTML that is just not necessary where the is not javascript available.

Paul: Okay yeah.

Christian: So instead of starting with the proper HTML and CSS structure, you basically have this whole gumph of HTML because there’s the javascript to clean it up anyways.

Paul: Yeah.

Christian: So um… basically the main tip is you will never ever be able to replace a proper HTML structure. It doesn’t matter where technology is going because technology will go away from that sooner or later, but at least a human could actually go there and see that there is a structure.

Paul: Mmm hum.

Christian: And that there’s a way to convert this to something better in a second step. If you’ve created a lot of spaghetti code with like HTML and javascript mixed in and lots of little scripts in there, then you will never be able to convert that to something better in the future and this is what we’ve been running in circles for years and years. We’ve never been improving things, we’ve just been fixing things and adding little bits, and bobs, to it.

Paul: (Laughs)

Christian: The other thing that I keeps seeing is well the fan boy thing, about javascript libraries and of the academic way of some people measuring javascript. You have all these like, I mean there’s people that spend like weeks finding different javascript includes and script libraries and measuring how fast they are on their computer…

Paul: (Laughs)

Christian: …generating twelve thousand objects and trying to put them on dominoes. Show me the application that needs that done, then your comparison actually makes sense.

Paul: Yeah.

Christian: It’s the same as CSS. You have like ’10 Most CSS Tricks That You Never Knew’ or ’10 Most Beautiful Naviagations’. It’s like list blog posts digging their way through the internet.

Paul: (Laughs)

Christian: And it’s the same way there right now, like I can appear immensely cleaver if I just put loads and loads of effort comparing things to each other. Instead of saying ‘this’ means use ‘that one for this one’ and ‘use that one for this one’ cause the benefits of that one library is ‘this’ and the benefits of the other library are ‘that’.

Paul: Yeah.

Christian: It normally is like, ‘Oh yeah… that library won.’ or ‘All of the others are bad’.

Paul: Yeah.

Christian: And that’s never the case.

Paul: Hmmm.

Christian: We have to get away from this putting things together randomly and making up an application, to a proper web application design and I’m going to be in New York at the end of the month, no actually beginning of next month at AJAX Worlds and my talk there will be about how to do javascript design and javascript architecture of big applications.

Paul: Mmm hmm.

Christian: That’s going to be quite interesting feedback from the audience I’m quite sure about this, but it’s a matter that we grow up, we actually have to grow up as web developers and take our stuff serious and actually make sure that we don’t build for ourselves – but we build for the guy that comes after us cause that will always happen as well.

Paul: Yeah… and that’s really good advice.

Christian: If you think like that, then you will never write bad code and sometimes people just have to suffer that themselves before they start doing it.

Paul: Mmm.

Christian: It’s always clever to think of yourself as the javascript god that can do things better anyways, but some times it’s good to leave your superhero skills in the corner and just do something that works and that’s understandable and spend some time documenting for the next guy that has to take it over from you.

Paul: And I think that applies to everybody you know people, even people doing HTML or CSS or server side stuff thinking about the next person is, yeah, hugely important.

Christian: Yeah.

Paul: Thank you so much Christian. That was very useful and I really appreciate you taking the time to come on the show on Valentine’s of all days. Good to talk to you Christian and we’ll speak soon.

Christian: See you soon. Bye.

Listeners email:

Rolling out new features

Our first listener comment is from Alex who has come up with a clever little approach for educating existing users about new features…

I just listened to show 112, where you mentioned Christian Heilmann’s javascript walkthroughs. These walkthroughs reminded me that I wanted to do something similar for our website, except I wasn’t able to squeeze it in before the deadline.

My workplace decided on a total revamp of their website, and the final design had some substantial visual and navigational changes. Among other changes, disparate logins had been consolidated into one login button. Of course, now we had the problem of habitual users; because the website hadn’t changed for several years, how do we now try to avoid several hundred support calls asking where the logins have gone?

Well, the obvious solution is to not make such drastic changes. Going for evolution, not revolution and whatnot. Failing that, is something like Christian’s walkthrough popups. However, these would still show up for new users, for whom this information would prove totally useless.

Here’s the solution I had planned:

A couple weeks before the new site or feature launch, we use javascript to set a cookie. This accomplishes two things: 1) we target people who have javascript, so we know the popups will work for them, and 2) we’ll know they were at this page *before* we changed the design or added a feature. Now, once we launch, we check for that cookie using PHP (or other server-side scripting). Why do this on the server side? Well, it lets us avoid even inserting the popup code for people who don’t have the cookie. If the cookie exists, we can then delete the cookie (so they don’t see the walkthrough again), and then insert the walkthrough divs and javascript.

Even though I didn’t get a chance to implement it, maybe this will help other people prepare for site overhauls.

What a great idea Alex. Existing users rarely like sudden changes to the sites they use regularly and often need a lot of help making the transition. This is an excellent way of doing that without confusing new users with unnecessary information.

Content management and CSS

Our second listener contribution is a question from Adrian…

Thank you very much for the show – it has been so helpful!

I have been given the job of creating an Intranet site for a small business. After listening to your shows I would love to create this website using webstandards and have been learning CSS. As well as this it is important that the users of the site can modify the content via a CMS.

So my questions are; can both of these things be satisfied? Also is it possible to design the website using webstandards and then “plug” a CMS into the already created website?

It is definitely possible for content providers to update content built using CSS. In fact it is easier, and allows the designer to maintain more control over the design. Traditionally content providers had to make all kinds of design decisions when adding content. If they needed to add a heading they had to decide what that heading looked like. If they wanted to make a piece of content stand out, they would pick a colour and font size to make that happen.

However, when a site has been built with standards the content provider doesn’t need to worry about what content will look like. They simply say this is a heading by defining it as an H1 and the CSS will decide how to style this. Equally to make something stand out they mark it as strong and the style sheet does the rest. Simple.

The only problem is that some content management systems do not have WYSIWYG editors capable of supporting this approach. They are still focused on giving the content provider design control. Fortunately there are editors out there that do think in this way. A good example is xstandard although there are others. These can just be dropped into your CMS.

Finally, it is certainly possible to plug standards based code into a CMS. Infact, it is actually easier because the style and content have been separated. A content management system is (as it name suggests) primarily concerned with content. It doesn’t care about how that content is styled. Nothing makes integration easier than nice clean meaningful markup, unencumbered by formatting.

Worthy of your attention in 2008

Posted in Web strategy on January 10, 2008 by Paul Boag

I want to look at 5 areas that need our attention if we want to ensure our careers stay on track in 2008.

As web designers we are all busy people. We are in such a fast moving sector that it can be hard to know what is worthy of our attention. Should we be focusing on Silverlight or brushing up on Javascript? Learning Rails or grappling with mobile devices? In this post I want to share my thoughts of where you should be focusing your energies in 2008.

I hate the raft of predication posts you see at the beginning of each year. I have intentionally tried to distance this one by leaving it a couple of weeks and by focusing on what we need to do rather than what might happen.

I want to look at 5 areas that need our attention if we want to ensure our careers stay on track in 2008. Of course, these are very generic choices and won’t apply to every web designer. If you specialise then this post is probably not for you. However, if you are a bit of an all rounder like me then it maybe relevant.

Focus 1: The rise of Javascript

Year on year we are seeing more and more creative things done at the cutting edge of web design using Javascript (and AJAX). However, despite that many of us still haven’t taken the time to become comfortable writing Javascript from scratch. Developers often consider it below them and designers find it too intimidating.

Until now we have largely been able to get away with it. We have copied and pasted when we need a certain bit of functionality and most of us haven’t had to build anything too complex that required Javascript. However, I believe that time is over. If you don’t know Javascript inside out in 2008 then I think it will really start to damage your career.

Having a good grasp of Javascript and indeed AJAX will be as much a requirement as knowing HTML and CSS. If you are a freelancer then you are going to struggle to fulfil client requirements and if you are in a full time job the next one is going to be hard to find without it.

Focus 2: The decline of web 2.0.

I don’t care what anybody else says we are in a bubble. I lived through the last one and this is another without a doubt. However, the problem with calling it a bubble is that it implies it will burst. I don’t necessarily think that will happen but I do believe it will slowly deflate like a soufflé over the coming year.

What does this mean to us as web designers? Well it could either mean very little or a hell of a lot depending on your circumstances. If you work for a web 2.0. company either directly or indirectly (your clients are web 2.0. companies) then I would be afraid. I can see many of these companies going under in the coming year and so you could well be without a job or loosing a lot of work.

If like the majority of us you aren’t working for a web 2.0. firm then the effect on you maybe minimal especially if you are working as an in-house designer/developer for an established company. However, if you work for an agency or are a freelancer you may see things becoming tougher.

At the moment there aren’t enough web designers out there for all the work that is about. Remove the majority of web 2.0. companies and suddenly you see a more competitive sector.

My advice, make sure you are working for a web established company or have a superb reputation to ensure you keep the work coming in when times get tough.

Focus 3: The necessity of frameworks

As times get tougher and competition gets more intense prices will start to drop. We wont be able to demand the rates we currently charge out at. Therefore efficiency will become king. We will need to work smarter if we are going to still make money.

Although I am not a great fan of frameworks I do think they will become important in this more competitive environment. Used right, frameworks allow for speed of production and keep costs down. Whether this means using “off the shelf frameworks” or developing them in-house I do not know. However, the key will be efficiency whether we are building applications, writing HTML/CSS or implementing Javascript.

Focus 4: The mobile web

But it is not all doom and gloom. As one door closes (those unrealistic web 2.0. businesses) another will open in the form of the mobile web. Whatever you think of the iphone and its lack of key features, it has stimulated the mobile market especially when it comes to the mobile web. We are seeing a growing number of competitive devices all of which have a strong mobile web component.

The mobile web offers a massive opportunity for a web designers career. With mainstream web design becoming increasingly competitive, the mobile web offers a new frontier where there are far fewer players. Being able to offer your clients mobile web services will start to prove beneficial as the year draws on and you may even find employers starting to ask for experience in this area when recruiting.

Take the time to learn the basics of designing for the mobile web this year. It will quickly pay off.

Focus 5: Widgets and the desktop

Finally, I believe 2008 should be the year that you look beyond building websites. For a while now the bigger players have been pushing their content out beyond the confines of their sites. Take ebay for example. You can view ebay products on other sites via widgets or even on your desktop through AIR applications. I don’t think it will be long now before mainstream website managers will want to do the same and it will be down to you to deliver.

Take the time to become familiar with some of the different widget and desktop standards out there. Admittedly there are a lot so if you are looking for one to start with I would recommend AIR from Adobe. I believe that being able to build AIR applications in 2008 will prove very beneficial.

So there you have it. Obviously this is not a comprehensive list and all of this is very subjective. However these will certainly be the areas I will be focusing on for 2008.

Top Geek Gifts

Posted in Reviews on December 14, 2007 by Paul Boag

So this holiday season (previously known as Christmas), what gifts would you recommend others buy for the geek in their life? Here are my top 10…

These are products I own myself and would happily recommend to others. They are not in order and I have tried to pick things that suit varying budgets.

1. A mac

2007 was the year I moved from a PC to a mac and I have never looked back. Best of all if you have the budget they make great gifts. They look cool, are a pleasure to setup (no swearing on christmas day when something doesn’t work) and if you give him a week he will be insisting that you have one too so he no longer has to provide technical support for windows. Buying a computer can be scary if your not technical yourself so I suggest going along to an apple store. Those guys will be able to help you with selecting the model that best suits the geek in your life.

Prices start at £700 and are available through the Apple Store.

2. An ipod touch

I actually don’t own an ipod touch but I do have an iphone. However, I thought it was unfair to suggest something that has a £35 per month contract associated with it! I love my iphone and can’t imagine anybody not being pleased with an ipod touch. They are sexy, fun to use and definitely a cool toy for christmas day if they haven’t played with one before.

The 16GB version of the ipod touch (which is the one you should buy) costs £269 and is available through the Apple Store.

3. The Jawbone

The Jawbone is a bluetooth headset unlike any other. I have awful hearing and have trouble with mobile phone conversations. The Jawbone however has amazing noise cancelling technology that makes calls crystal clear no matter how noisy the surroundings. Best of all it looks cool and you almost don’t feel ashamed to wear it in public (unlike most headsets). In my opinion the Jawbone is the best headset on the market.

You can buy the Jawbone in pretty much any mobile phone shop and I have seen prices as low at £64.

4. Getting Things Done

Most geeks I know live a life in chaos. Getting Things Done is a superb book that has transformed my life and made me a more organised person. If the geek in your life does not read then buy it as an audio book and pre-install it on his new ipod touch!

You can buy the book for £7.14 on Amazon or for $12.60 as an audio book from Audible.com

5. Moo Cards

Moo Cards are cool little cards similar to mini business cards. You can print 100 cards for £9.99 and each card can have its own unique photo. You can either upload photos or just grab some random photos from his flickr account.

6. A flickr pro account

Talking of flickr why not upgrade him to a pro account this christmas. Flickr is the most awesome photo sharing site around and although it has a free account it is definitely worth upgrading. For just $25 the geek in your life can upload a limitless number of photos.

7. A Tom Tom

My sense of direction sucks and I couldn’t live without my Tom Tom GPS. Chances are the geek in your life doesn’t get out much, but when he does he wanders around looking lost and confused. A cool GPS in your car might encourage him to venture out of the house more. You never know.

They seem to sell Tom Toms pretty much everywhere these days from Halford to Currys. Prices seem to start at the £149 mark. To be honest the lower end models seem perfectly good from what I can tell.

8. A DVR

A DVR is a Digital Video Recorder such as the TiVo in the states or Sky Plus in the UK. These clever little boxes let you record programs to a hard drive, pause live TV and series link an entire season of a show ensuring you never miss it again. Having one of these babies will change the way he watches TV forever.

If you buy Sky Plus online at the moment you can get the box for £49. Of course it does require a sky subscription which starts at £16 per month.

9. A Duct Tape Wallet

Okay admittedly a wallet isn’t the most hi tech gift but Duct Tape Wallets are cool. Basically they are… well… wallets made out of duct tape. I know that sounds strange but they make a great stocking stuffer. Mine has lasted forever, it always generates discussion and its easy to repair (stick more duct tape on it).

I bought mine from Ducti and it cost about £15.

10. A Wii

I know there is world wide shortage of these babies but try to get one. The geek in your life may sneer at it but they are strangely addictive. The novelty will wear off after a while but not before you have had many hours of fun watching your geek actually taking exercise and socialising with others!

Good luck finding one of these. Prices seem to range from about £270 to Millions on Ebay at the moment.

Actually looking back through this list I think I would recommend most of those gifts for pretty much anybody. However, the real question is what would you recommend? Add your suggestions to the comments.

Show 97: FoWA

Posted in Classic shows on October 9, 2007 by Paul Boag

On this week’s show: Paul proposes tactics for overcoming design by committee. Marcus talks about extracting a budget from clients and Dan Cederholm compares pixels, ems and percentages.

Podcast: Download (27.0MB)

Download this show.

Launch our podcast player

News and events | Extracting a budget from your prospects | Avoiding design by committee | Dan Cederholm on ems vs pixels vs percentages | Question of the week

About 100th episode

We really want the 100th episode to be as interactive as possible while keeping the format of the normal show. So with this in mind here is what we have in mind for our live show…

News – This will be the top 4 news stories that have most effected web design since the shows launch in August 2005
Marcus – Most unreasonable client
Paul – The worst web design mistakes of all time
Ask the expert – Ask Paul and Marcus any question you want whether it is related to web design or not

You can either turn up on the night and contribute or send us an email or MP3 with your contribution to any of the above areas.

News and events

Gossip from FoWA

I wanted to share a little about the FoWA conference I have just attended. It was absolutely superb and I am extremely glad I attended. The speaker line up was excellent and the subject matter was inspiring. There was a good supporting expo which was great as it prevented the problems that have occurred previously of sponsors touting their wares in the speaking slots.

However, I am not bringing it up simply to gloat that I was there and you weren’t. I got to speak to some great people and leant a few things that is worth passing on. Firstly, it is very apparent that the power of podcasting as a marketing medium is really on the rise. I had a long chat with David Prager and Jay Adelson about Revision 3 the company that produces Diggnation among other shows. It sounds like things are going great for them and they are pulling in some big name advertisers. However, the advertising model is not the only approach that is working within podcasting. The other is the promotional approach where you showcase products that subscribers can then buy. This is perfectly demonstrated by Wine Library TV hosted by Gary Vaynerchuk that allows you to purchase the wines reviewed in the show. I was fortune enough to meet Gary at FoWA and it is obvious that it is passion for the subject and strength of personality that makes the show work.

Of course the real power of podcasting was demonstrated in the live taping of a diggnation episode. I estimate that approximately 1200 people turned up for the recording and it was more like a rock concert than a geek conference. Kevin Rose and Alex Albrecht (the hosts of the show) were pretty much mobbed after the show by insane fans. It was almost scary and drove home the power of the medium.

I could talk about some of the great speakers I got to hear including a stella performance by Daniel Burka who gave his first ever conference presentation. However, I don’t have the time to cover it all so want to share instead a couple of rumors surrounding Google. The first is that the fabled gPhone from Google is in fact going to be an operating system rather than a specific hardware device. If this is true it could well introduce yet another platform for creating cool web based mobile applications. Finally I wanted to mention the imminent announcement of Google in relationship to its APIs. It would appear Google is about to open up its many online offers from Gmail to Docs allowing third parties to build web applications based on them. This will really open up the opportunities for developers to really innovate.

The average website visitor

The next news story of the day is yet another list from Smashing Magazine (this is getting boring now). This one attempts to bring together some general stats on website users from various sources. Although the article acknowledges that really you need to look at your own stats it does explain that from time to time you want a more general picture of the average web user.

The post therefore lists 8 facts you should know about the average user. These include (but are not limited to)…

The most popular browsers (bet you can’t guess!)
Most common screen resolution
Most popular operating system
Most popular browser family worldwide
Most popular browser in Europe
Most common browser size

Getting started with Photoshop

We know that not everybody who listens to this show are web designers. Some of you are developers, clients or students. Some of you are just starting out in web design. If you fall into any of the above but want to get a better understanding of a key tool of the web designer then you maybe interested in a new article by Sitepoint. This detailed tutorial is an introduction to using Photoshop.

This is an amazingly detailed introduction that covers everything from the user interface right the way through to working with Alpha Channels. As you can imagine it is a long read but if you have the time I cannot think of a better introduction to this hugely powerful image editor.

Waking the sleepers

Last up today is a post by the guys over at 37 Signals. The post is primarily written for those running web applications but actually the principles apply to a much broader audience. It is looking at the subject of sleepers. Sleepers are those users who sign up for your service but never use it (or stop using it). This clearly applies to web applications but is also applicable to ecommerce sites or even sites that offer newsletters or other registered features.

It asks how these users can be reinvigorated and encouraged to become active again. Using an email from StumbleUpon as an example the post suggests so good ways of breathing some life back into your users.

If you are struggling with an apathetic user base this is worth a quick look.

Marcus’ bit: Extracting the budget from clients

So here’s the situation: I receive an invitation to tender in my inbox from a potentially good client. The brief is well written and, for the most part, the requirements are clear. The first thing I do is check the timescales, second is to see what the budget is. But what if the brief does not include a budget? How do you extract the budget from the client?

Paul’s corner: Avoiding design by committee

So I have now reached chapter 4 of my book writing marathon and in line with my commitment to recycling I want to share with you some of the content from my initial draft. Chapter 4 focuses on the role of the client in the design process and one of the big challenges that they face is design by committee. Of course, avoiding design by committee is something designers want to avoid too which is why I thought it would be a good subject to cover on the show.

Ask the expert: Dan Cederholm on ems vs pixels vs percentages

Paul: So one of the most common questions that I seem to get time and time again as far as CSS is concerned, revolves around working with ems and pixels and percentages and what to use when and how to work out what you should be using and all of that kind of thing. So, I thought, “Let’s get an expert in.” And so, I have Dan Cederholm joining me. (Dan Snickering) Hello, Dan.

Dan Cederholm: Hello Paul!

Paul: Don’t snicker! You are the expert for today.

Dan Cederholm: (laughing) I’ll try to be. I’ll put on my “expert hat”.

Paul: Just go with the flow, its fine.

Dan Cederholm: I will. (laughs some more)

Paul: Okay. So Dan, like I said, this is a common question that we get asked and I’m just interested in your opinion about “When’s the right time to use what combination? Should we mainly be using ems? Should we mainly be using percentages? Should we be going pixels?” What’s your take on the discussion?

Dan Cederholm: Well I think it, in a very politicianesque way, I’d say it depends. (Paul laughing) And this call is over. I could just hang up now (Dan laughs).

Paul: Okay

Dan Cederholm: No, I’m just kidding, it depends.

Paul: Depends on what then? (Paul laughs)

Dan Cederholm: Yeah, so it depends. Now are you referring to strictly font sizing or units in general for boxes and things?

Paul: I mean, there’s lots of different things isn’t there? (Dan: Yeah) There’s kind of, do we make, you know, when we design a whole web site, should the web site be fixed width? Should it be hybrid? Should it be fluid? Should it be built so its elastic? Let’s start with that as the discussion.

Dan Cederholm: Okay. Width in general… Well, I think, like I said, it does depend. It’s a tough decision to make depending on the site and depending on what’s in the site and the design and that kinda thing. It can be tricky. I love EM based design. And that’s what I use currently on SimpleBits and a few other sites that I’ve done recently. But, I’ve actually been sort of re-thinking that because its difficult to do… to drop in say an image or something that’s fixed width in that design and still account for that fixed element to be cut off or to look odd when the text is re-sized or if the text, the base font size is different. To me, the difficulty with an em-based layout is sort of the fixed image problems. So, for instance, on SimpleBits, for my blog posts I’ve been wanting to do more visual stuff like drop in an image from Flickr or a photograph or something.

Paul: Sure.

Dan Cederholm: But that becomes difficult because its em-based. If the image is a fixed pixel width, obviously its hard to just drop that in and design around it so that it looks like its meant to be there, you know?

Paul: Mmm Hmm

Dan Cederholm: And now there are tricks that people have experimented with, with em-based and setting the image width as well.

Paul: Right

Dan Cederholm: But that, of course, gets tricky when if the image is blown up it looks, you know, it will look terrible or shrunk down or won’t look as nice as it would if it was re-sized properly. To me, that’s the biggest drawback to em-based layouts. So, depending on the site, if the site is not image heavy or if you’re not going to be doing a lot of that sort of image stuff, then em-based styles can be excellent and they can provide, sort of that flexibility, almost like zooming in and out just by changing the font size.

Paul: So would your recommend that over, say, a percentage-based layout?

Dan Cederholm: Well I think that… I like the… They each have their own, sort of pros and cons. The percentage-based layout is great as well. So that’s fluid, or liquid, right?

Paul: Yeah.

Dan Cederholm: And that, that gives a little more control to the reader, because they can stretch their window out. Now, the main problem there is the “max-width” and “min-width” in Internet Explorer 6 and below. So, the common problem with that, or why people don’t use liquid layout is if you stretch the window out really, really wide, then line length becomes a problem with readability.

Paul: Mmm Hmm.

Dan Cederholm: But, that can be solved by setting a max-width to certain things. So in IE 6 and below, that’s not supported aside from some javascript hack or something. But, liquid layouts do offer that extra control for the reader. Some people… its weird, its like a religious sort of divide. Some people hate liquid layouts. Some people love them or swear by them. Its interesting how people can get. It can be a heated debate with designers. I found… it’s interesting with uhm… so, the iPhone came out over here in the US and I found liquid layouts actually look far better in the iPhone because of that small window width and that becomes even more of an advantage on a smaller screen. As opposed to fixed-width layout or even an em-based layout, the viewport isn’t necessarily computed correctly and you don’t take advantage of the full screen, whereas with a liquid layout, it does.

Paul: So when you do, say an em-based layout or a full liquid layout, what about things like margins and padding? Do you do those in the same settings or do you do those using pixels, or how do you work with those?

Dan Cederholm: Yeah, that’s a good question. So, one of the … the tough parts of a liquid layout or percentage-based IS margins and padding, because often times you need to add extra elements to add padding around, say if you want a fixed gutter width between columns. Unless you’re specifying percentage, like let’s say its a simple 2-column layout. The left column is 70% and the right column is 30%, which equals 100%. You can’t say the 70% block has a margin right of 10 pixels because now its 100% plus 10 pixels, which doesn’t work.

Paul: Yeah.

Dan Cederholm: So, you could either… there’s a couple choices… You could do a percentage gutter, so you have like 70, uh sorry, 65% with a 5% right margin and then 30% on the other side. Or, the other option would be to add another element sort of like a div that’s inside of each and the add a pixel amount to that without a width at all. So, there’s extra markup involved there. One of the things I like about ems is that instead of worrying about percentages, ems are… you can add… its easier to add gutters and padding with ems because the math works. (Dan Laughs, Paul agrees) So, you’ve got a whole width for the layout of say, 70 ems, or whatever it is and then you can break that up doing the math properly with the width of the columns and the width of the gutters as well. So, percentages are tricky because you can’t go above 100% and you can’t take away from a percentage with a pixel amount.

Paul: Yeah.

Dan Cederholm: Take away, or add with a pixel amount. So if you want fixed width gutters with liquid layout, it often requires extra markup to do that.

Paul: What about when it comes to typography? Are you suggesting always go with ems in situation like that? Because you’ve then got to add just more complexities too. You’ve got keywords that you can kind of throw into the mix there as well.

Dan Cederholm: Right. Right. Yeah, I prefer… in my own work, I prefer to use the keyword as a base. So, I’ll use “small” as a base on the body.

Paul: Right.

Dan Cederholm: And then use percentages for going up or down from there. So, headings may be 120% for a heading or whatever and then paragraphs would be 90 or that kind of thing. I like that because to me its sort of, ok, this is a base line. I know its not going to be the exactly the same in all browsers but I’ve had good luck with getting pretty damn close cross-browser sizing that way. The other way to do it is with ems and there’s a great article by Richard Rutter, actually, about sizing text with ems that he wrote a few years ago. And he explains a way of using a percentage as a base to knock it down to.. oh, are you familiar with it?

Paul: Yeah.

Dan Cederholm: And then that sort of… you can relate em units to pixel amounts. So, if you’re used to sizing text with pixels but want to use ems, he explains a way of sort of knocking down that base so that the math becomes simpler and using… specifying ems but thinking what that would be in a pixel amount.

Paul: Yeah, which is the approach that I normally use. The only thing that kind of (Dan: It is? Okay.) does my head in about that is that obviously ems inherit from one another.

Dan Cederholm: Right, exactly.

Paul: And that’s where it gets really confusing.

Dan Cederholm: It really does, doesn’t it? I mean especially if you’re nesting more than one level deep. Then the math becomes mind boggling.

Dan Cederholm: And so that still happens with the keyword percentage model that I use often… the same problem… so when you’re nesting percentages, things start to get a little weird. It becomes a little difficult to do the math but I found that I’m not often nesting too far… you know, more than maybe two levels or so when I’m sizing things. And if I am, then unfortunately, I have to do the math or try a different approach but, yeah, that is a tricky part of ems or percentages. In a perfect, ideal world, I think the designer could specify pixel, right, and then the browser would resize it from there but, you know, IE actually 7 and 6 and 5 don’t let you resize the text and I’m kinda baffled why its still a problem in IE 7. So, that would be ideal because the designer can say, “Look, this is what I intended to be as a base and this is gonna look the same across browsers for the most part for most resolutions and then the user can always over-ride that.” I mean, the user should always be able to over-ride that. But, unfortunately, for baffling reasons, they chose not to let someone do that in IE. So, that goes back to, I guess, your site statistics and if IE is a low percentage, which is probably not going to be the case for most sites, you could sort of weigh that and can say, “Well, I’ll go with pixels.” And, I mean, a lot of people do go with pixels now anyway, and just not worry about it. But I tend to, you know, I bump up si… I don’t wear glasses, for instance, and I bump the text size up on a lot of sites.

Paul: Yeah, I do too.

Dan Cederholm: And so, if I’m doing that, and I have pretty good eye-sight, I imagine a lot of people would as well.

Paul: Ok so what…

Dan Cederholm: Having that control is important.

Paul: Yeah. So, one last question before I let you go (Dan: Yeah) and get back to your normal work… You were talking about browsers there. And so, Internet Explorer 7 has come along with sort of this zoom page functionality.

Dan Cederholm: Right.

Paul: How does that enter in all of this? Does it change the landscape in any way?

Dan Cederholm: I think it definitely helps. That’s what sort of baffles me even more. I’m using the word, “baffle” a lot today. (Paul laughs, Dan chuckles) Why they would add the page zoom to IE 7 but not allow you to re-size font set in pixels. So, I think it helps in a way but the problem there is that it will… your viewport stays the same. So, when you zoom the layout, you’ll start to get horizontal scroll bars and you’ll have to sort of navigate the page that way, whereas just zooming the text, the viewport stays the same and you can read the page a little easier, I find. I mean, it’d be interesting to talk to someone that has low vision and uses, you know, zoom or text bumping up on a regular basis. I think that that’s sort of the… the downside I see to it is that its, it can help but, let’s say that you’re looking at a block of text and you use the page zoom feature and you’re window is small. Let’s say you’re on a small screen device or something or at least you’re monitor is small or whatever. So, zooming in will make it easier to read but you might have to do some extra navigating of the windows to keep reading that. Whereas bumping up the text, you shouldn’t have to do that. It should stay within it’s container and the window should just… yeah, you’d be scrolling down but you won’t be scrolling horizontally.

Paul: I mean that’s a particular problem, isn’t it? With fluid designs, I’ve noticed, with a zoom function that as soon as you start zooming on a fluid web site,

Dan Cederholm: Oh, right.

Paul (continues): you immediately get horizontal scroll bars. Which to me, is ridiculous.

Dan Cederholm (laughing): Right, right. Exactly! Right, so in bumping up the text in a fluid design, should be, I think, should be a lot more… better an experience. That brings up a good point though, with em-based design. Now, when you’re bumping the text with an em-based design, the entire layout, if they layout is set in ems as well, the whole layout will expand. Sort of like zoom, but… So, that’s something to consider as well. Where the layout could go beyond the viewport, you could get horizontal scroll bars as well there. So if you have an extra wide layout in ems, that can be an issue. Just bumping it up one notch or two notches could cause that sort of scrolling problem.

Paul: Yeah. So, the long and the short of this, is there’s no right answer, is there?

Paul: There’s no perfect solution here.

Dan Cederholm: Yeah, there really isn’t.

Dan Cederholm: I mean, like a lot of things in web design, there’s not… yeah, it sort of just depends on a case-by-case. I mean, people fall into sort of things that work for them, you know, like I use the “keyword/percentage” thing and that just seems to work. Other people like the em-based approach to text sizing. But neither one is really right. I think you’re correct in saying there is no real right answer at this point. It will be interesting to see how CSS evolves and affects the way we layout pages. Just the other day, I was looking at the CSS 3 grid layout draft.

Paul: Bleh!

Dan Cederholm: Yeah. (laughs) Which is pretty amazing. And maybe we’ll be able to use it in the next fifty years.

Paul: Well on that cheery thought, (Dan (laughing): Sorry) I’ll have to grapple with CCS 3.

Paul: Thank you so much for your time, Dan. I appreciate you coming and explaining the different options that are available.

Dan Cederholm: Ahh! Its my pleasure. Thanks for having me.

Question of the week

Pxels, ems, percentages… which do you use the most? Answer in the comments.

Show 96: Moll on Mobile

Posted in Classic shows on October 2, 2007 by Paul Boag

On this week’s show: Paul suggests some ways a client can pick which agencies to ask to tender. Marcus asks when is speculative design okay and Cameron Moll explaining how to get started on the mobile web.

Podcast: Download (31.0MB)

Download this show.

Launch our podcast player

News and events | When is speculative design okay? | Who to ask to tender? | Cameron Moll on the mobile web

News and events

Social Participation as a business tool

Back in 2006 I spoke at refresh06. One of the presentations I gave there has since proved a popular subject and I have been asked to speak on it again a number of times in various forms. It is on the subject of social participation and how to use it as a marketing and business tool. Social networks and communities are often seen as the domain of the teenage crowd with sites like YouTube and MySpace dominated by this demographic. However, community based applications are applicable to all audiences and can be a powerful tool for businesses.

After preparing the latest incarnation for a presentation I am giving at IBM, I thought I would do a run through (as I have only limited time). Discovering the new record feature in keynote I decided to record the whole thing and upload it for all to see. Hope it is useful.

Test your website for mobile compatibility

So this week we have Cameron Moll on the show talking about some of things covered in his new book “Mobile Web Design”. In his book he mentions an interesting site that I would like to pass on to you. It is a web application that allows you to test how well your website would appear on a mobile device. You simply enter your website address, wait while it calculates your results (it even gives a random mobile web development tip while you wait) and then view a complete breakdown of any issues with your site.

The report is distilled down into a single score but you can also see performance in each of the individual areas including:

Speed
Cost in terms of data access
Quality of code

and a whole host of miscellaneous tests. However, best of all is the fact that it also provides an emulation of what your site would look like on a whole host of mobile devices.

Laying out inline images

My next story tackles one of the mixed blessing of content management systems. Although it is great that content management systems allow clients to add content themselves they almost always fine a way of screw up the look of a site in the process. One way that they manage this is adding inline images. They are often required to add specific classes to images for them to be displayed correctly. Unsurprisingly the client sometimes fails to do this and the design becomes broken.

This week the List Apart website proposes one way to slightly reduce this risk. They use javascript to detect content images on a page and then apply different classes based on the width of the image in relation to its containing tag. In other words the Javascript detects whether the image is a full column, half column, or quarter column image and lays it out appropriately.

Its not the perfect solution and there are still ample other ways clients can screw up a design but it is a nice use of javascript that enhances a design without being mission critical. I think seeing this kind of use of Javascript and we should all be looking to use it for this type of thing.

10 Usability nightmares you should be aware of

My last story this week is another top ten list from the guys at smashing magazine (they do like their lists!). This one is a list of the top 10 usability mistakes and I have to say it is an entertaining list focusing on some big name sites. The list includes:

Hidden log-in links
Pop-ups for content presentation
Dragging instead of vertical navigation
Invisible links
Visual noise
Dead end
Content blocks layering upon each other
Dynamic navigation
Drop-Down Menus
Blinking images

Each mistake is explained in detail including some offending screenshots. A worthwhile read for us all.

Marcus’ bit: When is speculative design okay?

I have decided to talk about speculative design work this week because we have recently produced a couple of designs and, although we recommend that it should be avoided, sometimes you simply can’t.

Unpaid prospective work is the bane of all of graphic based agencies and freelancers. It’s also something we have looked at before, but it’s such a significant subject I think it’s a good idea to look at it again.

The worst case

Some ‘clients’, and I use the word loosely, are simply looking for free work. It seems that they think ‘art’ or ‘drawing’ is not real work and is something that only fools pay for. They usually ask for a number of different page designs and concepts and will often ask for revisions on delivered designs.

The project often ends up being dropped by ‘the board’ and then mysteriously, a few months later, something very similar to your design appears for all to see.
These people are effectively stealing from you. Don’t do it.

When is it ok?

If you take the line that we should never do unpaid work then the answer is ‘never’.

However, life simply isn’t like that so you need to make some choices. You could argue that as long as the client is genuine i.e. it’s a real project that someone will win and subsequently get paid for, then it’s ok. It’s a fair fight and the best design will win.

But, this isn’t just about getting paid.

Educate (how many times do I use that as a heading!)

Speculative design is a beauty contest. The whole point of the exercise is to impress the client. This can possibly be seen as taking a somewhat derogatory view of a client’s ability to make the distinction between a design for them versus a design for their users. But even for those that understand the distinction, I don’t think it is possible to separate ‘what I like’ from ‘what is right for our users’. If there is a choice, then people can’t help picking the one they like best.

Added to this, there’s the big issue of designing in the dark. Even if a client has supplied a detailed brief and they’re happy to chat on the phone, the guy pitching still doesn’t really know what the requirements are. The early part of any design project involves detailed discussions about an organisations USPs, target audience, brand values, site statistics, site goals, etc etc.
User interface design is a collaborative process between the agency and the client that goes through an iterative cycle based on user feedback. This simply doesn’t happen with speculative design work.
So, in summary, always have this conversation with prospective clients. I know for a fact that on one job, we won the work by doing so. The client saw it as the most professional and well thought through approach taken by the agencies pitching for the job.

However, sometimes you have to do it or you will jeopardise your chance of winning the work – but still have the conversation and ask whether or not producing an initial concept will adversely affect your bid.

Paul’s corner: Who to ask to tender?

With literally millions of web design companies worldwide where do you begin when trying to draw up a list of potential agencies? Who do you invite to tender?

Ask the expert: Cameron Moll on the mobile web

Paul: Okay so joining me today is Cameron Moll. Good to have you on the show Cameron.

Cameron Moll: Hey, thanks Paul.

Paul: I think this is your first time on Boagworld, is it not?

Cameron Moll: Yeah it is.

Paul: Ah that’s good stuff we alway like to get new people on instead of having the same old boring people on every time. Nice to get someone from the States as well. Which is good.

Cameron Moll: Yeah absolutely and I’m kinda bummed you didn’t pick me for your hundredth episode.

Paul: Well if your in London you can come to our hundredth episode and join in the show. Do you happen to be over then by any chance?

Cameron Moll: Uh, when’s that gonna be.

Paul: Uh, October 20.

Cameron Moll: Um, unfortunately not.

Paul: Argg.Shame, what a shame. Yeah, so we’re looking forward to our hundredth that should be fun. So I mean the reason we’ve got you on the show today is because you’ve just produced a book called Mobile Web Design. This you already know I’m sure. So we thought it would be good to get you on the show just to talk about some of the things that you kind of cover in the book, and give a bit of an introduction, um, to the world of developing mobile websites. And um the question I wanted to kick off with is in your book you dicsuss kind of four different responses to kind of mobile web. In other words four different approaches people could take when they start thinking about the subject of mobile web design. And I just wondered whether you could talk us through those four different approaches that people could use.

Cameron Moll: Yeah that’s probably a good place to start. Um, most of these are straight forward right. It’s I think a pretty simple thinking to understand how one would approach the mobile web. And uh, you know I produced these about two years ago as I was trying to understand how someone like myself, you, how we would make that leap over to mobile. The more I was researching it the more it became apparent that you know there is really these four methods, and what they boil down to is, uh, is this. So one, you essentially do nothing. Two, you reduce the number of images and styling therby reducing the file size, uh, the page weight and so on. Three, handheld style sheets and then four, mobile optimized or what some refer to as content adaptation. And uh, the breakdown is essentially this, if you’re going with that first approach your saying “You know what, I’m going to do nothing.” I’m either lazy. I assume that my users have devices that can support the content I already developed and uh, you know when you think about the mobile web obviously the question that comes to mind is what technology am I going to use? How am I developing content for mobile devices? And fourthly, most devices out on the market today will support well structured mark up out of the box. And so most of the devices being sold, most of the devices that people have in hand today are going to support your html markup. So a lot of user will take that approach, I guess developers that is, take the approach to say you know what, what I have developed it good enough. I’m going to push it out there. And with things like the iPhone and some of the higher end Nokia devices that are out on the market, most of those devices can support a full desktop experience. Right, so it’s this idea that I refered to as content zooming. And so with the iPhone I can see the full website. I can pinch or zoom in. With some of the Nokia devices and Oprea mini 4, I can have that same experience. And so the thinking with that first approach is, lets just leave the content as is and allow those higher end devices to access them.

Paul: Sure (thoughtfully like he is paying attention)

Cameron Moll: Uh, the second approach. This essentially takes the existing markup and content and says lets pull out the images. Lets pull out the styling and allow users to access that raw content. And the thinking there is we’ll reduce the file size. We’ll take out all those big images, that unnecessary styling. Most of the devices out on the market today, well I shouldn’t say most, but alot of them don’t support the styling that you and I are used to using on the desktop. So, the thinking here is just to pull all that out and allow the device to see the raw content. And after all people are after the content not necessarly the background images and colours and things like that. Now the third approach is perhaps right now the most controversial, and that being handheld style sheets. I mean these have been promoted as kind of this poster child of all things web. So any device whethe it be a mobile device, a car a watch or what have you should potentiall be able to take the same markup and with a style sheet specific for that device, again it might be a printer it might be a mobile device. Being able to attach specific style sheets that render the presentation differently for that given device. So the idea being, you know if I just attach a handheld style sheet to my markup. I don’t touch the markup. I don’t touch anything else. I just add that handheld style sheet then great it’s going to display it differently and so on. Of course there are drawbacks to this approach and I guess what I’m skipping here is there is drawbacks that I cover in detail in the book to.

Paul: Yeah (thoughtfully like he is paying attention)

Cameron Moll: To each of these approaches. They all have pros and cons. The biggest one here with handheld style sheets, cutting to the chase, is the fact that not all devices support it. I would guesstimate, I don’t have any exact figures, I don’t know that they exist. But is guesstimate only about half the devices out on the market will support handheld style sheets. And even of those that do the support is somewhat shotty. In that some of those devices will correctly obey a property such as “display none” but they’ll still in the background download the associated content with that. So if you’ve got a large image for example, and you attach to that “display none” it won’t show it but it’s still gonna download in the background that image or that content. So right now, at least, using handheld style sheets is a bit of a pipe dream. It’s just we’d love to be able to have the power to access those, that capability. But right now it’s just not all that feasible.

Paul: Hmm. (thoughtfully like he is paying attention)

Cameron Moll: Finally, on the fourth point, mobile optimized content. This is where you say “You know what. I understand that the environment of being mobile, this idea of context is different that it is when I am sitting at my desktop.” It’s different because I might be using one hand for data entry. I’ve got a much smaller screen and naturally I’m out on the street. I’m out driving or something along those lines. So we say what’s different about that experience, then sitting at one’s desktop. Proponents of this fourth approach essentially say, “You know what the other approaches, especially the do nothing approach completely ignore context.” And that is what is the user doing when they’re out walking. When they’re on the tube or the subway and so on. So this last approach says, okay the context of being mobile is different than anything else. People want to do things differently when they’re out and about. So we’re gonna reformat our content to cater to that experience. We’re gonna present and entirely different experience, and altered experience perhaps to that of the desktop that addresses the specific needs of being mobile. The arguement I make in the book, I guess coming full circle with these approaches is, I often get asked the question “Well what’s the best approach then Camerson?” I don’t know. And you ask 20 different people in this industry and you’ll get 20 different answers. Right now I think the most feasible approaches moving forward are the first approach, do nothing, and the last approach, to create mobile optimized content. The arguement being is one, you need to understand first of all the context of mobile users and therefore adapt that experience to that context. But at the same time you have alot of capable devices out on the market that may be able to render a full experience that users are used to elsewhere.

Paul: I mean you talked there about context and in particular the fact that peole might be using it one handed or whatever else. What are kind of the major differences that you are seeing between kind of a user experience designed for the desktop compared to user experience designed for the mobile device? How do they alter? What should we be doing differently?

Cameron Moll: Well I think that the key phrase here is mobile right. So Barbra Ballard, I quote her in the book, I love her quote that essentially says that when we’re talking about mobile it’s referencing the user not the device. And I think if we start there saying okay mobile is about the user not necessarily the device that they are using but the user. We then start to understand. Okay what is this user trying to do? Where are they? What are the limitations that they confront? And what are the oportunities that are provided through mobile that might not be provided elsewhere? So, it’s not about how do we make this experience similar to the desktop, but how is it different? How do we make it different and how do we welcome that different experience? So this idea of context, it’s this idea, you know, you have this great content, and we hear this phrase “content is king.” Well I argue that context is king. Cause when a user is mobile that content is of little value if you ignore the context in which it is being used. That inevitably leads to the question. What are the needs? What are the problems? What are the tasks that users may encounter in an environment of mobility. Then that leads to what are the opportunities that mobile provides for that given context. For our content, for our company that the PC doesn’t.

Paul: Yeah. I mean it’s a very interesting area because it’s almost somethign you need to address on almost an individual project basis. Looking at what content you’re working with, and working out what of that content is actually relvant to a mobile device and which isn’t. I mean you use an example about that somebody’s probably not going to want to look at your portfolio page on your personal website on a mobile device. It’s just not the right context. I guess that’s what your getting at there.

Cameron Moll: Right. You bring out a very interesting point and that is, let’s say a given company. Let’s say you and I as developers are working within an organization right. And we’ve got 20 projects that we manage. Something you said earlier keys to the point of looking at those 20 applications or websites and saying okay first of all which of these 20 apps might be relevant to someone being mobile. We cut that down to say 5 or 6 or whatever the number becomes. Within those applications or sites if we’re talking about existing content here within those applications or websites it’s those 5 or 6 as being perhaps suitable to mobility. We then look within those entire applications, so within a given application for example that might have 20 different tasks that a user does with that application. We then say okay which of those tasks are relevant to someone being mobile. So it’s this process, at least with existing content, looking at what are the applications we provide and within those applications what are the features that are going to be relevant. Now what that also ignores though is the fact that we’re not saying what are new opportunities? What applications have we not developed that might cater to mobile? Or within an application that we have developed, what opportunities such as location awareness might be provided to a user that we just haven’t even thought about it.

Paul: Yeah. I mean that whole about the fact that you get into this mentality that a mobile device is a cut down version of what you provide on the desktop. Actually, there are opportunities to do stuff on a mobile device that isn’t actually possible on a desktop and the location aware stuff is a good example of that I guess.

Cameron Moll: Right exactly.

Paul: Okay. So lets say as a web designer I’m beginning to get a bit excited about the mobile web. It’s obviously the way that things are going. You provide some excellent statistics in your book about take up levels of mobile devices and I’ve cribbed those and used them on the show before. So I think that there is a lot of people that are listenin to the show and going yeah this is something that I am really quite excited about. But where do I start? What kind of technical skills to I need to develop mobile websites? Is it enough to just know standards based design? Or is there other thins I need to know as well?

Cameron Moll: You know that’s a perfect question. If you look at where we are at now today it’s totally different then say 4 or 5 ago. I remember the same hype 4 or 5 years ago where people were saying mobiles coming. Developing websites for mobile devices is the next big thing. It just kind of died out. I think largely it was due to the fact that back then you still had to develop in WML, which is not a cryptic language. It actually provided a lot of clarity and unity to the mobile web environment 4 or 5 years ago. But at the same time it required that a lot of us had to learn a new language in addition to HTML or CSS. That’s no longer the case. So this second time around when we hear this hype about the mobile web, to me at least it feels much more real. Because now we have again, as I mentioned earlier, most devices out on the market, in fact nearly all of them support HTML, XHTML, and some level of CSS. So that means that you and I, we already know HTML. We already know CSS. We can take that knowledge and start developing content for mobile devices. Whereas 4 or 5 years ago we had to learn a new language just to get over that barrier of providing content. So the good news is, for the most part, really if you know standards based design and development techniques, you are 90% there. I think the other 10% is left to understanding context. So trying to understand what those limitations are with mobile devices and mobile users. And also looking at the opportunities. so again we’re talking about smaller screens, data entry. Those being limitations but at the same time location awarenes. Users just want to do things different. They’re out on the go, which can be a great advantage depending on what kind of content you’re providing. So I think the good news here, long story short, yes. You and I can just build on the knowledge we already have if we just start to understand just a little bit about what the users are doing.

Paul: I mean you say. It’s interesting some of the words you use. You say ‘for the most part.’ Or ‘some browers understand CSS.” And I think that’s the other big fear that people have when they start investigating the mobile web, is the huge plethora of different browsers and devices and all of this kind of stuff. And it seems like how the hell am I supposed to test on that. It’s impossible to test on every conceiveable device and every conceiveable browser. Where do you start? Where do you put your initial efforts?

Cameron Moll: You know when I first started talking about mobile I think I was a bit to pessimistic in that I would stand up, say in a conference or in an article, and say okay if you’re going to test for mobile devices be prepared to test on dozens of browsers and if you think 4 or 5 desktop browsers. And getting consistency right for those is difficult. Wait till you see the mobile web. I’m a bit more optimistic now. I hope the book at least comes across that way and when I talk about it at conferences it comes across that way. And the reason being is this. There are some pretty easy ways to deal with that challenge of consistency. Of testing for mobile devices. Of just developing content period for mobile devices right. So you and I, you use probably the web developer extension for Firefox. We both probably at some point used Opera. Both of those browsers with those extensions and plugins can, at least at the very start, render and initial small screen preview. They both have options to be able to do that. So starting at the very least we can develop, again because we’re developing in XHTML rather than WML, we can within the browser at least do a very quick test to see roughly how it’s going to show up for the user. After that, once you’ve got at least the markup structurally sound you can then jump over to emulators. Now there are plenty of online emulators. .moby provides one. Opera mini provides another and there’s several others out there. But also there’s desktop software that you can download to be able to emulate mobile devices. So then taking 5 or 10 mobile devices I can now test how my content’s going to render, and it’s very close to how it will actually render on the device. But you can’t stop there. The last step has to be actual devices. And I think this was what was insurmountable for me starting out as a mobile developer. At least a beginner saying oh gosh do I have to go out an purchase 100 devices to be able to test my content. Well fortunately you can get away with 5 or 10 devices. If you can get 5 or 10 devices that vary widely. By that I mean one being a very basic phone, another one being a PDA,another one being a popular device such as the Razor. If you can get 5 devices that vary widely, 5 to 10, the chances are that that content is going to render well for most devices out there on the market. That will get you close enough. A lot of that is based not just on my personal preference but on the case study that I offer in the book. That is the Yahoo! website for the FIFA world cup last year. They took that approach. They said you know it would be difficult to test on 100 devices but we think if we can get 5 to 10 widely varying devices that chances are our content is going to display well for a global audience. Which indeed it was for that particular website. So that’s the arguement that I’ve made. I’ve hear others make that arguement as well. And it’s not difficult to get that number of devices right. So you can probably get 3 to 5 from yourself, from friends, collegues and so on, on loan for a couple hours. If you’ve got a blog you can ask for volunteers to do testing. I’ve done that before and it works pretty well. And then finally anyone can hop on eBay and do a search for unlocked mobile phones and purchase phones for an affordable price and get you know 5 to 10 devices. That’s how I did it. You know I hopped on eBay. I bought about 5 phones that were unlocked and then I just take my SIM card and swap that around the phones when I am doing testing. So it’s really not that difficult once you’re done developing your content to make sure that it renders well for mobile devices.

Paul: What do you think about the kind of growing thing that we’re seeing at the moment about designing mobile sites for specific devices? Like the iPhone. Do you think that is a bad route to go?

Cameron Moll: You know I’m not going to say it’s a bad route to go. But I do question it’s integrity. Three years ago or so, when I bought, well this was a little bit after I bought my Treo, for example which is a feature rich PDA. There were all kinds of Treo specific sites that had been developed. So you had something like, lets just say you had something like ESPN.com/mobile/pda/treo would be the web address for that content. And it was formatted just for that device. When you think about all the devices that are out on the market you then realize that that becomes a big chore to try to develope content for X number of devices. Now I think with the iPhone at least you have that same experience being repeated. For me it feels in part like you know years ago when we hit up a website and it said best viewd with Internet Explorer 4.0 or something like that. You know that is what we’re seeing now with the iPhone. Granted the iPhone provides a much different experience and a much richer experience, which is great, but at the same time I worry that we are spending a lot of effort on a device that 1. Is not a market majority and 2. The device itself, the iPhone itself might change at some point in the future. I might have a larger screen. It may render content differently. Which then will require that we go back and rewrite that content yet again. So the arguement I’ve made is if it makes business sense to develop and iPhone optimized site well more power to you. Go for it. But I advocate as a default creating content that can render on as many devices as possible. Not necessarily just one device.

Paul: Cool. Thank you so much Cameron. That is incredibly useful. Where can people find out more about your book then?

Cameron Moll: The web address is mobilewebbook.com or they can find a link from my website cameronmoll.com.

Paul: Excellent. It’s a .PDF book that you can download instantly. Now waiting around for delivery at $19. The best thing of all is it’s nice a short. Just over 100 pages. Isn’t that right? Something like that?

Cameron Moll: That’s correct. And I’ll give your listeners a heads up that we’ve got a print version coming out in October to be announced soon.

Paul: Oh that’s excellent. So you’ve got the choice either way. Alright thank you very much for coming on the show Cameron. We’ll get you on again in the future no doubt.

Cameron Moll: Hey thanks Paul.

Show 93: dconstructed

Posted in Classic shows on September 10, 2007 by Paul Boag

On this week’s show: Paul talks about how to make the most of the footer, Marcus explains why cold calling never works and Gary Marshall shares some great advice on writing content.

Podcast: Download (27.3MB)

Download this show.

Launch our podcast player

News and events | Why cold calling never works | Making the most of the footer | Gary Marshall on writing better content

News and events

iPod Touch

Unless you have been living in a cave for the last week you will already know that Apple has just released a new range of iPods including the massively exciting iPod Touch. What is so exciting about the iPod Touch is that it is basically an iphone without the phone. This means it has WiFi and a fully functional web browser. This is a major development in the web design world as it will mean millions of internet enabled iPods and a whole new audience in a whole new context.

What is more Apple has also done a deal with Starbucks where by songs played in Starbucks can be purchased directly on the iPod. I am convinced this is just the tip of the iceberg in terms of context / location aware mobile web. It won’t be long before you arrive at a University Campus and access a campus map or go to a shopping mall and access all of the menus of the various restaurants.

With the iPod being such a universal device now is the time to think about how you are going to utilize the power of the mobile web.

Free photo manipulation tools

This week I came across a site stuffed with loads of free photo manipulation tools. These guys have certainly been busy as there are loads of really fun tools including a Mosaic maker, CD cover creator and even a Hockneyizer. However, probably the most useful tool to us web designers is the palette generator. Upload an image and it will automatically create a colour palette based on it. Nice!

dconstruct feedback

This last week also saw the dconstruct conference in Brighton. I was fortunate enough to attend it and got to hear some truly remarkable speakers. I am not even going to try and recount all that was said, however I do want to particularly mention three superb talks.

Tom Coates, gave a mind blowing presentation on shifting our thinking from a website model to a data model and the consequences of this in terms of how we develop applications and how users navigate data. Tom’s presentation really felt like a glimpse of things to come.

Leisa Reichelt gave an inspiring presentation about how we develop projects. Amongst other things she talked about Agile development and I have to say this was the first time it has been explained in language I understood. This talk definitely made me reconsider how we run projects.

Finally, I couldn’t mention dconstruct without talking about Jared Spool’s presentation on experience design. Jared (who is a superb speaker) took us through how to create great experience design, explaining why it is important and how to draw together the necessary skills to make your design stand out from the crowd. Compelling stuff.

The reason I mention all of this is that all of these talks will soon be released as podcasts and I wanted to strongly encourage you to check them out!

170+ Expert Ideas From World’s Leading Developers

The final story today is the release of an article on the smashing magazine website. The guys at the magazine interviewed 50 designers and asked them 6 questions. This has led to an article with 175 professional suggestions, tips and ideas.

Its always fascinating to see how other designers work so this article is definitely worth a once over.

Marcus’ bit: Why cold calling never works

Ok, to say that cold never works is a bit strong because very occasionally it does. I should also qualify that I am talking about winning quality web design work here.

So, a more appropriate, but considerably more boring, title would be: why cold calling almost never works when selling quality web design services.

But, in my opinion, you don’t really even need to qualify the ‘what’ you are selling. I guess there are certain products or services that can, effectively, be sold over the phone to a person/organisation that you don’t know but I expect they are few and far between.

The word ‘effectively’, in the last sentence, is pivotal to this. I would love to see the ratio of telesales staff costs against actual sales won via the telesales force for, say, a double glazing company over the last year. The fact that I seem never to be called these days by double glazing companies suggests that my suspicions are correct and it simply isn’t worth it.

I don’t know anyone who likes being called out-of-the-blue and certainly, no-one who has actually bought anything through this process. I think most people are instantly ‘on guard’ and mistrusting of a cold call. This has worsened, I believe, over time and has now reached the point where it has almost become a joke.

Anyway, I’m rambling off the point – back to web design.

You can’t create a project that doesn’t exist

This is the main issue. Even if you are lucky enough to find a receptive listener, the chances of calling them right at the point where they are thinking about starting a web project is remote. The best you can hope for is that contact will be made later when a real project does happen.

You may not be talking to the right person

It is very possible that the one successful call that you made after a day’s banging the phone was actually to a chatty junior who cannot make or even influence decisions. Asking to speak to the ‘marketing director’ or ‘person in charge of the web budget’ etc is a recipe for an instant hang up.

Even if you are speaking to the ‘right’ person, chances are they will have to go to other partners or directors and that group will want to know track record, where did the recommendation come from etc.

Making yourself known

Ok, so you can’t actually win work cold calling but you can occasionally start the process of winning work through a cold call. However, I would say from experience, that this cannot be a completely cold call. You need at least one thing connecting you to the person at the other end – and the direct mail piece you sent them two days ago does not count because they will have instantly thrown it in the bin!

The kind of things that can make this type of call potentially worth it are:

Work done for one of their competitors (vertical selling)
Locality (“we’re in the same town”)
Professional connection e.g. a print designer you are close to works for them
Social connection e.g. my neighbour Dave Smith works for your accounts department and thought I should call you….

But remember you are simply selling your professionalism, skills and competence; basically, just the chance to pitch for work when it comes around.

However, I would recommend that the majority of your efforts are spent on a) ‘hot’ calls to people who contact you with real projects and b) your existing clients as they are usually your best prospects.

Paul’s corner: Making the most of the footer

This week I thought I would try and tackle a question from Peter in Italy…

Disclaimer, copyright, accessibility statement and privacy policy; these are the links that can often be found in the footer of a page. Why is it important to add this information on a website and what should this information include?

The footer is the graveyard of many websites. The place where links are sent to die. However it doesn’t have to be that way.

Gary Marshall on writing better content

Paul Boag:
So, joining me today is Gary Marshal, a technology journalist and author and many other good things as well. Hello Gary.

Gary Marshall:
Hi Paul, how are you doing?

Paul Boag:
Not too bad, good to have you on the show, we had you on once before as I remember.

Gary Marshall:
Yeah it was a couple of months ago now wasn’t it?

Paul Boag:
Yeah it was a little while back. What I thought would be good today is to get you on to talk in broader terms about writing for the web, and writing in general, as obviously that’s what you do for a living. That’s your job, and so I thought I’d kick off with really a question about copy writing and copy writers; do you thing website owners should be looking to get a professional copy writer in to work on their website rather than doing so themselves?

Gary Marshall:
I think it depends a lot on the website that you have, if your doing something where your unique selling point is a fantastic price for a product, then it probably doesn’t matter too much what the copy’s like, but the more important the text of your site is, the more important it is to have good text. So take for example if your site is a brochure then obviously the quality of copy then is really, really important. There’s also the technical side of writing as well, which is not so much a copy writer but more of a technical writer for that so you know, product information, frequently asked questions, support, that kind of thing.

Paul Boag:
What benefit do you get from getting in somebody who does this professionally in preference to trying to do it yourself, where’s the real kind of money earner in it? If that makes sense, the return on investment.

Gary Marshall:
Yeah. Well it really depends on what your sites all about. One of the things about getting a professional to do it is it saves you time, the same way you would get somebody in to do stuff around the house because your time is better spent doing what your good at. But particularly with copy writing, if you get somebody who is pretty experienced in this, what they’re doing isn’t so much writing, but its writing that works. So you know a good copy writer can say more in a sentence than your average guy can say in 700 paragraphs, which is one of the reasons that guys in advertising get paid so much, because they come up with these fantastic strap lines that lodge in peoples minds.

Paul Boag:
Yep ok that’s fair enough. Obviously the main thing that puts off people from getting a copy writer is the cost associated with it and sometimes its just prohibitive, although I have to say that I get somewhat confused that people recognise they cant do design and they get a designer in to do that but somehow people think they can do copy which is somewhat confusing sometimes.

Gary Marshall:
Yeah, it’s not that expensive. If your going to have a multi page, 1000 page website then yeah it is going to cost you a fair whack of cash, but he majority of writers tend to be paid by the word, so you’ll set a rate, and what it is you want to get and the end result isn’t going to be an awful lot of money. Your looking at a couple of hundred quid for a couple of thousand words, its not a lot.

Paul Boag:
No I suppose in the grand scheme of things that isn’t much at all is it? If you think of the amount that people pay for content management systems and design work and usability testing and all that other stuff.

Gary Marshall:
Provided they’re good at what they do. Of somebody is going to polish the text in your website, and make what you do sound absolutely fantastic, if that makes the difference between somebody hiring you or not or somebody buying your product or not then it’s paid for itself.

Paul Boag:
So, making the presumption that there are some people out there that just aren’t in a position to hire a professional copy writer and its just not an option – what advice would you give someone who is starting out writing copy for their own website? Where would you start? What are the most common mistakes?

Gary Marshall:
I think the most common mistakes are thinking from your own point of view rather than from your visitors point of view, I’d say that’s probably the worst offence that you can do, and it’s the old moaner when if you have a frequently asked questions section it’s the questions you hope people would ask rather than the one people actually do ask, you get an awful lot of people where on a website the fist page is the entire corporate history and as a visitor I don’t care, I don’t want to know this stuff I want to know what are you going to do for me why should I hang about here. So it needs to be very much ‘put yourself in the customers shoes’. Have a look at other websites and see what you like about them and what works on those sites. The other thing you need to think about big style is search engine optimisation. I was talking to someone the other day who was saying ‘when we do searches on particular products and particular areas we just don’t come up in the results at all’ and I said ‘do any of these phrases or words feature on your site?’ the answer was no. That was probably why they weren’t featuring in the search results! It might be obvious to you that your search should come up if you look for, I don’t know, web design companies in Brighton, but if you don’t have the words ‘web design’ and ‘Brighton’ in your website its not going to be indexed by any of the search engines. That can be a really difficult one to pull off, you see a lot of bad copy writing that’s done purely on the basis of SEO, where they’re just trying to get as many different phrases in as they possibly can to try and get it up in the Google rankings and I think that’s counter productive because ultimately your trying to get humans to read this and if somebody comes to your website and the whole thing is stacked with all these meaningless phrases that don’t actually give you any useful information at all, then your just going to go ‘what a waste of time, I’m out of here’

Paul Boag:
Do you think there’s a difference between writing for the web and writing for other mediums?

Gary Marshall:
Yes

Paul Boag:
What kind of differences? What should people be doing differently?

Gary Marshall:
The biggest one is brevity, simply because your reading on a screen – you’ve no control over what sort of screen people are going to be reading on for starters, so I might be looking at it on my BlackBerry, you might be using a 22 inch monitor, but web content doesn’t lend itself to huge blocks of text and long, long sentences so you need to think much more visually than you do with the printed page I think, break it up a lot more and have a lot more white space. The way to present it can be important also, even having a bigger gap between lines can make a big difference to whether your text looks appealing or not. Again, work back from the basis of ‘what is it that your visitors are going to want here?’ You need to really start with that. I find that bullet pointing is usually a very good way to approach it. So, you sit down and think ‘what are people coming to my website for? And what is it they’re going to be looking for?’ and answer that first. If you’ve got a bit of spare time go into you full corporate history and everything you’ve done in your life, but concentrate on the purpose of your site first.

Paul Boag:
It strikes me that websites, unlike other mediums aren’t linear, so you have the option to start with the top level brief information and highlights, and people can kind of dig down to the in depth stuff if they want to.

Gary Marshall:
Indeed, one of the things you see in print a lot is the use of ‘pull quotes’ to draw your attention to a particular bit of the body copy, and its basically a sales technique and exactly the same thing works on websites and can be very effective and can encourage people to read more. The other thing I would say is try not to link too much in your actual body copy because every little blue line there is a potential reason for someone to disappear.

Paul Boag:
Ok that’s interesting.

Gary Marshall:
I think it can get in the way – if you’re trying to engage people you don’t want people to go off on tangents because you’ve got this short attention span thing going on.

Paul Boag:
Yeah I can accept that – the other thing as well is that if the page is full hundreds of links it makes it visually quite difficult to read as well.

Gary Marshall:
Yeah and avoid these kind of hover over adverts that infest websites. If it looks like a link I expect it to be a link and if I move my mouse over it and just get ‘find out about hotels in Guatemala’ or something its instantly away from the website. There’s something as well, I don’t know if its true or not but in journalism school they teach you when writing for tabloids you should write on the assumption that your reader is going to be a small child, and I think that can work with websites as well because it really does focus you on getting the information there quickly with the minimum amount of waffle and without going off on huge tangents. And like the old press thing as well where you have all the information in the first paragraph and you expand on it as you go along, so you should be able to chop from the bottom. If you’ve written 500 words, you should be able to chop the bottom 250 off that without losing sense of what you’re doing.

Paul Boag:
Yeah that’s good. So, websites are one thing – your kind of corporate websites and things like that, but more and more organisations are starting to use blogs as a method of communicating. Do you think there’s a difference there? What advice would you give to people writing posts for blogs?

Gary Marshall:
Be sure that you want to do it in the first place. Jacob Neilson quite famously said the other week that businesses shouldn’t blog, and he’s getting a bit of a headline generator there – he doesn’t mean no business should blog, but it can backfire because the nature of blogging is very much off the cuff, very quick reactions to things and that’s fine if it suits your particular kind if business, but if people are coming to your site for in depth information then I don’t think blogging does suit because by it very nature blogging is your most recent thought at the top so if you don’t have regular readers its quite easy to fall into the trap of assuming everybody knows the context of what your talking about, and they might not because you wrote about it 3 weeks ago or 3 months ago. That’s quite a common pitfall I think. The other thing about blogging is because it’s quick and easy it does encourage you maybe not to craft things as well and not think things through. You have got to remember that this stuff potentially hangs about for eternity. So it might be tempting to, I don’t know, slag off the competition or something but it could well come back and bite you later on. I think with blogging, it comes back to any sort of writing – you need to know what your trying to achieve with it because if you don’t have a clear idea of what your blog is going to bring to your website, and what benefit its going to bring to your visitors and customers it’s a potential massive waste of time and effort that you could be spending on something more interesting.

Paul Boag:
Yeah.

Gary Marshall:
I sound really negative; I don’t mean to be really grumpy today! But I think it’s a bit like in the early days in the web there was always these wonderful ‘do-hickeys’ and logos you could slap all over your website and lots of people did without actually asking ‘does this bring me any kind of benefit whatsoever?’. Done well, blogging can be a fantastic thing on a website. I’ve seen a few examples of it in all kinds of things – I was looking for drum loops for ‘Garage Band’ and I was looking at the various drum loop companies and I found one that the owners blog, and they talk about how they do the stuff, what they’ve got coming down the line, why they think that they’re great and nobody else is and all this kind of stuff and I really quite warmed to them and that encouraged me to have a look on their website and I ended up spending money on it. Other sites that are just plain old e-commerce things and really don’t care. Unless your doing a kind of niche market where I don’t know, ‘golfing grandmothers’ or something then the very fact that you’ve got a niche people are more likely to pay attention to what you’ve got to say. I don’t care if the marketing director of Comet has a blog; I have no interest in what he’s got to say – so adding it to something like that would be a waste of time. I don’t want to read a blog on ‘great big faceless ISP dot com’ whereas ‘Merchant city music’, which is a music shop in Glasgow, I’d be quite interested in what these guys have got to say, so ‘We’ve got some amazing stuff coming in!’ or ‘we were away seeing a band last night and they were fantastic!’. That feeling that your part of a bigger picture can be really effective, particularly with smaller businesses.

Paul Boag:
Yeah, good stuff I couldn’t agree with you more. I think there are a lot of blogs out there that shouldn’t be out there and there are also some places that should be blogging that aren’t.

Gary Marshall:
Yeah I would agree with that.

Paul Boag:
OK thank you very much for your time Gary, it was really good to talk to you again and no doubt we’ll have you back on the show in the future

Gary Marshall:
No doubt!

Show 92: Royal Air Force

Posted in Classic shows on September 4, 2007 by Paul Boag

On this week’s show: Paul asks how much you should blog, Marcus takes a look at the state of music online and John Oxton joins Jon Hicks in discussing the benefits and drawbacks of home working.

Podcast: Download (25.9MB)

Download this show.

Launch our podcast player

News and events | Music on the web | How much to blog? | Hicks and Oxton on home working | Housekeeping

One quick thing before we dive into the news. I am lazy. Yes, I know it is a shock. I am always looking for the easiest way to do things. But as well as being lazy I like pretty shiny things. One thing I particularly like is pretty desktop pictures. However, looking for cool ones takes too long. You can therefore imagine my delight to discover a mac app called Desktoptopia that basically pumps gorgeous background to my desktop on a continual basis. What is more you can even add your own RSS feeds if you don’t like their images.

So I wrote to them saying I liked their software and they offered me a $5 discount for all you boagworld listeners until the 18th September. That means you can buy the software for only $15! All you have to do is go to desktoptopia.com/store and enter the code “boagworld”. I know this sounds like an ad but it isn’t. They aren’t giving me anything. I just liked their product.

Anyway if you know of any other cool apps that you want me to go after a discount on that drop me a line.

News and events

The Mobile Web

This last week has seen the release of Cameron Moll’s book on the Mobile Web. I have been waiting a long time to read this book and although I have yet to finish it, what I have seen justifies the wait.

You maybe tempted to think that the mobile web isn’t really something you need to concern yourself with, but I would strongly encourage you to reconsider. In Cameron’s book he explains that 59% of the entire world population will have a mobile phone by 2010. In 35 years – roughly the same amount of time as the PC and nearly one-forth the time of the landline phone – mobile phone penetration has surpassed the PC and landline phone combined. It is a massive growth area. Admittedly not all of those phones are internet enabled and even if they are that doesn’t mean people use them. However, in the UK and US mobile access to the internet is already one-fifth the size of those accessing from a PC.

The book is only $19 and can be downloaded in PDF format from mobilewebbook.com.

If that has wetted your appetite for the mobile web you should also check out an iphone article that has appeared on the List Apart website. It provides loads of great advice on developing sites that work well with the iphone and although it is iphone specific a lot of the information applies to other mobile devices too.

Incredible image scaling

Next up is a video demonstration that is causing considerable excitement online. The video shows an amazing technology that can dynamically scale an image up or down to fit the available space. We are not talking pixel scaling here, we are talking about adding or removing pixels in a seamless way by following the contours of the objects in the picture.

Its an incredibly hard thing to describe on an audio podcast and so I would encourage you to look for yourself.

What I can say however is that this is an incredibly exciting technology which the big players are taking seriously. Adobe has already hired one of the creators of this technique.

Finding a domain name generator

My next news item for today is a great little post I came across on the sitepoint.com website which lists three domain name generators. These “generators” help solve a growing problem you encounter when launching a new site or product; finding an available domain name.

You can tell just how hard it has become to find a good domain name by the way that web 2.0. companies have started dropping vowels in order to get the word that they want.

The sites listed in this blog post allow you to enter keywords and it will suggest domain names based on word combination, plurals and even thesaurus lookups. Best of all one of the sites mentioned also works nicely for those of you who are looking for language specific URLs.

Very useful indeed.

The ultimate design brief

Last up in today’s news segment of the show is an article about writing a design brief. It is not directly written with web design in mind but ever word is applicable. The article applies equally to designers as to clients and talks about the important role that a design brief fulfills. It suggests that designers need to encourage clients to put together a formal design brief outlining exactly what their requirements are. It then lists a series of suggestions of things which should be included. The list it includes is far from being comprehensive (at least not for web designers) but it is an excellent starting point.

I really cannot emphasis enough how important a formal brief is no matter how small the project. It is a strange coincidence that this post comes out in the week that I am drafting a chapter on brief writing for my book. While working on this it has reminded me of just how bad things can become if all parties are not entirely aware of each others expectations.

If you tend to be a bit slack when it comes to writing down requirements then make a point of reading this article.

Marcus’ bit: Music on the web

I remembered writing an article for the Headscape website a long time ago on this subject so I thought I’d go back, have a look, and compare it to how things have actually changed in the past five years.

At the time, before the general take up of broadband, the use of music on websites was limited to annoying, over-compressed loops that bore little relevance to the rest of the site. I hoped that the advent of broadband for all would lead to music being created for sites a lot more often and the role of web music developer/designer becoming a reality.

So, has anything changed?

Well, to be honest, not really. The sites that used to include music; ‘cool’ sites like trendy design agencies, band sites etc still do and they do it a lot better. The quality has improved along with the choice of what you can listen to. But that wasn’t what I was hoping for.
At the time, there was a bit of a buzz about audio branding – promoted by Intel’s audio ‘logo’. This lead me to think that a lot more companies would start to introduce audio branding and add it to their sites. This hasn’t happened at all apart from a few big names

like Philips and Ford.

Why not?

The main reason for the lack of take up of music on sites is, I think, that music needs to either sit on it’s own i.e. you don’t associate imagery with it at all or, it needs to synchronised with imagery. Music works great with films/ads/etc because they’re fixed – you can stop and start them but that’s about it. They can’t be viewed in a random way like the way people navigate websites. This means that music on websites will always feel like a bit of an add-on and, at worst, as a distraction.

Additionally, websites are generally seen as information portals and not as places of entertainment per se. They provide entertaining things to download, watch, etc but in themselves they are simply shells for content, most of which is written text. While I’m on ‘text’, one thing I thought we would see more of was voiceovers – but again, this hasn’t caught on.

Any positives for the composer?

Yes. What has exploded since the take up of broadband is video. We are seeing more and more video online. Video, which is a fixed entity, usually benefits to a lesser or greater from the addition of music.

Though the creation of quality video is a specialist field, I can see web design agencies being asked to produce more and more video (for example: client testimonials, staff interviews, product demos etc). Quite a lot of the time I expect that library music will be used but I expect that little by little, more new compositions will be required for video on websites.

I’ll check again in five years!

Paul’s corner: How much to blog?

I recently received a question from Dan:

For as long as I can remember the prevalent thought has been that the key to success for blogging and podcasting is to post frequently and on a regular schedule. Now, this made a lot of sense because websites had to get visitors to comeback manually to find new content. But now in the age of RSS feed is this advice still as important as it used to be if at all? Also in terms of how web managers spend their resources is it more important to do a few updates with stella quality or to manage your time so that frequent updates are the priority?

With over 66% of blogs not updated in over 2 months and anywhere between 60% and 80% abandoned within their first month this seemed a good subject to examine in more depth…

Hicks and Oxton on home working

Paul:
Okay. So joining me today are two towers if British web design genius, in the form of Jon Hicks and John Oxton. Hello guys.

Jon:
Hello.

John:
Hello. I think he is trying to tell us that weíre fat.

Jon:
[laughs]

John:
[laughs]

Paul:
[laughs]

John:
I was just agreeing with him. [laughs]

Paul:
Itís always good practice, if you are doing a podcast, to butter-up your guests in advance.

Jon:
[laughs]

John:
[laughs]

Paul:
[laughs]

John:
Oh, I always wanted to be greased up. Thank you.

Paul:
Enjoy. Okay so the reason we dragged these two guys onto the show today is really to talk about a change that they both made in their carriers recently. So you guys have been freelancers for a while, is that right?

John:
Yes. Iíve been 5 years. How long have you been John?

Jon:
On and off for about 5 years as well.

Paul:
Okay.

Jon:
With three years committed.

Paul:
So that is quite a while to work as freelancers. And I guess that you both used to work out of home offices. Is that right?

John:
Yes. Iíve worked for the first three years from a home office. And the last two years I have renting a little desk in a local print design company.

Paul:
Okay.

Jon:
So it kind of like the next step-up.

Paul:
What about you Mr. Oxton?

John:
I worked out of a bedroom, like every proper developer should.

Jon:
[laughs]

John:
For as long as I have been doing web design I never had my own office.

Paul:
Okay. And then, relatively recently the two of you decided to get together and move into an RAF base, is that right?

Jon:
[laughs]

John:
[laughs]

Jon:
Thatís right… over. [sound of CB radio clicking off] Yeah, I mean… do you want to tell the story John? Or should I tell the story?

John:
You tell the story.

Jon:
Iíve been renting a desk for two years. It was a nice place to rent and nice people. But it really was though… ìWe have a spare desk in the corner and you can come and use it.î John mentioned that we wanted to find an office, so we were looking for anywhere sort of halfway between where we lived. And this place came up and I think I have to admit, there was kind of a boy-appeal to the whole RAF based thing. I mean it is not big, an RAF base, about 8 or 9 years ago. But, there is still an airfield here and it is still being used. And, itís great.

Paul:
So, beyond this being some nice reminiscing about how youíve got a lovely office together and shouldnít we all be envious of you? I mean, the reason I kind of got you on is to talk a little bit about home working and working in an office, and working as a freelancer really. And setting yourself up and stuff like that. What made the decision for you to move out of a home office and into an office working together? What triggered that decision?

John:
I think for me, the key was having young children. Working at home with young children is an nearly impossible I think.

Paul:
Hmmm.

John:
But it is also the fact that we kind of worked together for the year before hadnít we, on a project, and we found out that we get on quite well.

Jon:
[laughs]

John:
[laughs]

John:
So those were the two elements for me really. Find someone you can get along with and just wanting to get out of the house because of the kids.

Paul:
So was it a desire to be in an environment where you could bounce off of somebody else and have other people you could speak to as well? Or was it just getting away from the kids?

Jon:
That that is one aspect of it. Certainly, going back to the place that I was renting the desk from, they are lovely people and they were good print designers, but I couldnít talk to them about anything web related.

Paul:
Yeah.

Jon:
Ummm. I mean, they did websites using Freeway.

Paul:
Right.

Jon:
So you know you couldnít talk code to them, you could talk about IE bugs – and that kind of thing. Ummm, although I could do my thing of asking people what color something is, if I needed to check… but that was about it. So yeah, that is an element to it. Having someone there you can actually talk to about these things, or you know passing around things like… discussing things like the blueprint of CSS framework or what was that one called Moonfall, or something. It was the Perl script for doingÖ

John:
Oh yeah.

Jon:
CSS variables. These sorts of things, beforehand I wouldnít know anyone to talk to about that. You know, that makes the difference.

John:
And Iíve got somebody that can identify fonts for me now…

Jon:
[laughs]

John:
[laughs]

Paul:
[laughs]

John:
…which is a huge bonus! And what about merging two big iTunes libraries.

Paul:
Ah, I didnít think about the iTunes libraries.

John:
It is all about the music really.

John:
I mean it is difficult. There are definite advantages to home working. Ummm. Not having to travel is a huge one. Especially when you think about the environmental costs. As well as the financial cost of traveling somewhere to work.

Jon:
If anyone mentions carbon footprint, I hang up.

Jon:
[laughs]

John:
[laughs]

Paul:
[laughs]

John:
Yeah. We donít think it matters a bit. And everything is there. If you want to go and make a bacon sandwich at lunchtime you can. If donít have to go out and shop necessarily. And it is a nice familiar environment. And it is definitely cheaper. Thatís the thing. You are paying less over head.

Paul:
Hmmm.

John:
But, for me that would only work if I could afford a big house.

Jon:
Yeah.

John:
And we had the space to do that. And the space enough to be far enough away from that other activity as John says like children.

Paul:
Hmmm.

John:
And even if you lock yourself away in a room they still come in and talk to you.

Paul:
Do you think there are actual business benefits to being in an office rather than working out of your home?

Jon:
Well definitely. One of the things here, when they took over the RAF base, they took over what was the officers mess. They turned the rooms into separate suites. So there, what do you say John, about 20 other companies here?

John:
Yeah.

Jon:
Quite a lot.

John:
As well as some other virtual companies. Yeah, and a load of them Jon is working with other companies in the building.

Jon:
I think there is definitely an element where, ìYou can afford an office you must be doing something right.î I think he makes it look a bit more professional, for a start.

Paul:
Umm hmmm.

Jon:
You have a real live office, and you are not working out of your bedroom. It is a nonsense perception, but never the less it is true and it is a factor.

Jon:
And it is somewhere you can bring a client to. When I worked home, we would always have to meet clients at their place or at a pub… which wasnít a bad thing.

Jon:
[laughs]

John:
[laughs]

Paul:
[laughs]

Jon:
But sometimes a pub isnít the best place to meet. If you actually have got the nitty-gritty to discuss. So like here for example, there is a huge meeting room and a smaller meeting room. You hire it by the hour and they bring you in tea and coffee. And clients like coming here, donít they John?

John:
Yeah. Itís a nice journey.

Jon:
Again, as we all said about the other thing, clients here are greeted properly. Not like knocking on your house door and being jumped on by children.

John:
Yes. [laugh]

Paul:
Yeah.

Jon:
The phones get answered properly. There are lots, from a perception point of view ñ making you look more professional ñ I think.

John:
Absolutely.

Paul:
I mean we have a quite a few people listening to this show that would be enthusiastic amateurs at the moment. People that donít do web design full time, but maybe thinking about going freelance. Or, they are working for an existing company as a web designer and they are thinking about coming out of that and setting up freelance. What would you advise to people like that? Would you say start off in a home office or would you say go professional and go into one of these units straight off at the bat?

John:
Iíd be inclined to say, ummm, to start off at home if you can, but it depends what you are going out to do really. If you are going out with share holders and big plans for a product then probably go straight into offices. But if you are going out to be a freelancer who builds backends or frontends then you probably want to keep your overheads a small as possible to begin with.

Paul:
Hmmm.

John:
And then you can cut your position a little bit. And I think that was my attitude for a long time.

Paul:
So I mean would you have any particular advice for people who are working out of their home? As to… what things to avoid and what things to do in order to make yourself as productive as possible?

John:
I liked the Mark Bolton thing that he wrote, where he said to actually leave the house and walk around the block in the morning – to put his shoes on and actually leave the house. Because you know there have been days I have sat and worked with just my socks on. [laughs]

Jon:
[laughs]

John:
And it is all too easy to sit down and read a book. You know trying to make some mental separation between home and work is one of the key things.

Jon:
Yeah, definitely. That is something actually as well that I have to do here too. Ummm. Perhaps less than I did at home, but…

Jon:
And the longer you stay in front of a computer the less productive you can be. And a lot less stimulated your brain is. And just a simple thing of like, it doesnít have to be a long walk, just a couple of minutes. Get out and get some fresh air. Go around the block and come in again. And it has reinvigorated you. You if do it like a curve graph you see a sort of dip and over time it would get lower and lower the longer you stay in front of a computer.

John:
Yeah. That is for sure. I tend to go for short bursts, I pace a lot.

Jon:
Yeah. Yeah. We recorded ourselves recently doing that. And it proves how much I stay just rooted to a computer, while John paces and jumps up, and dances quite a lot.

John:
[laughs]

Paul:
[laughs]

John:
I like dancing.

Jon:
[laughs]

John:
[laughs]

Paul:
[laughs]

Jon:
But…

Paul:
That would be worth seeing. You recorded that…

John:
Ah huh.

Paul:
…on YouTube?

Jon:
Video I think.

Paul:
The actual work environment that you create, either at home or in the office. You know is there a certain setup that you like? That kind of makes working easier for you?

John:
I think it is a little bit like, old men and their sheds.

Jon:
[laughs]

John:
[laughs]

Paul:
[laughs]

John:
You know how when youíre an old man youíve said, ìWhen they get old they wouldnít even need their space.î When they need things around them they would say, ìI am going to my shed.î And when I was working from home it was like, ìI am going to my office.î

Paul:
Yeah.

John:
The thing about the office it that, it is the place where you control how it looks. It is your posters, your books. Your not necessarily mingling with everyone elseís. I think what we have done here, weíve created an environment that… well we havenít got an interior designer or anything… but we just kind of say we are an RAF base so letís go with an RAF theme. Some really nice 1940ís posters up on the walls. Even the famous ones you see everywhere, ìCome and Carry Onî, and Government advise posters.

Paul:
Yeah.

Jon:
It isnít too corporate in here is it?

John:
No.

Jon:
Itís clean and white. But the important thing is that it has all of our books and itís got our music.

John:
And we are quite lucky that we have some space in the back where we can hide all of our horrible stuff like filing cabinets.

Jon:
Yeah.

Paul:
Oh. Thatís good.

John:
We can keep it quite clean, canít we?

Jon:
It is a bit like the extension of the house really.

John:
Yeah. You know I have a window sill with all of my Doctor Who toys on it. It is creating an environment that makes you feel glad to be here.

Paul:
Ummm.

John:
That is one thing that I felt I when I went on holiday for two weeks, and coming in on Tuesday I felt it was great and feeling really excited to be going back into my office.

Paul:
Hmmm.

John:
We have quite a lot of things there and we have looking like we want it to look.

Paul:
Yeah.

Jon:
I find that quite a thing in the morning for me. Especially having this be the first office, with the actual leaving the house and coming to work, my brain actually starts thinking, ìI am going to work. I am going to work.î

John:
Yeah

Jon:
And at home, it was always a bit of a hard thing to do. Sometimes I would have to go out and come back, you know go and get something from the shop and come back to get the mental thing kicking in. So…

John:
Yeah. Well that is a huge thing. A lot of people talk about that, the separation of your home life and work life.

Jon:
But the actual office itself isnít geared up for relaxation really. It is geared up for calm working moments.

Paul:
When you guys worked at home, did you make sure you had a completely separate room dedicated to work? Because that always strikes me as being very important…

Jon:
Yeah. I did.

Paul:
…not to mix the two.

John:
There was occasions when I would go downstairs if I was doing something that I wasnít really motivated. I would sometimes go downstairs and just be amongst the family.

Paul:
Yeah.

John:
To have other people around me so I wasnít so excluded. So occasionally that could work for me to get me going, but generally… yeah, shut the door, put the music on and design away.

Paul:
I mean you talked about several things here about the need to get out and walk around a bit to clear your head. The need to sometimes to go and sit with other people, just to get that external stimulation. You talked about needing a quiet environment sometimes. What other kind of techniques do you use to help you be productive and get stuff done?

Jon:
Yeah. Setting deadlines is a big one for me.

Paul:
Okay.

Jon:
You know. Setting myself with burst deadlines when I had to get something done by setting that with the clients with an expectation otherwise I tend to get all, ìWell Iíll research that for a bit longer.î

Paul:
Yeah right.

Jon:
Deadlines are a important and acknowledging that sometimes Iíll do my best work at 3 oíclock in the morning – and going with that for a certain extent.

Paul:
Okay.

Jon:
Yeah, but I try and not do that too much anymore. But sometimes if I am struggling on something, 3 oíclock in the morning seems to be a good time.

John:
[laughs]

Jon:
I donít know why.

John:
Well I think for me, the simple fact of moving into an office was a big motivation booster. For a start, the change in environment was great kind of it reinvigorated me. But also, just the simple fact of, ìIíve got to do work to make money to pay for this place.î

Paul:
Yeah.

John:
…is a big booster in itself. But, yeah I use various things to sort of productivity in the sense I set a to-do list in yoJimbo a Mac application. I use Billings and BaseCamp a lot. Which I find that Billings can be very motivating the way I do these timesheets for everything I am doing.

Paul:
Okay.

John:
I never used to be very disciplined about recording time spent on things. But for some reason now, I am starting to do this. It is a very easy way to do it in Billings. And I find that quite motivating actually.

Paul:
Yeah.

John:
Actually recording how long things take.

Paul:
So, I mean kind of the final question that I wanted to ask is… The two of you have moved into an office together. But you still work very independently in your businesses or do you find that you are doing more stuff together? Is this the first step in becoming Jon and John Design, or…

Jon:
[laughs]

John:
[laughs]

John:
If you ask us that, we will put to you a different answer from the both of us.

Paul:
Oh dear. I have touched a nerve.

Jon:
[laughs]

John:
[laughs]

Jon:
You b****rd! [laughs]

John:
I mean at the moment we are very much independent. Ummm. But that is not to say that in the future…

Jon:
…I think that we touched on the subject and we are not willing to commit to any kind of answer yet are we?

John:
We are kind of looking at the projects in the future that we can collaborate on.

Paul:
Hmmm.

Jon:
I think there is more of a chance of us hooking up, because we are in the same office to collaborate on something ñ than we are about to becoming suddenly a big limited liability company with loads of employees.

John:
Yeah.

Jon:
That is nothing that I can see in the future… yet.

Paul:
Okay, well thank you very much guys for coming on the show and you never know, one day in the future we might get you to actually come in and talk about web design or something.

Jon:
[laughs]

John:
[laughs]

John:
I donít know anything about that. [laughs]

Jon:
How many episodes of Boag World have you done so far?

Paul:
You canít ask me that question because I do not know when this interview is going to go out.

Jon:
[laughs]

John:
[laughs]

John:
I see.

Paul:
I am going to take a stab and say 92.

Jon:
Well, there you go. After 92 podcasts what could we add to your web design conversation? [laughs]

Paul:
Obviously I know absolutely everything about web design. And there is nothing more to say other than what I have already said.

Jon:
Or catch me on a day when I am in a bad mood, and then I will tell you what I think about web design.

Jon:
[laughs]

John:
[laughs]

Paul:
[laughs]

Paul:
Excellent. Well, it was really good to talk to you and no doubt we will get you back in soon.

Housekeeping

And so that pretty much wraps it up for this week’s show. However, I do want to quickly mention one or two things before we go. If you are a web designer and live in the South West of England I just wanted to mention a new mailing list I have setup. It is exclusively for those in the South West and is designed to help build a community among web designers there. There is so much going on in places like Brighton and London and I thought it might be nice to build up a community in the more “rural” parts of Britain! You can find out more about the group at groups.google.com/group/swwd.

Also a quick reminder about the live recording of our 100th episode up in London on Saturday 20th October. If you are intending to come please sign up at upcoming.yahoo.com/event/224744.

Finally, because of d.construct and a trip to Cork I have at the beginning of next week, I am not 100% sure when we can get the show out next week so it might possibly be a few days late. However, don’t worry it will appear.

Thanks very much for listening and don’t forget to vote for our panels at this years SXSW at panelpicker.sxsw.com. We need all the votes we can get!

Show 90: Digg

Posted in Classic shows on August 14, 2007 by Paul Boag

On this week’s show: Marcus abandons Paul to go on holiday. Paul talks about competitive analysis and does an in-depth interview with Daniel Burka, the creative director at digg.com.

Podcast: Download (22.1MB)

Download this show.

Launch our podcast player

News and events | Daniel Burka talks about Digg | Competitive analysis

Hello? Is anybody there? I am so lonely, nobody to talk to, nobody to rant at, nobody to take the piss of! Your listening to boagworld.com, the podcast for all those involved in designing, developing and running websites on a daily basis. My name is Paul Boag and this week, I am sad and alone as Marcus is away on Holiday (or should I say vacation?).

I have to say it is not the same without him. Of course on the upside in many ways its a lot better. Less waffle, no interruptions, no skype problems and you get to hear my undiluted genius. So thats okay then :)

Because we don’t have Marcus around this week, todays show will be a little different. For a start Marcus wont be saying much, which should make the show shorter. However, in his place we have an extended interview with Daniel Burka the creative director at the social news website Digg. We cover loads of stuff from the difference in designing for social networking sites to working with AJAX and designing for the iPhone.

I will also be doing my segment as normal. This week I will be providing a quick and dirty introduction to competitive analysis. We will be looking at what you can learn from your competitions websites and how you go about extracting the maximum amount of information.

But before we can get into all that good stuff we first need to look at what has been happening in the world of web design over the last week.

News and events

Eric Meyer tries to prevent history repeating itself

First up in the news segment of the show today is a passionate call to action by Eric Meyer. Like myself, Eric has been working in the web for a very long time and is all too familiar with the problems of the past. He is a veteran of the browser wars (how dramatic does that sound!) and remembers the many problems that period caused.

During that time many web designers simply gave up trying to support multiple browsers and instead displayed the now famous message…

“Your browser is not compatible and must be upgraded”

It is therefore particularly disturbing when we thought those days are over to see the return of a similar message. As Eric points out in his post, those types of messages are returning in the form of…

“This site is for iPhone users only.”

As Eric says: Stop it! Stop it right now. He is absolutely right. There is no reason whatsoever for shutting out users from viewing iPhone optimized pages. Sure they might not look as good on a non iphone browser but other than that they should work fine on a compliant browser. To be honest, even if they don’t, that is still no reason to block non iphone users. If I choose to look at an iphone site on my Windows mobile device or even on my desktop browser, I am not going to expect it to look perfect. However, I could have all kinds of reasons for wanting to do it from wanting to check out the functionality to using an alternative mobile browser that is just as capable of displaying the content.

In Short, Eric argues (and I whole heartedly agree) that the “best viewed in…” approach to web design is a fools errand. Whether it is the iphone or something else, make sure you avoid that road at all costs.

6 Keys to Understanding Modern CSS-based Layouts

Talking about best practice, Jonathan Snook has posted a helpful article for those of you still struggling to move across to modern CSS-based layout.

As Jonathan says in his post…

Much of CSS is pretty straightforward and, I suspect, quite easy for most people to grasp. There’s font styles, margin, padding, color and what not. But there’s a wall that people will run into… that point where a number of key elements need to come together to create a solid CSS-based layout that is consistent cross-browser.

Jonathan addresses this challenge by talking about 6 key principles that will help you get over this hump. He talks about; the box model, floating columns, sizing with ems, image replacement, floated navigation and sprites.

Its an interesting list although I am not entirely sure I would include the same items. For example there is no mention of HasLayout or IE conditional comments. However, Jonathan does say it is just his take on things and encourages people to add suggestions in the comments so they are definitely worth reading too.

How to mix fonts

So you might be listening to this feeling smug about your CSS skills but how are you with typography? Working with type is a challenging area and one that is very easy to get wrong. That is especially true when trying to combine multiple fonts together in an effective way.

Fortunately, David who listens to the show, has sent me a link to a cheat sheet on mixing typefaces. Not only does it provide specific examples of typefaces that work well together, it also gives you some basic information on typography.

I am a great fan of cheat sheets and have a number pinned to my wall including my much loved microformats cheat sheet. So, if you are looking for some advice on typography add this to your collection.

Making money through forums

My final news story for this week’s show comes off of the back of a story knocking around here in the UK. A number of large companies have pulled their advertising off of Facebook following the discovery that those ads were appearing on the profile of the BNP (a pseudo- fascist political party in the UK). These companies were unhappy that their brands being associated with the organisation.

This Facebook story is indicative of a wider problem that advertisers seem to be having with social networking sites and forums in particular. So the question then arises, can you make money from a social networking site?

For most of us this is not a question we have to deal with. Most of us don’t run social networking websites. However, many of us do run forums and we are looking to make a bit of extra cash from them.

If that is you then you might want to check out “Can forums still make money?” on sitepoint. This post suggests a load of ways you can improve your return on your forum and make some cash to cover hosting costs. The post is very realistic suggesting that the vast majority of us are not going to get rich from our forums. However, it might help pay for your cleaner (which is what I spend my Adsense revenue on!) and so it is worthy of your attention.

As a slight aside before I wrap up the news segment of today’s show, the article also links to some useful tips from Google about maximizing your return from Google Adsense, so you might want to check that out too.

Talking of social networking websites, that brings me on nicely to my interview with Daniel Burka from Digg…

Daniel Burka talks about Digg

Paul: Okay. So joining me today is Daniel Burka the lead designer/creative director/God of all things user interface at Digg.com. Is that a fair way to describe you Daniel?

Daniel: That was a very polite introduction. Thank you very much.

Paul: Well, it is always good to butter up the guests at the beginning…

Daniel: [laughs]

Paul: I find it goes down better that way. [laughs] So Daniel, I thought that it would be great to get you on the show, simply because you seemed to have worked so extensively with web projects centered very much on social participation and web applications, you know, and various other Web 2.0 buzzwords. Obviously Digg.com is a good example of that. And a lot of listeners of this show are still working on content heavy brochure-ware type sites. But, they seem to be really interested in more interactive elements to their site. And so we thought, let’s get an expert on the show that seems to specialize in this area. So, here is my first question Daniel. What do you see as being the main differences between designing and social networking sites, compared to more traditional content heavy sites that I am sure you have worked on in previous lives, so to speak?

Daniel: Oh yeah, I mean absolutely. I worked on those kinds of sites in the past. The big difference with something like Digg is that all of the content on the site, pretty much, is provided by users and so we're building conduits as frequently as we can where people can provide their input, provide content you know foster discussion, these kinds of things so I guess wherever possible we're not only designing the technically areas that they can do it but focusing the design on encouraging them to participate.

Paul: So how to you do that? How do you encourage someone to participate in using kind of design tools and design approaches?

Daniel: Right. I guess the big thing is to make it obvious that other users have provided content to the site. So, making it clear that the Digg count went up because other people you know dug the story. You know, showing which users submitted certain things or which user made a comment. You know that indicates, Oh okay. Other people, like me, have participated and that might be something I might be able to do too.

Paul: So how did you deal with the kind of early days before Digg had really taken off? Where perhaps you had less content than you do now and you kind of want to give the impression that there is loads going on, when perhaps here isn't?

Daniel: Right. I guess by the time I got involved in Digg which is about 4-5 months after it had started. So Kevin and Owen originally developed the site.

Paul: Oh okay

Daniel: And then they hired the company that I work with in Canada. They hired us to come in and basically do a design review and redesign of the site and that was the primary focus of the redesign was to look and say, Okay, what is this site about? And what the site is about providing input and so the original design which was more definitely designed from an engineer's perspective. It had all of that content, it had all of the facts and the bits and the place to Digg something, but it wasn't very clear at all what you should do or why you should do it.

Paul: Hmmm.

Daniel: And so, you-know probably the most interesting thing I have ever done on Digg was to take the Digg count, to make it really big and stick it on the left and stick a really explicit Digg It button under it. So, I mean that's clearing indicating X number of people already participated.

Paul: Yeah.

Daniel: And if you want to participate hit the big button.

Paul: Yeah. The kind of putting right in front of peoples face where they can't possibly miss it, so to speak.

Daniel: Right. I mean that is the entire purpose of the website is to, you know, say you like something.

Paul: So what other kind of things did you implement in those early days when you came in and started redesigning the site?

Daniel: The original focus, I actually thought this was a kind of interesting approach to take. Steven and I were looking at the site and trying to determine that. It already, in some ways, had a fairly large scope to the website. So we were trying to determine where do we get started. Often that is redesign the look of the site or redesign the home page. We looked at it and what is the most important thing here and the story format, I think, was probably the most important thing about Digg. And so we looked at each individual story in the list. There is a whole row of them on the homepage. We got about 15 on there now. And kind of a singled one of those and dissected it and said, What is important about a story? Why did the user submit it? Why is another person going to be interested in it? How do I encourage them to participate into that story? And so, that story format counts for a few different iterations since we started.

Paul: Hmmm.

Daniel: I think that being the primary focus of ours.

Paul: I mean what about the kind of more rich elements that you started to introduce? Where there is a lot less page refreshes that perhaps there once was and you kind of changed the way the people interacted with the site by introducing AJAX and things like that. I mean was that a big shift? What kind of thinking went into that process?

Daniel: Absolutely. I mean that is critical to Digg's success. Owen and Kevin had already started playing around with AJAX and this was before anybody like Jesse James Garrett that coined the phrase, AJAX. So, we were still calling it Asynchronous Javascript and XML request. Thank God someone has shortened that. And the fact that you are requiring mass participation to make something interesting would be entirely stymied if we had forced a page reload every single time a person wanted to participate.

Paul: Ummm.

Daniel: So we are using that all over the place. The Digg It button is the one real obvious place. And then you know especially in the comment system. There are various other areas where we're basically allowing you to have a really low-threshold of participation. No long page loads. Immediate reaction that what I did I got a reaction back from that, so I get that positive feeling.

Paul: So how does that kind of process work within Digg? I mean are you actually involved in coding the AJAX elements or do you just do the user interface? How do those kinds of accountabilities split up?

Daniel: Right. I guess we've got a really good balance I think between the development and the UI design. We are really tightly integrated with the different teams. And we are getting big enough now that we can actually speak about them as teams. So generally the flow at Digg starts with it's great we have a really design focused process here that Kevin will come up with an idea and then he and I will bounce the idea back and forth usually and figure out what the pros and cons are and then kind of rough out the design aspect. And then, basically take it from the conceptual stage code it statically and then work with the developers in terms of coding the functionality into it. So I don't do a lot of PHP or very much Javascript, but I provide with them XHTML and CSS and obviously the images and work with them implementing the basic flows.

Paul: I think a lot of the impression I get is a lot of organizations is still struggling to work out whose responsibility is the AJAX elements. It's kind of client side stuff that is very user-interface oriented. So should it be a designer job or is it kind of so intrinsic in the kind of connecting to the database and pulling out the content and that kind of thing which is actually a developer's job? It's quite interesting to hear how different people do it.

Daniel: Right. We probably fall into the developer's side of things. You know, it is submitting content to the database which is not horribly different than a normal form submitting to the database.

Paul: Yeah.

Daniel: So that is probably how we line it up.

Paul: Yeah. You guys seem to be doing some interesting things at the moment. One of the things that I imagine is particularly challenging is that you got a tech-savvy audience which is where Digg started. But you're constantly at the moment in this process of broadening that audience out to be more of a mainstream audience. And I'm just interested from a kind of design point of view, and user-interface point of view, what challenges that has presented you as far as shifting that audience. You know kind of in-mid process if you want. Most websites have a fairly good idea of who their target audience is upfront. But you are having to adapt that as the site evolves and I imagine that must be tricky at times.

Daniel: Oh, absolutely. I mean we started off as you said as very a tech-heavy site at about this time last year. I guess just over a year ago we broadened out very explicitly by introducing other content areas to the website. As we grow, and as a less tech-savvy audience comes in, there definitely is a real dichotomy between the perceived power-user who understands the very complex form type systems versus people who barely used a comment system on a weblog. On different areas of the site that level of experience I guess really comes to the fore. Although, I think I really take inspiration from the FireFox Project in that regard – particularly in Van Gudgers response. He is one of lead engineers on the FireFox Project. One of his best qualities being saying No! during the FireFox development and a lot of power-users perceive that they want all of these options at their finger tips. They want a hundred different options, if there are a hundred possibilities. Where as, in reality, having a simple system actually works better for both the power-user and the relative novice. I think the correlation between what happened with the Mozilla Suite, which was the previous iteration before FireFox which had a lot of different features and a lot of different buttons and customizability, versus FireFox which is really the torn-down simple browser. Which really ended up serving both audiences better.

Paul: So have you had the kind of guts to take functionality away or are you more kind of hiding it away so that it is still accessible to the power-user wants to go and get it?

Daniel: Well that is definitely the balance that we try and make. I think hiding the functionality is actually I was just reading a book a friend lent me. John Maeda’s book The Laws of Simplicity and he covers this subject. I think that it is really interesting that you can hide functionality as long as it doesn't feel intimidating and as long as you are not obscuring the functionality. I think you can actually, quite successfully, create a simple site by tucking functionally under the right areas, I guess.

Paul: That struck me. This whole idea of dealing with different types of audiences is a very challenging area. You have been at Digg for a while now, what has been the most challenging aspect from your point of view?

Daniel: Well, I think managing user feedback is definitely one of the big points of working at Digg. It is very intimidating working on a site where, every time you want something new, you have about 2 million people seeing it the next day and giving you their feedback on it. It is fantastic! It is really inspiring and exciting – and at the same time horribly intimidating. It is hard not to get frozen-up when you are about to launch something in two days and you kind of have to brace for the criticism because you know that people are going to be critical. And I mean that in the positive sense. They are going to critique what you have done. And so, being able to basically listen to a wide range of opinions and make sure that you are listening to everyone. But, you don't necessarily do what everyone says because there are obviously people with conflicting opinions and there are people who have very specific interests that may or may not be reflected by other people. I think managing those expectations that people want to know that you are listening to them and they want to see their suggestions reflected in what you are doing. Balancing those types of expectations is a really challenging part of the job.

Paul: So how do you go about that? How do go about deciding which suggestions you are going to implement and which you are not? Do you have some kind of process for that?

Daniel: I'm not sure if it is horribly formalized. I think the first and really important thing that we've learned at Digg, and I have learned on other projects being worked on, is taking a really deep breath. People will immediately ask for feedback on something, the minute you launch it

Paul: Yeah.

Daniel: They will ask for change. So don't make a change for the first week, unless they point out obviously drastic problems that you didn't anticipate. Take a deep breath. Let people give their feedback. Let them get some experience with the change because people are adverse to change generally. Their first reaction is going to be, Well I was familiar with it the other way, now it is different and I don't feel comfortable with that. And so, you will get a lot of feedback in that regard. And then carefully go through and filter and look for themes of feedback from different people. Try to determine why they were giving that feedback. And then iterate from there. I think that iterative process is so important.

Paul: One of the things that I think everyone has noticed recently about Digg, is that you released this iPhone interface. Everybody is going on about the iPhone endlessly and I am hugely jealous that we don't have it over here in the UK. And so, I am obviously bitter and twisted about it.

Daniel: [laughs]

Paul: But, putting that aside there is this plethora of iPhone applications coming out and Digg is one of the people who have done it. Were you involved in that putting it together?

Daniel: Yeah, absolutely. Joe, who is one of our developers, kind of came over and he was talking about it and was thinking it would be a great idea. And we both kind of got excited and pumped the whole thing out over our weekends.

Paul: Ahhh.

Daniel: Big props to Joe Hewett, who is not the Joe who works here, but Joe Hewett has made this great framework basically to start developing for iPhone applications in Safari.

Paul: Ahhh.

Daniel: He actually released a prototype of it on Friday afternoon. I think? And we started off from there and started developing. That is what does the sliding effects in our interface.

Paul: Okay.

Daniel: And we kind of took what he had done and I think we launched on a Tuesday the next week and on Wednesday Joe had already refined it and made into a kind of framework more people could use. So it was very useful to us.

Paul: So how do you feel about that, because that is a very different interface to be developing? It is much more controlled. You know the browser you are aimed at. You know the screen size. Was it a pleasant experience?

Daniel: Oh, absolutely. It was really really fun. I mean, there were a few things that were really fun about it. One, you are absolutely in that controlled environment. I mean people aren't resizing there fonts. You have a controlled number of fonts. You know the resolution. You can accommodate for when you flip the screen and it goes to wide-mode. And plus you are working with a rendering engine that doesn't suck.

Paul: [laughs]

Daniel: So it is really fun. [laughs] I mean you can even use advanced Webkit only type rounded corners and all kinds of fun stuff like that so, that part of it is really liberating. I can just imagine if all web design was like that. You know if all browsers were actually as standards compliant as they think they are. So that was fun. But, I think the most interesting thing is that you're working with an input device that is this big-fat-honking finger. And so, everything you do you have to be thinking about that. I think it will be interesting to see who succeeds at developing applications like that. But, you really have to think about pairing things down.

Paul: Yeah.

Daniel: When you are clicking with a finger there is no way you can have four or five buttons in a row and expect the person to be able to pick one out when they are sitting on a bouncing bus, with this phone in their hand. And so, buttons have to be really big. The Digg button on the source pages for instance is about two and a half times bigger than one on the normal site. And the links, we considered two different links. One to go to the source and one to go to what we call the Permalink page, the story page, of that particular item. But you know, even having just two buttons per story was much too difficult on the iPhone so we just have one you just can't miss which is a big finger button and it slides over and you get the story.

Paul: Yeah. Do you think you will be doing kind of more with Digg where you are kind of delivering the content, through other various mechanisms; such as the iPhone? I mean, could you imagine doing stuff with desktop applications like using AIR or anything else? Is that an area that you think you would get into?

Daniel: I think the really exciting thing is that we are finally getting a proper API out there. And so, I guess we launched the API maybe two or three months ago. Maybe longer than that, I forget, but I think it will be really interesting to see you know if a desktop experience of dig is really valuable somebody is going to pick up that project and go with it.

Paul: Sure.

Daniel: And they'll develop it on the API. So, I'm not sure if explicitly if a desktop application will be great, but I could see it having certain benefits and maybe toying around with the idea ñ for sure.

Paul: Is there something personally you are interested in as a web designer doing, you know, it's a different medium again isn't it? You're going from a browser based environment to a desktop environment. Is that something that interests you personally?

Daniel: Oh, absolutely. I think it is interesting that those lines are really blurring. I mean, AIRs is that first salvo, in that regard, you really are to a large degree developing a web application. You can develop it in HTML and CSS with basically the same skills it takes to make an iPhone application, or a basic website, you can build an AIR app. That is pretty exciting. I think that once that platform matures, it could open up a whole range of things.

Paul: From a personal perspective, what is the area of your job that you most enjoy?

Daniel: I really enjoy trying to make things easy for people. Sometimes is really irks me if Kevin describes my job as making things pretty.

Paul: [laughs]

Daniel: I think it is such a minor part of design. You know it is an interesting one. But I think sitting down trying to determine, when you are looking at a fairly complex system you are trying to build, and trying to figure out how to not be complex. What to takeaway, how to design something so that it feels simple by putting the really important things upfront. And throwing it by some users and watching them how they do it. I think it is really exciting to see somebody participate in something that is under the hood really complex, but which they have fun and they feel that they are participating. And they do not put a lot of thought into what they are doing, they are trying to achieve what they came to do.

Paul: What about the fact that you kind of have been working on Digg for a prolonged period of time and it is that one site you have been working on continually? I guess because I work for a web design agency where I have a series of clients back-to-back and I am doing different things the whole time. Sometimes it strikes me that we're working on a project for a prolonged time is both a blessing and a curse. I just kind of wondered, what you think? Do you really enjoy being able to spend time digging into that one area?

Daniel: That is a very interesting point, because I also come from the web design company background where I basically would do a different project every month. And until December I was still fairly heavily involved in the day-to-day affairs of my previous company, so it has been a reasonably new experience for me

Paul: Oh I didn't know that.

Daniel: To be working solely on one site, with Pounce on the side. [laughs]

Paul: Yeah. [laughs]

Daniel: Another site I have been working on. So this is really very interesting. Absolutely, there are so many things fantastic about it. It is really fun to be able to go into great detail and have the time to go back into something you designed previously, and to alter it. It is not necessarily that you made a mistake, but a month later you suddenly realize that a big improvement to that would be if I did X. And so you actually have the opportunity to go back and do those kinds of things. Where as I am sure, if you were working with a client, it has happened before that you know six months later you see something you say it is obvious to me now but it is kind of out of your control. The contract is over. You know

Paul: Yeah

Daniel: They're working with a different firm. There are all kinds of things like that. And so, working on something as big as Digg it is really fun too. Within Digg there are lots of different projects. There are different pages. There are new things we are working on. And so you kind of I guess segment them into kind of different projects you can go around in a circle and come back to later on.

Paul: Do you ever envision a day where you throw out the existing user interface and apply a new one? Or do you think it will always be a kind of evolving iterative process?

Daniel: Oh, I think an iterative process for sure.

Paul: Yeah.

Daniel: I don't want to second guess what is possible in the future. We may have some brilliant idea or new technology that blows our minds. But, I think there is no reason to throw out something that is working pretty well. I think there is a kind a rush sometimes to you know, to start from scratch that real desire to start from scratch sometimes. But something like Digg, I mean it has changed fairly significantly over the last two years, but I don't know if too many people notice

Paul: Yeah.

Daniel: Other than a few big pushes we made, that things had changed much. I think that is really healthy that people become familiar with systems. They learn how to interact with them. And to really shake them up, you really better have a damn good reason to do it.

Paul: Yeah. Okay so last question then before we finish up. Is there any stuff that you are working on with Digg that you are allowed to talk about [laughs] because obviously there are things you are not allowed to talk about.

Daniel: Right.

Paul: But the stuff that you are allowed to talk about, what is really exciting you and what are you really enjoying getting into at the moment?

Daniel: Oh, there is a bunch of things. I think I am allowed to talk about that Kevin mentioned the other day that we are working on the images section.

Paul: Cool.

Daniel: So we are going to do right now you can do news and videos. And we are pretty confident we are going to get into images as well. And so we are working on a couple of projects to kind of lay the framework for doing that. So, some people think it is as easy as adding a section

Paul: Yeah.

Daniel: And putting a title on it. But if we want to do that, we want to do it the right way. And lay the ground work first. I am working a couple of things I cannot go into great detail unfortunately there so much secrecy here that we can't

Paul: [laughs]

Daniel: Layout too much of what we are up to. But, I am really excited that we are headed in this direction.

Paul: Yeah. The trouble is that you guys get ripped off so quickly, don't you, that you need to keep things quite.

Daniel: Well. I think it is a combination of problems. One is that we are obviously concerned with people duplicating our features and the other one is that we want to be careful setting expectations. Because if we say we are going to do something, we really want to do it.

Paul: Yeah.

Daniel: And I think people will get disappointed if we say, In two months we are going to launch such-and-such. and you know lot's of stuff happens in two months. And unfortunately if that had to get pushed back, and that two months was a totally random date that I pulled out of my head

Paul: [laughs]

Daniel: [laughs]

Paul: See know, we all believe that it is all going to happen in two months.

Daniel: Shoot! [laughs]

Paul: [laughs]

Daniel: [laughs] People will be disappointed or they will feel like we haven't lived up to their expectations I suppose.

Paul: Yeah. Okay. Well that was really great. Thank you very much for coming on the show Daniel. No doubt we will try and crowbar you again in the future to come and talk to us about Pounce as well. Because that is an exciting project.

Daniel: That would be fun.

Paul: Okay thank you very much for your time and talk to you again soon.

Daniel: Thanks so much for having me.

Paul’s corner: Quick and dirty competitive analysis

Great stuff from Daniel! It was really fun to speak to him even though I managed to offend him after we stopped recording by calling him an American (he is Canadian). Hopefully he will forgive me for the ultimate crime!

Okay, so before I wrap up today’s show lets take a quick look at the subject of competitive analysis. Its actually a segment I have just written for the book I am working on and so I thought I would share what I have covered. The idea is not to make you an expert in the field but simply to allow you to extract as much information as possible from your competitions websites in a quick and easy manner.

As always I have written this up as a blog post entitled “Quick and dirty competitive analysis” so check that out in the show notes if you want to see exactly what I covered.

No show next week

So that is about it for this week’s show. Remember that there will be no show next week as I am going away on holiday too! Yippee! However, if you need your boagworld fix don’t forget you can check out the forum and chat with other people about the poor quality of Marcus’ jokes.

Show 86: Boagworld Book

Posted in Classic shows on July 10, 2007 by Paul Boag

On this week’s show: Paul talks about taking a brand online, Marcus gives some advice about reviewing your information architecture and Ian Lloyd introduces us to the challenges of designing for screen readers.

Podcast: Download (44.6MB)

Download this show.

Launch our podcast player

Paul’s personal news

Just a bit of personal news before I get into the industry related stories. I want to let everybody know I have signed a contract to write a book. The book is going to be primarily for website owners rather than web designers, however to be honest I think it could appeal equally to both. I intend to look at what “client’s need to know about building and running a website” so hopefully it should show by example how best to communicate and work with clients.

The most exciting thing about this book from my point of view, is the fact that I want to write it as a collaborative process with you the boagworld community. I am going to release chapters for you to see in advance of publication and also blog on various aspects of what I am writing. I really want to encourage you to share your thoughts and make suggestions as we go along through comments and the forum. I have already set up a forum thread dedicated to book ideas as well as an initial blog post on the book.

Obviously writing a book is a really slow process, but hopefully it is something that we can all get excited about.

News and events

Building for the iphone

Unsurprisingly there is a lot of information appearing relating to building web applications for the iphone. There is an iphone gallery consisting of hundreds of screenshots of the iphone. This is great if you want to mirror the look and feel of the iphone as closely as possible. There is also the iphone developers guide from Apple which provides loads of great advice. Finally there is iphoney, a piece of software that replicates some of the iphone’s web browsing functionality and lets you see what your application will finally look like.

Of course whether it is worth developing for the iphone at this stage is another matter. I guess if you are trying to reach the tech-savy audience who are iphone owners then maybe. Otherwise it might be better to wait until the iphone becomes more mainstream or other phones start offering the same level of web experience.

@media podcast

I was gutted to miss @media this year. Well, I say gutted, I was actually on a really pleasant family holiday, so I cant complain. However, I did miss a great line up of speakers talking about some amazing subjects. I was particularly depressed to have missed Jesse James Garrett’s keynote on “Beyond AJAX” and “Diabolical Design: The Devil is in the Details” by Jason Santa Maria.

Fortunately the recordings of the @media sessions are beginning to filter out for me to download and listen to. However, note that I don’t call them a podcast. There is no feed that I can find which is extremely frustrating.

Setting that little moan aside, it is great to be able to listen to these speakers even though I did not attend the conference and I would strongly encourage you to download and listen to a few yourselves.

Common mistakes in web copy

Although we would prefer to avoid it, the reality is that as web designers we write far more copy than we would like to admit. As for those of us who are website owners, a substantial part of our responsibility is writing good web copy.

We have talked on the show before about writing good copy but our focus has mainly been on style rather than technical detail. This week, I came across a post about common grammatical mistakes. However what I liked about this post is that it wasn’t focusing on the silly details of grammar that don’t really apply particularly well to the conversational tone of the web. Instead it looked at errors such as when to use “me, myself or I” and the difference between “i.e. and e.g”.

If you ever have to write copy then spend a few minutes to check it out. It only covers the worse offenders so doesn’t take long to read.

A department dedicated to the web

Jeffrey Zeldman has written a post entitled “let there be web divisions“. If you are responsible for deciding who should manage your corporate website then you simply must read this. If you are a mere foot solider then it might not be as relevant but it is still a good read.

Basically Jeffrey proposes that a company website should not sit under IT or marketing (as is traditional) but should be a division in its own right. I am not going to repeat all of Zeldman’s logic, but I have to say I wholeheartedly agree with it.

Websites are simply too multi disciplined to sit comfortably under either department and too important to be caught in an endless tug-of-war.

Paul’s corner: Taking a brand online

About a week ago, I had to give a presentation to a board of directors ,explaining the process we went through to develop a new design for their website. A large proportion of that presentation focused on the issue of brand identity. This organisation had a very well developed style guide and we spent a lot of time and effort getting that guide to work online. My presentation talked about the various steps involved and it occurred to me this might make an interesting podcast section.

I have also put together a blog post on the subject of “taking a brand online” and it is this that I cover on the show.

Marcus’ bit: Information architecture review

I am currently in the process of carrying out an information architecture review for a new Headscape client. I have done a fair amount of IA work over the years but I have found myself particularly enjoying this one so I thought I’d waffle on about what I’ve been doing.

We have covered the various aspects of IA work in previous podcasts – Expert Review, Stakeholder Interviews, Card Sorting and Wire Frame testing. This section is looking at the first of these, expert review, in a bit more detail.

I think it’s worth explaining what I mean by Expert Review. When we carry out an Expert Review we are effectively analysing a client’s existing site content, site structure and naming conventions with a view to creating a new IA based on our experience of using and developing websites. This is a collaborative process with the client – it has to be; we can make logical, usability based decisions but cannot claim to be experts in the client’s particular field.

First things first

I make sure that I have a good grasp of a number of things prior to carrying out an IA review. At the kick off meeting make sure the following are covered:

Target audience – this is crucial for the development of the IA. It may be that the existing site caters for one group well but another poorly.
Site aims – is there a stepped process that the client wants their users to go through.
Design – things like horizontal over vertical navigation can affect the IA.
Homepage requirements – find out what the killer apps and content are as these will need to be linked to from the homepage.
Finally, have a general discussion about content and site structure. See what the client thinks is important and what’s not.

Map out the existing site

The first thing I do is map out the existing site’s IA. This is a fairly slow and laborious task but it is the best way to not only learn about a site’s content and structure but also to understand what they do and what they offer.

Be logical, captain

Usually, the goal of this type of exercise is to streamline content into groups and name those groups so that users will understand what’s inside them.

Site’s that have grown organically over a period of time tend to spread content all over the place. It is usually fairly easy, though time consuming, to group content together. There are various methods for doing this; I tend to print out the existing site IA (that I usually create in Excel unless it’s a particularly small site, then I might use Visio) and scribble all over the printout until I’m getting somewhere. Some people like to use cloud/cluster diagrams (either on paper or using software) or there is always the age old method of creating ‘cards’ where each page name is written onto a scrap of paper. This is a bit like doing card sorting on your own where you group the cards into piles and give names to each pile.

Naming

We come from the ‘it does exactly what it says on the tin’ school of page/section naming. Marketing departments often don’t! A good example of this is the trend to verbs as section names over nouns. I remember one client wanting to call a site section ‘Enjoy’ when the section covered ‘Leisure Activities’. No prizes for guessing what we recommended!

Labels should be as descriptive as possible. Sometimes this can be difficult when:

there isn’t much space, for example, ‘How to register for our newsletter’ won’t fit on the average button, even ‘Newsletter Registration’ would probably be too much for a top level, so I would go for just ‘Newsletter’. It’s fairly obvious that the content underneath will relate to the organisation’s newsletter and should logically include registration, whereas ‘Register’ leaves the user asking ‘register for what?’
Sometimes sites are so big that main sections can include too much differing content to be labelled descriptively. In this case, I would recommend either shortcuts on the homepage replicating the main sections that include descriptive words or create drop down navigation that displays the lower level links.

Section ordering

This should follow some sort of desired path through the site. For example, the client may want users to get a bit of background, followed by an understanding of what the organisation offers, followed by some examples of previous work with a view to finally making contact. This would translate to:

About Us | Services | Case Studies | Contact Us

Conventions

Users don’t want to have to think (that sounds familiar!); they want to look and understand straight away. Following conventions helps with this process. For example, many sites include an About Us section as the first main section. This usually includes some history, annual reports, job vacancies and contact details. Users looking for this type of information don’t want to have guess that this information might be under, for example, ‘Company Background’ which is located at the far right of a horizontal navigation.

Collaborate – to a point

When you have created your first draft it then needs to be reviewed by the client, discussed and iterated until everyone is happy. Take on board any changes that are based on your lack of understanding of what the client does but be prepared to stand your ground on issues relating to web conventions and usability – after all, they’re paying for your expertise.

Ask an expert: Ian Lloyd on screen readers

On this week’s show we have Ian Lloyd giving us an introduction to the world of screen readers. I vividly remember the first time I heard a screen reader being used. I was gob-smacked by how painful an experience it was and I am still amazed that anybody manages to use them effectively.

It struck me that many of you listening to this show might not have heard a screen reader before. Hearing what blind people have to work with really makes you take their needs seriously and so I thought I would get Ian on the show to give you a taster.

In his segment, Ian takes us through some classic problems that screen reader users experience. Unfortunately to best understand what is going on in some of the examples you need to see what he is doing. In order to get around this problem Ian has made a screencast to accompany the audio. There was too much detail to make it available online or via your video pod but you can download the screen reader .mov file here.

What follows is a transcript of Ian’s section of the show…

Hello Paul, Hello Marcus and hello to listeners of Boagworld. This is the ‘Ask the Expert’ section and today I’m going to be talking about screen readers.

Now, I don’t actually qualify [meant to say classify!] myself as an expert screen reader user simply because I don;t use one on a day-to-day basis, because I’m not forced to; I do have good vision. As such, the way that I would use a screen reader would be different from someone who has to use it on a day-to-day basis. That said, I still think it’s useful to demonstrate to people what a screen reader sounds like. And the reason for this is that as far as I am aware on your podcast although you’ve talked about accessibility a lot and mentioned screen readers I don’t believe we’ve ever had a demonstration of what they actually are like for people when pages are built incorrectly.

So, today I’m going to be showing a few problems using a screen reader. I’m also going to be doing this as a video, so this is a screencast. I understand that at the end of this you will be providing a URL for listeners so that they can access this and view what’s happening on screen. Because of course it’s all well and good to listen to this stuff but to get the full context it would be good to actually see the video as well. I will try my best to describe what’s happening on screen throughout this podcast though.

Now the first example we’re going to look at is Amazon dot com. And somewhat cheekily I’ve brought up the page for my own book on Amazon. And, er, just having a look around at what I can find on the screen and there are some issues there. So, let’s have a look at this.

[Screen reader reads out page graphic correctly 'Build your own website the right way using HTML and CSS, Link graphic']

Oh, so that’s not too bad. I’ve just found an image there and it’s announced it correctly because it’s found a suitable alt attribute but underneath there are a couple of thumbnail images which, if I want to access those, it gives me a whole different … well, hear for yourself:

[Screen reader announces: 'See larger image, Link' then moves to next link, the thumbnail image and reads an unintelligible string of characters - numbers letters and underscores - out to the listener].

Mmm, doesn’t make an awful lot of sense does it? Let’s try the next image:

[Screen reader reads out more unintelligible characters and takes almost 8 seconds to read it out]

So, what’s happening there? Well, it’s quite simple: there’s no alt attribute defined for that image and so JAWS tries to fill in the gap and, er … oh I didn’t mention earlier that JAWS is the name of the screen reader that I’m using. So it tries to fill in the gaps because it doesn’t have an alt attribute it uses the file name instead and the filename, as is often the case on Amazon, is a right load of old gobbledegook! So it doesn’t give it any useful information about that image.

Here’s another example of the same thing.

[Screen reader reads out an image gallery as 'thumbs slash zero, thumbs slash one, thumbs slash two' etc]

So this is actually a photo gallery, erm, with a bunch of thumbnail images hence it’s reading ‘thumbs’ because that’s the folder where the thumbnail [image] is actually in and it’s reading them sequentially as well. It doesn’t sound quite as painful as the Amazon example but it still doesn’t tell you any useful information about the images on the page.

[Screen reader announces more examples from the same page]

So let’s listen to a slightly improved version of that:

[Screen reader announces the same images but with appropriate alt attributes, e.g. 'The Mystery Machine, driven by Scooby' for a photo of a camper van that is painted like the Mystery Machine from the cartoon Scooby Doo]

If we were to look at that on the video I’m showing that page with the style sheet disabled and the alt attributes displaying inline next to the image. As you could hear in the second example it was far more usable – you could actually understand what the image was about (as long as you understood some of the VW terminology used in there), whereas in the first example none of the images actually had alt attributes so it was just trying to read out the location of the file.

So let’s look at another example.

[Screen reader announces content of new page 'Page has no links' and then starts reading subsequent page content before I stop it]

What I’m looking at on screen is a page that seems to have a page full of links. But if you were listening carefully to the beginning of that, the screen reader thought otherwise. I’ll just try to find that again for you.

[I scrub back in the video clip to find the part where the screen reader says no links]

According to the screen reader the page doesn’t have any links. And the reason it thinks that is, well, there *aren’t* any links. What’s actually happening … is … we have a whole bunch of text on the page that is styled using CSS and the behaviour for the link is added using JavaScript. So, we have a <span> element that has an onclick event, location.href=’somewhere.html’ and that’s [the span] wrapped around the text that says ‘This is a link – click me’. Um, but of course it’s not a link. The screen reader can’t find it because it’s not an <a href="">, it’s something else that’s been styled to look like a link and behave like a link. But it’s not. Thankfull that’s not too common but you have to just be aware that what may look great on screen for you may not be any use to someone using a screen reader. You have to use the right markup for the job.

So, you could have a page that’s full of links that say ‘click here’ but of course that’s another problem all in itself. Let’s have a listen to that:

[Screen reader reads 'Click here to view' repeatedly as I tab through the links on the page]

Yes, so … the problem there is that it doesn’t give you any information at all. And this is actually still quite common. In fact just yesterday I was looking at Facebook dot com (for my sins) and, er, I was quite shocked to find that they were using a lot of this where the link phrase was ‘click here’ as opposed to the phrase that you would really want to have, so for example instead of saying ‘click here for more information’ and having ‘click here’ as the link phrase you would have ‘for more information about our products’. That would be the link phrase. Erm, but if you just use ‘click here’ and you’ve got a whole page of links that reads ‘click here’ this is what you get:

[Screen reader once again reads 'Click here to view' repeatedly as I tab through the links on the page]

Basically, completely unusable.

Now the next example I have is of a form, and in this example, er, the form has been laid out using a table. Thankfully, these days, tables are being used less for layout and people are using CSS for page layouts. However, for forms it’s still not uncommon to see someone put a table in there. And, er …

[screen reader interrupts as page loads]

OK, so in this example what I’m looking at on screen is what appears to be, um, well … four text inputs, and then there is a radio button and it’s basically asking for some personal information, first name, surname, your age, place of birth and then a question ‘Do you have a nut alergy’, the answers being ‘no’, ‘yes’ or ‘don’t know’. So let’s see what the screen reader makes of this.

[screen reader says 'table with two columns and four rows'. I tab to the first input and it reads 'surname/family name - edit']

Already we’re hitting a problem. Because the first field that I tab to I can see on screen is *actually* [the one for the] the first name . But the screen reader believed that to be the surname.

So I’ve now tabbed to the second field which is the surname and it didn’t announce anything. So let’s tab to the next field:

[screen reader announces field as 'town/city - edit']

Again it’s getting it wrong. I’ve actually tabbed to the field that says ‘Age next birthday’

[tab to the next field, screen reader announces 'tab - edit']

And *now* I’m in the ‘town/city of birth’ field and it hasn’t told me anything.

[screen reader announces 'yes - radio button', then 'don't know', reading the radio button choices]

This is all a bit confusing here. OK, so it’s asking me the question ‘Do I have a nut allergy?’.

[I tab to the next field, screen reader announces 'Yes - radio button - unchecked']

OK, so … that thinks I’m at the yes radio button but I’m looking at it on screen and it says ‘no’. So, what’s going on here? Now this is going to be a difficult one to explain on the podcast; this is one of the sections where you really need to see the video. But what’s actually happening here is we’ve got a table to lay out the page and the text sits above the text input, so for example where we’re asking for first name, the text that says first name is in the first column and the input that relates to that is in a column underneath, sorry, I mean a table cell underneath it in the next table row. Now the reason this is causing a problem is because if you were to actually linearize that table, in other words look at it in the order of the source code you get a very different view of it. And this is what happens with the screen reader. So if I were to look at this form and read it out in a linear fashion, it goes like this:

First Name [text]
Surname [text]
Form input for First name
Form input for Surname
Age [text]
Town/City of birth [text]
Form input for Age
Form input for Town/City of birth

And so on. The problem is that the screen reader expects the text for that input to appear before that input, and because of the way this has been laid out it really really gets things confused. As I said, this is quite a difficult one to explain on the podcast but if you look at the video clip you’ll see why this is causing a problem.

[screen reader blurts a few things out as I try to manipulate it ... poorly]

Sorry about that, that didn’t add anything useful at all. Hopefully Paul can edit that out!

OK, so …. the big problem here is that you may be asking a question as we have here that says ‘Do you have a nut allergy?’ and the answers are ‘no’, ‘yes’ and ‘don’t know’. But if you do put the form elements in the wrong order you’re gonna have a problem. And the reason is obviously that with a nut allergy that could be a life or death situation. You could be filling out a form as a blind user and you select what you think is the ‘yes’ radio button but because the form has been poorly laid out and doesn’t have <label> elements that are actually helping to enforce the accessibility you may actually have been selecting the no checkbox [meant to say radio] and it really could be a life or death situation. It may *not* be as bad as that – it could end up with you booking the wrong hotel location or date. So you have to be very careful with the form layout.

OK, one final example. Now everyone’s talking about AJAX, it;s the buzzword of the moment. Unfortunately it’s also not very good for screen reader users. And the reason for this is that, er, anything that is updated on the page after page load is very very problematic to pass on to the screen readers. now the example I’m going to give here is a fairly simple one, and it’s the Google Suggest page. What Google Suggest does is let you type in your search phrase and as you type it’s calling back to the server, finding suggestions for you which it then populates in a list underneath the search input. So let’s have a listen to that.

[screen reader announces: 'google search - edit, type and text' then reads each letter of search term 'this is a test' as I type]

So I’ve just typed ‘this is a test’ and on screen underneath that is a whole bunch of suggestions that it has found. But if I try and actually access any of those using the keyboard:

[screen reader announces 'Google search - edit, Google search - edit, Google search - edit, Google search - edit' with each keypress on the down arrow]

It’s actually doing nothing. On screen I can actually see that it’s going up and down the options but the screen reader, it’s getting nothing back at all, nothing useful at all.

[more screen reader confusion]

Well thankfully with Google Suggest this is something tat you can opt out of – you don’t have to use Google Suggest, it’s not enforced on you. But it’s a very simple example and it just goes to show that a very simple technique like this can be, basically, completely unusable for someone using a screen reader.

So, that was just a few examples. Hopefully you’ve had an indication of how a poorly built website or web page can affect a user. the bottom line is, keep listening to the podcast, keep doing things right, keep using good markup and, if you can, test your own web pages or web sites using a demo version of JAWS. It really does pay dividends to find out how this works – or doesn’t work. So, thank you very much, I hope this has been useful, and I look forward to the next podcast, Paul. Thanks guys.

No show next week

Unfortunately there will be no show next week as I am away speaking at the Institutional Web Management Workshop. However we will be back the week of the 23rd July.

Show 83: iphone bollocks

Posted in Classic shows on June 19, 2007 by Paul Boag

On this week’s show: Paul talks about the importance of undo, Marcus explains the benefits of stakeholder interviews and Struan Robertson highlights some legal deathtraps waiting for us online.

Podcast: Download (19.3MB)

Download this show.

Launch our podcast player

News and events

Safari for Windows

Probably the most talked about story of the last week is the fact that Apple have released Safari for windows. To be honest I am a little surprised just how much has been written about this considering I don’t think the impact is going to be that significant. Will Safari cut into Internet Explorers market share? Probably not. Will it undermine the market share Firefox has developed? Almost certainly.

If safari under windows rendered exactly the same as under OSX then there maybe some benefit to windows based web developers. At the moment it is impossible for them to test on Safari without buying a mac. This has the potential of changing that. However, in all likelihood differences will emerge and if they do then this is just another browser that we have to test against.

We will see.

Applications for the iphone

At the same time Steve Jobs announced Safari for windows he also talked about the iphone. The biggest criticism of the iphone to date has been the fact that it is locked down so third parties cannot develop applications for it. Apparently Apple have been thinking long and hard about the problem and have come up with a solution. They are going to allow developers to build web 2.0 applications that can be accessed by iphone users using the built in Safari browser.

What a load of bollocks. They are telling us something we already knew. As soon as Steve Jobs announced that the iphone carried a full safari browser we knew that web applications would be developed for it. Sure, they are now saying that methods are going to be provided to automatically access iphone features such as dialing and google maps but very little detail was given. As far as I can see Apple is not giving people anything more than they already had.

Jason at 37 Signals is excited about what this means for web apps. He says…

This is the coming out party for web apps. We are very excited about this. These are exciting times.

…and he is right. It is exciting for us web developers. However, I am not convinced the user will see it that way. David Shea mirrored my own reaction at this news when he simply posted a graph showing the astronomical cost of data calls on mobile carriers. Web applications are great for web designers but for users of mobile devices like the iphone they could quickly be prohibitively expensive.

Web Design-isms: 7 Surefire Styles that Work

I found a great article on Think Vitamin this week that talks about design trends on the web. One of the things you learn early on as a designer is that despite your desire to produce something completely original you never will. Everything has been done before and in this article Larissa Meek takes us through 7 styles of design that appear again and again on the web.

The article very much reminded me of design meltdown, an excellent site that showcases different approaches to design. However, what I particularly liked about this post is that the author showed examples of how these styles occur in art as well as online. This is nice because it encourages us as web designers to look beyond the web for inspiration, a subject I have spoken about before.

CSS frameworks

The final story caught my eye because it is an extension of something we have been doing for a while. A while back I talked on the show about the fact that Headscape work with standard XHTML templates. We use these templates as a starting point for development. They allow you to jump start the build process as well as ensure consist naming conventions across the entire design team.

In a new post on the List Apart website Jeff Croft proposes a similar approach for CSS, based on the concept of Frameworks. Jeff argues that certain aspects of CSS development are often repeated across multiple projects. From browser reset styles to creating horizontal menus and standard grid layouts, it seems absurd that we generate these from scratch each time. Jeff proposes that instead we create a series of CSS files that we can be reuse again.

Its a great idea and one definitely worth exploring if you work on lots of similar projects or are part of a large team where you are looking for consistency.

Agony uncle: The importance of undo

A couple of weeks back I received this email from Tom in Texas:

I am a designer currently working on developing a web 2.0 app. The developer is doing some really cool AJAX stuff but unfortunately most of it breaks the back button in the browser. He is arguing that it doesn’t really matter as there are lots of other ways of going back. What is your opinion on the subject?

Once I had recovered from the naivety of the developers comment and finished counting slowly to 10, I started to think through the role of undo. In the end this very simple question from Tom evolved into a blog post on the importance of undo. It is this subject I am looking at in todays show.

Client corner: Stakeholder interviews

Got this question from Dusted.

I’m about to begin a project to help an organization evaluate its current web site and web site management. I’m also going to perform some research and planning to help them start developing a new web site.

The organization is quite complex with a lot of different departments – marketing/events, sales, information/press, youth and more. Each person responsible for each department will be interviewed and I need some advice about what questions to ask them.

Starting off with a few…

Describe your department’s needs of the web site.

What can be done in a better way?

The results of the interviews will be used when I present my evaluation (and research/planning) to the board.

Any advice, links to articles, books… help of any kind would be deeply appreciated.

We have done quite a lot of stakeholder interviews over the years so this question seemed like one I could help with.

Stakeholder interviews can often be confused with user interviews, as they can often happen during the same process. I tend to differentiate the 2 by calling them internal and external stakeholders. These groups will always require a very different set of questions.

This piece refers to internal stakeholders only; those people that:

Will be paying for the project!
Are content owners
- Some won’t know or want to be content owners – “that’s X’s job”
- Some will consider their content considerably more important than everyone elses – “there should be a tab called ‘Corporate Accountancy’ and a big ad on the homepage”!
Will be users e.g. sales

There are a number of good reasons for talking to stakeholders, as follows:

Politics

Most organisations involve some sort of tension between departments/stakeholders/teams/whatever. Giving representatives from each of these groups (make sure you don’t leave anyone out!) provides everyone with a voice. It ensures that everyone has said their piece and it’s down in writing. Ultimately, it gets buy in on the project from all parties thereby creating a better end product.

Education

This applies from both sides. The interviewer is looking to be educated regarding the various points and specialisms that the interviewee has (that’s the point of the interview!). However, the interviewer also has an opportunity to educate a whole raft of internal staff about the web. A good example would be why it’s not a good idea to name site sections after departmental structure. In fact, teaching users to think of their end users early in the interview will probably affect what they have to say.

Verification

Talking to internal stakeholders can often highlight the need to develop certain functionality/facilities/micro-sites/etc that web managers only thought might be useful. Interviews can also be used as a test bed for ideas as well as feedback.

Semi-structured

Following on form the last point, make a point of telling interviewees that they can go off track. The questions are useful as guides but don’t stop writing down what someone is saying if it doesn’t fit with the script.

So, finally on to some good questions to ask&#…;

Questions will, of course, vary depending on the organisation, end user requirements etc, but looking back through a number of scripts, these seem to crop up regularly:

What does your department do?
What are your ‘processes’?
Who is your client and what do they want?
How do you think the web can help you deliver?
What is your role?
What is the biggest pain about your job? What takes the most time?
Describe your Internet understanding/usage?
Describe your software understanding/usage?
Name applications that you are a confident user of.
Do you store any information in databases? What?
The current website – what’s good and bad about it, what’s bad about it?
Are you tasked with providing content for part of the website? If not, do you want to be?

Ask the expert: Struan Robertson on Legal Issues

Today’s guest expert on Boagworld is Struan Robertson a corporate lawyer who specializes in IT law. I first met him on the .net podcast and thought it would be great to get him on the show to give us a small taster of the kinds of legal issues encountered by web professionals. In the show he answers three questions on particular scenarios to give you a taster of the kind of issues that can arise. These include:

What are the dangers of working on websites for illegal companies
Some of the issues surrounding using images when you aren’t sure about the licensing
Storing private data

Although the particular scenarios are quite specific hopefully they communicate some underlying messages and encourage you to take your legal obligations seriously. If you are interested in learning more about the legal issues surrounding web design and IT in general then check out Outlaw.com where Struan provides a lot more advice. Also Struan writes a column in the .net magazine where he covers different legal issues each month.

Show 63: More than iPhone

Posted in Classic shows on January 16, 2007 by Paul Boag

This week on Boagworld, Paul looks at whether it is possible to build HTML emails with CSS, Marcus discusses how to write a good brief and Christian Heilmannwades into the current Javascript library debate.

Podcast: Download (21.2MB)

Download this show.

To subscribe directly within itunes click here

News and events

Seems like there is loads going on in the world of web design this week and we struggled to narrow it down to four items. However, this is our pick of the best:

Getting a job as a developer

Christian Heilmann has written a post on his experiences of hiring developers at Yahoo! He gives some really sound advice to any developers in search of employment. Definitely worth a read if you are considering a change of job.

Talking of changing jobs, if you are a developer considering a career move then you might want to take a look at the developer position currently available within Headscape.

Global free stock imagery

Luke Sanderson (an old friend of mine) has taken the Google Coop and configured it to search all of the free image stock libraries from one place. Saves a bit of trawling around looking for that perfect (free) image.

The future of flash

Now, I don’t know much about flash but I know a man who does and he has just posted his impressions of the Flashforward keynote at MacWorld. He talks about Flash CS3, flash on alternative devices and reveals some fascinating stats on the take-up of Flash 9.

iPhone

Apples announcement of the iPhone seems to have caused a lot of excitement in all quarters not least the web design community. Brian Fling believes it could “revolutionaries the web”. Personally I find myself agreeing more with Cameron Moll who takes a more cautious view.

Agony Uncle: HTML emails built using CSS

This week has seen the discovery that Outlook 2007 uses Word to render its HTML emails rather than IE7. This severely limits what is possible when it comes to HTML emails and standards. It was therefore very topical that this week’s Agony Uncle Question is about using standards with HTML email. We look at what is possible and what is not referencing articles both on the A List Apart website and Campaign Monitor.

Ask the Expert: Javascript Libraries

The debate about the value of Javascript libraries has been raging for a while now but seems to be back with vengeance at the moment. That is why on this week’s show we have Christian Heilmann sharing his thoughts on the question, “Javascript libraries: Friend or Foe?”

Review: Pro CSS Techniques

Pro CSS Techniques is a new book by Ian Lloyd, Jeff Croft and Dan Rubin aimed at experienced CSS developers looking to take their skills on to the next level. Jonathan Snook provides an excellent review on this book that we reference in this week’s show.

Clients corner: Writing a web design brief

Writing an effective brief for web design agencies will not only make the selection process easier but helps to avoid potential miscommunications over requirements further down the line. In this week’s show Marcus looks at the issue of invitations to tender and how to go about writing an effective brief that will help your project run smoothly

Oh yes… don’t forget the boagworld meetup