How much to blog?

I recently received a question from Dan about ensuring the quality and quantity of his blog posts. With so many of us blogging I thought it might be an interesting areas to cover.

Over 66% of blogs have not been updated in over 2 months and anywhere between 60% and 80% are abandoned within their first month. It is very easy for a blog to go from a good idea to an embarrassment.

The main problem is that blogging is a lot more work than people expect. Regularly coming up with quality content over the long term is a significant challenge and many individuals and organisations find it hard to keep up.

Many bloggers struggle with getting their posts right. They feel the pressure to post regularly but also want to maintain the quality of what they put out. I think Dan reflects the feelings of many bloggers in the question he sent to me…

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

I get the sense that Dan is keen to lighten the load and understandably so. However I think that by doing so he may undermine the effectiveness of his blog.

Let look at the two questions he raises.

Do I still need to post regularly and frequently?

Dan is right when he says the prevalent thought is that bloggers should be posting frequently and on a regular schedule. However, I believe this is about more than drawing people back to your site.

The amount and regularity with which you post depends very much on why you are blogging in the first place. If you are blogging purely for fun then it really doesn’t matter how often or how regularly you post. However, if you blog for more commercial reasons or even to build your personal profile then it does matter.

Blogging is a powerful way of continually keeping your brand (whether that be personal or corporate) in somebody’s mind. For example if I only posted once every few months the chances are you would soon forget about me and fail to include me in that invitation to tender for that great web project you are working on! Equally by posting regularly you build an expectation (either consciously or unconsciously) and users start to miss your when they are not there. For example, every time I take a week off of recording boagworld I always receive emails saying that the show was missed. Even the absence of a post can keep your brand in people’s mind if you are posting regularly enough.

Of course Dan’s point about RSS feeds is a valid one. In a world of RSS the need to constantly encourage people back to your site is less. However, you need to be careful not to make assumptions. Yes it is true that if you are aiming at the geek audience there is not the same need to post regularly and frequently. However, if you are aiming at a mainstream audience I wouldn’t be so sure. Feeds are still a long way from being universal and many users still do not know how to get notifications via RSS.

There are endless debates online about how often you should blog. To be honest there is no single answer. It depends on multiple factors including audience, subject matter and the popularity of your blog. However as a rough starting point I would encourage most people to blog at least once a week. Of course if you have a particularly popular blog that figure might be nearer two or three times a day!

However, blogging isn’t just a matter of frequency its also about the quality of the posts. That brings us nicely on to the second part of Dan’s question.

Is quality or quantity more important?

Should the emphasis be placed on posting regularly and frequently or on ensuring a high quality of post? Personally, I am not sure that this is the best question to ask. I think instead the question should be “how do I create something relevant to my readers?”

If you are writing a blog aimed at academics then the chances are the emphasis should be on quality. If you are writing to friends and family they are probably more interested in hearing from you regularly. However, for those of us who have an audience somewhere in between there are ways that you can have the best of both worlds.

Consider defining a list of several different types of posts you can add to your blog. Some of those types can have an emphasis on quality while others can be quick and easy so they can be used more regularly.

Take my blog for example. I post the show notes which tend to be very detailed and take a long time to put together. Then there are opinion pieces like this one, which are more frequent but not quite as detailed. Finally, there are links to other resources. It takes seconds to bookmark and comment on a link and so these appear on a much more regular basis. By using these different styles of postings you can ensure a frequency on your blog without losing the quality of what you are publishing.

Conclusion

Obviously, there is a lot more that can be said about blogging. Indeed entire books have been written on the subject. However, in answer to Dan’s question I strongly believe that posting frequently and regularly is still very important. The trick is to do this without overly compromising the quality. Having different styles of post will help with that but you may also want to get others involved in posting. The only downside of this in my experience is that a lot of people who offer to “help out” fail to deliver the goods.

Show 90: Digg

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

Play

Download this show.

Launch our podcast player

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

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

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

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

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

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

News and events

Eric Meyer tries to prevent history repeating itself

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

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

“Your browser is not compatible and must be upgraded”

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

“This site is for iPhone users only.”

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

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

6 Keys to Understanding Modern CSS-based Layouts

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

As Jonathan says in his post…

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

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

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

How to mix fonts

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

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

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

Making money through forums

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

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

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

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

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

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

Back to top

Daniel Burka talks about Digg

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

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

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

Daniel: [laughs]

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

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

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

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

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

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

Paul: Oh okay

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

Paul: Hmmm.

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

Paul: Yeah.

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

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

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

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

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

Paul: Hmmm.

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

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

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

Paul: Ummm.

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

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

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

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

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

Paul: Yeah.

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

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

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

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

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

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

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

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

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

Paul: Yeah.

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

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

Daniel: [laughs]

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

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

Paul: Ahhh.

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

Paul: Ahhh.

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

Paul: Okay.

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

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

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

Paul: [laughs]

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

Paul: Yeah.

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

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

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

Paul: Sure.

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

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

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

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

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

Paul: [laughs]

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

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

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

Paul: Oh I didn't know that.

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

Paul: Yeah. [laughs]

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

Paul: Yeah

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

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

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

Paul: Yeah.

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

Paul: Yeah.

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

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

Daniel: Right.

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

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

Paul: Cool.

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

Paul: Yeah.

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

Paul: [laughs]

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

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

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

Paul: Yeah.

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

Paul: [laughs]

Daniel: [laughs]

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

Daniel: Shoot! [laughs]

Paul: [laughs]

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

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

Daniel: That would be fun.

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

Daniel: Thanks so much for having me.

Back to top

Paul’s corner: Quick and dirty competitive analysis

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

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

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

No show next week

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

Back to top

Show 83: iphone bollocks

On this week’s show: Paul talks about the importance of undo, Marcus explains the benefits of stakeholder interviews and Struan Robertson highlights some legal deathtraps waiting for us online.

Play

Download this show.

Launch our podcast player

News and events

Safari for Windows

Probably the most talked about story of the last week is the fact that Apple have released Safari for windows. To be honest I am a little surprised just how much has been written about this considering I don’t think the impact is going to be that significant. Will Safari cut into Internet Explorers market share? Probably not. Will it undermine the market share Firefox has developed? Almost certainly.

If safari under windows rendered exactly the same as under OSX then there maybe some benefit to windows based web developers. At the moment it is impossible for them to test on Safari without buying a mac. This has the potential of changing that. However, in all likelihood differences will emerge and if they do then this is just another browser that we have to test against.

We will see.

Applications for the iphone

At the same time Steve Jobs announced Safari for windows he also talked about the iphone. The biggest criticism of the iphone to date has been the fact that it is locked down so third parties cannot develop applications for it. Apparently Apple have been thinking long and hard about the problem and have come up with a solution. They are going to allow developers to build web 2.0 applications that can be accessed by iphone users using the built in Safari browser.

What a load of bollocks. They are telling us something we already knew. As soon as Steve Jobs announced that the iphone carried a full safari browser we knew that web applications would be developed for it. Sure, they are now saying that methods are going to be provided to automatically access iphone features such as dialing and google maps but very little detail was given. As far as I can see Apple is not giving people anything more than they already had.

Jason at 37 Signals is excited about what this means for web apps. He says…

This is the coming out party for web apps. We are very excited about this. These are exciting times.

…and he is right. It is exciting for us web developers. However, I am not convinced the user will see it that way. David Shea mirrored my own reaction at this news when he simply posted a graph showing the astronomical cost of data calls on mobile carriers. Web applications are great for web designers but for users of mobile devices like the iphone they could quickly be prohibitively expensive.

Web Design-isms: 7 Surefire Styles that Work

I found a great article on Think Vitamin this week that talks about design trends on the web. One of the things you learn early on as a designer is that despite your desire to produce something completely original you never will. Everything has been done before and in this article Larissa Meek takes us through 7 styles of design that appear again and again on the web.

