Becoming number one on Google

‘Become number one on Google’ – The dream of every website owner and titles like that grab people’s attention. What can you do to help achieve that dream without resorting to black hat techniques?

We have spoken before about the dangers of using black hat techniques to improve your sites ranking. But, what legitimate techniques can you use?

There is a lot you and your team can do to improve your placement on search engines. These fall into three broad categories:

  • Improving your site’s build
  • Improving your site’s content
  • Encourage quality links

Improving your site’s build

I have written before about how accessibility can also improve search engine placement. By avoiding content types that search engines find hard to access (like Adobe Flash), marking up content semantically and using appropriate ALT and title attributes, we make our sites easier to index. However, although these techniques ensure content is indexable, it does not mean search engines will discover that content in the first place.

The following will ensure Google (or other search engines) discover your content.

  • Create a clear hierarchy – Every page should be reachable from at least one other page of your site.
  • Use text links – Links between pages should be textual rather than use images, Flash or other unaccessible technologies.
  • Use short URLs – Some web addresses created by dynamically driven websites (such as those built using content management systems) cause problems for search engines. Shorter web addresses with less parameters (characters after the ? in the address), the more likely to be found.
  • Add a site map – Add a site map that includes links to the important content. However, try not to exceed 100 links on a page as this can cause problems.
  • Submit your site – A search engine will find your site through those who link to you. However, speed up the process by submitting your site for indexing. You can submit a site to Google here. You can also submit a site map using Googles Webmasters tools. This helps Google learn the structure of your site and increases the number of pages indexed.
  • Once search engines can access your website, you need to address the content.

    Improving your site’s content

    The most important consideration when writing copy for search engines is the inclusion of search terms. Before writing a page have a clear idea of what it is about and what search terms might use when searching for that subject. Next, incorporate them naturally into copy, headings, image alt attributes and the page title.

    Be careful not to use too many search terms. Two or three per page is adequate. If you use more, copy may become hard to read and the ranking of each individual term will be reduced.

    Do not stuff a page with search terms as you may be penalized. They should be incorporated naturally into your copy. Try reading your copy out loud. If it sounds like you are forcing the use of keywords it will require some rewriting.

    Ultimately all you need to do is write good copy. If it is well written and engaging it will also attract links.

    Encourage quality links

    If you already run a website, you will have probably received an email from somebody wanting to ‘exchange links’. The email may have explained that Google ranks pages by the number of incoming links.

    There is some truth in this claim. Google does partially rank pages based on the number of sites who link to you. However, this is not the whole story.

    In reality nobody but Google knows how they rank sites. Links are a factor but it is not just the quantity that matter. Google states that:

    The quantity, quality, and relevance of links count towards your rating.

    Google looks at a number of factors:

    • The subject matter of the site linking,
    • The copy that appears in the link,
    • The popularity of the site linking,
    • The reputation of the site linking.

    It is rarely worthwhile responding to link requests, unless they come from a high profile website with appropriate content.

    It is however worth seeking links from relevant sites. Which sites would you like to appear on irrespective of the benefits to your ranking? Which sites do your target audience frequent? Getting featured on such sites provide benefits of their own, independent of the benefit to ranking.

    Will the above techniques get you to number one on Google? Possibly. It will certainly do your site no harm unlike many of the other techniques out there.

    This was another lovely little extract from my book – the website owners manual.

    Effective browser support

    Browser support should focus on usability and accessibility rather than pixel perfect design. Sites should render in all browsers, but provide advanced features and aesthetics to those which can support it.

    Most web design contracts address browser support. Many agencies still treat support as a black or white decision – a browser is either supported or it is not. If the browser is not supported the site is often unusable. However, this approach fails to acknowledge the diverse and evolving nature of the web. We should be supporting all browsers.

    What does ‘support’ mean?

    Although we support all browsers, that does not mean every user will have the same experience. For example, it is unrealistic to expect a user accessing the web through a text only browser to have the same experience as somebody using the latest version of Firefox.

    As Yahoo states in their own browser support documentation:

    Requiring the same experience for all users creates a barrier to participation. Availability and accessibility of content should be our key priority.

    Supporting a browser should provide the best experience possible within the constraints of that browser, and should exclude none.

    Expecting pixel perfect accuracy across browsers is unrealistic and not cost effective.

    The problem with pixel perfect design

    With browser technology improving all of the time it is unsurprising that modern websites do not always render the same in older browsers such as Internet Explorer 6 (released 2001) as they do in more contemporary counterparts. In fact even modern browsers differ in the way they display HTML.

    Many web designers go to extreme lengths to ensure consistency across their ‘supported browsers’. However although this is achievable if the number of supported browsers is limited, it comes at a cost. This includes:

    • Significant overhead in the time required to overcome limitations in older browsers.
    • Increased likelihood that unsupported browsers cannot access the site. This is because of hacks and excessive code employed to ensure consistency.
    • A tendency to design for the lowest common denominator.

    A better approach is to ensure that the site works well and looks reasonable on the lowest common denominator browser, and then ‘enhance it’ for more capable browsers.

    For example, modern browsers support design enhancements such as:

    • rounded corners
    • drop shadows
    • Improved typography

    and various other styling not supported by older browsers without additional code and effort. However as Andy Clarke explains – because these design elements are not intrinsic to the usability or functionality of the site they can be safely dropped.

    If this approach is adopted, it is less likely browsers will render sites incorrectly and so the level of testing can be reduced.

    Testing

    When a black and white approach to browser support is employed, testing can become expensive and time consuming. While website owners want to support as many browsers as possible, web designers want to limit the number supported to make testing manageable.

    However, if a modern approach is adopted the burden of testing is reduced. This is because instead of testing focusing on pixel perfect precision across all browsers, the focus is on usability and accessibility.

    Obviously, when claiming support for all browsers it becomes impossible to test in every browser combination. Instead it is necessary to prioritize browsers based on website statistics and ensure accessibility by testing in these.

    The number of browsers and versions that a site is tested on will vary depending on the budget available for testing. However, even testing on a handful of browsers will normally cover the majority of users experiences (as a relatively low number of browsers dominate the market). In addition, those browsers that are not tested should reliably render the page because no unnecessary code or hacks are used to build the site.

    Conclusion

    In conclusion, building websites that are enhanced for more capable browsers – improves accessibility, reduce costs and ensure every user gets the best experience possible within the limitation of their choice of browser.

    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

     

    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

    Improving your site with user feedback

    Users can be invaluable when deciding how to move a website forward. We should always listen to what they say. However, sometimes that is easier said than done.

    Whether you are a website owner or a web designer, listen to your users. Whether you are running a web application like GetSignOff or developing content driven websites, listen to your users.

    We all know that user feedback can be invaluable for improving our sites. However, knowing something and putting it into practice are different things.

    There are two problems with listening to users:

    • How to listen to them in the first place
    • How to decide what is valuable feedback and what is not

    We will never pay more than lip service to the idea of users shaping our sites unless we overcome these obstacles.

    Collecting user feedback

    Everybody thinks they know their audience. However, in reality they probably do not. When was the last time you actually asked a user his opinion? You may think you know what they want but you can’t be sure unless you ask.

    Fortunately there are a number of ways to collect feedback from users:

    Face to face

    From focus groups to usability sessions, meeting users in the flesh provides unparalleled feedback. Meeting users allow a level of interaction unavailable through other methods because they allow two way real-time interaction.

    This creates a better empathy and connection with users. You can get inside their heads by watching their mannerisms, listening to their tone of voice and even observing the way they dress. All of these subtle elements help construct a picture of the type of person they are.

    Admittedly face to face meetings can be difficult to arrange. However I would encourage you to settle for nothing less. You may not do it extensively, but make sure you do it at least once.

    Web stats and search queries

    In my post ‘use web stats for more‘ I explored what could be learnt from analysing web logs and search queries. I explained that web stats could be used to find and resolve problems with usability, accessibility and content. I also looked at how monitoring search queries reveal what users really want from your site and the mental model they use to find your content.

    In short, web stats are an invaluable source for identifying trends in behaviour and expectations.

    Questionnaires and surveys

    Probably the most traditional and most favoured form of collecting user feedback is the ‘survey/questionairre’. One reason they are favoured is because they identify broad trends in much the same way as web stats.

    Personally I am not a fan of this approach, especially when used in isolation. Tracking broad trends through statistical analysis does not encourage empathy with users. As is pointed out in the book Subject to change, empathy is an important aspect of successful web development. Without empathy you will not truly understand your users.

    Also, in my experience there is a difference between what users say and what they actually want. Users often request features and functionality when in reality they value a simple user experience. Without a two way discussion with users it is hard to identify the underlying needs.

    Finally, unless users feel strongly about a site they are unlikely to complete a survey. This polarises results suggesting extreme opinion where it does not exist.

    I am not suggesting surveys are useless. The problem is how they are acted upon. Many treat survey results as absolute. In fact it is necessary to ignore some results and read between the lines of others.

    Third party web applications

    The final way of collecting user feedback is through a new generation of community tools. Sites like Get Satisfaction and User Voice allow two way interaction with users. Users can submit suggestions, questions and complaints online and you can respond in kind. This happens in an open forum allowing anybody to participate in the discussion.

    This open format (when compared to the predefined questions of a survey) encourages a more personal discussion and provides opportunity for a deeper level of discussion.

    As with surveys the people responding are likely to be more polarised in opinion. However, because of the interactive nature of these services it is possible to dig a little deeper and understand the underlying issues.

    Personally, I have found these services an invaluable way of building a closer relationship with users and better understanding what they are looking for.

    Of course, whatever method you use to collect feedback it must be assessed. You need to determine what must be acted upon and what can be safely ignored.

    Assessing user feedback

    Once you have engaged your users, you will be amazed at the quality and quantity of suggestions. The problem becomes deciding what to implement.

    I have had this problem for some time with both Boagworld and more recently GetSignOff. I have established 4 criteria I use to judge whether I act on a suggestion or not. These are:

    • Level of feedback – How many people are making the suggestion? If it is a substantial number then you should seriously consider implementing the idea. However if it is just a vocal minority then you may wish to think twice.
    • Source of feedback – Who is making the suggestion? Are those people your core audience? It is easy to find yourself implementing functionality for a group of users who provide no value to your business or site.
    • Cost of implementation – Consider return on investment when deciding on whether to implement a suggestion or not. If it is time consuming to build and expensive to implement, then the benefit to your users and your business must be high.
    • Impact – Finally, consider the broader impact of adding new functionality or content. Will it introduce complexity into your site? Will it break another part of the site? Will it distract users from your call to action or undermine business objectives? Often implementing a suggestion can have surprising consequences.

    There is no doubt that listening to users can be an invaluable way of improving your site. However, ask yourself how you intend to gather their feedback and respond to the results.

    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.

    As I continue my efforts to finish the website owner’s manual, I have reached a section on web stats. What struck me was how little most of us use the power of web stats. They can do so much more than monitor your marketing efforts. In particular they can:

    • Help find and resolve problems on your site
    • Improve the quality of the content you deliver

    Let us look at how.

    Finding and resolving problems

    When it comes to web stats one of the most popular figures to monitor is conversion rate. Conversion rate compares the number of users visiting your site to the number that complete a call to action.

    If your conversion rate is low, this could reflect a problem with your site. This could be due to:

    • Usability – The user is unable to find the call to action due to poor navigation or other usability issues.
    • Accessibility – For example a particular browser does not render the site correctly and so users cannot complete the call to action.
    • Content – The site does not provide adequately convincing content to encourage users to complete the call to action.

    But what consists of a low conversion ratio? That entirely depends on your call to action. For example, an ecommerce site could have a ratio anywhere between half a percent and eight percent depending on the sector and product. On the other hand, a call to action that does not cost the user money should expect a higher figure.

    The best approach is to compare a conversion ratio against itself over time. As you make adjustments to your site does that harm or improve conversion rate?

    Fortunately website statistics can also help establish what changes will improve your conversion rate. Start by looking at where users exit your site.

    Dropout points

    When looking at where users exit your site exclude those who only view one page. If you do not the homepage will be at the top of your list. This is because people click through from a search engine, discover this is not the site they wanted and leave immediately. Although this may indicate a problem with your SEO, it does not reflect badly on the site.

    Once these anomalies are excluded take a look at the remaining pages. Why are users leaving at these points? Is the content relevant and clearly presented? Is the navigation usable? Are you suggesting a next step to the user or are these dead end pages?

    Look at the history of users who dropout at a particular page. How long have they been on the site by this point? What other pages have they viewed? How long did they spend on the exit page before leaving? Does this reveal trends which help to identify the problem?

    Sometimes the problem will be obvious, other times it will not. In such cases try usability testing. This will uncover potential issues. If usability testing is not an option try using a tool like Click Tales.

    Click Tales picks up where traditional analytical packages leave off. It allows you to see what users do on an individual page. It record user sessions anonymously showing you what they click on, hover over and how far down the page they scroll.

    Although a technology like Click Tales is impressive it cannot replace traditional usability testing. It does not provide you the opportunity to question the user. For example it will not explain why users abandon shopping carts?

    When the website owners of ecommerce sites start examining their website statistics they are often horrified by the dropout rate experienced on shopping cart pages. They worry that there is a fundamental usability flaw. However, in many cases that is not true. Questioning users reveal they abandon baskets for a host of reasons ranging from ‘I was saving the items to buy later’ through to ‘I wanted to compare the price on another site’. Like the homepage, shopping carts will always have a high exit rate and no amount of statistical analysis can change that.

    However statistical analysis will allow us to improve the content and products we provide on our sites.

    Identifying popular content

    There is a real benefit in understanding what users want from our sites. From what content they want to what products they will buy, understand users requirements allows you to mould the site to user needs.

    Website statistics can help identify popular content but not in the way you might expect. Looking at the most visited pages will not provide answers.

    Popular pages can be misleading for three reasons:

    • Pages can be visited by mistake
    • Page can be popular because their prominent
    • Pages can be popular because they are gateway pages to deeper content

    The homepage is a good example of these problems. I have already explained that the homepage is visited my mistake from search engines. It is also a prominent page and used as a navigational tool for finding other content.

    Looking at how long users spend on a page can help to weed out ‘false positives’. However ultimately this is a flawed approach and can only give a partial indication of the popular content on your site.

    A better approach is to look at the search terms users entered into search engines to reach your site. Almost all website analytical packages provide this information and it helps define users priorities. However, this is only going to show content that already exists on your site. If a user entered a search term for content you do not have, your site would not have been returned. The user would never come to your site. What you really need is a way of identify content that you do not offer but users want.

    This is possible by examining the phrases users enter into your own sites search engine.

    Approximately half of your visitors will use internal search. Every time they use search they are telling you exactly what they want from your site in their own words. That is incredibly valuable.

    You need access to these search terms and particularly the ones that return zero results. This is the area where you need to do work. Users are expressing an interest in a piece of information you do not have or your search engine does not recognise.

    Once you have access to these search phrases, start tailoring content around them. If the content does not exist, add it where appropriate. If it does exist but is not being found, introduce the exact phrasing your users are searching for. Better to use the language of your users than sticking to internal jargon nobody understands.

    And there you have it. Proof that website stats can be used for a lot more than just tracking marketing campaigns.

    139. Brand

    On this week’s show we’re joined by Ryan Carson to discuss building an online brand. We look at promoting your site with minimal budget and Marcus shares his views on working in an office.

    Play

    Download this show.

    Launch our podcast player

    News and events

    Understanding progressive enhancement

    Its funny how we spend our whole lives telling clients to avoid jargon and yet web design has more jargon than most. Every few months we seem to make up some new term that is thrown around like everybody knows it.

    In reality some we have never heard certain terms, while others seems so similar to one another that the difference escapes us. Take for example ‘graceful degradation’ and ‘progressive enhancement’. Have you heard of them? Could you tell me the difference?

    I have to be honest, I couldn’t. In fact in a few weeks you will hear an interview I recorded with Paul Annett from clear:left where I make a comment about graceful degradation and he said ‘no its more like progressive enhancement’. I had no clue why one was right and the other was wrong and I am supposedly a web design expert. Does that make me thick? Possibly. However, more likely I just missed the memo on that one.

    The trouble is we are all too busy looking intelligent to clearly communicate with one another.

    I have to some extent criticised A List Apart (among others) in the past for perpetuating this kind of ‘in the know mentality’. However, I am now being forced to eat my words (gratefully so) as they published an excellent article on Progressive Enhancement and why you should care about it.

    Now if only somebody could explain what Web 2.0. really is.

    A free conference (kind of)

    I realise that some of the advice I give on this show is unrealistic for some. For example, I talk about the importance of attending conferences. However, when a conference can cost hundreds of pounds it is not always possible.

    One alternative is to listen to the podcasts that most conferences published. Unfortunately, they are slow to appear and are hard to follow without being able to see the slides.

    Fortunately, the FOWA in London has significantly raised the bar and other conferences will be forced to follow suit.

    FOWA has released video of most talks. These appeared within hours of the speaker taking the stage, and are beautifully done including both speaker and screen.

    There are also ‘highlights reels’ for most talks. These are a cut down version of the presentation, ideal if you are too busy to watch the whole thing.

    With some of the most influential people in web design taking the stage, this is an invaluable resource and Carsonified should be congratulated for making it freely available.

    Design Float

    Talking of useful resources check out Design Float. Design Float is basically a Digg clone. However it is a clone aimed at designers.

    I have to say I don’t like sites that rip off Digg. I have huge respect for what people like Daniel Burka and Joe Stump are doing at Digg. I hate to see people directly ripping off their work (normally badly).

    However, Digg does have one flaw. It doesn’t serve the niche very well. Even Kevin Rose recently said: "We don’t really do a good job of servicing the long tail of content." And he is right.

    As a web designer, categories such as technology or design are just too broad for me to bother following Digg regularly. Until this problem is resolved, Design Float is an alternative.

    Design Float allows me to only see stories relating to web design and although the smaller community means that stories are posted less regularly, what is posted is pretty good.

    I recommend checking it out. However, if you are a designer don’t just limit yourself to web design posts. Also look at the other design posts. There is some pretty inspiring stuff there.

    Can we stop supporting text scaling?

    Finally today, a post by Dave Shea in which he discusses page zooming.

    Most modern browsers now support page zooming. The only exception is Safari and that will soon change. This allows users to zoom an entire page, not just the text. Obviously this is beneficial to those with visual impairments. However, is also exciting for web site owners and designers.

    Traditionally websites have been forced to support text resizing. This significantly increased development time as well as making design integrity challenging. As text scales, designs often breakdown especially when fixed sized images are involved.

    With page zooming these problems go away. It provides the designer with more control and reduces the costs of development. A cost normally passed on to the website owner.

    Dave asks whether it is time to support page zoom rather than text resizing. As can be seem from the comments, there is no wrong or right answer. Nevertheless it is an interesting question and one you might want to start considering for your own site.

    Back to top

    Interview: Ryan Carson on Building an Online Brand

    Paul: So I’m really excited to have joining me today Ryan Carson from Carsonified. Good to speak to you Ryan.

    Ryan: Thanks for having me Paul. Good to be here.

    Paul: It seems that we are crossing paths more and more often with me doing various things with Future Of conferences and you guys kindly giving discounts to my listeners, so it’s good to finally actually have you on the show.

    Ryan: Thanks. It’s great to be here.

    Paul: So the reason I have asked Ryan on to the show today is to talk a little bit about building an online brand. Carsonified have got lots of different brand identities going on with obviously Carsonified itself and then Future Of and ThinkVitamin and various other things. Ryan’s a bit of an expert really, or he comes across like that anyway, at building an online brand and I wanted to talk to him about how he’s gone about doing that. But before we get into that, Ryan, tell us a little bit about the background of Carsonified. How did it come into being, so to speak? How did it end up being what it is today?

    Ryan: Well, it was kind of born four years ago. It started off basically as just me in our top bedroom. I used to be a developer in a web design studio and when Jill and I, my wife and I, got married four years ago we just decided to start our own company. At that point it was just me and I was trying to build web apps and attempting to make money and didn’t really do a great job of it. Then I kind of slowly moved into doing sort of more workshops and things and then we built our first proper web app, which was DropSend, and then we just kept growing and growing and doing more web apps and more websites, for ourself not for clients, and then we launched a couple big conferences, Future Of Web Apps and Future Of Web Design, and all of a sudden now we’re about eleven people. Located in Bath and just love what we do and are really excited to be part of the web industry. So that’s us kind of in a nutshell.

    Paul: It’s quite interesting, the approach that you’ve taken. You’ve come from the same background as the vast majority of us yet your business has gone in a completely different direction. You haven’t gone down the road of delivering solutions to clients but you’ve done this quite eclectic thing of a bit of web apps here, conferences here. Was that an intentional thing or has it just kind of naturally evolved that way?

    Ryan: It kind of naturally evolved but my mother, and your mom always knows you best, she always said there’s a vein that’s been running through my life for a long time, which is just connecting people. I don’t know, for whatever reason I just get a lot of joy out of connecting people and physical events are just a great way to do that. I’m passionate about the web and therefore it’s kind of like, well, connecting people in the web industry, in the technology sector is just kind of made sense. It did start off with this thing called BD4D which you probably don’t remember, By Designers For Designers. A friend and I did that and it was bd4d.com which is now gone but the idea was we got together designers for free just at a bar and people showed their work. It was in London originally and it kind of took off and I think then it was always just a for fun thing. We called it the Creative Fight Club. I think that was kind of the genesis of our events career. We don’t really see ourself as an events company we see ourselves very much as lovers of the web and technology and we just kind of happen to connect people at events so, it just kind of worked that way. I’m also not a big fan of working for clients because it’s just so hard. I really respect what you guys at Headscape and any web designer web developer because constantly doing work for clients is really hard work and it’s fun but it’s hard and because we run our own conferences and build our own web apps thankfully we’re our own client which gives us a bit more freedom. So that’s kind of how we ended up there.

    Paul: It depends on how you look at it Ryan because from my point of view you’ve got thousands of clients while I only have one at a time because you have all those users of your apps and the people who come to your conferences. You’ve got far more trouble in my opinion.

    Ryan: I guess you could look at it like that but they tend to be less demanding. They’re not paying us thousands of pounds each so it kind of. But you could look at it like that. We try to treat all of you who come to our show with the same respect as clients, it’s just a shorter term, lower economic value relationship.

    Paul: OK, so let’s talk about brand a little bit and profile and stuff like that. Carsonified has kind of built quite a significant online profile and I’m just quite interested in some of the techniques that you’ve used to achieve that. You know, how have you made that happen?

    Ryan: OK, well I think underlying everything we do is genuineness. I think that we care very much about honesty and being genuine and being kind and friendly and that sounds a bit fuzzy and happy but that’s just kind of, I don’t know, the way we are. And I think that’s been the key to our success, that when we do things people know that we’re not trying to pull the wool over their eyes or secretly sell them something. We have a genuine interest in the web and the tech industry and so when we do things people kind of know there’s real people that are behind this, we’re not some company. And I think we’ve always been very personal and very human and very transparent and I think that at least set the stage for being successful, but obviously we just follow through with pumping out tons of hopefully valuable content. We see building a brand as basically building friends and I think that on our blogs and through our tweets and at our events and through our communications we try to treat everybody as friends and that’s kind of, I think, a little bit of the key to our success.

    Paul: I like that idea of talking about treating people as friends. I think that’s a good way. Too many people treat people as potential customers in preference to actually having any real interest in them as human beings I guess. So it’s good.

    Ryan: Well yeah. I just kind of think about who do you like being around? I mean, It’s your friends and there’s a reason for that. I think why does business have to be different? Of course there’s an element of professionality but when you go to the pub and you relax it’s because you feel comfortable with people and I think that whole idea should permeate business. You know with your friends you just buy them a beer, but with your customers there’s significant money being exchanged I think that should involve even more trust than friendship. Hopefully our customers, our attendees and our sponsors really believe that we’re doing the right thing for them. You guys probably do something very similar when you work with your clients. You want them to know that you care about them. That this isn’t just about money that you actually are trying to build something beautiful and worthwhile for them.

    Paul: Yeah. I mean it’s interesting. You talking about friends reminds me a little bit of the Innocent smoothie guys that I heard talking at Fuel, which is obviously one of your conferences, where they were talking about how they refer to their customers as family, don’t they? And I always thought was quite a. It sounds naff when you say out loud, referring to your customers as family but if you kind of treat them with that kind of respect, I don’t know, it’s good but it depends on how you get on with your family I guess.

    Ryan: Yeah. It could be good or bad but the problem is that would never work if you didn’t actually think Innocent cared about you. If you looked on their bottle and there was E numbers and preservatives and stuff you’d think, “Well, they talk this stuff, but they don’t really seem that committed to doing this.” So I think it really needs to be backed up with a sincere and real effort to support. I mean, we’ve been talking about accessibility, this is a good example, at Carsonified for years. You know, “Yeah we care about accessibility and it’s a great thing,” but we don’t actually know what we’re doing and so we just met with AbilityNet yesterday with Robin and we said we want to get serious about this. I know that you guys are really good at accessibility and sort of putting our money where our mouth is. We want people with disabilities to be able to attend our shows and to use our websites. Let’s actually spend some money on that and get serious about it so at the bottom of each page we’re going to put a little thumbs up symbol that will go to a site that explains why accessibility is important to us and what we’ve done to move towards that with also sort of some tips and hints for people who are disabled like how can you use this site better and get more out of it so trying to put our money where our mouth is really.

    Paul: Yeah. I tell you one of my favorite moments I ever had at one of your conferences was, I can’t even remember who the speaker was but the question that came out for the panel was about promoting your business and can you do that outside of San Francisco and California and this guy said you had to be in California you had to be at San Francisco if you wanted to launch a web app and you stood up afterwards and you completely laid into this guy and you said, “No no no, that’s not the case, blah blah blah.” But it does strike me, you know, you’re a Bath-based company and Bath isn’t exactly the beating heart of the web design world and I’m quite interested as to whether you feel that that’s been a barrier to you in any way, being based where you are.

    Ryan: That’s a great question. It makes it harder, for sure. You know, we have to go to London to have meetings to go to drink, parties, to network, blah blah blah, but the way we make up for that, and I think a lot of your listeners won’t be in London necessarily or New York or Silicon Valley so this is applicable to all of you out there. It’s all about being visible on the web. And you guys do a good job of this as well. You just have to get yourself out there. So we blog as much as we can, we tweet as much as we can. We try to gather a community around us and that’s the way we make up for the fact that we’re not in London or Silicon Valley. I was going to say another important thing about building a brand, and this fits into that, you need to have an opinion in order to be heard, and that means that you have to be comfortable with the fact that people will completely disagree with you sometimes. You know I think in a way I’ve been successful at building a brand because I’m willing to say something that pisses people off really. You know and I think it’s only interesting to hear from someone who has an opinion. When Paul Graham said that “You know you need to be in the startup hub,” it just really made me angry, because he was basically saying to every one of us, well, you know you’re just kind of screwed, and I just thought, “You know what? That’s just not true, and it makes mad and I’m gonna sort of put my reputation on the line by going on stage and disagreeing with you, a well known entrepreneur.” And if I kind of was afraid to do that you know, not so many people know about et cetera. So yeah, get out there, blog, be as controversial as you can, you know as long as you’re being genuine and be ready for people to say mean things about you really.

    Paul: Talking about mean things and people say mean things about you. You’ve come under some criticism for being somewhat pushy in your self-promotion. Do you think that’s kind of justified in any way? Do you think maybe there’s a cultural difference there, the fact that you’re American and are us English more uncomfortable with marketing and promoting ourselves?

    Ryan: Yes, I think there is a cultural difference. But I’m also kind of, I like to think I’m friendly but I am sort of a brash person. I’m not afraid to tell you my opinion and do what I think I need to do. While being kind, I don’t want to sort of hurt anybody, but I think there is a cultural difference and I do think that, I mean my wife is English so I’m obviously very familiar with English culture now and British culture and I think there is kind of a slight uncomfortableness with getting on stage and blowing your own horn. I think that in the UK we need to get over that. Not change our culture here but be willing to admit that in the UK if we don’t start to step up to the plate and start talking about ourselves, the rest of the world’s just gonna carry on in the tech space. Mike Harrington, he’s not going to shut up. You know and unless we really start to kind of compete with that and start talk about all of the great things that are going on in the UK and really kind of get out there I think unfortunately it means that the startups and the web designers and web developers that are British are going to start to fall behind in the world stage. For instance, I was trying to think, who are the rock star developers in the UK? Who can you name? I mean I can name a couple but who do you think?

    Paul: It’s hard. It’s hard to say. I think there are more rock star designers than there are developers. You know you can think of people like Rachel Andrew, and Drew. Two that spring to mind. Jeremy Keith is kind of a developer but maybe not really.

    Ryan: Matt Biddle. You know, there’s a few but it’s just. It’s not the plethora that are sort of being spoken about, in the US particularly, but I have no doubt there’s just as many talented people here. It’s just that, that hesitancy to say, “I’m going to do my own startup. I’ve got a good idea. I’ve got what it takes. I’m gonna start talking about it.” It’s just less common over here. I’m not saying that’s a bad thing and that everyone here should change but I think if you want to build a brand in the web space you just need to admit that I’ve got to get out there. You know I had an interesting conversation with Alex Hunter who is sort of really big in Virgin, The Virgin Group, he’s high up and he’s met Richard Branson a bunch of times. And you know what was crazy? He said that Richard was really shy. And I was like, “Really?” That’s a great example I think of a guy, he’s obviously driven and I don’t think everyone should be like Richard Branson but he’s obviously driven and he understands that in order to get Virgin talked about, to build a brand he’s got to be kind of crazy and get out there. He’s always hanging from helicopters or you know flying spaceships and you know, that’s why people talk about him.

    Paul: I think there’s also a little bit within the web design community here in the UK of kind of almost false modesty and a little bit of trying to persuade the world that we’re being very altruistic in what we’re doing and not being up front. I receive criticism for the fact that I’m very open about the fact that Boagworld is a marketing tool and that we make money out of it.

    Ryan: But it’s the truth.

    Paul: Yeah, exactly. So I think I prefer to be up front about those things, than kind of hide them behind a façade of false modesty to be honest.

    Ryan: Well yeah and that kind of goes back to my thing I said earlier about being genuine. I think you’ll always be better off if you’re genuine. And of course we’re sort of painting with broad brushstrokes here, but there’s some very talented people here and I just think, let’s get on our soap boxes and sort of shouting back at the Americans really. And people are doing it, I just think there should be more of it.

    Paul: Talking about effective marketing tools, ThinkVitamin, let’s talk about that for a little bit. ThinkVitamin is a website that you run which is basically web design related and web app related kind of articles and stuff like that. I’m guessing that was set up as a marketing tool. Tell me a little bit about why it exists and how you came about setting it up and what its aim is for you.

    Ryan: Yes. So thinkvitamin.com has two purposes. It’s to build good will and to give back to the community but it’s also a marketing tool and those things are actually very related. If we pump out great content we give away for free it will be valuable, but those of you who read thinkvitamin.com will also probably come to our shows. It’s a symbiotic relationship. We’re very happy to do that. There is a little bit of altruism there, we do actually want to provide good content and give it away for free but we also realize we needed a platform to talk about our shows. We kind of kept calling in favors like, “Do you mind blogging about Future Of Web Apps?” and “Can you mention it?” We just thought we need to build a big site that people go to so we can tell them about that and we’re fortunate to have great connections. We know people like you and Molly Holzschlag and Kevin Rose and just big Internet people and they all agreed to be on the advisory board and really that’s just a group of people that we trust that occasionally write for us but we’re actually taking ThinkVitamin in a new direction where we want it to pretty much become it’s own little business. So we’ve hired a full time Editor named Simon Mackie and he was really high up at SitePoint actually. And he’s come over and he’s taken the reigns and we’re gonna, yeah we’re gonna basically grow that team and expand that out into its own little business.

    Paul: That’s interesting.

    Ryan: It’ll be better for the readers. It kind of was dying. The publishing schedule was going down and I think we realized, “Man this is so valuable we have over 50,000 RSS subscribers, closer to 70 if you count the news feed,” and we thought, “This is great, we should grow it.”

    Paul: Yeah. I mean it’s interesting in some ways you’ve kind of taken the same approach that we have at Headscape using ThinkVitamin that you could have created a blog on the Futures Of website and you could have put this content there. There’s actually a value in separating it out and making it a standalone thing. It feels less salesy I guess. The same way as I could have posted my Boagworld stuff on the Headscape site. You know it could be the Headscape podcast instead of the Boagworld one. All the rest of it. It just comes on a bit too strong if you do that I guess.

    Ryan: I totally agree. And it’s interesting because I had a good conversation with Mike at FreshBooks, and freshbooks.com for those of you who don’t know is an app that helps you send out invoices. He had this blog and he was really slogging his guts out on it and at freshbooks.com/blog or something and he said, “I don’t get it. No one’s really reading it,” and to me it was obvious for that reason you just said. Well it’s clear that this is just a marketing tool. Why would you put a blog on your company’s site, on your product’s site? It’s just kind of obvious and that’s exactly why we haven’t done it for our events, you know we put occasional updates there but it’s hard. As much as I like Web 2.0 Expo or something I would never read a blog from Web 2.0 Expo. It’s just too blech, you know what I mean?

    Paul: Yeah totally. It’s interesting that the other thing that you’ve done, which again is something that I do, which is that you haven’t just relied on people coming into your sites, whether it be ThinkVitamin or the Futures Of sites or even the Carsonified site. You’ve made a big deal of kind of going out there and using tools like Twitter and Qik and YouTube. I’m just interested as how effective you’ve found those things.

    Ryan: I find Qik to be really effective, or Qik, however the heck you say it qik.com and I was really shocked as soon as I started broadcasting was that just tons of people were interacting and I almost couldn’t wait to do the next one. Annoyingly 3G is kind of spotty in Bath so it makes the quality a little bit bad but I’d highly recommend Qik or any other comparable service. It’s so fun you just take your phone with you, I had to get a kind of crappy Nokia phone or something, because I use my iPhone for normal business but just grabbed it from the 3 store, got a plan I think it’s 20 pounds a month that gives you unlimited data which you’ll need if you’re streaming live video from a phone, and whenever I’d walk to Starbucks or something I’d just turn it on and start talking and people would show up because the way Qik works for people who don’t know is you actually see comments live on the phone screen.

    Paul: That’s very cool.

    Ryan: Yeah, it’s great for interaction and any tool you can use to interact with your fans will increase your connection and that friendship. It will show you want to be real and you want to connect with people and I think hopefully we’ve achieved that where people think, “Gosh you know Carsonified we know who’s there we know it’s not a company it’s really these people that are there and they’re interested in hearing from me and talking to me,” so that’s been good. YouTube has been amazing, I mean I hate YouTube, it’s ugly, it’s a bit crude you know but man there’s just a lot of people on it. I used this cruddy little video camera, filmed myself giving some tips about business, threw it in iMovie, put some music to it and popped it on YouTube and I think I can’t remember the figures it’s up to, it’s up to like 10 or 15,000 views in literally like two hours work.

    Paul: Yeah, I keep meaning to get around to that myself and I’ve never quite managed it.

    Ryan: Now you can use a Flip camera. Flip is just a type of camera, you just record and then it’s got a USB dongle built right into it. You pop it in and it actually automatically uploads it to YouTube.

    Paul: That’s nice.

    Ryan: There’s a couple tools you can use to make it easier. And then Facebook, I’ve been using Facebook a lot just to connect with people and remember people’s birthdays and say hello and just be a friend to them. The more connections you can have to people the better, which builds your brand and I feel that, like a mercenary when I say that, and I don’t like it, like I do believe it’s just a better way to live to connect with people and it happens to build your brand which is great and I like that as well, but I think it’s important that you need to be genuine and actually care about people for this to connect.

    Paul: What about Twitter? How have you got on with that? Have you found that a useful tool?

    Ryan: I love Twitter. And it’s been probably the best way I think for me to communicate I’ve got I think around 4,200 followers now and I don’t know why people follow me. I don’t think I’m particularly interesting but I do whenever I tweet I try to imagine if I was somebody else and I was reading it if I would find it interesting. I think with Twitter don’t tweet too much, maybe a couple times a day max. If you tweet too much people unsubscribe.

    Paul: That will explain my problem then, I tweet too much.

    Ryan: I still follow you so it’s not too bad. But you know Evan Williams had a good tip he said you should tweet things every so often that you’re not quite sure if you should tweet because they’re a bit too personal or a bit too blech, because that’s the type of stuff that’s actually fun and interesting to read. Initially we had a twitter account for Carsonified and we deleted it. I think we decided that that was kind of exactly what not to do. People don’t really want to hear from a company, they want to hear from you.

    Paul: That’s almost the same as having a blog on your own corporate website isn’t it? Having a kind of corporate Twitter account. After saying that we have set one up for GetSignoff but more as a for announcements. If something goes down with the service or if we’ve done some bug fixes or stuff like that. By far the majority I do via the Boagworld Twitter account which is just me talking about my life. I agree with what you’re saying about putting personal stuff there as well that people seem to like to know what’s going on with each other’s lives. I like to know how Jackson’s doing. People like to know, I don’t know. Making it personal, it’s about that personal connection again isn’t it really?

    Ryan: Definitely. And I think that that’s the future, you know just in general. Humankind you know it’s just kind of being personal and not hiding anymore behind companies or brands or policies or terms and conditions. It’s about, “Hey, how can I help you and how can I take care of you?” and that’s just a better way to live and it will massively benefit your company which is great. What’s interesting though is that everybody, including us, continues to look at the Signal vs. Noise blog from 37signals and kind of scratch our heads it’s like, it’s the one blog where it is a company blog, I mean yes it’s called Signal vs. Noise, but it’s on their domain, and yet they have over 90,000 subscribers. It’s funny because I think everyone is kind of, “How do you do that? I want to replicate that.” In the end I think you know, they were kind of first. You can’t have that many of those type of blogs and I think most of us are gonna have to be happy with just doing a good blog that is real and personal whether, and I mean ours is carsonified.com and it seems to work and we have about 4,000 subscribers and for us that’s a pretty good number. We should post more but that’s something I haven’t quite figured out yet and I’d be interested to hear from your listeners what they think about that. Is it possible to have a company blog that people care about or is it just not possible? I don’t know.

    Paul: I think what you said there about being first is quite significant. I think originality goes a long way. I mean even with the Boagworld podcast. Simply the fact that I was the first web design podcast it seems to give it a momentum that keeps things going, you know because you keep delivering the goods so to speak which obviously the guys at 37signals really have done. I think there is a momentum in being first in something.

    Ryan: Yes and that’s probably the secret sauce.

    Paul: OK, So let’s wrap this up with kind of a last question which is: What advice would you give to budding entrepreneurs seeking to increase their profile? Let’s have some kind of top tips if you’ve got some.

    Ryan: OK. The first tip I give is to start connecting with people that you feel are influential. You know, spend some time and try to get out and physically meet these people, get to know them and to not be creepy about it, but to get out there, to get in front of them and to get to know them. See if you can do something to help them out, to get on their radar, and I think building sort of a group of friends that trusts you but is also influential is just instantly valuable. So I’d do that and you can use all the tools we talked about for that: Facebook, Twitter, etc. etc. but physical meeting is always the best. I mean you want to have a beer with people.

    Paul: And you say you do that by trying to help them out in some way? Because that’s always the difficult thing. It’s all well and good to say, “Get to know influential people,” but how you do that’s the tricky part isn’t it?

    Ryan: Well my dad always did something that worked. If it was someone he really respected or cared about and wanted to get on their radar he would find an article about them in a magazine and he’d actually go to a framer and have it framed and then write them a personal note and just kind of say and send it to them and say, “You know, I bet you haven’t had time to actually frame a picture of your article so I thought you might want this for your wall.”

    Paul: What a genius idea. I love it.

    Ryan: And it’s genuine. I’m not trying to get anything out of you but I respect you and here you go. It’s very subtle. You have to be very careful to not try to sort of bribe people. If you come across that way it’s exactly what you don’t want to do. If you feel, and kind of think deep down, “Do I actually want to be friends with this person or am I trying to use them?” I think you should steer very clear of a person if you just think actually I don’t really like this person I’m just trying to get something out of them. But if you think there’s some synergy there, that’s a great way to do it. Remember people’s birthdays, it’s just a nice thing to do. Stuff like that is a great way. Most people’s friends don’t even do that for them. I’ve had people send me stuff and you know it just makes me smile and I’ll always take their call or answer their email now. So I think that’s a good idea.

    Paul: Any others?

    Ryan: Um, other tips. Um, probably put a real emphasis on customer service and build a real base of caring in your company. Not just for your customers but for your own team. I think that your team will never be able to treat your customers well if they don’t think that they’re treated well. So I think as entrepreneurs grow and they start to hire people I think it’s important to remember to take care of your staff first and then your customers second. And a really great resource for that is what zappos.com does. Zappos.com has an amazing company culture. They have this book called the Culture Book and every year it comes out and you can buy it and it’s basically a bunch of testimonials, thousands of them from the Zappos employees about why they love their job. And it’s just packed full of ideas of how to take care of your team and it’s a great inspirational resource. I think you can either get it on eBay or Amazon or you can buy it straight from Zappos. A couple hopefully useful tips?

    Paul: Yeah that’s excellent. Ryan thank you so much for coming on the show, it’s been really good to get you on and I think there’s some really good useful advice there for anybody looking to kind of build an online brand so thank you very much and no doubt we will have you back again soon.

    Ryan: Thank you, it’s an honor.

    Thanks goes to Todd Dietrich for transcribing this interview.

    Back to top

    Listeners feedback:

    Site promotion with minimal budget

    Our first question is from Adam in the boagworld forum:

    I have got a site that needs an awful lot of promotion to work, and have got very little budget to do it with. I could probably spend a little bit on Google AdWords but on nothing else. So, how can I promote my site for little money?

    Adam went on to tell me it was a charity website. This makes it challenging. As Adam said…

    There are thousands of Charity sites, and many better funded, and just altogether bigger.

    In this situation search engine optimisation or Adwords is going to be tough. The competition is fierce and so it will be expensive to be highly ranked.

    The other problem with a charity site is that unless it is niche (e.g. bird protection) the potential audience is open ended. However, with limited resources there is little point in targeting ‘the general public’. You will have no impact on such a broad audience.

    Target a specific group as it will be easier to gain momentum within a smaller audience. For example, there are Christian charities who do general humanitarian aid. Even though anybody could be a potential supporter, they instead target other christians. Therefore they are well known in that circle. Better to have a lot of support from a niche audience than a small amount of support across the general populous.

    Once you have picked the audience use three techniques to reach them:

    • Offline promotion – Engage with your audience offline as well as on. Attend conferences, produce offline promotional material and target magazines your audience reads. As web designers we often forget to power of offline marketing.
    • Social marketing – Identify the social sites your audience You should be wherever your audience is interacting. Finally, seek out key figures who your audience admire and respect. See if you can get them on board and encourage them to promote your site.
    • Editorial promotion - Find out if your audience reads online blogs or magazines. Offer to write articles for these sites. Do not overtly promote your charity but instead write content which will be of interest to the audience. Failing that make use of comments to join in the discussions and increase your sites profile among that audience.

    However, be careful. In your haste to promote your site do not spam. The key is to offer something of value. You must earn the right to promote your site.

    Sitepoint has an excellent article entitled ‘10 rules for driving traffic using forums‘. Although it is focused on forums, its advice is applicable to most forms of online promotion.

    Office Or Not

    This from Brad:

    A question from Canada! I’m a long-time listener of the show, and I thank you both for your entertainment and inspiration.

    A little bit of background first… Two years ago I co-founded a small web development company, and to date we have not yet invested in office space. As we slowly move on to ‘higher profile’ clients, we find it increasingly important to have someone in-house, to answered the phones, do the books, etc, etc, so we can focus on growing the business.

    That said, I’m obviously touching on a huge spectrum of possible questions, so I’ll try to narrow it down. I don’t think this is something you have covered specifically on the show before…

    Is office space really important for a creative business? If so, what steps would you recommend. And if not, are there better areas to spend $2000 / month?

    If I had been asked this question only two years or so ago I would have said that office working for a web team is not important at all. If anything, I would have said that home working was better. The following extract from Paul’s blog, written in 2005, underlines this:

    The benefits of a virtual company

    By virtual company, I mean we do not have a central office. Each member of staff works from home and we communicate and file share with tools such as Skype, CVS and Groove.

    People are often curious about an entire company home working and ask how well it works in reality. My answer is usually that it is brilliant. From the employee perspective, you do not have to commute and you can see a lot more of your family. For example, if I were still working for IBM when I used to commute an hour and a half everyday, I would only see my 2-year-old son at weekends. As an employer, I love it because my staff tend to work the hours they would commute and generally home working is seen as a big bonus that keeps people at the company longer. Not to mention the savings made on premises.

    Communication really is not a big problem. There are so many tools out there these days that help, and broadband means that even telephone conversations are now free.

    Paul goes on to say that the only drawback of home working is that it lacks the social aspects of working in an office.

    Not true I’m afraid. Though of course home working does give you an environment to ‘get your head down’ without interruption, what it really lacks, that phone/email/IM cannot replace, is creative collaboration. People simply do not bounce ideas around like they do if they work together.

    Our current office is open plan and there’s nowhere to hide yourself away. This has meant that I haven’t really frequented it that often – I need ‘calm’ to write. However, watching particularly our development team grow and work really effectively together underlined to all of us the value of working together.

    So much so that we are about to move into our ‘dream’ offices where there will be a mixture of open plan spaces and areas where we can work quietly.

    So (finally!), in answer to Brad’s question, I think that office working is better for the business in the long run and I would say warrants the additional associated cost (though beware the costs, they can mount up – another podcast topic I think). That said, we have managed for nearly seven years before doing it properly (i.e. pretty much all of us will be in together most of the time) so it won’t necessarily damage you if you leave it awhile.

    Back to top

    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

    134. Chrome

    In this weeks show we give you advice on choosing the right hosting company, Teifion and John send us a review of dConstruct and of course we discuss the release of Google Chrome, can it topple IE?

    Download this show.

    Launch our podcast player

    News and events

    Managing and choosing fonts

    With the new generation of browsers supporting embedded fonts in a consistent way, it is time for us as web designers to start taking typography serious.

    One small part of this is how we manage and choose fonts. I confess, I have put little thought into font management. The result is that my choice of font is often not as thought through as it should be. A massive drop-down list in Photoshop does not inspire considered typography.

    However, a couple of discovers this week have inspired me to put more thought into the subject.

    The first is a review of 25 font management tools. This include both free and paid for software. It also has options for both the Mac, PC and even Linux.

    You might ask why we need a font management tool at all. Trust me, if you start installing a lot of fonts on your system you will soon discover why. Large number of fonts become unmanageable and can cause serious performance problems. As a minimum you need an easy way to enable or disable fonts.

    The second discovery was an online/AIR font application that displays text of your choice in every font available on your system. This in itself makes font selection much easier. However, this application also enables you to narrow the field by removing unsuitable fonts. It is a great visual way of getting the right typographic look.

    jQuery supercharges menu rollovers

    Although I am a standards based designer through and through, I have always felt like the nerd in the class. After all it is the Flash kids that get all the girls and attract all the attention with their cool (if somewhat inaccessible) animations and effects.

    4 years ago Dave Shea attempted to smarten up our image a little with CSS Sprites. This was a technique for doing CSS based rollovers on menu items. It wasn’t as eye catching as Flash but it was a start and at least I didn’t feel dirty after I used it.

    Jump forward to the present and we find a world where the ‘cool divide’ has been reduced thanks to Javascript. Dave therefore felt the need to bring his CSS sprite technique up-to-date on A List Apart, using a sprinkling of Javascript.

    Using jQuery Dave takes the plain old CSS sprite menu and gives it an attractive new look. However, at the same time he maintains its accessibility thanks to progressive enhancement.

    It is a slightly long winded article (like I can talk!) in places nevertheless it is a nice illustration of what jQuery and CSS are capable of. It is also a technique we can all make use of right now, something A List Apart has been missing sometimes of late.

    Can Google Chrome Topple IE?

    Without a doubt the biggest story of the week is that Google has launched its own browser called Chrome. At the moment the browser is only available for windows although a mac and linux will follow shortly.

    More on my thoughts can be found here

    Back to top

    Feature: Choosing a Hosting Company

    Hosting companies are a dime a dozen. They all offer very similar packages and all seem competitive on price. How then do you choose between them. We discuss this in this weeks feature.

    Back to top

    Review: dConstruct

    Teifion: And the next part of the podcast is sponsored by Ticklefish Design and Searchlight Digital.

    John: Hi I’m Marcus Lillington.

    Teifion: No I want to be Marcus Lillington. Marcus is the cool one he doesn’t get my name too wrong.

    John: No no. You agreed that we would both be Marcus.

    Teifion: That’s a fair compromise. No one want’s to be Paul. Anyway right. On with the show. So Marcus what did you generally think of the conference?

    John: I thought it was really good actually. Yeah I enjoyed it all. I enjoyed the free coffee.

    Teifion: Which you didn’t tell me about till right at the end so I only got one cup.

    John: No that’s right.

    Teifion: I thought I was a bit unfair.

    John: I thought it was sort of obvious there was free coffee. But with regards to the speakers, yeah I enjoyed all of them. Some of the speakers were speaking about things I don’t really you know, I’m not involved with directly but they all put their points across really well. I enjoyed all of them. I think I can take something away from each speaker. What did you think?

    Teifion: I quite liked the fact that none of them talked for too long or too little. They were all quite engrossing and though again not directly related to what I do they were all very interesting and I did end up taking something away from it.

    John: Yeah and there was humour in there as well.

    Teifion: Oh there was Matt and Matt are hilarious.

    John: Yeah Matt and Matt get the award for comic.

    Teifion: With that subject what was your favorite talk during it?

    John: My favorite talk was Tantek on microformats.

    Teifion: Okay summarize roughly what he talked about. Except microformats that just kinda basic.

    John: Yeah it is really. You know the concept of how microformats are I don’t really know what I’m saying again.

    Teifion: Just keep going Paul does.

    John: Yeah just how you shouldn’t have to keep reinputting data into all these different sites, all these different social networks that we go on. They should all, you know there should be one sort of central hub which is your sort of central place where you put all your details in and all these other sites that you choose to join up to and put information on. They should all just link up. Microformats again is a new subject to me. I’ve only done a basic vCard and that’s about it. It’s definitely something I’m going to read into.

    Teifion: I’ll definitely agree with that summary.

    John: Although a little long winded.

    Teifion: No not long winded at all. Remember the people who listen to this are used to listening to Paul.

    John: Yeah that’s true.

    Teifion: Well I’d say that my favorite talk was Jeremy Keith on the system of the world it’s titled. I would have titled it something more like "Why the cloud can be smart and why it can be stupid. Why you think you can predict it and why you really can’t." It was a great intellectual talk and I’m pretty sure that most of it went over my head. Possibly into the head of who ever was sitting behind me. He basically said that you can’t predict what will be the next big thing like Facebook or Twitter but you can create good foundations or nurture something so that it’s more likely to be the next big thing.

    John: Yeah that’s a good summary there as well. I mean basically I thought it was just about a black swan.

    Teifion: That is true actually. It’s just all about the black swan. You can’t predict it. It’s got a big effect and after it you’ll all go back and say "Hey we knew this was coming.

    John: We knew this black swan was going to be born.

    Teifion: Yeah that’s how it works isn’t it. Tell you what, what do you think the best moment of the conference was to you?

    John: Ah. I mean there’s a lot of moments but the best moment has got to be Teifion, as Marcus calls you, when you went up to Ryan Carson to thank him for the free complimentary tickets to dConstruct.

    Teifion: I’d like to point out that yesterday as in the day before the conference I had a 5 hour train journey from South Wales to Brighton. I then went to bed really late and got up really early. I was really tired and confused.

    John: Still no excuse. You call yourself a student.

    Teifion: No I’m a graduate.

    John: Oh okay. There’s a slight difference. But luckily for Teifion I pulled him back at the last moment to save his ???? it wasn’t Carsonified that supplied the tickets it was Clearleft.

    Teifion: I knew it was Clearleft that supplied the tickets. I just got confused. Tall guys in hats are very confusing.

    John: What about you? What was your favorite moment?

    Teifion: I think it was when we actually went up to thank Jeremy for putting the whole event on and for possibly the free tickets. It wasn’t actually Jeremy that we needed to thank aparently. I like the way that you sort of thought how to do it. You went for the wussy catch his eye approach. I just walked up and said "hi thanks for the tickets. Have a business card." I didn’t actually give him a business card.

    John: No but that is a funny point. Tef did hand out quite a few business cards. Which is good I mean networking is really good. Apart from the lady who you tried to impose your business card on.

    Teifion: I don’t think she heard me.

    John: No she just blanked you.

    Teifion: It’s possible. It’s happened before. You remember why we went to see Jeremy don’t you. It’s because sadly Marcus your jokes are sadly not up to the calibre that we would like. Granted their not dire, I mean if Paul was in charge of it they would be dire or worse. But I think Marcus’ jokes could do with some improvements. So we went up to Jeremy to ask him for a joke. Do you want to tell the joke.

    John: Yeah I would love to tell a joke. Apart from the fact that I actually can’t remember it. But seeing as you already knew it and knew the punch line you can tell it.

    Teifion: Okay why did the chicken cross the mobile strip?

    John: I don’t know. Why did the chicken cross the mobile strip?

    Teifion: To get to the same side. If you don’t know what a mobile strip is Google it.

    John: Unfortunately I don’t.

    Teifion: That’s a shame. Well I suppose we’re hitting the 6 minute mark which if we were Paul we’d go "Well lets start on the news." or maybe waffle on a bit more. We’re actually going to have to conclude this partly because it’s not our own podcast. So I figured what we could do is we can end it with a question. What do you think of that idea?

    John: Good idea.

    Teifion: Well what I’m going to do now is I’m going to put you on the spot and I’m going to pause it for 30 seconds and you are going to come up with a question and then you’re going to ask it.

    John: Brilliant. Was that the pause?

    Teifion: Yes a good long 30 seconds.

    John: I thought you were just going to do a pretend pause and then we’d just go right into it.

    Teifion: No that would be something that Paul would do. Paul’s not cool.

    John: My question to both of you Paul and Marcus is, "Would you advise up and coming web designers or developers to email and get in contact with local agencies with regards to getting some kind of work experience with them? Even if it’s only for like a day or two." So that’s my question.

    Teifion: Fair enough. I suppose I could add a sort of additional question. It is "If you put so much effort into your work Paul you presume you put a lot of effort in to your family like. I know you put a lot of effort into youth work. Why is it so hard for you to put just a little tiny bit of effort into learning how to pronounce a name that so many people I know can so easily pronounce? It’s (he didn’t spell it so I don’t know). It’s really not that hard.

    John: Teifion

    Teifion: See if you knew me for longer you’d be able to pronounce it. Maybe Paul’s just not cool enough.

    John: Maybe you should all just call him Ty from now on.

    Teifion: That could work. Anyway that’s it.

    John: O I’ve got one more point. Stanton.

    Teifion: Where is Stanton?

    John: Stanton we agree well we met him. He said he wanted to help and come in and say a few words at the end of the podcast but we don’t know where he is. He was last seen

    Teifion: chatting up randoms.

    John: Yeah that sums it up.

    Teifion: I could guess at what he would say I could be completely wrong though.

    John: I think we should end it on that note.

    Teifion: Bye.

    John: Bye.

    Thanks goes to Curtis McHale for transcribing this review.

    Back to top

    130. Air

    On this week’s show; Paul talks about better understanding disabled users. We have a tip from Jeremy about problem solving and Jonathan Snook introduces us to Adobe Air.

    Download this show.

    Launch our podcast player

    Housekeeping

    A few pieces of housekeeping I wanted to quickly mention at the start of this week’s show.

    • FOWA – The guys over at Carsonified have been kind enough to offer boagworld listeners a 15% discount off of the upcoming Future of Web Apps conference in London. The conference takes place between the 8-10 October and is an absolutely superb event. To claim your discount use the code FOWA-bw at checkout. There are only 50 discounted places, so be quick.
    • SXSW – Talking of conferences can I ask a favour of you all. Marcus is desperate to go to next years SXSW conference in Texas. However he is only allowed to go if he is speaking. As you may know speakers for SXSW are chosen using a voting system. So, in order for Marcus to attend SXSW he needs your votes. Give an old popstar a second chance. Go vote for him now!
    • Think Vitamin - Finally I just thought I would quickly mention an article I have recently written for the Think Vitamin website. It is entitled "the 5 hidden costs of running a CMS" and I thought you might be interested in check it out. It is an extract from chapter 8 of my book the Website Owners Manual, which as I have said many times before, you can download right now ;)

    News and events

    Designing for emotion and flow

    Not long ago I wrote an article for boagworld on the importance of context. In that article I highlighted elements such as time, mood and environment as key factors that contribute to a users context when accessing your site. This context directly impacts how the user interacts with your site. What I didn’t tackle in my article is exactly how context should affect the way you design.

    An article called "Design for Emotion and Flow" on the boxes and arrows website, takes my post a step further by going into a lot more detail about what affects users behaviour and how we should design in a way that accommodates their state of mind.

    Its quite an in-depth article but worth the read. It touches on user physiology as well as issues of environment and although it can be slightly theoretical at times, it focuses in on what you can practically do towards the end.

    Articles like this always leave me with mixed feelings. They can easily feel overly analytical to the point where you wonder if they are applicable in the real world. However, in my experience if you take the time to read and digest them, they start to influence the way you design on an almost subconscious level.

    7 essential guidelines to functional design

    By contrast our next article is much more down to earth. The "7 Essential guidelines to functional design" is another post by smashing magazine and focuses on some fundamentals of good design.

    However, don’t get the impression that this is just an article for designers. The principles it talks about also apply to developers and website owners. Basics such as the goal and audience for your site are things everybody should be considering.

    According to Smashing Magazine the 7 essential guidelines to functional design are:

    • Consider our product’s goal
    • Consider who will be using it
    • Consider what your audience intends to do with it
    • Is it clear how to use it?
    • How does your user know it’s working?
    • Is it engaging to your users?
    • How does it handle mistakes?

    Whether this is the definitive list, I am not so sure. However, it is a worthwhile read especially if you are just starting out.

    15 companies that really get corporate blogging

    While we are on the subject of lists our next post is "15 companies that really get corporate blogging". What can I say, I am a sucker for a list!

    This one is really for those of you who run a website and in particular run a corporate blog. As the name suggests it lists companies that do a good job at blogging. However, it is not the list that attracted me to this article, it is the reason why the companies got on the list.

    There is a lot of good advice to be gleaned from this post. Just a few snippets I picked up include:

    • Don’t just pimp your products, talk about other stuff too
    • Post regularly
    • Encourage conversation
    • Be candid and open
    • Offer advice and lessons you have learnt

    The list could go on. Corporate blogging is by and large a disaster with many companies just failing to ‘get it’. According to a recent report, 56% of corporate blogs just republish press releases and two thirds hardly ever receive comments. However, as is highlighted in this post there are a growing number of organisations that are doing things right and we should follow their example.

    Learning from signage

    If you have listened to this show for any length of time you will know I am a great fan of looking beyond the web for inspiration. I also believe there a lot to be learnt from other forms of design including signage.

    It would appear that Mark Boulton would agree with this sentiment judging by his recent post on airport signage. Mark, compares the signage in two airports and looks at how the lessons learnt apply to web design.

    Some of the gems he discovered include:

    • Signage should work without colour coding
    • Only designers care about fonts
    • Don’t rely too heavily on pictograms
    • Always put your ideas to the test

    This is a great article which should (if nothing else) encourage you to look at the world around you for inspiration.

    Back to top

    Interview: Johnathan Snook on Adobe Air

    Paul: Joining me today is Johnathan Snook who I recently saw at the @Media conference. It was great to see you there again Johnathon.

    Johnathan: A pleasure to see you there as well.

    Paul: You really got me with your presentation. It was an excellent presentation. Very, very enjoyable, and you touched on the subject of Adobe Air. It wasn’t the main thrust of the presentation, but it was the bit that really grabbed my attention so I thought "let’s get you on the show and have a bit of a chat about it" if that’s O.K. with you.

    Johnathan: Absolutely.

    Paul: Good. So, let’s start from the absolute basics so that we’re all on the same page. Could you just explain very briefly what Adobe Air is so that people that haven’t come across it before kind of know what it does.

    Johnathan: Certainly. Adobe Air is a development platform for making desktop applications to make desktop applications cross-platform. So, something that you build once and that would work on Windows, Mac OSX as well as Linux.

    Paul: O.K. And this is built using web technologies…

    Johnathan: Yeah, It’s really great that they’ve managed to leverage what they know things like Flash, Flex, and really the kicker is being able to develop desktop applications using HTML, CSS and JavaScript that, obviously, a lot of us web developers are going to be familiar with.

    Paul: Sure. So, I mean that’s I guess why we’ve included it on the show even though it’s a web design podcast, that kind of line between the web and desktop applications seems to be blurring and Air is a big part of that. What drove you to kind of investigate it and kind of look into Air as a product?

    Johnathan: For me, it was just a curiosity. The platform, what it could do, knowing that I could create a cross-platform desktop application was kind of enticing. When we build for the web we’re trying to do things as cross-platform as possible make sure that we target as many browsers as we can, and really be able to reach out to the people and do really cool things. So, for me it was like, O.K., well what can I do with this what are the possibilities. One of the first things that went off in my brain was building a Twitter application. At the time, when Twitter was up for more than 24 hours straight, it was kind of cool to be able to build a desktop application to kind of separate out from the web, because the web site was frustrating me to know end, and to be able to put in stuff that made the site more usable for me and in the end was a tool that I got to use every day and that I enjoyed to use.

    Paul: Cool. I’ve kind of got a basic understanding of it. I understand what it does and I understand the kind of technologies that exist under it, but can you kind of give me an idea of, you know, how it works as such. I know how to create an HTML page, CSS and Javascript and stuff like that. How do I get from there into turning it into a Air application?

    Johnathan: It’s surprisingly quite easy. What happens is, if you look at the Air runtime, is it essentially runs your Air application, so you don’t create a .exe file or a .dwg file you don’t create an executable in the traditional sense. What you end up doing is creating a .air file that you use to distribute. The Air runtime actually handles that. Building that .air file, there is an SDK available from Adobe that allows you to compile this Air file. So, those Air files are pretty straight forward, they’re really just like a ZIP file with some extra information in it. So, to create an actual Air application, you can do it just using a normal text editor, you can do with specific IDEs like Eclipse. If you’re into Flex development, they have Flex builder. If you’re into just doing HTML and CSS kind of thing, you might want to look into Aptana they have Air support built right in. If you’re a fan of Dreamweaver, there’s a Dreamweaver extension for automatically compiling your application, and being able to set properties on your application. So, things like how big should the window be when it opens up, can I resize it, what kind of stuff can I do with it. That obviously, in this GUI sense, to a certain degree can make things a lot easier. So, I think there are a lot of benefits to using an IDE with built in support, but you don’t have to. There is the capability of just using a normal text editor and then running the SDK command line sequences to actually generate the Air file. It is really straight forward.

    Paul: So, the one selling feature or one thing about Air that’s been promoted quite heavily is the fact that you can take online applications offline in a sense. The application is still usable even if you’re not connected to the Internet at a particular point in time. I think they showed off, right from the beginning, an eBay example of that where you could do all kinds of things offline, and then when you connected it was all uploaded. How does that kind of process work? There must be some kind of local database that’s running, one presumes.

    Johnathan: That’s correct. I think some people may be familiar with Google Gears in having the local storage using the SQLite database. Adobe Air actually does something very similar. They do have a local SQLite database that you’ve seen create local databases and store any information there. There’s actually different ways. You have access to the local file system, so you can certainly write new files. Say, if you wanted to create new text files, xml files, new binary formats. So, if you wanted to create an image editing software that stores files in a binary format, you could do that. So, there’s a lot of flexibility there because you do have some access to the local system. You have network connectivity, so you can do either regular AJAX calls or you can do socket connections. You can connect to web servers. You can connect to remote database servers. You’ve got a lot of flexibility and a lot of control because of that.

    Paul: You seem quite enthusiastic about the development environment. What has been your impression of it. Was it something that was a steep learning curve, but when you get there it’s really cool, or is it easy straight out of the box? What were your impressions?

    Johnathan: I think it’s going to depend on what it is you’re trying to do. I think that there are going to be some frustrations. There are going to be some things that you have to understand about the environment. To give you an example; the HTML/CSS stuff is pretty cool it basically runs on a WebKit engine, which is the same engine that powers Safari. That gives you a lot of control and stuff, but ultimately that WebKit engine is still running within a Flash runtime. So, there are some limitations to that because of the fact that Adobe just simply hasn’t built in certain support. Things like support for double byte character encoding, so Chinese and Japanese character sets can be more difficult. However, they are working on that. Version 1.1 is supposed to be coming out soon it will have support for that, but right now you’re limited because of that.

    Paul: What kind of people should be delving into this. Is this the kind of thing that only a hardcore developer like yourself should be touching or is it something that somebody like myself that would be a front-end interface designer should I even bother picking it up or am I better keeping away?

    Johnathan: It’s really easy to develop in. I think you can make really quick solutions really straight forward. To give you a comparison; there is a Mac software called Fluid for creating site applications, but that is separated from the browser. You can kind of plot the same kind of things with Adobe Air because you do have that WebKit engine. You can basically use it as a browser. So, to give you a quick example; Muxtape, which is an online mix-taping thing you upload MP3s, and then people can go to your page and listen to your mix tape… The problem is that if you accidentally close the browser, you lose that information. I think there are a lot of websites that have this stickiness factor where you want to decouple the application from the browser. So, I put together a really basic example in which you type in a URL and it loads up a mix tape. That’s a very straight forward interface, but to be able to do that in a desktop application that I can minimize to the dock or the system tray is something that is, I think, a lot more appealing than running this kind of stuff through the web browser. And, it was really easy to put together. I spent about an hour one evening to put that kind of thing … I mean it is a very basic prototype, but the fact is that it is very straight forward to put that together. So, I think if web developers have ideas, they can really take advantage of that and build pretty cool stuff.

    Paul: So, it’s not something we need to be intimidated of, then.

    Johnathan: No, absolutely not.

    Paul: The other thing that maybe is a bit of a concern to us very standards-based designers in comparison to the Flash community is that Adobe says we support CSS and HTML, as well as Flash, but obviously Flash is their product. You kind of get this feeling that they’re going to always support Flash more and that CSS and HTMl are a bit of an afterthought. Is that the case, or is that unfounded?

    Johnathan: To a certain degree, it is the case. It’s, I think, unfortunate. I think they are more familiar with Flash. They’re more familiar with that environment. So, as you try to build the equivalent of a browser within this Flash runtime it’s going to be extremely difficult and I think things are going to get missed. And, I saw that sort of along the Beta process. Things like no support for "undo." I mean, that’s a pretty basic thing, but the fact that that’s not built in there does hamper people trying to build HTML-based applications. It works great in Flash-based applications and then what you end up running into is, to give you another example with Snitter, my little desktop Twitter application because it’s built using HTML and CSS, it had certain limitations, but there’s other Twitter clients built with Adobe Air that were built using Flash that actually have different limitations. So, people would say, "Well this application can do it just fine. Why can’t yours?" You have to kind of explain to them that it’s because of the limitations of how the environment was developed. Despite the fact that they are both still Adobe Air applications, technically they’re done differently and there are maybe more limitations as a result of that.

    Paul: Is there an opportunity to mix Flash and XHTML and CSS and whatever else together, or do you have to make this decision up front?

    Johnathan: No, absolutely not. Certainly, within the Adobe Air environment, you have that flexibility to create these little hybrid applications. I think Snitter, for example, is a good example of it. There’s a lot of Flash components out there that can do certain things. For example, a bunch of folks made an iMap component, so you can actually connect to an iMap server. However, that component is Flash-based. Another component out there that I saw was a Jabber client. So, let’s say you wanted to do a GMail chat client or some other Jabber-connected application, you can import those Flash runtimes into your application and use them from Javascript. So, you do have that flexibility to use both technologies and take advantage of that. I’ve certainly done that with Snitter, and I’ve done that with other applications as well because we have that flexibility of the environment. I think there is that sort of understanding that you can do that, and actually look out for the solutions that not only are HTML and Javascript, but that are Flash-based as well and come up with new ways of thinking because I think, traditionally, as web developers, we tend to separate those two as much as we can.

    Paul: That’s quite interesting. You talked about this kind of hybrid approach of combining Flash and HTML at @Media combining them together and about how we had some fears as standards-based designers of even touching Flash in any kind of context. Is that a kind of approach that you would apply beyond Air to the web generally?

    Johnathan: Absolutely. I think MuxTape is a great example of that. To be able to play MP3s isn’t something that’s easily done using Javascript. However, you can take advantage of Flash and use its capabilities to play MP3s to create new interfaces that aren’t specifically 100% Flash-based; that we have something that’s still HTML and Javascript that interacts in ways that I think a lot of us are comfortable with, but still have access to a lot of features that Flash offers to us you know, the fact that we can create the bridge between the two; we can do that on the web just as well as we can do that within Adobe Air.

    Paul: O.K. That all sounds very interesting and it certainly has made me want to kind of pick up Air and have a play with it and kind of get my hands dirty. I guess, perhaps as the last question then, is what tips would you give to people like me that haven’t yet touched Air and are considering having a play. What are the big traps to avoid? What are the good things to start with. Where should I begin the journey, so to speak?

    Johnathan: I think probably one of the first things you should do is head over to the Adobe web site. They have a number of really good resources to start off with. Obviously, you’re going to need the SDK so you can actually build your applications, but they also have the dev center where they have a number of introductory articles to learn how to build applications and it doesn’t mean those applications have to be built using Adobe applications like Dreamweaver, you can certainly do them without. So, there’s a lot of really good tutorials on there. From there, they lead off to a number of resources outside of Adobe that would certainly help you get started.

    Paul: What about mistakes? What were the big mistakes you made up front that, with hindsight, you would avoid? Or, did you get it right the first time?

    Johnathan: I don’t make mistakes! Well, I think one of the cool things about the environment is certainly the flexibility to take advantage of a lot of advanced CSS. Because you are using the WebKit engine which, when it comes to CSS 3 support, is one of the most advanced, you know that you have support for things like rounded corners, border radius, that you have support for multiple backgrounds, image-based borders you can do some really cool stuff with that that is really fun to play around with. You can create transparent applications, so if you wanted something that was completely and uniquely shaped, you can do these really cool things. The downfall for that is that you can quickly start running into performance issues. If you start creating all of these alpha PNGs that are layered over the top of each other, they give you a lot of flexibility, but unfortunately are a performance drain on how much your system can actually handle. I think that was one of my initial mistakes going in and saying "Wow, I’ve got all of this stuff that I can use let me throw everything at it" and then realizing that, you know, maybe that wasn’t the best solution. I think we still have to be wise in considering how we structure our CSS, how do we structure the design in such a way that, while it’s still flexible, it still does things from a performance-minded aspect so we’re not doing things that are going to unnecessarily slow down or application. Those are things that we’ve got to think about.

    Paul: That’s some really good advice Johnathan. Thank you so much for coming on the show. That was a great introduction to Air. Hopefully it’s encouraged a lot of people listening to the show to go out there and give it a go. Thanks for coming on and talk to you again soon.

    Johnathan: Awesome. Thank you very much.

    Thanks to Aaron Cooper for transcribing this interview.

    Back to top

    Listeners feedback:

    Getting a feel for accessibility

    Our first contribution is from Kenneth and is about accessibility:

    I listen to your podcast all the time and am working hard to become a very good web designer. My question for you is about accessibility, I hear a lot of people talking about it but not a lot of web designers are working hard on it to create sites that disabled people can use. I want to be a person who builds accessible sites that really work. How would someone know if their site is really accessible? How can you feel what disabled people are feeling when they visit your site? Could you talk about the different tools that disabled people use to go online so that we can use those tools and try to understand how they feel.

    Okay. Let’s start by clearing up a minor point. Validation is not directly related to accessibility. Having a site that validates does not make it accessible. Equally, a site that does not validate is not necessarily inaccessible. Admittedly a site that validates is more likely to be accessible, but that is all. It is great you validate your code and you should continue to do so. However, it is okay if your site does not always validate. There are good reasons why Boagworld does not and I am sure the same is true for Clear:Left.

    Let’s turn our attention to the heart of the question; how can you better understand the experiences of disabled users? It is an admirable aim but one that ultimately is impossible to achieve. There are so many different types of disability that you cannot associate with them all. That said, I can make a few suggestions which might help.

    A good place to start is by trying out a screen reader. Increasingly screen readers are bundled with operating systems. Recent versions of Microsoft Windows come with a basic Narrator, while the Mac OS includes a more feature-rich screen reader called VoiceOver. However, the most widely used screen readers are the separate commercial products like JAWS for windows. This is probably a good place to start as JAWS offers a free trial version for you to experiment with.

    However, be warned. When you first use a screen reader it is an intimidating experience. They take a lot of getting used to and can leave you with the impression that a blind person will never be able to use the internet. An alternative would be to watch a demonstration of a screen reader in action. Ian Lloyd did an excellent demonstration for Boagworld a while ago.

    Of course not all visually impaired users are blind. Some use screen magnifiers which enlarge screen content. Again, most operating systems have this functionality built in so you can easily try this for yourself. However, there are also a number of commercial products you can try out too.

    The other form of visual impairment worth investigating is colour blindness. Although not as serious, it is far more common and affects a large number of users. There are a couple of tools which will give you an idea of what a colour blind person is seeing. The first is Colorblind Web Page Filter which allows you to enter a url and see what that page would look like to a colour blind user. The second is Sim Daltonism, a colour blindness simulator for the Mac OS. Both will help you better understand what the web is like for colour blind users.

    The final little tip I want to share with you is kind of stupid but does sort of work. I do a lot of design for the elderly and they often suffer from a mixture of visual problems and motor issues (like arthritis). In order to better understand their experience I have bought a pair to ski gloves and some reading glasses (I don’t need reading glasses). Every now and again, I surf the site I am designing wearing both the glasses and gloves. The glasses make the screen hard to read while the gloves hamper my use of the mouse and the keyboard. There is nothing more frustrating than trying to select something from a drop down menu wearing ski gloves!

    Turning problems upside down

    Our second listener contribution for today is not a question but a tip. It comes from Jeremy and he writes:

    I can’t remember the name of the book off the top of my head (Getting Things Done?) that you’ve been recommending, but you mentioning it reminded me of a problem solving method that I learned a few years back that I thought you might enjoy. It’s called turning the problem upside down. It sounds stupid, but honestly it works pretty well.

    The principle behind it is if you can’t figure out a solution to a problem or are having trouble coming up with different ideas, you turn the problem upside down, or invert it, and then come up with solutions for the backwards problem. For some reason it’s much easier to think of the backwards solutions. Then you flip them back to normal and there are your solutions. Sounds confusing, so here’s an example:

    Problem: You want to increase traffic to your website

    Turn the problem upside down: You want to decrease traffic to your website

    Some ‘off the top of my head’ Solutions:

    • Make the site unfriendly
    • Randomly shut it off
    • Never update anything
    • Be rude
    • Keep key content hidden or difficult to find

    Now let’s flip the solutions back again and see if they solve the original problem:

    • Make the site more warm/friendly
    • Make sure it stays up reliably
    • Be good about frequently updating content
    • Be aware how of my copy and if I’m talking down to my visitors
    • Make sure the good content is easy to find and prominent

    What a great little tip! Excellent when you are suffering from creative block. I love it when you guys send in suggestions rather than questions. I know from the forum that the boagworld audience is hugely experienced and its great when you share that experience. Keep them coming!

    Too many content management systems

    I know we live in a capitalist society. I know we are supposed to believe in choice. However, there are just too many damn content management systems. Another extract from the Website Owners Manual

    Let’s face it, most content management systems look the same there days. They all offer very similar functionality. After all, most people want similar things. Once you have narrowed the field by price it can be hard to make the final decision.

    However, functionality and price should not be the only criteria by which you make your judgement. There are a number of additional issues which need considering. In many ways these are just as important.

    These include:

    • Licensing
    • The development team
    • Security
    • Accessibility and code quality
    • Documentation and training
    • Support
    • Community

    We should begin by looking at the subject of licensing.

    Licensing

    Examine in detail the license attached to your choice of cms. It is not uncommon to find licenses that state you can make no change to the source code or use a alternative developer.

    You may also find that licensing is per site or worse still per user. This can become very expensive if you want to setup multiple sites or have a large number of content contributors.

    Ideally you want an agreement that allows unlimited use of the cms with the exception of reselling.

    The development team

    Look carefully at the development team behind any cms you are considering. For example is it an open source project with a community of developers or the product of a single company?

    Neither approach is wrong. However you need to be confident in the long term health of the product.

    Open source projects can be highly productive despite often being created by volunteers. That said, they can die off quickly if a more attractive project comes along. If you are considering an open source solution look at the age of the product. Mature products are more likely to remain supported in the long term.

    With a commercial product you need to be confident in the long term viability of that company. Consider requesting a copy of their accounts to confirm their financial stability.

    In both cases look for a team that are regularly releasing updates to their system. This is particularly important from a security perspective.

    Security

    Security is an important issue for any content management system. If your site is hacked you could loose content and find yourself in litigation if hackers get hold of your users personal data.

    Judging the security of a content management system is not easy unless you have technical expertise. If unsure, get an experts opinion. However at the very least you can do a google search on the name of the cms and ‘security issues’. If you see lots of results then you will definitely want an expert opinion.

    Accessibility and code quality is another important, and yet hard to judge, issue.

    Accessibility and code quality

    As we established in chapter 7 it is important to build using the latest best practice. This ensures your site is accessible and provides the flexibility to adapt over time.

    Judging whether a content management system uses best practice is difficult if you are not a web designer. However, talk to the cms developers about their approach to accessibility. Equipped with the knowledge from chapter 7, you should be able to get an indication of their competency.

    One aspect of best practice we have yet to discuss are webpage addresses. For a long time content management systems produced addresses that were hard to read. For example:

    http://www.boagworld.com/index.php?sourceid=navclient&q=4

    However, more recently content management developers have realized this is hard to read and damaging to search engines placement. Therefore modern content management systems produce addresses that look more like this:

    http://boagworld.com/technology/friendly_urls/

    This is a huge step forward and also allows the web address to be used as a navigational tool. Users can identify where they are in the site and even edit the url to find different pages. For example if the above address is shortened to:

    http://boagworld.com/technology/

    it will return all pages within the technology section.

    Whenever possible look for systems that support friendly urls. They are a good feature to have and provide an indication of how up-to-date the practices of the developers are. If a cms supports friendly urls they probably support accessibility and standards too.

    Additional information on best practice should also be made available through the documentation that supports the cms. This too is an important differentiating factor.

    Documentation and training

    Good documentation is a crucial component of any cms. As I have already said, content providers may not be using the system on a daily basis. They can easily forget how it works. Documentation should therefore be comprehensive and easy to use. Some content management systems also provide walkthroughs and video tutorials. These also help users understand how the system operates.

    There should also be documentation for developers too. This will enable your web team to adapt the cms to better suit your needs. Without this it can be nearly impossible to work out how the cms works.

    Alongside documentation, training is another useful resource. This is important for content providers who need more than a manual before they start using the system. Training provides them with hands on experience and the opportunity to ask questions.

    No matter how good the cms and supporting documentation, there are occasions when you will require additional support.

    Support

    You need to ask some hard questions about support. What happens if you identify a bug in the content management system? Will you be required to pay for the fix? How fast can you expect a response? Do you require 24/7 support?

    You need to know your requirements and have a good understanding of what the cms provider can offer.

    Beyond fixes, there are broader questions about help. If you have a problem with the system is there somebody you can turn to for advice. Do you have to pay for this support and when is this support available?

    Of course not all content management systems come with support. It is unusual for anything but enterprise level systems to offer this option. If it is not available you need to look at whether the system has a vibrant community.

    Community

    The community is made up of other individuals who use the cms. They share advice and experiences via forums, mailing lists and support sites. Such communities are particularly important for open source content management systems because these products rarely offer formal support and training. However, many commercial products also have excellent online communities.

    A good community will be able to answer questions, offer support and even make available a range of plugins that can be used with your cms. Before investing in a cms ensure it has a vibrant community. Visit the support site and look at how many users are registered and how often they post. Examine the kind of topics people are discussing and particularly how supportive they are to new users. It is not unusual to find apparently vibrant communities that are hostile to new users asking ‘dumb questions.’

    For more from the Website Owners Manual and early access to chapters as they are written go to the books website.

    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!

    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.

    The more I consider context the more I recognise its impact on every aspect of a website. Context affects design, usability, accessibility and content. Its influence is profound, and yet it is largely ignored by many web designers.

    But what is context when applied to a website? Its actually hard to define. It is easier to think in terms of the users context while access your website. Understanding this context affects how you design a site.

    We put a lot of emphasis on user centric design. We believe that understanding users is important. For example, we believe in carrying out user testing. However, think for a minute about the way we do this. We bring the user into an artificial environment (such as a usability lab). We remove them from their normal context.

    Equally when we create personas they focus on demographics (age, sex, job etc) rather than their context. We miss a crucial part of the jigsaw.

    So what is the users context? I have identified 5 aspects that form his or her context. These are:

    • Environment
    • Device
    • Comfort
    • Mood
    • Time

    Let’s look at each of these in turn.

    Environment

    Environment refers to a number of factors including location. The kind of information a user wants to access is dependant on his or her location. For example somebody planning a weekend break using their PC at home, will want information on hotels and attractions. When they are actually on their break and using their mobile phone, they are more likely to want information on the nearest pub or the opening times of a museum they want to visit.

    Location does not just affect content. It can also affect design. Viewing web content outside will mean battling with sunlight and so high contrast is required. Alternatively, you do not want to be dealing with fiddly form elements while being jostled at a train station.

    However, environment is not just about location it also includes distractions and surroundings. For example a mother of three toddlers may find it hard to concentrate on a complex survey, with the children demanding her attention. Equally a user accessing the web from a library is not going to appreciate audio suddenly playing on your website.

    Environment also defines the type of device we use to access the web. This is another aspect of context.

    Device

    Although location and the device often go hand in hand (you tend to use a PC at home and a mobile while out), this is not the only affect device has on context. The device also determines the input methods available.

    Few mobile phones come with QWERTY keyboards. None come with a mouse. You can access the web via games consoles like the wii. These generally rely on gamepads, remotes and on screen keyboards.

    Different input devices should radically affect the user interface. Not only do each of these devices alter how you interact with the system, they also alter how you view the information.

    Typically PC users are sitting close to their monitor and viewing at relatively high resolutions. Games consoles are normally attached to a TV where you sit much further away and the resolution is lower. Mobile devices have a lower resolution still and the viewing position is different again. This all affect the design of your website.

    Talking of viewing position, the other factor that needs considering is the users comfort.

    Comfort

    How physically comfortable a user is affects the length of time they will interact with your site. Although you cannot know whether your target audience is comfortable or not, sometimes you can make an educated guess. For example, if you know your users will be accessing your site via a kiosk in a shopping mall, they will probably be standing and not stay long.

    Comfort is to a large degree dictated by environment but not entirely. It can also be dictated by physical conditions. If you are launching a site aimed at those who suffer from back pain or weak bladders, do not expect them to spend a long time on your site!

    In some ways comfort is also closely linked to our next factor, mood.

    Mood

    There is no way we can predict the emotional whims of our audience, but they do have an affect on attention span. Those who are busy or stressed get irritable with a site quicker. They are likely to give up and walk away. Conversely those who are relaxed muddle through and are more tolerant of bad design.

    It is important to consider the likely temperament of your users. For example, business executives are likely to be less patient with a site than a pensioner siting in his villa in the south of France.

    Environment, device and comfort can all have an impact on mood. However, the biggest influcening factor is time.

    Time

    It is obvious that the time available to a user affects how long they spend on a site. However, we often do not take this into account when designing a site. Unnecessary form fields and key content buried deep within your site, are just 2 ways we ignore the time constraints users operate under.

    Online banking is a good example. It is so complex to login to my account that it is quicker to pick up the phone. With time being a valuable commodity users will often choose a competitors site because they can get things done faster.

    Of course, in reality there is a lot of overlap in these facets of context. However, I have yet to read much about context that isn’t directly related to mobile devices. Hopefully I have demonstrated that context applies to all the work we do and not just to mobile websites.

    Lessons from the O2 failure

    I don’t want to start ranting about the debacle that was upgrading via the O2 website, from my iphone to the iphone 3G. However, there are a couple of things we can learn about good site design from their mistakes.

    Like most of the British population (or so it seemed) I tried to upgrade my first generation iphone for the new iphone 3G. Following the instructions I received from 02 I went to their website and then spent the next 2 hours battling to place my order. This horrendous experience raises some interesting points.

    • Load test - If you are expecting shit loads of people to hit your site at the same time then run some loading testing against it!
    • Don’t cause a panic – Announcing there is limited stock and that you are going to sell on a first-come-first-served basis is going to cause a rush.
    • Provide alternatives – Don’t force users into only purchasing through a website. Allow them to purchase via phone or store too.
    • Keep it simple – The whole process could have been streamlined. Adding a text message as a method of authentication was unnecessarily complicated and caused problems.
    • Avoid AJAX – On a site that is going to be hit by heavy traffic, avoid using unnecessary AJAX. It was impossible to jump to the appropriate place in the process. Instead I was forced me to start from scratch each time the page hung.
    • Use cookies – By using cookies they could have saved me considerable time entering my information again and again.
    • Clear messaging – Despite completing the process I am unsure of whether I have an iphone coming or not. The site needed to make it clear whether an order had been successfully placed.
    • Error handling – When things went wrong with the site it didn’t respond elegantly. Some carefully written messages could have cleared up a lot of confusion.
    • Better labels – One label asked me if I wanted a bolt on package. It didn’t explain what that package was or what answer was required. It just gave me a blank text box. What was I supposed to type into it? Should I leave it blank? Why was it a text box and not a dropdown menu? Was this the reason my submission was failing?
    • Email confirmation – It would have been nice to receive an email confirming or rejecting my order.
    • Waiting list – For those who failed to place an order before the product ‘sold out’ there should be an alternative. Never turn a customer away. Either offer the chance to pre-order with an estimated delivery date or at give the change to register to be informed when new stock arrives.

    Update: Alex made some excellent additional points in the comments and I wanted to mention them here too. He added to my already extensive list:

    • Get a CDN or virtual servers – If you’re expecting a lot of traffic in a short time, look to share the load. Think about placing your critical functions (such as an online shop) onto a platform that allows you to deploy additional servers on demand (often called Virtual Private Servers) – such as Amazon S3 or similar. If you can’t change onto something like that – you can still help your server by moving images, CSS and javascript onto another server, or even a CDN. A Content Delivery Network (CDN) is a network of servers that contain copy of your key files to help spread the load.
    • Have a backup plan (or have two!) -
      If you have something really high-profile, have a backup plan, or two! In this case, O2 DID have a back-up plan… they had a ‘failover’ site… which was a simple one-page form to take down customers details. The only problem was it didn’t work when it needed too… it failed too!
    • Brief your call centre -
      Knowing that some customers were likely to experience trouble accessing the site (or even just getting confused placing an order), you should make sure that you brief your call centre staff – put on extra staff and make sure that they can take orders too, and know what to do.
      When I called O2′s customer services, they couldn’t offer any help as ‘upgrades were online only’. Additionally they couldn’t check if my 3 times I put my credit card details in were registered (they weren’t as it happens).
      If all goes wrong… the call centre is your last line of defense, and O2 dropped the ball here too.

    Update 2: Well, the iPhone 3G has now launched in the UK and O2s website continues to fail users. This time Apple was forced to turn away customers from their stores because they were unable to register them with the O2 site. The reason why: The O2 website would only work in Internet Explorer. This provides us with yet another lesson to learn…

    • Build for your audience – Consider who your target audience is and what requirements they have. In particular consider their accessibility need to make sure you never turn away people wanting to give you money.

    All in all it was badly handled and I am pissed off. Can you tell!

    124. HTML 5

    In this weeks show we explore how to create better online surveys and Lachlan Hunt joins us to discuss HTML5

    Download this show.

    Launch our podcast player

    Watch the behind the scenes video (Part 1)

    Watch the behind the scenes video (Part 2)

    News and events

    Removing Microformats

    The story that has generated the most email this week is the BBC announcement that they will be dropping the hCalendar Microformat. This decisions comes because of long standing accessibility concerns over the machine readable content within that particular Microformat. The problem is that code meant to be used programatically is potentially read out to screen reader users and displayed as meaningless tooltips to sighted users.

    The decision of the BBC to adopt Microformats was a huge boost to the movement. Equally the rejection the hCalendar is a blow. However, it is important not to get this out of proportion. Remember, they are only rejecting a single Microformat not the whole approach.

    The other thing to consider is that the BBC is a public service organisation with an incredibly high obligation to ensure maximum accessibility. In many ways they are in a unique position. Although it maybe appropriate for your organisation to pull hCalendars too, it should not be based on the decision of the BBC.

    My advice is as follows. If you already have hCalendar information on your site I would probably leave it (dependant on your exact circumstances). The Microformat community is working on a solution and I would implement that rather than removing hCalendar entirely. If however, you are not yet using hCalendar then I suggest you hold off until an updated specification is released.

    Becoming employable

    In the past we have spoken about becoming a professional web designer. I know that many people who listen to this show or read the blog are students. You are concerned that the skills you are being taught are out of date and will not improve your employment prospects. How then do you become a more employable web designer? What skills do you actually require?

    Andy Rutledge tackles this subject in his post "the employable web designer". Without a doubt it is the best post I have read on the subject of web design career development. I highly recommend you read it.

    The thing that impresses me is that it looks beyond the obvious design and technical skills required to be a web designer. It also tackles the business and communication skills too. He really drives home quite how wide an understand a good web designer has to have.

    My only criticism is that it could feel demoralising. You may read the list and think it is an unachievable aim. However, I don’t think that is the case. What Andy outlines is the optimal requirement of a web designer, rather than what is needed to get your first step on the ladder. I certainly did not have all of the attributes listed when I started.

    All we need now is a second post telling us how to gain the skills he lists.

    Better CSS font stacks

    David (a boagworld listener) sent in the next story. It covers a subject that I am currently still grappling with. It is a post about CSS font stacks.

    If you code in CSS you already know about font stacks. It is where you specify the fonts you wish to use. You can say for instance; use Helvetica and if that isn’t available use Arial. If that fails use a generic san-serif font.

    For many of us that is as far as our thinking goes. The majority of us use very basic font stacks that are uninspiring to the point of being insipid.

    I love this post because it lays out a very clear methodology for improving your font stacks. It also goes on to provide an impressive selection of font stacks organised into heading and body fonts, allowing you to instantly improve your site

    If your site is looking tired and boring, but you don’t have the time to redesign, consider adding a new font stack. Such a simple change could make a real difference.

    Do flexible layouts still matter?

    Our last story of the day is a post from Smashing Magazine entitled Flexible Layouts: Challenge For The Future. To be honest I was ensure whether to include this post or not. On one hand it covers an issue many people have been asking me about. On the other, its arguments seem stretched and the whole thing ends with an advert for a CSS framework.

    The article tackles zooming and fluid design. The new generation of web browsers – Firefox 3, Opera 9.5 and Internet Explorer 7 – provide full screen zooming. This gives users has the ability to enlarge the whole interface, not just text. Some are arguing that this is the end of fluid layout because zooming tackles many of the accessibility concerns associated with fixed width sites. However, this article strongly disagrees.

    The author argues that flexible designs are better for mobile devices, that pixels are becoming less important and that the user shouldn’t be required to customise a site to their needs (it should be done automatically). Although his arguments are weak at times and he uses some fairly dodgy comparisons I do generally agree with him. I see no reason to think fluid design will go away anytime soon.

    That said, I am in no doubt that page zoom does reduce the number of occasions fluid sites are necessary. Ultimately there is no right or wrong answer. It is entirely based on the situation. For example Boagworld, Headscape and The Website Owners Manual all use fixed designs. However, many of my client websites do not. That decision is based on numerous factors such as device, user base and business priorities.

    Back to top

    Feature: Creating a Better Survey

    The web allows us to interact with our customers more than any other medium. One of the tools in our arsenal is the online survey. However, these are often badly implemented. In this weeks feature we find out how we make your surveys more effective?

    Back to top

    Interview: Lachlan Hunt on HTML 5

    Paul: Joining me today is Lachlan Hunt; It’s good to have you on the show

    Lachlan: Thank You Very much

    Paul: It’s great to have you here I really appreciate you taking the time to join us, now the reason that we asked Lachlan on the show is because he posted a brilliant article on the A List Apart site about the subject of HTML 5 and I have been keen to look at this subject for a while partly because of my own ignorance to be honest, um, so lets kinda kick off by if you could perhaps tell us a little bit about where HTML 5 is at the moment I know that kinda getting a language to a release like this finalized is a massive process so can you tell us where we are at in that process.

    Lachlan: OK, it’s, um, a really an ongoing process with browsers implementing different parts of it progressively so it’s not, you know, going to be all implemented at once and ready to go in one, er the next few browser implementations. We have some features implemented already and shipping in browsers other features which are being worked on at the moment and other are planned for, but still a few years of yet. But it is gradually getting there. We are trying to focus on what authors really need, instead of trying to do it all at once

    Paul:Ahh, okay so that a slightly different approach that we have seen in the past, the idea of an incremental roll out. So how does that work from the W3C’s point of view are they doing modular releases is that how it works

    Lachlan: Um, at the moment no, but the way the spec is structured each part of the spec, what I am trying to indicate is the stability of each section of the spec as we go along. SO thing like the Canvas API which has been in browsers for a few years now, it should be getting to IE very soon. That section is pretty stable, Other things for example "data grid" or a lot of the web forms are not widely implemented.

    Paul: OK so that quite an interesting approach to the problem I guess from what you were saying earlier to me there is a community base element people can get involved and contribute. How is that all working then?

    Lachlan: Well we’ve got a REALLY REALLY open mailing list on whatwg.org anyone can subscribe at the moment there wa about 800 subscribers on that list anyone is free to subscribe and post feedback about the spec if they want to, but that’s not for everyone obviously because it’s quite a high volume mailing list and not everyone can keep up with that. We have also got an open blog on http://blog.whatwg.org/ where absolute anyone who wants to can write an article submit it and have it published. Anything to do with what the WHATWG are about, HTML5 and anything related to it at all. It’s also a good way to let the community know what’s going on by publishing articles also to find out what people think because they keep posting comments on there as well. We have also got an open forum which is at http://forums.whatwg.org/ again anyone can subscribe to that, am sue you know how a forum works

    Paul: So there are lots of different ways to be involved, I have to confess things like that can feel quite intimidating to get involved in. You’re kinda worried about putting your foot in it, and saying something really dumb, is there kind of Opportunities to lurk and are people fairly friendly over there? I guess you are going to say yes aren’t you

    Lachlan: Yeah everyone is friendly over there,they are nice sort of area to go to aim at web developers and people who aren’t quite as technical with the spec areas and stuff. You can ask any question you want and just learn whatever you want as well. Their is also the w3c side of it as well. Which is strictly related but is more focused on the actual technical side and issues so yeah. The What WG and the W3C are both publishing exactly the same spec and they both work on it together and feedback can be sent to either place, it will all be taken into account

    Paul: Oooh, that’s useful. So looking at kinda the state of affairs at the moment with HTML 5, reading through your article there was some things in there that really sounded quite exciting, there was this thing about structure and some kind of additional elements that could be used, which provide a little bit more structure, headers and footers and things like that can you tell us a little about that, and maybe explain a bit of what those do.

    Lachlan: Well at the beginning of the work back in 2004 / 2005 we basically took a look at what a lot of site where doing and we noticed that they were all using a similar structure. All the blog’s were using headers and footer and generally things like column layouts to show articles and stuff like that. So we wanted some semantic elements to come and cover each of those features that people actually used, solving the real problems that they were actually focusing on. instead of having to do "Div" elements for everything, which is what people do we give them an actual element and that also has a side effect of increasing accessibility because an element with specific semantics can be hooked into the accessibility API’s and help someone with assistive technology navigate the document a bit easier.

    Paul: Okay, because I mean reaction just glancing at it quickly and not thinking about it was what’s wrong with the div with an ID Equals footer, or an ID equal header or whatever but like you say, as you think about it more it become obvious that if those are considered distant elements, one person might call it a footer another might call it "the bottom" or whatever else if they have consistent semantic names then you know you can have screen readers and stuff jumping to the footer or avoiding / not reading the footer depending on what is set in their preferences, is that what you are thinking?

    Lachlan: Yeah that sort of it, it’s also helping the authoring side too, as there are lots of Div elements in source code which makes it easier to read if you have got elements with different names

    Paul: yeah very much so, I spend half my life trying to which closing Div relates to which elements, that very exciting. Obviously the other big area you talk about in your A List Apart article is the audio visual elements and there is a lot that’s happening in there. It’s always had the vague feeling that HTML has never had any kind of, erm, erm, the audio visual elements have always been and after thought, what happing in HTML 5 in regards to that?

    Lachlan: Well we have added the video and audio elements to the spec to try and allow video to be added directly to HTML, at the moment we have sites like youtube revel and all the other video site out there using flash to embed video and using the flash to give customized controls and stuff to the user, it’s really awkward, depending on proprietor technology, so we want to open that up a bit give a very very easy to use Javascript API to hook into and promote custom controls and all sorts of cool stuff with videos and of course audio as well. We have got experimental implementations of that in opera and in webkit. I have heard mozilla is considering implementing it as as it is now I am not sure of the status of their implementation. However the one big problem with video and audio at the moment is with Codecs, there are a whole load of software patent issues going around and we are not quite sure what codec we are going to standardize upon or if we are going o be able to get common codec support among the browsers, That’s an open issue but I am no lawyer to I cannot really go into that, so the ultimate aim is that you will be able to embed your movie file, your avid file or whatever directly into the HTML without the need to kinda pump it through something like flash

    Paul: cool

    Lachlan: that make it a whole lot easier to the authors hopefully

    Paul: Yeah, you kind of, to some extent got to ask the question why do we need that when we have got a solution like flash

    Lachlan: Well because Flash is a proprietary technology it’s managed only buy Adobe , they control it, they control the changes and what does and what does not go into future versions of it, however the thing with HTML is that it is an open standard platform which can be implemented by anyone and maintain interoperability between those venders.

    Paul: It’s intrusting isn’t it that adobe has just announced they are opening up the flash format, do you wonder if that’s a reaction to some of the stuff you have been doing to kind of force their hand if they want to stay ahead o the game and dominant they need to be open

    Lachlan: Yeah I don’t know how that going to work though, it depends, if they open the format up and actually make it an open development process where anyone can contribute to the future version and features which go into it or whether they just write the specs and tell other people to implement based on what they write, so I don’t know much about that. It will be interesting to see how it goes.

    Paul: Very interesting, Now the next thing you cover in the A List Apart article is something which you titled "Document Representation" now I have to confess this confused me, so do you want to explain a little about what you meant by document representation. What you were getting at there.

    Lachlan: Yeah, well in the past we have had HTM, and XHTML with two separate specs, HTML 4.1 which a lot of people use and XHTML 1.0 which a whole lot of other people use one of them is based on XML and is really really strict syntax that requires well formedness and is supposed to when you serve it correctly, if you make a well formedness error the browser is suppose to stop processing and throw and error message saying "Sorry I cannot handle this" where as HTML is more sorta loose and convenient in its error handling, it’s the traditional inspired by SGML, although really only syntactically similar these day but the error handling is a bit more lenient and you can get away with making a lot more errors. So instead of having two distinct language which you can use we have combined them into a single language which share the same elements and attributes and everything and as much a possible and when the browser reads those file it produces and internal representation called the DOM, a lot of javascript user will be familiar with the DOM as they work with that with their scripts to modify the document through the DOM. That’s an internal representation which is mapped, the DOM which is sort of mapped to by the syntax’s, the HTML and the XHTML syntax’s so it give the authors a choice of which syntax they want to use

    Paul: So why do we need that choice what is the key difference, I mean you talk about HTML being more lenient are there other reason for choosing one over the other.

    Lachlan: erm, well I don’t really know. However a lot of authors do prefer the strict syntax of XHTML like to make sure they quote the attributes and encode all their ampersands properly. They like to know they have done everything perfectly as with HTML a lot of people do make mistakes inadvertently and don’t want end users to see big error messages, so it’s a bit more user friendly if some little small error slips though their CMS and causes problems.

    Paul: So it’s basically come down to personal preference then

    Lachlan: yeah

    Paul: Okay, that’s fair enough, so both, we are going to see equal support for both of them in browser manufacturers are we

    Lachlan: Well that’s the hope we have said that we have got good support in most browsers, it’s just IE which is lagging behind

    Paul: (Sarcasm) Oh that’s a suprise (Laughs) Okay are there ant other things in HTML 5 that might be of interest to those listening to the show which we should be paying attention to?

    Lachlan: erm, well, as I said before we got canvas implemented in most browsers

    Paul: So tell us, what’s canvas

    Lachlan: It’s a 2D drawing API that you can use javascript to draw dynamic image with. People have used it to implement things like graphs that are built using tables of data which are on the page. People have also gone and done 3D games with it which is really cool

    Paul: Wow, that incredible. I mean that sounds very similar to SVG is it a different thing.

    Lachlan: It is different SVG is entirely done with XML, you modify that with script via the DOM by changing elements and attributes and stuff or with CSS. Canvas is an immediate mode graphics API where it is more like a bitmap sort of thing where as SVG is vector graphics, and canvas is bit map. They can both do images, the same sort of images, if you like but we have both vector images and bitmap images, so they both can serve different purposes.

    Paul: Right, I see. Okay that’s good, so okay the big question, kind of the final question everyone is going to have is when can they start doing some of the cool stuff. Now you said right at the beginning this is going to be modular support based thing so we are going to be able to see some of these elements before others. You know some parts before other, so what can we do now, what are we going to be able to do soon give us an idea of where things are at.

    Lachlan: erm, okay let’s see I think what’s being implemented at the moment. Cross document messaging is being implemented at the moment, that’s an API that lets you send message between documents with javascript without worrying about cross domain security issues,

    Paul: Oooo…. that’s good.

    Lachlan: Yeah it’s a really, really handy API that been implemented in opera for a while and I heard mozilla is implementing it soonish and should be in firefox 3 thought I am not entirely sure about that. That should be very very soon, erm, what else have we got, we got…. hmmm, this is tough

    Paul: Sorry put you on the spot there (laughs) is that last one supported in webkit?

    Lachlan: erm, I am not sure I would have to double cheek that

    Paul: Okay that’s fair enough

    Lachlan: yeah,

    Paul: Okay so any other elements? Things like the structural changes are any of those being supported yet?

    Lachlan: Not quite yet, erm as far as I know support for those requires changed to the phaser, and to implment the new pharsing algorithm in HTML 5, as far as I know browsers are not yet focusing on doing that because..

    Paul: Okay that’s a shame, because that one I liked the sound of, what about the audio and the visual stuff?

    Lachlan: We have experimental implementations in opera which supports OGG video, though it’s not really in a public build version yet, there is a experimental version which was released last year sometime. And webkit also has support in their nightly builds, which supports mpeg 4 unfortunate they don’t support the same codec but you can experiment with them.

    Paul: (laughs) That would be far to easy

    Lachlan: yes I know

    Paul: So it’s all progressing slowly but, erm you know obviously the one name which has been very absent in the list you keep mentioning is Internet Explorer, so I expect we can probably see some slower movement there. We are talking you know in the years before this all becomes mainstream and we can actually start using it. Is that a fair comment to make?

    Lachlan: Yes it will be several years before the entire spec is finished, we are hoping that it can get finished sooner rather than later but realistically it’s going to be quite a while yet, But it is important to know people will be able to use theses features before the spec is finished; so it depends on when browsers start supporting features authors can go ahead and use it.

    Paul: That’s great and real exciting that you can start to do that sort of stuff. you know that we don’t need to wait for it all to be set in stone before moving forward. And it’s always exciting as well to see the future, know what coming up and be aware of everything. so is there somewhere people can go a websites address and keep an eye on what is currently supported by browsers.

    Lachlan: Not at the moment but that’s something worth looking into, I think there is a wiki on the Working Group site, it does have some implementations listed but I am not sure how up to date. But it’s something I think we should look into

    Paul: Yeah it would be great to have some kind of single page which says what features are supported by each browser that you could check back every few months see what’s going, there you go there is my contribution to the working group (laughs). Alright it was really good to speak to you and thank you so much for your time, What we will do is to get you back in further down the line and have a check to see where we have currently got to in the development of HTML 5, Thank you so much for your time.

    Thanks to Jamie Knight for transcribing this interview.

    Back to top

    Listeners feedback:

    Staying healthy on the web

    Evan writes: My question to you is not entirely related to design, development or management but rather about health in the web industry. This is very important but we often seem to forget about it. We spend hours upon hours at our desks but are unaware of the damage this could be having on our health. Eyeballs almost touching the screen, typing without a break, sitting incorrectly – just a few examples. So, what do you do to maintain good health while working?

    I am possibly the worst person in the world to answer this question. I consistently abuse my body while at work. In fact a physiotherapist friend said I had the worse posture in front of a computer she had ever encountered.

    However, there is possibly something to learn from my terrible example. Let’s look at what I do and compare that to best practice.

    • I sit with my leg tucked up under me – Posture while working is important. Both feet should be flat on the floor, rest your wrists on the desktop in front of your keyboard and make sure your monitor is at eye level (in other words avoid laptop screens).
    • I stoically refuse to use anything other than my preferred mouse and keyboard – Using the same keyboard and mouse in the same position day after day can cause damage. Try using a variety of different hardware and positions. Push your mouse and keyboard nearer or further from you to change the position of your arms.
    • I believe that an individual pixel should fill my field of view - Leaning too close to your monitor is a particular weakness of designers who want to position that pixel ‘just so’. This not only damages your eyes but also your back. When you learn forward your neck and back support the weight of your head. When sat upright, the head is supported by a straight spine and therefore your chair bears the weight.

    On the upside I do take regular breaks. I would like to claim this is because of my health. However, I think it has more to do with my short attention span. I get easily distracted and wander off to do something more interesting.

    From Photoshop to HTML

    I see a lot of PSD 2 HTML services on the internet but never tried any out. It seems to be an great option for an designer for making an quick website, to edit later myself.

    What is the opinion of you guys? Love to hear you discuss this topic in one the next podcasts.

    An long time listener from Holland.

    I have to confess to being a snob over these services. Until recently I have always doubted the quality of the code but after seeing some recent examples I have begun to change my mind.

    We are even considering giving them a try at Headscape, just to see what happens. Certainly from an economic point of view they make sense especially if you have more work than you can handle. That said, I do have three concerns.

    First, results may vary. Without a personal recommendation it could be hard to find a provider who can produce the quality you require. Anybody can convert a photoshop document into HTML. However, it is much harder to do so using techniques like microformats, semantic markup and accessibility. Also, just because the quality was good once, does not mean it will be so again. As the good providers get busy it can lead to a decline in quality.

    Second, people code in different ways. Unless careful attention is given to commenting, it is hard to pick up somebody elses markup. This is fine for relatively static sites where only small changes are required. However for projects where change happens regularly as the site evolves, it is more important that the markup is tailored to your style of coding.

    My final concern is that this could lead to designers not learning HTML. As I have said before on the show, I believe all designers should be able to code themselves. You need to understand how the web works and markup is apart of that. Also, if you cannot code how can you judge the quality of the markup you receive?

    Back to top