Tag Archives: forms

123. Plight

Posted in Classic shows on by Paul Boag

In this weeks show we review Textmate and the Top 5 Tips for Web Designers and we discuss the plight of in-house designers.

Play

Podcast: Download (30.4MB)

Download this show.

Launch our podcast player

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

If you feel you could help once in a while please drop an email to Ryan our producer and he will add you to the list.

News and events

SPAM meltdown

It is always with fear and trepidation that I mention HTML email. It inevitably leads to a torrent of comments ‘educating’ me about the evils of HTML in email, and that we should only use plain text.

Although personally I wish HTML email was never invented and try to limit its use, I do accept it is here to stay. Despite its many drawbacks it is statistically more effective than plain text from a marketing perspective.

You will be hard pushed to pursued a client to forgo HTML. Inevitably we will have to produce HTML templates occassionally. Of course, being conscientious, when we do produce HTML emails we want to ensure they look great and are well coded. This leads me to a couple of stories worth mentioning.

The first is that Patrick McNeil (of Design Meltdown fame) has launched a new site called Spam Meltdown. The site showcases examples of great email design in much the same way as Design Meltdown does with websites. Patrick has done an amazing job on this site and he has my sympathy because he is subscribed to over 1000 mailing lists! The designs he showcases are organised by style, colour, industry and topic. As with design meltdown this categorisation approach works really well. You can quickly find inspiration by looking at categories that are relevant to your project.

The second news item worth mentioning is that Campaign Monitor have updated their chart for CSS support in email clients. Campaign Monitor is a service which allows you to send HTML newsletters, but they do a lot more than just take your money. They are actively involved in improving standards support among email clients through the email standards project. Next time you are trying to produce an HTML email template check out their CSS support grid as it will clearly show you whether a particular CSS property is supported.

Form Analytics

While I am on the subject of cool services like Campaign Monitor, I also want to mention Clicktale. Clicktale is a service that allows you to track users as they move about your site and even anonymously record their actions. The last time I mentioned them this disturbed many people who saw it as an invasion of privacy. However, I see it as a valuable tool for learning about user interaction and improve site usability.

If you share my view, then you maybe interested in a new service they are starting to offer. You can now not only track users as they click around your website, you can also watch how they interact with forms.

In addition to video recording, the new form analytics service also provides three invaluable reports…

  • The time report – This shows how long users spent completing each field.
  • The blank report – This provides information on fields that have been left blank on submission.
  • The refill report – Which highlight fields that have been completed incorrectly.

If you run a site that requires users to complete long or complex forms then you will see the benefit of this service. On a high trafficked ecommerce site this would be invaluable, substantially reducing the number of users dropping out at checkout.

Art direction hits the blog

This week has seen the launch of Jason Santa Maria’s new personal website. For those of you who do not know, Jason is the creative director at Happy Cog (Zeldman’s company).

Normally, I would not mention the launch of a new personal website. However, Jason has done something very interesting. His new design is well executed but plain. It certainly is not as inspiring as his other work. The reason for this simple approach is that it is a framework upon which he will build.

The idea is that each of his blog posts will have a custom design to accompany it. The design will therefore reflect the content. In effect he is bring art direction to his blog. This is a bold experiment and something that Zeldman has written about before.

Although I am fully behind the idea of bringing content and design closer together, I do have some reservations. First, there is a possibility that the constantly changing design could make navigation around the site confusing. Fortunately from what I have seen so far that will not be the case. Jason has been careful to ensure key navigational elements remain in a consistent location and have similar styling wherever you are in the site. However, if other designers were to adopt this approach would they be so careful?

My second concern is a purely practical one. If each article not only needs writing but also designing, will that reduce the amount Jason posts? In other words is a blog really the right place for this type of art direction?

However, despite these reservations I am really pleased Jason is trying this approach. A personal website should be the place to experiment and try new things. Too many blogs (including my own) are cookie cutter solutions with some pretty graphics slapped on top. Its superb to see somebody doing something different.

Prototyping

My final news story of the week returns to a subject we have touched on recently. How do you wireframe a modern web application with its high level of interaction? In show 120 I mentioned that one approach might be to utilise flash. Today I want to point you at an article on the List Apart website, which suggests that building prototypes maybe better than struggling with wireframes.

When I first saw this article I was hesitant. After all I can barely pursued my clients to pay for wireframes let alone a full blown prototype. However, the more I considered what was being suggest, the better the idea seemed.

The majority of time spent getting an application working is spent on bug fixing, browser support and non-core functionality. The rough ‘outline’ of an application can come together very quickly. What is more, unlike wireframing, a prototype can be used as the basis for the final build. It does not get thrown away like a wireframe.

The article also points out that prototypes are better for demonstrating difficult concepts to clients. They encourage earlier collaboration between designer and developer, and provide something substantially better to user test against.

With almost every new website having some form of web application, we all need to consider how to better conceptualise their operation.

Back to top

Feature: The plight of the in-house designer

The more organisations I work with the more sympathy I have for in-house designers and developers. It is a role that can be thankless and isolating. How then can their lives be made that much easier? We discuss this in this weeks feature.

Back to top

Reviews: Textmate and Top 5 Tips for Web Designers

We have two reviews this week by our lucky competition winners Teifion Jordan and John McFarlane. Teifion and John will be going to this year’s dConstruct in Brighton.

dConstruct is the affordable one day conference for people designing and building the latest generation of social web applications. Tickets cost £125 inc VAT and went on sale yesterday so be sure to check it out.

Textmate by Teifion Jordan

Hi, I am Teifion Jordan, I am reviewing a program created by someone far smarter than me. I am going to be looking at Textmate. Textmate is a Mac only application though there is a similar editor called eText Editor for Windows.

First impressions of Textmate are that it’s pretty sparse, it looks like any other editor. I throw it a PHP file and it colours the text in, just like any other editor would. The colour scheme can be changed, both text and background colours can be altered, which is quite a neat touch. I can even make parts bold, italic and underlined which is a neat touch. It requires knowledge of Regular expressions but I can actually add in more rules for what to colour in! I used this to make variables used as array indexes appear differently, something I have wanted to do for some time. Not since I was a toddler, but definitely some time.

But enough moaning about how the program itself is both smarter and better looking than me, I wanted to try some code. I found that if I typed "foreach" in a PHP block and hit tab, I was presented with an entire foreach loop. Closer inspection revealed that there were dozens of snippets and commands for PHP and dozens more for each of the many languages and some things that were not languages. With 5 minutes of effort I had setup Textmate to post my blog posts for me, I am now one step closer to not having to put any effort at all into blogging.

It is possible to create your own snippets and not at all hard either. I now have one to tell me that I am beautiful and another to create a PostgreSQL query. I can also write new commands, I can write them in command line script, Python, Ruby and PHP to name a few. All of the commands are completely open sources, so you can see what’s already been done, and sort of plagiarise that sort of work for your own means. Except plagiarism is bad so don’t ever do it.

I can edit columns, I can write new snippets, commands and even entire languages, I can Regex, I can manage projects with a hierarchal file structure. It’s like before I was walking but now I’m on a push bike. I can’t make use of the ability to run down pedestrians until I learn how to do balance and pedal. Okay, the running down pedestrians was a bad example but anybody that is still listening and not calling the police must have understood it so I’ll continue. There’s nothing I can’t do in Textmate, I just need to look at the extensive online manual to learn it. And there I think is it’s biggest failing.

Textmate is a really lovely program to use but it’s so complicated. Coda, as a contrast, is a more intuitive application but it is to Textmate as a spade is to a chainsaw, that is, meant for a different problem and with fewer moving parts but also with the ability to digs holes? I’m sorry, my mind wandered. What I meant to say is that Textmate is great for dealing with code but not so much the design which is what apps such as Coda excel at. I’ve now been using Textmate for 10 months and I still think there is potential to unlock, though, that might be because I’m a thickie.

I suppose I should wrap this up by saying that I would heartily recommend anybody thinking about writing lots of code to give TextMate a good look. It takes a lot of time to get a lot out of it, but there really is a lot to get out of it.

Thank you very much for listening, I hope this was at least semi-informative

Top 5 Tips for Web Designers by John McFarlane

Hi, I’m John McFarlane and this is the first ever review brought to you live from my living room. Today I’m reviewing a post that has been submitted on the boagworld.com forum. The title is "Top 5 Tips for Web Designers". I’ve been reading through the replies and I’ve put together my top 5 top tips.

In at number 5 submitted by richquick, allow time and money for personal development, read blogs, buy books, attend conferences, experiment and learn new techniques and technologies.

In at number 4 posted by Jayphen, surround yourself with designers, whether they’re colleagues, real world contacts, online contacts, forums, podcasts. The more you talk about design the more you learn and I’d like to add to that e-mail designers for advice and let them know your experiences.

In at number 3 posted by some guy called Paul Boag, develop with the latest best practices, ensure you separate content, design and behaviour. Make sure everything you build uses progressive enhancements.

In at number 2 another one by Paul Boag, it’s an obvious one but one that can’t be put across more clearly, know HTML, CSS and javaScript inside out, you need to know the core technologies that underpin the web back to front. I’d like to add to this point, the basics of HTML and CSS are easily learnt but don’t be fooled into thinking that you know enough, you really need to know these subjects to an advanced level. This will benefit you when your implemented the latest best practices.

And that brings me on to my number 1 tip and that is love your job, I think if you love this industry and have a passion for web design, I think those qualities will guide you to achieve your goals. So enjoy your development and don’t rush yourself too much. Take the time to develop the right way, build contacts and friends and embrace the industry as a whole.

That about raps up this weeks review. I hope you’ve enjoyed the very first show live from my living room. Thank you and goodbye.

Back to top

Listeners feedback:

Newspaper columns on the web

Adrian writes: Hey guys, long time listener from the states. I’ve been working on a new personal site lately and I’ve become fixated on the idea of using newspaper style columns. Since you two seem to know a thing or two usability, I’d figure I’d ask for your thoughts.

It seems like most people view them as a print concept that doesn’t translate well online but seeing as most screens these days are widescreen and vertical space is taken up by menu bars, docks and browser extensions, going horizontal strikes me as a logical solution.

I appreciate the logic. It is true that more computers than ever have widescreens and that vertical space is at a greater premium than horizontal. However, I would think very carefully before employing newspaper style columns. As I see it there are two concerns:

The usability concern

As you point out, people reference usability concerns as the primary reason against newspaper columns. In a newspaper, copy runs across several columns with the eye darting from the bottom of one column to the top of the next. This is acceptable because the user can view the entire newspaper in a single glance. There is no such thing as a scroll bar.

On the web it is different. You are unable to predict the height available in a browser window and so users will almost certainly have to scroll. This means the user will scroll down one column as they read and then have to scroll back to the top to start the next column. This is far from a pleasurable reading experience.

It is also important to consider width as well as height. As you say newspaper style columns works well on high resolution, widescreen monitors. On anything less the story becomes unreadable with narrow columns and short line lengths. The alternative is to allow both horizontal and vertical scrolling. But as I am sure you, know this is the ultimate usability error and should be avoided at all costs.

The technical concern

There are also technical considerations to take into account. How will a story be split over multiple columns? Currently this cannot be done in CSS, although this may appear in CSS3.

One option would be to manually layout each block of text. However, this isn’t going to be practical with anything other than the most static of sites.

The only option is to use some server side code. However, even this is not without its problems. Consideration needs to be given to inline elements such as images or quotations. What happens if they appear at the end of one column? Does a quote get split? Will the design accommodate larger images? What happens when text is scaled?

Although all of these technical problems can be overcome, you are forced to ask whether it worth the effort. This is especially true considering the serious usability concerns.

Estimating dev/creative work

Kirk Henry asks: I’m not sure if this should be listed as a question or not but her goes. I’m a Creative Director for a dev shop with some very large fortune 500 companies and a problem I always seem to come across is difficulty in the estimating process. We use excel documents, have some standard hours for comps but have to do custom estimation for multi media projects etc… my estimates are always pretty decent but I want to know what you guys use or what software you would recommend. I have been listening on itunes from the start and love the show.

Ok, this is probably the most important subject that we (and I mean the web community) don’t talk about. Why? I think, because it’s difficult to pin down a method of reliably estimating a project and, more so, we’re all guilty if underestimating time and again… these are my thoughts:

The first thing to ask yourself is ‘how serious is this project?’ I have a sixth sense for requests for quotes that fit into the following brackets:

  • ‘We have this idea but have no idea how much it will cost and we want you to do all the research work involved in scoping it. Of course we won’t pay for the research and there’s no way we’ll pay sensible money for the work once we know what it is’
  • ‘We have a supplier that we want to work with but my boss says I need a couple of other quotes’
  • ‘Us guys in sales and marketing have been doing some blue sky thinking and want a quote to redevelop Google….’

You get the idea – timewasters. You need to deal with these requests quickly – this is how I do it. Have a chat with whichever department(s) would do this work if it ever materialised – get them to give you wide ballpark figures. Add in PM and contingency and send them an email. 99 out of a 100 won’t even bother getting back to you. Some will, but they’re usually trying to get free scoping (‘can you give me a bit more detail on how you reached those figures’).

Anyway, I’ve ranted long enough timewasters, back to Kirk’s question.

First question – do you know the budget? If yes, then you are looking to fit a scope into a set amount of effort. Can you do it? Will the ‘client’ be happy with the scope that fits their budget? Do they understand what that scope is (especially if you have reduced it to fit their budget)? DO NOT get creative with your effort allocations just to fit within the budget. Either ask for more (up front) or walk away.

If you don’t know the budget then you are looking to scope a project from scratch. If it’s a really big project then ideally you should be being paid to scope it as we’re looking at business analysis and consultancy here.

Break down the project into rough task areas. It’s likely that you’ll have done other projects that include similar tasks so you’ll know efforts on these (though ask yourself if you got it right last time). For the ‘new’ tasks, break it down further and you will probably find other smaller tasks that you have done before. For the really new stuff then you need to talk to an expert (designer/developer/IA) and get them to think the task through. They will provide you with an informed guess. That’s right – guess. Because people are guessing it is really important to overestimate fixed price projects. This is the cost to the client of having a fixed price.

Don’t forget to charge for meetings (if 3 people are attending then charge for 3 people!). Project management is notoriously undercharged. We have a rule of thumb of 15 – 20% (and that’s probably light).

The golden rule of estimating is don’t be tempted to lower your probably already too low price just to win the work. Be prepared to walk away.

As far as tools to help with estimating go, MS Project is great at separating tasks, linking resources to tasks and giving you a good idea of how long things will take. But, I tend to find that it is over the top at the quote stage and tend to stick with Excel.

Back to top

122. Screencasting

Posted in Classic shows on by Paul Boag

In this weeks show we have Ian Lloyd discussing Sitepoints HTML reference and we take a look at creating screencasts.

Play

Podcast: Download (28.7MB)

Download this show.

Launch our podcast player

Watch the behind the scenes video

News and events

Typography everywhere

This week has seen a plethora of posts about typography. There is an article about changes being made to typography in Firefox 3, a post dedicated to working with paragraphs and some future developments in CSS 3 fonts. Combined with the growing support for embeddable fonts, it would appear that web typography has a rosy future.

Although all of these posts are interesting, I feel we are not making use of the typographic tools we have already. I have learnt a huge amount by reading what people like Richard Rutter and Jon Hicks have to say on the subject. For example how many of you…

  • Ever change the default kerning
  • Really get specific in your cascade of fonts
  • Consider vertical alignment
  • Think about the relative sizing of our various typographic elements

The list could go on.

Many web designers choose to ignore web typography because it is so restricted. However, this will soon change. We need to learn to walk with the basic tools currently available before we run with what is to come.

Accessibility cheat sheet

Our next story follows on nicely from last week’s feature in which we addressed accessibility quick fixes.

Aaron Baker has written an accessibility checklist aimed at designers and developers who know little about web accessibility. The idea is that by simply referring to the list during development they will be able to avoid the major accessibility issues.

Aaron is the first to admit this isn’t an ideal solution. He also accepts the checklist fails to cover everything. However, in my opinion he has done a damn good job at making the accessibility guidelines… accessible!

What I like most is that he also provides a PDF version that prints out as a single page. Instead of having to wade through pages of W3C guidelines you can print out a single page and pin it to the wall. Ideal for those starting down the road of accessibility.

Does this mean we can ignore WCAG? Absolutely not. However, this is certainly an easier starting point for those who are intimidated by the subject of web accessibility.

Advice on wireframes

We are having an interesting discussion within Headscape at the moment. Where does the job of an information architect (IA) end and that of a designer begin? When it comes to wireframing in particular, the line is blurred. A wireframe is often produced by the IA but can strongly define the layout and design. This reduces the designer to skinning a site, which is a real waste of their skills.

I was therefore excited to read the first in what will be a series of posts on wireframing. The author identifies exactly the problem we have been struggling with and talks about page description documents. These documents differ from traditional wireframes because they do not endeavour to establish a layout. Instead this is left to the designer. A page description document focuses on identifying and prioritising content. It is then down to the designer to represent this on the site.

It is an interesting approach and one that I think has a lot of merit. However, I am equally excited to see the other posts in this series, where the author promises to show us example wireframes and provide more details on his approach.

Top five tips for new web designers

The final news story of today is an unusual choice as it comes from our own forum. Our forum is always full of great threads, but one in particular caught my eye this week because it covered the most common question I get asked; ‘what advice do you have for a new web designer?’.

It is not a long thread (yet!) and so is easy enough to follow. However, each poster has provided some excellent advice in the form of their top 5 tips.

The tips include…

  • Advice on business
  • Techniques for improving your skills
  • Areas to focus on
  • Books and sites to read
  • What to learn first
  • How to increase your profile

Without exception they are all gold dust and if you are new to design then definitely give them a read.

Equally if you have been a web designer for a few years take a moment to post your own contribution. I think you will probably learn something at the same time.

Back to top

Feature: Creating Screencasts

Video is becoming an intrinsic part of the web and not just dumb ass videos on YouTube. Video can be used to show off products and provide online presentations. But how do you create a high quality screencast on a budget? We look at this issue in this weeks feature.

Back to top

Interview: Ian Lloyd on Sitepoint HTML Reference

Paul: OK. So joining me today is Ian Lloyd. Hello Ian.

Ian: Hello Paul!

Paul: Have we had you on Boagworld before or is it just .Net?

Ian: Erm… Actually never in real life person. I did the video thing for you before, the screencast.

Paul: Yeah. That’s it. I knew there was something.

Ian: I’ve heard my dulcet tones before.

Paul: Yeah but not on a live, real, happening interview type basis.

Ian: Is this happening? What as in cool, hip and happening? Wow.

Paul: This is happening right now! So there we go. That’s exciting. So the reason I have Ian on the show today is that he had just undertaken and completed a mammoth project no less, in the form of a HTML reference guide that is now available via SitePoint. Now we’ve talked before on the show about the CSS reference guide but the HTML one is a new project that is beta at the moment. Why have you showed a beta tag on it? Come on, put your money where your mouth is. Commit to a real live version!