The article very much reminded me of design meltdown, an excellent site that showcases different approaches to design. However, what I particularly liked about this post is that the author showed examples of how these styles occur in art as well as online. This is nice because it encourages us as web designers to look beyond the web for inspiration, a subject I have spoken about before.

CSS frameworks

The final story caught my eye because it is an extension of something we have been doing for a while. A while back I talked on the show about the fact that Headscape work with standard XHTML templates. We use these templates as a starting point for development. They allow you to jump start the build process as well as ensure consist naming conventions across the entire design team.

In a new post on the List Apart website Jeff Croft proposes a similar approach for CSS, based on the concept of Frameworks. Jeff argues that certain aspects of CSS development are often repeated across multiple projects. From browser reset styles to creating horizontal menus and standard grid layouts, it seems absurd that we generate these from scratch each time. Jeff proposes that instead we create a series of CSS files that we can be reuse again.

Its a great idea and one definitely worth exploring if you work on lots of similar projects or are part of a large team where you are looking for consistency.

Agony uncle: The importance of undo

A couple of weeks back I received this email from Tom in Texas:

I am a designer currently working on developing a web 2.0 app. The developer is doing some really cool AJAX stuff but unfortunately most of it breaks the back button in the browser. He is arguing that it doesn’t really matter as there are lots of other ways of going back. What is your opinion on the subject?

Once I had recovered from the naivety of the developers comment and finished counting slowly to 10, I started to think through the role of undo. In the end this very simple question from Tom evolved into a blog post on the importance of undo. It is this subject I am looking at in todays show.

Client corner: Stakeholder interviews

Got this question from Dusted.

I’m about to begin a project to help an organization evaluate its current web site and web site management. I’m also going to perform some research and planning to help them start developing a new web site.

The organization is quite complex with a lot of different departments – marketing/events, sales, information/press, youth and more. Each person responsible for each department will be interviewed and I need some advice about what questions to ask them.

Starting off with a few…

  • Describe your department’s needs of the web site.
  • What can be done in a better way?

The results of the interviews will be used when I present my evaluation (and research/planning) to the board.

Any advice, links to articles, books… help of any kind would be deeply appreciated.

We have done quite a lot of stakeholder interviews over the years so this question seemed like one I could help with.

Stakeholder interviews can often be confused with user interviews, as they can often happen during the same process. I tend to differentiate the 2 by calling them internal and external stakeholders. These groups will always require a very different set of questions.

This piece refers to internal stakeholders only; those people that:

  • Will be paying for the project!
  • Are content owners
    • Some won’t know or want to be content owners – “that’s X’s job”
    • Some will consider their content considerably more important than everyone elses – “there should be a tab called ‘Corporate Accountancy’ and a big ad on the homepage”!
  • Will be users e.g. sales

There are a number of good reasons for talking to stakeholders, as follows:

Politics

Most organisations involve some sort of tension between departments/stakeholders/teams/whatever. Giving representatives from each of these groups (make sure you don’t leave anyone out!) provides everyone with a voice. It ensures that everyone has said their piece and it’s down in writing. Ultimately, it gets buy in on the project from all parties thereby creating a better end product.

Education

This applies from both sides. The interviewer is looking to be educated regarding the various points and specialisms that the interviewee has (that’s the point of the interview!). However, the interviewer also has an opportunity to educate a whole raft of internal staff about the web. A good example would be why it’s not a good idea to name site sections after departmental structure. In fact, teaching users to think of their end users early in the interview will probably affect what they have to say.

Verification

Talking to internal stakeholders can often highlight the need to develop certain functionality/facilities/micro-sites/etc that web managers only thought might be useful. Interviews can also be used as a test bed for ideas as well as feedback.

Semi-structured

Following on form the last point, make a point of telling interviewees that they can go off track. The questions are useful as guides but don’t stop writing down what someone is saying if it doesn’t fit with the script.

So, finally on to some good questions to ask&#…;

Questions will, of course, vary depending on the organisation, end user requirements etc, but looking back through a number of scripts, these seem to crop up regularly:

  • What does your department do?
  • What are your ‘processes’?
  • Who is your client and what do they want?
  • How do you think the web can help you deliver?
  • What is your role?
  • What is the biggest pain about your job? What takes the most time?
  • Describe your Internet understanding/usage?
  • Describe your software understanding/usage?
  • Name applications that you are a confident user of.
  • Do you store any information in databases? What?
  • The current website – what’s good and bad about it, what’s bad about it?
  • Are you tasked with providing content for part of the website? If not, do you want to be?

Ask the expert: Struan Robertson on Legal Issues

Today’s guest expert on Boagworld is Struan Robertson a corporate lawyer who specializes in IT law. I first met him on the .net podcast and thought it would be great to get him on the show to give us a small taster of the kinds of legal issues encountered by web professionals. In the show he answers three questions on particular scenarios to give you a taster of the kind of issues that can arise. These include:

  • What are the dangers of working on websites for illegal companies
  • Some of the issues surrounding using images when you aren’t sure about the licensing
  • Storing private data

Although the particular scenarios are quite specific hopefully they communicate some underlying messages and encourage you to take your legal obligations seriously. If you are interested in learning more about the legal issues surrounding web design and IT in general then check out Outlaw.com where Struan provides a lot more advice. Also Struan writes a column in the .net magazine where he covers different legal issues each month.

Advice for CMS users

I have been putting together a document for work that provides some basic advice for people who work with content management systems. It covers things like accessibility and writing for the web.

Introduction

Although content management systems enable anybody to publish content to the web, they do not guarantee the quality of what is published. Many content managed websites are hard to use, inaccessible and poorly structured not because of any failure in the design or technology but simply because the quality of content is poor.

This document aims to introduce the reader to good practice for generating web content. In particular it focuses on advice about writing for the web and ensuring that what is produced is accessible to the widest audience possible.

Writing for the web

Writing great web content is a particular skill. Although it shares some characteristics with writing for other medium, there are many unique elements too.

Two traits make writing for the web, particularly challenging. Firstly is the perception that most people have that computers are being cold and impersonal. Many see technology as the enemy and so a good copywriter has to work hard to ensure their copy has a friendly and approachable tone.

Second is the fact that users rarely read pages in their entirety, but rather scan read. The emphasis is on looking for the next link that will take them one step closer to their goal.

Below we investigate these two challenges in more depth and suggest some possible solutions.

Writing style

Well-written copy should be both engaging and accessible. In other words it should overcome people’s inherent suspicion of technology and ensure that, as wide an audience as possible understand what is written.

Engaging with the user

Computers are immensely unfriendly. This is mainly due to their total inability to interpret or communicate the more subtle forms of human communication such as body language and tone of voice.

The result is that most people find interacting with a computer a cold and frustrating experience. However, there are techniques you can use to avoid the problem. These include:

Using a personal tone

By ensuring that your copy is friendly, informal and approachable, you help to counteract the inherent lack of personality associated with computers and the web. Even on a relatively formal site add more informality than you normally would in order to offset the users default perception.

Writing how you speak

If you are experienced in writing more formal offline documentation, writing in a more informal manner can be difficult. Although there is no one catchall solution to this, writing as you speak will certainly aid comprehension and generate a more informal feel.

Avoid being patronizing

The danger of writing in a more informal tone is that you overcompensate and your writing style becomes ‘chummy’ and patronizing. The writing as you speak rule comes in useful here. Picture your audience and ask yourself whether you would speak to them like that in a face-to-face meeting.

Making your copy clear

The W3C accessibility guidelines clearly state:

Use the clearest and simplest language appropriate for a site’s content.

In other words ensure that your reader can understand what you have written.

Many people make huge assumptions about what their audience understands and careful consideration needs to be put into this subject. Particular assumptions are made in regards to:

Jargon

A common pitfall is the use of abbreviations and acronyms within web copy. The assumption is that your target audience will already be aware of the jargon used. However, this is an entirely false assumption.

You cannot always assume that your audience will be aware of every acronym around. For example there are so many acronyms within web design that it would be impossible for one individual to know them all.

