Typeface.js

There are many solutions to insert custom fonts into your designs, whether it’s the good old CSS image replacement techniques, SiFR or FLiR, we’re really just biding our time until font-embedding through the @font-face rule becomes widely supported in the browsers (we’ve covered font-embedding before in show 129) But for now, there’s another technique on the block called typeface.js which uses browsers’ vector drawing capabilities to draw text in HTML documents.

Browsers have, for a while, supported vector drawing – Firefox, Safari and Opera support the canvas element was well as SVG, and IE supports VML. The Typeface.js project uses this vector capability to ‘draw’ the fonts within your webpage.

There are a couple of caveats, while the ‘drawn’ text is selectable, it’s not highlighted (though this should be remedied in future versions) and the fonts have to be converted first through a tool available on their website. But this might be a nice little fallback if the users browser doesn’t support @font-face.

Sell Your Web App

In our next news item Ryan Carson, owner of Carsonified, has this week published a blog entitled “Sell Your Web App: Lessons I Learned From Selling Dropsend” and as you would expect from that title he shares his tips and mistakes when selling his app and it’s a very interesting read.

He talks about considerations like choosing the right merchant account, anticipating high lawyer and accountancy fees and off course being discreet, don’t blog about your sale!

He’s also prompted for people to leave their own tips in the comments so if you’ve sold a web app yourself head over to thinkvitamin.com and share your experiences as well.

Lessons learned while building an iPhone site.

Theres a nice article on the Flickr Blog which details some of the lessons they learned while building the popular iPhone version of the Flickr site. They go into detail of subjects such as “don’t use a javaScript library or CSS framework”, “Load page fragments instead of full pages”, “optimize everything” and making sure to tell the user what’s happening through visual indicators.

If you’re developing iPhone apps, or are even just thinking about it I’d recommend giving this article a read before you start work, it may save you a lot of time down the line.

Free Site Validator

Our final news item brings our attention to a service blogged about by Roger Johansson at 456bereastreet.com. Roger was looking for a way to validate his site without having to do every page individually and what he found was freesitevalidator.com.

The service automatically craws each page of your site and checks it for validation, as well as giving you a report of any broken/dead links. Also known as Link Rot!

The service looks really useful so be sure to check it out.

Back to top

Paul: So as I said at the start of the show, joining me today is Mark Boulton. Good to have you on the show Mark.

Mark: Good to be here.

Paul: It’s nice to finally talk to you, we met up for the first time just a few days ago now.

Mark: Yeah, it was it was about a week ago.

Paul: It was great to do so. I talked about you a few weeks ago on the show as well when we were talking about a recent blog post that you wrote. But we will come on to that in just a minute. What we are going to talk about today with Mark is that he has done the unthinkable from a design point of view. Haven’t you really?

Mark: I have really yes.

Paul: You’re totally insane and so I wanted to pick you brain about why you have chosen to do the unthinkable. Before we get onto that, all of this resolves around some work your doing for Drupal. Tell us a little bit A) about what Drupal is and B) what you are doing.

Mark: Drupal is a Content Management Framework I guess, that allows people to build websites and its an open source project, it’s been going for quite a while now. I think seven years or so. The software is on version six now and it has a very large user base. Probably three hundred or so registered users.

Paul: Three hundred users?

Mark: Three hundred thousand!

Paul: Ah ok.

Mark: So it’s a pretty enormous project really, and with it being Open Source these are all very passionate developers. It’s quite a developer centric platform.

Paul: Ok.

Mark: The community, with it being open source the community contribute quite a lot to it, with modules and themes and that kind of thing, plugins. Our involvement in the project is redesigning drupal.org, which is kind of the home on the web of the framework, so you can go there and download and read documentation. But it’s also the home of the community, which is a pretty huge one. So it’s very exciting.

Paul: So tell us a little bit about the design process that you’re using, and this is what you blogged on and what kind of caught my attention and struck me as a ridiculous idea and what on earth were you thinking about?

Mark: Yeah, well I’ve been working with Lisa Raquelt who is a user experience researcher and kind of strategist. She started very early on in the process. She started blogging about it with the Drupal Association, who represent the Drupal community, who engaged us on the project. They are very happy with this being an open source project. They’re very happy with us to talk about it. Which is completely opposite to the way you normally work with a client.

Paul: Yeah, totally.

Mark: Normally you sign NDAs and it’s very closed doors. You don’t want to tell the competition, its the complete opposite, which is terrifying. Lisa started blogging about it and got really really great feedback from the community, really valuable feedback. Then I then started blogging about some of the design work we were doing. We are redesigning the wordmark and the branding currently. And I thought I may as well just jump in feet first here and see how this goes, which is totally contrary to the way I’ve been working in the past and the way your mind tells you you should work. You just shouldn’t openly talk about design because you’d think that it’s very subjective and everyone is going to have their own opinions, which is true. But we blogged about it a couple of weeks ago and it’s where my blog post on my own site, markboulton.co.uk, came about was I had a lot of people including yourself Paul. Who were saying I was insane, why are you doing this? And it’s this notion of design by community that’s very different to design by committee. Which is what a lot of people was telling me, "You can’t design by committee, it never works." Which is true, it never does.

Paul: So why do you think we are so hesitant as designers to talk openly? Is it fear of the subjective, is it that we don’t like people looking at our designs before they are finished? Why are we so hesitant do you think?

Mark: It’s a really interesting question that. I had an interesting conversation with an architect a couple of weeks ago about the exact same thing. A lot of architects don’t open up. A lot of designers, maybe product designers. An insight into the way somebody works and as designers we all work very differently and sometimes it’s a very private process. To expose that it’s almost like going out shopping with no clothes on. Suddenly you’re exposing the way that you work to everybody, to judge you, and people will judge you. It is a terrifying thought. I think part of it is also schooling. If you’ve done art at school, which most designers have done, most visual designers. You slave away on a piece of art and it’s not finished yet and it’s not finished and you don’t want anyone to look at it until it is finished, so I think there is an element of that as well. When I released two versions of the Drupal wordmark, for feedback they were very much just sketches. They were right in their first iteration. I would normally never do that but I thought let’s see what the community thinks.

Paul: So what happened when you released those two sketches?