Ian:Well that’s not really my shout in fairness but I think the reason they do it is that with all the will of the world and all the technical editing that goes on and all the rest of it, invariably there’s going to be things that will crop up.

Paul: I was always under the impression that you were infallible Ian.

Ian:Well I would to keep that myth going but it’s obviously completely untrue. But no, I think it’s sensible. From what I can gather they did this with the CSS reference and they told me that they did get some good feedback as a result of doing this. So it gives them an opportunity to capture anything that has so far evaded various editing stages. There are little things that you can easily, easily miss. So it makes sense. Put it in front of a whole bunch of pedants and you will find that things will be revealed that you weren’t aware of.

Paul:Yes certainly. So tell us a little bit about how the project came about. How did you end up working on this from SitePoint and how you get involved?

Ian:Right… Well it’s actually quite a long story that I’ll try and shorten down. Basically I’ve got a bit of history with SitePoint. It goes back to probably 2001/2002, something like that where I was writing articles for them. I had written a few and they had been scored quite highly. At the end of 2003, I took a year out of work.

Paul: Ah I didn’t know… Yes I did know that.

Ian:While I was travelling around the world I made it my business to try and call in on people that I knew from the web. You know, you’ve part of the world so I’ll pop in and say hello. That’s what I did with the SitePoint guys. I was in Melbourne for a while so I thought I’d pop in and say hello. So we did lunch and I was having a chat with one of the guys there who was saying “Oh, have you ever thought of writing an accessibility book?” and I was like “Oh, I don’t know. I don’t know if I’ve got a book in me. It seems like a lot of work.” But not long after that I was asked if I’d like to do some tech editing and I thought “Yeah OK, I’ll do that” and I actually did it while I was still travelling around Australia in the van. So that was actually quite easy to do, wasn’t too bad at all. And then what happened is that when I got back to the UK I was asked “Do you want to write a book?” and this is the beginners book you have reviewed in the past on the show. So it’s kind of been an escalation from there really. So there was that book and I did a couple of bits and pieces for APress and then not so long ago I got the call back from SitePoint saying “Do you want to do this HTML reference?”. At the time I thought “I don’t know. I’m not sure. Does the world need another HTML reference?”. But I kind of thought that when I did the first book, and that’s done pretty well and I’ve had some really good feedback, so I though “Well, let’s think about this. Maybe it’s worth doing”. In my mind I convinced myself that this wouldn’t be a difficult thing to write…

Paul: *Laughs knowingly*

Ian:See you think you know HTML. You think you know it because you use it everyday and I though “Well how difficult can it be?” compared to say the Javascript reference they were writing. There’s a million and one ways you can approach something with Javascript where as with HTML there’s a finite number of elements or tags, whichever you prefer to use, that you can use in any given scenario so you think it’s pretty straight forward isn’t it. That’s what I thought anyway and I was also thinking in terms of browser compatibility the bigger problems come from the CSS you put over the top. That’s where you get all the quirks happening. So I thought to my mind, “Yeah this isn’t going to be too difficult a job”. But I think I underestimated it.

Paul:Is that not always the way when it comes to any kind of project like this that it always ends up being loads bigger than you thought it was going to be.

Ian:I think it actually surprised me how much more work there was involved. I don’t know if you did that little test a little while ago that was one of those things everyone was sending around, how many HTML elements can you do in 2 minutes or something. Everyone was having a go at it. You think you know quite a lot but then you realise there’s so many more you didn’t know and there was so many that I vaguely remember and but probably would never use. That was the funny thing, writing about these elements where I think “Well, that’s that one done. Never going to use and nobody’s every going to read it either but it’s got to be covered.

Paul:So with the CSS reference guide that they produced they have now turned it into a book. Are they intending to do the same with this? Is that the plan?

Ian:Absolutely. And that was the other strange thing I thought “This is kind of a strange business model. They are going to put it on-line for free but also gonna do a book. Will people actually buy a book?” But I’m sure they don’t do these things without doing the research first. I’m pretty sure they’ve got a good idea on what they’re doing with this. I never went into it thinking I’m going to make millions out of this because it’s never going to happen. Anyone who’s written a book, yourself included…

Paul:I’m still witting so I’m still in that naive state of thinking “Yeah, it’s going to sell hundreds of thousands of copies and millions of copies and I’m going to be rich”. So don’t shatter it.

Ian: Sorry Paul.

Paul: Just say how much money I’m going to make.

Ian: Oh yeah, you’re going to be rolling on a bed of money. You’re not going to know what to do with the stuff.

Paul: Excellent. Wonderful. Great. I’m looking forward to that. *laughs* So basically it’s gonna turn into a book before too long.

Ian: Ah yes.

Paul:You mention that there were some things in there that you thought “I’ve written this but I’m never going to use this and probably no one else is as well”. I noticed there were a couple of sections in there dedicated to depreciated HTML tags and stuff that people actually shouldn’t use. That’s a bit of an unusual decision isn’t it – to put in stuff people that people actually shouldn’t be using. Why take that route?

Ian:Well the thing is because it’s a reference you have to include everything. So everything that is in the W3C approved recommendation, everything in there is included. Even if it’s as much use as a chocolate teapot it has to go in there. And that includes the deprecated tags but there’s also things that are included such as blink or bgsound or marquee that were never actually defined in any standard but because they have almost universal support, not all of them have the same level of support, but basically there’s a lot of elements out there that were never defined in the standard but are well supported. So the decision is this has to go in there, we can’t deny it’s existence. It may not be something that anyone would want to use but as it’s a reference book we should include it. There were some that we didn’t include that I can’t remember off the top of my head what they would be. Things that were perhaps defined in Netscape 4 and just are not supported in anything and given that Netscape 4 is dead and gone a long time ago, there were some things that didn’t make it in. But the reason for having a second index that said “Here are some elements that you shouldn’t use or should avoid or these are deprecated ones” was really a case of saying that we’ve got this index of all these things and I don’t want anyone to think that because it’s in the index that it’s necessarily approved. So I wanted to kind of pull them out and say “It’s in the reference but actually we don’t really you to use those.”

Paul:Which are the worse culprits? Which are the ones you think that people are using a lot and they really, really shouldn’t be? Your chance now to lecture people and preach to them about their bad HTML.

Ian:Well strangely enough I don’t actually see a lot of them used now. I think probably the most common is people using the bold and italics, the <b> and the <i> tags, when really they should be using strong and em. Then again the b and i tags do have their place but they are usually misused. Thankfully the kind if things that I wouldn’t want people to use, you don’t tend to see much nowadays anyway like the blink, marquee or bgsound that was always a pet hate of mine. You’d visit a site and then suddenly you’d get some Indonesian Gamelan music blaring through that was set in a bgsound. I was kind of thinking it’s good that this is gone but if you go to any page on MySpace and they’re replaced it with something that has got sound in Flash. So yeah, that may have gone but they have replaced it with something equally annoying.

Paul:Now there’s a little question there. You say that bold and italic have got that place. How is it supposed to be used? Educate me as to the proper use of those two.

Ian:Well if you what you are actually marking up something that describes something typographical. So if you are putting the b tag around something because you are describing it as bold. So it’s that kind of context. I use in the examples on the reference it’s like I’m describing a sign of something like that. So there are reasons when you use it but generally speaking when people are using it is when you want emphasis or strong emphasis. In most cases what I would end up using would be strong and em because that is what I’m normally trying to do, emphasis.

Paul:What other kind of bad practice have you been seeing? What are the things, not just with specific tags but general bad practice, that are your pet peeves when it comes to HTML? What things are people doing a lot that just piss you off?

Ian:Like I said earlier, because of the kind of sites that I tend to look at I don’t actually stumble across too many coding sins because that’s kind of the circles I’m in I suppose. The funniest thing is when you see your own mark-up from years ago and I’ve just had to do this for something at work where I’ve taken on a reworking of something written 10 years ago and I’m like “Oh my God. This is awful”. It had been duplicated 5 times instead of one file with the logic inside that one file. So it was like “Hang on. I have to do this five times over?”. But it was nice to go back and see something that was old and table layout and all the rest of it and give it a good clean up in the process. So yeah, it’s funny when you look at your own mark-up and think “I’ve moved on”.

Paul:Even when you just look at what you learned from when you started doing standards to when you’re doing it now. I look back on the early standards work I did and it’s all div-tastic. There’s just divs everywhere.

Ian: Oh yeah. But there’s no meaning to the document as such.

Paul: Yeah. No meaning whatsoever. It used CSS so it must be alright *laughs* Which obviously doesn’t quite work does it in reality but there you go.

Ian:I guess the kind of thing that I really see a lot is just general sloppiness. People not closing tags when they’ve said they are using XHTML or unsymmetrical opening and closing. Those kind of things. Probably the first thing is missing alt attributes for images which is such an easy thing to put right but I see it so often. I guess probably the worse offences come from the kind of people who probably have never looked at a reference and may never look at a reference so I don’t know that this would solve the problems. And by that what I mean is people who would never actually get their hands dirty in the code. They’ll be using things like Frontpage, Word. You know – save as HTML in Word. You just want to beat them over the head with a large reference book. I don’t know if those kind of people are beyond hope. Maybe we we’ll be there at one point who knows. Maybe they are not beyond saving.

Paul: Nobody is beyond hope.

Ian:Funnily enough, I was saying about the Frontpage thing. It’s quite shocking I was looking at the program for a local college evening course and out of curiosity I flicked through to the computing section to see if they were doing any web design courses and
yay, there were. How To Build A Website and it was a seven week course, how to build a website using Frontpage. And it was like head slap, what are they doing?

Paul: Ah. That’s amazing that people are still doing that.

Ian: Shocking. So yeah. It’s not going to go away in the short term still.

Paul:When you were going through this reference, putting it together, was there a tag that you came across that you thought “Why don’t I use this more often? That’s an underused tag.” For example, I’ve just suddenly started using definition lists more.

Ian: Paul, you’ve taken the words right out of my mouth. That’s exactly what I was going to say.

Paul: There you go then.

Ian:That’s exactly one of those things that I don’t tend to use an awful lot myself but there are certainly uses for it. When we did this quiz thing that we were talking about earlier, I did with some people at first. So few of them had actually heard of definition lists. It was like “What is this markup of which you speak? What is this dl? What is this dd?” They had never heard of it and it surprises me but, I don’t know, maybe it shouldn’t be a surprise. You see list items used absolutely everywhere but it seems to be a bit of mystery to people. So that would be one that people could use more often and I’d certainly like to see people use them more often.

Paul:Umm. I’ve found it really useful. It’s surprisingly how many of the things, for example a news story where you have a title and then the description underneath the news story. There’s loads of examples like that where there are these paired matchings that suit a definition list so well. It’s a cool tag, if a HTML tag is capable of being cool which is probably doubtful.

Ian:There are some others as well which I would certainly like to see people use more often and they’re not ones that I don’t use, I use them all the time. Things like the accessibility specific type ones like for forms: label, fieldset and legend. I’d like to see them used more often. To some people this is something that they still don’t get. Of course in general, using the proper semantic markup. As you’ve already mentioned sites that are div-tastic. Stick a couple of headings in there and some unordered lists and already you’re starting to give your document more structure.

Paul:So talking about semantics and all that stuff, I noticed that you have a section dedicated to Microformats. Microformats aren’t really part of the W3C specification so why did you decide to include them?

Ian:Because it’s really cool. Yeah, it’s really cool stuff Paul. No, the reason really is because in the process of drawing up the table of contents, looking at all the elements we needed to cover, it became clear that there are certain things that HTML can’t do. Obviously this is not a revelation otherwise Microformats wouldn’t have come about anyway. But it felt right to put it in because essentially although Microformats are still developing they do go through a rigid process of being documented, discuss, ratified and all the kind of thing. So while it isn’t W3C recommendation it feels like it’s controlled. Also it doesn’t really do any harm. You can add this in over the top of HTML. You’re still using plain old HTML but adding that extra richness in without necessarily doing any harm. So it felt like something safe to put in. I guess the only problem with putting something like this in, at least for the printed version of the book, is that as they are developing it can get out of date. At least with the on-line version as things get added and they are adopted, that can easily be added in. It felt like a useful thing to do.

Paul:And it’s good to give Microformats higher profile because I think there are still a lot of people that are unaware of them. So it’s good.

Ian:I was gonna say it is by no means a complete Microformats reference. It really is still a fairly entry level introduction. I mean there are books out there specifically for Microformats. If someone really wants to learn more they’d do better to pick up a book or go to Microformats.org to learn more. Hopefully it would give some exposure to it that perhaps wouldn’t otherwise. And the other good thing about it is because the reference on SitePoint is very, very searchable hopefully by the time that Google’s indexed it you will find people that stumble across that wouldn’t have done otherwise and just from doing a search from inside the site itself. There’s a chance that people might learn about Microformats when they might not have otherwise of done. But we’ll see.

Paul:Bearing in mind that a lot of people listening to this podcast are web designers and you know, they are sitting there going “Well I know HTML”, like we were saying at the beginning that you have this perception that is something you know back to front. So just to finish up with is there a kind of one area that you really want to challenge people over or one piece of good practice that you’d like to push people on where they’re not as hot as they should be.

Ian:Hmmm… That’s a tricky one. I’m obviously aware that the audience of the podcast know a fair amount already. I guess you do have some people that are relative beginners so I’m not entirely sure the advice is appropriate for the audience. But the kind of advice that I would always give is that, and maybe I’m teaching people to suck eggs here, but really it’s so much more useful if you can learn from the ground up. You know, learn the code using really simple tools. I use Dreamweaver a lot, an awful lot, but that’s because I know how Dreamweaver is going to handle the markup. I know if there any little forbals, what it’s gonna do. So it’s very quick for me to use that without causing any real damage. But I wouldn’t really recommend that to a beginner. I’d say learn the basics. Walk before you run. Obviously things like I mentioned earlier – Word and Frontpage. Never, ever dream of using anything like that because they just do an awful, shocking job of it. In essence, HTML is not difficult to get to grips with. What I tend to find is a problem is what you then layer over the top of it. It’s the browser incompatibilities with CSS and obviously with Javascript it can be as simple or as complex as you like. HTML is not massively difficult to learn but it’s still useful to learn from the ground u
p and not let a tool do it for you. I think that’ll be my advice.

Paul:On one hand it’s not difficult to learn but on the other hand I think it’s quite difficult to master, if that makes sense. It takes quite a long time…

Ian:You’re talking about the pedantic kind of… When you start to argue about the fine details about which element is appropriate for this usage and you can get into some debates over some things, yeah.

Paul:I liked the way you referred to it as pedantic. Do you think we’ve gone a little bit overboard with our obsession with HTML and marking up everything correctly?

Ian:I don’t know. I think it’s a good thing that people discuss and try and squeeze the most out of it. But there are some grey areas and you do sometimes think it is a bit limited, hence things like Microformats adding the richness on top of it. But I don’t know. It’s usually good natured, put it that way.

Paul:Oh OK. I thought I was going to get you to say something really controversial that would get you flamed but I didn’t quite manage to…

Ian: What luck “HTML SUCKS!”?

Paul: Yeah like “Just use Frontpage. It’ll be fine man.”

Ian: Yeah something like that.

Paul:OK. Thank you so much for coming on the show and where can people check this out if they want to try out this reference for themselves?

Ian: The HTML reference is at http://reference.sitepoint.com/html and if you want the CSS reference, replace /HTML with /CSS. And I understand that the Javascript reference written by James Edwards aka BrotherCake is still ongoing. So at some part there will be a third part to this reference. So we’ll have all three layers.

Paul:And I have to say I’ve been impressed with what I’ve seen so far. I’ve actually been using the HTML reference believe it or not. In fact I used it yesterday to check something. I can highly recommend it. Much better than that crappy old W3Schools so you can ignore that from now on and use that instead. OK, thanks very much Ian. That was really good and I look forward to seeing you soon.

Ian: OK. Thank you very much Paul.

Thanks to Lee Theobald for transcribing this interview.

Back to top

Listeners feedback:

Can you trust developers?

JW writes: I have been on the buying side of both fixed and hourly projects with lackluster results lately. The process can be quite frustrating for me with some of the following bubbling to the top:

  • Inaccurate estimates both in cost and time
  • A lack of commitment to carry out all agreed items within a scope when it takes longer to accomplish than originally planned.
  • The need to ask for more money when the scope doesn’t change.

Which leaves me asking “How much is the developers “word” worth?”

JW’s email goes on to talk about the differences between fixed price and time and material work. I believe that this is where the heart of the problem lies.

I know many within the web design industry will disagree with me but I advise in my upcoming book to only work with developers willing to agree to a fix price contract.

There are always exceptions, such as when you have found a developer you know and trust. In such circumstances I suggest the complete opposite. However, generally speaking I don’t believe it should be the client who takes the risk for projects overrunning. Obviously, if the scope is changed by the client then additional work should be priced and agreed (once again on a fixed price contract).

Make sure the scope is clearly defined up front even if it delays the project starting. The tendency is to jump right into development work as soon as possible, especially when deadlines are tight. However, this could cause problems later.

Unfortunately, occasionally you will encounter a developer who agrees to fixed price project only to move the goal posts part way through the project. By this stage it is difficult to walk away. How then do you avoid ending up with this kind of developer?

There are two approaches that work well. First, before engaging a new developer ask to speak with a selection of their existing clients. If possible, contact clients independently of the developer. That way you won’t just get fed a tame client who is bound to say nice things.

Second, for larger projects consider separating off some of the initial work into a smaller self contained project. That way you can ‘try the agency out’ before committing to a larger project with a greater degree of risk.

In answer to the original question, I am sad to say you cannot trust a developers word. You have to put safe guards in place and mitigate the risk.

The life cycle of a website

Richard asks: What is the life cycle of the websites we develop as web designers? Do you see it as a short term year / year and a half, or a longer term two / three years? What kind of time period should we expect to wait before being contacted by a client about a potential redesign?

I would like to challenge two presumptions you make in your question. First, you are presuming sites should be redesigned periodically. Second, you suggest that the client has to come to you. In my opinion, neither are ideal scenarios.

I have written before about how, ideally websites should evolve rather than going through a continual cycle of redesign. I do however accept that this decision lies with the client and not yourself. Nevertheless I would encourage you to work hard at persuading the client of the benefits this approach brings. This serves both your interests as a web designer and those of your client. Throwing out all previous work on a site every couple of years is lunacy and totally unnecessary.

I also have to say that you are doing your clients a disservice by simply waiting for them to contact you. It is your role to continually suggest ideas on how their site could be improved based on emerging innovations.

We offer our clients the opportunity to regularly meet with us (free of charge) to discuss their site and where they should go next. This encourages them to think in terms of evolving their sites. It also ensures the sites do not stagnate and die.

Not that this approach is completely altruistic. By speaking with our
clients regularly we ensure they don’t forget us and increase the likelihood of repeat business.