Secondly, the reader maybe relative new to your target audience and so still learning much of the ‘lingo’.

When writing copy ensure that whenever possible jargon is avoided and where that is not possible that it is accompanied by an explanation. We discuss acronyms and abbreviations further in the accessibility section.

Reading level

There are reasons why tabloid newspapers like the Sun sell so well. One of those reasons is because they require such a low reading level. As many as 40% of the population have a low literacy level and yet little consideration is given to their accessibility needs.

Even when writing for a well-educated audience you cannot make assumptions about their reading level. Many people suffer from attention deficit disorder, dyslexia or other conditions that could affect their ability to process what you have written.

Below is some advice on how you might go about improving comprehension of your copy:

  • Simplify punctuation – People suffering from a low literacy levels struggle with long sentences that include a lot of complex punctuation. Keep your sentences short and your punctuation simple.
  • Be consistent – There is often a desire when writing copy to vary your language to prevent a document appearing repetitive. Although this has its place it does make copy harder to comprehend. Where possible, use terms in a consistent manner across the whole site.
  • Use numbers not words – By simply referring to 1223 instead of ‘one thousand two hundred and twenty three’ you increase comprehension dramatically as well as shorten sentences and aid scanability.
  • Specify clear actions – If you wish a user to complete an action (for example to click on a button) clearly specify this. Do not assume the user will instinctively understand what is required of them.
  • Use imagery – The saying ‘an image speaks a thousand words’ is very true for low literacy users. If an image will help to convey the meaning of a page be sure to use it to support existing copy.

Although the techniques above are of particular benefit to low literacy users, they do actually offer benefits to all users. Ease to comprehend copy aids the speed at which information can be digested and helps users scan copy as we are going to look at next.

Making web pages easy to scan

It can be a depressing realization that users will probably not read your carefully crafted text. However, the sooner you accept this reality the sooner you can start to adapt copy to aid users in their hunt for information.

There are a number of techniques that can be used to help a user quickly scan through a page and identify the information they require:

Front loading

Front loading applies in two different contexts. Firstly, front-load the page by including a summary of the entire page right at the beginning of the document. This helps the user ascertain quickly whether the page is relevant to them or not. Secondly, front-load each individual paragraph so that the main point is first. Ideally a paragraph should only make a single point (see 2.2.2) but if it is longer then the user can get the gist by reading the first sentence.

Keep it short

Usability expert, Steve Krug recommends in his book “Don’t Make Me Think!: A Common Sense Approach to Web Usability” that a copywriter should take his copy, edit it down to half its original length and then half it again. This sounds like an impossible task but it is often easier than it appears. By removing repetition, marketing speak, and ‘happy talk’ (content with no real substance like ‘welcome to this site’) you will quickly find your content substantially reduced.

Keep paragraphs short

As well as keeping the page as a whole sort, you should ensure individual paragraphs are short too. Each paragraph should make a single point as this aids both user scanning and comprehension.

 

Keep sentences short

 

At a micro level you should also endeavor to keep each individual sentence as short as possible. Again this aids scanability and comprehension but also helps to remove any unnecessary ‘waffle’.

Break your copy up

As well as breaking up copy into short sentences and paragraphs you can also aid scanability by using other techniques as well. Look at each paragraph and ask yourself the following:

  • Can I associate a heading or sub heading with this block of text?
  • Could this paragraph be reduced to an easy to scan bullet point list?
  • Is there a key message in this paragraph that users need to instantly see?

If the answer to the last question is yes, then you might wish to use a breakout box (also known as a pull out). This is a technique originally introduced in magazines to ‘hook the user’. They would take a key line from an article and highlight it in someway (usually in a separate box) to draw the reader into reading the rest of the article. The same technique can be used on a web page to draw a users attention to a key point that they maybe searching for.

Many good content management systems (including Headscape’s own CMS) provide this functionality.

Accessibility

We have already touched on the importance of accessibility when talking about writing clear copy, however accessibility extends beyond simply the copy you write.

As a content management system user, you are required to go beyond just writing the copy. You are also required to enter the copy into the system so that it can be displayed on the site. This requires you to ‘markup’ your copy correctly.

The importance of markup

So what exactly is markup? Markup is the method by which you tell the browser what the content you are entering is, so that the browser knows how to display it to the user. This markup is usually written as HTML.

So, if for example you want to tell the browser that something is a heading you would mark it up like this:

<h1>This is a heading</h1>

or a paragraph would be marked up like this:

<p>This is a paragraph of text</p>

Of course, one of the main attractions of most content management systems is that you don’t have to know how to write HTML. Instead the content management system will add the code for you.

Historically content management systems didn’t even try to understand what any individual piece of content was. Instead they let you as the content management user, style the content to look however you wanted. So instead of telling the system that this is a heading you simply made it look big and bold so users of the site would know.

Although this sounds like a good approach in principle, it actually opens up a whole load of problems that are too extensive to cover here.

More modern content management systems, such as the ones deployed by Headscape, ask the user to explain what each piece of content is so that the system can add the proper HTML code.

The way the content management user does this is normally through a drop down menu of styles much like you find in Microsoft word. You simply select a block of text and choose the style which best describes that text.

Marking up content in this way brings a whole host of advantages including (but not limited to):

  • The ability to redesign how an individual style looks universally across the entire site without editing each page.
  • The ability to change the appearance of styles based on what device is accessing the content (for example a mobile device style).
  • The ability for screen readers and other assistive technologies to understand the site.

In short, a well marked up piece of content will be available to a much larger audience and is easier to change and adapt.

Text alternatives

Well marked up content is not the only way to improve the accessibility of your site. Another is to provide text alternatives for elements that some users will not be able to access.

The most common example of this is with the inclusion of images into your pages.

There are a number of reasons why a user may not be able to see the images on a page. These could range from viewing the page via a mobile device to the user suffering from some form of visual impairment. However, whatever the reason the solution is the same; add alternative text that describes the image.

Alternative text is only visible to users who cannot see the image and so does not impact the design in anyway. The method of adding alternative text will vary between content management systems but in most cases (including on the Headscape system) you will be asked to add some text when you try and insert an image. A good system will go as far as requiring alternative text before approving an image for insertion.

A common mistake that is made with alternative text is to use it as a caption for the image rather than a description of the image. The difference is subtle but important. An image of Marcus Lillington our sales director might read ‘Marcus Lillington is more than happy to speak to you about your requirements’. This would be a caption rather than alternative text. Alternative text should describe the image and nothing more. So in the case of our example it should read simply; ‘Photograph of Marcus Lillington – sales director’.

Finally it is worth saying that the principle of alternative text does not apply just to images. It should apply to any screen element that can only be understood visually. That includes Flash, video, audio or other plugin.

Meaningful links

Another common accessibility mistake is with link text. When a content management user creates a link between pages it is not uncommon to see links with phrases like ‘click here’ or ‘read more’. This presents a problem for two reasons:

Firstly, users who access the web using screen readers often have all links on a page read back as a list in order to save listening to every piece of text when all they want to do is find the next link. A link like ‘click here’ means nothing when read out of context.

Secondly, many users will scan a page looking specifically at the links. They don’t read the text before or after the link so again they see it out of context. The result is that, like screen reader users, terms like ‘read more’ mean nothing.

This problem is easily avoided by ensuring that all links make sense out of context. So instead of linking the words ‘click here’ in the sentence ‘click here for more news’ you simply link to the phase ‘more news’ or ‘news archive’.

Acronyms and abbreviations

Earlier we talked about how where possible jargon, acronyms and abbreviations should be avoided. However there are occasions where that is not possible.

In such situations your choices are very much dictated by the functionality provided by the CMS you are using. Unfortunately, many content management systems are not particularly helpful in this regard and you maybe limited to typing out a description in brackets each time.

However, more modern content management systems such as that provided by Headscape, allow you to select an abbreviation style. You can then enter the full description and this becomes available to the user without destroying the flow of your text.

