Tag Archives: simplicity

135. Libraries

Posted in Classic shows on by Paul Boag

In this week’s show we talk with John Resig on javaScript libraries and address the question what is more important when we release an app: speed or quality?

Play

Podcast: Download (27.5MB)

Download this show.

Launch our podcast player

News and events

The complexity tax

Don’t you hate it when somebody beats you to the punch? I recently finished writing a report for our biggest client (Wiltshire Farm Foods). It talks a lot about the need to simplify and remove complexity. It is a lesson we should all learn and so I am in the process of turning extracts from the report into a blog post which we will cover in next weeks show.

However, it would appear I have been too slow and that Gerry McGovern has beaten me to it with an excellent post on the cost of complexity. However, where I focus on why simplicity is important, he addresses the underlying causes of complexity.

For me his post is summed up in the following quote…

Most organizations are producing far too much content. Too many emails, too many PowerPoints, too many reports, too many webpages. All this content creation activity keeps a lot of people busy.

If you are part of a large organisation or work on a substantial website you need to read this post.

10 Rules for Driving Traffic Using Forums

What do you do if you have no marketing budget but have some free time to promote your site? Well, there are a number of guerilla marketing techniques you could use but contributing to forums is one of the most effective.

Sitepoint has posted an article explaining why forums are a great way of driving traffic to your site. It goes on to suggest 10 rules for doing so effectively. These include…

  • Build your profile
  • Follow the rules
  • Start by responding
  • Contribute your expertise
  • Don’t be a ‘me too’ poster
  • Don’t self promote
  • Explain yourself, but be brief
  • If you’re wrong, say so
  • Write intelligently and correctly
  • Negativity is a no-no

This is an excellent article and one that you should definitely read before using forums as a marketing tool. If you do not, you are in danger of damaging your brand, rather than driving traffic.

Accessibility in suit and tie

The life of the corporate web worker who cares about standards and accessibility can be a frustrating one; hampered by office politics and archaic content management systems. In an article on the Think Vitamin site, Bruce Lawson looks at what you can do to make sure your projects are as accessible for your users as possible.

Its a very pragmatic article, which I love. Bruce works from the premise that this is going to be tough and makes suggestions like "some accessibility is better than none". He also talks about the need for ‘buy-in from the top’ but goes on to provide practical tips about how to get that buy in. What is more, his arguments for accessibility were backed up with facts. For example…

Finally, he looks at how to get content providers onboard through education and getting them writing HTML rather than relying on the WYSIWYG editor.

UK Government Browser Guidelines

Our final story raises an interesting discussion; should you decide which browsers to support based on popularity or capability?

Apparently, the UK government believes we should test on the basis of popularity. In a draft document advising public sector websites, it suggests that if a browser appears in visitor logs as being below an arbitrary percentage of total “unique visitors”, then it should not be listed as being “fully supported”.

On the surface this appears very sensible. However, as Jon Hicks points out on his site, this can create problems. He writes…

It isn’t clear how the supported browser list would be enforced, but I’m concerned that this approach will encourage browser sniffing, a move that will exclude browsers like Omniweb, Shiira and iCab, simply because their name isn’t ‘Safari’. They share the exact same rendering engine, and therefore require no further testing. You can be more inclusive without spending any extra resources.

In other words we should be defining our list of supported browsers based on capability rather than popularity. This is the approach used by Yahoo! and it is one that I would fully support.

The Yahoo model supports all browsers through progressive enhancement and graceful degradation, without the need to test on every browser. Its a neat solution but one that the UK government guidelines specifically say they do not advocate…

These guidelines do not advocate specific development methodologies, for example graceful degradation or progressive enhancement. However, it is widely accepted that sites conforming to open web standards such as XHTML and CSS are more likely to work well across a wide range of browsers.

How come if they are widely accepted, do they not advocate them?

Fortunately there is an opportunity to change things before this is set in stone. I recommend reading the WaSP article on the recommendations and then sending some polite feedback to the powers that be.

Back to top

Interview: John Resig on javaScript Libraries

Paul:Joining me today is John Resig, who is famous for jQuery and the work that he has been doing with jQuery. John, it is great to have you on the show.

John:Well, thanks for having me.

Paul:I have to say this at the beginning. I have to get this out of the way. I absolutely love working with jQuery, and it’s an absolute pleasure. I remember twittering just a few days ago that every time I start doing anything in jQuery it makes me smile, so that’s got to be a good sign.

John:Well that’s good. I’m glad to hear it.

Paul: What I wanted to do today is get you on the show and not just for me to suck up and say how great jQuery is, but to kind of look a little bit broader at the subject of JavaScript libraries. Because I have to say from a personal point of view my opinion has changed quite a lot about JavaScript libraries and I’m kind of interested in your perspective on things as somebody that’s actually created one. I think the place I want to start is for a long time I had the attitude that you shouldn’t use JavaScript or indeed any library and that you should know the underlying code yourself and all of this kind of thing. Let’s start with the question of how do you know if it’s appropriate to use a JavaScript library? When is it appropriate to use it? What’s your opinion on that?

John:Well, I guess my opinion is it’s always appropriate, and I mean the simple fact of the matter is that there’s two things. One is that when you’re developing, you’re trying to support, generally a large number of browsers simultaneously. This is the same as if you are doing CSS development, JavaScript development, you want to support a large enough market share and you want to make that development process easy. The problem is twofold that you’re going to be encountering weird browser bugs and the APIs, the different utilities the browsers provide, will be different. For example, Internet Explorer provides different ways of handling events from all the other browsers. So what libraries do is that they remove you away from dealing with browser bugs, which is huge. And at the same time they provide a simple interface that you can interact with that will just work ubiquitously.

Paul:Is there a problem there in the sense of, you know, somebody came along and they basically learned to write jQuery for example from scratch, but never learned the kind of underlying JavaScript? Is there a problem there, do people need to know JavaScript before they start using a library?

John:It depends on the library, but I don’t think you do. I don’t think you have to know JavaScript. In a lot of ways, at least in my experience with jQuery directly there’s a lot of people who have used jQuery who have never done any programming whatsoever. jQuery does embody a lot of advanced concepts but you don’t necessarily have to know them in order to make good use of jQuery. I know this sort of translates well into some of the other libraries but one point of concern you brought up was what if someone learns a library but doesn’t learn JavaScript? I used to be more concerned about that, if someone only knew a library and I guess from a purist perspective, that’s a bad thing. Fundamentally, you want people to be getting better at programming JavaScript, not this specific thing. However, I think the reality of it is, is that so many people are just using JavaScript or CSS or doing web design, they just want to get their job done. It’s not really a matter for them of becoming an excellent JavaScript programmer or awesome CSS user, you want to get from A to Z and finish their work in an effective manner that works everywhere. So I think it’s important to realize that this market, so to speak, exists. It’s a very large one. And that ignoring it completely will just leave users frustrated and going back to the simple cut and copy paste scripts that they used to use. So, I think what libraries are doing is they are instilling good standards, they are instilling good practices, even though the users don’t necessarily know about it. And then eventually what’s good is that since these libraries have these good practices that users can always open up a library and read about it and try to understand better what’s going on.

Paul:I guess that’s always been a little bit of my concern with relying heavily on a library is that if you come across something that’s a problem or a bug or something like that, you can’t fix it yourself because you don’t necessarily know your way around the library. What’s your response to people that say stuff like that?

John:Well by the same token if you encounter a problem with a browser you are far less capable of fixing that issue. There’s really no way about it other than that ultimately it would be good to have that knowledge, absolutely. I fully support people who want to do that and I’m writing a second book now encouraging people to do that, to dig into libraries, to learn more, to build their own. What’s important here is that you just don’t, you can’t force people to do it if they, one if they don’t want to or if they’re just not capable. There’s no reason I feel to force a designer, someone who’s a designer by trade to learn the fundamentals of object oriented programming, or functional programming. Theoretically that can help them some way in the future but what’s more important to them is doing good design and I think by helping people keep their focus where it should be. Obviously if a library is able to help programmers program better, that’s good as well. It’s all about helping people keeping their focus and making sure they aren’t down a rabbit hole getting sidetracked.

Paul:I think that’s the thing that really attracted me to jQuery is as a front-end interface designer was the fact that I could pick it up and run with it very easily. The conclusion I came to is, “OK. Well if I do by some chance find a major problem with it, there’s a massive community of very clever people out there that I can ask and I can get help from.” So, that kind of reassured me, I think. If then, we’ve kind of come to terms with the fact: “OK we want to use a library.” There are so many different ones out there. Run us through some of the different options available and the pros and cons and how do you go about picking which library is right for you?