Do we always take this approach? No. Some clients don’t want us continually pestering them. Some simply cannot afford to move their site forward. In this case we take a more passive role, encouraging them to read this blog or just ‘keep in touch’. However, this is the exception not the rule.

So to answer the original question; I would argue that the life cycle of a website should ideally be indefinite, as it evolves and changes overtime. This happens through a partnership between agency and client.

Back to top

121. Coda

Posted in Classic shows on by Paul Boag

In this weeks show we discuss 5 quick fixes to accessibility, and we review the mac code editor Coda.

Download this show.

Launch our podcast player

Watch the behind the scenes video

News and events

Skipping Photoshop

The biggest news this week is a post from 37Signals entitled ‘Why we skip Photoshop‘. The article outlines some excellent reasons why they choose to bypass designing in Photoshop, instead going straight from sketches to HTML/CSS. Reasons include…

  • Mock-ups are not interactive
  • Photoshop draws you into the details too early
  • Text on Photoshop is not like text on the web
  • Photoshop is not productive
  • Photoshop does not aid collaboration
  • Photoshop is too complex

They are all valid points. However, although I accept this is right for 37Signals, it is not right for Headscape. Our view is echoed completely by the response of Jeff Croft at Blue Favor. He argued…

  • 37Signals are working with an established visual aesthetic
  • That 37Signals aesthetic is simple and so is better suited to pure HTML/CSS
  • That 37Signals do not work with clients
  • That working in HTML/CSS can lead to constrained design.

That said, the post has made me consider experimenting occasionally with the approach. For me that made it worth reading.

It is a great discussion and I am really glad Jason at 37Signals brought it up. It has certainly created a lively debate including posts from Jon Hicks and Mark Boulton.

Web Designers should do their own HTML/CSS

But we haven’t finished with 37Signals yet. They have posted a second blog entry this week entitled ‘Web designers should do their own HTML/CSS‘. The title is fairly self explanatory and they put forward a good argument as to why designers should never produce a design and then simply hand it off to ‘code monkeys’ who make it work.

At the end of the article they write…

We simply don’t consider designers who don’t get their hands dirty with the materials relevant to the kind of work we do.

If you’re a designer working with the web who still doesn’t do your own implementation, I strongly recommend that you pick up the skills to do so.

Whether you agree with 37Signals or not, the message is clear: You will struggle to get a job if you do not know how to code pages as well as design them.

We would certainly never hire somebody unless they know HTML/CSS just as well as they know Photoshop. The nature of the web means that an understanding of the medium is crucial to creating a great user experience.

Beyond CAPTCHA

I hate SPAM. I hate it with a passion. I particularly hate comment/forum SPAM because it not only inconveniences me but also affects my users.

One common approach to the problem is CAPTCHA. CAPTCHA presents the users with a distorted word(s) that they have to type in before they can comment.

An example of CAPTCHA in action

Although in principle CAPTCHA sounds great it does have a number of weaknesses…

  • It creates accessibility problems
  • It are hard for normal users to complete
  • It can be beaten by spammers
  • It make SPAM the users problem

In short, CAPTCHA doesn’t work. So what is the alternative? Well, that is what James Edward (AKA Brothercake) explores in a post on Sitepoint entitled ‘Beyond CAPTCHA‘.

He looks at server side solutions, services like Akismet and honeytrap approaches. He also looks at OpenID and other forms of authentication.

The conclusion is that there is no perfect solution. However, he argues we need to stop making this the problem of users and take on the responsibility ourselves.

I can certainly see his position and generally speaking I agree. However, when you are faced with limited time and budget it can be necessary to cut corners. Personally, I cannot stand CAPTCHA and I regularly fail to complete them first time. However, I have no problem completing a basic question such as found on the boagworld website.

Read the article and make up your own mind. At the very least it will offer you some alternatives to CAPTCHA that can be implemented quickly and easily.

Website Owner’s Manual

Our last news story is a little bit of news about the book I have been working on. For a start it has a title; ‘The website owners manual‘. However, the big news is that you can start reading it and contributing to the final version.

Back to top

Feature: Quick Fix Accessibility

Complying with accessibility guidelines can seem like a massive undertaking. However, addressing 5 simple problems can make a huge difference to your sites accessibility. We discuss these in this weeks feature

Back to top

Review: Coda

Find out why I am seriously considering abandoning the code editor I have been using for over a decade in favour of Coda for the mac in this weeks review.

Back to top

Listeners feedback:

Team working environment

Gareth writes: I have been “promoted” from a support desk position for an Oracle based financial system to the company’s single web designer. We are not by trade a dedicated web design firm and as such i am having to develop procedures and polices by myself. I have been reasonably successful in this thanks in large part to your podcast, which has in turn led me to blogs and websites such as A List Apart, Sitepoint, Headscape (obvious one that) and many more that have also helped me.

Due to the sheer volume of work that is coming in this year we have found ourselves needing to recruit an additional web designer. At the moment i have all of my work saved on my laptop and all my tasks and appointnments stored in my Outlook.

What tips can you give me in relation to creating a centralised working environment that can be used by both myself and this new person as well managing our work loads. What do Headscape do? I should probably point out that we will be office based in the sane room rather than working from home.

Why is it that Ryan our producer, keeps picking questions he knows I am not an expert on. I am a front end interface guy. What do I know about this kind of thing! Also we primarily work remotely so have a different setup anyway.

That said, I am willing to give anything a go and ignorance has never stopped me before.

Okay, if you are sitting in the same office communication is not going to be the primary problem.
However, you still may want to take a look at Basecamp. Its a great way of organising team working.

The main problems will come in the form of file sharing, backup and overwriting each others work. One thing you might want to consider is a version control system like Subversion. At Headscape we use something called Source Anywhere however this is just personal preference. These systems allow you to…

  • check out files, preventing others from overwriting them,
  • rollback to previous versions of a file,
  • branch files, allowing multiple versions of the same file.

However, for some this might be an over the top solution. The biggest danger is overwriting files. There are a number of code editors which prevent this including Dreamweaver and Coda. This just leaves the problem of shared storage and backup. You could solve these problems separately. However, personally I like the look of Drobo. Its not that cheap ($499 plus the drives) but it provides an incredibly expandable solution that minimises the problem of data loss.

No doubt my ignorance is showing in this question so if you have better advice please post it on the show notes.

Internal Search

Stephanie writes: I have a question regarding internal site search. I am wondering what types of solutions there might be for enabling a site search when one does not have a development team to turn to. All I can come up with is Google custom search and it has some drawbacks (ad serving in the free edition and blog posts do not get indexed right away).

Love the new site!

So you want to add search to your site eh? If you’re using a popular engine such as MovableType, then there will be a built in search, so let’s assume you’re not. If you’ve just built your site using HTML, or aren’t happy with the results of your CMS’s out-of-the-box search, you still have options.

If PHP is your game, you can install a spider on your server, such as Sphider. This will index your site and provide a very customisable solution, that doesn’t send queries off to a third party server. If you’re looking after a large site, with huge numbers of pages and documents to index, you might consider a program called SearchBlox. SearchBlox is expensive, but powerful. It runs as a java based web app on your server, with many fine tuning features that will keep even the most fastidious of clients happy.

If it’s a free, third party service you’re after then you might consider Atomz or Google. Atomz is easy to setup, free and customisable but does include text based ads, similar to Google. The indexing schedule is regular, but only weekly. Google is an established name in search, but also has the downside of irregular indexing and ad supported results. It is of course possible to spend a little extra money to remove these, with Google Site Search

There is however an interesting alternative service called JRank. JRank don’t stuff adverts into the results, they only require that you provide a link to their website on the page that you set as the index for crawling. They also have a REST API, so without much work you can integrate the results in your website, as the PHP code below demonstrates:

<?php
$jrank = file_get_contents('http://www.jrank.org/api/search/v2.xml?key=[API key]&q=[query]');
$xml = new SimpleXMLElement($jrank);
$result = $xml->xpath('//entries/entry');
while(list( , $node) = each($result)) {
echo '<h3>' . $node->title . '</h3>';
echo '<p>' . $node->content . '</p>';
echo '<a href=”' . $node->url . '”>' . $node->url . '</a>';
}
?>

An interesting point in the question was that Google doesn’t index blog posts right away. In my experience, search is used to find old articles or those that can’t easily be found by tags or menus. Newer articles should be easy to find from the home-page of the site, particularly if it is a blog site. If powerful search is required, then you’re going have to put up with the ads, or fork out for a bespoke solution.

Back to top

117. Friendly

Posted in Classic shows on by Paul Boag

On this week’s show, we review woopra, a google analytics alternative and we explore why friendly urls are so important and what tools are out there to help you set them up.

Play

Podcast: Download (22.4MB)

Download this show.

Launch our podcast player

Information

Fuel Conference

Fuel is a one-day conference for entrepreneurs and marketers who want to make their companies, services and products truly remarkable. The conference is on the 13th June 2008 and tickets cost £195 inc VAT however for lucky boagworld listeners if you enter the promo code boagworld at the checkout you will get a £25 discount!

Back to top

News and events

The devil is in the detail

We kick off the news with three stories that focus on the detail of web design. So much is said about design, usability, accessibility and other broad subjects. However, less is written about the small things. It is here that a good site becomes an excellent site.

The first is a post on the list apart website entitled Zebra Striping: Does it really help?(1). Zebra striping refers to alternating colours on a table of data. It is a small thing, but a lot of us do it thinking it helps the readability of the data. But does it really? This post takes that theory and puts it to the test. The results are inconclusive but it is an interesting read anyway.

The second story is about a new book released on the topic of web forms. It’s called Web Form Design(2) and as the title suggests looks at the much under-represented subject of creating a great looking, usable form.

As I have said before forms make or break some of the most crucial elements of a website: checkout, registration, data input, and any task requiring information entry. This looks like an excellent read and I highly recommend you check it out. I will be.

The final post that focuses on the detail of design is looks at pagination(3). It is a tutorial that explains how to code pagination semantically. It then demonstrates how you can use CSS to recreate the appearance of pagination on sites like digg or flickr. It is an easy read and ideal for beginners.

Review crazy

The next theme of the week is reviews. In particular Smashing Magazine have gone review crazy in two excellent (if somewhat excessive) posts.

The first reviews 35 useful code editors(4). Of course, we can write our code with a text editor but that wouldn’t make for a very interesting post! Also we like those advanced features like auto complete, formatting and debugging tools.

If like me you have been using the same coding tool for years, this article is worth a read. Things have certainly moved on and there is no shortage of choice out there. It might be time to change.

The second review from Smashing Magazine only manages 25 applications. This time it is WYSIWYG editors(5). I guess this compliments the previous post very well. However, generally speaking I would warn against producing sites using WYSIWYG editors. That said they do have their place. They are useful to give to clients who want to maintain their own sites. They are also good for posting to blogs or other sites where the styling is already set.

It has to be said that I personally code in Dreamweaver, which has a WYSIWYG component. I have been known to use it to find a particular part of the code I want to edit.

A balanced look at flash

Our final news item of the day is a post by Veerle on her blog entitled Does Flash irks me?(6). It is an excellent opinion piece that clearly lays out her feelings about flash. She explains how she decides whether to use it and dispels some of the misconceptions about the technology.

Her post is very timely coming as it does a week after flash goes open source. It is balanced and her attitude very much mirrors my own (therefore it must be right!). If you view flash as the ultimate evil or alternatively refuse to code in anything else, read this post. It will provide a healthy dose of realism.

Back to top

Feature: Friendly web addresses

When redesigning boagworld considerable time was spent formatting the sites’ web addresses. Find out why so much time was taken and an introduction to the tools I used in this weeks feature

Back to top

Review: woopra

When it comes to website statistics Google Analytics dominates most of our thinking. However, there are some impressive alternatives. One I would like to introduce to you is woopra. I give my thoughts to woopra in this weeks review

Back to top

Listeners feedback:

Creating consistant colors

Anna Joe Writes: I know that the colour of a website will look a little different on every monitor, but is there a profile setting that you use as an ‘average’ setting?

Since I work on Mac with a Mac monitor, I’m afraid most people will see something radically different than me. I have read that Mac defaults are brighter than Windows. I’m using a lot of dark colours, so I am concerned about the site appearing too dark on the majority of computers.

I have a list of colour settings provided on my computer… only one seems to have a Windows-related profile. It’s called ‘Nikon WinMonitor 4.0.0.3000′

Do you have any suggestions regarding this issue?"

I have to confess Anna, this was a subject I knew nothing about before your question. The way that I got around the problem was to look at any design I produced on as many different monitors as possible. To be honest, even after my research I would advise this as the best approach.

View your site on a TFT and an old CRT monitor. Also check on laptops and under different operating systems.

However, based on a bit of reading it would appear that the problem is to do with Gamma settings. Macs by default have gamma correction built in while PCs do not. This causes images (especially photographic images) which look good on a Macintosh monitor to appear too dark on a PC.

Fortunately there is a tool that allows us Mac users to experience the horror of the PC world. It’s called gamma toogle(7) and can be downloaded for free.

If you don’t have access to multiple machines for testing this would be the next best thing.

Setting up an ecommerce site

Paul East Writes: My girlfriend has come up with an sales idea that would require a simple store front application with the ability to take credit and debit card payments online.

Have you any advice on where to start or any recommendations on store front applications?

We’d like to try and keep start up costs low (we’d like to avoid paying a web designer, sorry!) and avoid eBay type stores if possible for that more professional look.

We’ve done a little investigation on merchant accounts but could do with a good steer on the rest!

Again this is not a subject I k
now a huge amount about. Most of the ecommerce sites I work on are considerably larger. However, hopefully I will be able to point you in the right direction.

First, for the best advice when it comes to setting up ecommerce sites big or small I would highly recommend the ebiz video podcast(8). These guys really know their stuff and in fact we had them on show 55 to talk about ecommerce basics.

Second, in the past I have come across two simple shopping cart systems that impressed me. The first is FatFreeCart(9). This simple system can be integrated easily into an existing site. If you are only selling one or two items this is perfect. The alternative is shopify10. This is a little more sophisticated but incredibly simple to setup and run.

Neither of the questions today are subjects I know much about and I am guessing there are people groaning at my advice. If that is the case, get in touch and we will put you on the show.

Back to top

115. sxsw

Posted in Classic shows on by Paul Boag

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

Download this show.

Launch our podcast player

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

News and events

Microsoft launches beta of Internet Explorer 8

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

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

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

Designers agnst

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

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

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

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

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

Usability challenges associated with web applications

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

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

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

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

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

Back to top

Feature: Lessons learnt SXSW

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

Back to top

Interview: Garrett Dimon on form design

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

Garrett: Pretty good.

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

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

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

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

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

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

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

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

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

Garrett: Yeah, comment forms and…

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

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

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

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

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

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

Paul: How bizarre.

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

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

Garrett: Yeah absolutely.

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

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

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

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

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

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

Paul: So where can people find out about him?

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

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

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

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

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

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

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

Paul: (lauging) So many out there.

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

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

Garrett: Yeah likewise.

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

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

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

Garrett: Yup, exactly.

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

Garrett: Sounds good.

Thanks to Lee Theobald for doing the transcription

Back to top

Listeners feedback:

Finding usability test subjects

Our audio question comes from Clare who asks…

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

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

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

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

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

Accessible tables

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

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

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

Day AM PM
Monday Meeting Travelling
Tuesday Free time Meeting

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

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

However, if marked up correctly it suddenly makes sense…

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

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

113. Hiring

Posted in Classic shows on by Paul Boag

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

Play

Podcast: Download (29.9MB)

Download this show.

Launch our podcast player

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

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

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

News and events

Highly extensible CSS

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

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

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

Video tools

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

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

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

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

Microformat boost

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

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

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

Back to top

Feature: Hiring new staff

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

Back to top

Expert interview: Christian Heilmann on common Javascript mistakes

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

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

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

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

Paul: Um hum…

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

Paul: Yeah…

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

Paul: Um hum…

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

Paul: Yeah.

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

Paul: Umm…

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

Paul: Yeah.

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

Paul: Mmm…

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

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

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

Paul: Um hum…

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

Paul: Yeah.

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

Paul: Mmm hmm…

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

Paul: Mmm…

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

Paul: Mmm…

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

Paul: Mmm…

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

Paul: Mmm…

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

Paul: Mmm…

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

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

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

Paul: (Laughs)

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

Paul: Mmm.

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

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

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

Paul: Mmm…

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

Paul: (Laughs)

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

Paul: Mmm.

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

Paul: Okay.

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

Paul: Oh okay.

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

Paul: Mmm.

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

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

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

Paul: Mmm…

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

Paul: Mmm.

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

Paul: Yeah.

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

Paul: (Laughs)

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

Paul: Um huh.

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

Paul: Yeah.

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

Paul: (Laughs)

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

Paul: Yeah.

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

Paul: Mmm.

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

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

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

Paul: Mmm.

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

Paul: Mmm.

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

Paul: Right.

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

Paul: Mmm.

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

Paul: Yeah.

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

Paul: Mmm hum.

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

Paul: Yeah.

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

Paul: Umm hmm.

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

Paul: Mmm.

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

Paul: (Laughs) …or drinking…

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

Paul: Mmm.

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

Paul: Mmm.

Christian: Otherwise you start preaching to the choir.

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

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

Paul: Okay.

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

Paul: What do you mean by that?

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

Paul: Okay yeah.

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

Paul: Yeah.

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

Paul: Mmm hum.

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

Paul: (Laughs)

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

Paul: (Laughs)

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

Paul: Yeah.

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

Paul: (Laughs)

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

Paul: Yeah.

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

Paul: Yeah.

Christian: And that’s never the case.

Paul: Hmmm.

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

Paul: Mmm hmm.

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

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

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

Paul: Mmm.

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

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

Christian: Yeah.

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

Christian: See you soon. Bye.

Back to top

Listeners email:

Rolling out new features

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

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

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

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

Here’s the solution I had planned:

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

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

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

Content management and CSS

Our second listener contribution is a question from Adrian…

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

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

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

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

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

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

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

HTML snippets

Posted in Development on by Paul Boag

If you are part of a web design team or skip constantly between projects, then you might want to consider an alternative approach to writing your HTML.

At Headscape efficiency is king. If you are efficient, you increase profit margins and keep prices competitive. You can only charge as much as the market allows. If you want to increase your profits you need to complete projects faster, while avoiding lowering quality.

As part of our efficiency drive we identified 4 problems…

  • Designers have to work with each others markup. We all code in different way and this creates a learning curve when a project gets passed between designers.
  • Integration HTML markup into server side applications was time consuming. Because designers coded in a different way and change their markup for each project, it was time consuming to apply that code to web applications like our in-house content management system.
  • Designers were constantly reinventing the wheel. Each project was built from the ground up with little reuse of markup across projects.
  • It was confusing switching between multiple projects. In order to ensure the most efficient use of time, designers are expected to work on several projects simultaneously. Unfortunately, switching between project is confusing because each had different markup.

We required some way to standardise tour markup.

