5 options when website budgets get slashed

Your site is in desperate need of a redesign, content is out of date and the technology is archaic. Unfortunately times are tight and your budget has been cut. What do you do?

The economic downturn is affecting everybody and even at Headscape we have noticed the budgets of clients shrinking. With less money to spend how can you maximise the return on your investment?

To be honest I think it is a good thing that people have less to spend on their websites. We have had too many clients approach us asking for complete overhauls of their sites when that is not what is really required. Often more subtle changes can have a greater impact over the longer term. They certainly generate a better return on investment.

We have been working closely with our clients to suggest ways they can improve their sites without breaking the bank. Here are just 5 of our suggestions.

1. Realign rather than redesign

Why do you need a redesign anyway? Redesigning your entire website is time consuming and costly. However, more importantly it is often unnecessary. I seem to be quoting Cameron Moll’s excellent article “Good Designers Redesign, Great Designers Realign” a lot recently, but that is because he talks a lot of sense. He writes:

Like a kid in a candy store, we creatives redesign like it’s the new black. Why do we possess such an insatiable desire to refresh and remake? Why do we thrive on renewal? What tempts us to be seduced by the sway of renaissance?

I believe it is because we see a redesign as the solution to a failing, tired site. However that is rarely the case as Cameron goes on to explain:

Too often, look and feel, color scheme, layout, and identity are presented as solutions to problems… long before regard is given to other less-aesthetic issues that may very well be the root of the problem. The old warning against treating symptom rather than cause comes to mind.

What is more redesigns can often cause more harm than good by confusing the loyal users who are familiar with your old site.

When budgets are tight let go of the notion you need to do a complete redesign. You can improve your site many times over with the smallest change. Just take the case of the $300 million button I mentioned in show 150 of my podcast.

My facebook profile

2. Simplify

As website owners we are always looking to expand our websites by adding more features and content. However, that costs money we may not have.

Here is a radical alternative – Instead of adding more to your site, why not take things away.

Typically websites are stuffed with content and features that users simply do not use. A quick look at your analytics package will demonstrate the problem. The vast majority of traffic is to a handful of pages.

The problem is we tend to leave content in because ‘somebody might find it useful’. Although this maybe true, it does not necessarily mean keeping content is a good idea.

The more content and features we make available the harder it is for users to find what they need. It is the proverbial ‘needle in a haystack’.

Fortunately, simplifying your website does not have to be entirely about removing content. According to John Maeda’s book ‘The Laws of Simplicity‘ we can also streamline our sites by shrinking and hiding content too. Consider ways to reduce the prominence of less important content, to place a greater emphasis on what matters.

When budgets are tight take a long hard look at your site and ask whether more can be achieved by simplifying what you have rather than adding complexity.

Apple Homepage

3. Prioritise and phase development

Another technique which can be used when budgets are tight is to phase development. There seems to be a tendency among website owners to store up changes and roll them out in a single large deployment. Unfortunately this means a large single expenditure too and that can be problematic from a cash flow perspective.

A better approach is to roll out incremental changes on an ongoing basis. Not only is this better from a financial perspective, it brings other benefits as I explain in the Website Owners Manual. Phase development also provides:

  • Faster delivery because new features are launched independently. Some features can be launched while others are in development. This prevents a single feature stalling the entire rollout.
  • More accurate estimates. Bigger project are harder to estimate. Breaking them down makes it easier for suppliers to quote accurately.
  • Better PR opportunities. Whenever a new feature is launched there is an opportunity to publicize the site. New features can motivate users into taking another look. A single large project only provides a single opportunity to grab peoples attention.
  • Limited risk of working with a new supplier. Choosing an agency is always a risk. Until you work with somebody, it is hard to gauge how good they are. Reduce this risk by limiting the size of project they are commissioned to build. If the agency fails to perform, you can look elsewhere when commissioning subsequent work.

This is an approach commonly adopted by larger websites with their own in-house teams but much rarer among smaller sites who use external agencies. Nevertheless, it is an approach which works well in tough times.

Digg Technology Homepage

4. Reuse and recycle

Too often we reinvent the wheel. When budgets are plentiful this can make sense. Although there is similar functionality out there, we might choose to develop it ourselves so we have more control or can customise it to our exact requirements. However as budgets begin to get squeezed these are luxuries we cannot afford.

In a world of widgets, APIs and open source it is becoming increasingly hard to argue the case for custom builds. Why build your own mapping application when there is Google Maps? Why build a forum when you could use an open source alternative like Vanilla?

My only word of warning is in regards to integration. It can be hard to get these ‘prebuilt’ tools to work together. Be careful that the savings made are not lost to integration problems. Where possible use tools like WordPress that provides an architecture with a wide range of plugins for quick integration.

opensourceCMS screenshot

5. Move beyond the website

Finally, I think it is important to remember that your web strategy is not all about your website. We spend the majority of our ever decreasing budgets on adding bells and whistles to existing websites when there are large number of potential customers who never reach our sites.

Instead of sinking your budget and efforts solely into your website consider looking further afield. Could your web strategy be better served by putting resources into a Facebook group or a twitter account for example? Would your target audience listen to a podcast? Do they read RSS? What about a mailing list? The possibilities are endless.

Ask yourself where your target audience congregates. Instead of constantly trying to draw users to your site begin to spend time where they already meet. What social sites do they use? What editorial sites do they read? Contribute to these communities and offer to write for the editorial sites they read.

Many of these things can be done at almost no cost and with little technical knowledge. All it takes is some time and enthusiasm.

Conclusions

Whether a site is successful is not dictated by its budget. However many larger organisations have relied on money as a method of driving their web strategy forward. As these budgets are slashed there is an opportunity to gain a competitive advantage by being smarter.

Hopefully this post has demonstrated a few of the possible avenues available and inspired you to discover some more of your own. However if you would like some more personal advice specific to your own website then feel free to drop me an email.

145. Baby Jack

On this week’s show Paul looks at how to communicate better with your users. Marcus examines ways to improve your contracts and Ryan has a baby (not actually on the show).

Download this show.

Launch our podcast player

Watch the behind the scenes video

Housekeeping

Two pieces of housekeeping before we begin:

  • First, congratulations to Ryan Taylor our producer and Michelle on the birth of their first child. We want to send our love to them all and welcome Jack Taylor to the world!
  • Second, just a quick note to say we will be holding our live Christmas special on the 8th December at 2.30PM UK time. The show will be an open question and answer time so either send in your questions in advance or come along and join us in the chatroom. We will also be doing a feature on this years top Christmas gifts for geeks. You can vote for your suggestions over at UserVoice.

News and events

Google goes social

The biggest and most controversial story of the week is the addition of SearchWiki to Google search results.

SearchWiki is a way for you to customize search by re-ranking, deleting, adding, and commenting on search results. You can move the results you like to the top or add a new site. You can also write notes attached to a particular site and remove results that you don’t feel belong. These modifications will be shown to you every time you do the same search in the future.

However, most controversially you can also share some of these changes with other users. This has led to fears of spamming and negative commenting as users attempt to manipulate the results.

Personally, this feels like a storm in a tea cup. It is an interesting new feature but I really do not see it catching on in any significant way. Only the most extreme power users will bother using these features and the majority will never see the change.

For example, even if website owners do attempt to manipulate users by spamming notes or adding negative comments about competitors, the vast majority will never see these notes. Users have to actively choose to view other users notes from a tiny link in the footer.

I say let stupid website owners spam these comments. It will keep them busy doing something which ultimately will make no difference to the popularity of their site.

Where this could be useful is when I can identify friends who I trust. Being able to see their notes or reordering of results would be of interest to me. Until then, this is non-starter.

In browser web development tools

In last week’s show we listed your top web development applications. Interestingly several of those applications were browser addons such as the web developer toolbar and Firebug.

This week Smashing Magazine has reviewed 15 in-browser web development tools that offer a variety of debugging and coding features.

The list ranges from the web known like FireBug to the more obscure like Fangs (for showing how a screen reader might read a page) and ColorZilla (for quickly listing all the colors on a particular web page).

Other tools featured include:

  • YSlow – a Firefox extension that analyzes a Web page for front-end performance.
  • Fiddler – an Internet Explorer extension that analyzes and profiles a Web page’s HTTP traffic.
  • DebugBar – a debugging extension for the Internet Explorer.
  • Web Accessibility Toolbar – an extension for Internet Explorer and Opera that quickly evaluating and analyzing your Web content’s accessibility.

If you are regularly coding this list is a must read.

From tables to CSS and back again

Kevin Yank, the co-author of Everything You Know About CSS is Wrong has written an excellent article on Think Vitamin telling us it is time to build websites using tables.

Before you all start sending Kevin hate email I should point out he is referring to CSS tables.

Let’s face it, the worst thing about CSS is its support for column based layout. Sure, it does a great job at absolute position but floats just make no sense! As Kevin writes…

You couldn’t come up with a more convoluted way of expressing page layout if you tried!

Fortunately with the imminent arrival of IE8 all major browsers will soon support CSS tables. This means any group of elements can be made to display like rows and columns within a table. Suddenly designing layout in CSS is as easy as using HTML tables.

I know what you are thinking… ‘what about IE6 and 7?’ Kevin addresses this in his article. He suggests that because it is so easy to layout using CSS tables we will have the time to design in CSS tables for modern browsers and the fall back on floats for IE6 and 7. He goes on to suggest that perhaps it is worth simplifying your design slightly for these older browsers to further speed up the process. He believes (and I agree) that clients would agree to this if they understood the cost savings.

Overall, I think this is a very exciting transition and one that will help bring across those hold out ‘table based designers’.

Advice for long term success

Our final news story today is some advice from the founder of Amazon. Jeff Bezos has done an interview with the ‘US News and World Report’ on how to run a successful business. The advice he shares is something that applies to all of us whether we are running a website or building a freelance career.

From reading the article I took away three lessons…

  • Have a long term strategy – Whether in business or running a website, you need to look ahead. Too many of us are thinking about the short term. What feature should we implement next? Where is the next salary is going to come from? Jeff encourages us to look further and work towards long term and visionary objectives.
  • Do not be distracted – Jeff also encourages us not to be put off by others who do not ‘get’ your long term vision. Stick to your guns and keep going. It is easy to have your confidence knocked by the criticisms of others or problems you encounter along the way.
  • Take risks – I am a great believer in taking risks from time to time. A part of this is excepting failure. If you want to double the amount you succeed you must also double the number of times you fail. As Churchill once said Success is the ability to go from one failure to another with no loss of enthusiasm.

Sure, the interview is not about web design and is written by a guy who can afford to think long term, ignore others and take risks. However, it is still good advice and something we need to take on board both as web designers and website owners.

Back to top

Feature: Successful communication

We put a lot of time and attention into the content on our sites, but what about our other communications? We send out newsletters, post blogs, participate in forums. All of these reflect on our brand and the way we are perceived.

In this week’s feature Paul examines how to improve our communications with users.

Back to top

Listeners feedback:

Sign-off and payment

We have this question from an anonymous listener:

I have a designer’s contract in front of me and I am getting a ‘feeling’. The contract doesn’t discuss much in terms of scope; just really limits risk for the designer. Though I can understand the need, I raise an eyebrow to focusing more on ‘not getting burned’ than ‘providing a good design’ … so here is the big question. The designer wants 50% upfront and 50% on an arbitrary completion date or “prior to file relinquishment, or upload and/or assembly of website on clients web server.” My thought is I am not paying $X for a pdf mock-up … I am paying for a site redesign and would like to see it work live prior to getting signoff. (or payment) Inevitably, there is a trust issue; I believe we have both been burned in past client/ designer relationships and are treating each other cautiously. Is there an industry norm which could help the situation? My perspective is how it will look live, especially considering different browsers, am I off base as a client to see the design work live prior to payment?

Ok, so picking this apart from the top:

Firstly, having a contract is a good thing. Full stop. But, you don’t have to blindly agree to whatever is put in front of you. If you don’t like what you’re reading then amend and send it back. This may also mean that you want to get legal advice – I guess that depends on your confidence dealing with the legalese involved in most contract documentation.

Contracts should be made up of two parts:

  1. the terms and conditions (the legal stuff) that should cover obligations, deliverables, rights, liability etc.
  2. the Schedule that should be a detailed description of the project – tasks, timescales, price, payment terms etc. It should also include detail on what the testing process is, what browsers/operating systems etc.

Ideally risk should be limited for both parties. A good contract makes expectations clear for both sides and lays out what should happen if something goes wrong.

Regarding payment terms, it is perfectly normal for a contractor to ask for a percentage of the total cost up front. But, it doesn’t necessarily have to be half up front, half on completion. We often spread invoicing over 4 or 5 different points over a project. This is good for our clients as it is an incentive for us to reach certain milestones along the way. One question I have here is – does this particular designer want payment literally on commencement? We provide 30 days for our clients to pay bills, so even though we may invoice on commencement, we will be a month into the project before we receive payment.

Ok, more detail… the contractor wants final payment:

  • On an arbitrary completion date – you should not agree to this. Payment by a particular date is not acceptable as the work may not be completed and the delay may not be down to you.
  • Or “prior to file relinquishment” – this is not unheard of. Basically, they are saying ‘you pay us and you’ll get your stuff’. Which is fair enough as long as you (quite rightly point out) have witnessed the site operating correctly in a ‘live’ environment. I’ll come onto this shortly.
  • Or upload and/or assembly of website on clients web server – this is what you want I believe.

A ‘live’ environment doesn’t necessarily have to mean your web server. We test all our web development work on our own development server prior to making it live and we ask our clients to sign-off on this environment prior to pushing live. We do, however, rarely invoice until the site is live because there are possible issues with the live environment that we may not have envisaged. Particularly, hosting platforms often need to be able to support certain technologies – if they don’t, you have a problem. If the designer is providing the hosting then that is unlikely to be an issue. It also gives them an option of taking your site down if you don’t pay. That way, they can happily make the site live prior to sending you the final invoice. Do they offer hosting?

So, in conclusion, I would push for the final invoice to be on live and tested release of the website. I would also propose that payment is split into 3 points – on commencement, on design look and feel sign-off and finally, on live and tested release.

Back to top

 

Successful communication

We put a lot of time and attention into the content on our sites, but what about our other communications?

We send out newsletters, post blogs, participate in forums. All of these reflect on our brand and the way we are perceived. How can we improve the way we communicate?

Good communication is dependent on two factors:

  • When you communicate
  • How you communicate

Get this wrong and you risk seriously damaging the relationship with your users.

When to communicate

The schedule of your communications are always important, whether posting to a blog or sending out a newsletter. Send too many communications and it becomes irritating, too few and they forget about you.

There is no frequency that is always right. To a large extent it depends on the nature of your site. If your site sends out stock market tips then users may expect updates every few minutes. However, if you sell a service that is purchased once every couple of years then sending out communications every few weeks will be enough to keep you in their minds.

The key is not so much frequency as regularity. Users should come to expect your communications. Communicating on an ad-hoc basis becomes frustrating, especially with blog posts, newsletters or podcasts.

However, communication does not have to be completely dictated by a schedule. You can also have trigger based communications. These are normally emails sent to a specific individual rather than the whole community. They are sent in response to a specific event rather than a schedule.

A common trigger based communication is an email sent to somebody who has just purchased from an ecommerce site. These typically include an email confirming the transaction but also one when the goods are dispatched. These emails are extremely important and yet are often overlooked in the development process.

Trigger based communication are also useful in encouraging repeat traffic. Most website communities have a large number of ‘sleepers’. These are individuals who have signed up for your site but have stopped using it. It is possible to monitor user activity and if they stop using the service an email can be automatically sent tempting them back with incentives or new content.

However, never forget the golden rule of user communication; do not contact users without their permission. Nothing will damage your sites reputation faster and destroy your community than spam.

Take a few moments to consider your communication strategy. When might it be appropriate to send out trigger emails? Are you collecting user’s contact details and is it legitimate to contact them? What methods you are going to use to communicate and on what schedule?

Your communications with users needs the same attention you gave your sites copy. This includes not only when to communicate, but how.

How to communicate

There are lots of communication tools out there including blogs, podcasts, email and RSS. However, these are just technologies and don’t get to the heart of how to communicate. Communication is about what you say and how you say it.