John:Well it really depends a lot. There’s a coupe questions you need to answer. Probably the most important of which is you need to ask yourself, how do you want to write JavaScript? Because libraries end up augmenting or really changing the style of how you write JavaScript. So, finding a library that you like how it looks. It sounds very superficial, but you like how it looks, you like how the code feels is a great place to start. There’s obviously a lot of libraries to choose from. There’s a select group of libraries whose quality is generally above the others and the popularity of those libraries generally reflects the quality as well. Out of those I pick generally jQuery, Prototype, Yahoo UI, dojo, then also MooTools and sometimes XJS. What’s interesting is all those libraries are open source and they are all the most popular JavaScript libraries. I don’t think that’s a coincidence. It’s just a matter of fact that in the web these open source frameworks are going to improve better and attract more users and generally have better community to surround them. So out of these libraries though you break down into a lot of different paradigms for development. I’ll try to summarize as best I can, but it really is not substitute for trying it out yourself. Looking and seeing some examples you can have a pretty good feel right away. So, Prototype and MooTools, they both extend the native objects of the language. They both try to improve the JavaScript language itself. So they add new methods to arrays, they make strings better, at the same time they provide things like object-oriented code
, and all the way out to doing things like events and AJAX. The normal things that you would expect. But at a very broad level they are trying to improve the overall quality of the language and of the experience. Then you have Dojo, Yahoo UI, and XJS and they are generally very modular, very package oriented and they have components you can easily snap in and out with nice ways of handling dependencies and it can end up being a very cleanly architected style of coding. They really support object-oriented code, and additionally events, AJAX, all the normal stuff you would expect. I would tend to group jQuery a little bit differently in that jQuery is more oriented toward improving the relationship between JavaScript and HTML and that it’s highly focused on searching through an HTML document, modifying some things, just getting in and getting out. Unobtrusive, and it doesn’t provide any language features, it doesn’t provide any object-oriented code writing features, it’s just hyper-focused at the task on hand.

Paul:It strikes me from my experience with jQuery that it’s very much a tool that’s primarily focused at helping front-end interface people implement the kind of functionality that they require from a usability point of view rather than necessarily doing, I mean would you build massive applications in something like jQuery?

John:It’s absolutely possible and people do it all the time. For example, T-Mobile’s T-Online in Germany, they built their entire user area so like their mail, their calendar, and everything using jQuery. So it’s absolutely used for very large projects. What I think is very interesting for jQuery at least is that while we don’t explicitly provide the object-oriented styles that most hardcore developers are used to we provide some very interesting alternatives especially they way it, like functional programming that I think actually end up suiting development very well. It’s very different, I will completely grant that, but it’s still very capable of scaling quite large.

Paul:So if people go out there and they have a kind of play around with these different libraries and try each of them out as you say to kind of find what fits their style of coding, once they’ve found something that kind of codes in the way they would like to, for example for me the similarities between jQuery and CSS made it a very natural fit, but what are the kind of things that you should look for from a functional perspective? What kind of things should be included in a JavaScript library? Does that make sense?

John:At the very core there should be a set of features. Of the libraries that I listed previously they all have methods for doing DOM traversal, so traversing through an HTML document, modifying an HTML document, events, so handling user interaction, animations and AJAX. All of them have some support for that to one degree or another. You can be fairly safe in knowing that if you pick a library you will have that base level. In my opinion those sets of features are probably the most important features and the ones that you end up using the most with your applications. Some people might say in their particular case that maybe animations aren’t as important, or maybe that they aren’t using AJAX, it really depends but for most of the time that set of features is fairly comprehensive. On top of that you really have to start to, once you’ve tried to use it, and once you’ve played around, there’s a whole set of secondary features that you kind of have to dig into, ones that aren’t immediately code-related. Things like the community around a library, the documentation for a library and even the health of the projects themselves.

Paul:What do you mean by that last one, the health of a project?

John:There’s a lot of things. In health, do they have an active development team? Are there developers? Are there multiple developers? It’s the famous hit by a bus; if a developer is hit by a bus will the project still continue? Is there a team will continue? Can you view the source code? Is there a repository where you can go? Is there a bug tracker where you can submit bugs? And finally is there a test suite, is what you’re going to be using going to be tested and analyzed to make sure it stays working. Another point that’s important to bring up is that a lot of browsers now are starting to integrate the test suites of these libraries into their test suite. So for example actually this is a lot of my work at Mozilla, was integrating the test suites of Prototype, Scriptaculous, jQuery, MochiKit, a bunch of libraries into our test suite such that if we ever added a change that caused a regression to happen in a library we would catch it and we would fix it on our end. Obviously we would do this in a very smart way, we wouldn’t just blindly be like, “Oh something broke!” We would communicate to the library what the issue was or whatever and this has been very big because now you can, there’s an extra level of safety and security here, in that you’ll know that if you’re using a library like this that it’s going to continue to work going forward in these browsers. That’s an extra level of safety that your personal code can’t provide. I think that’s very interesting. I want to jump back here really quick to the other issues I mentioned.

Paul:Sorry, I distracted you there and we took you off topic.

John:It’s OK, it’s OK, of community and documentation. So community, it can be usually be pretty easy to determine the health of the community. All these libraries will have some sort of a mailing list or a forum that you can go to. Just hopping on there, seeing how many messages are posted, seeing what the typical response is like, how they treat new users, just stuff like that it can be really useful because if you’re just starting out, you know you’re going to have some pretty basic questions. Do they understand your problems? Do they help you out? Doing some searches on Google for example to see how many people are talking about it, or using a service like Technorati or something. Are people blogging about it? Is it positive? Are they having problems? The other thing is documentation. This is also pretty easy to tell. If you are starting out with a library, you’re probably going to start out by doing a quick test, running a simple application just to get a feel for it. When you’re doing that you’re immediately going to be in the documentation trying to figure out how things work. I think you’ll be able to determine pretty quickly if the documentation quality meets a standard that you, because if you aren’t, if the documentation just isn’t that good, you’ll immediately have problems and I guess you will have to resort to the mailing list or the forums or whatever. Secondary is, do they have good examples? Do they have books if you want to learn from a book? Do they have books that you can buy to learn from? So again there’s a whole lot of issues here but what a lot of it boils down to is looking at the libraries, looking at their style of code, does it seem alright with you? Then just doing a quick test with each of the libraries that you’ve picked out, building like a menu or just a basic form of interaction. How easy is it? How hard is it? Does it in fact mesh with you well? This is something you can do over the course of a single day and it definitely shouldn’t take you any longer th
an that. If it’s taking longer than that then you probably want to try a different library. Ultimately you should be trying to use these libraries to make your development simpler and easier. If it doesn’t improve your productivity, if it doesn’t improve the quality of your code then you probably shouldn’t be using it to begin with.

Paul:Tell us a little bit about the kind of plug-in architectures that exists around many JavaScript libraries. Certainly I know there’s a strong plug-in architecture with jQuery. Does the same kind of thing exist with other libraries?

John:It depends. What jQuery has is a little bit unique in that we provide a number of plug-in points that plug-ins can snap into and extend how jQuery works. So they can add in new CSS selector behavior, or they can add in new events or all sorts of intricate additions. Other libraries have things that aren’t quite of the same vane, in that they’ll have modules or packages that you can use. Also another thing that varies is how do the various projects treat these plug-ins? At least with jQuery there’s a dedicated plug-in repository that’s used that plug-ins are listed in that you can browse through, you can see ratings, comments, discussions and things like that. Currently no other framework has something similar to that to the best of my knowledge. It’s much looser, just people uploading, putting things to their websites or Google code or some such. So again, at least to me, what makes plug-ins, jQuery-style plug-ins important is that they are, that there’s extension points and that they are supported by jQuery fully.

Paul: The only thing that I think that I kind of struggle with a little bit about plug-ins, you know I love the idea that there are other people out there that can do the hard work for me in that they can develop something I was looking for, and I love the fact that I can go to jQuery, I can type in whatever I’m looking for and it will pull back stuff. I’m always a bit unsure mind about how reliable those plug-ins are, you know as you’ve been saying with the kind of, the core jQuery library that you’ve created I know there’s a big team of developers working on it, I know that it’s thoroughly tested, I know what browsers it’s tested against, all of that kind of stuff. Plug-ins are a bit more of an unknown entity. Is there any kind of advice that you can provide about judging whether a plug-in or module or whatever is reliable or not?

John:I mean you sort of have to use the same standards that you would use in looking at a library. Looking at, what you mentioned, is it tested? Is there good documentation? Are there, how many developers are working on it? Like for example in the jQuery project we started a sort of, sub-project called jQuery Glide in which we’ve taken a whole bunch of plug-ins and actually blessed them and proved them, given them themes, excellent documentation, examples, all this stuff and made them sort of official. We’re doing this more and more, trying to bring in more plug-ins, improve their quality and make sure that they’re up to our standards. There’s still tons and tons of plug-ins that are just excellent, but the issue comes down to that you have to sort of train your eye to look at, and be able to spot when something has good quality. The thing that’s easiest for a plug-in author or a library author to do is to just set up a page that has their code on it and has a basic example. At the very least every single library is going to have that. If you dig in and see that it has documentation, that it has tests, you begin to realize that that plug-in is a much higher quality, at the very least. I think it’s really starting to dig in to these side issues, that you begin to get a better picture of how, of the true nature and of the true health of a particular library.

Paul:Excellent! That’s really useful and I think it’s easy to just look at these libraries and indeed the plug-ins as well and ask, “Well do they have the basic functionality that I require?” But, like you say, looking at things like the community and documentation and things like that are equally important. It’s been very useful John. Thank you for taking the time to come on the show. No doubt we will get you back in the future to talk about some of the specific things going on with jQuery and maybe this book that you’re writing as well, sounds very good. Thanks for your time.

John:Thanks for having me, Thank you.

Thanks to Todd Dietrich for transcribing this interview.

Back to top

Listeners feedback:

Quality or Quickly?

What is more important, to reach market quickly or to launch with a quality product?

I received this question from Pete in South Africa…

I have been working on a small web application, which I hope to launch soon. My problem is that I am spending ages tweaking and improving it before launch. I fear that if I spend much longer on it somebody will beat me to market. What is more important, getting the product right or launching it quickly?