Templating doesn’t work

At first, we produced templates for the different types of pages. For example, we had news listing, text and FAQ templates. Although this worked, they were not very flexible. As soon as the content or functionality began to deviate from the norm the templates had to be heavily customised. This undermined the benefits they provided. They also didn’t allow flexibility of design. Although content and design should be separate, it rarely works that way. Sometimes content needs to be marked up up in a particular order. Other times extra divs are required. The templates didn’t accommodate either scenario.

We needed a more flexible approach.

Using snippets

The solution was HTML snippets. Content such as news listings, forms, navigation and FAQs appear in a vast majority of websites we build. By coding these in a consistent way each time they appear, we solve all of the efficiency problems mentioned above.

Take for example news listings. Most news listings look the same. They have…

  • Title
  • date
  • link
  • description
  • and sometimes an image

Because of this consistency you can code in the same way each time. Content will change, each will have its own unique id and sometimes an element might be dropped (e.g. the date or image). However, fundamentally the snippet is consistent

This consistency allows…

  • A designer picking up the code to instantly understand what is happening.
  • A developer to quickly integrate it with server side code because the integration is consistent every time.
  • Pages to be built faster because you are dropping in pre-generated markup

In affect all the designer has to do is build an HTML framework. This consists of the overall containers (main content, secondary content etc.) He then drop snippets into that framework in whatever order he requires.

However, the benefits don’t stop there. You can also associate CSS with each snippet of HTML.

CSS fragments

If your HTML snippets are consistent, you can also build up a library of CSS fragments to support them. Take for example our news listing. Not only does it often contain the same content it is also often laid out in the same way. The image sits to the left while title, date and description sits next to it on the right. Because we know what the markup looks like, we can create this layout as a CSS fragment that can be dropped in whenever this HTML snippet is used.

We are not limited to a single CSS fragment per HTML snippet. Over time you can build up a variety of different CSS layouts for each snippet that can be used as the design dictates.

This approach provides a huge productivity benefit as the HTML and CSS can be built up in a ‘pick and mix’ fashion. However, you can also take the principle one step further and apply it to Javascript.

JavaScript functions

Each HTML snippet can have associated Javascript functions. These can be dropped in just like CSS fragments. These functions carry out common behaviour associated with that HTML snippet.

Take, for example, a FAQ snippet. A common behaviour with this snippet is to only display the answer when a question is clicked. Because we have consistent code in the snippet, it is easy to build a function that works with it and can be dropped in as required. Where possible keep your functions generic and not tied to a particular HTML snippet. However, where that cannot be done, we have standard HTML that allows us to reuse functions across projects with no editing.

Conclusions

In many ways this approach is a cross between microformats and frameworks and so in itself is not groundbreaking. However, from an efficiency standpoint, the impact is overwhelming. Without a doubt it will speed up development times and allow you to turn around projects quicker.

106. Back to work blues

Posted in Classic shows on by Paul Boag

On this week’s show: Paul and Marcus discuss common mistakes when creating your sites structure and Rachel Andrews shares her experiences of getting into web design.

Play

Podcast: Download (29.5MB)

Download this show.

Launch our podcast player

News and events | Common mistakes of site structure | Rachel Andrews on building your web design career | Listener emails

Just a quick little request before we kick off today’s show. I need to get some more moo cards for the boagworld podcast (I am too tight to get proper business cards). Anyway I am having trouble with what to put on the cards. I was going to put a nice image on the cards but when I thought about it I couldn’t think of anything appropriate. In the end I decided to include tiny snippets from the reviews people have written about the show. However, being typically British with our self deprecating sense of humour. I decided to use the negative reviews rather than the positive ones. I have some great stuff such as “Paul has an ego that doesn’t need boosting” and “truly crappy jokes”. However, I need more. So, if you have 5 minutes this week drop me an email with a short, witty and hopefully not too rude review of the show. Let the venom flow :)

News and events

Internet Explorer 8

So the last time we did the news before Christmas Microsoft were under attack from Opera for its lack of standards support. Well, things have moved on since then and it is looking like Internet Explorer 8 is shaping up to be a very nice browser indeed. For start IE8 has passed the Acid 2 test published by the Web Standards Project. This is a definite commitment from Microsoft to provide comprehensive standards support and should be applauded. Jonathan Snook explains the ramifications of this as well as making some predications of his own as to what IE8 will look like. According to him we can expect straightforward column layouts, grid positioning and improved javascript support. Best of all if Jonathan is right we might see IE8 out in beta by the summer and in final release by next Christmas. Maybe then we can look at dropping support for IE6.

Using CSS to diagnose problems

Although there is still a lot of CSS not supported by browsers such as IE it is incredible what is possible with just what we have at the moment. Eric Meyer recently posted an article suggesting that you might want to consider using CSS to diagnose issues in your HTML that need resolving. In his article he uses CSS to find out where markup might be choking on missing accessibility features, targetless links, and just plain missing content. For example he uses CSS to visually highlight all images that have an empty or missing ALT attribute.

This isn’t an entirely new ideas. In fact Marco Battilana proposed a similar approach to highlight accessibility issues back in July 2006. However, Eric has taken it that much further and offered an excellent way of not only highlighting problems to yourself but also to your clients who maybe editing HTML.

Common accessibility mistakes

Talking about highlighting accessibility mistakes I came across a great article that does exactly that. Basically the article focuses on the fact that website owners can often be over enthusiastic when it comes to accessibility and start overusing HTML attributes designed to help accessibility. The result is that we can often do more harm than good. The article looks at the alt and title attributes which are often verbose or repetitious. It also looks at tabindex and accesskeys that can cause confusion and conflicts with normal browser behaviour. If you are applying any of these attributes to your code then I highly recommend you cast your eye over this article.

Basic design principles

The final story this week is an amazing series of posts by Patrick McNeil over at Design Meltdown. The reason I say they are amazing is because they are immense and I confess I am yet to read all of them. As you probably already know Design Meltdown tracks trends in web design and shows examples of sites that highlight these trends. Using the same example based approach Patrick looks at the fundamental principles of design and deconstructs them expertly. He covers Emphasis, Contrast, Balance, Alignment, Repetition and Flow in a screenshot packed series of posts that are a must read for anybody starting out in design. In the past I have always recommended Jason Beaird’s book “The Principles of Beautiful Web Design” for those starting out in design. In fact we have Jason on the show soon. However, if you don’t like reading books or want to save a bit of money then Patrick’s analysis is a credible alternative. Check it out.

Back to top

Feature: Common mistakes of site structure

Just before Christmas I wrote my final blog post for the year on creating the structure for your site. It is a topic that I have been thinking a lot about recently because of various projects I am working on and so it was fresh in my mind. In particular it occurred to me how much harder producing a good site hierarchy is than it first appears. In fact I see the same common mistakes occurring again and again. It is these mistakes I want to look at in today’s show. Read Common mistakes of site structure.

Back to top

Expert interview: Rachel Andrews on building a web design career

Paul: OK, so joining me today is Rachel Andrew from EdgeofMySeat.com. Hello Rachel. It’s good to have you on the show at last.

Rachel: Hello, Paul. It’s good to be here.

Paul: I feel like I’ve been trying to bully you to come on the show forever and ever and ever, but it hasn’t worked out for one reason or another, but we finally got you here, so that’s good news. So uhm, Rachel, when I came to kind of putting together what I was going to do, talking to you. I suddenly realized I didn’t know you very well. I’ve heard a lot about you and I’ve heard a lot of other people say good things about you, which has gotta be a good thing, but I didn’t know anything about your background or kind of how you came to be involved in web developement. So, I thought it might be quite interesting, if It’s ok with you, just to spend a few minutes talking about how you came to be a web developer. How did you get into this illustrious career?

Rachel: Uhm, completely by accident, really. It wasn’t something I intended to do. My training is as a dancer. I was going to dance. That’s all I ever wanted to do.

Paul: All right.

Rachel (laughing): So, the part where I ended up doing this surprised everyone, (Paul laughing) especially my programmer father. (Rachel laughs)

Paul: Ahhhhh

Rachel: We didn’t even have computers in school when I was in school. I’m showing my age.

Paul: Yeah, I know the feeling.

Rachel: Yeah, so, and I remember when I was, I don’t know, either 13 or 14 there were two guys that came in and said, “All of you will need to know about computers in your future careers.” And I was like, “No I won’t. I’m going to be a dancer.” and they couldnt tell me why I would need computers and so I felt quite pleased with myself. So, yes, it wasn’t on the radar after all.

Paul: So, how did you go from dance to web developement? It seems a bit of a leap there.

Rachel: Well, I know this is a fairly technical career, and I was working back stage for a quite a while and when I decided to quit dance for various reasons, I was working in the west end and I managed to my way into a back-stage techie job.

Paul: OK.

Rachel: I did work as a choreographer and I knew a reasonable amount about sound and lighting and could my way in. So, I worked back-stage in the west end and for a year and a half on Charlston and on The Mouse Trap.

Paul: Right, I see.

Rachel: So, so that was it. So, it wound up to be a technical kind of job and then I found myself pregnant with my daughter. And you cant go heaving around stage equipment while pregnant.

Paul: No.

Rachel: So (laughing), I found myself with some time on my hands. It was really that I even started using the internet.

Paul: Oh, ok.

Rachel: I was fairly young and didnt know anybody else with a child and pregnant.

Paul: What kind of… how long ago are we talking about here?

Rachel: Well, the said child is now nearly 11.

Paul: Right.

Rachel: So, quiet a while ago. ( laughing)

Paul: OK.(laughing)

Paul: So, in the relatively early days of the Web then to some degree…

Rachel: Yes. Yeah and I mean thats really so very important in that at the time there wasn’t actually that much to learn and I was chatting to people on for the parents on the forums because as I said, I didn’t know anyone with a baby and I didn’t know anything about babies. So, (Paul: Ahhh) I was using the web just to talk to other people in the same situation. And then if you wanted to put anything online there wasn’t Flickr or all of these hings. You really had to build a web site.

Paul: Right. Yeah.

Rachel: So, you know, once my daughter was born, I started putting together various HTML. So I could put together a web site telling people about her and things like that. And that’s what everyone did.

Paul: OK.

Rachel: You chat in the discussion forums and you build web sites. Uhm I don’t know… I quite liked that. That was always good fun. So, it didnt take that long before people would start asking me if I would build them a web site.

Paul: Mmhmm

Rachel: And… and at the time there was so little to know. You know, it was a bit of HTML and you had to do some basic things with images. As time went on, I realized I was actually quite interested in, what at the time fewer people were doing which was writing things with Perl which was about the only thing that anyone used to do things like guestbooks and (Paul: Yeah) posting forums to email. It was very, very limited at the time in terms of what people were doing on the server side. I sat down with the Orilley Camel book and taught myself Perl.

Paul: Oh Right, OK. (Rachel laughing) As you do.

Rachel: As you do. Obviously

Marcus: Or not, in my case.

Rachel: Yeah, well… I was bored. (all laughing) I had a baby. You know? Nothing else to do. So, that’s really how I got into doing the back-end stuff via such a strange route and I didn’t really realize what I was learning or if there was real reason to do so. It was interesting to me.

Paul: Do you think there was any advantages or drawbacks to taking that kind of route. I mean I know that most of us that entered the web in the early days did it through some convoluted route in preference to having some kind of formal training. Do you think the people that are coming along these days are going through a proper… you know, going through some kind of computer training course or whatever? Do you think their at a disadvantage for not learning it themselves and discovering it themselves.

Rachel: Well, yeah, but I think things are so different now. I mean back then, it really was a case of: You learned HTML. You learned a little bit about how to make graphics work online. And maybe, if you’re very pushy, you learned some Perl. (Paul: Yeah) And that was it. There wasn’t a huge amount of decisions. I mean, even just to start learning to do this now, you start having to think, “Well, which language do I want to learn? What is the best thing to be learning? Where should I put my time?” (Paul: Yeah, totally). You know, I was just kind of sitting with a little 486 computer and thinking, “You know… this is quite interesting. Look, I can do this!” But we were all just discovering what we could do at the time. Whereas now, if you’re looking at this as a career and what’s going to be best right from the start, before you’ve even gotten started, you know? (Paul: Yeah) So, It’s very different. And It’s very difficult when people always say, “Well, how did you get started? Have you got any suggestions on how I can get started?” And It’s so different now.

Paul: That’s probably one of the most common emails I get. It’s, how do you get started and what languages do you start with? So, I guess you really didn’t have a lot of choice. (Rachel (laughing): No…) It was Perl or nothing, wasn’t it?

Rachel: Really, I mean, yeah, there were other things around but generally people were writing in C, Javascript, and Perl. And the web host I happened to have, had this server which you were allowed to run your scripts on. (Paul: Oh, ok) (Rachel laughing) They were still slightly nervous of it. You know, it was just one server you could run things on. It was a quite good community around that. People would help each other out on how to do things.

Paul: So what advice do you give people who do write with those kinds of questions as to what languages to start with? What do you say?

Rachel: I think the important thing is to learn something well. At the end of the day, once you’ve learned one launguage, you can usually swap to something else. It’s the concept that’s the hard thing. (Paul: Yeah.) Understanding based design or understanding just the basic constructs of any language. Once you’ve done that, you can usually swap to something else. I usually say that PHP is a pretty good choice. Just because It’s out there, everywhere. (Paul: Yeah) You’re going to be able to easily find somewhere to run it. You can set up your own development environment without having to spend any money, really. You can get that all set up. And there is lots and lots of help and there is a great community around that. And to be honest, PHP is what we tend to develop in now and most of the time.

Paul: I mean, It’s quite interesting that you talk about those early days and how you basically got into it because you became a mother. But the early days in the web, and to be honest, to some extent now, there arent exactly a huge number of female developers around. I mean, it seems to be a very male dominated thing. Did that put you off? Did that create barriers to you?

Rachel: It didnt really at the time when I was learning because I came out of a very male dominated profession anyway, (Paul: Oh, OK.) having been working back stage. So, it didnt, worry me. And also at the time, I was just interested in learning it. I think out there in the work place once I became employed doing this, I encountered all sorts of strange situations where people really couldn’t quite get their head around the fact that I was technical and not like a designer or not something else that cliquey females are doing. I was the head of a technical team and went to help someone with a computer and I was the most senior person on the team. And they said, “Oh, can you not send one of the boys down?” (Paul gasps) I then said, “I can send one of the boys down. They’re not going to fix your computer for you, but I can send them down if that’s what you want.” (all laughing) I mean, so people were a bit taken aback, I think and don’t immediately assume that I do the job that I do (Paul: Yeah.) and are much more comfortable of putting me in a designer area.

Paul: Well, that was the mistake I made, isn’t it? (Rachel laughing) The first time, I suppose. I was the typical male chauvinist pig and presumed you are a designer, which I don’t know why. I think it was the hair color, more than anything.

Rachel (laughing): To be honest, I am not particularly hung up about it. It’s not something I get terribly upset about. I find it sort of intriguing that people just assume that. I’m not… you know… I’ve work in… sort of male dominated jobs for a long, long time now and I think if I got terribly upset about these things I wouldn’t be doing it. It is interesting. But in other ways, it works for me. When I was going for job interviews, for instance, if I’m the only woman who walks in and there are lots and lots of men, they’re going to remember me. (Paul: Yeah) And in the same, you know, if I’m pitching for work it’s a talking point. You know, people are always interested as to why I’m doing what I’m doing.

Paul: Damn, and here I was thinking I was asking original questions!

(Rachel and Paul laugh)

Rachel: I think sometimes, it does work for me because do remember. They would think can’t a woman do something a bit unusual?

Paul: Do you think it’s a problem within the industry or would you just think It’s one of those things and what will be will be kind of attitude?

Rachel: It’s really hard to see where it’s a problem. I think It’s a problem if girls or young women who are looking at career choices are being put off because they don’t see female role models out there. And, there’s lots of reasons why. There are women around doing this and tend not to be so high profile. (Paul: Yeah) I mean the reason that I’m not touring around all the different events and things is because I’m a mom. (Paul: Yeah!) You know, and I think that’s the same for an awful lot of women. I talked about this on my blog once and got loads and loads of women contacting me going, “Yes, exactly!” We’re the one’s doing the majority of childcare. I know there are men in that position too, and I’m not saying there aren’t men who are having to be… going to pick up kids at 3:00 or whatever it is. But it does tend to be women and It’s often the women who make that choice or wants to spend time close to the kids when they’re very little. My daughter is getting older but even so, I still wouldn’t be happy about, say going to a different country and leaving her here to go to an event.

Paul: Yeah. I mean to be honest, even for this interview we kind of have to fit it in around you taking your child somewhere, Marcus has got to do a school run in a minute. You know, so, it’s all part of the kind of… yeah… It’s nice we’re in a position where we can kind of fit our work around our families. It’s a good thing, not a bad thing.

Rachel: Yes, it is. And I think that’s possibly one of the reasons why there aren’t so many high profile women, because it takes time to raise your profile. And without me quite looking, I’ve been able to do that through writing, which I can do at midnight or whatever. If you’re going to get out there and get around to all the conferences and things, you know, and look at what other people who are considered to be my peer group and what they’re doing. I just couldn’t physically do that. (Paul: Yeah, totally) Because, I don’t want to. I don’t want to spend a lot of time away from my daughter right now. Maybe in 6 years time, she will be very disinterested in spending any time with me.

(Rachel and Paul Laughing)

Paul: Once she’s a teen-ager, you won’t want to be with her either.

(Both continue laughing)

Rachel: Exactly, you know, so things change but there are quite a lot of people with quite young children and actually more and more so. It’s quite funny, I feel like I’ve got quite an old child for the group of people that I speak to. There are lots of new developer babies out there.

Paul: Yeah, well Marcus is old and decrepit.

Marcus: Well, just to depress you, Rachel, what happens when they get older and become teenagers, they just rely on you as a taxi service.

Rachel: Well, I get that as well. That was the case today. I was ferrying mine and two others back from the

Marcus: The only thing I would say though is, we went through a period about 6 months the beginning of this year, trying to recruit new developers. And we only interviewed one woman out of probably a dozen candidates

Paul: I think that it’s worth saying that’s because we only have 1 woman apply, rather than we segregated all the women who refused to interview.

Marcus: That’s what I meant. Yes, well put Paul. We literally had only 1 woman apply, so yeah… I don’t really know why. Maybe it just seemed like kind of a boy’s area at the moment. I suppose, from what you were saying about the fact that you’re not inclined to go out there and sort of go out on the circuit like Paul does. I suppose until that happens, and maybe younger women who aren’t thinking about motherhood yet, are the ones who are going to be out there raising the profile of women and hopefully, this sort of “boys’ club” type mentality will sort of just fizzle away.

Paul: I mean, It’s quite interesting that you say, how you talked about how you managed to raise your profiles through writing. Tell us a little about that. How did you get into writing books? Because, you seem quite prolific. I did a quick search on Amazon to see exactly how much you’ve written and it seemed to go on for quite a long while.