Always remember when communicating with users to make it personal. Whether it is in a forum or posting to your blog, people like to talk to people not faceless corporations. Whenever possible write as ‘Jim from Marketing’ rather than as ‘Acme inc.’ People are less critical and more receptive when dealing with a individual rather than an organisation.

Although your aim is to demonstrate that your organisation is made up of ‘real people’, that does not mean you do not need no unifying voice.

Know your voice

The danger individual employees engaging with your users is that your organisation sends out mixed messages about its identity. All copy should have a consistent tone, from the content on your website to the emails you send existing customers.

At first reading this may seem contradictory. On one hand I demand a consistent identity and on the other I want users to see the people behind your organisation. However, this is actually an approach newspapers have been employing for years.

Most newspapers have regular columnists who readers come to recognise. However, each newspaper has an overall identity. For example in the U.K. tabloid newspaper "the Sun" has a very different persona to that of "the Times".

Deciding on your persona will underpin all communications with users. Ask the question – if your site was a person, what type of person would it be? Would it be a young hip teenager or a boring middle aged business man? These characteristics help define how you communicate and the tone you set for your site.

However, whatever persona you create it should always be as open and transparent.

Be open and honest

Many organisations feel they need to maintain a flawless facade with users. This serves to create a barrier, reinforcing the feeling that the user is dealing with a faceless corporation.

A better approach is to be honest and fallible. Nothing is more effective in getting users trust than admitting when you get it wrong. Take for example photo sharing site Flickr.com. Their site suffered a series of outages in which users were unable to access their photos. Unsurprisingly the mood in the flickr community was pretty negative. However, flickr was able to turn that negativity around with a simple blog post entitled "Sometimes we suck". They acknowledged the problem, apologised and promised to do better. They did exactly that and before long flickr was seen as a shinning example of how an organisation should run a community.

In fact it is possible to turn a critical user into an evangelist for your site simply by responding in a timely and open manner. In a world where users can instantly broadcast their frustrations via blogs, social networks and other methods of online communication you cannot afford to ignore them. However, if you respond in a positive and open fashion those same users will be broadcasting their pleasure at your response.

This post is an edited extract from Paul’s book – The Website Owners Manual.

144. Scale

On this week’s show Paul talks to Joe Stump from Digg about scalable websites, we review the best apps for web designers and investigate services for sending bulk emails.

Play

Download this show.

Launch our podcast player

News and events

How much should you charge?

If you are starting your freelance career the number one question you will have is ‘how much should I charge?’ It is important and yet strangely it is not something you are taught at college. Perhaps they don’t teach it because it is a damn hard question to answer. It is certainly something we have avoided talking about on this show.

Fortunately an article entitled ‘Six things to consider when setting your freelance rate‘ has been released this week. Although the article does not give a magic number, it does provide 6 valuable insights that will inform your final decision. These include…

  • Young freelancers and recent grads almost always ask for too little.
  • You can do things your clients can’t.
  • Your rate influences your perceived value.
  • You don’t get to keep it all.
  • An hour worked is not an hour billed.
  • The higher you start, the less you’ll need to increase.

I couldn’t agree more with everything said in this article. However, the one that really resonated with me was ‘You do not get to keep it all.’ Your rate has not only got to cover your billable hours but the cost of sales and marketing, as well as your various overhead. The article has a link to a superb rates calculator that helps you work out your chargeable rate based on these various costs. Definitely worth checking out.

A plethora of accessibility posts

With the implement arrival of WCAG 2.0. we are seeing a resurgence of interest in accessibility. This has led to a plethora of accessibility posts over the last few weeks. These include…

  • Writing good ALT text – This is a simple post about the use of the ALT attribute. It suggests two rules of thumb when it comes to writing ALT text. First, if you were to describe the document to someone over the phone, would you mention the image or its content? If you would, the image probably needs an alternative text. Second, does the alternative text of any images in the document make sense if you turn off the display of images in your web browser? Simple advice, but well worth remembering.
  • Designing for Dyslexia – This is a series of 3 in depth articles that look at the subject of Dyslexia. It asks what Dyslexia is and how we as web designers can improve our sites to accommodate the needs of Dyslexia users. Its interesting stuff. Part 1 defines what Dyslexia is. Part 2 looks at some of the conflicting requirements with users who have visual impairments. Part 3 suggests some specific things you can do to improve the legibility of your designs.
  • Accessible forms using WCAG 2.0. – This extensive post aims to provide web developers and others with practical advice about the preparation of accessible HTML forms. It compares the WCAG 1.0 accessibility requirements relating to forms with those contained in WCAG 2.0. Important stuff but not a 5 minute read!
  • Too much accessibility – The RNIB explains how the LEGEND tag can cause more harm than good if not concise and relevant. The reason? LEGEND text isn’t read at the start of the FIELDSET, it is read at the start of the label. It repeats at the beginning of every single text label in that FIELDSET.

A business case for deleting content

I find myself using the word ‘simplify’ a lot when I talk to clients these days. So many website owners are constantly wanting to add features or content to their site. However, in reality we should be removing not adding to our already bloated websites. This is particularly true for large institutional websites. However it does also apply to smaller sites.

Take for example the Headscape website. When we started the redesign process for our site, I sat down and really thought through what information prospective clients wanted. The answer was very little. In the end our large text heavy website was reduced to a single page. That is the power of simplicity.

Gerrry McGovern summed it up perfectly this week in his post entitled the ‘Business case for deleting content‘. He wrote:

The more you delete, the more you simplify. The more you simplify, the more you increase the chances of your customers succeeding on your website.

We may think that we cannot delete content because ‘somebody might want it’ or because we believe ‘it will help our search engine ranking’. However, bloated sites bring complexity and with complexity comes confusion. The more content on your site, the less chance a user will be able to find the content they need.

12 principles for keeping your code clean

We finish today with a great post for those who need help with their HTML code. Whether you are a student learning HTML or a designer who is more comfortable in Photoshop than Coda, this is a very useful article.

The post provides 12 excellent tips for keeping your code clean. These include…

  • Use a strict doctype
  • Set your character set and encode those characters
  • Indent your code
  • Keep your CSS and JavaScript external
  • Nest your tags properly
  • Eliminate unnecessary divs
  • Use better naming conventions
  • Leave typography to the CSS
  • Add a class/ID to your BODY tag
  • Validate
  • Order your code logically
  • Just do what you can!

The article explores each of these points in depth and communicates clearly current best practice in coding HTML. Well worth the read even if only as a reminder.

Back to top

Interview: Joe Stump on Building a Scalable Site

Paul: Ok, so joining me today is Joe Stump from Digg. Good to have you on the show Joe.

Joe: Oh, good to be here.

Paul: Have we had you on the show before?

Joe: Ah, not that I’m aware of.

Paul: Oh, wow, well we need to rectify that then. It’s good to have you on. Well, I have to say, this interview was arranged by Ryan, who is our producer. And he’s a developer, and I’m a designer. And he suggested we got you on the show, not that I wouldn’t like you on the show, obviously. That we got you on the show, obviously about scaling websites. Now, I’m going to be out of my depth very quickly here, so you’re going to have to be very gentle with me Joe.

Joe: Sure

Paul: So, in fact, it was so bad, that as I sat down to write questions I thought: "I don’t know what I’m doing here" , so I went and talked to some of the developers at headscape, and I asked some of the Boagworld listeners, and so we’ve got a little selection of questions for you, that, hopefully we can learn a little bit about how you go about doing things at Digg. Lets start off, what’s your job title, what is it that you do at Digg?

Joe: Ah, I have a really fancy job title that doesn’t mean a lot of anything, but ah, my official job title is "Lead Architect" and um, I think what best describes it, is that I manage the technical implementation on the code side.

Paul: OK

Joe: So, Digg’s broken up into a lot of different arenas on the tech side, we’ve got, R&D, which is headed up by Anton Cast, we’ve got operations, which is headed up by Scott Baker, and then under that are the people that I work with, ah, probably most closely in implementing solutions for Digg. Ron Gorodetzky is our lead systems engineer, Tim Ellis, also known as timeless, is our chief DB wonk, and then, Mike Newton is our lead network guy. So I think us four kind of steer the technical implementation along. The managers, ah, the manage, and handle the strategy and partners, and stuff like that.

Paul: You managed to say the word manager with real distain.

Joe: Oh, no actually, I have a great manager, John Quinn, he’s our VP of engineering, he’s by far the best direct manager I’ve probably ever worked with. Yeah, he’s really good.

Paul: OK, well lets go back in time a little bit. And start by, well, when was the point when you realized, that you were going to start having scaling issues with Digg? When did you start thinking about the whole subject of scaling?

Joe: Um, well Digg was pretty big when I came on board, so Digg was about 10 – 12 million uniques when I joined on.

Paul: Wow.

Joe: And I think we’d just cleared 35 million last month. So scaling was obviously an issue, but the big difference is that, I think sites generally go through a few different levels of scaling, where like the first one’s like, "I’m just going to throw it on a virtual server, or an Amazon server, you know, you’re basically just seeing if things are going to just "stick to the wall", and then they do. Ah, so the first thing you normally do is start breaking services off onto separate boxes. I want to put my DB on one box, my server on another box, and maybe memcached on each of them. And then you hit, read saturation on that one DB server, so then you go to the kinda next level of scaling. Which is where Digg was when I started, where you start dangling, a whole bunch of read slaves, off of your DB master, so, and for those who are not familiar with the master / slave terms, you send all your writes to one database server, and then that disseminates those writes to a whole bunch of slaves, and then you send all your read traffic to those slaves. So that’s where Digg was when I started. It’s write http traffic across a whole bunch of servers, its read traffic across a whole bunch of slaves, and then we have one master. And we’re now going through, what I think is the third phase, where you hit write saturation on your master, which is a bigger problem, because you then need to start sending some write traffic to some masters, and we’re actually going with a strategy that’s common with Facebook, and Flickr, and those kind of websites, where it’s called horizontal partitioning, where you put some of your records on one server, and the other records on another, so it’s like, you can say, for users, all users whose names start with A through J, would go on this database server, and K to Z live on this other database server. So we’re in the middle of implementing the first swipe at that. So we’ll be pretty aggressively into where everything will be federated and partitioned across a whole bunch of servers.

Paul: OK, one of the questions which kinda came up, which kinda relates to that, is, once you start spreading things across multiple servers, how do you handle things like user sessions, which have obviously got to be persistent.

Joe: Aha, so there are a couple of ways to handle that which, I’d say most people are handling it by.. There’s two ways, probably that you can do it easily. One of them, is if you have what they call "session affinity" on your load balancer, so the load balancer will say: "Oh, well this person, last time I had them here, they went to server A, so we’ll send it back to that server". So the session always lives on only one box. That’s one way to do it, we don’t do that here, we have a custom session handler in PHP which sorts the session in Memcache, and that allows you to.

Paul: Can you just clarify what memcache is, for idiots like me who don’t know.

Joe: Sure, memcache is a distributed caching system that’s actually, basically what it allows you to do, is expose a machines RAM over the network, and cache stuff into another machines RAM across the network.

Paul: Ah, OK

Joe: Yeah, it’s insanely fast, it was developed by Danga back in the day, and Brice Fitzpatrick, yeah so it’s heavily used by anyone whose scaling with LAMP, even a lot of people who aren’t. They all use memcached.

Paul: Wow

Joe: So, yeah, we store all of our session data in memcached, so PHP creates a unique session id, and we just stuff session data into that in memcached, and we can distribute that across, I don’t know, 50 or 60 memcached servers, and what not.

Paul: So how many servers do you guys have, it must be a staggering number by now.

Joe: Um, yeah, it’s kinda funny, every time I ask Ron that, he’s always like "Ah, I don’t know"

Paul: Laughs

Joe: Because we really can’t I mean, I couldn’t give you a specific number because on any given day, we’ll pull or push into production, a dozen servers, so, hundreds, there’s definitely hundreds in production. So.

Paul: I mean, with that many servers, so obviously you’re talking about taking servers on and offline, and all that kind of thing, I mean, making updates to the site, when Daniel comes up with some stupid idea, that you’ve got to apply to the site, of a new feature that he wants to apply on the site, and you’ve gone through the process of making it work. And you’ve then got to push it live.

Joe: Aha

Paul: How does that work? How do you go about pushing something like that live when there are so many servers involved.

Joe: So we have Ron Gorodetzky our lead systems engineer guy. So us developers have a bunch of M4 make files, that, when you check the code out, you run basically Make, Install, and it, for lack of a better word, it builds or compiles the website into a cohesive package, and then Ron pushes that to each server, I think he is still doing it by rsynch, but I know we are migrating over to Puppet, so it may happen via Puppet soon. The production side of things, is something that’s handled completely by operations, so I couldn’t tell you specifically how it happens, but generally, we make a tag of the website, and tell Ron, we need you to push "9.4.15" or something like that, and he does a checkout, builds it, and pushes it to all of the different servers.

Paul: So is that – do you actually have to take the site offline to do those updates? How do you minimize the downtime that’s involved with that.

Joe: Oh, well there’s a bunch of different ways. Um, we don’t bring the website down normally for pushes, it depends on the size and complexity of the push. But like, day to day pushes, we probably push I guess, a minimum of once a day, just little bug fixes and stuff like that. And those happen generally in the middle of the day, and nobody notices, it’s no big deal. Ah, the outages these days, are completely dependant on database activity, you know, like database fixes and stuff like that. And the ways that we’re getting around that these days, is using a different method of partitioning called vertical partitioning. Where, like for instance, like I think our comment Diggs table, of like, who’s dug a comment, up or down, that’s like 15 billion records in it.

Paul: Wow

Joe: that’s like, yeah, if you’re like to alter that table, you’d probably crash mysql, but if you were, it would probably take a week to alter it. So instead we probably create another table, where we have like comments, and then we have another one called comments_made_up, or something like comments_diggs, comments_diggs_beta, and that has a couple of extra fields in it. And so we’ll say, OK, we’re about to push the code, at the end. When we push the code, the first comment id that was added to the table was 15,000,000,001, so then you start at 15,000,000,000 and work my way back in the table. So we do some of that live as well. For the next push that we’re doing, we’re using a migration table, which will tell us how far along each record is, and which records we’ve actually migrated, and stuff like that. And then we’re going to use this package called "GearMan" which is a queuing system which we’ve had in production for a while. And we’re basically turning our servers into a giant BotNet, so we’ll back fill all those partitions quickly.

Paul: Wow, that kind of amount of data, it must create huge problems, even adding a new piece of functionality onto the site, to actually code it in a way that’s not going to have a momentous impact on the database. This must be something that’s always constantly on your mind I guess?

Joe: Yeah, I’ll tell you a really funny story that highlights that perfectly, we have these little green badges that are on the Digg button, and they indicate, that a friend of yours has dug that story. And when you hover it shows the last four friends to dig it or something. So that’s a pretty knurly query, against a very big table, and we’ve actually had to, what I would call "dial it down a bit", so that it only shows up on the stories that are 48 hours old, and it won’t show up if there are more than 500 diggs or something. So the features fairly usable, but it’s not like… Well before if someone went to the top of 365, it was basically crashing our servers. So we’ve been rewriting that, and we basically, the way that we’re rewriting it is: If you write something, we take that Digg and we drop it into each of your followers buckets. So we make a bucket for each story for each person. Any time one of their friends digs it, we drop that dig into their bucket, but the problem is, like Kevin Rose is followed by 40,000 people, so every time he digs something, I need to drop 40,000 things into 40,000 different buckets. And we did the math, and just to get that feature up and running in a vast sane manner, so that it will scale, so we can bring it back in full capacity so everyone can use it all the time. We need 1.25 GB of storage, and we need to be able to sustain 3000 writes per second in order to keep just that small feature online.

Paul: So that really kind of illustrates that a relatively small feature that someone comes up with, has massive ramifications from your point of view.

Joe: Yeah, this is something that has kind of been something that I always talk about. I mean even back when I was doing consulting, I’d kind of have clients come to me, and it would be: "Check out this awesome design", and I would be like "that designs awesome, but that little feature down there, that’s going to cost you know, $100,000 in servers, and 500 man hours. But it’s, like, well the designers think of sizes and shapes, and so Daniel always jokes around and says: "Well I can make it purple" if that will make it easier for you" you know, it’s like…

Paul: Laughs

Joe: Laughs – well that doesn’t make it easier!