It is a good question and one with no single answer. It is certainly something we have been struggling with as we prepare to launch GetSignOff.

To read the rest of this blog click here.

Back to top

Fixed Footers without JavaScript

Posted in Development on by Paul Boag

Ed Merritt (one of our very awfully clever designers at Headscape) has come up with a innovative little CSS technique I have encouraged him to share with you.

A client recently asked me if it was possible to have a page footer which would stick to the bottom of the browser window if the content didn’t fill the window, but behave normally (i.e. be pushed down by the content) when the content was tall enough.

This footer behaviour is not a new idea; I’ve seen it on a few sites over the years, the most well known probably being version 7 of Shaun Inman’s site. Take a look at the ‘Work’ page with JavaScript enabled, then disabled to see the effect in action.

I suspect that this behaviour, which can look great in the right situation, has not been widely adopted because existing solutions have always relied on JavaScript for what should be a simple presentation issue.

The technique described in this article is purely a CSS solution and works in all modern browsers, tested down to IE5.5.

Firstly, here’s a demonstration.

The HTML

<div id="container"> <div id="content"></div> <div id="footer"></div> </div>

The CSS

*, body {margin: 0; padding: 0;} #container {display: block; position: absolute; min-height: 100%;} #content {display: block; margin-bottom: 3em;} #footer {position: absolute; display: block; bottom: 0; height: 3em }

IE6 Stylesheet

body, #container {height: 100%;}

this should be referenced using a conditional comment:

<!--[if lt IE 7]> <link href="css/ie6.css" rel="stylesheet" type="text/css" media="screen"   /> <![endif]-->

How it works

As you can see, the mark-up and styling are pretty simple. Here’s a quick run-through of what’s going on…

  • #container is set to be at least as tall as the browser window using min-height and although IE6 doesn’t understand this, it treats height in exactly the same way. #container must be positioned absolutely, or this will not work.
  • #footer is positioned absolutely at the bottom of #container
  • #content is given a bottom margin equal to the height of #footer to prevent the two ever overlapping.

Known Issues

The simplicity of this technique makes it fairly reliable and the only real issues to consider are for IE6 and below. For these browsers you’ll need to specify any additional containers as also having a height of 100%.

For example, if your mark-up was:

<div id="extraContainer"> <div id="container"> <div id="content"></div> <div id="footer"></div> </div> </div>

In your IE specific CSS you’d need to specify:

body, #extraContainer, #container {height: 100%;}

Conclusion

This is a nice and easy solution to those unsightly gaps below your footers and while it won’t be appropriate for every site, it might come in handy from time to time. Please let me know if you find any problems with it.

Show 90: Digg

Posted in Classic shows on 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.

Play

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…

Back to top

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.

Back to top

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.

Back to top

Show 89: 404

Posted in Classic shows on by Paul Boag

On this week’s show: Paul talks about creating the perfect 404 page, Marcus covers some of the basics of rich media and Aral Balkan makes working with databases and APIs a whole lot easier in flash.

Download this show.

Launch our podcast player

Before we dive into today’s show I have a small request from you our loyal fans *cough*. As you may have noticed the show notes we produce for this podcast are a lot more comprehensive than once they were. They are almost a complete transcript, which is important to us because we want the show to be as accessible as possible. I have been contacted by a number of deaf users who are frustrated because they cannot access the show and to be honest I sympathize. We have done our best to produce a complete script but we are getting hung up on the expert section. I just do not have the time to go through and reproduce everything say. An alternative would be to use a service like Casting Words but to be frank I am not confident on the quality we would get back. I was therefore wondering if any of you would like to volunteer? I know a number of people have offered to transcribe in the past but quickly became overwhelmed with the amount of work involved. However, transcribing just this section of the show (typically about 10 minutes) shouldn’t be too bad. Hopefully if we can put a rota together it should be too big a job and best of all you would get to listen to the expert sections in advance :)

So, if you can spare the time drop me a line.

News and events

Writing for the web

First up this week is the fact that the latest issue of A List Apart is entirely dedicated to the subject of writing for the web. There are two great articles both of which are definitely worth reading. The first post takes the idea of personas and suggests that your website too should have a persona. What tone of voice should your website have? What character should it project? The second article (and my personal favorite of the two) is a passionate defense of good writing on the web. It fights hard against the attitude that web copy should be kept to a minimum arguing instead that if the content is web written it draws the user in and engages with them in the same way good design can.

Both articles are excellent and has made me reconsider the importance of good copy. It is an area I am constantly frustrated by and just wish I could get my clients to pay for a copywriter to really bring their sites alive.

Microformats in Google Maps

Next up is a really exciting announcement by Google. It would appear that Google Maps now supports Microformats. I can hear your cries of disappointment… thats not that exciting! Well, I think it is. This is a huge boost for the Microformats community and puts literally millions more hcards out there. Not only will this raise the awareness of Microformats but I also think it will lead to some interesting mashups using the massive database of businesses that are displayed on Google Maps.

If you are yet to play with Microformats or haven’t gotten around to adding them to your website then now is the time. They are quick and easy to implement and oh so very cool ;)

There has been a lot written about Microformats but it is nice to see big players picking it up and running with it. Good stuff.

Corporate Web Standards

What you don’t see a lot written about anymore is web standards. Its almost as if all of the arguments have been made. However, I did come across an article this week that convinced me there was more to cover. It was a discussion about implementing web standards in a large corporate environment where you are weighed down under legacy pages and internal politics.

It was a refreshing article because it was so pragmatic. Much of what you read about standards is bordering on fanatical. This article was much more down to earth accepting that you cannot implement the perfect solution especially within a large corporate environment. It talked about little steps and something being better than nothing.

If you work in a large organisation then this is definitely worth reading. You will find it very encouraging.

Web Design advice

Last up is a couple of websites I have stumbled across this last week. Both of them are provide general web design advice and I have to say both look very impressive. The first was sent to me by Charles Russell who recommended it as an alternative to “The Principles of Beautiful Web Design“. I am not sure it is an alternative personally but it is certainly an interesting website. It is called Web Design from Scratch and does exactly what it says on the tin. It literally covers every aspect of web design providing basic advice and then referring you on elsewhere. Ideal for the beginners.

The other site I wanted to mention is the Web Designers Wall which I believe has only just launched. It seems to be filled with all kinds of nice goodies including tutorials, code snippets, commentary, inspiration and more. What is more the site design is beautiful. I have a feeling that this site is only going to improve with age.

Marcus’ bit: Rich media

Multimedia doesn’t really mean that much anymore I think. It used to refer to CD-Rom type content but now I think it refers to any web content that isn’t just plain old text and images.

I have been pricing up some new/interesting/dynamic content for one of our clients and it struck me that I haven’t discussed this sort of thing here before. I guess there isn’t a great deal of point to this other than ‘have you thought of doing…’, so here goes…

Animated shortcut banners

These seem to be all the rage at the moment. Usually quite a large portion of the homepage is dedicated to a rolling carousel of messages or adverts for content deeper in a site. There will usually be 3 or 4 different ads that flow from one to another. Manual controls are also available to go straight to a particular shortcut or pause on an ad.

There’s a good example at Wildfowl and Wetlands Trust.

Video

I don’t really mean just plain video; I’m referring to a piece we did for the Surrey Hills AONB that incorporated:

  • Still shots
  • Video footage
  • Voiceover

All of which were pulled together to create a tourism video that can be downloaded at Surrey Hills.

The voiceover, incidentally, was done by Surrey Hills patron and famous british actress, Penelope Keith. Going to her rather grand house to record the session was a great experience.

Voiceover

Which brings me nicely on the subject of voiceover. I have two rules relating to voiceover recording:

ALWAYS use a professional actor. The girl in the office with the ‘nice’ voice will sound rubbish, so will the ‘posh’ guy in accounts (we know, we’ve done it!). Voiceover actors aren’t that expensive and, because they’re professional they’re quick. I have used Voicebookers in the past and they have been superb.

Less important but… use a proper voiceover recording studio. I have used studios in London that are really very reasonable and the quality is superb. Though of course this isn’t always possible as with Penelope Keith (recorded my laptop).

Panoramic imagery

We have done a few external 360 degree images, again for Surrey Hills and some for National Trails. We haven’t used dedicated equipment that take full spherical shots basically because you end up with an unnecessary amount of sky. I have simply used a decent camera and tripod and done two full sweeps of portrait images (roughly one just below the horizon, the other just above), moving the camera about 10 degrees each time.

The ‘fun’ part with these images is that they are usually taken from high vantage points so expect to have to do a lot of climbing to out of the way places!

There is a compromise to be made with panoramics. The best time to take a good landscape photo is early in the morning or just before sunset. However, for a panoramic that doesn’t work because you will have the sun in view for a large chunk of the image. This is one of the reasons why panoramic images can often look a little ‘flat’.

Dynamic screensaver

This is quite a cool idea where the standard screensaver idea (pretty pictures rolling from one to the next) is enhanced to allow the client to update information to it. Basically, when the screensaver fires up (as long as it connected to the internet) it checks with the client’s site to see if any changes have been made and automatically updates if there has. This is really handy for news stories but could be used for anything.

Mapping

I think I have discussed mapping previously because it is something Headscape has done a lot of in the past. Up until recently we tended to develop maps using Flash where points of interest are dynamically generated using grid references. We also added features such as layering of different categories.