Rachel: Yeah, there’s quite a few. That was, again, like most things, I tend to say, “Oh yes, I’ll have a go at that!” and then worry about it later. It was a long time ago, I had written some stuff for the Macromedia Web Site about Dreamweaver.

Paul: OK

Rachel: And it was Glasshouse who contacted me and said, “Oh, would you write a couple of chapters for a book?” A couple of chapters, that would be alright, you know (laughing). (Paul: Yeah, no big deal). So yeah, I wrote a couple of chapter for a book and it kind of went from there, really. I like writing. I enjoy… I’m much more from an arts background really than technical. So, I do enjoy writing and putting things across that way. So, yeah, it just went from there. And then when someone said, “Oh, will you write a few more chapters?” Yeah, ok, that was alright. (laughs) And before I know it, I’ve got this great list of books.

Paul: Yeah. It’s a very time consuming thing to do. I mean, beyond the fact that you obviously sound like you enjoy doing it. Do you find it beneficial from a publicity angle for bringing in work?

Rachel: Yeah, absolutely. I think people tend to see you as an expert if you’ve got things in print; if you’ve written things. It does sort of depend that you do know what you’re talking about. And especially with what I do, which is much more… It’s not like I have to show a nice portfolio of pretty things. This is what I can do. What people are doing when they hire me or hire my company is they are hiring us for our expertise. And they have to constant that we actually are experts; that we know what we’re talking about. So the writing does help in that because people assume that if someone let you write a book, you must actually know what you are talking about.

Paul: I mean, I get emails from people asking how do you go about raising your profile. I’m quite interested as to whether you stumbled into this. You know, you talked about you were writing for the Macromedia web site. Did you go out purposefully, intending to write for them or did it just kind of happen? How’s that come about?

Rachel: Again, that really just happened. But because I was writing on my own blog, and I was writing… you know, I was helping people out in forums. (Paul: Right) You know, if you’re out there doing things, people do notice. I mean certainly with things like magazines and books and you know, varies sites that want articles. There are people out there that are looking for people to write all the time, because there’s actually an awful lot of people who know what they’re doing but there are fewer who can express it and express it in a way that someone new to the concept is going to understand. If you are able to do that, if that’s something you can do and you are doing that on your own site or are helping people out in forums and things then it will get noticed. And there are quite a bit of places you can be submitting I suppose, to, you know, Site Point and Vitamin… There’s quite a bit of other sites that accept good content. (Paul: Yeah.) It means that you have to write a few things that you’re not paid for to get going. You can find then, that you can start putting together a body of work and say, “Well, this is the stuff I’ve done.” It’s not in It’self something that you earn a huge amount of money from. I think people who write for a living must have to work incredibly hard.

Paul: (laughing) Or be incredibly good. One or the other.

(Rachel and Paul laughing)

Rachel: Both I think, both. As something that helps raise your profile for the other things you do. If I found it an absolute chore, I don’t think I would do it because you don’t want to be sogging away at things you can’t stand in the hope that it will get you some profile. But it is one way to do it and It’s certainly a way to do it if you are in a position where you can’t get out to lots of events or you’re not someone who wants to do public speaking. I’m not keen at all on public speaking. I much rather hide behind the computer (laughing).

Paul: A proper developer. That’s what I like to hear.

Rachel: So, you know, It’s another way of doing it, because I do sort of think of the public speaking if you’re going to be thinking of conferences as being something that would really get that profile up there. No one has really met me until fairly recently at any events because I didn’t get to anything really. And yet a lot people would have known of me and the stuff I’ve done because of the lighting.

Paul: I mean, you talk about that you use this as a mechanism to you know, to increase your profile for the other work that you do. So, perhaps we ought to talk about the other work that you do. I mean, you run a company, “Edge of My Seat” which is edgeofmyseat.com. How did that start? You obviously from going… from being an enthusiastic amateur, you must have gotten a job in web design, I’m guessing. How did you go about getting that job and from there, how did you end up running your own company?

Rachel: Well, I… When I decided I actually wanted to go back to work… I’ve been doing bIt’s and pieces while my daughter was quite little and I decided I wanted to go back to work and it was really tail-end of this whole dot com era. (Paul: Oh, OK.) And so, I ended up heading up a technical team at Property Finder. (Paul: Oh, OK. Yeah, I know.) Which was very much on the technical side and we managed the servers and things like that rather than even doing any development or very much development. There were other people who were more on the development team, although we still did bIt’s and pieces. I did that for a while and the whole sort of dot com thing was starting to fall apart really, at that point. And I moved to another dot com company who built portal sites for accountants. So I know quite a bit about stage integration (Paul: Wow. What an exciting life you have). Yeah, but that’s the time where things really weren’t looking that stable and I felt, well I can actually do this myself. And at least then I would know where I was in terms of whether I was going to get paid by people. The problem is being employed in an unstable situation is that really, you can work a whole month and get to the end of the month and find out that nobody’s paying you. (Paul: Yeah.) And so I figured that actually, I may be better off setting off on my own. And so people had asked if I would take on bIt’s of freelance work and things. And so, I actually purchased a printer’s trust because at the time I was a young single mom. I’m not so young anymore but I purchased a printer’s trust and this in 2001. And they basically gave me a small grant and loan to get the company started. So, I had about a month’s money when I started. (laughing) I didn’t have the dot coms, so I kind of had to work. (Paul: Wow!) It’s a good way to start a business, you know (Paul: Yeah.) … make or break really. If it doesn’t work, we don’t eat.

(Rachel, Paul and Marcus laughing)

Marcus: I remember that feeling very well.

Rachel: Yeah.

Paul: Yes

Rachel: But it makes you really dive into it. The nice thing was, because I was paying for a child, mind you, at the time, I actually only had to earn half of what I had earned because I could keep her home with me.

Paul: Ahh, ok.

Rachel: So, I must have cut my expenses by being able sort of work around my daughter’s schedule and things. So, that kind of worked out alright and really, it went from there.

Paul: So how did you begin to win the business in that first month of, “Oh crap! What have I done?” (Rachel and Marcus laugh) You know, where did the work come from?

Rachel: Well, at the time, what I realized was that because of how the dot com was collapsing, everyone was getting rid of their developers. But they still had all these applications. And something I’ve always been good at is picking up on other people’s stuff and working on it. So, probably, uhm, September ’01, which was like a terrible time to start a company (Rachel and Paul laugh) and really for the first two or three years was taking stuff that was already built and was falling apart, or the developers had gone or had all sorts of problems with it and just fixing it or adding bits to it. And I did lots and lots of that which, during this time of recession, really, was actually, really good work because there was plenty of it. Everything had to have been built while they had lots of developers and they had money and things. And so I sort helped things limp along a lot. And what this sort of lead to really was this idea of doing development for design agencies. (Paul: OK.) And focusing on doing really good development to support really nice design. That really is what we’ve moved on to do now. Most of our clients are designers or design agencies. And they do a really good design, and then they hand it over to us and we look after it and we make sure it will work. (laughing) That’s actually a really nice way to work because it means we get to work with some really nice stuff, anyway, well designed stuff and we have people who care about what they do. (Paul: Yeah.) And we get to do the development side of things that we enjoy. Sort of working with people rather just sort of chucking things over the fence and throwing it back.

Marcus: The point your picking about picking up what other people have done and fixing it and that kind of thing… did that not kind of cause you problems with development platforms and having to deal with lots of different types of languages and that kind of thing?

Rachel: Yeah. I had learned ASP by that point and a bit of Java. And I tend to not have too much problems swapping from one thing to the other. Certainly, I mean then, it was a lot of Perl and my class PSP. Because that was, at this sort of time, they were really the two things that you were seeing things built in. So, I used to do either and then I started doing PHP as well around the same time. So, I’ve always been quite happy swapping between languages, swapping between databases. (Marcus begins to speak: I think the reason why…) It gets a bit much if you do too many in one day, you know, because you start putting semi-colons in the wrong place and stuff. It doesn’t really bother me too much. I mean, its nice to be able to concentrate one thing. As I said, we tend to build new stuff in PHP. But, I’m generally quite happy switching around.

Marcus: I suppose, the reason why I was asking is we’ve come across a few briefs that we’ve been sent in the past where it seemed like the perfect job for us but the development platform in particular has been something that we just don’t work on. Do we want to invest on that kind of platform just so we can go after this job and quite often, we’ve thought to ourselves, “No, we don’t.” So, I guess that’s where the question is coming from.

Rachel: Yeah, I think in terms of new stuff, you kind of do have to focus unless you’ve got an awful lot of people able to create your own libraries and things in different languages. So for new stuff, we do tend to choose PHP but at the time, what I was doing was just picking up on stuff. It was less of a problem really because I was just fixing stuff that already existed.

Paul: You seem to have done very well over the last few years and Drew has come and joined you now and you seem to be branching out a bit into the area of training. That seems to be something that’s come up.

Rachel: Yup.

Paul: I’m quite interested, you know… it’s great you’re there and you’re able to offer training courses. You do have a basic CSS training course, I think (R: Mmmhmm) and you’re talking about doing an advanced one, is that right?

Rachel: Possibly going to do that. We’ve had a few people ask. (Paul: OK) So, that’s what we’re thinking of doing.

Paul: So, I mean, the question now is who trains the trainer? How do you guys stay on top of the latest things that are emerging and how do you keep up with what’s going on?

Rachel: Well, basically, because we are doing it all the time, I think. The difference between us and a training company that just does training is that actually what we’re doing is, we’re using this stuff all the time. It’s the same as when I buy a book. I’m writing a book from the point of view of someone who has to do this. You know, who practically is doing it. And it’s the same with the training. Obviously, we’re constantly reading up on new things and trying things out in browsers and trying to get around problems and just by the day to day work that we do. So, that’s really what we’re bringing to a training course. For two or three years, people have asked me if I would do training. But until Drew joined, we just didn’t have the capacity. It comes down to one of those things that have to be arranged. So, it wasn’t saying that I really felt that I couldn’t do, but Drew was making to do it as well. Its great fun. Its an enjoyable… its actually enjoyable to be face-to-face with people. Especially writing a book and then the feedback you get as the occasional email that people say, “Oh, I really enjoyed that!” or, “Why did you say this? Its rubbish!” (Rachel and Paul laughing) Actually being face-to-face with people and seeing how they work through the course is really, really interesting and great fun.

Paul: Cool!

Rachel: So, yes. It’s been good.

Paul: Excellent! Well, thank you so much, Rachel, for coming on the show. It was really good to hear how you got into things and how your career has progressed. Even if it’s somewhat chaotic along the way. Although I can associate with that (Rachel laughing) kind of bouncing from one thing… We’d set up Headscape in January, 2002. So we were only 3 months behind you, so we understand your pain there.

Rachel: Yes, well it wasn’t the best time, really.

Marcus: We were both made redundant from a dot com in December, 2001, so it was necessity that got Headscape, I think.

Paul: Yeah. Always the best way. OK, thank you very much, Rachel, uhm and I’m sure that we will get you back on the show again if you’re willing at some point (Rachel laughing) in the future. Alright, thank you.

Rachel: OK.

Back to top

Listeners email:

So just before we wrap up the show I wanted to share with you an idea sent in recently by a listener (sorry I can’t find your name)! A number of you have written in since we said we were going to change the format of the show with ideas about how things could be improved. One idea that particularly appealed to me was a new short section at the end of the show where we read out some listeners emails. These emails could be a question, comment, recommendation or indeed anything else you think others maybe interested in. So whether you have a tip for improving your sites search engine rankings or just want to tell me how ignorant we are then drop us an email. Write in soon as we need content for next weeks show!

103. Bargain basement

Posted in Classic shows on by Paul Boag

On this week’s show: Paul looks at doing usability testing on a budget. Marcus explores the perfect working environment and we review writemaps an excellent online tool for creating site hierarchies.

Play

Podcast: Download (29.2MB)

Download this show.

Launch our podcast player

News and events | Marcus: The perfect working environment | Paul Bargain basement usability testing | Review: Writemaps | Question of the week

News and events

Improve your javascript

There seems to be a lot being written about Javascript at the moment, much of which should really help those of you like myself that have a basic grasp but really need to move on to the next level. First, there is a post by Christian Heilmann entitled Javascript Shortcuts that is aimed at teaching dummies like me how to code better. Its actually a very good post and helped me to grasp some shorter ways of working with Arrays and if statements.

There is also a post by Roger Johansson that lays out the basic rules of unobtrusive Javascript. Great for those of you who are old school Javascript coders and need to come a bit more up to date. Most of the points are obvious if you have worked with unobtrusive javascript before but there are also some nice extras like…

Work for the next developer: Make maintenance easier by writing logical code with clear variable and function names and commenting where necessary.

Finally, PPK has updated his DOM compatibility table that catalogues browser support for various DOM modules. I have to confess that some of this went over my head but it is still useful for understanding why a piece of Javascript is not working in a certain browser.

The guys over at Blue Flavor are having a go at answering the million dollar question this week; what makes great design? To be honest I am not sure if this is a question that can really be answered, but I have to say they have a hell of a good go!

Nevertheless it is a good article to point clients at if you need to explain why they should pay more to make their design stand out from the crowd.

Better web forms

On the subject of great design being in the detail I thought it was worth mentioning a great article by Garrett Dimon on Digital Web. Garrett is an information architect and has the most amazing eye for detail. By making small changes he has a significant effect on the sites he works with.

In his article he takes the registration form from ebay and makes a series of small alternations that improve its usability and readability. By tweaking things like the position of labels, the division of fields and the weight of headings he turns a very average form into something that is so much more accessible.

Forms are tricky things to work with and most designers hate doing so. However, reading this article should inspire you when next to tackle a form.

Building an inspiration base

Talking of inspiration, my final news story for today is another one from Blue Flavor. This time they are talking about how to build a reserve of inspiration that you can draw upon. Inspiration is a subject I seem to come back to often and with good reason. It is very easy for designs to become formulaic and it is important to be constantly looking for new sources of inspiration.

This article is in itself very inspiring suggesting a number of ways to find inspiration that I had not previously considered. Although it covers the obvious such as keeping a sketch book or photographing things that give you pause, it also suggests looking through cookbooks and even standing on your head (and other changes in perspective).

I am not convinced all of these ideas will work for everyone but if your going through a dry patch it is definitely worth a read to see if you cannot spark some inspiration.

Back to top

Marcus’ bit: The perfect working environment

Recently we received a question asking about our working environments and specifically what your working environment should be like when you code.

I’m going to swing this a little wider and look at working environments in general rather just concentrating on one’s own desk. This is something that both Paul and I have a great deal of experience of so I expect he will have as much to say on the subject as I do.

Mess vs tidy

Marcus' desk (hell hole)

Ok, I have been brave and posted a picture of my office, in its current disgusting state, onto the site. It is appalling – no question. I hate it like this. I keep talking about tidying it up but I reckon it will take at least a week to do it!

Does it make me any less productive to be honest, I’m not sure. The instant answer is to say “no, of course not”, but I am sure I would rather be in here if it was tidy, so it’s certainly possible that I would get more done.

I don’t believe that there is any real benefit to working in this type of squalor. It’s really easy when you first set up an office not to bother spending the tiny amount of time required to organise yourself. This is a mistake. File stuff away regularly (in a sensible way). If you don’t well, just look at the picture.

Music vs silence

For me (the musician), it has to be silence. I am not absolutely sure why, but I think this is because I mostly write as opposed to design or code stuff. I also think it’s because I listen to the music rather than it just being background. This is either shows a weak mind or an outstanding empathy for the musical arts you choose ;-)

Other people

One thing that the questioner didn’t get into was whether or not it is good to work with other people around you. I think that the healthiest option here is to mix it up. Working on your own all the time as we have done for years, is great with regard to getting things done. You can really hone in on a task and give it your all. Headscape’s office is open plan with anywhere between 4 and 10 people in it at any one time. I struggle to write in this environment as I’m too tempted to talk to other people.

But, working on your own all the time can be counterproductive. You are far less likely to bounce ideas around and learn new stuff. Teams tend to be more focused and productive if they work together regularly.

Working on your own for years can lead to stagnation and a lot of staring out of the window if you don’t really fancy a particular task. I tend to measure my desire for a job based on the amount of tea I make during it!

How to organise your day

I tend to check email as it comes in and I respond to IM and phone calls immediately. I can’t help it. I often think that it would be a good idea to check email, say, every 2 or 3 hours and not let it interrupt what I’m working on. I guess this is the salesman in me thinking that every contact is a good lead.

Paul tends to block out chunks of time for tasks and won’t let himself get interrupted during this time. This has got to be more productive than the flitting around method that I adopt.

We’re all different

The main thing to recognise with working environments is that we’re all different and react differently to various situations. Some people like to lock themselves away, others feel lonely working on their own. I think employers need to recognise this and, within reason, try to provide the best environments for their staff on an individual basis.

Back to top

Paul’s corner: Bargain basement usability testing

Okay so lets pretend that your boss refuses to pay for usability testing, you have no budget of your own and yet you are determined that the site will be as easy to use as possible. What do you do?

Today I want to look at how you can carry out usability testing without spending a penny. Of course if you can afford $19 per test subject then you can afford this an interesting little service discovered by Tom a boagworld listener.

Back to top

Review: Writemaps

I have never managed to find a tool I like for creating site hierarchies and getting them signed off. However, recently I found something that is definitely getting there and I wanted to share it with you.

Back to top

Question of the week

What is the best online application you cannot live without?

Show 96: Moll on Mobile

Posted in Classic shows on by Paul Boag

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

Play

Podcast: Download (31.0MB)

Download this show.

Launch our podcast player

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

News and events

Social Participation as a business tool

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

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

Test your website for mobile compatibility

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

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

  • Speed
  • Cost in terms of data access
  • Quality of code

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

Laying out inline images

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

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

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

10 Usability nightmares you should be aware of

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

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

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

Back to top

Marcus’ bit: When is speculative design okay?

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

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

The worst case

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

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

When is it ok?

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

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

But, this isn’t just about getting paid.

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

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

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

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

Back to top

Paul’s corner: Who to ask to tender?

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

Back to top

Ask the expert: Cameron Moll on the mobile web

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

Cameron Moll: Hey, thanks Paul.

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

Cameron Moll: Yeah it is.

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

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

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

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

Paul: Uh, October 20.

Cameron Moll: Um, unfortunately not.

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

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

Paul: Sure (thoughtfully like he is paying attention)

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

Paul: Yeah (thoughtfully like he is paying attention)

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

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

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

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

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

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

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

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

Cameron Moll: Right exactly.

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

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

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

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

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

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

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

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

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

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

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

Cameron Moll: Hey thanks Paul.

Back to top

Social Participation as a business tool (Video)

Posted in Web strategy on by Paul Boag

Community based applications are applicable to all audiences and can be a powerful tool for businesses.

Social networks and communities are often seen as the domain of the teenage crowd with sites like YouTube and MySpace dominated by this demographic. However, community based applications are applicable to all audiences and can be a powerful tool for businesses.