Paul: Well, we’re going to get you and Daniel back on the show to talk about this whole design / developer relationships, so you can lace your side of it now, and get your side in first. Before he defends himself.

Joe: Sounds like a plan.

Paul: So are you at the point now where you’ve got an architecture that’s kind of infinitely scalable, or are you going to have to go back to the drawing board if Digg just goes even more, you know off the scale than it already is?

Joe: Yeah, well we’re actually at the drawing board right now.

Paul: Yeah?

Joe: Yeah, Ron, myself, and some of the other senior peeps, about 8 or 10 months ago, we started putting together… well we knew that we were going to start to have serious limitations, especially since we were going to be scaling internationally. You know there is a problem with latency. With you guys across the pond hitting the west coast and other things like that. So we want to be in multiple data centers. We want to be actively serving traffic from multiple data centers, so we’re are, well we need to horizontally partition, we need to make sure we can do that. And we need to live in two different data centers. We need to be able to survive one data center disappearing. So we spent basically a week in front of the white board, and we created this thing called IDDB, which is kind of an elastic storage engine, built on top of SQL, and memcachedb, that we’re going to be putting the first bits and pieces into production, probably over a month or so. And really, the whole partitioning thing isn’t the difficult thing to figure out. The difficult thing is basically spanning multiple data centers, and also we’ll have a couple hundred gigabytes of data, and I need to spray that across, you know, a couple dozen different servers, without bringing the site down. So we have a couple million – 3 or 4 million users, and I need to take all of their records, and all of their auxiliary records, here’s like your user record, and there’s also a bunch of cruft related to that. So I need to take all of that, and migrate it to different partitions. But I need to do that while the site’s still up and running, and I need to do that without breaking the site for you. So, that’s the more complex problem at this point.

Paul: I mean you talk about spreading across multiple data centers, and if one of those data centers goes down, the site does too, and whatever. How are you currently handling redundancy? How are you making sure the site stands up at the minute?

Joe: Right now, our only single point of failure at this point, is our actual data center, so if the data center falls off the planet, then we’ve got problems. But we’ve got a general architecture. We’ve got a couple of general balancers up front. And those two have, what we call a "heartbeat" between them, and if one of them falls off, the other instantly takes over traffic for it. And that balances traffic across, I couldn’t even tell you, dozens and dozens of web servers, and of course, the load balancer does help checks on those, so if any of those falls over, it will drop it out of the pool. Behind that, we have, I think, 4, I guess our masters are technically single points of failure, but we have multiple masters as well, and we have dozens of read slaves hanging off of them. I think right now it takes about 10 minutes to bring a new master into production if one fails. So, and then we have, to store our files, we have a thing called MogileFS, which is a distributed web dav storage engine of sorts, and we can loose multiple nodes on that, and not have any problem with that as well.

Paul: Yeah, so at the moment it’s a physical problem that you have, that if your data center gets hit by an earthquake or whatever, then you have problems. Please tell me it’s not in San Francisco?

Joe: It’s not in San Francisco.

Paul: Ha ha, yeah, you’re not actually going to say where it is are you?

Joe: No I can say we have one on the west coast, and we have one on the east coast.

Paul: Oh, well that’s at least something. Um, I mean so far we’ve concentrated a lot on scaling technology, but there’s kind of another side to this, as well, where you get something like Digg, that has grown incredibly rapidly, over a very short length of time, and that is, kind of scaling the team behind it. You know, I don’t know how many developers were working on Digg when you joined it, but there would certainly be a heck of a lot more now. And I’m quite interested in how you went about growing the team. And how you deal with that kind of rapid growth, and making sure everyone knows what they’re working on, and not overwriting others work, and all the complexity that goes along side of that. How have you dealt with that?

Joe: Sure, I guess, to put things into context a little bit, when I was hired, we had both Kurt Wilms and I, were both hired on the same day, and were respectively employees 18 and 19, and developers, I think there were 7 of us. So, now we’re at the low 20′s as far as developers, and we’re in the mid 80s, as far as total employees, and that’s been in a year and 9 months. So as far as scaling the teams go, some of the building blocks were well in place by the time I got here. Like, source repository, stuff like that. But I think the crucial things that we’ve done, since I’ve come on board, that were, we had some coding standards that were out there, but they weren’t really in force. And then we had, we didn’t really have any frameworks in place. I think one of the problems, you know, when Jay, our CEO, was asking, where do we find more senior developers, I told Jay, like that’s not the right question, the right question is like, how do we get the code, and how do we get the technology, in a position, where we don’t have to hire really senior people. So I think the keys to that are, we do have pretty strict coding standards, so we do enforce those rigorously, through continuous integeration environment, and code reviews. Every piece of code that gets pushed to production has to be reviewed. And that’s literally 4 or 5 coders, sitting in a room, going line by line through change sets, and stuff like that. And that sounds really time consuming, but without question, on every code review I’ve sat in on, we’ve found one show stopper bug. So, those have been crucial, in getting things put together. The other things we did as we grew, is we broke the team up into smaller teams, so we have a development team of 20 – 25 developers, but that’s broken up into teams of between 3 and 5 developers. This really helps in a couple of areas. 1, it enforces code ownership. So everybody has this problem. I code this, then I go and work on something completely different. And 6 months later I come back to this code and I’ve forgotten. I don’t remember any of that. Where as if you’re always working in the same area of the sites, not only do you remember a lot more, you’re a lot more familiar with that. But also, you feel a bit more of a sense of ownership over that. You’re not just this hired gun that’s come in and ploughs through this feature then moves on to something else. You have your own territory that you need to keep track of. You need to keep really nice and what-not. So we did that, and then we have a bunch of core frameworks, that we’ve built. We have a small application framework, we have an AJAX framework, and now, we have this data access layer that we’ve been building up called IDDB. So I think those are pretty crucial too. It’s difficult to find coders that are intimately aware of memcached, and race conditions that exist in memcached, and um, we have to be very selective about what fields we add indexes on in mySQL. We also have to be very selective about how we store that. Normalization flies totally out the window, if you’re a DBA guy. A lot of concepts, they are not bad developers, by any means, they do great AJAX work, they do great application level PHP work, but if you don’t have frameworks in place for them to not have to worry about the super-super complex stuff. It’s going to be really difficult to hire, and it’s going to be really difficult to, you know, get a lot of stuff running in parallel and stuff.

Paul: Wow.

Joe: Yeah, and then we also, another one of the things we’ve adopted, is the agile SCRUM. So we’re doing sprints, and we’re running those in parallel now across all the teams. So right now we have 4 major projects going on right now.

Paul: Ok. So you talk about a sense of ownership there, and the developers are split down into multiple certain areas. You know, does that not get boring, for the developer, having to work on the same bit of code long time, or do you rotate people?

Joe: Well, we don’t currently rotate people, the team structure’s been in place for about 4 or 5 months now. And you know, most of the work they get is fairly immediate, and we’re moving major projects like Facebook connect, so the "Tools and integration team", their doing facebook connect now, and after this, they will maybe work on a new version of the API and so on. It’s written out to wide swaths of the site, so that we have "Site Apps" which does like, all the different applications on the site. And then we have "Tools and Integration" where we have the external projection of Digg, then we have "Core Apps" which is like, search, R&D stuff like recommendation engine, and what not, and then we have "Core Infrastructure".

Paul: So it’s probably enough to be interesting?

Joe: Yeah, we have pretty broad teams, and also, when we put people on those teams, even if someone has an amazing core infrastructure background, but they say, look, like, one of our UI guys, used to be really heavy into core infrastructure stuff when he worked at Quest, and managed massive warehouses, but he says, like, "That’s not what gets me up in the morning any more". It’s like, "Javascript UI interfaces are". So we try to put people on the teams where, you know, where their passions lie. And that’s kind of another thing that people need to recognize. And that’s like, not all developers are driven by, or interested in the same things. We have some, what I would call "UI / Frontend" developers, where like, they could care less about PHP, but we have PHP guys who could care less about Javascript. So I think, recognizing strengths and weaknesses, and capitalizing on those, is pretty important too.

Paul: OK, one last question to finish off, and that is, well you know, the kind of things that you’ve been talking about are fascinating to hear, about the kind of challenges that you have to face with the size of Digg, and the amount of traffic you have to handle. But obviously a lot of people who are listening to this podcast, aren’t at that stage. They are not working on massive projects like that. So I’m really interested in what advice you would have, for those who are just beginning to suffer from scalability problems, and they feel that it’s coming, and it’s something they need to be paying attention to. But it’s not on the enormous scale that you have to deal with. What things can they do right now to prevent problems down the line?

Joe: Um, I think, the easiest things you can do, is you need to re-think the LAMP acronym, because that stack is actually no longer really that stack. I would take Linux, and I’d take Apache out of that stack, and it doesn’t matter, as long as you’re running on a Unix. And as far as Apache goes, Lighty and EngineX are much better at getting a lot more money out of your box, as far as scalability goes. The two areas, that I think people, they sound hard, but they are really easy. One of them is installing and using Memcached, and the other one is installing and using a queuing system of some sort. And I think, like, recently I went through this with a little side project, called "Please Dress Me" which AJ and Gary Benashack and I did.

Paul: Oh, yes yes.

Joe: And we had a very small virtual server at MediaTemple, that survived pretty crushing blows from TechCrunch, Digg, BoingBoing, with almost no load. And that was like, beforehand, memcached is so second nature to me at this point, that I was just like, "Oh, well I’m just going to cache everything in memcached", and it was literally just like this RAM spewing machine. It didn’t actually hit the database. Actually my sysadmin at MediaTemple was like "Something’s really weard, MySQL is only doing like 1 query a second, and you’re doing like 500 requests per second from BoingBoing. So I’m cached. Yeah memcached is just like, it takes literally 10 minutes to install, and probably another hour or two to implement.

Paul: Wow, that sounds excellent, that’s really good advice. Joe, thank you so much for coming on the show, and I can’t wait to get you and Daniel fighting with one an other in the not too distant future. I’m hoping to get a good violent argument about designers and developers, just because I can.

Joe: Laughs.

Paul: I was a little bit disappointed when you guys sat down at Future of Web Design, were far too nice to one another, compared to the evening before, when you’d had a bit to drink, and you were talking in the restaurant. That’s the kind of conversation I want, that real vicious session.

Joe: OK, I’ll make sure that Daniel and I get liquored up before coming on then.

Paul: Yeah, that’s the answer. Ok, thank you so much Joe, that’s really good advice, and we’ll talk to you soon.

Joe: Thanks Paul, bye.

Thanks goes to Nathan O’Hanlon for transcribing this interview.

Back to top

Listeners feedback:

Top web designer applications

Often this section of the show consists of questions for myself and Marcus. However for a change, I thought we should ask the questions. Via the forum, the boagworld site and twitter I recently asked you to vote for your ‘favourite web designer application‘. The response was overwhelming and you can see the complete list of suggestions on UserVoice. However, here are the top 5…

  1. Firebug – Firebug is a Firefox addon that puts a wealth of development tools at your fingertips while you browse. You can edit, debug, and monitor CSS, HTML, and JavaScript live in any web page. A less popular suggestion was the Web Inspector in Safari.
  2. Web developer toolbar – The Web Developers toolbar is a Firefox addon that provides a variety of web development tools. You can disable CSS and Javascript, visually highlight elements, manage cookies and much more. A less popular alternative was the IE developers toolbar.
  3. Adobe Photoshop – A professional image-editing and graphics creation software from Adobe. It provides a large library of effects, filters and layers. This is the grandfather of such applications and many (like myself) use it out of habit more than anything else. Less popular suggestions included Fireworks, Illustrator and Inkscape.
  4. Coda – Coda is a one window development environment for the mac. It includes FTP, text editor, browser preview and even terminal window. A beautifully designed app it appeals to the more visual web designer. Simple, easy to use and elegant.
  5. TextMate – TextMate is a powerful text editor for the mac with an extensive plug-in architecture. From its code highlighting in near endless languages to support for numerous version control systems, TextMate is probably the most powerful text editor out there.

If you disagree with the Boagworld Listeners top five or want to see the other entries then head on over to UserVoice and vote for yourself.

Sending out bulk emails

My second listener contribution comes from the forum. It is a question from Richard about sending bulk email.

Richard writes: I need to send out bulk emails to approx 200k registered (opted in) users on a monthly basis.

Does anyone have any recommendations for an outsourced bulk email provider?

As with the previous contribution I want to focus on your responses rather than my own. This is what the Boagworld community had to say…

Jamie was the first of a number of people to recommend Campaign Monitor. Judging by the feedback from the forum they offer an excellent service but are expensive when compared to others.

As well as recommending Campaign Monitor Nick mentions Silverpop, which he described as ‘an enterprise affair’. Apparently it is not as polished as campaign monitor but considerably more powerful.

Phil recommended two more, Mail Chimp and Mad Mini. He hasn’t used them personally but the prices look good and he says the user interfaces appear polished.

Doug doesn’t recommend a specific service but does refer Richard to a post on Creative Tips which provides a comprehensive review of Campaign Monitor, MailChimp, AWeber, and Constant Contact.

If you have suggestions for Richard or would just like to share your experiences of using bulk email services then contribute to the thread in the boagworld forum.

Back to top

143. Partnership

On this week’s show Paul and Marcus discuss how to promote your web application, ways to improve the client/designer relationship and tools for managing your font library.

Download this show.

Launch our podcast player

Watch the behind the scenes video

News and events

Obama top technology promises

One of the most exciting things about being at this years FoWD conference in New York was that I got to witness the election of the next U.S. president.

Whatever your political persuasions it was a landmark election. Not only will Obama be the first African American president he is also probably the most technically aware.

Obama campaigned aggressively online, from a dedicated YouTube channel to Obama pages on Facebook and MySpace as well as Twitter feeds. He even had his own iPhone application.

So what can we expect from this tech-savvy President? How will he shape the future of U.S. online presence and possibly that of the entire web? An article on tgdaily entitled ‘Barack Obama’s Top technology promises‘ gives us a roundup of various technological promises from Obama’s speeches. These include:

  • A commitment to Net Neutrality
  • A desire to expand broadband penetration in the U.S.
  • A review of the current wireless spectrum usage
  • Tougher legislation around online security.

Of course, promises made on the campaign trail are one thing. We shall see what the reality turns out to be.

Could Microsoft consider adopting Webkit?

Talking of things that may never be, a young (and very brave) developer at Microsoft recently asked Steve Ballmer:

Why is IE still relevant and why is it worth spending money on rendering engines when there are open source ones available that can respond to changes in Web standards faster?

Ballmer’s response was surprising to say the least:

There will still be a lot of proprietary innovation in the browser itself so we may need to have a rendering service. Open source is interesting. Apple has embraced Webkit and we may look at that, but we will continue to build extensions for IE 8.

Although some have seen this as a sign that Microsoft may adopt Webkit, personally I am sceptical. Were Microsoft to completely change its rendering engine it would inevitably break large numbers of sites and cause outrage among many of their large corporate clients.

The backlash when moving from IE6 to IE7 was massive. Moving to Webkit would conflict with Microsoft’s mantra of ‘not breaking the web’.

That said, we can dream. Without a doubt the real innovation and competitive advantage among browsers is in features, not rendering engines. This would in many ways be a smart move allowing Microsoft to concentrate on differentiation through ‘extensions’ and functionality, rather than wasting time on getting pages to display correctly.

WCAG 2.0 resources

Something that is definitely going to happen very soon is the release of WCAG 2.0.

WCAG 2.0. has now become a proposed recommendation. This means it is not only technically complete but has been successfully implemented on a large variety of sites. In short, it has been proved to work.

According to the Web Standards group this means it could therefore be released before Christmas.

This is hugely significant and very exciting from an accessibility point of view. WCAG 2.0. has come a long way from its controversial beginnings and is now a very good set of guidelines.

Now is the time to start building compliant sites and the Web Standards Group has provided some useful resources for implementing WCAG 2.0.

Prototyping with XHTML

Our final story is a post on the Boxes and Arrows website encouraging us to ‘Prototyping with XHTML‘.

The article lays out an approach to wireframing and prototyping, which is based entirely around the use of XHTML. Starting with the XHTML itself, you build up the structure and elements within your site. You then add CSS and Javascript to further refine the concept.