However, recently we have developed a site for River Thames that utilises Google Maps. The site’s main purpose is to promote the River and encourage people to visit. Again, we have used Google Maps to show points of interest such as places to eat, places to stay etc that are controllable in layers. Using GM is very cool though because the points shown alter when the maps are dragged and/or zoomed (apparently lots of brain power went into making this work!).

Finally, we also created a trip planner or itinerary builder that gives site users the opportunity to list all the places they want to visit (inc. contact details, address, directions etc) and print this off in a print friendly design or email to a friend.

Paul’s corner: Handling missing pages

I noticed this last week that I have been getting a lot of traffic from the Smashing Magazine and so I went to check out where it was coming from. Turns out it was an article on 404 error pages and they had used my error page as an example. The article also referenced another site called the 404 Research Lab that provides lots of good information on setting up custom error pages. All of this reminded me I wrote a blog post ages ago about handling missing pages and yet for some reason i have never spoken about it on the show before. Seems strange because it is a subject we all need to deal with. So, I thought it was time I covered the subject properly using my old blog post as the basis.

Review: Aral Balkan on SWX

Paul Boag: OK, so joining me today is Aral Balkan. Hello! How are you?

Aral Balkan: I’m fine, Paul. How are you doing?

Paul: Not too bad. I feel like I’m speaking to you quite a lot recently, one way or the other.

Aral: [laughs] I know, but it’s fun, huh?

Paul: So I was explaining to everybody earlier in the show how we got you into Headscape to give us a little bit of training and kind of bring us up to speed with what was going on with Flash.

Aral: Yeah, that was a lot of fun, too.

Paul: You had a good day, did you? It wasn’t too painful then.

Aral: Yeah. Me and my bunny had a good day. [laughs]

Paul: Yeah, that was deeply disturbing, on so many levels.

Aral: [laughs]

Paul: But I think we’ll just leave it at that. We won’t tell people any more details on that. We’ll just leave them worrying about it. [laughs]

Aral: OK, let’s do that. [laughs]

Paul: So, as part of that day, you mentioned SWX, which is something that you’ve been involved in developing. And it sounded so cool and kind of dragged my attention back when there were points where I was thinking that this is beginning to get a bit out of depth to me.

Aral: [laughs]

Paul: There were techie people in the room that understood what was going on.

Aral: Yeah.

Paul: But then you started talking about SWX, and I started to think, “Ooh, that sounds cool” so I thought I’d get you on the show and ask you a little bit about it.

Aral: That’s great. That’s great, because SWX is what I’m most excited about these days.

Paul: Good stuff. So, do you want to kick us off by telling us a little bit about what SWX is?

Aral: Well, SWX is a couple of things. SWX itself is a new data format for Flash. It’s actually the native data format for Flash, which is kind of weird, because Flash has been around for a while, so why hasn’t it had a native data format until this point? I don’t know. Nobody else did it, so at the end; I was like, “OK. Well, I guess I have to bite the bullet here.”

And when I say native data format, if you’re not very fluent with Flash, think about JSON, or what JSON is for JavaScript. But it’s actually a step beyond that, because, with JSON, you still either have to parse it, or in JavaScript you have to evaluate it, before you can use it. So there’s another step before you can use it, after the data’s loaded.

In SWX, there isn’t. It uses SWF files, which are native Flash files, to store data, so it makes it very easy to work with.

Paul: What’s the kind of target audience for this? Who do you see as using it?

Aral: There are a couple. So, anyone right now who’s working with Flash basically can use this to build mash-ups, to build data-driven Flash applications. And also, mobile developers who are developing with Flash Lite can use SWX to develop mobile Flash applications.

And in fact, that’s where it’s currently, I think, most useful, because with SWX RPC–which is the remote procedure call, the gateway for it–you can make remote procedure calls, so call back-end services and methods, through SWX. And it’s the only RPC solution, really, because Flash Remoting doesn’t work on Flash mobile, on Flash Lite, so it’s the only RPC solution for mobile right now.

Paul: I think what kind of struck me about it was the fact that there are a lot of people out there that maybe have been doing some superficial stuff with Flash…

Aral: Yeah.

Paul: And have been doing some ActionScript and things like that.

Aral: Right.

Paul: But when it gets to things like making data calls, it all seems to get horribly complicated, all of a sudden.

Aral: It does. It gets very hairy, and I don’t know why. I think part of it is because the back-end, the server side, of applications has traditionally been the realm of traditional programmers: the brainiacs, the people who are very comfortable talking in code, thinking in code.

And they’re not always the best people, I find, to simplify concepts, because they’re so intelligent, they can understand all of this, or they have such a focus on this that they don’t mind spending hours trying to set something up. Sometimes, they’re not always the best people to create simpler systems for mere mortals like the rest of us.

Paul: [laughs]

Aral: So that was my main motivation behind it, because I think Flash is great for building mash-ups and data-driven applications. But we don’t get as much experimentation in Flash with that, and I think it’s because it’s too hard. The barrier of entry is too high. You have to jump through so many hoops to get even something basic working, whereas it should just be, off the bat, you should be able to get started with things. And that’s been my focus with SWX.

So, for example, on the Mac, there’s a bundle that you can download that gives you everything you need to start using SWX, with a one-click installer, a disk image.

Paul: Cool.

Aral: My focus, really, with SWX is on simplicity. And when I say simplicity, I mean for the whole process, from the moment you go on the website and download SWX, to the moment you can get up and running. I’m trying to make that whole process as easy as possible, basically.

Paul: From what you showed me when you came into Headscape…

Aral: Yeah.

Paul: Basically, within a few minutes, you can kind of download this bundle onto my Mac. I can run an install file, which sets everything up for me.

Aral: Yeah.

Paul: And you’ve even set up…

Aral: Well, you basically get a development server for free.

Paul: Yeah.

Aral: It uses the MAMP Bundle, which is a great bundle that has Apache, PHP, MySQL. So if you’ve ever been afraid to work with these things, that’s also a way to get started, because there they are on your machine, running, without any configuration or anything on your part.

Paul: And you have also included some kind of interfaces to common APIs, things like Flickr and Twitter and stuff.

Aral: Yes, and in fact, if you remember the installation process and everything that you were talking about, you don’t even have to download and install SWX to start working with the pre-existing APIs that come with it, because I host an instance of the SWX gateway on swxformat.org. It’s the public SWX gateway that you can just hit directly from your Flash applications.

Paul: Ah!

Aral: So if you don’t want to mess with the back-end, but say you want to build a mash-up that uses Flickr or Twitter, currently two of the main APIs that I have on there, you don’t even have to download SWX. You can just open up Flash, write four or five lines of code, and get, for example, the list of your latest photos from Flickr.

Paul: Cool.

Aral: Or your friends’ photos. With nothing else. So you don’t even have to download anything to start working with SWX, because it is native. What you’re getting from the back-end, from that SWX gateway, is a SWF, and Flash knows how to deal with that, and the data in there is a native Flash object and ready for you to use the moment it loads.

Paul: So, how does somebody get started on this? Where do they go? What do they have to do? Especially, you made it sound very simple for the Mac. Is it horribly complicated if you’re a Windows user?

Aral: Oh, not at all, not at all. Like I said, regardless or what platform you’re on, unless you want to build your own server-side services, if you want to use the APIs that it comes with, you don’t even have to download it, actually.

Paul: Oh, OK.

Aral: In fact, just last week, I got moo cards printed. And these little moo cards have all the code you need on the back of them, because there’s only about four lines of text you can put on the back.

Paul: [laughs]

Aral: But they have all the code you need to get the latest public timeline updates from Twitter. So it’s actually, seriously, four lines of code, and it fits on a moo card.

Paul: Wow!

Aral: So, to get started, you don’t have to do anything, really, apart from open up Flash, write four lines of code, and see it run and get the feeling that, “Wow, maybe I can build data-driven applications in Flash, too, because this is simple.”

The next step would be to download SWX onto your own machine. If you have a development server already, if you have a web server with PHP, then you just download the ZIP file, unzip it into your web root, and hit that location in the browser, and the start page comes up and guides you through the rest of it.

Paul: Cool.

Aral: If you’re on a Mac, get the MAMP Bundle, and that’ll get you started even faster. But, like I said, you don’t even need to download anything to start playing with it.

Paul: So these four lines of code to get you going…

Aral: Yeah.

Paul: If they don’t have one of your precious mood cards, where can they go to learn those kind of basics?

Aral: Well, on swxformat.org, there is a screencast right now. It runs you through the MAMP Bundle, but the concepts are exactly the same for all of the rest.

Paul: OK.

Aral: Although, I am going to record a few more screencasts. I’ve started putting them up on Viddler, which is actually really cool. I don’t know if you’re used it.

Paul: Yeah, I have.

Aral: But it’s really great for screencasts, because it keeps the original resolution of your movie. So I’m going to record quite a few more and put them up there, including one that will just get you started, like the moo card does.

Paul: Cool.

Aral: So, look on swxformat.org. And also, look on my blog, because I blog about SWX quite often there: it is aralbalkan.com.

Paul: So as I understand it, at the moment, this is all built on PHP and MySQL. Is that going to change? Are we going to see other platforms supporting this, too?

Aral: Well, basically, the SWX format itself is a data format, so it’s platform-agnostic, in terms of the back-end, etcetera. So if you have a SWX SWF, you’ll be able to load that. Even if it’s offline, if you have if on your hard drive, you’ll be able to load it into Flash and get the data off of it.