Mark: It was carnage. Initially it was quite painful sometimes to listen to some of the comments to be honest. I think anybody takes their own work personally. If someone then attacks some of your own work with necessarily seeing any of the context and that kind of thing, then it can smart a little bit. But I’ve written my own blog for a while now and I’ve got reasonably thick skin, so it wasn’t that bad. What did come out through all of the comments were trends. Trends started to emerge. So from people’s subjective opinion, if enough people were having the same kind of subjective opinion, then that becomes less of an opinion and more of trend. And it was really those trends were looking to identify, that we could feed back into the development of the design.

Paul: It’s interesting there you talked about the fact the people who were seeing this stuff didn’t have the context. Did you not prepare the ground in any way? Did you not tell them why you took the approach you did? Or did you literally just put out the branding there and go, "What do you think?"

Mark: Yeah, there is a reasonably sticky situation with Drupal, particularly with the wordmark. They have a kind of logo at the moment, which is a kind of drop with a face on it. And that logo at the moment is under GPL so it can’t be trademarked which means the Drupal Association can not protect their own property, as it were, because this logo is under GPL. Which means that anybody can take it, change it, completely mess around with it. Which is fine, the community have been doing that for a long time now. So when I took on and blogged about this redesign of the wordmark, there was not the context, the business context, was perhaps lacking because I felt that I could not provide that business context. Because I was the designer and that should really come from someone else, and that was a little late in coming. Which is why the first blog post really didn’t go down too well, because I assumed the audience knew that this project was happening. As it turned out, it actually wasn’t. They didn’t know and it was all a bit of a mess, but it’s kind of smoothed over now, with later iterations and there’s been more blogging done by the Drupal Association. Which has provided the rationale for redesigning the branding.

Paul: Right, so there is a lesson to be learned there I guess of the importance of providing context and why stuff is happening and why you are taking the approach you are I guess.

Mark: Absolutely yeah, I think context is really important, especially for branding and logo design and that kind of thing. Just providing, and I was very aware of this when I blogged it. We all saw what happened with the London 2012 logo, when that is released very early without any context, it’s either misunderstood, or just hated or really liked. I’d rather have that kind of opinion anyway, than somebody kind of going, "Yeah, its alright."

Paul: You prefer to create a strong reaction.

Mark: Yeah, either positive or negative, because those are the reactions you can act upon. Anything in the middle is kind of gray, middle ground. That’s actually very very difficult to take on board and move forward with. So any kind of negative or positive reaction, you can take that on board, which we did. But the context for the Drupal logo is going to be the other stuff around it, which is the branding, the tone of voice, what is said on the page, the design, the other design elements around it, how it interacts with the existing kind of drop because they are still keeping that as a mascot. So it’s how all of that works together was perhaps lacking at this early stage. Which is why perhaps, going back to your initial question, designers don’t actually release very early on because the context isn’t there yet.

Paul: Yeah, which makes a lot of sense. When it came to the feedback, so you were obviously asking for feedback here, were you setting any kind of constraints on that feedback? From time to time I’ve talked on the subject about how to get design signoff and that kind of thing and one of the things that I always say is, "Don’t just say, ‘What do you think?’" but actually kind of try and guide the type of feedback you want and give a context to it, is that something you did?

Mark: Yeah. Not initially, which was why we had to.. The initial blog post didn’t really go down so well from an actionable sort of feedback point of view. Because I felt that a lot of the design questions I wanted answered. I think it was too early and I hold my hands up for that. I think it was too early in the process for me to blog about that. The second post that I put up I asked for specifics on whether or not the word mark needed a capital D or a lower case d and whether or not it needed, we were developing the idea of a secondary icon with it which is a splash and whether or not it needed the splash or not. We got some really great feedback because that focused people’s attention. That provided a really great selection of trends which have fed back into the next iteration. The first post was a bit of a free for all to be honest. Nothing really useful came out of it, which was a shame.

Paul: I mean you kind of, you talked about trends. Do you think that that is kind of, those trends that you see emerging, have the way that you have taken those on board has it been a kind of anecdotal trends or are you talking statistics here? Were you kind of marking down how many people you know said, "Yes, there should be an uppercase D." or whatever or are you just kind of taking on a feeling? Does that make sense?

Mark: Yeah. It was kind of taking on the feeling. More qualitative than quantitative at this point. However, for the cap D or lowercase d we could have just run a poll which in hindsight we should have done, is just had a tick box for each question as it were. However I’m always a little, I actually quite like a lot of the qualitative feedback because people were saying, "Yes cap D and splash," but then they go on to say something else. If we just reigned it into a simple poll then we would have lost all that really great, valuable feedback, because it’s that that provides context for their answer.

Paul: Yeah, I mean you won’t necessarily know why they’re saying a capital D.

Mark: Exactly, and there was enough of people saying the same kind of thing in those comments for it to be a pretty good trend for us to act upon. And it also throws out more heads about them on as it were. There was a lot of valuable comment from the Drupal community especially. And that we would have spent six months trying to research the ins and outs of that community, the history and the culture because there is an awful lot, you know. It’s been going seven years and there’s a lot of people in there. I would have been around ‘til next year trying to fully understand that community if I hadn’t adopted this open way of working.

Paul: It’s quite interesting, isn’t it? I mean when they were coming back and you were seeing a trend emerging very definitely one way or the other over something, were you always going with that decision or were sometimes you saying "Well actually, although everybody’s saying we should go with a capital D or whatever, I’m not going to because of X, Y and Z."

Mark: Yes. I think there does have to be somebody who is willing to make a decision on something that needs to be decided upon. If fifty percent of people said, "I like a black website," and fifty percent of people say, "I like a white website," the compromise is that you end up with a gray website and nobody wants gray. So, what we’ve done especially with the cap D and lowercase d for example there was pretty much an overwhelming response to, "Yes it should be lowercase d," because it’s kind of more attractive aesthetically and all the rest of it. However we’ve chosen to go with uppercase D and that is because of business requirements and also because of the ties in with the documentation. We’ve revised the word mark now where the uppercase D is actually a lot better than the previous version. Perhaps when I posted initially the lowercase d and the uppercase D were not really on an equal footing design-wise. The uppercase D needed a lot of refinement and again perhaps that skewed the results, skewed the comments and so we’ve actually reversed the general trend there and said, "Actually no. We think we should go with the uppercase D for this reason and this reason," and that will continue throughout the whole process. We’ve got to remember, and it’s very important, that the Drupal Association hired us for our expertise and if we feel strongly about something then hopefully we’ll go ahead with that and we’ll push back on any feedback.