It is an approach with a lot of merit. Unlike other methods, the prototype is not thrown away but becomes apart of the final deliverable. It is also an approach particularly suited to multiple iterations, allowing you to refine the design over time.

In a world of web applications it is becoming increasingly important to demonstrate user interactions in a way static comps cannot. However, although this approach is appealing I do not believe it replaces the Photoshop mockup. Client’s like to see ‘finished’ looking designs. That said, it is another useful tool in your arsenal and you should be sure to read this post.

Back to top

Feature: A Partnership of Cooperation

At this years FoWD I shared how the relationship between web design agency and client is fundamentally broken. Where there should be mutual respect and cooperation, there is negativity and mistrust. Read More.

Back to top

Listeners feedback:

Marketing a web application

Nick Charlton writes: Long time listener, haven’t asked a question before though..

Apart from your blog, the podcast and twitter, how else have you marketed GetSignOff?

To be honest, I have done very little marketing yet. However, I know that has got to change. The problem is that I am not a trained marketeer and so don’t really know what I am doing. That said I do have a rough plan:

  • Free pro accounts – While in beta we gave away numerous pro accounts to ‘web celebs’. However, to be honest it was a waste of time. These guys were either too busy to review it or just didn’t feel it was worth writing about. This time I intend to give free accounts to those who blog about the application. Not entirely sure how I am going to do this yet but I think it might generate some buzz.
  • Offering discounts – Discounts are an effective way of spreading word of mouth. Again I am not entirely sure if or when we will do this, but offering the occasional discount should encourage people to tell their friends.
  • Targeting appropriate publications – I am in the process of writing a number of articles either directly or indirectly related to GetSignOff. I have also asked some sites to review the application. I have approached sites like Digital Web, Think Vitamin and printed publications such as .net. Having a product aimed at people like myself makes identifying appropriate publications easy.
  • Producing supporting video content – I have already produced the ‘Getting design sign off‘ presentation but also intend to make some shorter tutorials for YouTube. These will contain valuable content in their own right, but will also promote GSO.
  • Utilising CSS galleries – Because my audience are web designers we have submitted GSO to several CSS galleries. We know that many web designers use these sites and so this gives our application a lot of exposure.
  • Use speaking opportunities – Speaking opportunities have been a great opportunity for promoting GSO and I have started tailoring my speaking slots around the subject of sign off.

In time we may consider advertising through things like Google Adwords or the Deck. However, until we are confident in the return on investment we are not willing to invest more money in anything other than development.

Font management

Aurel writes: I would realy like to know how designers deal with fonts? From personal experience, I have alot of fonts and it takes me time to find or manage them. So I was wondering if you know of any way to group the fonts, e.g. when you go through the drop menu of fonts in photoshop, they apear in groups (or something along those lines).

The solution I use was recommended on the Rissington Podcast (oh the shame of admitting that.)

It is a piece of software called FontExplorer X which is available for both the mac and PC. It has some superb features if you are serious about fonts. These include:

  • Organising your fonts – Organise using a library, folders, tags and even smart sets. You can directly access all typefaces from a certain foundry or all fonts tagged with a certain keyword? You can even view all italic fonts.
  • Auto activation – FontExplorer allows you to decide which fonts are available in which applications. This is ideal if you want to avoid scrolling through large numbers of fonts in applications like Photoshop.
  • Font information – FontExplorer gives you a clear customisable preview of your fonts as well as detailed information on the character set and usage restrictions.

The application also has an in built store that allows you to buy additional fonts within the same intuitive interface. I am guessing this is how they manage to offer the whole application absolutely free.

Back to top

140. Launch

In this week’s show GetSignOff has finally launched, we talk about how to use web stats to improve your site and we answer your questions about roles with web design and should you help clients with hosting.

Play

Download this show.

Launch our podcast player

News and events

Acid3 receptions and misconceptions and do we have a winner?

The team that develop WebKit, the open source web browser engine that Safari and the new Google Chrome are built on, have just announced that the engine passes the Acid3 test developed by The Web Standard Project (Wasp).

So what is Acid3?

Acid3 runs a series of tests against a given browser and produces a score, the goal being 100/100. This score is generated from how "standards compliant" the browser is. For example whether it supports CSS2.1 styles such as "inline-block" and "pre-wrap", if it supports SVG-Fonts, what DOM features is supports and a whole range of other criteria.

So WebKit passes!

Does this mean we should ditch Firefox, IE and all the other browsers in favour of Safari or Chrome, well no, and that’s what Lars Gunther is talking about in his article over at WaSP.

It’s great that tests like Acid3 exist and that browser developers endeavour to build better browsers because of them. All in all it results in a much better experience for the average user and makes our lives as Web Designers much more hassle free.

6 Things To Like About Dreamweaver CS4

So Dreamweaver CS4 became available this week, 15th October to be exact and Alex Walker over at Site Point has been having a play and has shared with us 6 thinks he likes about the new release. Check out his article for details of each, but a summarised list is:

  • UI/Workflow Improvements
  • The Related Files Toolbar
  • Code Navigator
  • Live View
  • Advanced JavaScript Interpretation
  • Making JavaScript Unobtrusive

From reading the article these improvements over the previous version look really promising. One feature that really caught my eye is "intelligent code completion" for JavaScript and the most popular libraries such as jQuery, MooTools, Prototype etc, the same way it does for HTML!

It would also appear that Adobe are making big improvements to the "Display View" of Dreamweaver, which has historically been the stigma plaguing most "professional" designers who use it. The "Display View" now has integrated code navigation, so you can use it to jump to specific elements within the page and Adobe have also built WebKit into Dreamweavers core so you can run your site through the software to test JavaScript, rendered CSS, server-side code etc.

So will these new features encourage more people to use Dreamweaver?

7 Ingredients of Good Corporate Design

Smashing Magazine has published a great article that discusses 7 ingredients to good corporate design. They break the discussion into two elements:

  • Design as artistic representation, which consists of:
    • Logo
    • Typography
    • Colours
  • Design strategy, consisting of:
    • Brand
    • Quality
    • Community
    • Culture

It’s important to understand that corporate design isn’t simply of a graphical nature but is intrinsically linked with your strategy, the goals that you set and how you implement them and this article is well worth the read.

Back to top

Launch: GetSignOff Goes Public

Monday GetSignOff finally opened to the public. It has been an interesting journey read more here.

Back to top

Feature: Using Web Stats for More

We all use web stat tools like Google Analytics for tracking marketing campaigns. However, they can also be used to improve your site. We discuss this in this weeks feature.

Back to top

Listeners feedback:

Salesman seeks designer/developer

Got this audio question from Andrew:

Hi Paul, hello Marcus and hi to all the people who work at the show. I live in Canada so hearing your nice English voices through my headphones is great. My name is Steve and I’ve done some freelance web design for clients in the past, but the part I enjoyed the most was the selling cycle; being able to explain to the client what a standards based website could do for them and then persuade them that investing in such a site would be wise for their business. I bet there’s a lot of designers and developers out there who are absolute Jedis when it comes to coding CSS and HTML but really hate the selling part. And then there are people like me who can really sell well but I wish I could work with people who are amazing at building websites.

My two-pronged question is as follows:

Is there a website or another resource that would allow people like me, who love web design, but are more business/marketing oriented to touch base with people who are in the opposite situation? And I’m thinking more than just a job board here, I guess the best analogy would be something that Marcus might be familiar with – adverts in the back of music magazines that would say something like ‘band seeks drummer’ or ‘talented singer needs people to play instruments’.

My other question: how did you guys do it at Headscape, were you all great at coding and someone had to get pushed out the door and start selling or were there very separate roles from the beginning?

Ok, part one first (I’m original aren’t I)… the ‘band seeks drummer’ analogy is good but I much prefer a dating agency analogy! Cuddly, financially sound salesman WGSOH seeks quiet, intense, practical developer for fulfilling relationship. :-)

As far as I am aware, sadly, this service does not exist. Forums, like the Boagworld forum, have got to be your best bet.

Right, part two. Much as I would love to claim that I used to be great at coding before they kicked me out of the door to do the selling, it would be a blatant lie. When Headscape started, the three of us came from different disciplines – Paul was designer/tech (it’s true!), Chris was project manager and I was salesman. We soon didn’t have enough design/tech resource and started to recruit but the fact that a) Chris was organising and pushing projects along and b) that I was concentrating on bringing in new work meant that we were running things like a larger agency (more efficiently and with less risk) very early on.

I have banged on about how important effective selling is in the past many times so won’t repeat myself here. The only thing I will say is that having totally separate roles is not necessarily a good thing. Even now, we don’t have very separate roles. Chris and Paul are both heavily involved in the sales process and always have been. In my view, it is the responsibility of the company directors to se
ll.

But, added to that, Chris and I also do a lot of consultancy work (requirements analysis, IA work etc), and Paul still does design work. This is important because it keeps our ‘hand’ in. Getting too involved in one role can often lead to a lot of potentially out-of-date talking, and very little ‘doing’.

Do/should you help clients’ with hosting?

Hi all

I’m just about to do a ‘simple’ website for a friend (aka my 1st client) which will try to market something he is looking to rent out. Whilst I’m confident I can do the website, I’m not sure how far I should go with helping/organising his hosting. The client doesn’t know anything about hosting and doesn’t have any hosting space with his broadband provider.

Now I don’t really want to get into organising hosting unless I have to, so I’d just like to know what the ‘norm’ is in this regard? As a web developer/firm do you automatically sort out hosting, do you get the client to do it and then give you the hosting password so you can upload the site? Is it even a good/lucrative idea to get involved in sorting this out as part of the ‘service’? Can people suggest what they do please?

Thanks, Alex

This question came from the Forum and there are already some interesting posts in response. The biggest issue here is:

Can you support this website?

Can you provide support if the site goes down in the middle of the night, on Christmas Day, or even when you’re on your two week break to Spain?

If you decide to sell hosting then you become a middle man between your client and the hosting company. Your client is contracted to you to provide and support hosting, not the hosting company. Of course, you have a relationship with the hosting company where they will provide an agreed level of support but… you are still the person that has to deal with your clients’ issues as and when they arise.

At Headscape we are completely open about this with our clients. We tell them that we only provide support (of any kind) on working days between 9am and 5.30pm. We’re not set up to do anything more than that.

However, we do offer hosting for those clients that feel that the level of support that we offer is enough. We have our own managed platform and we also act as a reseller for a large hosting company.

The solution for those clients that require a superior level of service is simple. The client buys the hosting directly thereby taking you – the agency/freelancer – out of the loop. We specify technologies, discuss the level of support required, amount of bandwidth etc with client – we will also set up the site on the web server – but the client orders and pays for the hosting.

This has worked really well particularly for the larger, busier sites that we have developed.

All that said, if you act as a reseller, and you have enough clients, you can make a decent profit via hosting. However, don’t be fooled into thinking that it doesn’t involve any work keeping all those clients happy and up to date. If you have enough clients to make money out of hosting then it’s very likely that you will have regular hosting issues to deal with and constant renewals to deal with.

My friend and colleague, the long suffering Mr Scott, has many times said that he wished we had never touched hosting simply because it often ends being a constant irritation that gets in the way of project work and rarely pays for itself.

Back to top

Don't panic!

According to Jason Calcanis and Michael Arrington the tech sector is in economic free fall. But, is the doom and gloom justified?

I am no financial expert. I have no idea how the economy works or how the actions of the stock market impact the rest of us. What I do have is my experience of the the dot com bust in 2001 and that tells me there is a lot of unnecessary panic flying around.

That said, I can understand why the likes of Jason Calcanis and Michael Arrington are twitchy.

I have said it before and I will say it again, any startup whose business plan is built solely on advertising revenue or venture capital has no business plan at all. When an economy gets into difficulties those are the first two areas of revenue to dry up. Companies do not advertise when they start tightening their belts. They certainly do not invest.

It is therefore unsurprising that there is a growing sense of unease in Silicon Valley. As with the last dot com boom there are a lot of companies with naive business plans. I am concerned for my friends who work in companies like that. I think they have worrying times ahead.

However, for the vast majority of web designers things are nowhere near as concerning. We are not supported by advertising or venture capital, but by delivering a service. Depending on our clients we probably have little to worry about.

There are of course exceptions. If your clients fall into the following categories, then I would look to alter that client base slightly:

  • Web 2.0. companies – If they are being squeezed then they will stop investing in their site,
  • Advertising agencies – As the wider economy tighten its belt they will stop spending with advertising agencies and this will trickle down.
  • Very small businesses – These people still see websites as a marketing spend rather than an intrinsic part of their business. If times get tough they will cut this expenditure.

However, if you clients do not fall into these categories, you probably have no need to panic. Things will slow down and you will see a trickle down affect, but if you can weather the storm there will be good times ahead. Recessions tend to clear the forest of dead wood and leave opportunities for growth later on.

136. Stagnation

In this week’s show we talk about overcoming stagnation and Ed Merritt shares a technique to achieve fixed footers without the use of javaScript.

Download this show.

Launch our podcast player

News and events

Design by committee vs design by community

We all know that design by committee sucks, but why? What is it that makes the process fail and what would happen if you took it to the extreme, and opened up the design process to an entire community?

That is exactly what Mark Boulton has done with the redesign of the Drupal website. With over 200,000 registered users this is a significant community and not the kind of environment where you would feel inclined to design in the open.

However, according to Mark it has generally been a success.

The key would appear to be scale. In design by committee you typically have a handful of decision makers, and one or two dominant individuals who overwhelm the others. It is an environment of conflict and compromise.

However when designing by community, the sheer scale of the community drowns out anybody who seek to dominate the process. You move from an environment of personal opinion to one where you are monitoring emerging trends.

So next time you have a client wanting to design by committee, consider opening up the process rather than locking it down to one or two decision makers.

Self Directed Projects

When was the last time you worked on a personal or internal project? Do you do anything that is not paid client work? If not, then according to IdeasOnIdeas you should start.