Back in 2006 I spoke at refresh06. One of the presentations I gave there has since proved a popular subject and I have been asked to speak on it again a number of times in various forms. It is on the subject of social participation and how to use it as a marketing and business tool.

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

Who do you ask to tender for your web project?

Posted in Web strategy on by Paul Boag

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

One option is to search on google filtering by geography. There are valid reasons for selecting a web design agency within the same country. Issues such as currency exchange, time zones and differences in company law can make working with international agencies challenging. However, beyond that, geography doesn’t play a large part. A web design agency is just as capable of designing a website whether they are next door or a few hundred miles away.

The best approach is to rely on word of mouth recommendation. Nothing beats a recommendation by somebody who has already worked with a particular agency. The best recommendations come from people you know and respect. Start by talking to your suppliers or other business partners. Who did they use to build their websites? What was their experience like? Next, if you are apart of a trade association see if they have any recommendations. They often have lists of preferred suppliers and even if they don’t you can always ask who produced their website. After that, try looking further a field. Search online for any forums or mailing lists related to your sector and ask for recommendations there.

A final option is to look at websites that you like or consider successful. Most websites will have a link somewhere to the agency that developed them. If they don’t, then a quick search on Google can often reveal the agencies name. However, it is important to be careful if adopting this approach. Just looking at a website does not tell you the whole story. The underlying technology could be a shambles, the management may have been appalling and the project might have exceeded its budget and missed specified deadlines. If you do select an agency on the basis of a website then you may be wise to call the website owner first and get their opinion on the agency.

By combining the various approaches above you should have built up a considerable list of agencies. How many agencies you choose to send the brief to is subjective. It depends on the size of the project and the time available. Invite too many and you have a lot of proposals to read and presentations to sit through. Invite too few and you may not receive enough responses to carry out a fair comparison. For an “average” website redesign (if there is such a thing) anywhere between five and ten would be a good number. However, the chances are that your current list is larger than that. How then do you refine it down to a reasonable number?

Assessing an agencies website

The most effective way of finalizing the list of agencies you wish to tender is by looking at their websites. An agencies website can tell you a lot about whether they are right for your project. The problem is that web design agencies are very aware that they are judged by their websites and so put a lot of effort into projecting the right image. Your challenge is to look beyond the superficial gloss and focus on what can be learnt about the reality of their offering.

It is easy to get seduced by alluring graphics and exciting animation. However, I suggest there are four essential pieces of information that you need to focus on.

  • Do they have the capacity to deliver? You need to be confident that their team is big enough and has the right skill to deliver your project. A good agency will ensure that information on the size and makeup of their company is available, in order to help you make that judgment.
  • Do they have the right experience? Agencies who have experience of working on similar projects or in the same sector, can prove invaluable. Their experience will dramatically reduce the learning curve and this will impact costs and timescales.
  • Can they produce the right design style? When we discuss design in the next chapter I will argue that brand identity and target audience, rather than the preferences of either the client or agency should dictate design. It is therefore important that the chosen agency is capable of designing a user interface suited to these requirements. Most agencies show examples of their work on their websites. Look for examples that are aimed at a similar target audience or mirror the style to your existing branding. Failing that make sure the examples on their sites demonstrate a broad range of styles. If all the sites they produce have a definite “house” style and that is not inline with your requirements, then look elsewhere.
  • Can they deliver your technical requirements? Good web design is about more than the user interface. Increasingly, web projects involve complex development work. An agencies website should demonstrate a capability to deliver these kinds of projects. There should be examples that are comparable to your requirements and using similar technologies.

If a website does not provide you with the information you require, then take the time to pick up the phone and speak to the agency directly. A five-minute phone call can be more enlightening than pouring over a site for hours.

Hopefully this process will allow you to create a definitive list of agencies you wish to invite to tender. Once the brief has been sent, expect the agencies to call with various questions. Be sure to note down the calls you receive. Who took the time to call you and who did not? Of those who did call, which asked intelligent questions and which had not read the brief thoroughly? These are all clues that help you build up a picture of the agency and informs your decision making process.

What we can learn from Flickr

Posted in Site content on by Paul Boag

Once we wrap our heads around the fact that we should be focusing on our content rather than our website it offers some interesting new opportunities.

This years dconstruct really inspired me especially the talk by Tom Coates. It challenged my perception that web design is all about the website. Instead, as website owners, we need to start thinking about what content we hold rather than the method by which it is delivered.

These days the web is becoming less about websites and more about content delivery in all of its various forms. Once we wrap our heads around the fact that we should be focusing on our content rather than our website it offers some interesting new opportunities. However, instead of talking in theoretical terms lets look at a real world example; the photo sharing site flickr.

Alternative delivery mechanisms

Flickr realized very early on that they were about photos, not running a website. Central to the Flickr philosophy is empowering users to share their photos. It doesn’t matter to Flickr how their users share their photos. What matters is that they are exposed to the biggest audience possible. By opening up their content via an API Flickr photos can be accessed through a huge variety of methods including (but not limited to)…

  • The Flickr website
  • Mobile devices
  • Desktop widgets
  • Digital WiFi photo frames
  • Third party desktop applications
  • Third party websites
  • Even printed material (such as moo cards)

In short, Flickr has let go of the concept of driving traffic to their website and focused on putting their content in front of as many people as possible.

You maybe asking yourself how this applies to your website. After all you are not flickr and don’t share photos. However, the principles can apply to most content types. Take for example the humble blog. A blog is made up of individual blog posts. Each of these are content items that could be delivered through almost all the mechanisms mentioned above (with the possible exception of digital photo frames). Equally you might be a university who holds a database of all of your courses. Again, why limit that data to your own website? It could just as easily be delivered to a much wider audience.

Amazon get this idea. They have had an API since the dawn of time and are more than happy to push their product lines out beyond the confines of their website. Of course by doing so they loose some level of control over their content but that is offset by the many more potential customers who are exposed to their products and their brand.

However it isn’t just Flickr’s API that should impress you. Its also how they navigate and organize their content.

Navigate via meta data

Take a look at your average Flickr photo. It contains a lot more than the photo itself. Each photo has associated with a mass of additional information (known as meta data). Just some of the data held on a photo includes…

  • A title of the photo
  • A description of the photo
  • Comments on the photo
  • The photoset the photo belongs to
  • The user who uploaded the photo
  • Tags for the photo
  • Notes on the photo
  • The copyright restrictions
  • The longitude and latitude of the location where the photo was taken
  • The type of camera used to take the photo
  • Settings used when taking the photo

However, what is interesting is not the amount of data available about the photo, but the fact that it is possible to navigate by almost all of those criteria. You can search on title, description, tags and pretty much anything else. You can click to see the photos of a user who has commented or even see all of the photos that have a certain copyright restriction. You can view photos geographically via a map and even look at photos taken with a specific F stop!

This richness of navigation really helps when navigating a huge amount of data (such as the 1 billion photos in Flickr). It enables users to quickly and easily find what they are looking for as well as exposing them to content that perhaps they would have never previously found.

Again there is a lot that we can learn from this. In particular there are real benefits here for ecommerce sites. Building up rich meta data around products and allowing users to navigate via that, will expose them to many more products and allow them to narrow their search much quicker. For example on an ecommerce site users could choose to navigate via customer ratings or brand name as well as more traditional categories. With our blog example from earlier users could navigate posts by tag, author, or even number of comments. The possibilities are endless.

Of course, this approach is not without its risks. Without the kind of clean simple design implemented by Flickr users could quickly be overwhelmed by all of these options. However, it does not need to be that way and with some careful visual hierarchy a site can be both meta rich and easy to use.

Conclusions

The key to this approach is to start thinking beyond the page metaphor and to start looking at your content in terms of data types. Obviously this approach does not apply to all content types (for example I don’t envision pushing the about us page to third party applications) however most sites contains some form of key content to which these principles apply. The trick is identifying what they are.

Making the most of the footer

Posted in User experience on by Paul Boag

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

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

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

Good question! Why do we will fill our footers with all of this stuff? I suspect the truthful answers is three fold:

  • that we are lemmings, blindly following what others have done before.
  • that the only reason the footer exists at all is as a way of “finishing off” the bottom of the page.
  • that the footer is a dumping ground for information which doesn’t fit neatly anywhere else in the site.

This somewhat reactionary approach cannot be healthy so lets take a step back and look at what is commonly found in footers and what better solutions might be out there.

What is often found in the footer

To start with let’s examine the list of footer items that Peter proposed:

  • disclaimer
  • copyright
  • privacy policy
  • accessibility statement

Legal rambling

First up, disclaimer and copyright. These two links are often joined by various other forms of legal talk. Generally speaking, these are a waste of time from the users perspective, but often have to appear for legal reasons. Exact legislation varies from country to country (for example in the UK you have to display certain company registration information), however few people actually care about this stuff.

If nobody cares about this information why are we linking to it from every single page of the site (as footers tend to be universal)? What is more, why do we separate them out into numerous links? Why don’t we simply have a single link marked “legal information”?

Peter in his question asked what should be included in this information and to be honest I dare not try and answer that. I am no lawyer and as I have already said the answer will depend on your location. However, I would suggest that where possible this information is written in plain english rather than the legal jargon used on many sites. Take a leaf out of the creative commons book.

The users rights

Peter also mentioned privacy policy in his question. I would bundle this into a general category that appears a lot in footers. Lets call it “user rights”. This includes things like privacy, return and cancellation policies.

Unlike the legal ramblings, depending on the type of site, many users may actually be interested in this information. On ecommerce sites in particular users want to know these kinds of things and having that information gives them the confidence to buy.

If you are selling stuff or if you are collecting personal data then consider including this kind of information in your footer.

Accessibility

Finally, the last item Peter identified is the accessibility statement. I have to say I like seeing an accessibility statement link in the footer. It tells me that the website owner has at least considered accessibility and thinks it is important enough to justify a link on every page. However, although I appreciate the sentiment I feel that there are better ways of going about it.

The trouble with an “accessibility statement” is that it smacks of more ass covering. The emphasis is on defending the site against those that might criticize it rather than helping those users with accessibility needs.

If you are having trouble using a site because of a disability you do not immediately think “what I need is an accessibility statement”! What you actually think is “I need help”. Accessibility should sit under a help section and should be written within that context. “What help can you provide people with disabilities” rather than how do you defend the fact that your site doesn’t scale.

Of course it could be argued that people only look for help as a last resort. Perhaps it should be sold as a “guided tour” instead ;)

Whether this help section (or whatever you call it) should be on the footer at all is another matter. In my opinion it is too important to leave in the graveyard of your average footer. However maybe if the footer becomes something more, it might be the right place. That leads us nicely on to asking what role the footer should actually fulfill.

What role the footer should fulfill

So if the footer is not a dumping ground for rogue links, what is it for? Well for a start, I would suggest it has a lot more power than we give it credit. Think about it for a moment…

  • We know most users are now comfortable with scrolling and reach the bottom of the page.
  • The footer appears at the end of the body content when users are looking for their next action (after scanning the page).
  • It appears on virtually every page of your site.

The problem is that historically footers have been limited to a single line consisting of a few unattractive text links. However, there is absolutely no reason why they cannot be more. A growing number of sites demonstrate that if we free the footer from our artificial constraints it can be a powerful navigational aid. It can provide quick links to killer content and even be used for up selling and cross selling on ecommerce sites.

When next you design a website I would encourage you to seriously consider how you can make the footer more than a place where unloved links go to die. Take a look around at how others are beginning to use the footer in more innovative ways.

Show 91: God Bless America

Posted in Classic shows on by Paul Boag

On this week’s show: Paul gets to grips with the fact that the whole world isn’t British, Marcus explains how to deal with the client from hell and Julie Howell shares her expertise on accessibility

Play

Podcast: Download (32.3MB)

Download this show.

Launch our podcast player

News and events | Dealing with the client from hell | The international web | Julie Howell on Accessibility

News and events

There are tons of news stories which have sprung up since I last recorded a show. In fact I have spent all morning wading through my RSS feeds. Unfortunately as always I can only squeeze a few into the show so you will have to check out my delicious feed for the rest.

Gerry McGovern on Intranets

The first story I wanted to mention is a couple of posts by Gerry McGovern concerning intranets. I am constantly getting emails asking for me to talk about intranets on the show but somehow have never gotten around to it. Fortunately Gerry has and if you are somebody who works on intranet sites then you should take the time to check them out.

The first, tackles the basic problem of how to get senior management engaged with the intranet. Gerry observes that generally speaking management don’t consider the intranet an important asset to the business and so the site never gets the backing it deserves and requires. In the post he suggests the solution is in how the intranet is portrayed to management and goes on to propose a better approach.

The second article Gerry has posted on intranets is a breakdown of a report on what staff really want from their intranet. Basically, staff overwhelmingly want a better organized intranet where they can quickly find people, policies and procedures, and forms.

Gerry goes on to look at the numbers behind this conclusion and links to a summary of the results in PDF form.

SXSW Panel Picker

Probably the biggest web design news since I have been away is that SXSW have launched their annual panel picker. For those of you who do not know, SXSW is the biggest web design conference of the year and takes place in Austin Texas. The massive event has democratized their selection of panels by opening it up for you to vote on.

By going to the SXSW panel picker you can browse over 680 suggested panels and vote for the ones you like the look of most. Although this sounds great in principle, as Andy Budd points out, it can turn into a popularity contest for the speakers and not necessarily an assessment of the quality of the subjects.

That said, I need you to all vote for the three panels I am associated with whether you think they are any good or not! I don’t even care if you are attending SXSW or not, just get on the site and vote. Hell, I have crafted this podcast lovingly for you every week for over two years the least you can do is vote for me :)

Seriously though, I am hoping to be on three panels (yes I know this overkill) and am really excited as it is my first year speaking at the conference.

My panels are:

Hopefully at least one of these will come off.

HTML characters lookup

My next news item that I wanted to mention is a useful little tool which has recently been launched. I love this tool because it solves a really simple problem in a very easy to use way. Basically all it does is allow you to look up the HTML code you need to include ampersands, spaces or other characters which need to be escaped.

Let me explain the problem in case you don’t know what I am talking about. In HTML certain characters are reserved for use in the code. For example if you type an & it will interpret that as code and not text. It is therefore necessary to code up these characters in a special way. This online tool will tell you exactly how to do that.

You simply type in the character you wish to use and it returns the code you have to use. The site uses AJAX so results return incredibly quickly and if you are a mac user you can even download a dashboard widget.

Very useful indeed.

Moving from Print to the web

My final new story for today is some help for you print designers out there who are struggling to make the transition to the web. It is not always an easy process not just because of learning the technical side but also the mental shift involved.

Well, if that is you I would like to make two suggestions. First up, I would like to recommend an article I came across that takes you through the process of moving from print to the web. Its extremely good and makes some excellent recommendations about where to start.

Secondly, you might want to think about getting some training on CSS and XHTML. There are a number of courses out there but if you are UK based I would like to particularly recommend a beginners CSS course being run by Rachel Andrews and Drew McLellan. These guys are both experts in their field and they have a session coming up in October. Of course this course is ideal for anybody starting out with CSS, not just print designers!

Back to top

Marcus’ bit: Dealing with the client from hell

Found this rather frustrated boagworlder (Cadore) in the forum – read on&#…;

Hello everyone, I was wondering if I could get some feedback on how to proceed with a problematic client.

I have a small business client who contacted me about a website. After talking with her she decided she wanted a basic two column layout with some navigation, she would provide language, etc. All was good, but here is the main problem: I design the header or banner, whichever you call it, and she says it looks great, she loves it. Then we move onto the navigation, she likes the navigation, but now the header seems “too busy” – take a step back. One thing that cracks me up is she said in emails she wants to have a large amount of leaves throughout the design. So, I incorporate leaves and she says she is thinking of not having any leaves at all now. It’s like she wants to do the design for me? Me designer – you client. Do you understand what I am saying, every step forward she wants to go a step back. Now she has a problem with the navigation, and the background image, that she has loved and hated 4 times already. Does anyone have any advice how to deal with a client like this. I was thinking of having her sign off on every little things, but this doesn’t make for a happy working relationship. Any advice on you have proceeded with a client like this would be appreciated.

I have talked loads about getting contracts in place, making sure everything’s agreed up front etc etc. But, agreeing on the look and feel of a site is not so easy to nail down before you start working on a project.

Certainly do all of the following before you start:

  • Find out who will be signing off the design.
  • Encourage the client to make this as small a group as possible.
  • Talk to these people. Obviously, talk to them about project specifics (see below) but try to get to know them a bit. Get an idea whether they’re conservative in their outlook, arty, whacky&#…; whatever. I remember seeing a panel at SXSW where a Swedish creative director said that he insisted on getting drunk with his clients before starting the job&#…; there is some wisdom in that!
  • As them for examples of favourite sites, particularly in their sector. Ask them why they like them.
  • Ask them for any other marketing material that they have, particularly items they like.
  • Discuss their brand (even if it’s just their logo) and the importance of continuity. Make sure that you are aware of any limitations.
  • Discuss colours.
  • Discuss imagery. Ask for imagery that you can use.
  • Discuss layout.
  • Finally, when you’re discussing these items, make sure that you provide examples, choices, potential solutions etc. Your client is almost certainly not an expert web designer therefore they need ideas from you; alternatives if you like.
  • However, you must explain why you’re recommending a particular idea. You need to communicate that you are an expert. This is actually the crux of the problem I think. Successful designers communicate their ideas before they ‘put pen to paper’ and provide solid reasoning for their choices afterwards.

Summarise all of your discussions in an email. Insist that they agree (or not) upon all of the points in the email before you start.
Ok, so that’s all done, now you have a choice:

Limited iterations

This is when you say to the client:

‘Ok, we will put together a design concept for you. You can come back to us with any modifications/comments once that will be incorporated into the design concept, anything after that is chargeable’.

I think this works well for small client, low budget work because everyone knows where they stand and possibly expectations are lower. Also, constantly going back over a design can affect the bottom line of a small project a lot more than a big technical project.

Averaging things out

The problem with this approach is that it can piss off your clients. You can end up looking petty or, even worse, you can end up making changes for free after the agreed cut off point (“it was only a 10 minute job”)&#…;

The approach that we have ended up with at Headscape takes the view that clients won’t pay time and materials for design concept work (they need a fixed price), so we have estimated what we think the average time spent on this work and charge that to all clients. This price is per concept but effectively allows unlimited mods to that concept. If a client wants multiple concepts then they pay accordingly.

Back to top

Paul’s corner: The international web

Just before I went on holiday last week I posted an entry on boagworld. On my return I was gob-smacked to see it had generated the most comments of any post I have ever added to my site.

The whole thing started with an email I received from a first time listener to the show. He was complaining about a joke I made at the expense of my american listeners. Those who listen to the show regularly will know that this is not uncommon and this listener felt the comments were inappropriate. I posted a throw away line on twitter about this and accidently started a debate on political correctness and international differences. Overnight I found myself thinking a lot about the subject and this lead to a blog post on the international web.