This is achieved in a variety of ways but the most common is using a dotted underline. If a piece of text has been marked up as an acronym or abbreviation it will appear to the end user as text with a dotted underline. When the user moves her cursor over the text the cursor changes to a help symbol and displays the full description as a tooltip.

This provides a full description to users encountering a piece of jargon for the first time, without getting in the way of those who already know what it means.

Using tables correctly

Web design has changed a lot over the last few years and so have content management systems. One of the most significant changes has been a move away from table-based layout.

Table-based layout is a technique that uses tables to position content on a page. However this is an abuse of the table feature in HTML and can cause significant accessibility problems especially for users running on older PCs or using mobile devices.

We therefore strongly recommend that using tables for layout is avoided at all costs. Instead clearly markup the content using the descriptive styles provided. The system will do the formatting and positioning.

That said there is still a place for tables. Tables were originally intended for tabular data (data made up of columns and rows, like that found in a spreadsheet). If you have information like this you wish to include on a page, then this is when you should use a table.

Working with imagery

Although we have already spoken about imagery in the context of alternative text it is worth noting that there are other accessibility issues relating to imagery you should be aware of:

Animation

Animation can be a problem area if not handled correctly, so generally speaking it is better to avoid the use of animated imagery unless it helps explain the content in someway.

The main reason that animation can be problematic is because certain forms of cognitive disability can be made worse by flashing animation. It can prove distracting and make it harder to process the content being read.

If animation is to be used we recommend:

  • That the user is given the ability to disable the animation
  • That the animation is not too rapid so that it proves less distracting
Colour

Finally, it is worth noting that a considerable proportion of your users will suffer from some form of colour blindness. For example almost 1 in 10 men are colour blind. In addition it is possible that other users will be accessing your site through black and white monitors on mobile devices. It is therefore important to ensure that any imagery you use is not reliant on colour to communicate information and that there is sufficient contrast between foreground and background colours.

These two issues are addressed in the W3C guidelines on accessibility:

2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup.

2.2 Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen.

Further information

Hopefully this document has been useful in outlining some of the basics of writing content for a website. However, we have obviously only been able to scratch the surface.

If you would like further information, please do not hesitate to contact Paul Boag (the author of this document) using [email protected].

Show 77: A dream?

On this week’s show: Paul talks about how a client’s work is never done, Marcus looks at dealing with scope creep and we review Dreamweaver CS3 (is it really worth upgrading?).

Play

Download this show.

Launch our podcast player

News and events

The web design survey

A List Apart are trying to build up a picture of the web design community by launching their web design survey. In my opinion this is an incredibly valuable project because there is so little statistical data on our profession. We have next to no information on salary levels, job titles, location, type of work done or even educational background. Its a strange situation for what is now a mature industry. Perhaps, as Jeffrey Zeldman suggests, it is largely due to the fact that we work in a hidden profession where the practitioners have meaningless job titles that bear little resemblance to the work we do.

Coding for content

If you listened to the SXSW special we did a while back you may remember me interviewing Garrett Dimon about the recent redesign of his blog. In that interview he talked a lot about his desire to focus on content and that the design should exist only to support that. The results of this effort are truly phenomenal and he has produced one of the most refreshing sites I have seen in ages. It is clean, easy to use and really succeeds in bringing the content to the fore. Well, this week he wrote an article that follows up on previous comments he made about his design approach by talking about how he coded the site. Its a great article and really shows off the fact that an attention to detail and methodical thought process can really generate some amazing results.

Don’t be a hero: Giving up is good

How often have you heard me drone on about return on investment? Well, now you can hear the guys at 37 Signals talk about the same thing but from a slightly different angle. In their post “Don’t be a hero: Giving up is good” they talk about the fact that developers don’t like to be beaten and will continue grappling with a problem long after it ceased to be profitable. The article argues that it is important to know when you cut your loses and drop functionality if it is simply taking too long to implement.

Working with tables and CSS

It’s amazing how many problems you have with tables even after you have moved across to CSS based design. One common problem I see a lot is the data in tables pushing out the tables width which in turn often breaks the design (see an example). Fortunately this week I found a post that seemed to solve the problem. It uses the table-layout property in CSS along with overflow:hidden. Its a useful little technique that is definitely work checking out.

Client corner: A client’s work is never done

In last week’s client corner section I talked about the role of the client and how in many cases it is very poorly defined. This started me thinking in more depth about how clients perceive web projects and how they often fail to grasp the enormity of the undertaking. In this weeks show I explore the ongoing commitment that clients have to make to their websites and look at what exactly they will find themselves doing on a day-to-day basis. As with last week’s client corner, this is a subject I have recently blogged about and so if you want to refresh your memory on what I said in the show check out my blog post on the subject.

Agony uncle: Dealing with scope creep

This week we will be reviewing a question from Bob in Iceland – “How should I deal with clients that keep changing the spec throughout a project?”

I guess the first thing to say is that the spec will change, they always do. Often it is perfectly understandable because people see a new design or piece of functionality and think ‘hey, we could do X or Y as well’.

But… and I have been as guilty of this as anyone… often the scope will creep as the client learns about the web development process as the project goes along. This is avoidable. It can often be seen as pedantic, or possibly even negative, to spell out exactly what a client is getting. For example, design iterations or template styles. Ask yourself when writing the spec – would a layman understand this? If not, then add notes to explain.

So, what to do when the first request outside scope comes in? As with most things, use your brain regarding how to respond!

If it is a 5 minute job then just do it, but make sure that client is aware that it is outside scope so a) you can earn some points with them and b) let them know that you are keeping a tight eye on the scope of the project.

Anything over that, you need to respond in writing (email is fine) stating that the work is outside scope and you estimate it will take X hours to complete… please confirm that you wish us to go ahead with the work. This puts the onus back on the client and makes them think about whether they really do want the work done.

It is good practice to have a change control procedure written into any statement of work. These can sometimes be over the top, demanding contract extensions in writing and the like (which probably is appropriate for a large new piece of work) but usually something like –

As and when issues arise, it is the project manager’s responsibility to raise these with the client and agree any actions to be taken.

If any rescheduling is required, the project manager will be responsible for ensuring that acceptable changes to the schedule are agreed with the client and documented.
The project manager will maintain an issue log and ensure that issues are either closed following discussion with the client or result in an agreed change to the project plan, with associated change documentation including price change where required.

Basically, this is saying ‘use your head’ and make sure you write down whatever is agreed.

Sometimes, however, it is wise to carry out additional work as a gesture of good will. This is usually appropriate if you ‘owe’ the client a ‘favour’ of some sort, for example if you had charged 5 days to produce a design and it took 1 because they signed it off immediately. You don’t necessarily actually owe them anything (assuming a fixed price contract) but they will be aware that you didn’t put in as much effort and probably won’t take a kind view to your charging them for an extra half an hour’s work at the end of the project.

Review: Dreamweaver CS3

I finally got my hands on a copy of Dreamweaver CS3 this week and although I am still taking it all in I thought I would share some of initial thoughts.

I guess the question you want answer is whether it is worth upgrading or not. As normal the answer isn’t black and white. If you are a a strong standards based designer who has worked with things like DOM Scripting or AJAX then this upgrade probably isn’t for you. However if you are still finding your feet with CSS and don’t want to learn Javascript then this upgrade is definitely worth considering.

Obviously Adobe is trying to pursued us that Dreamweaver offers a huge range of reasons to upgrades such as better Photoshop integration and improved browser testing. However, when it comes down to it, I believe it only offers two killer features.

CSS Layout made easy

If you are new to CSS this feature might be useful. It basically allows you to select from a series of CSS layout templates to get you started. Now, this never replaces hand coding it from scratch, however if you are anything like me you find it easier to learn from example and this certainly helps with that.

Spry framework