Paul: I mean it’s quite interesting. You talk about, "as we go through this process." So it sounds like you’re gonna keep going down this line, that you’re gonna, you know, as you create say, the website interface that you’ll expose that.

Mark: Yeah we are. If you have a look on groups.google.org and do a search for the redesign group in there we have set in a bunch of dates in the calendar for gathering community feedback. So we will be posting up a link on Thursday to the prototype we’re developing and we’ll be doing that for the next six to eight weeks. Every other week we’ll be posting a link up there to gather feedback throughout the weekend. So we’ll be posting it up on Thursday/Friday morning and then we’ll be kind of locking off comments on Monday and then all of those comments will hopefully try and establish some trends and feedback. That’ll then feed back into the next iteration. So we’ve pretty much set a precedent here and we’re gonna be designing in the open ‘til the final curtain call, as it were.

Paul: Excellent! So how do you feel this differs from design by committee? Because from chatting to you when we met up whenever it was I got the distinct impression from you, you saw this as a very different kind of experience, but why, what makes it different?

Mark: Yeah, well I’ve been involved in design by committee quite a few times. I’m sure a lot of designers have and generally in those instances you’re in a boardroom or a meeting and there are several people, maybe twelve tops, and they all have very strong opinions. Generally, as I said in my blog post, there might be an alpha male in there or two sometimes. People can rally around the loudest voice, so all of a sudden that becomes the opinion. It can be a very, very difficult environment to work in because there are so few people, all with a very loud voice. Design by community is a different kettle of fish really because we’re designing for essentially 300,000 clients and the wider web community as well, we’re not just asking the Drupal community for feedback here, we’re also asking the wider web community for feedback. Anybody can get involved in this, it’s not just for the Drupal community. So anybody can. So if you feel like, talking to the listeners here, if anyone feels like weighting in with their comments, please do. Because it’s very important to us that the wider audience is reflected in this redesign and not just designing for the Drupal community. So it’s a very different process I think, because we’re kind of staffing back a little bit. We’re not in a meeting room with twelve people trying to come up with a solution. We’re putting stuff out there. We’re asking for comments from a lot of people who are thankfully providing comments, which is great. Really thoughtful feedback, then we can try and establish trends and then it’s those trends that we act upon. It becomes a little less subjective. That’s the idea anyway.

Paul: It’s the scale that turns it into trends rather than just an opinionated person I guess.

Mark: Yeah, that’s right. And you do have to, like I said initially, sometimes it’s difficult to read a bit of a flaming going on on your blog posts, you know, because there are quite a few people out there who will be very passionate about this project. They’re very passionate about Drupal because they’ve got a lot of time and money, a lot of people their livelihood is dependent upon this platform. So we have to really take that into account that this is serious for a lot of people. We’re not just redesigning a website here, we’re actually providing a platform for a community to do their work. So it’s pretty important stuff.

Paul: So, I mean do you think that this is a kind of a peculiar situation? You know, is the Drupal project unusual or would this be a kind of approach you would encourage for other designers working on other types of projects?

Mark: It’s a really interesting question. I mean I’ve worked waterfall methodologies in the past so you get your, you do your research, you do your initial designs, they get signed off and then you build your website, it’s very linear. And after working at the BBC for so long I realized that, because we worked very iteratively at the BBC that actually a more iterative approach was actually more valuable so to take that client-side approach, and the agile software development approach, to take that commercially with design is actually very difficult. But with the clients we are currently working with, that’s the way that we work. So we don’t work in a waterfall methodology, we work very iteratively upon fixed time scales. So we have a week per iteration for example. Now the feedback thing, the only difference really between Drupal and any other big project is the fact it’s open source and has a very, very big active community who are used to working in this way. I think that’s the critical thing is that they’re used to people putting software updates out early, feedback and they get changed and honed down until the final version is released but it’s just the way that they’re working so we have to kind of slot into that culture and it’s not a culture that design thrives in actually.

Paul: No, I can imagine.

Mark: No it’s a very difficult environment for design because, and it goes back again to one of your initial questions about wanting to sit there and craft a solution until it’s finished. Well that goes counter to the way that this open source culture works. They want to see stuff early. They want to feed back. They want their say. So as long as you kind of understand that and they’re not being grouchy or attacking you in any way they just want the very best for the project. So yeah, it’s worthwhile considering it as a working approach. Certainly the iterative approach is worthwhile considering for any project but the getting feedback early, if your audience is big enough then give it a go and see how it works. You know if you speak to me in six weeks time I may have a completely different conversation. This is really very much a work in progress and we’re just seeing how it’s going. It’s not been done as openly in the public before. I can’t really remember any projects from a design perspective that have been like this. It’s fairly unique. Which is really great, it’s exciting. So we’ll just see. We’ll see what happens.

Paul: Yeah, very interesting stuff Mark. Thank you very much for coming on the show.

Mark: Thank you for having me. It’s been a pleasure.

Paul: And we will wait with baited breath to see future blog posts as to how the experience goes to the bitter end.

Mark: Please do because I’ll be blogging about it pretty much constantly throughout the life of the project.

Paul: We’ll keep an eye on that. Thank you very much for your time and we’ll get you back on soon enough.

Mark: Great! Thanks Paul!

Paul: Bye bye.

Mark: Cheers. Bye.

Thanks goes to Todd Dietrich and Andy Kinsey for transcribing this interview.

Back to top

Keeping Positive

Got this question from Bill (remember him?!)….

I have just found out that the potential new project I have put loads of work in to winning is not coming my way. I wrote an extensive proposal, did some unpaid mock-up work, attended a presentation and jumped through every hoop thrown my way.

I was told by the client that it was ‘very close’ but on this occasion I had not been successful. Gutted.

How do you guys at Headscape cope with these types of rejections?