Paul: Excellent.

Aral: And then there’s SWX RPC, which is an implementation of a gateway, basically, or an endpoint, that serves SWX SWFs. And the current implementation of that is only in PHP.

Paul: Right.

Aral: So, it will be ported later on. It’s currently in beta. And once we get closer to the release date and certain things are standardized, I’m going to be concentrating on orchestrating the ports. There’s a lot of interest from quite a few people to port it to Ruby, to J2EE, to.NET.

Paul: Excellent.

Aral: And my focus right now is on getting SWX to a level where it’s somewhat of a standard–not like an Internet standard, but at least, within itself, we know what we’re talking about when we say a SWX SWF so that, if it’s being generated from Ruby, it’s the same thing…

Paul: Yeah.

Aral: So there’s no fragmentation. That’s my focus right now. In fact, I’m writing my first RFC…

Paul: [laughs]

Aral: For the SWX formats, just so things are a bit more standardized, before we go porting it to every possible technology.

Paul: Excellent! That just sounds really exciting…

Aral: I’m really excited about it!

Paul: Yeah, I bet you are.

Aral: This has gotten me excited and working with technology again, at a level that I hadn’t been in the past. It’s fun. Because this stuff, the data exchange between tiers, it’s really not rocket science, and it shouldn’t be rocket science. We’re just moving stuff from one place to another. And my philosophy is: make that as simple as possible for people so they can concentrate on the really fun bits…

Paul: Yeah.

Aral: Building the user interface, building a great user experience. Because those are the hardest bits, really, conceptually, and they’re also the most fun.

Paul: Yeah. That’s great stuff, and I wish you all the best with it in the future. And thanks for coming on the show and telling us a little bit about it.

Aral: Thanks so much, Paul, for having me. It was a lot of fun.

Paul: Yeah. OK. Good to talk to you, and we’ll speak to you again soon.

Aral: OK, take care of yourself.

When developers design

Posted in Design on by Paul Boag

Although I cannot make you an expert designer, I can offer some advice of how to avoid the major pitfalls I sometimes see developers fall into.

In an ideal world designers design and developers develop. However, we don’t live in an ideal world and from time to time we have to swap roles. The problem is that there is a lot of tutorials and articles showing designers how to develop but little showing developers how to design. I therefore thought I would share some very basic tips.

First things first, I am not going to be able to teach you good design practice in a single post. That comes with time, training and to some degree, talent :)

However, although I cannot make you an expert designer, I can offer some advice of how to avoid the major pitfalls I sometimes see developers fall into.

General comments

Before I plunge head first into specific tips I would like to share some more general comments based on my observations of when developers do design. Hopefully these will help you think of design as more than arranging pixels.

Empathy

In many ways developers work in a world of absolutes. A piece of code either works or it doesn’t. Your world tends to be very literal, very straightforward. Computers are in many ways easy to understand. People on the other hand are a very different matter. We are messing beings full of contradictions and inconsistencies. This is the world of the designer.

Designers are trying to engage with people and to do that they empathize. They try and put themselves in the shoes of the user, to really understand how they think, how they approach a problem.

One of the most common mistakes I see developers make is that they fail to do this. To a lesser or greater extent they perceive the user as being similar to themselves. They make assumptions about the users motivations and abilities. They often misunderstand what the user is trying to achieve.

If I could give only one piece of advice it would be to encourage you to empathize. Really think through what the user is like. Are they in a hurry? Do they have a specific aim? What is their outlook on life? Will they have kids clamoring for their attention while they surf your site?

Really try to get inside their heads. It will definitely help.

Avoid graphical applications

The temptation is to think “I have to do some design, that means I need to open Photoshop. That is what designers use”. Of course that is entirely true, designers do use graphic applications like Photoshop or Freehand. However, I would suggest that unless you are already familiar with these kinds of applications, you are just adding more complexity to the problem.

Its hard enough to apply the principles of good design without adding learning a new application on top of it.

You know code, so work with code. Build your site using CSS and XHTML and these are the tools with which you are familiar. Sure, it wont lead to outstanding design, but that is not the aim as I discuss next…

Don’t try and be great; be invisible

Don’t try and produce a “creative” or “innovative” piece of design. Designers find this hard enough to do. The danger is that if you try and do this, you will create something that some people may love, but the majority completely hate.

Instead, play safe. Try and make your design invisible. A good solid piece of design will not impress but neither will it offend. The idea is that the users will not even notice it, they just use it.

If the user doesn’t acknowledge what you have produced it means it hasn’t caused them any problems and that is a good thing. Sure, you wont win any design awards but that isn’t very likely anyway!

Specific advice

Okay, so enough with the airy fairy advice, lets get specific. How do you make your design good enough to be invisible, non-offensive? Well, let me suggest 5 areas that you should pay particular attention to. Obviously I could write reams on each but lets keep this very simply and easy to implement.

Typography

The key to good typography is constraint and consistency.

Avoid using too many typefaces, normally 1 or 2 is enough. Also avoid having too many variations in sizes and weighting. Only use size and weighting to emphasis the hierarchy of the content. The larger and bolder the type, the more important the content.

Also try to be consistent in your application of typography. If something is a certain size and weight on one page ensure it is done the same on another. Although CSS makes this relatively easy, watch out if you are working with ems as you may have inheritance problems.

Finally, don’t just think about the type itself but also line length and line height. Don’t allow lines of text to become too long (between 40 – 60 characters is good) because they are hard to read. Also add some whitespace between lines of text as it will make the page feel more spacious, which brings us nicely onto…

Whitespace

Whitespace is the not-so-secret weapon of good design. For simplicity sake, I think the rule of thumb is to add more whitespace than you are naturally inclined to do. Whitespace improves legibility, gives a sense of simplicity and communicates a feeling of openness and style.

In order to limit scrolling, we feel the need to cram as much content in as possible so squeezing out whitespace. Resist this temptation. Be generous in your padding, margins and line height. Don’t be afraid of “empty” parts of the screen.

The grid system

You often hear people complain that a website looks boxy but in actual fact boxes are good. A good website should have a strong underlying structure of columns and rows. It helps the user identify hierarchy and communicates a sense of order in the site. Although a good designer will break out from the grid he will always have a grid structure still there underneath.

Think about how many columns the site is going to have. Ensure these are applied consistently across the whole site, but don’t be afraid to occasionally span across multiple columns. Also ensure elements are placed consistently in this grid from page to page. Do not move elements around, especially navigational elements like the menu bar and search.

A grid may seem restrictive and not very “creative” but it essential to all design.

Colour

Working with colour is particularly tricky and so I would suggest where possible you avoid making too many colour choices. Your best bet is to turn to an automated colour creator like Kuler. You can either choose from one of the existing palettes or enter a base colour (usually a corporate colour) and it will produce a palette based on that.

Notice that Kuler only includes 5 colours in its palette. This is good practice, resist the temptation to use too many colours. Apart from this site (where I was just being silly), I tend to use a very limited colour palette. One nice little trick however is to use a strong contrasting colour to highlight important content. Because it is a contrasting colour it will make content stand out from the rest of the site.

Imagery

The design work I have seen done by developers tends to shy away from the use of imagery and in someways that is not a bad thing. It is easy to get imagery wrong but I would encourage you to be a little more adventurous. Imagery is a great way to draw the users eye and so can be used to highlight key content.

Selecting imagery can be tricky but here are a few suggestions that will point you in the right direction…

  • Avoid animation.
  • Choice images with a strong foreground element.
  • Compress your imagery but not too much!
  • Use faces, people are naturally drawn to them.
  • Avoid clipart illustrations

I am sure there is more I could suggest but those are the ones that immediately spring to mind.

Taking it further

So there you go. Hopefully that has helped a little. Obviously, there is so much more that could be said, but that should have at least started you off. If you do want to take the next step and improve your design skill then check out Jason Beaird’s book “The Principles of Beautiful Web Design”.

The importance of Undo

Posted in User experience on by Paul Boag

An easily available undo function creates a sense of simplicity because it instills in the user the attitude of “what the heck, I can always undo it”.

Many internet users lack confidence when interacting with the web. It is our job as web designers to try and reassure them and provide a safety net when things go wrong. Providing various methods by which users can undo actions is a useful crutch to the less confident user.

Benefits of undo

Undo functionality seems to be in increasingly short supply on the more recent raft of web 2.0. websites, especially on sites that make heavy use of AJAX. This is a sad day for web design as the ability to undo provides three crucial benefits:

Alleviate apprehension

I have said this many times but it always bears repeating; the majority of people do not like computers. It is so easy for us to forget that, as we live and breath computers everyday. I have to confess that I am more comfortable working with a computer than the real world. After all, how many times have you tried to CTRL Z reality!

However, although we are comfortable with computers the majority of people aren’t. They are intimidating, impersonal and far from intuitive. This is not only true for the PC but also for the web. After all who would design a system where the interface changes when you move between sections (sites).

The ability to undo, go back or escape is a lifeline to many users. It is immensely reassuring to know that you can always undo something if you get it wrong and when that option is not available it can be incredibly disturbing. Take for example the first time you ever bought something online. Do you remember a feeling of apprehension when you realized that the next click would place the order and that there was then no going back.

A way to overcome complexity