I started by apologizing if my humor caused any offense but the main thrust of the article was looking at the broader issues of engaging with an international audience. I found the challenges of working across multiple cultures fascinating and felt it applied to all aspects of web design (not just podcasts).

However, unfortunately the majority of comments I received focused on the apology rather than the points I was trying to raise. I really appreciated the encouragement found in the comments but would like to come back to this issue of culture and cultural differences when designing for the web. This is a challenge that we all face and I want to cover the 5 points I mentioned in my blog post again for the sake of those of you who do not read my blog.

Back to top

Ask the expert: Julie Howell on Accessibility

Paul:
Today I’ve been fortunate enough to grab a few minutes of Julie Howell’s time. Julie is the director of accessibility at a digital design agency called Fortune Cookie and is also the former digital policy development manager at the Royal National Institute for the Blind. She has also been involved, I believe if this is right Julie, that you were involved as the technical author for the PAS-78 or do you call it P.A.S 78?

Julie:
It’s pronounced PAS. Also RNIB is for Royal National Institute of Blind People if you want to…

Paul:
Oh, I missed out the People didn’t I. Oh well, there you go.

Julie:
Well it’s a recent change anyway.

Paul:
Ah, it’s to keep me guessing. Anyway good to have you on the show.

Julie:
Thank you.

Paul:
And obviously, unsurprisingly we have Julie in here to talk about accessibility [laughs]. You know, it’s kinda a no-brainer really. So I thought the best place to start is, well Julie, it strikes me, and I know a lot of the people that listen to our show, that the world of web accessibility seems to be a bit of a mess at the moment. We’ve kinda got WCAG2 that seems to be taking forever to come out. We’ve got now this thing called the WCAG Samurai, what’s all that about? They seem to be in competition with WCAG2. Then whenever you go into or if you are brave enough to venture onto an accessibility forum, they all seem to be fighting over tiny details and you are terrified to say anything incase you get jumped over. Do you think that accessibility is in trouble and if so, what can it do to dig itself out of the hole? What can the accessibility community do?

Julie:
You know, I don’t think there’s as big a problem as is being suggested. I think that what you have to keep in mind is perspective and context. There is heated debate on some areas of the web about accessibility, how accessibility will change or how the guidance might change moving forward in the great big wide world of web design. But in the much bigger world of commercial companies posting content on the web, there isn’t that concern. Everything seems quite stable. It doesn’t worry me at all that the techies or the geeks, and I mean that in the nicest possible way, are having heated debate because it’s really important. That’s how things change and improve and move forward. What is important is that we as people who are part of what I call the accessibility movement, who care about accessibility and who care about the lot of disabled people, keep presenting consistent guidance to the people who really can make the difference to disabled people. That’s businesses who are putting their services onto the web. The fact that there is heated debate about the technicalities I think is positive not negative.

Paul:
It strikes me that there is a little bit of confusion among the business community about what is actually expected of them. Things like the Disability Discrimination Act. They’re not sure how it should be interpreted in reality. Do you think there’s a case or there’s a need for more legal cases to be taken up so that the boundaries of accessibility are better defined?

Julie:
I think there’s a few things in there. I think that the greatest problem that we have, rather than it being arguments about the technicality, is actually a PR issue. We have guidance. We have the Web Content Accessibility Guidance and the other two separate guidance published by the Web Accessibility Initiative. We also have the document published by the British Standards Institution, PAS-78, and I guess we’ll talk about that a little bit more. What we lack is any consistent and well resourced drive to raise awareness of those documents among the community that needs to now about them and that is businesses. That for me is the missing part of the puzzle. Of course the guidelines will keep changing because the technology is changing at such a fast rate. So that I think is healthy. But what we really do need is more effort put into helping businesses understand the guidance that we have. Businesses should not be engaged in the technical discussions because that’s not where they fit into all of this. Businesses want clear, succinct, and that’s a huge problem I have with WCAG2, succinct guidance so that they just know what to… Businesses are saying to us, and I’m saying “us” as in the voluntary sector, the government, the Disability Rights Commission (DRC), that they care about the disabled peoples access and they want to do something about it. They just don’t know what to do. They are confused about which guidance to follow and to my mind, that is due to poor PR and not having any single government department or agency in the UK responsible for pushing the guidance. We’ve got individual organisations and voluntary organisations such as RNIB and RNID doing great work on their own but there’s no government force or business force behind it. Championing the guidance that we have and saying “Actually, there’s no confusion here. The guidance has been published, it is stable and this is all you have to do to follow it. Go forth and get on with it”.

Paul:
Let’s talk about PAS-78 a little bit in context of the business community and what they need to know. Correct me if I am wrong but my understanding of that document is that it was meant to be advice for people that run websites, website owners, to really get them up and running. Is that a fair assessment of what it was about?

Julie:
Erm… I’ve never heard it described that way.

Paul:
[Laughs]

Julie:
[Laughing] I would say that it’s there to provide clarity. We were concerned by the feedback that we were receiving that people in the business community were confused about the range of accessibility guidance that was available on the web. If you go to a search engine and type in “web accessibility”, you get all sorts of stuff back and some of it seems to be conflicting. So what we wanted to do with PAS-78 was pull all of the web accessibility guidance that’s produced by WAI, and also that’s produced by the software developers such as Adobe and others like Microsoft, all together into a single document that can be read within a couple of hours if you want to sit down and read it end to end or could easily be dipped in and out of, which was the definitive guide to the process of making a website accessible. The existing technical guidelines are not for business managers so we have written a document that is in a language that business managers can engage with, can digest, and puts everything together as a process. So it talks about guidelines and it doesn’t seek to create any new guidance. It points to guidance that’s already been published by WAI and others. But it also explains this is a process. This is what you do at this stage and it’s very important to involve disabled people at this stage; at this stage you should write an accessibility policy, later an accessibility statement. These are some of the questions you might want to ask when you are appointing a web design agency. So it puts all of that together in one document. That’s what we were seeking to do really. There’s a few words I used when I was launching it. Two of those words were harmonise and consolidate. It was nothing new. It was bringing together all of the guidance so there was absolutely no doubt. If anyone in the business says “I don’t understand what to do to make my site accessible”, PAS-78 is the only answer they need.

Paul:
OK. So where would they find and get hold of that?

Julie:
Well PAS-78 is free. Now it’s freely available because of the Disability Rights Commission. If you go to the DRC, the DRC have a licensing agreement with the British Standards Institution. So if you go to the Disability Rights Commission website you can download a PAS-78. It’s available in a variety of formats including accessible PDF. After all the medium is the message. The website address for that is http://www.drc-gb.org/pas.

Paul:
Well that brings us nicely onto WCAG then doesn’t it. What are your impressions are of WCAG2, how the WCAG Samurai stuff fits into that and what your current thinking is on all of this?

Julie:
Yeah, we live in interesting times as they say. I’ve been involved with WAI to a lesser and greater degree since 1995. A long time. I’m very conversant in the processes that are there. Now I’m a policy person and a disability rights campaigner. I’m not a coder. I’m not a geek, meant in the nicest possible way, and I’ve got no interest in become one either. I used to design websites but that was back in the day and it’s all very different now. What I care about is disabled people getting access to the web. I care that businesses are enable to make that happen. So as your listeners know WCAG2 has been in development for a really long time. That in itself troubles me because that makes it seem like disabled people are a huge nuisance and very, very difficult to cater for because an organisation catering in specialising to disabled peoples needs on the web takes many, many years to come up with guidance. I don’t like the message that puts out and I think that fuels some of that kind of confusion and misunderstanding and hence that’s why we did the PAS. It was so much quicker and it puts out, I feel, the right messages. People joke about it now don’t they. How long it’s taken WCAG2 to appear and that is because it’s subject to a very rigorous process of course but taking a long time. Now it’s in its latest drafting stages and I have to say… I’m sure you’ve read it or at least looked at it. I haven’t read it because I don’t have the time to read a document of that size. However, it’s not for me. It really is a technical manual now and as a technical manual, what is important is that those of you who are developing code and need to read the technical stuff are engaged by it, will read it and use it effectively. So that’s where the checking needs to be done. I think in the past where we’re getting some of these struggles at the moment, is because WCAG1 was a document for all. So you could read it if you were a developer and you could also have a good read of it if you weren’t and get something out of it. Looking at it now, it looks like a technical manual. Then, for me, it comes back down to PR. If it’s a technical manual then they to call it such and make it clear. If you put that on the desk of any business director general / CEO and well you can imagine the reception that you’ll get, who wants to read that? That said WAI always produce very comprehensive guides to their guidelines and curricular to help the various groups to apply the guidance correctly. They will do so in this case and again for me it’s down to PR. It needs to be made very clear to each individual group, developers, business owners, advocates as well, which guidance is for which group so that we don’t get people belly aching “Oh this is too long”, “I don’t have time to read a document of 100+ pages”.

Paul:
What hadn’t occurred to me there until you just said it, the fact that this applies not just to people like Adobe and Microsoft but also applies to me potentially. If I’m developing a web application that enables users to contribute and upload content then in effect I’m being an equivalent of a Facebook or a Myspace and I need to be aware of those kinds of accessibility issues there are well. It’s quite interesting.

Julie:
It is and then it gets more interesting when you look at it in the context of the law in this country. We have the Disability Discrimination Act and that puts, and I choose these words very carefully, a legal duty on “service providers”. Now software developers are not covered by the DDA. However, the line is blurring. If a website is inaccessible, say a blind person goes to a site to do some shopping and it’s inaccessible, who’s responsibility is it? Whose legal duty is it that the site is accessible? Well it’s the owner of the business because it’s their service. But there’s an argument that the developer who coded the site has aided and abetted the discrimination. But we don’t have any case laws so this is all theoretical until we do get some case laws to back up what were saying. However software developers are not subject to the DDA. There’s a blurry of the lines, in my opinion, between a service provider and a software developer. But if I was to take an educated guess, if a disabled person experienced an instance of discrimination as defined under the Disability Discrimination Act and that happened because they tried to utilise a server via somebody’s page on a social networking site, who would be responsible? That would be very interesting. We also have the DDA, the Disability Discrimination Act. I have Multiple sclerosis. Everybody knows this. I’m very open about it and it really informs my work. Being somebody who stands to benefit, stands to live my life as I choose to and prosper because of the DDA, I can tell you from this side of the fence that the DDA is a very weak piece of legislation as it is. We don’t to date have any case law regarding websites but even if there was a case, it would take quite a number of cases to have any useful body of guidance other than what we already have and know as is published in PAS-78. Really that is your best guide. So yeah, interesting times that we live in. What I would say is that would hope that anybody who is responsible for social networking has a social conscience and cares very much about the ability of every member of society to be able to use the content, to both access it and create it. Unfortunately, disabled people don’t always figure in the planning process when people are putting together solutions and this is again where the web accessibility needs to keep on ramping up that awareness effort to get everybody to understand and to be thinking about disabled people at the earliest part of the conceptual process for new technology. It’s an issue we’ve always had that with web accessibility we’re always running to catch up because new ideas that come to market on the web really, really quickly and the trick to it, in my opinion, is getting close to the innovators, throwing in their face and keep on reminding them. Today we’re talking about accessibility of social networks, tomorrow it will be something else but I’ve got no idea what it’ll be.

Paul:
OK. So just before we wrap up let’s bring it back down to the more mundane day to day level. There will be a lot of people that are listening to this podcast and listening to our conversation thinking “Wow! This seems really overwhelming. It all seems very complicated. There seems to be talking about us having to get disabled people in to do testing, that sounds very expensive. There are legal obligations here and that sounds very scary. There are these various technical guidelines and they all seem very confusing.” Just to those people that are web sites owners that have perhaps buried their head in the sand so far about accessibility. What little step would you suggest to them? Just to get them going. Just to make the first tentative steps into the world of making their site more accessible.

Julie:
The first document to read is PAS-78 which is free of charge. It’s only about 60 pages and that’s in large print. It really is quite an easy read. We made sure of that when we wrote it. PAS-78 sets it all out in plain language. It’s very much written with the business audience in mind. I’d also offer some encouragement. Have a look at some of the case studies, you can easily find them on the web, of big companies that have applied accessibility and are profiting from it. An example being Legal & General, the one that I talk about a lot at the moment. Legal & General had a 300% increase in the take-up of one of their financial products via their website after they made the site more accessible.

Paul:
Wow!

Julie:
300% in a matter of months. You wouldn’t dare set that as a business target. It astonished me and I’ve long believed in this stuff. 300% is amazing. There’s also been a lot written about Tesco. Tesco take millions more in extra business away from their competitors because they’ve made their site more accessible. Accessibility is a good news story. There is money to be had through accessibility. If you make your website content available to the biggest possible audience that you’re tapping into a much bigger pot of money. Disabled people as a group in the UK alone are estimated to have an annual spending power in the region of £85 billion! An incredible amount of money that someone needs to exploit, to capitalise one. Disable people are very happy to be marketed to. Perhaps more so than other groups because disabled people, in particular blind people, are not exposed to advertising and therefore not exposed to a lot of choice that those of us that can see take for granted. Accessible sites are also interoperable sites. They work well on different platforms. If you make your site accessible for a PC you’re making it accessible for many other technologies including a mobile phone which people are using increasingly more now in the UK. Yes, there is a legal imperative as well. I wouldn’t be afraid of that though. There’s a long process involved in that. The DDA to safeguard disabled people’s rights to participate in society. Now indeed when a disabled people feels and finds that they have been discriminated against because of the way a web service is presented to them, of course they are going to feel angry and upset. I have long said I have never understood why I should be able to use a product or service to buy some tickets online because I can see but my blind friend can’t. To me that’s completely unacceptable and unnecessary discrimination. However it’s not a case of “Oh I’m not happy” and we’re all in court. There’s a process there of conciliation. The DRC is involved in that process or it can be, as well as a number of disability organisations because what we want is not to take anybody to the cleaners. It’s to make the web more accessible. The key to that is my mind is dialog. When I used to work at RNIB, if a blind person contacted me having found a website they couldn’t use and it was one of the bigger ones. This is what happened with Tesco. 40 blind people got onto us saying they couldn’t use Tesco and they wanted a legal case to be taken. This was tremendous because it’s alerted Tesco to this issue and it meant that we were able to start a dialogue, the result of which is hundreds if not thousands of blind people are now able to do online shopping for their groceries and delivered to their home which is wonderful. Tesco is not unhappy because it’s bringing in a lot more money through that channel where it wasn’t bringing in any previously from disabled people because it was inaccessible. What we are trying to achieve here is sustained change that will see disabled people included in society to the degree that it would seem outrageous and ridiculous not to do so. Big changes happen. I never thought I’d see smoking banned in public places. I can’t believe it. My goodness if we can do that as a society we can change the way we behave towards disabled people, stop belly aching about the issues and talk to each other about working towards solutions. I’m optimistic that in 20 years we’ll see disabled people much more included in everything that we are all doing now to keep the debate about disabled people and accessibility alive, contributing to a brighter future for disabled people. We should just keep on doing what we are all doing.

Paul:
Excellent. Thank you so much Julie for taking time to come in and talk about that. It was really interesting. I hope to get you back in again in the future before too long.

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.

Show 86: Boagworld Book

Posted in Classic shows on by Paul Boag

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

Play

Podcast: Download (44.6MB)

Download this show.

Launch our podcast player

Paul’s personal news

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

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

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

News and events

Building for the iphone

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

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

@media podcast

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

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

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

Common mistakes in web copy

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

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

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

A department dedicated to the web

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

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

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

Paul’s corner: Taking a brand online

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

I have also put together a blog post on the subject of “taking a brand online” and it is this that I cover on the show.

Marcus’ bit: Information architecture review

I am currently in the process of carrying out an information architecture review for a new Headscape client. I have done a fair amount of IA work over the years but I have found myself particularly enjoying this one so I thought I’d waffle on about what I’ve been doing.

We have covered the various aspects of IA work in previous podcasts – Expert Review, Stakeholder Interviews, Card Sorting and Wire Frame testing. This section is looking at the first of these, expert review, in a bit more detail.

I think it’s worth explaining what I mean by Expert Review. When we carry out an Expert Review we are effectively analysing a client’s existing site content, site structure and naming conventions with a view to creating a new IA based on our experience of using and developing websites. This is a collaborative process with the client – it has to be; we can make logical, usability based decisions but cannot claim to be experts in the client’s particular field.

First things first

I make sure that I have a good grasp of a number of things prior to carrying out an IA review. At the kick off meeting make sure the following are covered:

  • Target audience – this is crucial for the development of the IA. It may be that the existing site caters for one group well but another poorly.
  • Site aims – is there a stepped process that the client wants their users to go through.
  • Design – things like horizontal over vertical navigation can affect the IA.
  • Homepage requirements – find out what the killer apps and content are as these will need to be linked to from the homepage.
  • Finally, have a general discussion about content and site structure. See what the client thinks is important and what’s not.

Map out the existing site

The first thing I do is map out the existing site’s IA. This is a fairly slow and laborious task but it is the best way to not only learn about a site’s content and structure but also to understand what they do and what they offer.

Be logical, captain

Usually, the goal of this type of exercise is to streamline content into groups and name those groups so that users will understand what’s inside them.

Site’s that have grown organically over a period of time tend to spread content all over the place. It is usually fairly easy, though time consuming, to group content together. There are various methods for doing this; I tend to print out the existing site IA (that I usually create in Excel unless it’s a particularly small site, then I might use Visio) and scribble all over the printout until I’m getting somewhere. Some people like to use cloud/cluster diagrams (either on paper or using software) or there is always the age old method of creating ‘cards’ where each page name is written onto a scrap of paper. This is a bit like doing card sorting on your own where you group the cards into piles and give names to each pile.

Naming

We come from the ‘it does exactly what it says on the tin’ school of page/section naming. Marketing departments often don’t! A good example of this is the trend to verbs as section names over nouns. I remember one client wanting to call a site section ‘Enjoy’ when the section covered ‘Leisure Activities’. No prizes for guessing what we recommended!

Labels should be as descriptive as possible. Sometimes this can be difficult when:

  • there isn’t much space, for example, ‘How to register for our newsletter’ won’t fit on the average button, even ‘Newsletter Registration’ would probably be too much for a top level, so I would go for just ‘Newsletter’. It’s fairly obvious that the content underneath will relate to the organisation’s newsletter and should logically include registration, whereas ‘Register’ leaves the user asking ‘register for what?’
  • Sometimes sites are so big that main sections can include too much differing content to be labelled descriptively. In this case, I would recommend either shortcuts on the homepage replicating the main sections that include descriptive words or create drop down navigation that displays the lower level links.

Section ordering

This should follow some sort of desired path through the site. For example, the client may want users to get a bit of background, followed by an understanding of what the organisation offers, followed by some examples of previous work with a view to finally making contact. This would translate to:

About Us | Services | Case Studies | Contact Us

Conventions