To be honest, and this is from a lot of bitter experience, it’s hard and some are harder to take than others.

I do, however, have a few thoughts and pointers that may help. Firstly, you can help yourself by weeding out the enquiries that you will never win.

Are these people worth your time?

Check out the email address of the enquirer. If it’s gmail, hotmail, yahoo or similar then chances are your potential client is just looking for free consultancy from you. I.e. they have an idea and have no idea what’s entailed in making that idea happen. And they certainly will not pay you to research it.

Secondly, and I am only aware of this possibility in the UK, but you can check up on a company through the Companies House website. This tells you all sorts of useful information about how long they’ve been around, their liquidity etc. You may change your mind about responding to a tender sent from a dissolved company.

Talk money

There is nothing more frustrating than being told that you are ‘way out of the ballpark’ after putting hours, even days, of effort into a proposal.

Ask people, up front, what their budget is. Explain that you need to know it to respond with the most appropriate solution for them. An example I often use is usability testing. Everyone knows that testing, preferably many times throughout a project can only be a good thing. But that said, not doing any testing doesn’t automatically mean that your client will get an unusable turkey for a site.

If you don’t get anywhere by asking then create a 2 or 3 paragraph solution with associated tasks (a mini proposal I guess) and email that to the potential client with an associated ballpark price. If they still want you to deliver a ‘full’ proposal then, chances are, your ballpark is within their range.

Ask/listen

Ok, so assuming you think that responding to the proposal is a good use of your time, you now need to read their brief in detail noting questions you have along the way. You will make a number of assumptions about what is the correct solution for this client while you are reading.

You need to talk to the client to confirm their answers to your questions but you also need to listen to their responses to ensure that your assumptions are correct. It’s very easy to arrogantly assume that ‘you know best’ because you’ve been doing it for years.

This also applies to your written proposal. Don’t describe and price up what you think the client needs – go through every point in their brief and respond to it accordingly. If it is plain obvious that something they’re asking for makes no sense at all, then tackle it head on and explain why they shouldn’t be doing it.

Stick to your guns

We decided, quite a while back, and for very good reason, that we would not do any unpaid mock-up design work. In some cases this has been seen as a positive thing (once it has been explained) but with other potential projects I’m sure it has adversely affected our chances of winning the work. However, we should stick to what we believe is right. Chopping and changing presents a negative image to both potential clients and our staff.

If you do decide to present initial mock-up ideas don’t be tempted into iterating them further. Any client who asks for is again asking for free work and is most definitely to be avoided.

Be gracious

Sometimes you just have to accept that you’re not the right fit with certain companies – even if the initial phone call or meeting went really well. It may well be that someone else delivers just the thing that really swings it for the client – sometime you just don’t know what that is.

If you do lose then you need to accept that you win some, you lose some. It often happens that these things happen in streaks which can be very frustrating. We found ourselves turning away superb opportunities earlier this year simply because we were too busy.

But always try to bring a positive attitude to any rejection because it is possible that these people will contact you again for further work (though beware that you are simply making up numbers!) or they may recommend you to others. They won’t do either if you react badly to the rejection!

Back to top

Working from home

The first post this week appears on A List Apart and applies to a growing number of people in the web design business. That is because it is tackling the subject of home working.

According to the home business report (PDF) published in October 2007, home based business account for 28% of all employment and have a combined UK turnover in excess of £364 billion.

No doubt that percentage is even higher among web designers. Therefore it comes as no surprise that this subject is being increasingly written about in web design circles.

This particular post is written from the perspective of a home working mother. However, her advice applies to anybody consider working from home. This advice includes:

• How to draw the line between work and home
• How to isolate yourself from the rest of the family while working
• How to explain to your client the screaming child in the background of a conference call
• How to win clients that are understanding of your situation

If you are already a home worker, I am not sure this article tells you anything you wont have already learnt the hard way. However, if you are considering making the switch for whatever reason this is definitely a worthwhile read.

British Standard for accessibility

Some time ago the British Standards Institute and the Disability Right Commission teamed up to release the first formal guide for business on website accessibility entitled PAS 78.

PAS 78 was intended to be a web accessibility guide, aimed at website owners rather than web designers . Personally I found the result somewhat disappointing. Although the advice was solid the language was hard going and it referred too often to the WAI guidelines. Although these guidelines are superb they are too technical for most website owners.

However, despite my personal opinion the document has proved very popular and is now being converted into a full British Standard. A British Standard is a common standard used across a variety of products produced in the UK. Although anybody can claim to meet these standards without external review, it is possible to be officially certified. Once certified you can display a BSI Kite Mark. This is a symbol of quality universally recognised in the UK.

Personally, I think this is a much better route for web accessibility to take. The alternative is legislation and that carries with it numerous problems. The team working on the standard is excellent and I look forward to seeing the result.

Growing your business through twitter

The next post solves an embarrassing problem I have. When sitting in the pubs with my mates, they occasionally catch me twittering. It is particularly embarrassing because I cannot really explain why I do it. Fortunately now I can thanks to a post from Tiffini Jones at Blue Flavor.

Actually the truth be told, Tiffini’s post refers heavily to another by Elliot J Stocks a few months earlier. He suggests that twitter is:

• An ice-breaker
• A purveyor of "ambient intimacy"
• A broadcasting / marketing tool
• A fount of knowledge
• A social network

Both posts communicate well the power of social networks if used wisely. This has certainly been my experienced and without tools like Twitter this site and podcast would have been nowhere near as successful.

I know a lot of people look down their nose at twitter. They claim it is a time waster, unprofessional and dull. However, I think they are missing the potential. I believe that networking tools like Twitter will in time diminish the role of search engines. Increasingly people will turn to online contacts for recommendations about products, services and information, rather than relying on the algorithms of Google.

Smart CSS aint always sexy

My final article today, demonstrates a sea change in the web standards community. It is a controversial article on the Digital Web Magazine entitled Smart CSS aint always sexy CSS.

The article challenges some of the basic arguments of standards zealots. For example is it so bad to name a class ‘red’? Do we need to pursue semantics at all cost, even when it compromises performance or maintainability?