I am a huge fan of simplicity, largely because I recently finished reading “The Laws of Simplicity” by J Maeda. In his book he talks about the fact that the ability to undo creates an impression of simplicity even in the most complex applications.

An easily available undo function creates a sense of simplicity because it instills in the user the attitude of “what the heck, I can always undo it”. Once the user has that attitude they perceive things as simpler than they actually are.

A method to build confidence

The “what the heck” attitude is largely about confidence. A confidence in the power of undo to do its magic, is what allows us to play and experiment with an application. Through experimentation and play we learn and with knowledge comes a confidence in our own abilities. That is the power of undo.

Opportunities to provide undo

Now that I have established the importance of undo the next step is to look at what options are available to us as web designers to provide undo to our users. I have come up with four ways this is possible, however the sad reality is that we continually undermine these different methods in the way we code and design.

Back Button

I must have sat through hundreds of usability sessions over the last decade and I do not recall one where the user did not use the back button at some point. The back button is the primary life line used by most people to correct problems and yet in more and more sites it does not work. The problem lies in the use of AJAX and Flash which break the page metaphor on which all browsers are built. The same problem occurred with frames and was one of the major reasons that the use of frames died out.

Although there are fixes for this problem in both flash and AJAX, they are far from perfect and rarely implemented. Serious attention needs to be given to this problem when developing modern web applications as a failure to do so not only undermine usability but damages user confidence.

Breadcrumbs

There was a time when users didn’t really understand breadcrumbs. However as has been suggested recently by Jakob Nielsen, that is no longer the case.

Although breadcrumbs should never be seen as a replacement for the back button, they do work as a handy alternative for more experienced users. What is more, although they have traditionally been used on page based websites they can also translate well onto web applications.

Favorites

In usability sessions I have also occasionally seen favorites and bookmarks used as an undo tool to go back to a previous page. However as with the back button this functionality is often broken in modern web applications that update sections of pages instead of the entire page. Favorites provide the valuable ability for the user to quickly return to marked “safe points” in their surfing and as a result we should be doing our upmost to ensure that this ability remains.

Home

Almost all websites have a link back to the home page, however not all of them make that link very obvious. A common practice is to make the logo a link back and although in itself this technique is fine, it is not obvious this link exists and so many users are not aware of it.

Having a link back to the home page is a great way of letting the user “start again” but if you are going to provide that functionality it needs to be obvious.

So there you have it; why undo is important and some techniques to undo easier on your website. Hope it helps.

Show 81: Money Matters

Posted in Classic shows on by Paul Boag

This week on Boagworld: Paul gives advice to those who work with content management systems. Marcus finally talks about charge out rates and we talk to Dan Mall and Mark Huot about swfIR.

Download this show.

Launch our podcast player

News and events

37signals in Time Magazine

I notice that 37signals have made it to Time Magazine. This is exciting stuff because it shows the growing awareness in mainstream media of the explosion of web 2.0 businesses. However, the real reason I mention this article is because of what it tells us about how 37signals work. You get to learn about their focus on simplicity, the fact that innovation can happen outside of Silicon valley and their approach to a distributed company.

The one part of the article I personally found particularly interesting is how 37signals’ current suite of products was born out of a need they had to communicate across a distributed company. The idea of building a product that meet a personal need is a good one. It is particularly interesting to me as Headscape has started development of a product which does exactly that. I don’t want to say much more at the moment (as it might never happen), but this article contained a lot of valuable lessons for us.

AJAX tools

I seem to find myself doing more and more ajax and javascript these days. One of the more tricky areas is keeping the user informed about what is going on. I am encountering two specific problems:

  • How to draw the users attention to content that has changed
  • How to inform the user that content is still loading

The latter is fairly straightforward as you simply display a loading graphic. However, I am a lazy sod and can’t be bothered to hand craft a beautiful animated gif. Fortunately this week I came across AJAXload which generates those pretty web 2.0. loading graphics for you. Very nice.

Informing users of changing content is a bit more tricky. I have been aware of the fade to yellow technique for a while but that requires a white background, which my designs don’t ways have. What I didn’t know until I finished Jeremy Keith’s “Bulletproof Ajax” is that there is also a fade to anything technique. This is basically the same as the fade to yellow approach but the background colour doesn’t matter. Simply download the code and away you go :)

Waves of creativity

I stumbled across an article this week talking about the relationship between brain waves and creativity. This explained a lot about my own personal creativity! The gist of the article is that your brain needs to be relaxed in order to be at its most creative. This makes sense for me personally as inevitably I am at my most creative when I am lying in my bed at night.

The sad truth is that we spend most of our lives in a more agitated state and so creativity is hard to achieve. This dove tales nicely with my experience of implementing “Getting Things Done: The Art of Stress-free Productivity” (David Allen). Since reading that book I have felt much more relaxed and in control and hence I have been considerably more creative.

Eric Meyer explain why forms controls can’t be styled

A big thanks to Eric Meyer who has been kind enough to look into the incredibly confusing area of form controls and then explained it to the rest of us. Many web designers express a real frustration with the fact that you cannot consistently style form elements. Although personally I think it is generally unwise from a usability perspective to start mucking around with form elements, I have still always wondered why browser developers have chosen to give us so little control. In a recent post Eric goes into extensive detail about why form controls are “weird” but the upshot is that you are simply better off not styling them.

Agony uncle: Web Design rates

Another question from Bob in Iceland:

“Hi guys, I am becoming increasingly bewildered with what I should charge for web design work. I also do a fair amount of copywriting and content research. What should I charge? Should my rates change for different work? I am a one man band.”

Firstly, I should say that there is no real fixed figure for web design related work. It depends very much on a number of factors, such as:

  • Experience e.g. proven capability to deliver
  • Ability to deliver specialist services e.g. usability testing
  • Size
  • Diversity of staff
  • Location
  • Portfolio

However, to use a real example as a baseline, a survey carried out by eConsultancy a couple of years ago showed that English web design agencies employing 10 to 20 people with a turnover of approximately £1M, charged between £500 and £800 per day for most services. I expect this gone up a little since then.

Setting your rates is partly science, partly weighing up what the market will bear for what you offer.

You do need to work out to the best of your ability what your daily break even cost is but in, in theory, your annual figures should be able to tell you that. The biggest drain on any web agency, unless you have marble and gold clad offices in central London, will be your staff. Good creative/technical people don’t come cheap.

Be realistic from a number of different angles:

  • Don’t try and charge a grand a day if you’re straight out of uni with no experience under your belt
  • Don’t expect to have 100% effort allocation – 70% is excellent
  • Price projects as honestly as you can but remember that clients are human beings and really don’t like paying for project manager anywhere near as much as they do technical development

So should you charge different rates for different services. Again… it depends. Some jobs require a lower level of skill as part of the project. For example, recruitment (though an absolute pain) for any type of testing requires basic organisational skills and not,say, years of experience in project management. If you can outsource that work at a lower rate, then charge a lower rate, but if your PM ends up doing it then you have to charge at your PM rate.

For years we charged a flat rate across the board because it was simpler to manage and we felt clients liked it. Over the past couple of years we have done a lot more consultative work that has placed pressure on the timetables of the directors. This has led us to having the following rate categories:

  • Creative director – Paul
  • Consultancy – IA, business analysis, testing etc
  • Standard – design, technical, pm

We charge a fixed uplift (per client dependent on geographic location) for on site work – kick off meetings, testing etc.

Client corner: Advice for CMS users

I have been putting together a document for work that provides some basic advice for people who work with content management systems. It covers things like accessibility and writing for the web so I thought there might be some value in sharing it on the show. For complete notes on everything I cover check out the CMS user blog post.

Ask the expert: Dan Mall and Mark Huot on SWF image replacement

I was fortunate enough to get some time to chat with Dan Mall and Mark Huot the creators of SWF image replacement. We talked about:

  • What exactly swfIR is and how it works
  • What kind of scenarios they imagine it being used in
  • What inspired them to create swfIR in the first place
  • A little bit about the process of applying it to a site
  • What the future holds for swfIR
  • What it is like working at Happy Cog

No show next week

Just a quick note to say there will be no show next week as I am off on holiday to sunny cornwall. However, please continue to send in your suggestions for the show and don’t forget you can always check out the forums if you want your boagworld fix :)

Keeping your home page clean

Posted in Design, User experience on by Paul Boag

In the fight for real estate, usability and design aesthetics are often the first causalities.

One of the most common sticking points I encounter when developing a website is the sign off of the home page. Client’s want to cram it with as much content as possible, while the designer is seeking to maintain the integrity of the design. So, what is the best way of avoiding this kind of confrontation?

I am sure you have come across requests like this before…

I need the logo bigger, more space for news, events and features, shortcuts to key applications, more prominent navigation and can you make the search stand out. Oh yes, and I don’t want the page to scroll at 800 by 600. Also, sales would like to add banner advertising across the top and down the side.

In many cases these absurd scenarios occur because of a perception that the home page is the most valuable location on a website. As a result all the various departments clammer to get their piece of the limelight.

In the fight for real estate, usability and design aesthetics are often the first causalities. Below I outline four techniques I am starting to use in order to bring some sanity back to the home page scramble.

Recognizing the changing role of the home page

One of the first steps to home page utopia is to get the stakeholders (those who are fighting for home page prominence) to recognise that the home page doesn’t have the importance that it once did. In fact I think it would be fair to say that we are going to see a continued decline in the traffic going to home pages over the coming years.