Users don’t want to have to think (that sounds familiar!); they want to look and understand straight away. Following conventions helps with this process. For example, many sites include an About Us section as the first main section. This usually includes some history, annual reports, job vacancies and contact details. Users looking for this type of information don’t want to have guess that this information might be under, for example, ‘Company Background’ which is located at the far right of a horizontal navigation.

Collaborate – to a point

When you have created your first draft it then needs to be reviewed by the client, discussed and iterated until everyone is happy. Take on board any changes that are based on your lack of understanding of what the client does but be prepared to stand your ground on issues relating to web conventions and usability – after all, they’re paying for your expertise.

Ask an expert: Ian Lloyd on screen readers

On this week’s show we have Ian Lloyd giving us an introduction to the world of screen readers. I vividly remember the first time I heard a screen reader being used. I was gob-smacked by how painful an experience it was and I am still amazed that anybody manages to use them effectively.

It struck me that many of you listening to this show might not have heard a screen reader before. Hearing what blind people have to work with really makes you take their needs seriously and so I thought I would get Ian on the show to give you a taster.

In his segment, Ian takes us through some classic problems that screen reader users experience. Unfortunately to best understand what is going on in some of the examples you need to see what he is doing. In order to get around this problem Ian has made a screencast to accompany the audio. There was too much detail to make it available online or via your video pod but you can download the screen reader .mov file here.

What follows is a transcript of Ian’s section of the show…

Hello Paul, Hello Marcus and hello to listeners of Boagworld. This is the ‘Ask the Expert’ section and today I’m going to be talking about screen readers.

Now, I don’t actually qualify [meant to say classify!] myself as an expert screen reader user simply because I don;t use one on a day-to-day basis, because I’m not forced to; I do have good vision. As such, the way that I would use a screen reader would be different from someone who has to use it on a day-to-day basis. That said, I still think it’s useful to demonstrate to people what a screen reader sounds like. And the reason for this is that as far as I am aware on your podcast although you’ve talked about accessibility a lot and mentioned screen readers I don’t believe we’ve ever had a demonstration of what they actually are like for people when pages are built incorrectly.

So, today I’m going to be showing a few problems using a screen reader. I’m also going to be doing this as a video, so this is a screencast. I understand that at the end of this you will be providing a URL for listeners so that they can access this and view what’s happening on screen. Because of course it’s all well and good to listen to this stuff but to get the full context it would be good to actually see the video as well. I will try my best to describe what’s happening on screen throughout this podcast though.

Now the first example we’re going to look at is Amazon dot com. And somewhat cheekily I’ve brought up the page for my own book on Amazon. And, er, just having a look around at what I can find on the screen and there are some issues there. So, let’s have a look at this.

[Screen reader reads out page graphic correctly 'Build your own website the right way using HTML and CSS, Link graphic']

Oh, so that’s not too bad. I’ve just found an image there and it’s announced it correctly because it’s found a suitable alt attribute but underneath there are a couple of thumbnail images which, if I want to access those, it gives me a whole different … well, hear for yourself:

[Screen reader announces: 'See larger image, Link' then moves to next link, the thumbnail image and reads an unintelligible string of characters - numbers letters and underscores - out to the listener].

Mmm, doesn’t make an awful lot of sense does it? Let’s try the next image:

[Screen reader reads out more unintelligible characters and takes almost 8 seconds to read it out]

So, what’s happening there? Well, it’s quite simple: there’s no alt attribute defined for that image and so JAWS tries to fill in the gap and, er … oh I didn’t mention earlier that JAWS is the name of the screen reader that I’m using. So it tries to fill in the gaps because it doesn’t have an alt attribute it uses the file name instead and the filename, as is often the case on Amazon, is a right load of old gobbledegook! So it doesn’t give it any useful information about that image.

Here’s another example of the same thing.

[Screen reader reads out an image gallery as 'thumbs slash zero, thumbs slash one, thumbs slash two' etc]

So this is actually a photo gallery, erm, with a bunch of thumbnail images hence it’s reading ‘thumbs’ because that’s the folder where the thumbnail [image] is actually in and it’s reading them sequentially as well. It doesn’t sound quite as painful as the Amazon example but it still doesn’t tell you any useful information about the images on the page.

[Screen reader announces more examples from the same page]

So let’s listen to a slightly improved version of that:

[Screen reader announces the same images but with appropriate alt attributes, e.g. 'The Mystery Machine, driven by Scooby' for a photo of a camper van that is painted like the Mystery Machine from the cartoon Scooby Doo]

If we were to look at that on the video I’m showing that page with the style sheet disabled and the alt attributes displaying inline next to the image. As you could hear in the second example it was far more usable – you could actually understand what the image was about (as long as you understood some of the VW terminology used in there), whereas in the first example none of the images actually had alt attributes so it was just trying to read out the location of the file.

So let’s look at another example.

[Screen reader announces content of new page 'Page has no links' and then starts reading subsequent page content before I stop it]

What I’m looking at on screen is a page that seems to have a page full of links. But if you were listening carefully to the beginning of that, the screen reader thought otherwise. I’ll just try to find that again for you.

[I scrub back in the video clip to find the part where the screen reader says no links]

According to the screen reader the page doesn’t have any links. And the reason it thinks that is, well, there *aren’t* any links. What’s actually happening … is … we have a whole bunch of text on the page that is styled using CSS and the behaviour for the link is added using JavaScript. So, we have a <span> element that has an onclick event, location.href=’somewhere.html’ and that’s [the span] wrapped around the text that says ‘This is a link – click me’. Um, but of course it’s not a link. The screen reader can’t find it because it’s not an <a href="">, it’s something else that’s been styled to look like a link and behave like a link. But it’s not. Thankfull that’s not too common but you have to just be aware that what may look great on screen for you may not be any use to someone using a screen reader. You have to use the right markup for the job.

So, you could have a page that’s full of links that say ‘click here’ but of course that’s another problem all in itself. Let’s have a listen to that:

[Screen reader reads 'Click here to view' repeatedly as I tab through the links on the page]

Yes, so … the problem there is that it doesn’t give you any information at all. And this is actually still quite common. In fact just yesterday I was looking at Facebook dot com (for my sins) and, er, I was quite shocked to find that they were using a lot of this where the link phrase was ‘click here’ as opposed to the phrase that you would really want to have, so for example instead of saying ‘click here for more information’ and having ‘click here’ as the link phrase you would have ‘for more information about our products’. That would be the link phrase. Erm, but if you just use ‘click here’ and you’ve got a whole page of links that reads ‘click here’ this is what you get:

[Screen reader once again reads 'Click here to view' repeatedly as I tab through the links on the page]

Basically, completely unusable.

Now the next example I have is of a form, and in this example, er, the form has been laid out using a table. Thankfully, these days, tables are being used less for layout and people are using CSS for page layouts. However, for forms it’s still not uncommon to see someone put a table in there. And, er …

[screen reader interrupts as page loads]

OK, so in this example what I’m looking at on screen is what appears to be, um, well … four text inputs, and then there is a radio button and it’s basically asking for some personal information, first name, surname, your age, place of birth and then a question ‘Do you have a nut alergy’, the answers being ‘no’, ‘yes’ or ‘don’t know’. So let’s see what the screen reader makes of this.

[screen reader says 'table with two columns and four rows'. I tab to the first input and it reads 'surname/family name - edit']

Already we’re hitting a problem. Because the first field that I tab to I can see on screen is *actually* [the one for the] the first name . But the screen reader believed that to be the surname.

So I’ve now tabbed to the second field which is the surname and it didn’t announce anything. So let’s tab to the next field:

[screen reader announces field as 'town/city - edit']

Again it’s getting it wrong. I’ve actually tabbed to the field that says ‘Age next birthday’

[tab to the next field, screen reader announces 'tab - edit']

And *now* I’m in the ‘town/city of birth’ field and it hasn’t told me anything.

[screen reader announces 'yes - radio button', then 'don't know', reading the radio button choices]

This is all a bit confusing here. OK, so it’s asking me the question ‘Do I have a nut allergy?’.

[I tab to the next field, screen reader announces 'Yes - radio button - unchecked']

OK, so … that thinks I’m at the yes radio button but I’m looking at it on screen and it says ‘no’. So, what’s going on here? Now this is going to be a difficult one to explain on the podcast; this is one of the sections where you really need to see the video. But what’s actually happening here is we’ve got a table to lay out the page and the text sits above the text input, so for example where we’re asking for first name, the text that says first name is in the first column and the input that relates to that is in a column underneath, sorry, I mean a table cell underneath it in the next table row. Now the reason this is causing a problem is because if you were to actually linearize that table, in other words look at it in the order of the source code you get a very different view of it. And this is what happens with the screen reader. So if I were to look at this form and read it out in a linear fashion, it goes like this:

First Name [text]
Surname [text]
Form input for First name
Form input for Surname
Age [text]
Town/City of birth [text]
Form input for Age
Form input for Town/City of birth

And so on. The problem is that the screen reader expects the text for that input to appear before that input, and because of the way this has been laid out it really really gets things confused. As I said, this is quite a difficult one to explain on the podcast but if you look at the video clip you’ll see why this is causing a problem.

[screen reader blurts a few things out as I try to manipulate it ... poorly]

Sorry about that, that didn’t add anything useful at all. Hopefully Paul can edit that out!

OK, so …. the big problem here is that you may be asking a question as we have here that says ‘Do you have a nut allergy?’ and the answers are ‘no’, ‘yes’ and ‘don’t know’. But if you do put the form elements in the wrong order you’re gonna have a problem. And the reason is obviously that with a nut allergy that could be a life or death situation. You could be filling out a form as a blind user and you select what you think is the ‘yes’ radio button but because the form has been poorly laid out and doesn’t have <label> elements that are actually helping to enforce the accessibility you may actually have been selecting the no checkbox [meant to say radio] and it really could be a life or death situation. It may *not* be as bad as that – it could end up with you booking the wrong hotel location or date. So you have to be very careful with the form layout.

OK, one final example. Now everyone’s talking about AJAX, it;s the buzzword of the moment. Unfortunately it’s also not very good for screen reader users. And the reason for this is that, er, anything that is updated on the page after page load is very very problematic to pass on to the screen readers. now the example I’m going to give here is a fairly simple one, and it’s the Google Suggest page. What Google Suggest does is let you type in your search phrase and as you type it’s calling back to the server, finding suggestions for you which it then populates in a list underneath the search input. So let’s have a listen to that.

[screen reader announces: 'google search - edit, type and text' then reads each letter of search term 'this is a test' as I type]

So I’ve just typed ‘this is a test’ and on screen underneath that is a whole bunch of suggestions that it has found. But if I try and actually access any of those using the keyboard:

[screen reader announces 'Google search - edit, Google search - edit, Google search - edit, Google search - edit' with each keypress on the down arrow]

It’s actually doing nothing. On screen I can actually see that it’s going up and down the options but the screen reader, it’s getting nothing back at all, nothing useful at all.

[more screen reader confusion]

Well thankfully with Google Suggest this is something tat you can opt out of – you don’t have to use Google Suggest, it’s not enforced on you. But it’s a very simple example and it just goes to show that a very simple technique like this can be, basically, completely unusable for someone using a screen reader.

So, that was just a few examples. Hopefully you’ve had an indication of how a poorly built website or web page can affect a user. the bottom line is, keep listening to the podcast, keep doing things right, keep using good markup and, if you can, test your own web pages or web sites using a demo version of JAWS. It really does pay dividends to find out how this works – or doesn’t work. So, thank you very much, I hope this has been useful, and I look forward to the next podcast, Paul. Thanks guys.

No show next week

Unfortunately there will be no show next week as I am away speaking at the Institutional Web Management Workshop. However we will be back the week of the 23rd July.

Website feedback mechanisms

Posted in Marketing on by Paul Boag

For many businesses a website is a lead generation tool. However, although a lot of thought is put into the website itself, very little is put into the gathering of the leads that result from the website.

As normal, when I returned from holiday I found myself faced with a mountain of email. Among the pile I have found several enquiries from the Headscape website which have remained unanswered for the week that I was away. Obviously, this is not good and it has started me thinking about how we as website owners handle enquiries and feedback that come from our websites.

As far as I am aware there isn’t much written on the subject of enquiry processing, which is strange considering that correspondence between website owners and site users is fundamental to the success of many sites. As nobody else seems to be talking about this much I thought I would jot down my thoughts on the subject.

Mechanisms for feedback gathering

A good place to start is by examining the methods you allow users to communicate through. It is easy to underestimate just how many options are available and each has its own pros and cons. Think carefully about your site and the people that use it. Are you really providing the right mechanisms for your users?

Email

Email is probably the most common form of communication from a website to its owner. Its easy to add an email address on your website and a lot of users prefer to email directly rather than use a form, because they can then keep a copy of the correspondence.

However, email is not without its problems. Not every user has an email address or access to their email client at a particular time. Also publishing your email address on a website opens yourself up to spam. There are ways to mask your address from spammers, but this often creates accessibility problems.

Forms

The next most common option is to allow communication through forms. A contact us form has an advantage over email because it doesn’t require the user to have an email client. However it can still suffer from spam. One advantage of a form is that it allows you to funnel emails in different directions based on the type of user enquiry. For example if a user specifies the message as a support query it can be sent to a different person than a sales enquiry.

Forms are probably the most versatile and powerful communication technique available and certainly work well on larger sites. However they are not always the right solution 100% of the time.

Forums

Although forums are often perceived as “user to user environments” rather than “user to website owner”, that doesn’t have to be true. Forums are an excellent way of communicating directly with your users. They are particularly good on a site where the enquiries are not confidential in nature and where you are getting the same enquiry again and again. A typical example of this is a support forum. By answering a support question publicly you avoid having to answer the same question multiple times and empower users to find their answers quicker without having to wait for your response.

Obviously, this approach wouldn’t be appropriate for sales enquiries and it still can suffer from spam however in certain circumstances forums can be very powerful.

Comments

Comments are a growing feedback mechanism, made popular by the growth of blogging. In many ways they provide similar benefits to a forum however they are slightly more limiting. On a forum a user can start a new thread dedicated to any subject they choose. When posting a comment it is normally attached to an existing web page on a specific topic. Although this is restrictive it can be appropriate if you are looking for feedback on a specific issue and want to avoid too much secondary discussion.

Ratings and reviews

Ratings and reviews can work particularly well when you are looking for feedback on a product line or article. Although ratings provide only limited feedback (a score) this also means that it is very easy for a user to participate. The ease of contribution makes it more likely a user will feedback than otherwise would have been the case. This approach works well when a website owner wants feedback on a specific web page. Having questions like “did this page answer your question. Yes or No?” is much more likely to get a response than an open comments box.

Live chat

More and more sites are introducing “live chat” facilities. To be honest I have mixed feelings about live chat. On the right site I am convinced it can be a powerful tool, however it can also create usability and accessibility problems. The best use of live chat I have seen is for answering support queries. They allow users to get instant answers without having to pay international phone call rates to contact foreign websites. They also allow website owner to handle a greater number of simultaneous enquiries than would be possible on a phone call. However live chat can be intrusive when the website owner initiates the conversation and on smaller sites the demands of having somebody available to answer queries can be prohibitive.

Of course, unlike every other method mentioned so far, live chat doesn’t seem to attract spam and so in that regards it is appealing.

Instant messaging

A cheaper and easier to implement alternative to live chat is simply to publish an instant messaging address on your site. Of course this does require your visitors to have an instant messaging client installed but that is less of an issue these days. Although instant messaging is a nice extra to have, I don’t think it will ever be more than an alternative for people who particularly like to communicate that way.

Offline mechanisms

It is easy to forget offline mechanisms of communication such as telephone and post. In fact it is surprising just how many organisations fail to include their telephone number and postal address on their sites.

Different mediums are good for different things and although a website can be an amazing tool there are some times when you just want to pick up the phone and talk to somebody. If you fail to put traditional contact information on your site then you do it at your own peril.

Dealing with feedback

Although the different communication methods are interesting, I guess the real question is how do you deal with enquiries when they come in (from whatever source). It is in this area that my own site currently fails and that is what got me thinking about how we approach the problem with our clients. This is the advice we normally give:

Feedback manager

One of the biggest problems I encounter when it comes to handling enquiries is that nobody sees it as there responsibility. Probably the best thing that can be done to improve how feedback is handled, is to ensure that there is at least one person in the organisation that has a clearly defined responsibility to respond to these correspondence.

Depending on the size of the website and the structure of your organisation, this may need to be multiple individuals, but the key is to ensure that these individuals are in no doubt about what is required from them.

Collection mechanisms

As I have learnt from personal experience over the last week the way that feedback is collected and processed is crucial. When somebody completes an online form where does it go? What happens if the person collecting those emails is away? How do you make sure that email is not lost in transit? How do you ensure the feedback has been responded to?

I remember working on a classic example of a bad collection mechanism a few years back. We were working for a travel company would created personalized quotes based on a form completed via their website. The problem was that enquiry form was sent as an email to a public folder in outlook. Sales staff would check that folder periodically and respond to any outstanding emails.

The whole process was incredibly painful. The folder wasn’t checked regularly enough and sales people would cherry pick the best leads leaving many emails unanswered in the hope that some other “sap” would deal with them. Emails would be responded to multiple times in some cases while others were simply lost in the scramble.

Eventually we built them a backend system that allowed administrators to assign enquiries and track their progress through the system, as well as provide reporting on response times and conversion.

Having a clearly defined and efficient mechanism for dealing with feedback from your site ensures that nothing slips through the cracks.

Speed of response

Ensuring that you respond quickly to enquiries is one of the best ways of differentiating yourself from your competition. One of the most common ways of achieving this is with an automated response as soon as a form is completed or an email sent. Although these kind of responses do provide some value as they let the user know the enquiry has been received, they do nothing to improve the users perception of your service. Automated response are impersonal and are the email equivalent of an automated telephone system saying that “your call is important to us”.

In my opinion nothing is better than a quick personal email thanking somebody for their enquiry and promising a more detailed response as soon as possible. Of course this isn’t always possible if you are dealing with a large number of enquiries, but for most businesses this is more than achievable.

Tracking feedback history

There is nothing more annoying than having to repeat yourself and with electronic communication at least, there should be no need to do so. Make sure that whatever system you use to track feedback also has the ability to archive and retrieve previous correspondence so that you don’t need to ask the user to cover old ground.

Personally I am a fan of customer management systems that allow for the tracks of all correspondence with a client whatever method is used. There are loads of greats systems around with something appropriate for your business, whatever its size.

Choosing a response mechanism

Finally I wanted to mention the mechanism by which we choose to respond to an enquiry. I recently listens to an interview with the authors of “Send: The How, Why, When – and When Not – of Email” who talked about the importance of knowing which medium to use in communications. The temptation is to respond in the medium with which you were originally contacted. For example, if somebody sends you an email you should respond with email. However, depending on the nature of the enquiry and the dialogue you need with the enquirer, it might be better to pick up the phone, instant message them or even use good old snail mail.

As with so much in life, always pick the right tool for the job.