This seems to be representative of a growing group of designers calling for a more pragmatic approach to web standards. Increasingly I am seeing little examples of rebellion against the more extreme supporters of standards. Whether it is the posts of Jeff Croft or the twitterings of Andy Clarke, it would appear there is the beginning of a more grown up approach.

Does this mean we can throw away good practice? Not at all. It simply means we are mature enough in our knowledge to bend the rule sometimes. Before you can paint like Jackson Pollock, you first need to know how to paint traditionally.

The morale of the story is that if you are new to standards then you should stick to the rules. However, if you are more experienced, there is nothing wrong with making compromises from time to time.

Back to top

No, content is not dead. Yes content is important, but there can only be one king and I am beginning to wonder if it is context in this weeks feature.

Back to top

Video and an elderly audience

Steven writes: I am currently working on a website that is going to be targeted toward an older demographic. There seems to be a large disagreement on whether video should be included on the site. The site is quite in depth and video explanation could be crucial. The main argument seems to be that people might not have the flash player and in turn not be able to view the video. On the other hand the Adobe site says that market penetration on flash player is over 99%!? Is flash video a usability issue?

One of the largest clients Headscape works with is trying to reach an elderly audience and so I have put some thought into this issue already. Unfortunately as with all of life, it is not a straight yes or no answer.

I see no reason why you cannot use video on your site. Although I do not believe Adobe when they claim flash has 99% penetration, I do believe the vast majority of your audience will have it installed. In my experience those who do not have flash are those behind a corporate firewall.

Although you can expect the vast majority to have flash I don’t believe you can design solely for it. The elderly develop visual, physical and cognitive conditions that can make it hard to interact with flash in some circumstances. Although a well designed application can minimise these problems, it will still affect a significant number of users.

I am afraid that although you can use flash, you will have to also provide an alternative. This could either be in the form of a transcript or captions (depending on the nature of the video), but additional work is required.

Most influential books

Teifion asks: What are the two most influential books you have read. Not just for web design but work and life in general.

I think this is possibly the hardest question I have ever had to answer. Choosing just two books has been horribly difficult. In an attempt to cheat slightly I have changed the rules to reflect BBC Radio 4s Desert Island Discs. This means I get the Bible and the complete works of Shakespeare for free! My choices are therefore…

• Getting things done by David Allen - I know I have spoken endlessly about this book before but that is because it has had such a profound impact on me. It is an easy book to dismiss with statements like "I don’t need to read it because I am already organised" or "it just tells you to write lists". In fact it is about a lot more than that. Getting things done has made me radically rethink my life and what I spend my time doing. It has made me question my priorities and change what I spend my life doing. Yes, I do write a lot of lists now and yes I am more organised but that is not what I got from this book. It taught me to take control of my life and decide what I want to achieve.
• Designing with Web Standards by Jeffrey Zeldman - I bought this book entirely by accident and yet it set my entire career in a new direction. Before reading this book I was feeling uninspired and stagnant in my career. I was bored with web design and felt that I had gone as far as I could. Reading this completely re-inspired me and introduced me to the web standards community. Without this book I doubt I would still be doing web design and certainly wouldn’t be doing this podcast or speaking around the world. Thanks Jeffrey!

The Mobile Internet has reached critical mass

This week saw the release of a new report by Nielsen Mobile entitled "The Worldwide State of the Mobile Web".

The gist of the report suggests that the mobile web is considerably more popular than many of us would believe. 15.6 percent of mobile subscribers in the US and 12.9 percent in the UK, use the mobile web regularly. In the US this equates to 40 million users. A substantial number.

Interestingly the most common device used for accessing the mobile web is not a smartphone but rather the Motorola RAZR. This reenforces the answer I gave Wayne in last weeks show. I said we cannot design exclusively for devices such as the iPhone.

With people like the VP of Google stating that the future of the internet lies with mobile users, there can now be little doubt as to the direction things are moving. This is especially true now that we are seeing unlimited data plans.

Web Standards Curriculum

A regular complaint I hear from students is that they are concerned about the out of date techniques they are taught at school or college. With many institutions still teaching table based design it is a legitimate concern.

Fortunately they are not alone in this concern. Opera and Yahoo! have teamed up to produce a web standards curriculum. This curriculum teaches best practice in web design and is broken down into modules that can be taught either by themselves or part of existing lesson plans.

If you are a student or educator definitely check this out. Hopefully you can get it adopted at your institution. Even if you cannot, there is nothing to stop you working through the course yourself.

Working with designers

Although our next post reads slightly like a rant (I should know what a rant sounds like!) it nevertheless communicates some excellent advice.

It is a post aimed at clients and provides 12 tips for working with designers. Advice includes leaving preconceived notions at the door, be specific in your requirements and design for your customers and not yourself.

There is no doubt that many clients serious misunderstand the role of the designer. However if I was a client reading this, I might find the tone hard to swallow. Despite that I would encourage those of you who work with designers to read this article. My favourite quote is…

Just as writers are not just people who can type, designers are not just people who can use graphics programs.

Web form design patterns

Our final post this week is a survey Smashing Magazine have done on 100 popular sign up form. The idea of the survey is to give you a better understanding of what makes an effective sign up form.

Of course, just because other sites do things in a certain way, does not make that the best approach. You should never blindly follow the crowd. Nevertheless this is a fascinating read.

The post is split into two parts and contains information such as…

The list goes on.

If you are looking to justify design decisions you have made or need some help designing the perfect signup form, this is a great place to start.

Just a quick reminder that the news we feature on the show is only a fraction of what myself and Paul Stanton post on the website. To get a more comprehensive view on what is happening in the world of web design, make sure you subscribe to our news RSS feed.

Back to top

I am not sure whether you noticed but this last week saw the launch of the iPhone 3G. It would certainly have been hard to miss it.

I don’t want to add anymore to the endless discussion surrounding this launch. However, I would like to focus on a side issue. I want to look at how O2s website handled this momentous event and what we can learn from their mistakes.

Back to top

Paul: So I’m very excited to have Jeff Veen joining me today on the show. Good to talk to you Jeff!

Jeff: Oh, it’s absolutely my pleasure. Thanks for having me!