Jakob Nielsen in his book “Prioritizing Web Usability” talks about a change he is seeing in the way users are interacting with the web.

There was a time, says Nielsen, when users who had a specific task would go to a site where they thought that tasks could be completed. For example, if they wanted information on the Crisis in Darfur they would go directly to CNN or the BBC. However, more and more it would appear that instead of turning to a specific site and finding content via that sites home page, they are instead looking to search engines. The search engine takes the user directly to the information they require thereby completely bypassing the sites home page. Obviously, this deep linking seriously reduces the prominence of the home page.

Add to this the rise of RSS feeds and more people accessing information via mobile devices, and you begin to see the focus shifting from the website home page towards the individual pages of content. That is not to say home pages are no longer important, they are simply not as important as once they were and so do not justify the level of competition they receive in some organisations.

Don’t rush into the home page

Another technique I am starting to use more often is to avoid addressing the home page too early in the process. By starting with standard textual pages (which after all make up the majority of the site) you get to set the design style before it gets diluted by the land grab for home page real estate. Once the client has “bought in” to the design they will perceive it as being more important and so are less likely to allow it to be railroaded by content demands.

However, delaying the home page development isn’t just a “political” move. It is also the right thing to do. A home page should reflect the sites content at the highest level and signpost the user to key content deeper in the site. In the majority of projects I work on the client hasn’t finalized all of the content in the initial design stage. In my opinion it is hard to create an effective home page until you have a full understanding of what content it is meant to signpost and represent.

Communicating the importance of white space

In the case of home page design the heart of the conflict between designer and client is often a perception of the importance of white space. Every designer knows that white space is a fundamental tool of good design, but we are often bad at expressing why in a way the client can associate with.

This is an area I have been thinking about a lot recently and I have come up with a possible solution which I am yet to try. It was inspired by the book “The Laws of Simplicity (Simplicity: Design, Technology, Business, Life)” which I am currently in the process of reading. On the subject of white space the author says:

“The opportunity lost by increasing the amount of blank space is gained back with enhanced attention on what remains.”

Or in other words; the more you add the less importance anything has.

I think this is where we sometimes go wrong as designers. We sell white space on the basis that it looks better. Instead we should be selling it on the basis that every item you add to the page detracts from the rest.

To help the client think this through I am wondering whether a point system of some kind might help. You might want to suggest that a user has 10 points worth of attention they can give to the home page. Every “module of content” added to the home page takes a minimum of 1 point. More points should be assigned to more important elements. This approach will quickly show that the more you add to a page, the more likely important elements are going to get lost in the crowd.

I am not sure whether the approach would work in practice or not, but it does strike me as a good way to focus the clients mind on what is important.

Embrace rather than fearing the fold

The killer blow to any home page design is when the client says: oh yes, and we want all of that to fit above the fold. This inevitably leads to smaller typefaces and less white space.

I think we need to work hard as designers to dispel the myth that users never scroll. Sure, users don’t always scroll but that is okay as long as we put less important elements further down the page.

The idea that users don’t scroll is horribly out of date and probably comes from the very early writings of Jakob Nielsen. However as early as 1997 he was suggesting that users were becoming more comfortable with the idea.

If your client needs further proof then install Crazy Egg or some other heat map service on the clients site. This will actually show where on the page a user chooses to click. You will see a decline lower on the page but not enough to justify putting everything above the fold.

The emphasis should be prioritizing content rather than cramming everything into the small space above this ill defined line that we call the fold.

But how?

Of course the fundamental problem with educating our clients, is that in many cases you cannot talk to the people that are demanding home page space. This is a very real problem and in many cases there is little you can do to overcome it. However I was impressed by Shane Diffily’s idea of running stakeholder workshops in his recent A List Apart article. Having a workshop at the beginning of a project where you can talk about good practice and dispel some of these common myths is a superb idea and should help a lot of projects run that much smoother.

Show 79: Despise the listener

Posted in Classic shows on by Paul Boag

A great line up this week with Paul, Marcus and Andy Clarke.

Play

Podcast: Download (21.4MB)

We have a great lineup this week: Paul talks about getting things done in web design and an alternative approach to your reading list. Marcus explains the exciting area of insurance for web designers and we have Andy Clarke on the show to give us an update on CSS 3.

Download this show.

Launch our podcast player

News and events

Google Analytics gets interface upgrade

Like so many who join Google, Jeff Veen has been forced to be somewhat tight lipped about what he has been working on. However in the last week we have finally been able to see the fruits of his labors with the relaunch of a new and improved Google Analytics. You would be forgiven for thinking that a load of new functionality has been added to the service. In fact that is not the case. The only changes have been to the user interface. The difference is that you can now find everything quickly and easily.

If like me you found the old Analytics service confusing and difficult to use then you might want to take a look at the new revised version. It is a definite improvement.

Great new articles on A List Apart

For a while I have been a little disappointed with the articles coming out of A List Apart. Perhaps they were simply too “high brow” for the likes of me but they lacked any practical application. However this issue is different. It has two great articles about handling clients.

The first entitled “Stand and Deliver” provides some superb advice on presenting your designs to a client. The second called “Educate Your Stakeholders!” talks (unsurprisingly) about educating the decision makers in a web project so they make more informed choices.

Both are really superb articles and I would definitely recommend you check them out.

Teaching the traditional web

We are all acutely aware that the web is changing at a rapid rate. At the moment the focus is very much on web applications however we cannot afford to ignore the massive number of page based sites that still need to adapt to the changing way people are interacting online. In a post called Teaching the traditional web, Keith Robinson discusses how we need to alter our approach to page based websites based on deep linking, RSS feeds and mobile access. A very enlightening read.

Baselines and vertical rhythm

Having Richard Rutter on the show a few weeks back made me acutely aware of my shortcomings when it came to web typography. Although I promised myself I would look into the subject in more depth I was a bit vague as to where I should start. Fortunately Richard has given me a starting point with a list of resources on his site that look at the subject of baselines.

I know that many people find web typography an uninspiring subject but good typography can have such a profound impact on how people perceive design that it really is worth your attention.

Client corner: Getting things done in web design

I have just finished reading “Getting Things Done” by David Allen. Not only has it seriously helped me to get control of my workload but its also made me rethink how I approach web design projects with clients. In this week’s client corner I suggest some techniques that designers and clients should use when a new project is starting.

As seems to be the default approach these days I blogged on this earlier in the week so if you want more information on what I said in the show then be sure to check out that post.

Ask the expert: Andy Clarke on CSS 3

Following Andy Budd’s recent criticism of the W3C CSS Working group it seemed appropriate to have Andy Clarke on the show to talk about the progress of CSS 3. Andy is an invited expert on the CSS working group so has the inside track on what is really happening. In the show Andy talks about…

  • Some of the cool layout features available in CSS 3.
  • The modular nature of CSS3.
  • The slow progress made by the group.
  • And the need for the web design community to contribute in the process.

Agony uncle: Insurance for web designers

We received the following question from Brian last week:

As an avid listener to your podcast – and having spent the day catching up on them while travelling! – I was very interested in a particular segment where your good self and that Lillington chap mentioned your Terms and Conditions and having, ‘…all the right insurances in place…’, with regard to setting up a business.

I’ve recently done some work with a mate – a few hopefully not-too-shabby websites – and although we think we are getting the hang of sorting out contracts now, we have never been able to settle on what to put in our Terms and Conditions. Every time I start to do it I either glaze over or start putting stupid things in due basically to boredom!

As for insurance we never assumed that we would need any for web design. Its not like we’re making nitroglycerine or heart bypass machines… so we assumed the basic rules of common sense prevailed.

To this end, if you have any advice on what insurances might apply or what sort of thing should be covering in T&C’s?

Firstly I’ll cover the terms and conditions issue, much as I don’t want to appear protective over our ts & cs, we have reached the conclusion that by providing them we are in effect providing legal advice.

This is not what we do and it’s not a path we wish to tread!

We suggest speaking to your lawyer or maybe a local chamber of commerce who could provide a standard terms and conditions contract template. I also droned on about the different aspects of terms and conditions in episode 65.

Insurance, however, is another matter. Though, again, I am concerned about making stuff up here (as is often the case!) so the majority of the following content is from Business Link. This is what we currently pay good money for:

Professional Indemnity

If you are in the business of selling your knowledge or skills, you may want to consider taking out professional indemnity insurance.

This protects your business against compensation sought by a client if you have made mistakes or are found to have been negligent in some or all of the services that you provide for them. Professional indemnity insurance will also cover any legal costs.

Public Liability

If members of the public or customers come to your premises or you go to theirs, you should think about taking out public liability insurance. This type of insurance covers any awards of damages given to a member of the public because of an injury or damage to their property caused by you or your business.

Product Liability

In product liability insurance (PLI) terms, a product is any physical item that is sold or given away.

Products must be “fit for purpose”. Under the Consumer Protection Act 1987, you’re legally responsible for any damage or injury that a product you supply may cause. PLI covers you against compensation awarded as a result of damage to property or personal injury caused by your product.

Employers Liability

Employers’ liability compulsory insurance (ELCI) enables businesses to meet the costs of compensation and legal fees for employees who are injured or made ill at work through the fault of the employer.

Key Man Insurance

Key man insurance is designed to cover you for the financial costs of losing key personnel. We still have this for Paul….goodness knows why! ;-)

Review: Looking beyond web design books