If you have tried and failed to get your head around DOM Scripting and AJAX then I would suggest you start off by buying “DOM Scripting: Web Design with JavaScript and the Document Object Model” (J. Keith) or “Bulletproof Ajax (Voices That Matter)” (Jeremy Keith). However, if even that fails then you might want to take a look at the Javascript framework now built into Dreamweaver CS3. As with CSS layout I should stress this isn’t as good as hand coding because:

  • you are stuffed if you want to add or amend functionality not offered from within the framework.
  • the code is bloated in places meaning it will make the page take longer to download.

However, that said, the functionality offered in Dreamweaver is very impressive. You can achieve all of the following without touching a line of code:

  • Work with XML datasets (like RSS feeds)
  • Expand and collapse content areas
  • Make accordion menus
  • Validate forms

The code isn’t great but at least from what I have seen it degrades reasonably and isn’t too intrusive.

If you are a confident CSS and DOM Scripting coder then the upgrade offers considerably less. Personally the best thing I saw was the ability to sort my CSS files in a drag and drop approach. Beyond that and copy and paste straight from Photoshop, there really isn’t much to get excited about.

The question is; has Adobe done enough with Dreamweaver CS3 to keep themselves ahead of Microsoft’s Expression Web which reports say is very impressive. Personally the lack of mac support in Expression Web could well be the deciding factor in what otherwise are very equally matched products.

“Adobe Dreamweaver CS3 (PC)” on Amazon

“Microsoft Expression Web (PC)” on Amazon

Show 64: Hosting

This week on Boagworld we explain all you need to know about hosting , look at how to interpret other people’s CSS and review an excellent HTML email testing tool. Oh yes… and Marcus drones on about client stuff.

Play

Download this show.

To subscribe directly within itunes click here

News and events

Heuristic Testing

This week seems to be the week of Heuristic usability testing. Andy Budd kicked us off with a post on how Jakob Nielsen’s classic article on heuristic testing needs updating to take into account the new generation of web applications. Lisa Herrod then followed up with an excellent article on the sitepoint website looking at how heuristic testing can be used by web development teams.

The Future of Web Design

I know that a lot of people cannot afford the time or money to go to web conferences but I thought the Future of Web Design one day conference was worth a mention as it is only £59. It has a great line up of speakers including people from 37Signals, Flickr and Adaptive Path.

Tips for better design review process

You maybe the best designer in the world but if you cannot “sell” your designs to the client then more often than not they will be rejected. Many designers hate the design sign off process and are often frustrated with the final result. Keith Robinson has written a superb article that will help you better manage the successful sign off of your designs.

Seven Accessibility Mistakes

A while back Chris Heilmann wrote two articles on typical accessibility mistakes that people should avoid at all costs. I am sure that they were great articles but I never got around to reading them. Fortunately Roger Johansson has taken the time to summarise them in a nice easy to digest format.

Client corner: Questions for designers

How do you know which is the right web design agency to go with? Proposals are important but what questions do you ask at the presentation? This week Marcus gives website owners the inside track on what to ask prospective web design agencies. Here are some of the main points he covered:

  • Get a detailed breakdown of rates and pricing.
  • Understand what happens if things go wrong.
  • Ask about the contractual arrangements.
  • Request financial information on the company.
  • Get detailed information on the work they have done.
  • Know the team who will be working on your project.
  • Always ask to speak to existing clients.

Agony Uncle: Understanding other people’s CSS

There is nothing worse than working on a site built by somebody else. This especially true when it comes to the CSS. What styles affect which elements? How do the styles cascade down? What is going to be effected if I make a change to a style? This week in the agony uncle corner we look at some of the tools which can help solve these issues. In particular we take a look at the Firebug Firefox extension and the CSS panel in Dreamweaver.

Ask an expert: Mark Crawley on hosting

One of the things that has been requested for the “ask an expert” section is that we try and get on some new names rather than the normal “web celebs”. With that in mind this week’s guy is an old work colleague of mine; Mark Crawley. He talks about an area we should have covered a long time ago… hosting.

Review: Testing HTML Email

Although many condemn HTML emails as truly evil, the reality is that many of us are occasionally forced by clients into producing them. Setting aside the appalling support for standards, the next biggest headache with working on HTML emails is testing. Fortunately Site Vista, a UK based company has solved the problem by producing a testing suite very similar to Browser cam but for email.

Podcast 42: Choosing the right design

It’s not unusual to be in a position where you have to choose between more than one design for a site. This podcast may help with the question “which design do I pick?”.

Play

In this week’s podcast Paul and Marcus discuss the decision making process involved in settling on a design for your site. Whether you are a designer or web site owner this podcast provides some interesting techniques for choosing the right design.

Download this show.

To subscribe directly within itunes click here

Help us out. Complete our podcast survey

How to approach choosing a design

Your approach to assessing a design is as important as the quality of design itself. Approaching your assessment in the wrong way can quickly lead to the wrong conclusions. Below are a few quick tips on assessing a design:

Avoid personal opinions

Design is very subjective. We all know what we like and yet we very rarely agree on what that is. It is easy to simply assess a design based on your personal preference. However, the chances are you will not be the end user of your site and so the design should cater for a wider audience than just you.

Be careful who you show

Although you don’t want your decision to be based on your personal preference you still need to think twice before you start showing it around. The temptation is to show it to work colleagues to get their feedback however they aren’t your target audience either (unless you are building an intranet). Try and avoid design by committee, have one decision maker that collates feedback from end users rather than co-workers.

View the design in context

It’s important that you assess a design within its context. Never print a design out to make your decision. Access each design on screen and within a web browser. After all, that is how other people will view it.

Check on multiple monitors

A design can look radically different on various monitors due to colour balance and gamma settings. Make sure you look at the designs on as many different screens as possible. A good design needs to be flexible enough to accommodate the different screens your site visitors will be using.

View at different resolutions

A design not only needs to work on different monitors but also at different resolutions. The resolution your PC is running at affects what can be seen on a design before you need to scroll. It is therefore vitally important to ensure key content doesn’t slip below the fold.

Accessing the design

Once you have worked out how you are going to go about assessing the design the next step is to establish the criteria by which you are going to make that assessment. Below are some initial ideas you might wish to use. Each of these areas could go into a lot more depth but I have tried to keep to the main points within each area.

Colour

Colour is a very subjective area, so rather than asking people what they think of a colour, ask them what words they associate with a colour palette. That way if they say a colour conjures up images of "progressiveness" you can compare this with the messages you want the site to convey.

Layout

There are two things to look out for when assessing the layout. Does the design have enough white space and does it have an underlying grid structure. White space allows a design to breath, making content more readable. A grid structure provides some organisation to the design and its absence can leave a design feeling chaotic.

Weighting and flow

Does the design draw the eye to key content and show the user what to look at next? Ensure that the design you choose puts the emphasis on the right elements in the same way a newspaper always makes it clear what the lead story is.

Typography

As with layout there are two key things to look out for when it comes to the text on your site. Firstly, make sure that the text has a decent space between lines. Tightly packed text can be really hard to read and will dramatically reduce dwell time. Secondly make sure that the designer has broken up larger blocks of text with headings, sub headings, bullets etc, as this dramatically improves scanability.

Accessibility

Obviously accessibility is a huge area but within the context of choosing a design there is only one main thing you need to know: Can you read the copy? Is there sufficient contrast between foreground text and the background? Avoid designs that you have to strain to read because ultimately they will drive users away.

Usability

Is it obvious what the user should do next? Do links look like links? Is the main navigation clearly positioned and labelled? Is the user overwhelmed with too many options? In many ways usability is the key criteria I use for judging design. Ultimately users just want to get at information as quickly and easily as possible and the design should not get in the way of that objective.

Branding

To a website owner this is probably the most obvious of the assessment criteria. How well does the design conform to your style guide and tie in with existing print material. A continuity across marketing collateral is vital for establishing a strong brand identity and the web is very much a part of that.

Imagery

The final area of assessment is the choice of imagery. Imagery can make or break a website. Some warning signs to look out for include:

  • Small busy images that are hard to see
  • A lack of consistency across the site with different styles of imagery, all mixed up together
  • Images that grab your attention away from content rather than directing you to it.