Paul: Well it’s really good to get you on the show. I’ve wanted you on for ages, but I haven’t had the guts to kind of approach you so I sent Ryan to talk to you instead. I feel vaguely like, you know, you get at school discos where you fancy a girl and you send your best friend over ’cause you don’t have the guts to do it yourself. Or is that just me?

Jeff: Well I’ll tell you, I’m happy to have this dance Paul. It’s great.

Paul: Right, well for those that don’t know you Jeff and don’t know your background can you just tell us a little bit about yourself and how you ended up in a situation where you ended up working for Google. You know, how did that come about happening? ‘Cause that’s what we’re going to talk about a little bit today is your experiences of being at Google.

Jeff: Well, I tell you I’d been working with developers, as kind of more on the design side for quite a long time. Do you remember hotwired.com from Wired Magazine?

Paul: Oh yes, definitely.

Jeff: Way back when, right? Like we launched that back in 1994 and that’s really when I got started on the web, was coming over to Wired, working on their online properties like Hotwired, Webmonkey, and HotBot search engine, you know stuff like that. So I was with them for quite a while, they went through an acquisition and brought us over to Lycos, that big search engine. And then from there I started a company called Adaptive Path. Adaptive Path is a user experience consulting group in San Francisco. It was seven of us, we were all friends from the industry. We really focused on research, design, information architecture, usability, stuff like that. And I did that for a number of years with them and then finally convinced my partners that doing a product would be something interesting for us to try. We had done consulting. We had done some events. So we were kind of looking for the next thing to try. So I put together a small team of developers and some other designers and we made a product called Measure Map. That was a web analytics tool aimed specifically at bloggers. And just as we were about to launch it, we had done a bunch of work on it, Google gave us a call and said, “We love what you’re doing. We want you to come over and bring that to Google.” So we went through an acquisition there and that’s really how I got to Google.

Paul: Ahh, I see. ‘Cause I remember very vividly Measure Map coming along and getting very excited about it and then it kind of disappeared.

Jeff: A little bit, yeah.

Paul: Yeah, ’cause you got swallowed into Google.

Jeff: Well Google was very clear that they had a lot of respect for the work that we had done around designing Measure Map and wanted us to apply that expertise to their big Google Analytics product which had recently, sort of. They had acquired a company called Urchin, which had kind of an enterprise analytics package and they had made it free, and that had brought it to a whole new audience that really, sort of, didn’t quite understand how analytics worked. So we brought some of the best practices of design into Google and redesigned Google Analytics to make it sort of, kind of maintain all the power that it had, but make it much more accessible to a broader audience. So that’s really what we spent our time doing at Google.

Paul: OK, so we saw Google Analytics and those changes that you made to Google Analytics appear a few months back, and you know, were very impressive. But I’m quite interested in what happened. How did that come about, and how did that process work? So you arrive at Google, you walk through the door of Google. Now, one presumes that there was an existing Analytics team already working. Is that right?

Jeff: Yeah, that’s right. There was probably about twenty developers or so that were working on the Analytics application. Almost entirely all, sort of back-end engineers. As you can imagine, something of that size and scope, it’s a pretty impressive technical feat. The amount of data that they’re tracking every day, really just continues to blow my mind how much scale they have over there. So there was really, really talented engineers that had been working with the product for quite some time. That product had been around for a number of years. I think they were in version six of the product. But, to their credit, the Director of Engineering, a guy named Paul Moret, really knew that he had to change that application for this new audience that he had, sort of had started to grow by being at Google. So he was really behind the idea of completely rethinking. “Like lets,” he said, “Let’s start from scratch. Right, we have a lot of users. We have a really powerful product that I want to completely rethink how this happens.” And so, yeah, we really just rolled up our sleeves and sat down with him and his team and really sort of became one team. Got in there and made a lot of change. One of the things I think that really helped us be successful there was that we had a pretty robust methodology for user research that really resonated with a lot of the engineers that we were working with. It was really sort of. It was like I said, pretty mature, had a lot of data behind it so we could really show a lot of the work and helped us really get over a lot of the perceived subjectivity of design. So, you know, you can imagine this team comes in. We are a bunch of relatively technical designers, but still designers. And we sit down with these very, very technical engineers and we kind of showed them a process of how we were going to talk to a lot of the existing audience, a lot of the new segments of the audience, take everything that they told us and kind of boil it down into a lot of actionable next steps. And a way of prioritizing what features and changes we wanted to make. And so rather than us kind of going off, doing a bunch of design work and presenting it to them, we really involved everybody, or as many people as we could, in the process of how to change that application at its very basic level. So I think the results of doing all of that with the technical team was that we built a lot of trust between us. So that we could take some of their fundamental assumptions and really question those, but include them in that process so that there was a lot of give and take.

Paul: I mean yeah, because your initial reaction when you look at a company like Google, that it is a very developer-centric company. So I was kind of half-expecting you to say that you encountered quite a lot of resistance to the kind of design changes that you were introducing, but from the sounds of it, because your methodology is quite scientific, for want of a better word, you know it’s very logical, etcetera that it sounds like it went down quite well.

Jeff: Yeah, it did. It feels like we’re using the scientific method: doing testing and research and analysis and things like that. Ultimately though, so much of design is really, really hard to measure. Especially when it comes to matters of taste and perception and things like that. I mean, we can measure click-throughs and we can measure conversion rates and things like that, but ultimately the changes had to come from just being good designers. So having this relatively, kind of quantitative analysis that we did just allowed us to sort of speak on the same terms with the engineers. Have them trust us, and then let us make the changes we felt in our gut we should be making. So a lot of times I’ll be working with somebody who is very technical and they want to say, “Well if you make that change, can you show us some data that’ll prove that that’s the right change to make?” And almost never can I do that. Right, like we can do little tests and we can do some A/B testing and multivariate testing and stuff like that. And that’s good for little incremental changes but when you’re fundamentally changing an application it’s almost impossible to measure the accuracy of the decisions that you’re making. And that can be hard for somebody who really is a very analytical thinker, very quantitative in the decisions that they make, to sometimes kind of let go and say “No. You’ve got to trust us. It’s just going to be better.”

Paul: So were there other techniques that you used beyond providing data to kind of bridge that gap between the way that maybe designers see the world and that of developers?