This post interviews several designers about their their non-client work. It becomes obvious as you read that self directed projects offer real tangible benefits. These include…

  • R&D – The chance to experiment with emerging technologies and techniques, that otherwise you would not get to try out.
  • Build visibility – Higher exposure online as people are attracted to your work.
  • Prove capability – Demonstrating your ability to deliver solutions not in your portfolio of client work.
  • Increase skills – Allowing you to improve your skills in areas where they are weak or have not been maintained.
  • Team building – Building a sense of common purpose among your team in a way that is more engaging than client work.
  • Creates passion – Allowing you to work on a project that generates excitement rather than ones that simply pays the bills.
  • As a release mechanism – The chance to play, and let off steam after the limitations of client work.
  • After years of spending all my time on client work, I have now reached a point where most of what I do is self directed and I can honestly say it is a joy. I also think it has been hugely beneficial for Headscape.

    Understanding Disabilities when Designing a Website

    Back when I was a teenager the government launched a massive campaign warning of the dangers of unprotected sex and in particular the risk of contracting HIV. It was a very powerful campaign and led to a generation growing up much more aware of the risks. However this campaign wasn’t followed up for the next generation and the rates of sexually transmitted diseases increased.

    Why do I bring this strange analogy up? Because I believe we are in danger of doing that with web accessibility. Many of us are getting bored of talking about accessibility. It feels like we are covering the same old ground. Why do we need another article about accessibility basics? We have heard it all before, right?

    Well maybe some of us have, but there is a new generation of web designers who have not. They need to know what we take for granted. Also, it wouldn’t hurt us to be reminded every once in a while.

    That is why I was so pleased to see Digital Web publishing an introduction to accessibility this week. Sure we have heard it all before and you might be tempted not to bother looking it up. However, I would encourage you to take the time. I guarantee it will give you at least one piece of advice which you fail to implement currently.

    More ways to find inspiration

    I often talk about how we need to look for inspiration beyond the web. In fact in this weeks Smashing Magazine, they post some incredibly inspiring graffiti that is worth a look. But, can we be inspired by other websites or does that always end in plagiarism?

    It’s a dangerous game when you start turning to gallery sites for inspiration. Before you know it you can find yourself lifting far too much of the design.

    How then can you be inspired without ripping off somebody else’s website? One way is to look at the design and ask yourself which specific elements you like. Is it the navigation, their styling of bullet lists or the way they handle the footer. By looking at individual elements rather than the whole you remove the temptation to copy the entire thing.

    This is what a designer from Portugal has done. He has made screen grabs of websites and placed them in his flickr account. However, rather than grabbing the entire site, in most cases he captures only a fraction of the page. He removes the temptation to steal a whole design and yet provides himself with inspiration next time he needs to design a comment form or build an online calendar.

    Take a look at his inspirational flickr feed and hopefully it will encourage you to take a similar approach.

    Back to top

    Feature: Overcoming Stagnation

    For many websites the days of rapid growth have passed and they have slipped into stagnation. How then can you re-energise a site and start it growing again? We look at this in this weeks feature.

    Back to top

    Listeners feedback:

    Fixed Footer without javaScript

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

    Ed begins…

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

    Back to top

    135. Libraries

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

    Play

    Download this show.

    Launch our podcast player

    News and events

    The complexity tax

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

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

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

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

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

    10 Rules for Driving Traffic Using Forums

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

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

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

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

    Accessibility in suit and tie

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

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

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

    UK Government Browser Guidelines

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

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

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

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

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

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

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

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

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

    Back to top

    Interview: John Resig on javaScript Libraries

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

    John:Well, thanks for having me.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    John:Thanks for having me, Thank you.

    Thanks to Todd Dietrich for transcribing this interview.

    Back to top

    Listeners feedback:

    Quality or Quickly?

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

    I received this question from Pete in South Africa…

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

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

    To read the rest of this blog click here.

    Back to top

    131. Version Control

    In this weeks show Ryan and Stanton return to talk about the importance of version control and answer your questions on project  management and invoicing applications, download sizes and page weight.

    Play

    Download this show.

    Launch our podcast player

    News and events

    Twitter Cuts UK SMS

    This week the team over at Twitter announced that they would no longer be delivering outbound SMS over there UK number. They go on to explain that the bill which up until now they’ve been footing is simply too great and that even with a limit of 250 messages per week they estimate a yearly cost of $1000 per user.

    Thanks to established relationships with SMS services in Canada, India and the United States the outbound SMS service will be continuing uninterrupted in those countries.

    Twitter has suggested a number of alternatives to the service, links to which can be found on their blog. It would also appear that a number of start-ups are rushing to fill the void as TechCrunch have also reported.

    A large portion of Twitters popularity is due to their SMS facilities and it is feared that “freezing” out the UK and other countries from this service will be detrimental to their future.

    It reminds me of when Pandora, the online radio station, closed its doors entirely to its UK audience due to licensing constraints and it begs to question do we poor souls in the UK miss out on all the good toys?

    facelift (FLIR) Image Replacement for Fonts

    Facelift Image Replacement (or FLIR, pronounced fleer) is an image replacement script that dynamically generates image representations of text on your web page in fonts that aren’t otherwise supported in web browsers. The generated image is automatically placed on your site and works in a similar way to sIFR, the big difference being the lack of Flash.

    This script uses PHP and javaScript and utilises actual .ttf font files to generate its replacement images, so you can simply specify which elements you want to replace, h1, h2 tags etc, download a font you want to use, point the script to it and your done.

    I’m looking forward to having a play with this script as it seems to be simple to use and the fact that you don’t have to mess around with Flash like you do with sIFR is a big bonus in my book.

    Take a look at the number of examples they have on their website and see for yourself.

    Gmail went down!

    So Gmail went down for a few hours this week and as Josh Catone said in his sitepoint article article:

    Judging by the reactions on Twitter and in the blogosphere, you’d have thought that the world ended.

    There’s nothing really more we can say about this that Josh hasn’t already mentioned, but suffice it to say, no web sites/app is going to have 100% up time and this echoes what Stanton and I were talking about the other week in regards to S3 going down. It’s important to always have a backup and not to put all your eggs in one basket because when the service you’re using goes down, and invariably it will, you need a plan B.

    Back to top

    And Now For Something Completely Random

    During the recording of this weeks podcast we were thrown completely when we spotted Paul Annett from Clear:Left dressed up as a Gorilla on Yahoo Live! and then proceeded to start dancing… always aiming to share the hysterics here’s proof. Random indeed.

    Paul Annett Dresses as a Gorilla

    Feature: To Version Control or Not?

    Version control can seem like a very daunting thing to incorporate into your work flow, but once it’s there you can be left wondering how you ever lived without it. In this week’s feature Stanton shares his experiences with you in a bid to convince you why you need it.

    Back to top

    Listeners feedback:

    Project Management and Invoicing Applications

    James writes: I would like some boagworld advice. I’m a web designer and SharePoint specialist at a large company in Cambridge, UK. Over the last 3 to 4 years i have been messing around with web design etc. I now am very busy outside of work and it is getting busier every month.

    I started of with a server under the bed at home with UPS hosting these sites. They ranged from personal sites, to company profile pages to shops. This server has now been replaced with a VPS hosted externally.

    My plan is to keep working full time and manage my time very carefully outside of work and keep these sites coming in and out etc and then one day take the big leap into the self-employed world.

    What could you recommend for me to manage my tasks, projects, time-management and invoicing etc?

    I love the podcast and would be quite happy to chat further with you. Look forward to hearing your experience comments.

    Well there is a multitude of online and desktop applications designed specifically for managing your business.

    Probably the most popular project management app I know of is 37 Signals’ BaseCamp and that’s certainly the first one that springs to mind when I’m asked this question. Depending on what package you have, BaseCamp allows you to create projects, set milestones, to-do lists, manage time spent on tasks among other things, however BaseCamp is tailored more towards collaborative projects for when you’re working with a team of people. It doesn’t provide facilities for invoicing clients and managing your accounts and so it might not be the perfect choice if you working alone.

    Another app I know of and which comes highly recommended is FreeAgent. FreeAgent like BaseCamp allows you to create and manage projects, clients and timescales, however in addition it provides you with the facility to generate invoices, manage your bank accounts as well as your expenses and incomes. It’s designed for sole traders, partnerships and limited companies and is wrapped up in a nice, user friendly interface.

    A final mention goes to a Microsoft app that I came across a couple of years ago now, and has only this year been release in the UK. It’s called Office Accouting Express 2008 and it’s actually free to download and use. As you would expect it integrates with other Office applications and provides you with all the facilities you would expect from an accounting package, invoicing, client management etc. So if you’re working on a PC it’s worth having a look.

    Luckily you can have a play with all these apps before you buy. BaseCamp has a free account which allows you to create 1 project so you can get in and see how it all works, FreeAgent has a series of demos you can use to see if the interface and facilities are to your liking and as I’ve said Office Accounting Express is free. So my advice would be check out them al
    l and see what works for you and no doubt there will be several suggestions in the show comments on other apps that I haven’t mentioned here.

    Download Sizes

    Bob writes: After reading a recent post from Smashing Magazine on textures I started to wonder… what is a good rule of thumb regarding document size per page on the web? Most of the example pages in the article ranked in at close to 900kb per page… am I behind the times?

    Very good question, and one I think we all worry about at points. There’s more than just the filesize to really worry about, there’s the general ‘page weight’ which is affected by many factors, such as:

    • The number of HTTP requests made – if you’re pulling in a lot of external javaScript or CSS files, each one has to be requested seperately. You can combine these into single files to reduce load times, but at the expense of readability, maintainability and organisation
    • The size of any javaScript files you’re pulling in – you can get minified versions of most libraries, for example, which strip out all the extra spaces and line breaks in the code, which aren’t needed in order for the code to execute
    • CSS expressions can be a useful tool, but are bloody slow, especially when used a lot
    • Image filesize can have a massive effect on load times, which is one of your main concerns as you mentioned textures. I’m assuming you’re already familiar with image optimisation, but also test to see if you can squeeze images into a GIF, or a PNG8 if possible, these formats will give you a nice small filesize if you only need a limited colour pallete.

    In this day and age it’s nice to think that we’re all cruising on nice fast broadband connections, but in reality we know that’s not the case and you really have to consider your audience, and the context in which they may visit your site (Paul’s talked about this quite recently). If you expect an older demographic to your site, or people in remote areas, then they might still be hitting you on a dial up connection. Some visitors may be using poor public wifi (I get suicidal on the train to and from London as the wifi is usually worse than dial-up), or mobile devices where the data charges can be ridiculously high.

    There are a couple of tools I use to get an idea of how my pages weigh in:

    There is a Firebug addon called YSlow which provides some nifty statistics on what’s happening under the hood of the pages you visit, and also grades the page performance and suggests methods to improve the loading time of your page.

    I tested 2 sites quickly with this extension to give an idea of what you can expect to see, Amazon and Boagworld.

    • Amazon.com weighs in at 501k with 85 HTTP requests and a performance rating of D
    • Boagworld.com is a bit lighter on it’s feet at 57.6k and 79 HTTP requests, but has a performance rating of F, due to (among other things) including 37 external javascript files compared to Amazon’s 8, and 33 CSS background images compared to 9 with Amazon.

    I also use a Firefox plugin called Firefox Throttle which lets you simulate a specific network speed (such as 56k) and get an idea of how long your site will take on certain connections.

    Unfortunately I don’t think there’s a good rule of thumb here. Personally, I don’t let the page weight issue affect or limit my design, but try and make savings where I can nearer the end of the project, by optimising images, switching to minified JS libraries and reducing the amount of HTTP requests where possible.

    Back to top

     

    127. Context

    In this week’s show we discuss taking context into consideration when designing websites and we answer your questions about video for an elderly audience and the most influential books in the industry. 

    Play

    Download this show.

    Launch our podcast player

    News and events

    Working from home

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

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

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

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

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

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

    British Standard for accessibility

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

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

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

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

    Growing your business through twitter

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

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

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

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

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

    Smart CSS aint always sexy

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

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

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

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

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

    Back to top

    Feature: Content is dead, long live context

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

    Back to top

    Listeners feedback:

    Video and an elderly audience

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

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

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

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

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

    Most influential books

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

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

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

    125. Copy

    In this weeks show we discuss how to give personality to your site copy and we talk with Elliot Jay Stocks about going freelance.

    Play

    Download this show.

    Launch our podcast player

    Watch the behind the scenes video

    News and Events

    The clever chaps at Carsonified

    If you happen to follow any of the guys at Carsonified on twitter, you cannot help but know they are working on a not-so-secret project called Matt.

    It is an interesting idea that they have done once before. They stop all normal work for a week and blitz a small self contained project using an Agile style approach.

    The final result is not what counts. It is the exercise itself that I find interesting. By doing this periodically they…

    • Create a lot of buzz which reflects well on their company
    • Build a great sense of camaraderie
    • Get to try out new technologies and techniques
    • Break the routine of everyday work
    • Push people’s comfort zones and help develop new skills

    It’s a great plan and one more of us should adopt. It is certainly something I would like to do in Headscape. Of course it is more tricky when you have clients with deadlines however the principle still applies. You may find it hard to do this for a week, but maybe a single day is possible.

    Adobe make flash searchable

    The big news of the week is an announcement by Adobe that they have been working with both Google and Yahoo! to improve the indexing of flash. This is no real surprises as the SEO of flash has been a major headache for the technology. The surprising bit is that they have succeeded, at least in the case of Google.

    Apparently Adobe have created a special flash player for the search engines that acts as a virtual user. This user trawls through each swf converting the content into something search engines can understand.

    Apparently Google is in the process of rolling out the technology. Unfortunately Yahoo! apparently have "some work to do." Nevertheless this is a promising step forward.

    Of course until Adobe make it easy for the average blogger or website owner to deep link within a flash file, the 73 million flash sites are not likely to be highly ranked.

    Colour blindness on the web

    My final story for the day is a post on colour blindness by Richard Rutter. To call this news is a huge stretch as the article was published in 2005. However, I have only just found it so it is news to me!

    I have to say I love this post. At the very beginning Rich tells us he is colour blind and so I braced myself for feelings of guilt and inadequacy as he tells me my sites are inaccessible. Instead I got this…

    The thing is, colour blindness on the Web isnÕt a big deal. You do have to bear it mind (as I will show later on), but there is no need to let it dominate any design decision.

    What a breath of fresh air. He then goes on to give some very simple advice that anybody can follow…

    • Do not rely on colour alone to convey information (such as on Jeff Veen’s blog)
    • Do not write instructions such as "click the green button"

    He goes on to dispel some misconceptions and provides good examples of where things can become a problem.

    If you worry about the large number of colour blind users out there (and you should do), then give this post a read.

    Back to top

    Feature: Copy with Personality

    Too much of the copy I read on websites is bland and uninspiring. Its time to add some personality. We look at this in this weeks feature.

    Back to top

    Interview: Elliot Jay Stocks on Going Freelance

    Paul Boag: So joining me today is Elliot Jay Stocks previously from Cansonified now a freelance web designer, in the depths of Norway I hear earlier.

    Elliot Jay Stocks: Yes. That’s all the hype depending on how you look at it.

    Paul: Well it’s really good to have you on the show.

    Elliot: Thank you for having me.

    Paul: Normally when we get people on the show it’s to talk about some specific area of expertise or something like that. Although I know you have many, many areas of expertise I wanted to get you on the show just because of the really interesting thing that you’ve chosen to do. The fact that you’ve left a fairly well known company that had a really good reputation. That you’ve decided to go freelance. And you’ve decided, at least for a short length of time to work from Norway, as a bit of an adventure. Is that the right way to put it?

    Elliot: Yeah I guess so. I don’t like to do anything by halves. I like to do everything at once. So we gave up our flat my girlfriend went off travelling to the far east. I moved to Norway and at the same time decided to start up my own business. So quite a few life changing things at once.

    Paul: Cool. I mean that’s really exciting and I guess that’s the power of freelancing, that you’ve got the freedom to work from wherever you want.

    Elliot: Yeah and the power of the web in general. You know whenever anybody says "How can you do that?" I say I’ve got my laptop and as long as I’ve got an internet connection then it’s all good. Although having said that my internet connection here is really dodgy.

    Paul: Which is why I’m calling you on an ordinary phone line.

    Elliot: Right. Where I’m staying unfortunately there is something wrong with the router where it doesn’t allow ftp or any way to send email out. So there’s no upstream traffic. Which isn’t that great when you’re a web designer. So my new office, as it were, is one of the local coffee shops.

    Paul: In order to get ’round the problem. So we’ve got loads of people listening to this show that either are web designer’s in an agency of some description or in house designers somewhere or alternatively people maybe not working in web design at all at the moment but want to. So we get lots of questions about freelancing and I thought okay let’s get somebody on the show that’s literally just gone through this process. And kind of ask you a few questions about you’re experiences a
    nd how its gone. I guess the biggest one and the one that we probably should start with is overcoming that kind of fear factor of giving up a regular income. How did you kind of convince yourself that this was a good idea?

    Elliot: I’d been thinking about going freelance for a while. Not to swat at Carsonified, but sort of the entire time I’ve been working at a web designer. I started off doing freelance things in University. So like doing site for things like friends bands and things like that. I mean I carried on doing that as soon as I started working in the industry and have carried on the last 4 years or so doing bits and bobs, evenings and weekends. Although I’ve only just started doing it fulltime I’ve got quite a bit of experience doing it on a part-time basis which obviously is a little less scary, when you’re making. I think the other thing as well at Carsonified most days of the week I actually worked from home, in London, so that was a really good testing ground to see if I had the self discipline to work by myself all day and stay motivated and stuff like that. So because of that it was slightly less scary making the actual jump.

    Paul: So would you recommend that to somebody who is considering going freelance? To kind of build up some work on the side and also if possible to negotiate some home working to see how you get on with it?

    Elliot: Yeah definitely. It’s something that’s not suited to everybody. Obviously there’s the appeal, everybody thinks WOW I’d love to work from home, loads of freedom fantastic. But, people I have spoken to have said I find it very very hard to get motivated when I’m at home. It’s easy to get distracted. The other thing as well is it can often be quite lonely. Jonathan Snook recently wrote a post about this on his site. He was disussing these ways of battling freelance loneliness. You know going to the local coffee shop for instance. Which is another thing to bear in mind when you’re doing it. There’s the option of working entirely by yourself. Working in the public, like the coffee shop. Working in a shared working environment. I’m still undecided really. I get on fine working by myself, but when I get back to the UK we’re not sure exactly where we’re gonna go. Depending on where we do go I may look into some kind of co-working space or whatever. There’s a possibility that we might go Oxford way, if so I may shack up with the old Rissington chaps, which would be lovely.

    Paul: That would be superb.

    Elliot: Yeah.

    Paul: Well obviously no it wouldn’t because they’re nothing but rude and obnoxious to me so I’m in no way supporting that decision.

    Elliot: And they’re a rival podcast.

    Paul: Well it’s not so much the rival podcast it’s the fact that they’re just so jealous and envious of my huge success (Paul laugh maniacally).

    Elliot: Well I hear you’re the one who gets noticed on the tube anyway.

    Paul: Well yes this is true. Okay moving back to the interview and on with the questions. Cashflow is obviously something that always scares people. Not just when making the leap into freelance. How do you actually fund it starting off? You know in those first few weeks. How did you go about that? What was your solution to the problem?

    Elliot: I’m not sure that my solution is the best one. People always say to make sure you have some money in the bank. You know enough to see you over for 2 or 3 months so that if it’s very slow starting off, if you’re not getting a lot of work in or if you are getting work in but clients are slow paying you’ve got a sort of fall back plan. I made sure I had a bit of money in the bank so that if it all went horrible wrong I’d still be able to survive. Luckily at the same time because we moved out of our flat and I am now living in Norway temporarily. Although Norway is horrendously expensive to anyone but Norwegians it’s actually cheaper working out here living here at the moment because of the reduced rent compared to what I was paying in London. So that was one factor that made it a little bit easier. The other thing is that I alread had a lot of work already booked in before going freelance. I think more than anything that’s the important thing when people make that jump, is having the work there. So rather than jumping and saying okay I work for myself now I better go get some work. To already have as much lined up as possible. Fortunately I am in a position where I had loads of stuff booked up a couple of months in advance. That was a good safety net. Obviously clients can be slow to pay so I always ask for 25% deposit before I start. That’s 25% based on the estimated amount of the project. But it’s a nice little safety net to have in there. It means you have a little bit of cash and if they decide that they want to be horrible at the end and not pay you’ve got a little bit of something to fall back on.

    Paul: Sure. I mean it’s interesting that you said that you were fortunate enough to get some work lined up before you began. I mean the obvious question is how did you achieve that. You must have been marketing or been selling yourself in some way in order to attract that work.

    Elliot: Selling myself. (laughs at Paul’s implied dirty joke)

    Paul: Selling yourself in the nicest way.

    Elliot: Yeah to some degree. I’ve been very very fortunate and I haven’t had to look for any work yet. So far people have got in contact with me so I haven’t had to go out there and kind of beg for clients or anything. Obviously Carsonified was quite high profile stuff. Prior to that when I worked in the music industry luckily I got work with some very high profile artists and bands so because of that and because I had those things in my portfolio that was part of the marketing. People see these kind of bigger bands in your portfolio. It definitly makes it easier because regardless of the work I think it kind of impresses people if they see a name that they recognize. In terms of marketing I guess this time last year, or I guess just over a year ago, the recent version of my site and things kind of took off from there really. I’ve put that on a load of CSS galleries which obviously helps because they get so much traffic. I think still sites like CSS Beauty and Web Designer Wall they’re still some of my biggest refers even now. So I think getting you’re site on there, getting people to look at it there that often has a snowball effect of having the other galleries picking it up and other sites and
    things like that. So that obviously helps. In terms of the work for the next few months, I’m actually launching a new version of my site which will probably launch in a month or two’s time. And I’m gonna do the same things again. Put it on lots of gallery sites. Tell people about it. I think having a new site with an emphasis more on the work more than just being a blog that will hopefully help as well in the continuing marketing. Luckily enough, doing things like this even lets people hear about you some more and I guess the thing with marketing it’s just to get your name out there in which ever way you can. To get people hearing about your stuff.

    Paul: So would you recommend, if someone’s talking about going freelance, say a new graduate that has just come out of university. Would you actually encourage them to try working for an agency where they can perhaps build up a portfolio of bigger clients before they go freelance? Or is there really no reason why they shouldn’t go freelance straight away.

    Elliot: No. I would definitely encourage working for an agency or as an in house designer for some kind of company before hand. When I left university my flat mate and I were condsidering starting up a business and I was thinking about this this morning actually. If we’d have done that and we could have done it I guess and maybe done okay out of it but the first thing is. I don’t think I would have then got access to the kind of high profile clients that I have got through my previous work experience so in that sense I probably would have still be struggling now to market myself and convince people I can work with big brands. The main thing that I, you know the wealth of experience that working in an agency will give you is definitely something not to be under estimated. Dealing with clients. Dealing with rediculous deadlines. Obviously these are things that your pick up being freelance as well but being inside an agency and working with other people and getting a feel for the industry that you are in, the working environment. The requirements. Things like that. All of that stuff. I am very grateful that I decided not to start my own business that early on and actually went to a real job as it were. So I would definitely recommend that people do it, that graduates do that. As well I thinks it’s just you learn a lot about who you are as a designer and where your strengths are. I mean when I was at Young life I was completely Flash. 100%. I barely new HTML at all when I started there because I was so interested in Flash. Obviously now that has completely changed. Now its much more, well completely standards based. That’s sort of where I specialize in now. If I hadn’t gone through that process I may not have realized that.

    Paul: Okay so we’ve done the kind of exciting stuff of kind of talking about setting up, or deciding to take the leap and go freelance. We talked where the work comes from. What about all the boring stuff? What was your experience of the admin of going freelance? Setting up all the kind of legal requirements. What did you do there? You kind of muddle your way through that yourself? Did you get any help? How did you approach it? What were the big problems?

    Elliot: A bit of muddling through. A bit of asking around. There’s still some things that I have yet to do. For instance I haven’t yet got a business bank account. Which I’m waiting till I get back to the UK. Mainly because I was setting this up at the time of moving, leaving the country. It was very very complicated. As I’m not getting paid immediately for some of the projects I am doing its fine to wait till July and set it all up then. You know what a nightmare UK banks can be anyway. So still waiting about that. One of the first things I did was get an accountant. I was quite nervous about this because one of the things that really dawned on me was how do you…First of all how do you find an accountant and then once you’ve found one how do you say "Ah they’re good.": You know, if you’re choosing a designer you can look at there work and it’s very easy to see what their like. What their styles like. What they’ve done. This kind of thing. With an accountant I think it’s really hard. You can only seem to go mainly on recommendations from friends and colleagues. Luckily I’ve had some dealings before with Nick who is Carsonified’s accountant and really nice guy and I figured well I’ll get a consult with him and if he fancies doing accounting for myself. I had a quick meeting with him. He was very friendly. I got to ask him all sorts of mundane tax questions which he answered for me. That was one of the first things I got sorted. So that was a big weight off my mind. To have someone who could look after all that stuff. Everybody has always said to me, in fact I think you may have said to me yourself, a good accountant will always pay for themselves and then some. In the time they save you. In the expertise. When the taxes come and all this kind of thing. So everybody recommended to me that I get an accountant from the first thigns and I guess that I would even in these early days say the same thing to anyone else thinking about that. In terms of paper work and stuff like that, one of the things I really really underestimated, although luckily I found out the truth in the first week, is how long it would take to manage my calendar. I just thought yeah I’ll book things and it will be fine. What I didn’t realize was that when projects need to shift round or you had to allocate couple of extra days for this. This had to move. The scheduling was actually, not a nightmare, but something you really have to make time for. The tricky thing is at the end of that you have nothing to show. There’s no realy paperwork to go with it. It’s an output as such. It’s easy to leave it off for, to neglect it. But obviously it’s something that needs to happen. In terms of paper work I made sure I designed myself a nice little invoice template so at least doing paper work isn’t as mundane as it has to be. Caus I got some nice little pretty pictures on my invoices. Doing that kind of stuff and obviously kind of chasing people to pay the money. Although actually so far everyone’s been very good. I haven’t got anything to complain about.

    Paul: It’s interesting isn’t it. That when you kind of sit down and think about going freelance and whatever else you do the calculations if I charged this per hour and you know I work 40 hours per week WOW I’m gonna be so rich. But very quickly you realize that well actually half of my time is probably taken up with non-paid work like managing your calendar, project management, invoicing. Dealing with the accountant and all of the that kind of stuff. It’s easy to forget that side of things. What about the business plan? Did you put any kind of business plan together or did you just go oh sod it I’m just going to do it?

    Elliot: I said oh sod it I’m gonna do it. For the kind of stuff that I’m doing I didn’t see the point in doing a business plan. Because I know exactly what I’m doing which is providing a design service to clients on a project by project basis. I don’t have any plans to grow the company as it were. This may change over time of course but at the moment I have not interest in turning it into an agency and employing other people. Obviously there are some financial benefits to doing that. A lot of people will tell you it’s the best thing to do and you gradually get less involved with the day to day stuff and are just running the company but to be honest at least w
    here I am now I wouldn’t be happy doing that. Because I actually love doing the day to day, the hands on design work and if I wasn’t doing that I wouldn’t be happy and that’s the reason I’m doing this anyway. So at the moment there’s no, it’s not like I’m a start up and I have a product and I need to predict sales and growth in that way. I think just being a designer we’ve got it a bit easier. So maybe I’m going about it the wrong way. Maybe I’m being unprofessional but this if fine for me.

    Paul: No I have to say I would agree. You know it’s not like you’ve got big costs going out. You don’t have offices that have to be paid for on a monthly basis. You don’t have staff that you have to worry about. And pensions for those staff. You know there’s no major complexity to it that kind of demands a business plan. I mean ultimately you just need to know that you are earning enough each month to pay your accountant and feed yourself.

    Elliot: That’s right yeah exactly. I think as long as you can go into freelance work and aim to earn at least as much as you were earning in your day job then I don’t think you’re going to run into too much trouble. As you say it’s probably safe to assume that half of your week you’re not actually going to be getting paid for because technically you wont be doing paid work like you say you’ll be doing the invoicing, chasing up things like this. So if you say you’re only working 2.5 days a week I think it’s a fairly safe bet to go on. If you can say that in those 2.5 days you’re going to earn at least as much as you were earning in a week when you were in fulltime employment then you’re not going to go too far wrong. Obviously a lot of what we aim to do and what is happening with me luckily at the moment is earning more than what I was earning in fulltime employment. So in that respect it’s yeah it’s good and I don’t think there too much to worry about there. As I said before luckily we as web designers have very very few overheads. Like you say if you’re renting an office that’s one thing and obviously there’s the accountant but actually accountants are very very reasonably priced anyway and I’m paying it all in a lump sum just to get it out there and get it done. Luckily there isn’t too much that we have to spend much money on.

    Paul: Okay last question and to wrap up with. How far in, sorry when did you set up again? I’m trying to think how long you’ve been doing this now?

    Elliot: Doing it fulltime has been since around the 20th of April.

    Paul: So it’s still very early days. You’re just over a month in. So so far pros and cons of being you’re own boss? What things have you liked? What things have you not liked?

    Elliot: The main pro and so far they’re living up to what I expected the pros and cons to be. Some of the main pros are the freedom of being you’re own boss. Obviously to an extent you’re clients are your bosses but just having the freedom to decide when you think this deadline should be. Doing the work when you like to where you would like to is a really great thing. When somebody comes to you to estimate a project being able to be generous enough with the hours to know that you can really spend a decent amount of time on the project. Not to a degree where you’re kind of taking the mickey as it were. But knowing that you can really give some really good time to a project instead of it being rushed. Also picking and choosing the clients. If you have got a fairly steady amount of work coming in and you can afford to say no to some things then that’s great cause it means that you can just work on a project that you personally find interesting. As I said before the financial benefits are working out well so far. That is a game when anyone goes freelance as well as freedom there is the monetary benefite as well. I can’t express enough this sense of freedom. Just having a chat with you this morning and then toodling off into town later this morning to go and do some work from a coffee shop and I’ll probably work a bit later this evening because we’ve had this chat this morning but you know having the freedom to do that and not having to worry about needing to stick to normal working hours and things like that. Not that employers aren’t flexible to these things but knowing that you’re the only person you have to please that does make a massive difference.

    Paul: So what about cons? Those were all pros.

    Elliot: They are aren’t they.

    Paul: You’re still in the honeymoon period aren’t you?

    Elliot: Yeah I agree. Give me a year and I’ll be all disheveled and angry. The only con I’ll say is that it can be a bit lonely sometimes. I mean I guess it’s hard to judge cause I’m in a foreign country where I only know a few people anyway. There way a while where I was working from my room here when the connection was a bit more reliable and that was great but I found I’m actually much happier being around more people now. Seeing more people during the day. I think I’m fairly well self disciplined like I said before cause I’ve had the experience of working from home before for quite a while but even so I found that I sometimes get a little bit distracted when I’m at home. You know go for a little wander. When you’re sitting down maybe in a coffee shop in public it’s more like this working environment, you can focus a bit more. I think even if you work from home most of the time maybe spend one day a week heading out and working in a public space just to see how it compares. I definitely find my concentration is a little bit better when I’m in somewhere like that.

    Paul: That’s really interesting because that’s something I’ve never tried doing. You know I work from home the vast majority of my week and I’ve never kind of gone and sat in a coffee shop. Mainly because I don’t drink coffee but also because, I don’t know its just never occured to me. I will go and try it today. There we go. We’ve got a little coffee shop around the corner I really like so I will go and sit in there and do some work for a while.

    Elliot: Of course as soon as you get there there will be really loud music and you won’t be able to concentrate.

    Paul: Probably. So Elliot you’ve definitely taught me something. I like that idea. What has that never occurred to me? Never even thought about doing that.

    Elliot: Of course I have only been doing it for a month so I could be completely and absolutely wrong.

    Paul: Yeah it could be a nightmare couldn’t it. But that’s why I wanted to get you on really. I wanted to get you on at the early outset of you doing this just to kind of give that unique perspective of somebody who’s just gone through the process. The stuff that you’ve covered has been great. I really apre
    ciate the time that you’ve taken to come on. We’ll get you back on again in the future when you’re a year down the line and see how you feel then.

    Elliot: Yes that would be a good test.

    Paul: It would be.

    Elliot: Something to aim towards perhaps?

    Paul: Yeah. So you’ve got to stay as a freelancer for at least a year otherwise it would be very inconvenient. Alright good to have you on the show Elliot and we will talk to you again soon.

    Thanks to Curtis McHale for transcribing this interview.

    Back to top

    Listeners feedback:

    Wayne Henderson from Southern California has sent in an audio file for this week’s show consisting of two separate but equally good questions.

    Hello Paul, Hello Marcus this is Wayne from Wayne Henderson voiceovers and as you can tell from my voice I’m obviously from Bristol, no wait actually Southern California and I have two question I would love to hear your comments and thoughts on. One, with the iPhone really taking off, gaining in popularity and other smart phones basically copying the iPhone, do you think it’s still even necessary to have the .mobi and designing for .mobi and my other question that I’d love to hear your thoughts on is kind of on the fringe of web design, I was wondering with WordPress being so popular, how do you feel about someone maybe being a WordPress design and installation expert? Taking the themes, customising them tweaking some things, changing some code and then kind of really helping other people to implement WordPress into their websites? Let me know what you think about that? Thanks guys.

    Let me address each in turn.

    The .mobi domain name

    There are two issues here which I would like to cover separately. First, let me look at this issue of whether we need to be designing for mobile devices at all. My answer is a categoric yes. No matter how great mobile browsers become, it is always going to be a different experience to surfing the web on a computer. Let me give you just three differences…

  • Size – Mobile devices have smaller screens than a PC. No matter how clever the mobile browser is a considerable amount of zooming and panning will be required to view a conventional website.
  • Controls – Not all mobile devices come with a QWERTY keyboard and none come with a traditional mouse. This can create problems on some sites, especially those with mouse over effects.
  • Context – Probably the biggest reason for creating a mobile version of a site is context. Mobile devices are not used sitting at a desk. They are normally used on the go. This affects the type of information being requested as well as the level of concentration being given to the task. When it comes to the mobile web context is king.
  • It is also worth mentioning that we are a long way from everybody having a smart phone. The majority of phones still provide a terrible web experience.

    It is harder to give a definitive answer about the .mobi domain. Unless your website is primarily mobile focused I think it is probably unnecessary. Most sites seem to use a sub domain rather than a seperate extension. For example twitter uses:

    http://m.twitter.com rather than http://twitter.mobi.

    I have even found myself guessing this format. I certainly never think of typing .mobi. Also on a purely financial note, you have to pay for .mobi while a sub domain is free.

    That said, I don’t have anything against .mobi. It is certainly a valid choice.

    Becoming a WordPress specialist

    Wayne’s second question was about becoming a WordPress specialist. It is good idea for a couple of reasons.

    First, as he point out, WordPress is hugely popular and there is certainly a market out there. It is also a well established product that has been around for a while and isn’t about to disappear. Having a clearly defined market is always a good strategy.

    Second, I am a great believer in specialising. With so many web designers out there you need to do something in order to stand out from the crowd. Specialising in WordPress is a good step in the right direction.

    However, I would argue that you could specialise further. You may choose to specialise in setting up WordPress for a particular sector or by using it in a particular way.

    Although this approach feels counter intuitive as you are narrowing the number of people who can hire you, it actually makes good business sense. By specialising you become the best in your limited field and so people are more likely to select you over your competitors.

    Back to top

    The plight of the in-house designer

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

    I last worked as an in-house designer/developer over 8 years ago, so I don’t feel I can really comment on the subject. I therefore enlisted the help of the boagworld forum and dug out various emails I have been sent over the last couple of years. I also picked the brains of Paul (our researcher) and Ryan (our producer) to compile 10 quick tips for improving the lot of in-house staff.

    1. Coding with others in mind

    The general consensus seems to be that as an in-house coder it is important to consider the next guy. Whether you are working as part of a team or as a lone developer, sooner or later somebody else will have to pick up your code and work with it.

    Two techniques were suggested for coding with others in mind. The first was to carefully comment all of the code your produce and if appropriate even create supporting documentation. The second was to have a library of reusable code so that all work produced is consistently marked up. That way it can be passed around the team easily.

    Personally, I believe this is good practice whether you are working in-house or not. Certainly Headscape use an extensive library of HTML, CSS and Javascript snippets.

    Of course, if you are working alone the need for a library of snippets is less pressing. However, our next problem is a bigger concern.

    2. Seeking out like minded people

    Many in-house designers/developers are working in isolation. There are a relatively few organisations that can afford a web team. Working alone has two obvious drawbacks. First, it is hard to keep up-to-date with new approaches because you are learning on your own. It is easy to get stuck in a rut, using the same old techniques. In web design stagnation can be dangerous both for your career and for the evolution of the site you are supporting.

    Second, it can be lonely. Even though you have other people with whom you work, they do not share your experiences as a web developer. You cannot moan about shared problems or ‘geek out’ on code or typography.

    The solution is something we have spoken a lot about before. Make contacts within the industry both online and off. Use tools like forums, twitter, and mailing lists. Offline, look for meetups and conferences you can attend. Nothing in your area? Don’t let that put you off. Setup something yourself. If somewhere as backwards as Dorset has a web designer meetup then there is no reason why your area cannot!

    3. A demonstration speaks a thousand words

    The feeling of isolation can be exasperated because management often simply fail to ‘get’ what you are trying to do. It can be amazingly frustrating when you have a great idea but you fail to make others see why it is so good.

    One solution might be to build a proof of concept or prototype. It is often much easier to convince management of an idea if they can see it in action. Some even spend their evenings producing prototypes as they are not given the opportunity while at work. Personally, I cannot help but wonder whether you should actually be looking for a new job if you are forced to develop ideas in the evenings!

    4. Impose some structure

    One idea I agree with is that in-house developer you should work within the same rigid structure used by external agencies. Too many in-house teams are treated like a free resource people can turn to whenever they like. This leads to scope creep and (more importantly) to the web team being undervalued.

    So what do I mean by a rigid structure? I am talking about things like:

    • Statements of work
    • Change control procedure
    • Client signoff
    • Project milestones (for both yourself and the client)
    • Resource assignment and budgeting

    These techniques ensure projects run smoothly, limit scope creep and project a professional image to the internal clients improving their perception of the development team.

    They are also worth applying no matter how small the job. For example if you have been asked to change some copy on the website always confirm what the requirement is via email. This acts as a mini statement of work. Project management doesn’t need to be onerous to be effective.

    5. Encourage internal charging

    Of course the best way of making somebody value your work is to charge them for it. There seems to be a general consensus that where possible internal charging is a good idea. However, often this is outside of your control.

    If you are unable to charge internal clients there are alternatives. One option is to calculate how much you cost the company per hour. Once you have this figure (even if it is an approximation) you can start to include it in statements of work. List all of the tasks to be done, associate a time with each of these tasks and include the cost to the company for each.

    Hopefully this will make internal clients think twice before using up your time. If you want further leverage start submitting a monthly report to management outlining what work you have been doing and the associated costs. Let clients know you are doing this as a further incentive for them to think twice.

    6. Be the authority

    Another piece of advice that was generally agreed upon is the need to be seen internally as an expert. How you are perceived is important if you want your opinion to be respected.

    Avoid being hesitant or negative about ideas because you are unsure how to implement them. Instead research solutions and if appropriate bring in an expert. Using specialists does not undermine your authority. Rather it demonstrates that you can manage a project even if it is bigger than your personal capabilities.

    7. Exude confidence, personality and enthusiasm

    On the subject of negativity, avoid saying ‘no’. Many internal web teams are perceived as a barrier to be overcome. Internal clients often turn to external agencies in an attempt to bypass them entirely. Once you are ‘out of the loop’ you loose control entirely.

    A better tactic than saying ‘no’ is to say ‘yes’ but go on to explain the consequences. Once you have explained the negative impact of a suggestion, be quick to provide a positive alternative of your own.

    Be confident and enthusiastic about every project. Avoiding being perceived as the stereotypical geek sitting in the dark barely uttering a word. Ensure you are likeable. If people like you they will listen to and respect your opinion.

    8. Broadcast your successes

    To further enhance your reputation internally make sure you broadcast your successes. If you launch a new sub-site or feature, ensure you tell as many people internally as possible.

    If the company has an internal newsletter or mailing list make sure you write something for it explaining what you have done and why in plain English. Focus on what the project brings to the business rather than how it works and why it was challenging.

    Offer to run workshops about the web or give a mini-presentation on web strategy to management. Anything to make you appear pro active and a benefit to the business.

    9. Understand the politics

    A lot of the points so far relate to company politics. Every organisation has its internal politics and ‘rising above them’ isn’t a realistic option.

    One area where politics becomes particularly important is sign off. If you are having trouble getting something approved ask yourself the following questions…

    • Does my internal client have the power to sign off themselves or is there somebody else I should be talking to?
    • Who are the people influencing those signing off?
    • Who are the opinionated trouble makers slowing down the process?

    In many cases the person who appears to be the decision maker is not really. They are being controlled by management higher up or influenced by a few vocal individuals. If this is the case you need to speak directly to these people or at the very least give your client the tools to force sign off through.

    10. Stick to the facts

    Finally, always have facts to back up your opinion. This is especially important if people within the organisation do not respect your opinion.

    Facts and figures are especially good but when that is not an option turn to an expert opinion. Quoting an internationally respected author like Steve Krug will generally carry more weight than your own opinion.

    That said, remember to explain who this person is and why their opinion matters. You cannot expect the heading of marketing to have a clue who Steve Krug is.

    Where an internal client remains unconvinced by an experts opinion turn instead to the weight of evidence. Don’t quote just one expert, quote ten. The shear number of people saying the same thing will impress.

    So there you have it. Advice straight from the boagworld community. If you have anything to add, post it in the comments below.

    122. Screencasting

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

    Play

    Download this show.

    Launch our podcast player

    Watch the behind the scenes video

    News and events

    Typography everywhere

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

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

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

    The list could go on.

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

    Accessibility cheat sheet

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

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

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

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

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

    Advice on wireframes

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

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

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

    Top five tips for new web designers

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

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

    The tips include…

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

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

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

    Back to top

    Feature: Creating Screencasts

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

    Back to top

    Interview: Ian Lloyd on Sitepoint HTML Reference

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

    Ian: Hello Paul!

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

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

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

    Ian: I’ve heard my dulcet tones before.

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

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

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

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

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

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

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

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

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

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

    Paul: *Laughs knowingly*

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

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

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

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

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

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

    Ian: Sorry Paul.

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

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

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

    Ian: Ah yes.

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

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

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

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

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

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

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

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

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

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

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

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

    Paul: Nobody is beyond hope.

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

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

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

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

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

    Paul: There you go then.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Ian: What luck “HTML SUCKS!”?

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

    Ian: Yeah something like that.

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

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

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

    Ian: OK. Thank you very much Paul.

    Thanks to Lee Theobald for transcribing this interview.

    Back to top

    Listeners feedback:

    Can you trust developers?

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

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

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

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

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

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

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

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

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

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

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

    The life cycle of a website

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

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

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

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

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

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

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

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

    Back to top

    Building for the future

    Does building with web standards really provide a firm foundation for the future or will websites be forever stuck in a cycle of sporadic redesign?

    This year at @Media I moderated a panel on communicating best practice. My fellow panellists were exceptional and nobody could dispute the excellent advice they gave. I on the other hand managed (as always) to court some controversy with my off hand remarks.

    At one point in the presentation I endeavoured to argue that one advantage of applying best practices today (such as separating content from design) was that it broke the cycle of continual redesign.

    A major grievances of management is that every few years the old website is thrown out and a new one is built. They are horrified by this for a number of reasons:

    • It means a massive outlay of cash every few years.
    • It involves completely writing off previous investment.
    • The site rapidly becomes out of date but they cannot justify another big rebuild.

    I argued that a standards based website moves away from this model towards an evolutionary, rather than revolutionary, approach.

    Stuart Langridge who was also speaking at the conference, challenged this line of reasoning suggesting that over the next 5-10 years the web would change beyond recognition and that the speed of change would ensure the redesign cycle continued. He even suggested that we would all be building our sites in Silverlight by then. Fortunately he was only joking and this wasn’t some kind of prophetic vision.

    Although I certainly understand Stuart’s position I have to say I think he is over estimating the speed of change. When looking at the future we all have a tendency to over estimate the speed of progress (I am still waiting for my hover board and cyborg eyes) and I believe Stuart is doing exactly that.

    The web will certainly be a different place in 10 years, but it will not be so different as to undermine the benefits of standards in planning for the future. For example separating content from design is going to allow for a gradual transition of content from HTML to XML or whatever follows. It will also allow for easy design changes to keep in line with best practice or the latest design trends.

    Am I saying that if your site is built with the standards now that you will have the same site in ten years? Well yes and no. Probably the entire site will have been replaced bit by bit. However, I don’t anticipate having to dump everything and start again every few years.

    It reminds me of a scene with Trigger in Only Fools and Horses. Trigger was boasting to Del Boy and Rodney about his road sweeping broom. He proudly announced that he had had the same broom for over 20 years. The other two looked at his mint condition broom and appeared dubious. Trigger went on to say that he had cared for the broom lovingly, replacing the handle 14 times and the head 17 times.

    Was it the same broom as he started with? Of course not. The handle and head had both been replaced. However, he had never had to throw out the whole broom and buy a new one. That is what it should be like with our websites. We should replace and upgrade parts of it on a regular basis rather than start again every few years. Standards and best practice make that possible.

    113. Hiring

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

    Play

    Download this show.

    Launch our podcast player

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

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

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

    News and events

    Highly extensible CSS

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

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

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

    Video tools

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

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

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

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

    Microformat boost

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

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

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

    Back to top

    Feature: Hiring new staff

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

    Back to top

    Expert interview: Christian Heilmann on common Javascript mistakes

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

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

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

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

    Paul: Um hum…

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

    Paul: Yeah…

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

    Paul: Um hum…

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

    Paul: Yeah.

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

    Paul: Umm…

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

    Paul: Yeah.

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

    Paul: Mmm…

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

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

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

    Paul: Um hum…

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

    Paul: Yeah.

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

    Paul: Mmm hmm…

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

    Paul: Mmm…

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

    Paul: Mmm…

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

    Paul: Mmm…

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

    Paul: Mmm…

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

    Paul: Mmm…

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

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

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

    Paul: (Laughs)

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

    Paul: Mmm.

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

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

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

    Paul: Mmm…

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

    Paul: (Laughs)

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

    Paul: Mmm.

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

    Paul: Okay.

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

    Paul: Oh okay.

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

    Paul: Mmm.

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

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

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

    Paul: Mmm…

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

    Paul: Mmm.

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

    Paul: Yeah.

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

    Paul: (Laughs)

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

    Paul: Um huh.

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

    Paul: Yeah.

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

    Paul: (Laughs)

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

    Paul: Yeah.

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

    Paul: Mmm.

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

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

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

    Paul: Mmm.

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

    Paul: Mmm.

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

    Paul: Right.

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

    Paul: Mmm.

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

    Paul: Yeah.

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

    Paul: Mmm hum.

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

    Paul: Yeah.

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

    Paul: Umm hmm.

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

    Paul: Mmm.

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

    Paul: (Laughs) …or drinking…

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

    Paul: Mmm.

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

    Paul: Mmm.

    Christian: Otherwise you start preaching to the choir.

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

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

    Paul: Okay.

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

    Paul: What do you mean by that?

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

    Paul: Okay yeah.

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

    Paul: Yeah.

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

    Paul: Mmm hum.

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

    Paul: (Laughs)

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

    Paul: (Laughs)

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

    Paul: Yeah.

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

    Paul: (Laughs)

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

    Paul: Yeah.

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

    Paul: Yeah.

    Christian: And that’s never the case.

    Paul: Hmmm.

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

    Paul: Mmm hmm.

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

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

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

    Paul: Mmm.

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

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

    Christian: Yeah.

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

    Christian: See you soon. Bye.

    Back to top

    Listeners email:

    Rolling out new features

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

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

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

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

    Here’s the solution I had planned:

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

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

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

    Content management and CSS

    Our second listener contribution is a question from Adrian…

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

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

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

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

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

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

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

    112. Jina

    On show 112: How to be more efficient using HTML snippets, Jina Bolton on women in web design and moving to a mac.

    Play

    Download this show.

    Launch our podcast player

    News and events | Using HTML snippets | Jina Bolton on women in web design | Listener emails

    News and events

    Some customers are not worth caring about

    My first piece of news is a post by Gerry McGovern. In his latest post he argues that some customer are not worth caring about.

    The thrust of the article is that by appealing to everybody, you ultimately appeal to nobody. This is something I see repeatedly from clients who define their target audience as “the general public” or “men under 50.”

    You also see it among developers who become overly concerned that people using IE4 with Javascript disabled might be unable to access the site. Even content providers suffer from this problem, dumping content on their websites “just in case somebody finds it useful.”

    Ultimately building a website has to generate a return on investment and some customers don’t generate that return.

    Version targeting rumbles on

    Next up is two new articles on A List Apart, which once again tackle version targeting. Jeremy Keith argues against it, while Jeffrey Zeldman defends the position.

    I have tried to stay fairly objective in my coverage of this issue. However, although I understand the position of people like Jeremy, I believe that Microsoft have done a good thing.

    The arguments against strike me as somewhat naive and arrogant. We live in a world of compromise and yet as compromises go this isn’t a bad one. By adding a single line of code we have the ability to control how the market leader renders our sites. As Zeldman says…

    Designers and developers should be popping corks, hugging each other, and weeping with joy. IE no longer sucks. No version of IE will ever again surprise us with unexpected displays or behavior.

    Perhaps I am overly pragmatic, caring more about real world scenarios than purity of solution, but I am hopeful about the future.

    Let users tagging your posts with delicious

    The last news story is two posts from Christian Heilmann. The first is a Javascript technique that returns any delicious tags associated with the current page. This is a great way of introducing tagging to your site, without having to tag all of your own articles. The downside is that when users click on a tag, they are not taken to other articles you have written. Instead they see all delicious links associated with that tag. Good for the user, maybe not so good for retaining users.

    The second post by Christian is another Javascript solution. This time he provides a mechanism for walking a user through the key features on your site. It generates an animated series of popup caption boxes beside different screen elements. It is definitely useful for showing off key features to new users. However, I have to wonder if a good screencast wouldn’t do the job better. Nevertheless, it is an interesting proof of concept. Check it out.

    Back to top

    Feature: Using HTML snippets

    If you are part of a web design team or skip constantly between projects, then you might want to consider an alternative approach to writing your HTML. Discover how we became more efficient at Headscape by using HTML snippets.

    Back to top

    Expert interview: Jina Bolton on women in web design

    Paul: Okay. So joining myself and Marcus today is Jina Bolton. How are you, Jina? Good to have you on the show.

    Jina: I am doing well. How are you?

    Paul: Yeah. Well, other than the weather that we just keep complaining about, things arenít too bad here. We are bearing up under the strain. So, for those of you that havenít come across Jina before, she is now an internationally renowned speaker

    Jina: [laughs]

    Paul: and author and incredible web designer. And is the kind of quality of person that is selected to appear at South by Southwest (SXSW) Marcus just for your interest that she is the kind of person they are looking for not you.

    Marcus: You know, I know that because I got a magazine thing through by South by Southwest and there she was on the cover of it.

    Paul: Ummm!

    Jina: [laughs] Yeah. I got into a little for that too.

    Paul: Why did you get into trouble for that? Who with?

    Jina: The company I work or. Iím not really a speaker on behalf of that company, so

    Paul: Ahhh, I see.

    Jina: and they printed that company name by my name.

    Paul: Right.

    Jina: Anyway, different subject. [laughs]

    Paul: Okay!

    Marcus: [laughs]

    Paul: And the company you work for will remain nameless and notorious for their strictness over things like that, so

    Jina: Yeah.

    Paul: There we go. But, basically yes Marcus. They want young attractive, intelligent and clever designer rather than an aging pop-star. Sorry about that.

    Jina: [laughs]

    Marcus: [laughs] I can live with it.

    Paul: Yeah. Jina has been kind enough to let me come on her panel, so that should be fun shouldnít it? Iím looking forward to that.

    Jina: Yeah, I think it will be great.

    Paul: If we actually get our act together and organize it.

    Marcus: But, Jina is obviously that much richer after you have paid her Paul.

    Paul: Well yes. You know I did have to bribe my way on. But, it seemed to work, so that is good.

    Paul: So, there are so many things we could have gotten Jina on the show to discuss. She seems to be talking a lot about CSS lately. Mainly just by putting the word sex in the title of everything she does, which seems to improve your ratings to no end.

    Jina: [laughs] You found my tactic.

    Paul: Yeah. It seems to work for you Jina, so thatís good. But we wanted to go for a little bit of an unusual subject. I wanted to really look at the role of women within web design because well letís face it, your kind of a rare breed in some senses Jina. There arenít as many women in web design as perhaps there should be. And I just thought that it might be an interesting subject. And Iím sure that you have some opinions on it and so maybe we can encourage I know that there are a lot of women that listen to our show that maybe havenít moved full-time into the world of web design and maybe youíve got some advice to offer. So thatís the kind of plans. Does that sound okay with you?

    Jina: Sure.

    Paul: Good. Okay, well letís kick off then just by asking a really kind of obvious question, but kick us off with this Do you believe that women provide something unique to the world of web design, and if so what is that? Is there actually a difference? Is there something that makes womenís role unique?

    Jina: Ummm. Well I think that there is something unique being brought to the table, that personís own personal style because I think that men and women have the same skill set. Now of course there are a lot of women that have a feminine style, so they do bring that into play, but I think it is more style than it is the natural skill of designing itself.

    Paul: Okay. So, do you believe that there are kind of genetic differences really? ëTheyí make all kinds of things for example that woman have better color perception than men, but men have probably got better 3D acuity and things like that. Do you think that that actually makes a difference? Or is that all so marginal, that itís not that big deal?

    Jina: Well I havenít really thought about that to be honest. As for color, I donít know. I guess, you know, a woman sense of color perception is supposed to be more acute. Maybe they could bring better colors to the table, but I think the skill sets are pretty much the same. I guess, you know, a lot of men can design for men and men can design for women. I think the skill sets are the same.

    Paul: Oh, okay. So you wouldnít believe say, for example, if there was a website that was primarily aimed at a female market that it should be a female designer that works on a site like that?

    Jina: Ah, well. So I do think that a female designer would have an easier time knowing how to cater to a female audience because they are that audience. But I donít think that it would make the website design better. I think a man would be just as capable in creating for that female audience.

    Paul: Ah, that is interesting. Marcus, what do you think about that? I kind of always naturally presumed that somebody is more capable of designing for their own gender.

    Marcus: Iím surprised by Jinaís answer to be honest. But, thinking about it, it is something that you think ëYeah, it makes more sense for women to design for women.í but really itíd to do more with the content. I think it would be hard for a man to produce content for a site aimed at women. But maybe the design is something, like Jina says, is more the designers have a set bunch of skills and whether you are a man or a woman it really doesnít make any difference. So it is more of a content issue.

    Jina: I do agree that it would be easier for a woman to do it, because like I said she is that audience so sheís gonna know what kind of things a woman would like. But, I donít think that would make the website design any better because a man would be able to do just the same.

    Paul: Hmmm.

    Jina: You know it is kind-of sort-of like to ëbring issues into ití. Like, I had a firm that was from India who was asked to design for the National Civil Rights Museum and his isnít African-American, nor was he even American, but he did a fantastic job. So, I think for gender it would kind of the same. Like, if he was African-American he probably would have had an easier time but he would still have been creative with the artistic part.

    Paul: So basically, he had to work harder to achieve the good design, but he could still do it.

    Jina: Right.

    Paul: Hmmm. Yeah. I do see where you are coming from on that. You mentioned earlier about a kind of feminine style to design. Do you think there are differences in style? What would you class as being a particularly feminine style of design?

    Jina: I think it is really color choices and font choices, as well as certain patterns like some designers I think of at the top-of my head *Vera-Ley* and *Legha Alfanterra* they both you know if you look at there websites they are very very feminine. You know my website is really feminine looking, but I think it is because of the colors theyíve chosen and the font choice weíve picked and as well as the patterns. I notice a lot of guys tend to go for the grungier things and the girls kind-of go for more of a clean look. But I think those are stylistic differences.

    Paul: So when do you think that kind of where do you think that comes from? You know is that something that is trained into us? You know, blokes tend to go for grungiest stuff? Even from being a kid I guess ëboys are blueí and ëgirls are pinkí, you know, all that kind of thing.

    Jina: [laughs]

    Paul: But, how much of it is nature and how much of it is nurture do you think?

    Jina: Ewe I have no idea. [laughs]

    Paul: [laughs]

    Marcus: [laughs]

    Jina: But, I do think it comes from the way people are brought up like you said ëgirls are pinkí and ëboys are blueí. I think it is really what that person has come to like as they have grown up.

    Paul: Hmmm.

    Jina: To be honest, Iím not a real fan of pink at all

    Paul: [laughs] Good for you.

    Jina: but I use it in my website for some reason. [laughs]

    Paul: [laughs] I mean yes. You see the trouble that you are making Jina, is that we are trying to make informed comments on this show and nothing that we ever say on this show is informed.

    Jina: I think, this topic is kind of just subjective I guess.

    Paul: Yeah. Basically you are saying that I picked a dumb subject. That is what you are saying isnít it?

    Jina: No, no.

    Paul: [laughs]

    Jina: A good topic to talk about it, but it is kind of confusing.

    Paul: Yeah.

    Jina: You know and when I started out doing websites, I used to do websites for rock bands. And all of those sites I did were grungy so I am kind-of contradicting myself.

    Paul: Ahhh. So I mean, I guess the big question is that whether you know obviously the industry that you have chosen is a male dominated industry. There are far more men out there. Certainly there are far more high profile men out there on the speaking circuits and writing articles and all of the rest of it. I mean do you perceive that as a problem?

    Jina: I am not really sure if ëproblemí is the word. I do think it is getting better. I see a lot more women speaking now and even attending conferences. I see more and more women in attendance. And of course, more women writing articles in books, but I think it may have to do with that it is a fairly new field, in comparison to other design related fields. And so now that it is getting taught in schools, more and more women will start getting into it.

    Paul: Hmmm. I mean that raises quite an interesting question. You know, how did you get into it then? From you know, what is your background and how did you end up being a web designer?

    Jina: Well actually, my Dad was playing around with making his own personal website and I was intrigued by the idea of publishing to the Internet. So he kind of showed me really-really basic-basic HTML using font tags and tables.

    Paul: Yeah.

    Jina: I grew up as an artist so I went to art school and I was actually going to be a print designer, but as I was learning HTML it became my hobby and it just kind of merged and became my job.

    Paul: Hugh. Okay, fair enough. It is just interesting to know. Okay, so do you think we should be you know you talked about that there are female designers learning at school these days on how to become web designers. Do you think we should be doing active as a community to encourage women to come into the profession? I mean, I know for an example, that there was a lot of talk at one stage about proactively discriminating in conferences to encourage there to be more women speakers. Publications need to make a point of using female authors in order to you know setup role models almost artificially. Is that something you would encourage or do you think that is a slippery slope?

    Jina: I have mixed feelings on that. As a woman, I have definitely benefited from people that were looking for more female speakers or more female authors so it has definitely helped me. But, I think discrimination is sort of a fine line and if a guy is more capable and more skilled he really should have more of that opportunity than a woman who is not as skilled. I wouldnít want her to get in, just because she is a woman. But, the fact that there are more opportunities is helpful so I am kind-of on the fence on that one. It is sort of like the same way I feel, and I know this might be considered controversial, but the whole you know like when you get a job. Are you getting hired in my case, if I get hired because I am a woman and I am half Asian versus somebody who maybe is a White male, but who are a lot more skilled than me. I donít know how I feel about that. You know, I am all for more opportunity, I think that is a really good thing. But I think that any discrimination is discrimination.

    Paul: I mean it is an interesting one, as somebodyís employer, and I donít know Marcus will feel about this but there are occasions when I really think we miss out as a company. I am sorry to say, we are an all male company, all thirteen of us. And not because we have gone out to be that, in fact precisely the opposite. Weíve often offered woman jobs and they have turned us down actually.

    Jina: [laughs]

    Paul: And it is a very sad reflection on us. But, I mean Marcus how would you feel about actively going out and saying ëRight, okay, we want to hire a female designer because we want that female perspective.í?

    Marcus: I am not too sure how I feel about that, from an employment point of view. As an employer, I think you have to look at who is the best candidate. But what I was thinking about when we were talking about earlier, and this goes back to what I am not talking at South by Southwest (SXSW) this year

    Paul: [laughs]

    Jina: [laughs]

    Marcus: and one of the reasons of why I am not doing that.

    Paul: Itís because youíre White, middle-aged and middle-class.

    Marcus: No, but one of the things the people who are organizing the panel have to look at different they have to think about ëOkay we are going to have a bunch of panels talking about business, a bunch of panels talking about designí you canít have everything. All the panels cannot just talk about business, for example. So you have to think, okay we will have to split it equally between the different types of genre, if you like. Now, doing that we also want to have an equal split between men and women, I donít think there is anything wrong with that. As an employer it is a different thing. I am not sure, where the law stands on that.

    Paul: Ummm!

    Marcus: Iím not sure we actually would be able to say we have to have a female employee, or whatever. I think you would be discriminating against other people by doing that.

    Paul: Yeah, I guess you are. But, I think we are actually (I have to be honest) I think we suffer as a business to some degree. A classic example of that was not long ago we worked on a website for a higher education institution where over 75% of the people that went there were women. And we were having to do a design. We did the first design and we put it in front of bearing in mind all of our designers are men and we put in front of some test users and the overwhelming response back was ëYouíre trying too hard. You know it is kind of overly feminine.í And it would have been so much easier in that situation if we had a female designer there just to say ëGuys. You really donít need to make it pink and you donít need the little fairies in the corner.í

    Marcus: [laughs]

    Jina: [laughs] Exactly, you donít want to go with crochets with pink and flowers unless that is the brand you are going for.

    Paul: Yeah, I mean that is a good question actually. Do you think there is any bear in mind there is a lot of male designers out there that are listening to this show what are the absolute no-noís? How can they design for a feminine audience without kind of really going over the top? You know, is there any kind of advice you can give, or is it just kind of feel as you go along?

    Jina: I think you definitely want to get critiques from women, like if you have peers letís say you are working at a design agency and there are female designers around you, get their opinions. If you donít really have that, I donít know, I guess go to Starbuckís or something

    Paul: [laughs]

    Jina: and get some critiques because I am just up more for just keeping it simple and clean.

    Paul: Yep. That sounds like good advice. I think we are going to have to wrap it up there Jina. Not because I am bored with talking to you, but because the sound quality on Skype sucks so much today. I think weíre gonna have to get you back on the show another time to share maybe some more stuff.

    Jina: Okay.

    Paul: I donít know, maybe when you are over in the UK that might be possible. Iím sure that it will happen before too long.

    Jina: That sounds good.

    Paul: Okay.

    Jina: And it might even be our Internet connection. I am sorry about that.

    Paul: Thatís alright, these things happen. I blame Marcus personally. I never have problems except for when he is on.

    Jina: [laughs]

    Marcus: Ha ha ha.

    Jina: Thatís awful.

    Paul: [laughs] Okay. Thanks very much for your time and we will talk to you again soon.

    Jina: Okay. Alright.

    Paul: Bye.

    Back to top

    Listeners email:

    SXSW

    This week we have a couple of questions about SXSW:

    Rich asks…

    I am attending sxsw for the first time this year. What should I expect and how can I get the most out of it?

    Last year was my first year at SXSW and to be honest it is overwhelming. Before I went I planned out all of the panels I was going to attend but to be honest I wasted my time. I don’t think it is really possible to prepare for a 10 track conference. Ultimately what you go and see will be dictated by how much energy you have left after the various parties you were attending the night before!

    Talking of parties, in my in my opinion it is the social aspects of SXSW that is really the most interesting. At the end of the day, you can find out about most of the topics covered online. However, it is meeting and chatting with other web designers that is the really inspiring bit. To this end I would suggest two ideas.

    First, take time to just sit in the corridors and get chatting with people. If you are in a good conversation, don’t worry too much that you are missing the panels. Its amazing who you meet just sitting around. Oh yes, and don’t be afraid to introduce yourself to anybody. Most people are friendly and if they are not… screw them!

    Second, if there are people you know already attending or if there are people you want to meet add them on Twitter. That way you can see where they are and what they are up to. As a newbie last year, twitter was how I found out where all the best parties were. Definitely add me as I intend to keep twitter up to date with my comings and goings.

    Talking of parties and socialising Matthew asks…

    Have you considered doing a live show at SXSW?

    We have considered it but have decided against it. To be honest, sxsw is manic enough without adding a live show. What is more, I don’t think live shows are that interesting to those that are not attending. This means we will not be releasing a show on the 12th March. However, we will be recording as many interviews as we can cram in, which we will be using over the coming weeks and months.

    Although we are not doing a live show, that doesn’t mean we wont have opportunity to meet up. Boagworld is once again sponsoring the Great British Booze up, which is happening on Monday 10th March from 7:30pm at Shakespeare’s Pub (314 E. 6th Street). Full details at http://upcoming.yahoo.com/event/403331/

    Moving to the mac

    Brenda asks…

    You mentioned on the Christmas list that you recently converted from Windows to Mac. How did it go? Did you have to buy all new software, or were you able to convert licenses for some of it? What was the learning curve like? What do you miss most from Windows? What would you say the overall budget for this was (emptying out that duct tape wallet)?

    A very timely question Brenda. With Marcus intending to buy a mac, we have been discussing the switch. I have to say that for me it went very well. Within a week I was entirely happy working on my new macbook and could do everything I did under windows and more. I have certainly never looked back and can honestly say I miss nothing.

    However, I confess I was in a luxurious position. Unlike most people I had Headscape to pay for the raft of software I had to purchase. Admittedly companies such as Adobe allowed me to transfer my license from windows to the mac (after jumping through some hoops). However, that was not always the case. Fortunately most of the software I purchased was only $30-40 each. However, that can quickly mount up. The biggest waste was on Microsoft Office. To begin with I couldn’t imagine life without Outlook and Word. In hindsight, I really didn’t need it. iWorks which costs a fraction of Office does everything I need and Apple Mail is a much more pleasurable experience than Outlook. I didn’t keep track of how much I spent on software, however I would guess it was $200-300.

    Overall it was a great move and I love not only the mac OS but the great software being developed by some very cool mac developers.

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