The golden rule

If there is a golden rule to choosing the right design it would be communication between client and designer. A client should listen carefully to what a design has to say about their design approach and the designer should be able to clearly communicate their ideas and why they have made the decision to produce a certain design. Too many designers fail to justify their approach and too my clients make up their minds about a design without listening to the logic behind it.

Also in this show

In this week’s show we take a look at a number of web conferences including the @media podcast feed, Refresh Orlando (which Paul will be speaking at) and d.contruct. We also discuss the ethical issues surrounding being "inspired" by another website, as well as a review of the Wiltshire Farm Foods website.

@media is almost upon us

Well I have just received my email from Vivabit giving me all the details about next week’s @media conference and it has finally made me look through the list of sessions. I have to say I feel like a kid in a candy store.

I have been intending to write a post on my hopes and expectations for this years @media conference for the last few weeks. However, it wasn’t until today that I have had a chance to look through the list of speakers and the subjects they will be tackling. And what a list it is!

Last year’s conference was a real turning point for me. I had become weary of web design and lacked inspiration and motivation. Listening to others enthuse really set me on fire again and led to this blog and subsequent podcast. So as you can imagine my expectations for this years conference are unrealistically high. However, the list of sessions did nothing to tame my out of control enthusiasm. It is as if somebody has asked me to list all of the areas I am passionate or concerned about and then made it into a 2 day conference.

Here is the list of sessions that have fuelled the fire of expectation:

Bulletproof Web Design

As somebody that has only recently embraced fluid design (as you can tell from this legacy site) I can’t wait to hear what Dan Cederholm is going to say to help people &#”;let go of pixel precision&#”;. My hope is that Dan can help me deal with some of the frustrating issues that arise from designing with ems and percentages.

The fine art of web design

I have been going through a bit of a stale patch with design for a while now. I feel like I am always having to fight clients to get anything other than the most mundane designs past them. Sometimes it is easier just to churn out the same old mediocre crap when you are faced with a difficult client. However, I am hoping that this session will put some fire back in my belly and make me fight my corner a bit more.

Fine Typography On the Web

Dave Shea’s presentation on typography looks intriguing if nothing else and I cannot wait to hear what he has to say about the state of online typography. Can we really be moving away from Verdana and Arial? Is there really a magic solution I am unaware of?

Mobile Web Design

I am interested to hear what Cameron Moll has to say on the subject of designing for mobile devices, as I have heard so many conflicting messages from &#”;just remove the stylesheet&#”; to &#”;mobile design is to web design what web design is to print&#”;.  It’s an area that I keep meaning to investigate in more depth because I believe clients will soon by requesting this from us as a matter of course.

The New Accessibility Guidelines: WCAG 2.0

Now this is a panel with a lot of potential!  Following Joe Clarks article on the subject I am hoping for a hugely constructive debate… that or a good old moan. I am open to either!

Don’t forget to say hello

To be honest I could have listed pretty much every sessions . How all of this is going to be crammed into two days is beyond me.

Anyway if you are going make sure you come up and introduce yourself. I will also be at the pre-event bash on Wednesday night so it would be great to see you.

Accessibility and the new headscape site

As you have probably gathered by now I am in the process of redesigning the new Headscape website. As part of it a lot of thought has been given to our approach to accessibility. This is what we have come up with.

We really wanted to demonstrate through our web presence that a site could be both visually appealing and accessible.

We wanted to show that flash could be used on a site without making it inaccessible. We wanted to show that a content management system could ensure a site remains accessible even when used by people with no coding knowledge. Finally, we wanted to make the world a happier, more loving place!

Did we achieve all of this, probably not!

The trouble is that most web designers agree web accessibility is important but few can agree on the best way of making a site accessible. That is mainly because it is still an evolving area and new ways to improve accessibility are being found all the time. As of now, we believe that the techniques used on this site are some of the best but no doubt, this will be out of date in a matter of weeks!

So what is the approach we have adopted?

Flash

A quick word on flash before we move on to things that are more important. Some hard line accessibility zealots will no doubt disapprove of our use of flash on this site. However, we believe that if used correctly flash and accessibility can sit comfortably side by side. Whenever we have used flash we have ensure it is accompanied by a clearly marked description and alternative ways of accessing the same information it provides.

WAI guidelines

If you are bothering to read this page, you have probably already heard of the WAI guidelines which layout three levels of accessibility. This site has been designed to be level three compliant (the highest level), with one notable exception.

Checkpoint 3.4 states:

Use relative rather than absolute units in markup language attribute values and stylesheet property values.

In short, this means that everything should be scalable. That includes fonts and layout. Although in our default style, we have made the body text scalable, the rest of the interface is not. It was our feeling that, after experimenting with both scalable and elastic sites, complying with this checkpoint would undermine the design. This would jeopardise our first objective, which was to show sites could be both accessible AND visually appealing. Obviously, this decision is a subjective one, but it should not be interpreted as a lack of commitment to people with a visual impairment and who require the ability to resize text. We have just chosen to solve the problem in another way (see below).

Low vision version

Because we have largely conformed with the WAI guidelines and built the site using web standards we are hopefully that users of speech browsers will not encounter any serious problems. Of course, you can make no guarantees as speech browser have more options than you can shake a stick at, and it is possible one of these will screw up the site.

However, there is a much larger group of visually impaired people, which do not use speech browsers, but do require an enhanced interface. One option is to make all the fonts on your site resizable as explained above, but this fails to tackle some of the other issues faced by visually impaired users. We have therefore introduced a low vision style for the site that is designed specifically to meet these users’ needs without compromising the default user interface.

No doubt some of you reading this page are thinking; "but hang on, doesn’t this fly in the face of RNIB policy on web accessibility?" This refers to a statement on the RNIB site that says:

At RNIB, we recommend against providing a text only version as much as possible, simply because being treated differently can reinforce the feeling of marginalisation that someone with a disability experiences.

However, we are not talking about a separate text only version of the site that quickly becomes out of date because it is poorly maintained. What we have done is create a secondary interface to the same content designed specifically for a visually impaired audience. They are accessing exactly the same content, simply displayed in a way that suits them.

New National Trust site about to go live

Back in 2000, I had the privilege of being the lead developer on the 2nd generation of the National Trust web site. With the third generation of the site about to launch, I am excited to see them move on.

Working on the National Trust web site was one of the most enjoyable sites I have ever done. When the Trust came to us they had little more than a "home made" site put together by some enthusiastic amateurs and a few technical staff at the Trust. We had the privilege of redesigning it from the ground up; information architecture, design, content, the lot.

Our approach

What was particularly enjoyable was there huge archive of photography. They had over 100,000 photos of some of the more amazing architecture and countryside in England and Wales. It did not take us long to realise that these images should rule the design and so everything else was built around that.

Project challenges

Accessibility

Of course, the project was not without its challenges. Firstly, the Trust wanted to ensure the site was accessible by their more elderly members who in many cases had failing vision. At the time, there was still much confusion about accessibility and how to ensure your site was accessible. Very different messages were coming from organisations such as the W3C, the RNIB and the British government. In the end we decided to adopt a similar approach to the "zoom the web" approach which seems to be the way things are moving at the moment. We simply switched to a different stylesheet to increase contrast and font size. Although the site was not WAI compliant, it did demonstrate some initial thinking in the area.

Navigation

The second problem area was navigation and in this, the constraints were much more frustrating. I will not bore you with the details but it is worth explaining that because of internal politics at the time we were only able to add a very basic header to the site that provided primary site navigation by a dropdown! In hindsight, this was my primary failing on the site. I feel I should have really fought for a more user-friendly form of navigation as dropdowns prove especially difficult to older users. However, I was not as knowledgeable as perhaps I am now and the whole industry has become older and wiser.

No content management system

The final problem with the site was totally out of my control. This was that the Trust wanted the entire site built as flat HTML. This was driven by technical constraints at their end and both the Trust and I were very aware of the maintenance problems going forward.