Jeff: Well I’ll tell you another thing that I really believe in, is prototyping rather than just drawing mockups. One of the benefits I had going into Google is that I had a remarkable team at Measure Map that were quite technical. A very good front-end developer who could do lots of JavaScript, AJAX, CSS markup kind of work. A talented Ruby developer, and then a guy who was great with Flash and ActionScript. So bringing this team together, all of them good designers, but all of them with very technical backgrounds, we could come in and very quickly start to realize what a redesign might look like. Also the thing that really helped us was that Analytics internally had a very well-developed API. So we could say “All right, show us how this API works, then we’re going to immediately start experimenting on top of it using real data. We can bring users in for usability tests and they can see their data in our prototype in a matter of weeks, rather than months and months of development.” So having that separation between design, front-end and back-end, through a robust API allowed us to prototype so quickly that they could immediately say, “Wow! Look at all the work this team is doing!” Rather than us standing in front of the projector pointing at Photoshop comps or something and saying “Imagine what it would be like to click here.” We just had a thing working that people could log into anytime.

Paul: Yeah, I can really understand how that would make an enormous difference. So I’m presuming that you talk about your little team of people that went in there and started doing prototyping and stuff like that, but obviously you’re going to want to engage more with the developers that are there. I mean, the traditional danger has always been that as a developer and a designer you work independently. The designer does his thing. He hands it over the partition to the developer. The developer goes away and does his thing. Now I presume you wanted to avoid that. So how did you establish that working relationship? How did you end up working closely together?

Jeff: I have almost no interest in that sort of “waterfall method” where somebody goes off and does research, hands it off to designers, designers then do some of their magic, hand it off to developers. I’ve never been successful at doing that, primarily I think because I learn so much from the process of building things. So again, it was just, really one of the first things we did was invest a lot in getting the teams to trust one another. And that meant really just spending time with each other. So that meant almost every day just scheduling some time in the conference room for us all to kick around ideas, to look at some of the existing work that they were doing, some of their future plans and just spending a tremendous amount of time with them. We also just had our desks right next to the development team. We were embedded, we were just right there. So we felt like part of the team. We’d all go eat lunch together. I mean simple things like that just make the development process so much more, so much easier because there’s real people working with each other rather than faceless “other people” handing specs over. So putting a lot of time in: absolutely crucial to success in a process like that.

Paul: So obviously you got to work with a great group of people over at Google. Some of the most talented developers in the world I guess. So I’m really interested to know, what was it you learned from them? You spent all this time with them, what was the kind of thing that you took away as a front-end interface designer what did you learn from this amazing group of developers?

Jeff: Well, a couple of things really. I think the thing that struck us the most when we first got there was just the enormous scale of everything. Like Google, as you can imagine, Google has lots and lots of users, but they have a tremendous diversity of users too, literally from around the world. A statistic that we throw out all the time is that seventy percent of Google’s traffic comes from outside the United States. So the audience that we were used to designing for is really the small minority of people, and in fact the rest of the world is where all of the products are being used. So we had to think about that diversity of audience even in the design decisions that we were making every day in that everything that we were designing was going to be translated in up to forty different languages. So that was probably the first thing that really brought our attention. The second thing was the unbelievably high standards that Google had for their products. Like you said, I totally agree, they’re some of the best engineers in the world. They have coding standards. They have testing standards, QA standards that were absolutely remarkable. I just learned so much about how every little detail fits into place to make a product that’s as robust and as really scalable and useable by a global audience that Google has. It was really like I got a crash course in some of the best computer science education I could possibly ever ask for.

Paul: Very cool indeed. So for the designers that are listening to this now, the front-end people that maybe are working with developers day in and day out and secretly behind their backs are having a bit of moan about those developers, they’re finding them quite tricky to work with, what advice would you give them about interacting and working with developers?

Jeff: Well, like I said, you’ve got to spend time in the trenches with them. That I think is just the most obvious thing that I can recommend doing. For both sides. It was hard for me to trust a lot of developers, like “Oh, you’re only concerned about your servers, you don’t care about users at all.” Which of course is completely false, but that’s an inherent bias that I would have. So again, spending that time: incredibly important. I think one of the things that I try to educate the most while I was there was that the level of detail, the care, everything that goes into the coding standards that engineers have, we have that same standard for the interfaces that we build. So I think sometimes, and I hate to generalize across developers, because I’ve worked just the entire spectrum of developers. One of the themes that I hear from time to time is that design is something that kind of happens at the end. Like “We do all the hard engineering. We get all of these systems in place and write all of this code and then we need some designers to come on and put the interface on so that we can actually launch this thing.” That I think cheapens a lot of the work that we do, and it’s a little bit demeaning for the discipline of design, of user experience. So I think we have biases on both sides and that frankly understanding more about what goes into the process both from a front-end and a back-end point of view is kind of what brings us all together.

Paul: So if you could communicate one thing to the developers, one lesson, the question the other way around I guess. I guess in some ways it’s the same answer, isn’t it? It’s kind of stick with one another.

Jeff: Yeah, a little bit. Also there’s some really simple techniques that I’ve used, for example: even before we started we’d schedule a usability test with the existing product and get the engineers into the room behind that one way mirror and we would just watch. And we would watch people flail around with the interface and struggle and get frustrated and push the keyboard away. I mean that’s just golden. People see that and they’re just like, “Oh man, we’ve got some work to do.” So making it as clear as possible, what our users are trying to do, how we can all collaborate together to help them: incredibly, incredibly important. That said, it wasn’t, you know when I did consulting at Adaptive Path I was inside lots of companies. I worked with some of the biggest companies in America and saw inside of them and, to be honest, Google is truly a user-centered company. I was just so impressed with that. Broadening that idea of user-centered technology development is something that we worked on. Making it more of a balance between front-end and back-end is more some of the things we worked on. But ultimately I think Google really understands that putting users first is the way to be successful. Just look at the search results page with it’s very simple but incredibly effective advertising techniques, and you know, Google never had a front page that was full of the sort of portal design stuff that Yahoo! and other companies have done. So really, it was very fertile ground for the kind of work we wanted to do when we got there.