This weeks review section isn’t so much a review as a recommendation. At SXSW you are really spoilt for choice as to what to attend. In fact there is so much choice it is overwhelming. After much consideration I decided to take an interesting approach. I decided to mainly attend panels on subjects I knew nothing, or little about. Instead of going to panels on CSS or design I went to sessions on marketing and strategy. The result was an incredibly enjoyable and enlightening week.

On my return to the UK I decided to take a similar approach in my reading. Prior to this the majority of books I read where either on CSS or Javascript. However I am now trying to broaden out the range of books I read to encompass other subjects like productivity, business process, and even some sociology. As with SXSW it has been an incredibly rewarding experience and something I would encourage others to do. I have been amazed at just how much of what I have read has related in someway to my job and I believe it has genuinely improved the quality of my work.

I would really encourage others to try the same thing and would like to suggest three books to break you in gradually. Although none of these books are directly to do with web design they all include valuable lessons that you can apply to your work on a daily basis…

Podcast 43: The business of web design

Posted in Classic shows on by Paul Boag

In this week’s show, we cover: running a web design agency, what employers look for when hiring a web designer, the best stats package in the world, should we stop testing in IE 5, and running multiple versions of IE on a single PC.

Play

Podcast: Download (26.0MB)

Download this show.

To subscribe directly within itunes click here

Help us out. Complete our podcast survey

User questions: Running a web design company

This week’s show is a little different. We answer a series of questions from listeners about running a web design company. Questions include:

  • How do you go about pricing projects and in your experience what hidden costs are there?
  • How do you bill projects? Do you use payment points? Do you have different rates for different people? Do you charge by the day or by the hour?
  • What skills does a freelancer need beyond the basic CSS, HTML and graphical skills?
  • How do you assess potential web designers when hiring?
  • How do you manage a company that primarily works from home offices?
  • What is your number one tip for running a successful web design company?

In the news

There are some interesting news stories in this week’s show:

ClickTales

This week sees the launch of a new online stats tool. Nothing particularly newsworthy about that I hear you cry. Well actually there is. ClickTales has an awesome set of new tools including the ability to view flash movies of your user sessions.

Visit the ClickTales site

Read the techcrunch review of the service

Gerry McGovern speaks out

This week sees the posting of an excellent article by usability guru, Gerry McGovern. Gerry gives a gentle reminder to all designers not to forget the basics of web design in our rush to implement the latest cool piece of technology.

Read Gerry’s Article

Read my response to his comments

The end of support for Windows 98

Microsoft has finally decided to stop supporting windows 98. On the show, we discuss the ramifications of this for web designers. Is now the time for us to stop, by default, testing in IE 5?

IE 7 Beta 3

It looks like the third beta of IE 7 is facing some problems. Users have been reporting a plethora of bugs including problems with installation and slow performance. Could this spell a delay in launch?

Review

In this week’s show, we look at your options for testing in multiple version of IE on the same PC. In particular, we focus in on running free virtual machines either using VMware or Microsoft Virtual PC.

For more, view my post; Why IE doesn’t play nicely.

Download any version of IE (or indeed any other browser) from Evolt.

Also in the show…

Paul talks about the need to develop in compliant browsers first. Marcus shares his thoughts on presenting your proposals and we both discuss the new look and feel for boagworld.

Keep it simple stupid

Posted in Web strategy on by Paul Boag

The KISS acronym has become such a cliché that we so often ignore it. After all why “keep it simple” when we can play with the latest cool bit of technology.

I often feel somewhat isolated from the web community. While everybody else is writing about AJAX and CSS techniques, I am talking about the humble hypertext link and building better forms. For a long time I have felt that as web designers we lose interest in the mundane and would much prefer to spend our time pushing the boundaries of CSS or integrating the latest Javascript widget.

You can therefore imagine my delight to read an excellent article by Gerry McGovern in which he wrote the following:

"Again and again, I meet web teams that are excited by the exceptional task, and are bored with the common task. The common task on a website may indeed be boring and often inconsequential to you because you have completed this task so often. You have learned it inside out and to you it seems simple. It seems like there is no more work needs to be done on it.

The exceptional task is much more likely to be exciting and intellectually challenging. Beware. Every time you add an exceptional task to a webpage, you make the environment more cluttered; you make it more difficult to complete the common task."

I couldn’t agree more. We need to be careful that we don’t let our attention to the basics slip in our desire to constantly push the web forward. I can understand that we find the common tasks boring. However, the very fact that they are common means that they are by far the most important, simply because users are encountering them more regularly.

Book recommendations

Posted in Reviews on by Paul Boag

One of the most common questions I get emailed with is “what book would you recommend for XXX”. As I find myself continually recommending the same set I thought I would post a list of them here.

Update: Just a quick note to say that I have updated this post with some new books and will try and continue to do so in the future. Please note that this list only contains books I have personally read so bear in mind there maybe better books out there :) If you can’t be bothered to periodically check back then you can always subscribe to my booklist feed on delicious

Build your own website the right way using HTML and CSS

This snappily named book is written by Ian Lloyd (of accessify.com) and is perfect for those starting out in web design. This book will teach you how to build websites from scratch. No previous knowledge required. What is more, as the title says, it shows you how to build them "the right way". A refreshing change when compared to most web design books out there.

Buy Build your own website the right way at Amazon

The Zen of CSS Design

This book is basically made up of a series of case studies based on designs found at CSS Zen Gardens. In my opinion it is ideal for developers who are trying to improve the quality of design on their sites. The book is a mixture of CSS tips and design advice.

Buy the Zen of CSS Design at Amazon

CSS Mastery, Advanced Web Standards Solutions

Andy Budd’s book is perfect for those of us who have been using web standards for a while. We know the basics and are looking for advice to make us more efficient in our coding. This book is packed with all of the techniques you would expect plus some extra tip bits that make you slap your forehead and wonder why you never thought of doing things that way.

Buy CSS Mastery, Advanced Web Standards Solutions from Amazon

DOM Scripting

Jeremy Keith gives Javascript a new lick of paint, calls it DOM Scripting and blows your mind with its potential. If you are a designer who has always shied away from Javascript then this book is a must read. Jeremy teaches you Javascript from the ground up and then shows you just how much it can enhance your design.

Buy DOM Scripting from Amazon

DHTML Utopia: Modern Web Design Using Javascript & DOM

If you already know the basics of Javascript then Stuart Langridge’s book is probably a better bet than DOM Scripting. Stuart teaches you all the latest techniques of unobtrusive Javascript and throws in a bit of AJAX for good measure. Probably a bit heavy going for your average designer but easy fodder for you hard core developers.

Buy DHTML Utopia from Amazon

Designing with Web Standards

If you need convincing about all of this web standards rubbish then Zeldman’s book is for you. This book will give you the history of web design and explain why we have ended up designing with tables. It explains why web standards rock and then gives you a whistle stop tour of the basics. A must read for anybody starting out in web standards.

Buy Design with Web Standards from Amazon

Web standards Solutions

Of course once Zeldman has convinced you of the value of standards and got you doing the basics, you are going to want to get into the details. That is where Dan Cederholm‘s book comes in. This handbook covers every conceivable area of CSS based design and shows you all the tips and techniques. You will find yourself thumbing through it regularly.

Buy Web Standards Solutions from Amazon

Getting things done

This book has nothing much to do with web design but I would high recommend it anyway. Getting Things Done provides great advice about organizing your life to make your more efficient both at home and at work. Also a lot of what he covers is directly relevant to running successful web projects.

By Getting Things Done from Amazon

Laws of Simplicity

Again not directly about web design but invaluable none the less. This book talks about simplicity in life, in work and in design. The principles laid out in this book are a template for good design. If you design user interfaces you should read this book.

Buy The Laws of Simplicity from Amazon

Bulletproof AJAX

I think the best way to describe this book is as the sequel to DOM Scripting. Where DOM Scripting taught designers Javascript, Bulletproof AJAX takes you the next step on. I have to say if you have read DOM Scripting there is a lot of repetition in this book but nevertheless it is worth the money

Buy “Bulletproof Ajax” (Jeremy Keith) from Amazon

Don’t make me think

If I could recommend a single web design book then I think it would be this one by Steve Krug. Zeldman’s book on Web Standards is a close runner but this book covers the fundamentals of user centric design. You learn why usability testing is so important and are even taken through the processes of running a session. It is down to earth, practical and at times very entertaining.

Buy “Dont Make Me Think” at Amazon

Prioritizing web usability

Jakob Nielsen can be a bit full of his own self importance at times but he definitely knows his stuff. If you can work through the first chapter where he tells the world how clever he is then you will find a very valuable resource with lots of real world examples.

Buy “Prioritizing Web Usability” (Jakob Nielsen) at Amazon

The Tipping point

The Tipping point is not about web design but is a must read anyway. It talks about the concept of ideas and products going viral. How do some products or trends suddenly spread like wildfire? How do you make that happen? It discusses how small changes can have a big impact. Its invaluable to web designers because it shows how reaching the right audience and presenting information in the right way can have a profound impact on the success of your website.

Buy “The Tipping Point: How Little Things Can Make a Big Difference” (Malcolm Gladwell) at Amazon

Mobile web design

This book takes the principles of web standards and applies them to the mobile web. Cameron Moll discusses the different approaches to taking the web mobile from doing nothing to creating mobile specific websites. The book really does tell you everything you need to know to start building mobile websites in only 100 pages.

Buy “Mobile Web Design” (Cameron Moll)