National Trust moves on

About 18 months ago, they finally decided to face the situation and move the entire site across to a content management system. As part of this rebuild, they also wanted to address some of the design issues and so a new look and feel was produced. Unfortunately, due to an internal reorganisation within the Trust and our lack of experience in the particular content management system they had selected, they chose not to employ Headscape to do the new look and feel. I have to say in many ways I feel this was the right decision. The Trust was a very different organisation to the one we first got involved in and I understood their desire to introduce new blood. In many ways, I felt I had done my part moving the organisations website to the centre of their marketing strategy rather than an added extra that received little funding and no serious consideration.

Waiting with baited breath

I have been waiting with baited breath to see the new National Trust site. For some reason they seem to have faced delay after delay in its launch. I do not know the details for this slippage but I would like to think they come from a desire to get the new site perfect before going live.

My hopes for the new National Trust site

So, what are my hopes for the site. Well, firstly I hope they fix the navigational problems the site suffers from. Secondly, I imagine the new site will dramatically improve from an accessibility perspective using the latest techniques and conforming to W3C standards. Thirdly, I hope they will move across to a web standards based build and all the associated benefits that has. Finally, my desire is to see a user interface that really shows off the beauty of the properties they own. The National Trust own some of the most amazing places in the world and I pray that their site captures that awesome architecture and wonderful countryside.

Accessibility for low vision users

Using web standards, many web designers have become a lot better at ensuring their sites are readable by speech browsers but what about the much larger audience that have some limited vision.

Feeling smug about accessibility

As I continue to work on the redesign of the Headscape website, it would be easy for me to become rather complacent about accessibility. After all, I have separated content from design ensuring the site degrades nicely on older browsers and works well for most speech browsers. I have even ensured all my XHTML is valid and the code passes a bobby check. What more could be asked of me?

The trouble with accessibility

The trouble is accessibility is about more than fulfilling a series of checkpoints or building to a certain set of standards. Sometimes things are more complex than that and sometimes there are no clear answers at all.

Low vision users

Take for example low vision users. Unlike speech browser users it is not enough to create clean code which their browsers can easily read (although even that has a whole bunch of issues I will not bore you with here). Low vision users have a number of requirements that need to be specifically catered for. For example:

  • They require a simplified interface free of anything but the most essential navigational elements.
  • They need a single column layout as content can be pushed off screen at large font size.
  • It is imperative the user can scale the font to any size without the design breaking.

So what are the options?

Remove the site sheet

The quickest and easiest option would be to allow the user to strip out all the styling of the site and see the raw content. It would not look very pretty but at least they would be able to scales it or even change the colours using their browser settings.

The downside of this approach is that this goes no way to meeting the first of our three criteria listed above because it just shows everything to the user.

Make the site scalable

Another option is to make the site scalable. This means that the interface adapts to compensate for increases in font size. However even the best scalable site is going to be hard pushed to accommodate some of the font sizes visually impaired users require. One option is to make the site elastic which means the whole interface magnifies with the text. The downside of this approach is that it can push elements off screen and as a result low vision users often fail to see them.

Of course using a single design approach to fit all also has an impact on the visual styling of the site as well as the usability. For example, a user who does not have a visual impairment is going to find a single column design frustrating and unattractive. It smacks of designing for the lowest common denominator where nobody wins.

Alternative stylesheet

The third option and my current favourite, is to create an alternative stylesheet for visually impaired users. Because we have separated content from design, it is easy to create a new style that can accommodate all of a visually impaired users requirements without compromising the standard design.

In some ways this feels like going full circle back to the days were we used an alternative accessible version. This approach was generally frowned upon especially by organisations such as the RNIB because these accessible sites often had less content and were poorly maintained. There was a feeling that disabled users were being treated as second class citizens.

The zoom layout is not like a ghettoized text-only page. It remains as fresh and updated as the regular page because the content is the same. All that has changed is the style sheet.

I tried to speak to the RNIB about this issue, but unfortunately despite assurances they would respond, have heard nothing. However, I then discussed it with Robin Christopherson at AbilityNet who specialise in assistive technology and he agreed that alternative stylesheets was the best option currently available:

If done properly they can radically alter the experience for different groups. This is quite different from ‘ghetoising’ groups by offering them an alternative site with, in most cases, less content or functionality (your ‘Text only’ link). It’s this that we and the RNIB object to.

The problems

Unfortunately, at the moment even this approach is not without its problem. The biggest and most obvious of which is the fact that when a user arrives at your site they have to first find the accessible version. This can be incredibly challenging and there is no simple solution. Obviously, a prominent link will help but at the sizes some visually impaired users would require this will totally dominate the design.

I am currently working on a JavaScript approach that would detect the font sizes specified in the users browser and change style if they are not the default setting. Of course not every person who happens not to be using the default settings are visually impaired and anyway there are significant browser compatibility issues to overcome.

The ideal world

In an ideal world there would be a way of telling the browser that a zoomed version is available. The user could then configure the browser to use this alternative version if it is found. Although there is some talk about making this happen it is still a long way from being a reality. In the meantime we might have to accept there is no ideal solution and endeavour to find a happy medium that provides the best possible to all users.

So what’s your approach?

So how does your site cater for low vision users? Do you do anything at all? I would love to hear how other people tackle the issue.

Further reading

If you want to know more about creating alternative low vision versions of your site I would highly recommend these two pages:

Zoom the web – presentation from the @media 2005 conference

Big, Stark & Chunky

 

Get yourself a great WYSIWYG

While in the process of rebuilding the Headscape website, I have come across the ultimate in WYSIWYG editors for your content management system.

If you are a regular reader of this blog, you will know that I have been trying to rebuild the Headscape website for a very long time. One of the main reasons for a rebuild is that our current site does not demonstrate the web standards and accessibility experience that has become core to our company’s approach.

The problem with Content management systems

Of course, it is relatively easy to build a web standards site and ensure it conforms to the basics of accessibility but it is much harder to keep it that way. In my experience, it is the WYSIWYG editor that often lets you down. The whole point of having a content management system is to enable even those with no programming knowledge to make changes to their site. Unfortunately, the majority of content management systems rely on editors that provide the user with little or no help ensuring that the underlying code is clean and accessible. The result is that within days of launching a site becomes non-compliant and potentially no longer accessible.

An outstanding solution

Enter XStandard.

Unlike many WYSIWYG editor that rely on native Internet Explorer Active X components, XStandard has been built from the ground up to provide standards based code and highly accessible content. Not only that it has been beautifully designed to be easy to use and novice friendly.

Superb features

Just some of my favourite features include:

  • The user selects from a list of clearly named tags that define what content is NOT what it should look like. The designer’s style sheet then automatically controls the appearance of these tags.
  • Encouraging the user to conform to accessibility guidelines. Wherever possible it automates this process and if it cannot it prompts the user.
  • Enables drag and drop of both images and files directly from your desktop
  • Microsoft word documents can be copied directly into the editor and it cleans the code and marks it up appropriately.
  • It has a multi-lingual spell checker built-in.

The list above refers to the best features from the users’ point of view. There are also numerous benefits from the programmers’ viewpoint as well.

Responsive customer support

The other thing that particularly impressed me is their customer support. We have received fast responses to our email enquiries and they have done everything possible to deal with all of our queries.

Problems with pricing

I have only one criticism of the product and that is its pricing policy. The price is calculated on both user licenses and site licenses which gets very complicated especially when integrated to a cms that can generate unlimited numbers of users.

Highly recommended

However other than pricing I can thoroughly recommend this product. Not only will we be adopting this editor for our own site we will also be integrating it into all of our content managed sites moving forward. In fact I would go as far as saying that if you already have a content management system that uses another editor that you should seriously look at the possibility of retro fitting this editor into your site.

Speeding up the web development process

I am currently working with our lead developer at Headscape to streamline the process of building and deploying content managed web sites. Part of this process revolves around seperating out the different aspects of a sites development to make it easier for multiple people to work on the site at the same time and to standardise some elements which had previously been bespoke to individual projects.