Paul: Very interesting. I’ve just thought of one other question that I get asked a lot from people looking to get into web design: they say, “So what am I better off doing, you know, where’s the best place to work? Is it in the large company? Or is it doing something in a small company by yourself?” Now you’ve obviously done both of those and there is no definitive answer, but what would you see as the pros and cons of a large company in comparison to working somewhere smaller like Adaptive Path?

Jeff: You’re right, in my career I’ve got swung back and forth between big and small. There are definitely benefits and drawbacks to both of them. In the bigger companies I think just inherently things move slower. Now, I mean Google is renowned for it’s “bottom-up culture” and good ideas are always emerging from people taking their twenty percent time. None of that is a myth. That all really happens. But at the same time, like I said, when millions of users, or hundreds of millions for some of the products. You just have to take a lot more steps, and what that does is it increases the distance between the idea that a designer or developer has, and a user actually seeing that idea. And one of the things that I love about this sort of entrepreneurial startup environment is that you can think of something, you can try it out, you can get it in front of your users. You can do that in an afternoon. And you can’t do that with a product like Gmail or Adwords or something like that because there’s so much inherent infrastructure and risk, things like that. I think it’s incredibly worthwhile for people to have both experiences, and frankly see what they like best. One of the things I really have learned in my career is that there are people that like to start things, and that there are people that like to run things. And there is no inherent judgment between the two, but once you understand “Ooh, I love having a big system and having that system run perfectly, and putting all the things in place to keep that, you know.” And that’s fantastic. I’ve learned, in my career, that I’m kind of on the other side. I love starting with nothing and building up something, and at some point I need to hand it off to somebody who is much better at running and maintaining, right. So those are the kind of things you learn by doing a lot of very different projects and product development and stuff like that as your career kind of goes on, I think.

Paul: So you’ve left Google now? So what’s the next step? What are you up to at the moment? Let’s finish on a looking forward note. Where are you going? What are you doing?

Jeff: I was at Google for just over two years and left about six weeks ago, and to be honest I’m spending a lot of time right now cycling and trying to sleep late, and things like that. I tell you it’s a tremendous luxury and I’m not taking it for granted at all. The immediate next thing is that I’m organizing a little conference with my colleague Bryan Mason, who I have worked with at Adaptive Path. He and I are doing a conference in San Francisco in August about starting companies. Yeah, as I was leaving Google I was thinking, “Well, what should I do next? What would be interesting?” So I talked to a bunch of my friends who have been entrepreneurs, or who are now investors and I just asked them, “Tell me your story. How did you get to where you are?” And I found those stories so interesting that I thought, “Man, we’ve got to share this. This is great.” And I thought, “Well, I could do a podcast or something like that.” But then I thought, “I love getting people together and having sort of a community feel.” So we thought: we’ll get one day, San Francisco in August. We’ll get everybody together and we’ll just have these conversations. So I’m really looking forward to it. It’s called “The Start Conference” and you can find it at thestartconference.com. That’s what we’re doing now.

Paul: Excellent stuff. Thank you so much Jeffrey for coming onto the show and talking about that. The issue of designers and developers working together is something that’s really important and I think there’s a lot of work still to be done, and it’s good to see that there are people out there that have got it right and are going in the right direction.

Jeff: I appreciate that Paul.

Paul: Thanks for your time.

Jeff: Thank you.

Thanks to Todd Dietrich for transcribing this interview.

Back to top

Adding a jingle to your site

Chris writes: A client of mine wants to incorporate 4 second jingles at various points on their website, triggered on page load, to reinforce their servicing brand. My first reaction is that this could get annoying but was curious as to your thoughts on the use of audio on the web.

I don’t think that there is any set ‘rule’ here but basically I would agree 100% that you shouldn’t do it because it will annoy the hell out of the site’s users.

There is an argument that audio branding can be included if the user only has to hear it once. However, I would dispute this as well for the following reasons:

• It may well still annoy (and therefore have a negative effect upon) the site’s users
• Users aren’t expecting it and it could embarrass them in an office environment
• Quite a lot of users will have the sound off. Therefore, if you decide that the audio is only an ‘add on’ for the brand then you may as well conclude that it’s not necessary at all.

I have talked about audio on website before and reached the conclusion that, even though technology and bandwidth makes it more doable, it’s the wrong medium for audio. I think I likened it to having a soundtrack while you’re reading a book - it’s just wrong!

Of course, there are no doubt exceptions to this rule - really well thought out and produced audio indicators on a web app for example - but, generally speaking, audio branding on a website will have a negative effect. If your client is insistent, try and persuade him to include a video download on the site where audio will certainly work.

Fixed or bespoke pricing

Jon writes: We are a small web design and development company (4 people) and have tended to concentrate on higher value bespoke work. We are probably about to merge with another slightly larger company in a neighbouring town. This other company have traditionally aimed at a somewhat lower value market.

My question is about pricing. The other company operate to a very structured price list (£x for a 5 page brochure site, £Y for a basic ecommerce site, £Z for an ecommerce site with knobs on etc). We have always priced each project individually using a mixture of time costing, guesswork, and a "how much can we get away with" approach.

Do you think that a merged company approaching a wider market and value range would be better to adopt one approach or the other, or continue to do both? Would the existence of one approach damage the ability to operate effectively at the other end of the scale?

I guess the big question here is - are you going to remain as two different entities with some shared resources, or are you going to merge more fully and share work between the team no matter where it is sourced from (i.e. will one of their designers work on a future project from one of your existing clients)? If it is the former (which I suspect it isn’t) then I would keep the two pricing models the same as they are. I wouldn’t try and hide the fact that the two companies have ‘merged’ though, just explain that there are two teams delivering different services.

However, if the two companies are merging more fully, then I think this is actually fairly fundamental stuff. It’s almost like you’re all starting again and need to write a business plan. I think you would be opening yourself up for much criticism if you tried to operate both pricing plans.

I suppose other questions to you would be:

• Which pricing plan is most effective (who is making the most profit)?
• What does each company’s order book look like? I.e. have you just signed a massive contract at your higher rates?

This is interesting stuff and I’d like to know how it works out. I suppose the biggest unknown for me (that may well answer all of my other questions) is that I don’t know the reason for the merger in the first place.

Back to top