Current working process

Normally a web project runs something like this:

  • Establish initial design concepts
  • Work on the Information architecture
  • Create the site templates (XHTML) and style (CSS) for the site based on the designs and information architecture
  • Populate the site with content
  • Make the site live

Obviously this is hugely over simplified but you get the idea. However the problem with this approach is two fold:

  • It is a fairly linear process which involves each phase being dependant on the previous steps being completed
  • The site templates (XHTML) and style (CSS) have to be made bespoke each time to fit the project

A new working process

The process we are moving to helps to solve both of these problem areas. By seperating not only the presentation from the content but also the content from the structure you can start to standardise even more of the process. Let me explain:

Standardising the structure

As all the content is held in the content management system there is no need for the site templates (XHTML) to be bespoke for every project. These site templates no longer contain content but rather only define the structure of the site. After all the majority of sites contain the same basic structural content such as navigation bars, content areas and the like. By consistantly naming these areas you can then just use style sheets to change the way this structure is presented.

This approach means that instead of having to build the site templates and styles from scratch each time, you can have a basic predefined template which are then tweak accordingly. Obviously some changes will need to be made. The style in particular would have to be altered quite considerably for each project, nevertheless basic features such as column layouts could be predefined. The site templates would require only minor tweaking on a per project basis to take into account issues such as some clients wanting their news templates categorised by subject while others would want it organised by date.

Working independantly

This approach would also allow a lot more stages of the project to happen independantly. For example the person populating the content can do so even before the design is finalised because they can still navigate the unstyled site and see the content they have entered. The added bonus of this is that the designer can play around with different designs directly on the final structure and content. This means he can see exactly how his designs will work with real content instead of endless blocks of dummy text.

The result

The result of all of this is that an average content managed web site could be produced considerably faster and using less internal resources to do it.

Further reading

If you are interested in knowing more about seperating out the different layers of web design I highly recommend this article on the subject.

Design 101: Branding

There are lots of articles on usability, accessibility, technical development and sales techniques for your web site but precious little on how to make your site aesthetically pleasing. I therefore want to post a series of articles on the basics of good graphical design. Today we will start with branding.

If you are responsible for your organisation’s web site the issue of branding is certain to have come up. How do you ensure that your web site reflects your offline brand identity? Well here are a few things to take into consideration:

The web is not the same as print

A degree of flexibility is required when portraying brand identity online. It is not always possible to accurately reflect branding in the same way online as in print material. The following issues can often cause a problem:

Fonts

Organisations often have corporate fonts which they expect to see reflected online. However not all fonts work well on screen. Serif fonts can be much harder to read online than in print and so should normally be avoided unless they are being used at a larger size for headings. Also it is important to remember that the majority of text will be dynamic and not graphical. This means that every PC which views that web page will have to have that font installed on their machine in order to be able to view it. To ensure that a user has the particular typeface the web designer will be forced to work with a very limited number of fonts. If your corporate typeface doesn’t fall into this set of universal fonts then it is best to avoid using it for anything other than graphical headings.

Colour

It is also important to note that a colour which works well in print won’t necessarily work well on the web. Colour in print is shown using ink on paper while colour on the web is displayed as projected light on a screen. Just this simple difference can dramatically alter the way the same colour appears. Combine with this the fact that printed colours are made up of CMYK while a monitor uses RGB to show your chosen colour. Finally it is important to remember that every monitor and PC graphic card will display your site with different brightness, contrast and saturation. This means your corporate colour might look fine on your monitor but appears almost black on another. It is important to take all of these factors into account when choosing how closely you stick to your corporate colour palette online.

Lost detail

Another difference between the web and print is the loss of fine detail online. I have already spoken about the problems with some fonts but it can also be a problem with logos too. The reason for this is to do with the number of dots per inch a monitor can show. When you look at a printed brochure your logo is made up of hundreds of tiny dots packed together. In fact the dots are so tiny and so close together that you cant see them. On average a piece of print work is made up of about 300 dots per inch. Now a computer monitor works on a similar principle however it can only show 72 dpi. This means that a lot of the finer detail is lost.

This can prove a real problem with complex logos that are being shown at a small size on screen. You might wish to look at ways of simplifying your logo in order to make it more web friendly.

Positioning

There is a general principle which you should be aware of when looking at how to apply your corporate branding to your web site. Users have come to expect to find the logo in the top left of the web site. This is a good idea not only because of users expectations but also because this is the first part of the screen the user will look at. Users will scan a web site from the top left to the bottom right (the same way we read a book – left to right, top to bottom).

The importance of tag lines

Your corporate branding online should also be accompanied by a tag line that clearly explains what you offer. Unlike when people read a brochure, users of your web site are much less likely to know anything about your organisation. In many cases they will have found you via a search engine and might not clearly understand what you offer. A tag line closely associated with your logo will make this immediately clear.

Find a web design company that can produce a range of styles

Finally make sure you find a web design company that can produce a site that reflects your corporate style. It is surprising how many web design companies have a very strong "house style" and find it hard to tailor their graphical style to match yours. Make sure your web designer has a broad portfolio of different styles or that their "house style" is inline with what you need.

Next time we will look at colour palette and how to go about choosing the right colour palette for your web site.

Managing site content

The majority of our clients now run content management systems on their sites but is a CMS really the answer to all our site management woes?

What makes content management systems attractive

It is easy to see why organisations find content management system attractive. So many web sites are full of out of date content, as well as being difficult to edit. A content management system appears to be the ideal solution because it allows anybody within the organisation to update web pages without the need for technical skills. Marketing departments can control the message being projected through their site while overworked IT departments don’t have to deal with a constant stream of changes. In larger organisations it is even possible to decentralise the running of the web site so that responsibility for sections within the site are deligated to individual departments.

The reality

Why is it then that only 27% of organisations using content management systems are not intending to make changes to the way it is used. Using a content management system to run your web site is good in theory but in reality it is not always that straightforward.

Content management is about more than technology

The problem lies in the fact that organisations perceive the implementation of a content management system as an answer in its own right. However a CMS is simply a tool that still requires people to use it correctly in order to maximise its potential. It is how a CMS is used within an organisation that determines it success, not the technology itself. There are three classic mistakes made when it comes to the use of content management systems:

Responsibilities

One of the most common problems is that responsibility for the web site is not clearly defined. It is rarely made clear to those expected to update the web site that this is a key part of their job. It is considered an additional chore that gets pushed to the bottom of the priority list. In many cases the web site is updated no more frequently than before a CMS was implemented simply because people dont have the time and motivation to do it. In my experience the time when CMS works best is when the individuals responsible for the web site have their role as web editor clearly defined in their job decsription and time is cleared in their schedules to allow them to undertake this role.

A single focus

Another common mistake is the lack of any single evangelist. There needs to be a single web master that not only ensures that other individuals contribute to the site when they are meant to, but also ensures that the contributions are consistant in language, style and message. Without this person there is no sense of "whole" in the message being communicated through the site. It will contain different writing styles and in some cases even contridictory content. You need one person that can set a style for the site as well as establish a vision for its future direction and development.

Training

Obviously there is a need to ensure that people know how to use the content management system, but that cannot be the end of the story. Its important to remember that many of those editing the web site might not be doing so on a regular basis. It is therefore important that they receive refresher training periodically to make sure they feel confident using the system. If they lack confidence they will avoid using it and once again content will become out of date.

Also training on the use of the content management system is only the tip of the iceberg. Web site editors need to have an understanding of how to write effective copy for the web. They need to know the basics of good layout and design as well as an understanding of how to structure the web site to ensure it is easy to find information.

Conclusions

So what is the lesson here? I guess it would be to invest as much time and money into the people who will run your web site as into the technology that will drive it. Make sure that there is somebody within your organisation who is a real evanglist for your web site. Somebody with a clear vision of where your site is going and the resources to make it happen.