Stop Using Stock Photography Clichés

I am sick of stock photography. We should refuse to use one more photograph of business men shaking hands or ethnically diverse people laughing together.

It is time to draw a line in the sand. 2010 needs to see the demise of bland, insipid photography that are the equivalent of using IBM blue.

Like IBM blue, certain stock imagery has been so overused that they have become meaningless. It conveys no information of value and carry no positive emotional message. Take for example the website below:

The WellDyne website features a photograph of two businessmen shaking hands

The image provides no clue as to the nature of the website and appears to be little more than a placeholder to fill up space.

The only reason to resort to such hackneyed clichés is lazinesses. A designer has literally millions of gorgeous images available to them online and should also be capable of producing unique imagery of their own.

This lazy approach was summed up perfectly in the design below. The designer was so lazy he did not even manage to purchase the image (see the watermark from istockphoto).

Website using an unpurchased image.

The alternative

Don’t misunderstand me. I am not writing this with a sense of superiority. I have been just as guilty of falling back on clichés as anybody else. After all, when time and budget is limited, you don’t have the resources to commission your own photo shoot!

However, just because you are forced to use stock photography does not mean it has to look terrible. There are several techniques that can help avoid clichés even when time and budget are limited.

Use Illustration

Increasingly websites are using illustration instead of photography. Even stock illustration often conveys more character and personality than your average piece of stock photography.

The style of illustration used says something about the website and organisation behind it. Illustrations make a statement and do not necessarily need to appear childish, as many clients fear.

Hull Digital Live

Safarista Design

Image based on Soviet Russian style

Image of comic fish

Better integrate

Even when you choose to use stock photography there is no reason why it needs to be confined to a box! Instead seek ways to better integrate it with your design by breaking out of the grid. This can take even relatively poor photography and give it new life.

Brooklyn Fare Website

Avenue 91.1 website

Oklahoma Wesleyan University

Stylise

Of course there are occasions when you are forced to work with poor photography. This typically happens when imagery is provided by the client or when the budget doesn’t allow anything other than the cheapest of stock imagery.

This is the point where you need to let your creativity run wild. Do not resign yourself to poor quality imagery, but rather enhance it using techniques as simple as a photoshop filter to as complex as a collage.

Suie Paparude website

Boutique website

Skipvine

The Nest

Pick images with punch

When you do have a choice of imagery make sure you select an image with punch.

When faced with an image library consisting of thousands of photos, it is easy to pick the first image that has the right subject matter. However remember, composition, colour and style make a huge difference.

Picture of a woman's face

Image of ornate costume

Image of the Festival of Colour in India

Use typography instead

Of course there is no reason why you need to use imagery at all. It is perfectly possible to create an incredibly powerful website with just the use of typography.

In fact I would argue that good typography is imagery in its own right.

Seed Conference Website

National Design Museum poster

Avoid being literal

My final piece of advice is probably the most important of all, and is one that website owners struggle to grasp – You do not need to be literal.

The reason so many websites fall back on clichés is because most organisations do not have strong imagery associated with them. When you think of a management consultant, PR agency or chartered accountant, you instinctively think of businessmen in suits shaking hands. That is the literal interpretation of these and many other businesses. In fact so few businesses produce something that can be seen or touched, they are only left with photographic clichés.

However, good imagery is about conveying a sense of personality and character, not a literal representation of what you do. After all prospective visitors understand that if you are a management consultant there will be men in suits. They don’t need a picture to tell them that. What they need to know is the character and personality of your organisation.

Images that convey information and emotion are considerably more powerful. These are the images that engage with your user and draws them in.

Unicef picture of girl holding water pistol to her head

Picture of a cactus in the shape of persons foot

Call to Action

Every good blog post needs a call to action. Mine is to ask you to be more adventurous in your choice of imagery. Do not settle for second rate stock photography but instead experiment with illustration, collage, typography and styling.

However, most of all I would encourage you to avoid being too literal in your choice of imagery. Some of the most powerful imagery can also be the most abstract.

10 Reasons why I prefer Fireworks CS4 to Photoshop for Web Design

Leigh Howells (a designer at Headscape) shares why he has decided to make the transition from Photoshop to Fireworks.

I have been a Photoshop user for over sixteen years, ten of which have been in a production web design environment. I’ve got used to the way it works. I’m used to its feature set and how it does what it does. I’ve worked happily within that framework and mostly not digressed unless my requirements have been to design a logo – where a vector illustration package like Illustrator has come into its own. More recently, however, I’ve begun to feel like I’m actually using the wrong tool for the job, in some ways like using a word-processor to replicate the work of a spreadsheet.

Just after Adobe’s CS4 suite was released, I decided to have another look at Fireworks – a package I had looked at a few times in earlier versions, but repeatedly given up on – each time falling back to Photoshop. I played with it, and I was impressed by a lot of what I was seeing. I persevered with it and started producing much of my my day-to-day work in preference to Photoshop.

1. Multiple Pages (with Master Page)

A Photoshop file consists of a single image with multiple layers. A Fireworks file on the other hand allows multiple pages with multiple layers per page. When working on a multi-page mock-up for a site design, the advantages of having all your assets contained within a single file are enormous. Although having 5 different PSD files may be workable initially, once edits and changes are required, for example changing text in a consistent header or footer, things can soon get messy and time-consuming as changes have to be made across all files. It’s also very nice that each page can be a different size, perfect for the different sizing which is often required between home pages and content pages.

As well as having multiple pages within the Fireworks .png file (the native file format) the powerful Master Page allows you to define consistent template elements which appear across all other pages. This is very powerful for defining a consistent header/footer which appears on each page and only needs to be edited on the Master Page to be updated across the design. A single page can also be detached from the Master Page if there is a unique page requirement.

2. Symbols

Symbols allow you to define an element or group of elements into a single object which can then be used all over your design across all your pages. This symbol can then be edited in a single place and all changes are reflected throughout your document. Imagine a graphic for a bullet icon which is used in many places across the design. To change the colour or shape of the icon within Photoshop may require lengthy manual editing and copying and pasting across multiple files. But with a multi-page Fireworks document using symbols, the change is only required in a single place for all the icons to be changed instantly across the design. This is a very powerful feature enabling design tweaks which may have otherwise been abandoned due to the time and effort involved.

3. Styles

Styles are to Fireworks as a CSS style sheet is to a web page. An items fill, stroke, font and effects can be defined into a style. These styles appear on the styles list and can be applied to other elements in the document. The real power lies in the fact that these styles can be amended and the changed cascading across the multi-page document automatically. Imagine a style of image with a particular border and drop shadow used in many places which you decide would look better with a different border colour and no drop shadow at all. If you have defined this image with your own style a single update will change all instances without all the pain. Like with symbols this can be a huge time saver whilst encouraging design experimentation and consistency.

4. Vector Objects

Fireworks offers the same basic tools as Photoshop for Bitmap editing but also has many extra vector tools. Lots of vector shapes are welcome with many control points for creating stars, polygons and regular shapes. In addition the Autoshapes panel provides a more diverse collection ranging from stick men with moveable bones, to clocks, calendars and title blocks.

My personal favorite or at least the one I have used the most so far, however, is the humble rounded rectangle which has control points for individual corners making a single rounded corner on a rectangle a simple task compared to Photoshop.

I also like the precise pixel control over each of fireworks elements in the Properties toolbar which makes sizing of images and vector objects a breeze to set to required sizes.

5. Libraries

Both symbols, styles and vector shapes can be saved for re-use and collected into useful library resources. In addition Fireworks ships with a common library of useful objects including buttons, browser and application elements for both Mac and Windows look and feel. A number of pre-defined styles are also provided ranging from Chrome and wood styles to more useful line shading and tool-tip styles.

6. Grouping

In more recent versions of Photoshop layer groups have allowed you to virtually group objects together. Though this works well, it requires a certain level of organisation moving individual layers into folders manually. Unfortunately, I have never liked working this way. I like to work quickly as inspiration guides me without having to laboriously put everything into layers and name them. Though the layer group model is still present in Fireworks it allows you to quickly select individual elements and group them together. The necessity to name layers is lessened by the fact they can be directly clicked on as in most vector packages, unlike Photoshop’s right click and ‘guess the layer’ (which didn’t get named!) method.

7. Interactive Gradients

Fireworks’s Interactive gradients are a simple enhancement to what is already available in Photoshop, but the gradient being used has control handles allowing it to be moved and sized within the object. A very simple enhancement but it works well and allows fine control and becomes particularly useful with using rectangular shading styles.

8. Web Layers

The web layer allow you to quickly add hotspot areas and links between the pages in your Fireworks document, or external URLs. Whilst being useful for linking together simple wireframes, it can also be applied to fully designed mockup pages illustrating how a finished site may navigate.

Fireworks’ initial conception was to help designers produce quick web sites with its ability to output html, rollovers and interactivity. All those features are still there and whilst you may not want to use the code it produces for final sites, for outputting your designs as an interactive mockup site, for example, Fireworks does a great job of exporting your images and html.

9. 9-Slice Scaling

This scaling technique can be applied to bitmaps aswell as to vector objects. This allows intelligent scaling as can be seen in the bitmap below; the four lines define vertical and horizonal sections on the image which will scaling areas when the image is resized, leaving the remaining areas untouched. This can be applied to dialogues boxes, headers, scroll bars, anything which you would want to scale, but to scale non-uniformally.

10. Small learning curve

Lots of things are just the same as in Photoshop – lots of keyboard shortcuts, tools palette – windows, toolbars, panel layouts etc. It all mostly feels the same and I have got to grips with it intuitively moving from Photoshop.

In addition to these ten points, Fireworks is also cheaper than Photoshop!

Some things I don’t like so much

Though I love Fireworks so far, I have some niggles. These may be due to my lack of experience, but then if that’s the case maybe my main niggle is the fact they aren’t obviously overcome!

1. Masks

These aren’t quite as intuitive as Photoshop yet. I have always been a big fan of quick masks in Photoshop; i.e.; pressing ALT between 2 layers making the lower layer mask the layer above. Though layer masks are the same, and there is the ability to paste bitmaps within objects using ‘Paste Inside’, these don’t work quite as freely at the moment.

2. Text Anti-aliasing.

I can’t quite put my finger on it, but the anti-aliasing of text isn’t quite as good as Photoshop’s yet. Even thought there is actually more control with the ‘Custom Anti-Alias’ panel – which allows you to edit parameters, sometimes text can look decidedly ropey at smaller sizes without lots of twiddling.

3. Performance

I can’t quite put my finger on this one either, but Fireworks doesn’t feel as solid as Photoshop. Maybe this is familiarity, but I feel like I’m working from within a piece of carved granite whilst inside Photoshop’s windows. I don’t have that feeling with Fireworks yet, but maybe it will come. (I also don’t know how many of the occasional memory problems and crashes have been due to running a pre-release version on Windows 7).

4. Snobbery

This is a terrible reason for not using one piece of software over another. However, I feel it’s very valid and I’m yet to tell a client I will provide them with Fireworks .png files rather than Photoshop PSD files (although multi-layered PSDs can be output directly from Fireworks). Maybe there is a fear your reputation as a designer is at stake if you aren’t using ‘the big and mighty Photoshop’. Maybe you fear you will not be taken as seriously, like in the old days of DTP using Pagemaker instead of Quark, or sequencing music in Cakewalk rather than Cubase or Logic.

Conclusion

To be honest, I’m not 100% happy with either product for web design work. I still prefer and am more comfortable with some of Photoshop’s familiarity, but I’m enticed by all the other features that Fireworks offers to make life easier and production more streamlined.

I guess the conclusion if you own both is obvious; use them in tandem. Use Photoshop for image editing, and more advanced image correction and manipulation, and use Fireworks for layout mockup of complex web sites which may end up with hundreds of layers. Note that with Photoshop installed, Photoshop’s layer filters are directly accessible within Fireworks in addition to Fireworks own filter options (which have all the basics; drop shadows, glows etc. etc.).

I eagerly look forward to future updates to Fireworks and wonder how the two products may diverge further now that they are both under Adobe’s wings. Although I wish they would change the name from Fireworks, to something like ‘Webshop’ as I keep mixing up Fireworks and Firefox both in conversation and launching the wrong application all the time! But maybe that’s just me.

180. Backend

On this week’s show: The Northeners are joined by the Headscape duo Craig and Dave. We talk about why you should care about .NET MVC and answer your questions about managing your code and friendly URLs.

Play

Download this show

Launch our podcast player

Our most complicated setup to date! Ryan in the studio, Craig and Dave in the barn and Stanton on the phone.

Housekeeping

Vote for our SXSW Panels!

It’s that time of year again and we’re asking our beloved listeners to vote for one or both of our SXSW panels.

Pain Free Design: Getting Client Sign Off

Boagworld Live – Open Mic

Any votes would be greatly appriciated!

News

Expanding your development skills with Creative Tech Projects

This post by Smashing Magazine tries to pursued you into doing something different every once in a while and points out that even if you’re a web developer, your next project doesn’t have to be a website! You can learn a lot by doing something outside your normal comfort zone, and there’s some great examples of different things you could play with, such as:

  • Write your own desktop application, using Air for example
  • Extend Firefox
  • Create interfaces for your favourite gadget, such as your iPhone or Wii
  • Play with Hardware, such as the WiiMote, Arduino kits or Lego Mindstorms

One of the things I love about working in this industry is the sheer amount of cool stuff available for us to play with. Admittedly, it can often be hard to find the time, or even justify spending time playing with cool stuff when client work is stacking up, but who knows, you might find that people out there would pay you good money to build things using the skills you acquire!

5 Advanced Photoshop techniques for web designers

Yes, this is a ‘top 5’ type post, but it’s quite a good one so I thought I’d tell you about it. This article on the Think Vitamin blog gives you a decent rundown of 5 popular visual effects in modern web design, and tells you how to replicate them.

There’s tons of screenshots and explanations of how to make awesome buttons, navigation menus, inset typography, faded shadows and depth. It’s a post to bookmark for those times when you have a spare few minutes to mess about in Photoshop and try new things.

Digg’s move to GIT

This is the first of a two part article detailing how the developers at Digg are making the move from Subversion to Git. I realise that source control doesn’t get discussed much on this show, but it’s something that every designer and developer should be using if they’re not already.

I’m not wanting to start a SVN vs GIT argument here, but I’m very interested in seeing how big established teams work in regards to source control and this is quite a candid account from the Digg team about the scaling issues they experienced as the development team expanded and SVN struggled under the load, and how they’re starting to use GIT to solve some of these problems, highlighting both the good and bad points of the new system.

Everyone will have their own source control preference, but if you’re part of a large team and have source control issues (don’t we all) then give this a read.

Back to top

Feature: Why .NET MVC? (and why should we care?)

Having previously written about the highs and, perhaps more importantly, lows of working as a .NET developer. This article will continue the trip into Microsoft World, only this time it’s to the land of MVC.

Read the Why .NET MVC? (and why should we care?)

Back to top

Listeners Questions

Managing your code

Question from Jamie…

I have recently started developing my own system for building web applications with. I have found that as projects have ticked by i have ended up with a large assortment of code of different versions and functionality. How do the backend development guys at headscape manage this code mountain beyond the project by project SVN style management?

Headscape has a strong design and consultancy background, however the development side of things has also been done internally since
the beginning.  In fact the design and Tech teams are of equivalent size and we have a large number of legacy and currently running projects
at any one time.  Source control and code management is therefore vitally important.

As a development team we rely heavily on three main methods of knowledge transfer over time, projects and team members.  This includes
the standard approach of code commenting, a source control system and an internal wiki for snippets, interesting decisions, rationales,
product roadmaps etc. The wiki, in the context of code, provides a space for longer descriptions and reasoning behind technical design and
implementation approach.

As many of you may be aware a large number of Headscape projects utilise our in-house CMS.  This acts as the base for our common code and
contains multiple projects – A common code repository (the equivalent of our ‘System’ namespace), a CMS class library project and
a base CMS Web project. When a new CMS project comes in we create a new project in source control, with the most recent labelled stable
version of the CMS code as the initial check in.  Changes on this development are then logged only within the context of the project.

Throughout key stages of development and during project washup changes and enhancements that can be generalised from this project will fed
back in to the main project after review with at least one other member of the tech team.  As some projects can be very bespoke we do not
currently utilise branching within our Source Control repository for the purpose of each project.

Friendly URLs

Daniel Farrell writes:

My university has a ridiculous URL naming scheme!

I can see what they are trying to achieve: human readable and logical ordering of pages. But by nesting on such a microscopic scale, they produce the opposite result. The pages are no longer memorable, and not even easy to read because you need a huge screen wide screen to see the whole URL.

Furthermore, because ‘software’ is a service provided by the ICT department is must be nested underneath it. This reflects the management structure of the department not necessarily the way a user thinks! For example, why couldn’t the URL be, /softwareshop/adobe?

What are your thoughts on human readable URLs and how would you tackle the problem of making such a huge site easy to use? Should I have more sympathy for the web team or do they need a good kick up the arse!

There are a number of reasons that large organisations use long and often convoluted URL schemes. One possibility is that different parts of the site could be hosted on different servers and managed by different people. There may be different systems running different sub sections such as a shop which generates its own URL structure under an already long base path.

Firstly, it doesn’t always matter. Unless it’s a URL you want people to remember, the majority of web users don’t really care what ends up in their URL bar once they start navigating a site. It makes no difference to a bookmark and can be shortened easily enough by any number of URL shortening services such as tinyurl or bit.ly.

So when does it matter? It matters when you want users to easily find something that could be tedious to find by navigating a site. A good example is TV or poster adverts where people need to remember the URL for a period of time or a subsite that isn’t linked to from the main site. (administration logins for example)

A good example of a website that manages this well is the BBC site. This is a huge site with many smaller subsites. It’s important for them to advertise concice and memorable URLs so many of their subsites are directly below the site root. One solution could be for the university to setup a series of shortcuts that redirect to the full URL.

Some tips for constructing easy to remember URLs
  • Keep sections concise. “personalcomputersupportandmobileservices” is bad, “ict” is good.
  • Try and use words that are easy to spell.
  • Avoid numbers and hyphens
  • If possible and necessary, create a couple of versions that are equivilent and redirect to the correct version (ie. Wikipedia’s redirection)

Back to top

175. Collaboration

On this weeks show: Ryan and Stanton take the helm, we interview Simon Collison on client collaboration and answer your questions about improving your design skills

Play

Download this show

Launch our podcast player

News

How to design a portfolio site

First up is a two part video series on Carsonified.com called “How to design a portfolio site” in which Elliot Jay Stocks shares his advice and experience. If you’re a freelancer, you know how important your portfolio is to your business and these 2 30 minute screencasts are filled with useful information such as:

  • The three key concepts that make a portfolio site
  • How to build great case studies to reinforce your expertise
  • The ultimate portfolio checklist
  • How to use narrative theory to strengthen your portfolio
  • How to take your design from Photoshop to HTML and CSS
  • How to integrate your design into a CMS like WordPress
  • Lots, lots more.

I’m also going to give a slight plug here to my co-host Ryan, as he’s just published a video interview with Elliot on his site havocinspired.co.uk where he asks Elliot about his career and how he got where he is today. Both definitely recommended viewing!

I’m also going to give a slight plug here to my co-host Ryan, as he’s just published a video interview with Elliot on his site havocinspired.co.uk where he asks Elliot about his career and how he got where he is today. Both definitely recommended viewing!

A/B testing and microcopy

Paul talked about microcopy last week and another article passed my way which further highlights just how powerful microcopy can be and how A/B testing can help to improve your calls to action. Dustin Curtis performed an experiment over the past few months where he tested a specific call to action on his website which prompted people to follow him on twitter and measured the number of clickthroughs various versions generated.

He started with the statement “I’m on Twitter.” Which led to a 4.7% clickthrough rate, then switched to a command “Follow me on twitter.” which resulted in an increase of 55%. He then went on to try a stronger personal command “You should follow me on twitter.” which increased even more and finally added a literal callout “You should follow me on twitter here”.
Overall, the clickthroughs increased by 173% showing just how much of an impact microcopy and A/B testing can have on your site and it might be something you want to look into.

Did Digg and YouTube just spell the end of the Internet Explorer 6?

Sometimes I sit back and wonder what life would be like without IE6 and the whole world is sunny, I sit in a lush meadow with my laptop, coding away without a care in the world… If only.
Every so often someone sets their sights on IE6 and declares war, most of the time we scoff, knowing IE6 has too many troops to be defeated, but two new armies have stepped into the ring, and they’re big armies at that. Digg.com and YouTube have both recently announced that they will be taking sides against IE6 sometime soon. This was highlighted in a blog by Chris Heillman.

A post on the Digg Blog shows that they’ve been researching the situation for quite some time, monitoring the reduction in IE6 use and weighing the number of visitors using the browser to the costs associated with developing specifically for it.

Admittedly, the audience of Digg might be slightly biased towards a more tech-savvy crowd, so these results might need to be taken with a potential overdose of salt, but it’s encouraging to see a fairly large outfit taking the time to research the situation and I’m sure that they’re not going to shut off support completely, but concentrate their bells & whistles on the newer, more capable browsers leaving just the content accessible for IE6.

YouTube have already started showing a message to IE6 users saying that they will be ‘phasing out support for their browser soon’ and recommending the user to upgrade. Chris points out this might not be as impressive as it first seems as 70% of YouTube’s traffic is from embedded media.

He also points out that both Digg and YouTube are social web sites, which are normally blocked by the kind of organisation which forces their users to use IE6, so the true impact of this news remains to be seen.

Back to top

Interview: Simon Collison on client collaboration

Ryan: OK, joining me today is Simon Collison. Hello, Simon.

Simon: Hello, nice to be here.

Ryan: And we’re here at the Future of Web Apps tour in Leeds, and you’ve just done a talk this afternoon, it was a very good talk, I really enjoyed it.

Simon: Smashing, thanks for that.

Ryan: And we thought it would be really good for our listeners to just cover a few of the things you talked about in that talk. Now your company, remind me your company name.

Simon: Er yep, Erskine Design. Or Erskine if you’re looking to impress, I think. Not quite sure where to stand on that.

Ryan: Where did that name come from?

Simon: It is, I think the origin of it means ‘upon the knife’, which is quite interesting. So, obviously, it’s a place in Scotland, it’s also an old saying and if you tweak it or someway, in this day and age, it means upon the knife, which we quite like for a design and development agency. We often feel as if we’re on the knife. So, it works quite well.

Ryan: Cool. And you started off your talk by telling about your biggest disaster, which I thought was quite interesting, but you were quite open about it and that was the Vanilla Pages.

Simon: That’s right.

Ryan: Just for the benefit of us listeners, would you like to tell us what the Vanilla Pages was, is…

Simon: Sure, definitely past tense, um yes. The Vanilla Pages was an idea that was brought to us and we worked on that for a client team, so it’s very important to stress that; it’s not our disaster, as such; we may have facilitated it. Basically, the Vanilla Pages was an idea for a web app that fitted a perceived niche in the fine food and drink arena. THe idea for the Vanilla Pages was that is was a 24 hours a day, 365 days a year tradeshow. Suppliers, wholesalers, buyers kind of creating links and making connections and finding new sales opportunities. On the face of it, we thought this was a good idea. Also, Erskine had only just begun, so we were looking for new and interesting clients and we met with the client we thought they had some good ideas and we spent some time discussing what the process would be. Now, obviously this was 2 or 3 years ago and our process is very different now – very well honed – but at the same time we had enough experience as a team then, we were kind of discussing the need to understand the audience, really get to the bottom of this niche and find out: “What do people really want, will they use ‘X’, will they want to do ‘Y’ abd so on”. And initially, it was like “Yeah, this sounds great” and we signed everything and we began work and instantly we found that our suggestions were being thrown out. There was very little room for us to use our experience to make suggestions and say: “have you thought about this?”, “why don’t wet a focus group together, why don’l;t we ask some retailers some questions” and so on. And as I showed in the presentation today, we then started to receive incredibly detailed and colourful Excel documents, pretty much telling us everything we needed to do, every nuance of the user experience was being dictated. Now, we’re not fools, we stood up for ourselves and we illustrated many warnings but it didn’t really happen and we continued the project and we launched it. It received quite a lot of advertising and it failed. And so, yeah, today I introduced the presentation with a video that was created for it and then proceeded to rip that video apart.

Ryan: Which was quite amusing.

Simon: And used that as a basis for everything else.

Ryan: I know that Ryan Carson’s been recording the talks, I’m sure that will appear on there.

Simon: Excellent. I’m sure this will come back to haunt me. I’m expecting an email from that client in the next few weeks.

Ryan: But you telling us about that site set up the entire theme for your talk, which was collaboration and the process of collaboration with your users and you came up with some, a list of points, a process that you kind of went through which; the first one was collaborate and then research and then… Can you just take us through that process?

Simon: Yeah, sure. I mean, to address the point of collaboration, I think, a point I made today was that it’s a collaboration across all kind of boundaries, so on one hand it’s the design and development team itself. So, to quickly summarise that, and this will be old news to many listeners, but essentially, the designer can talk to the developer; the project manager or, heaven forbid, account manager knows as much as the designers, the developers and so on; everybody is aware of every aspect of the project, or as much as possible. This gets away from that production line approach and allows the developer (to use labels here) to dictate, or suggest ideas, to the designer, and so on, because he or she is armed with enough information and understanding, through the process, to feel that they can contribute, that they’re not going: “I don’t know if this is relevant, but…” why not make the suggestion? So, a lot of collaboration within the office, if you like, if it’s an app for a client, then obviously look to collaborate with them as much as possible, so it’s not just a one-way process, so as many opportunities for focus groups, workshops, talking to stakeholders, investors, whatever that might be, and key to that, the intended audience, which was the main point today, as well, to collaborate with them from the earliest stage as best possible. In terms of the process, yes, collaborate at the top, it’s more of a reminder, through the process. So, we looked at things like research, prototyping, testing, rinsing and repeating that process really. If there’s an agile approach to what’s happening, then you know, there may well be a product launch, then loop back and go through the thing again. Yeah, and to summarise there again, it’s, we were talking about whether it’s waterfall, agile or a fast sprint. We wouldn’ make that decision until we’d spoken to the audience and we’ beginning to get an idea of what they might need, or how best to pitch this website or application.

Ryan: Which, I find quite interesting, because I seem to get the impression that, as a company, you don’t have a set process, so you basically, you know, a new client comes in and you’ll look at the audience and then you pick whether you’re going to through an agile process, or a waterfall process, whereas, you know, we hear a lot about, you know: “you must use agile, agile, agile, agile” or, you know: “waterfall’s best, waterfall’s best” and you seem to, you referred to it actually as: ‘Organic Collaborative Process’

Simon: Yeah, absolutely. I mean, it is very difficult to, in most situations where there’s a client involved, you need to respond to an RFP, or some kind of brief, you need to reach an agreement over what’s going to be done before they’ll say yes, we’ll give you ‘X’ amount of pounds and we’ll build this together hopefully. It’s very difficult to say “take a leap of faith with us, we will put some of the pieces together, shortly into the process, we need to find out more first, and get under the skin of what you want, what you’re intended audience might want.” So, that’s quite tricky, some of the greatest things we’ve worked on have been based in that leap of faith and we’re taking one as well, working with a client sometimes, you know. We’ve learned that it doesn’t always work out as it might look and they take a leap of faith with us. I guess a lot of it is, kind of, proving through previous work and illustrating how that process worked. So, it sounds a little trite and I never want anything to sound arrogant but a level of education, I think, commissioning for the web is difficult for a lot of people. If we can help them understand what they need to do and how we meet in the middle and how we collaborate then, you know, we’ll do everything we can, because that’s a great foundation for the project.

Ryan: Maybe slightly off the topic of collaboration, but do you price differently for different processes, so whereas agile’s much more extensive than just a waterfall method. Would you look at the project, pick which process you want to use, and would you price accordingly, depending on how thorough the process is, or do you look at a project and, you know, just price it the same across the board.

Simon: Yeah, that’s a killer question. It’s the… First of all, we try and be as flexible as possible and again that comes back to that leap of faith situation. There may be a ballpark figure involved early on. The ideal situation is that, if it’s a pitch, for example, we would kind of get the go ahead, if we’ve been fortunate, without having to be too specific. Hopefully, the illustration of our process and what we’ve done previously, and what we’re aiming to do can be enough. That is difficult. If the approach is going to be typically agile, it’s obviously a very different beast to a waterfall process, where you can pretty clearly define, you know, we’ll do A, B, C, D, we’ll end at Z – job done. With agile, who knows, because exactly how many kind of releases might there be? What’s going to be involved after the initial launch? So, very difficult. As a team, we democratically discuss everything, everybody is involved, and again collaborates on how we approach a potential job. Like a lot of people, and I’m sure there’ll be plenty of people listening who’ll empathise with this, we’ve burned many times, so we are extremely careful about it now. So, no set answer. We work with whatever flexibility we’re given.

Ryan: OK. Moving slightly on. You talked about logovisual thinking and these weird disk things

Simon: Yeah

Ryan: Which you looked to have lots of fun with, you put pictures up and everything and you want to just tell us s little bit about that?

Simon: Yeah, sure. The product itself is, yeah, LogoVisual Thinking, I couldn’t even begin to tell you why it’s called that.

Ryan: It’s the ‘logo’ bit, I can get ‘visual thinking’, it’ the logo bit.

Simon: Yeah, I’ve no idea. Maybe Mr Logo invented it, I’m not sure. That would be a great name. The URL, I’m pretty sure is logivisual.com, in fact, it is and they produce loads of products. I’m not affiliated with them in any way, I should make that clear, but I do wax lyrical about this stuff. Essentially, they are magnetic hexagons, but they also do all kinds of shapes and different tools and I think they’re really, they’re used a lot in business. You can just imagine the dry management meeting: “come on everyone, we’re going to imagineer for the next half an hour” and they’ll break these things out. It’s possibly easiest for people to think along the lines of Post-It notes, or using something like that. A classic example where we would use them is we would get a stakeholder or workshop team together and a few of us and we find that there are people in the room who are contributing a little less, you’ll have, you know, Johnny Smartpants who knows everything about Web 2.0 and he’s throwing all these ideas in, and there are some other people and you think “I wonder what they’ve got to contribute”, so give them a pen and a pile of magnetic hexagons and then give them a, let’s say, for simplicity sake, “list all the kinds of user you can foresee using this product or website” Go into detail, rather than say ‘government’, talk about specific roles, you know, what kind of people within a government department might use this thing and why. They all go away and, because there’s no pressure, the write whatever they want. We bring that together and then we’ll look at grouping these items in a particular way. The example I used today was audience grouping. We prefer to work with a broader brushstroke than the typical user persona, so you’ve got Johnny or Mary who, you know, Johnny does this, Mary does that, she knows about this but not that etc. Sometime we, and⁄or the client, forget exactly what Johnny’s supposed to be, we have to go check so with these tools, we’ll take everything that people have contributed and we’ll group them into 4 or 5, maybe, audience groups. We’ll then label those groups and then they will be in our minds throughout the process. So, for example, we’ll have a hierarchy, it might be that it’s a government site, it might be there’s a certain kind of user is ‘Hierarchy1’, a certain kind of group is ‘Hierarchy2’ and so on. And the outcome will be, we will do some lo-fi diagrams and look at where typically would somebody from this audience group arrive; what might might they do while they’re there; and, vitally, what action might they take, what might be there outcome, what do we want them to do. So we use these LogoVisual tools for things like that. Essentially we just have them around as whiteboards and they’ll be around for a project, we’ll move them around on the boards, because they’re hexagons you can group them beautifully and, yeah, I mean, have a look at logovisual.com, there’s some good ideas on there of how people are using it.

Ryan: And you talked about having a project space in your office, didn’t you, which you brought this picture of a, really impressive actually, all these things stuck to your walls and everything.

Simon: Yeah, it was. Well, that particular example was from the Erskine.com redesign, so we really did go hell-for-leather on that one. Yeah, we’re fortunate to have quite a large office space I’m not bragging there because it’s got no heating, single-glazing windows, it’s freezing, it hasn’t got enough plug sockets, it’s kind of rubbish, but we love it, and it’s a creative space.

Ryan: It’yours.

Simon: It is ours, which is wonderful, although we share with an idiosyncratic, little illustrator called John Burgerman, who’s gradually spreading himself through the office, but we love him. So, yeah, we set aside an area of the office, if there’s a spare computer, we’ll stick a computer in the middle, so we can access online information, but really it’s offline scrapbooking, so you know, we print out typefaces, we rip this out of magazines, classic stuff, as we produce wireframes, or any kind of, you know, back of a cigarette packet sketches, whatever they might be, or source material from a client, maybe, we just throw it all in this space. It acts as a constant reminder, so if you’re scrapbooking in a flickr pool, or, what is it, LittleSnapper, or something like that, that’s fine, but it can e difficult to share and it’s a bit out of sight, out of mind. With the project space it’s just there, and you can keep adding to it, and if you’re stuck for inspiration, 2 or 3 of us might, rather than just discuss this idea over Skype or, as you do when you’re in the same room, sad as that is, or sort of face to face at our desks, we’ll wander over to the project space, where we’re kind of surrounded by the project, and delve in and add to it, tear things up, I don’t know. It works for us; if you’re a remote team, and you’ve got people in different locations, it’s maybe not so good, but it’s a nice idea, and I think people like Clearleft and Mark Boulton, people like that, I’ve spoken to them and I know they do a similar thing. It’s just a, it’s a tip, but it doesn’t work for everybody.

Ryan: You talked about community and you had to rush through that a little bit, because your talk was overrunning, could you talk to us a little bit about that. Again you had bullet points of trust, and brevity and things like that. Could you just take us through what you were covering there.

Simon: Yeah, sure. Yeah, half an hour’s never enough really.

Ryan: It flies by, doesn’t it.

Simon: Especially when you waffle, like I do. Terrible – you should see me after a few pints, actually no, that’s a bad idea. Yeah, basically we have, they’re our kind of, what would you call them, they’re like little waymarkers or points to observe throughout the process, so through that early collaboration with the audience or the client, we’ll define some key aims and objectives, but they’re usually project specific, but I certainly believe that there are a number of conventions, if you like, or almost courtesy items to be aware of, when you’re looking to create a community around a website, so you mentioned trust, that’s something I really think is important, especially where you’re asking people to submit their own information, share information and kind of confide in the site, in a way, so it’s very important that the user feels safe, secure, this isn’t just a fly-by-night website. I don’t know why there aren’t more Web 2 applications that essentially fish, you know, imagine if flickr ended up being, you know, all that stuff and that was all going to be used in a way we didn’t understand. You need to build that trust. So we’ll look for certain devices, we might fall out with a client over their choice of a URL, because if they’re a business to business organisation, you don’t want something jokey. Also, who’s behind the site, are there humans behind it and how can we bring them into it, can we get them to write dome kind of introduction, can we make them visible, can we make them contactable? So, little things like that. And then other items on the list were classics such as, you know, brevity with content, making things easy to find, I’m sure that’s relevant, regardless of the subject matter, and so on.

Ryan: OK. You also mentioned having a features roadmap during the process of developing your site, do you want to explain why that’s benefit?

Simon: Yeah, I rushed through that as well, didn’t I? Basically, we often find that, if the first meeting with a client or, you know, if we’re building something for ourselves, grandiose ideas, you want to kind of do everything and I think it’s very important to bring simplicity into whatever you do it’s a bit of an obvious thing to say when it comes to responsible design, but at the same time, you know, 37 Signals and other companies have talked about this stuff for years and I think many of us have learned from it. Essentially it’s what are we going to do; when are we going to do it, sometimes it falls in very smartly with the agile process; what do we know about the audience, in terms of what we can throw at them and when. So, we obviously favour starting small. I was talking to somebody after the presentation about low expectations, take that the wrong way and it sounds quite negative, but I think, you know, it’s just putting the bar somewhere where you can reach it. I think it’s a very negative thing if you launch a site with all the bells and whistles in the world and then end up retracting too much after launch. I think it’s natural that some things will change and some things may be removed, but if you kind of visibly change your whole plan, because you haven’t thought it through, I don’t think that’s very healthy. So yeah, it’s defining a roadmap, as we call it, and probably others do as well, where we essentially outline what we’ll do, when and try to stick to that, but ensure it’s malleable, so as we learn more, we can rethink it, think let’s wait on that and the way we reflect that with the client, as well, in a more tangible way, is we try to get rid of all the sort of, the Basecamp noise and whatever other channels are in operation, reduce a project down to it’s deliverables, so we will have, I guess establishing a, if it’s not too pretentious to say a narrative to the project, so there’s point A, and there’s lots of things to click, on be they kind of sitemaps or research findings, through to batches of wireframes or comps or prototypes and whatever. We find that, in tandem with that roadmap thinking, kind of illustrates what we’re trying to achieve and when, and I think it can be reasonably easy for a client to buy into that, so it’s a case of OK, so, I guess it’s what you say and then backing it up, so proof as you go along. So that leap of faith is, kind of like, yeah, you were right. So, that seems to work quite well for us.

Ryan: Great, and you got everybody excited right at the end of your talk by showing them your ‘Ultimate Package’ [Laughs]

Simon: Yes, ladies

Ryan: That must sound very odd coming over a podcast

Simon: I’m sure it does, yes my ultimate package. OK. It would be really unfair of me to take credit for this, I do like the idea of conventions in web design and development, whether it’s navigation and using the word ‘About’, ‘Contact’. I think there’s plenty of other areas to create and do exciting things. Personally as a web user, I like certain constants. So, those kind of conventions I love. In terms of actually building websites, we use a lot of them in our development process. So, for example, when we start a project, we actually start building it, whether it’s a prototype or even if we’re just experimenting, we have a folder that we iterate, we’re on version 1.9 of our Ultimate Package at the moment, and we just drag it onto, we just FTP it.

Ryan: Like a template?

Simon: Yeah, basically. Responsibility for this goes to whole Erskine team, but specifically Greg Wood, our lead designer who is, kind of, the custodian of this thing so he’s very passionate about it. It’ll be up to Greg whether I’m able to share some or all of it with you all eventually, I don’t know, and I’m sure other people have their own versions. So, for example, you will have, in the Ultimate Package, some JavaScript files, the latest jQuery, some stuff to control certain functions and some JavaScript to help with IE6, PNG transparency, whatever it might be, and then a cascade of CSS files, so our main screen.css, with some basics in there, reset.css, our own version of Eric Meyers Reset CSS, and things like a scratch file, so if one of the, one of my colleagues wants to do some work in the CSS, they do it in their own file which cascades in, so, you know, Greg or somebody can approve it or ditch it, withough it really having any great affect…

Ryan: I like that. That’s a good idea.

Simon: on the main stylesheet, if you like, again that’s something that Greg’s introduced and we all find that really useful.

Ryan: Yes, that’s a good idea, I really like that.

Simon: And there’s a few other bits and pieces in there as well. The beauty of it is, if you start working, you want to start working fast, the external JavaScript, CSS and so on, is already linked up, so you can throw a function in very quickly, without thinking: “oh, I must, why is it not working? Oh, I’ve not called it in the <head> of the document” No, it’s all kind of there. You remove stuff as you go along, but it’s there. And there are things that help us with ExpressionEngine builds and a few rules in there as well, so that we’re all on the same page, if you like. If I’ve not worked on a project at all, the person who might have led it is on holiday, the client calls and they’re in a panic, I go into the code and I start looking for certain conventions: I know there will be a ‘Contents’ at the top of the main stylesheet, I can “Ah, 10.1, scroll down, find the flag for that” So, it works really well.

Ryan: And if we’re very, very lucky, we might get a chance to get a sneak peak at it?

Simon: I’ll have to speak to Greg. I’m really, I love the spirit of sharing.

Ryan: [Laughs] Greg’s baby.

Simon: Yeah, I don’t know if I owe him any more beer, but I’m sure that will be involved.

Ryan: It’s a good idea for people to think about and if they’re going to build their own anyway, I like the idea of a scratch file.

Simon: Yeah, just use your own, you know, your own conventions, if you like. I love the spirit of sharing in this community, especially we saw it through web standards, and everything else. I’ve really benefited from people sharing this kind of stuff, so, you know, hopefully we will. I’ll keep you posted.

Ryan: If not, there’s some ideas.

Simon: Yeah, I’ve already been asked today to write about how we go about producing it, so even if we don’t share the actual ‘Ultimate Package’.

Ryan: So, keep an eye on your blog or Twitter feed and that should be it?

Simon: Yeah, either myself or Greg will probably put something together at some point about that.

Ryan: Fantastic. OK, Simon, well thank you very much for taking the time.

Simon: It’s been a pleasure to be on boagworld.

Ryan: Thank you very much.

Thanks goes to Simon Douglas for transcribing this interview.

Back to top

Listeners section: Improving your design skills

David Smith

I’ve a question for you regarding how to improve my design skills in order to further my career.

I’ve been working professionally in the web industry for just over a year now. My current role involves web page design, web page development (XHTML & CSS) and some work with server side code.

Of these three aspects of my job I much prefer designing. Having listened to the feature of “Surviving the Recession” and hearing you telling us to specialise I feel that I would like to become primarily a web designer. However, I have no formal graphic design qualifications (my degree was in Music and History!), and although I have produced numerous successful websites for clients I don’t feel my skills are developed enough to compete with true pros like yourself!

Could you or any of your team/contacts offer me and others like me some advice on what I could do to improve my web design skills? I have considered courses but can’t seem to find any that fit my requirements.

I’d really appreciate it if you could take time to answer this question as I’m a big fan of the show and it would really help me to further my career.

Good question and I have to admit it’s something I often think about myself. I think a lot of it boils down to how you personally approach learning and seen as everyone is different this is probably going to turn out as quite an ambiguous answer, so I’ll go through some of the steps I use and have used in the past.

Learn how to use your graphics program, properly!

Personally I’m a big Photoshop fan, some people prefer Fireworks or various other graphics programs, it doesn’t really matter the principle is still the same, learn how to use them properly!

I’ve found that it can often be easy to think of a design in your head but converting that idea into Photoshop can be difficult if you don’t have a solid understanding of how to use the software. Equally so you can often find that your ideas are limited to your understanding of the software you’re using and as a result your work suffers.

Read books

And when I say read books I don’t mean for you to burn your brain out reading the Photoshop Bible from cover to cover (worst book I’ve seen for photoshop by-the-way, black and white images in the a graphics software book???), I’m talking about a good reference book. Pick a tool to learn an read that section.

I can personally recommend Ben Willmore’s Photoshop CS3 Studio Techniques (there is a CS4 version of the book but I’ve not read that one), which is about half the size of the Photoshop Bible, packed with tons of example images (in colour) and the explanations are concise but informative.

Watch examples

Video tutorials are cropping up everywhere these days and I love them, what better way to learn how to use graphics software than to be shown.

Lynda.com is a great place to have a look at as well. Short bite-size videos 3-5 mins on average that show you how to use the software through examples. It is a subscription service but you aren’t tied in for any length of time so you could simply pay for a month and watch as much as you like.

Challenge yourself

Its difficult to improve your skills without have a goal or objective, sitting down and saying “Right I’m going to improve my design skills” rarely works, you need to challenge yourself however you also need to be realistic. I’m not saying you should take on a huge blue-chip client and attempt to turn around a top class design as a challenge. Start small, push yourself and build upon your skills gradually.

Experiment

If you’re inspired by a piece of design work then try and figure out how it’s done, dissect it, try and learn how to achieve a similar effect, but obviously don’t rip it off!

You’ll find that the more you practice achieving various effects the more comfortable you’ll feel about taking on more adventurous projects which in turn will contribute to improving your skills.

Courses

Course are a tricky one because you have no idea how beneficial they’re going to be until you’ve paid your money and sat through a few lessons.

I went on a 10 weeks, intermediate to advanced Photoshop course a good while back and in all honestly I didn’t learn anything that I hadn’t already picked up from elsewhere.

Perhaps there are better courses out there? If you’ve had a good experience leave a comment in the show notes.

On the other hand you typically get a certificate or something to show for you effort which can go on your CV.

Conclusion

As I say everybody learns in different ways but the most important think to remember when developing new skills to just do it, learn and apply, take on projects that allow you to push yourself push yourself, do something different and try something new. You may be surprised with the results.

Back to top

159. Special Guest

On this week’s show: The northerners are back with special guest host Sarah Parmenter.

Play

On this week’s show: The northerners are back with special guest host Sarah Parmenter. We answer your questions on how to quote for projects and whether using off-the-shelf software is wrong and we have a chat with Sarah on her experiences in the industry and the difference between developing for clients and developing for yourself.

Download this show.

Launch our podcast player

News

Alkaline

Our first story for is a new product by the guys over at Litmus, you may have come across their Browser and Email testing apps before and they’ve just released a new Mac app called Alkaline, this is a Mac front-end to their online browser testing suite and lets you test your website designs across not only 17 different Windows browsers which they mention on the site, but also all of the Mac and Linux browsers that the online Litmus services test against.

Alkaline grabs screenshots of your site rendered in all major browsers, the number of which depends on your chosen pricing plan, It’s free to test against IE7 and FF2 and if you need to test across all browsers, it’s available under the standard Litmus pricing plan which offers both individual and team monthly subscriptions, and a handy day-pass if you only do this kind of testing every now & then. Litmus also stores a history of your screenshots so you can see the evolution of your design and also reports your HTML and CSS errors.

There’s plugins available for Textmate and Coda, and you can preview the sites right inside Coda 1.6’s preview window, however because Alkaline grabs screenshots of your pages it’s not possible to do any live updating of CSS and see the results in all browsers.

Paul at Litmus also informed me that throughout April, they’re offering full access to the Litmus service for free on Weekends, so on Saturday and Sunday you can test across all the browsers (using Alkaline or the Litmus site) and all the email clients, even if you only have a free account.

16 design tools for prototyping and wireframing

It’s no secret that prototyping or wireframing can really help in the overall design process, and there’s now a wide range of tools on the market that aim to help you in this process. A recent Sitepoint article lists 16 of these tools and rates their usefulness.

The list of tools is good, convering favourites such as Omnigraffle, Axure and Balsamiq to other applications which can be used to wireframe such as Powerpoint or Keynote. If you’ve not looked into these kind of apps before then do check it out, they also lists the price of the apps so you’re sure to find something within your budget.

10 Lessons every freelancer should learn

If I remember rightly, I came across this link from one of the people I follow on Twitter and it covers some killer tips on how to be a better freelancer, covering everything from self promotion, organising your workflow, finding time for your own projects, keeping motivated and how to charge appropriately, this is a must-read for anyone considering freelancing, or indeed those already in the freelance world.

Some great tips come in the way of keeping customers happy and generating repeat business and I’d like to squeeze in a forth link here to another Sitepoint article (sorry) which covers how to upsell additional services to clients as a freelancer you should be looking at maximising the amount of money you can make from each project through added services, whether it’s packaged services such as hosting, logo design or business cards.

I don’t really freelance but I do manage a couple of small sites I built on a freelance basis, and I get recurring revenue by hosting them on a small reseller account. I’ve also been able to tempt the customers into paying for a years hosting rather than a monthly cost by rounding the amount down to an even figure, which while it’s only a couple of pounds cheaper, always got chosen.

Back to top

Interview: Sarah Parmenter on the difference between developing for clients and developing for yourself

Ryan: OK, so onto our interview section and what we are going to do today is an off-the-cuff interview with you, Sarah, er, so for people who don’t know who you are, er, do you want to introduce yourself.

Sarah: Sure, my name’s Sarah, I’m based in Leigh On Sea in sunny old Essex and I own a company called ‘You Know Who Design‘ that’s been going for about nearly seven years now, um, and I just do web development and sometimes I dabble in a bit of graphic design. Um, when I started off when I was younger, it was more graphic design than web but now it’s purely web and, er, yeah, it’s what I love doing.

Ryan: Right, OK, and we think a good topic to have a chat with you about would be the difference between developing for clients and developing for yourself.

Sarah: Yup

Ryan: So, er, let’s start off. Do you give yourself time to work on personal projects?

Sarah: I do, but not as much as other people do; whenever I see on Twitter, there’s a lot of people who have a lot of personal projects on the go and it generally tens to be on a Friday as well (all laugh), you see Twitter on a Friday, generally full of people, um, doing their own stuff but I tend to, if I’m doing something I tend to, maybe, give myself a couple of hours if I’ve got a spare, if I’m waiting for a client to get back to me on something and I can’t proceed with anything. I put client work first, and I don’t know if that’s a good thing or a bad thing, but that’s the thing that pays the bills, so, um, they always come first and if I’ve got a bit of downtime, I’ve always got projects that I want to work on, but possibly haven’t got the amount of time to dedicate to them as I’d like. I think it’s probably the case with everyone.

Sarah: Yeah, absolutely. You get some time, don’t you, through work?

Paul: Er, well we did sweet talk our boss into giving us 5% time, which was supposed to be like Google’s 20% time, where they get a whole day to work on personal projects, if it benefits the company.

Sarah: Really?

Paul: Yeah, well we got, like an afternoon on a Friday, which is kind of sidelined at the moment.

Ryan: To spend in the pub (laughs)

Paul: That’s personal projects, I’m sure. No, it’s kind of sidelined at the moment, we’ve got some major projects on which are taking up all our time with some heavy deadlines, so we’ve had to shuffle that. Hopefully we’ll start to get that back over the summer and work on some cool stuff instead of the business stuff.

Sarah: I think it’s rea
lly difficult, because obviously your client stuff does have to come first, and even if you’ve dedicated an afternoon or a couple of hours, if something comes up that morning, or if you’ve got a problem that needs sorting, unfortunately, it’s just the way it is, your client work has got to come first.

Paul: Yeah, pays the bills.

Sarah: I mean, a lot of personal projects, a lot of people’s personal projects, do end up very lucrative for them, and you could argue that it’s just as lucrative to just go along with your own personal projects, but I think in general, most people would find that their client work would, er, would have to come first.

Paul: We’re trying to convince our boss to let us build, er, an iPhone app

Sarah: Really?

Paul: and sell it on the app store. He’s not having none of it, because we’ve told him we all need iPhones to test it on, he just won’t buy them for us.

Ryan: and a mac to develop on

Paul: a Mac to develop on, yeah. For some reason, he’s not warming to the idea.

Ryan: he can’t understand the thirty grand, you know, outlay to…

Paul: We’ll easily make that in a day on the app store (all laugh), I keep telling him this.

Sarah: the app store!

Paul: Yeah, the app’s 50p, you know…

Ryan: Er, completely sidetracked there, erm. What differences do you find, er, between developing for clients and developing for yourself? What major differences do you find?

Sarah: I find, when I’m doing stuff for myself, I’m actually a lot less decisive on stuff. I sort of, because I’m immersed in, maybe my own branding, or sometimes it’s really good to look at it from an outsider’s point of view. If you’re doing stuff for clients, I think sometimes it’s easier to look at stuff and go ‘well, that needs to go there and that needs to be there to catch someone’s attention’ or you need to move that or make that a different colour, and when it’s your own stuff I think you tend to be either really creative and you don’t really care if you get stuff wrong, or if, do you know what I mean? It’s more, sort of… the boundaries aren’t there, you’re not time-constrained, there’s no brief, you just go off on one, doing whatever you want, whereas with client stuff, there tends to be a bit more, erm, what’s the word, consistency across everything, and I find, personally, when I’m doing my personal stuff, I could sit in front of Photoshop pushing something from the left-hand side of the screen to the right-hand side of the screen for two hours, wondering whether it looks right or not, whereas if it’s a client site, I think ‘right, I have to make a decision on this – where would this go, or where would it be best placed, and you make a decision and you move on, because otherwise the more time you, you take going backwards and forwards is, er, less money that you’re earning, so I think I tend to be more decisive with client work and with my own I tend to be a bit more, erm, easy-going and, er, possibly a bit more creative, in the sense of trying things that I haven’t tried before. Erm, yeah, I think it’s just good to be (pause – all laugh).

Paul: I think personal projects give you time to play with the stuff that you wouldn’t normally risk putting into a client’s site, things that might take you a week to figure out.

Sarah: That’s what I, sorry a man just walked past my window in a pair of shorts, as I was answering that question, which completely put me off,

Ryan: Was it an ugly man, or a good-looking man?

Sarah: No, he was an old man.

Ryan: Oh, right. OK

Sarah: I wondered if he had dementia or something, and he thought it was summer.

Paul: Was he in just a pair of shorts?

Sarah: Yeah

Ryan: A pair of shorts and a smile?

Sarah: No, and a newspaper.

Paul: Strategically placed.

Sarah: It just completely sidetracked my thinking pattern, then.

Paul: That’s OK.

Sarah: Oh, sorry.

Ryan: Where were we? So, which do you prefer, developing for clients, because obviously you’re doing that every day, or do you prefer developing for yourself?

Sarah: I actually prefer developing for clients, erm. I prefer getting a brief and thinking ‘right, how can I best interpret this brief, and get the objectives that they want, er, they want to get out of this website, how can I do that in the best possible way?’ Whereas, I think that when you do stuff for yourself, you don’t necessarily write down a brief as strict as you’d get when a client is sending through something. So, I, I actually prefer developing for clients, I really like, I don’t, I really like doing all the end, getting to the end product with a client. I think I get more satisfaction out of that than I do when I’ve done it for myself, because I still look at it in a very critical point of view, I still think, ‘oh well, maybe I could make those buttons a slightly different hint of green and it will look better’; whereas, with client stuff I think it’s just all about decision making, I think you tend to make more decisive decisions with client work than you do with your own. You think of your own as an ever-ongoing project that you can forever tweak and make changes to, whereas with client stuff you, once it’s live, it’s pretty much. You might get to update…

Ryan: Yeah, it’s difficult to come back, isn’t it?

Sarah: Yeah. Exactly. So I much prefer developing for clients, when they’re nice clients!

Ryan: Yes, we only like the nice clients.

Sarah: Yes, we all like nice clients.

Ryan: But do you think personal development time is important, do you think it’s important to develop your own projects?

Sarah: Yeah, I do I think it’s important from the sense of being, when I personally do lots of my own stuff, I find that I tend to be a bit more, erm, creative, in the sense of I’ll try stuff that I might think ‘oh, that’ll look awful, I won’t bother doing that for a client site’, but I might try it and actually surprise myself and think ‘oh no, actually, that’s a really good technique to use’ or do something a bit different because you’re not constrained by time when you’re doing stuff for yourself, necessarily. But I think, I do think it’s really important to do your own, your own thing, because I think it’s also a learning curve, you might try out different systems to use, you might decide to learn something, you might decide to use something like, if you’ve never used WordPress, you might decide to go and bolt WordPress onto your site just to see how you get on with it, you might try different apps. I think it’s important, because it frees the mind to use other things that you might not necessarily get to use when you’re in an office environment or, or perhaps even day to day because you don’t have the time to learn it, so I do think it’s important, but I don’t think it’s the, er, the be all and end all of everything.

Ryan: I think, er, a good tie-in question, not specifically about developing for clients and, er, yourself. Erm, keeping it with blogs and stuff, do you allot yourself a, like, time to read your feeds and, er, things like that, and to keep up with them, because I’ve been so busy in the last two weeks, my feeds have just gone like – you know when Google Reader says ’1000+’ and that’s it, it’s just stopped counting, it’s gone ‘look man, give up on these feeds, you’ve passed a thousand.’

Paul: You need to declare feed bankruptcy, I think.

Sarah: I tend to do this really annoying thing, where if someone posts a good link on Twitter, I’ll open it up in a browser window in a tab, and then if someone else posts, I’ll open that in another browser tab, so I’ve got about 100 tabs open in Firefox that I never get round to, to looking at, which slows the whole thing down and end up having to then bookmark them in a little folder called ‘Interesting Links’, that I never get around to reading.

Ryan: When you look back, they’re four years old and completely out of date.

Sarah: Yeah.

Paul: The shocking thing, because I do the research for the, the Boagworld news and push it all through the links, I probably churn through 150-200 feeds a day (Sarah: gasp), which is so many feeds that I haven’t got time to read them, which is shocking; I get so much information, so many good things that I’m pushing out to other people, that I just don’t have time to read them, there’s too much information.

Sarah: Do you skim-read them?

Paul: I do, I skim-read, I usually read the first few paragraphs, just to see what the article was about, clip out the interesting bits of text for the previews and then send it on it’s merry way out of Twitter and then I’ve written a function that, every time someone clicks a link on Twitter, it kind of lets me know, tracks back and so I can see, right, which… and I watch it, I’ve got live stats and streaming on one of the spare monitors, so as this link goes out onto Twitter, I can see it being read, so I can actually what’s actually what the people are reading, what’s been interesting that way, instead of me thinking ‘that’s genius, we’ll use that on the show’. It’s actually kind of crowd-sourcing information like this.

Sarah: Yeah, that’s a better way of doing it, isn’t it? It’s more productive.

Paul: Yeah, but I do the same, it’s like something I really want to read, I’ll open it in a tab and I’ve got the permatabs thing on Firefox, so I’ll set it so that I can’t delete it until I’ve read through it, but usually it just ends up there for weeks.

Ryan: I tag them in Delicious, so I’ve got like tutorials and stuff that I think ‘oh, that looks fantastic’ and I’ve got a ‘to try’ thing, which is slowly increasing in number and I never sit down and have a go through the tutorials or anything like that.

Paul: Yeah, I think the key is to follow a few key, key things and not try and follow too much information, and then just look at what everyone else around you, the people that you respect, in what they’re sending out and try not to get overwhelmed because there’s a lot of information out there.

Sarah: Dead right, there’s so many, it seems to be a new thing on Twitter to actually post those sort of links, day in, day out, which is really handy because there’s a lot of people who have a lot of good stuff on Twitter.

Paul: Oh twitter.com/boaglinks is the premier source of all this information, of course.

Sarah: Of course! (all laugh)

Ryan: Er, OK, so I think the final question to you, then Sarah, is, erm, what inspires you to pursue your personal projects?

Sarah: Erm, oh, that’s a difficult one. I kind of get inspired in strange places, when I came back from the Future of Web Design and Future of Web Apps, I kind of get inspired by other people, not necessarily the apps that they’re producing, or work that other people are producing, but I sort of feed off other people’s energy, strangely. If other people come away from something really, erm, excited about something, I tend to think ‘oh, yeah, that sounds like a good, like when Adobe Air came out, that was a kind of a buzz around that for a while and it got me thinking ‘um, what can you develop with that that would, you know, might be interesting to other people or that other, that other web designers might want to use?’ but that’s kind of what happened with my own app, Olive, it’s kind of on the backburner at the moment, but there was a problem that came up at work and it was coming up time and time again and I thought ‘there must be something out there that actually addresses this issue of, of erm, client management, so went around, couldn’t find anything and then ended up building it, and it was actually built more for me, rather than other people and when I sent it out to a few people, they really liked, and got into using it and, erm, it’s just kind of handy if you build something that’s, that’s great for you, but equally other people find interesting as well. It’s, erm, it’s a win-win, really. I mean, I use it all the time, and there’s other people who do as well, bu
t at the moment it’s, er, needs a lot of updating, because I’ve been so busy with client stuff, but maybe I should have put that first, but clients pay the bills unfortunately.

Ryan: Absolutely, absolutely. I think I, erm, I think I overthink things, so I think to myself ‘oh, I’d love, love for this to exist’ and then I think to myself ‘I could spend the next three years developing that’ and, and someone would do it better than me, you know and just finding time as well.

Paul: Yeah, I think it’s right what Sarah says, you’ve got to scratch your own itch, you’ve got to find something that you would want to use so much that you would spend that amount of time to build it, and then if it’s for you, it doesn’t really matter that much if no one else wants to use it because it does something that you want it to do.

Sarah: Exactly.

Paul: And it’s a learning process, you can choose any language. If you want to learn a new language, if you want to learn Django or Python or something, you could build it in that, just to learn that language, erm, and then send it out in the world, see if people use it.

Sarah: Exactly, that’s kind of what happened. I was learning quite a bit about Ruby at the time, because Olive, Olive’s built on the Ruby on Rails platform and it was so interesting just to get an insight into how different developing with Ruby is compared to PHP. That was just worth it in it’s own right, really because I find that I learn much better with real world examples rather than looking at a load of code. I find that if, if I ever get something like that, I have to take it apart, almost, and then try and work out how to put it all back together so that it works. I think I learn better by doing that and a lot of people do. If you going on to any of the tutorial sites now, there tends to be a lean towards developing an app or something small; I think on the Nettuts at the moment, website – do you guys know that one?

Ryan: Er, yes.

Paul: Yes, ah the Nettuts, oh yeah.

Sarah: Yeah, there’s a, there’s a sway towards actually building like login systems from scratch and things like that on there, where it’s actually showing you the code and then showing you how it works in real world situations which I think is really good, for me, I don’t know about you two, but I personally prefer picking stuff apart (laughs).

Paul: Yeah, absolutely. I usually start at the very lowest common denominator, like a user access system, and I’m learning CakePHP now which is, kind of a Ruby clone for PHP and instead of using their in-build methods which will do it all for you with build this, just write these classes and it’s like ‘No, it’s like the most basic thing I can do in this language, let me learn how to do it’, and I’ll learn that way.

Sarah: Yeah, yeah, that’s, I think when, erm, when I looked at using Ruby for, er, for Olive, I didn’t build it, it was built by a guy, a brilliant guy, Adam Cooke, but I was still really interested to know how it would work and how Ruby is different and the first thing I did was built a, erm, a basic recipe, sort of database thing with, it was off of a tutorial site and I think it’s great if it gives you just a little bit of insight into something that you might not have already realised or known about building your own stuff, then I think you have that sort of passion to go forward with it, you have that confidence to then think ‘oh, well I’ve done that tiny thing, maybe I can do something else with it. Whereas, if you’re doing it for clients, you don’t, you wouldn’t really venture into using another programming language that you weren’t comfortable with on a client site, unless you were a bit silly.

Ryan: Absolutely, absolutely. Paul told me a really funny thing, in between, er, when he told me he was learning CakePHP. He said, I’m trying to remember what it was that you told me, it was ‘if Ruby’s French, CakePHP is French with an English accent’

Paul: Yeah, its kind of the same, just not quite as elegant.

Ryan: Yeah, I thought that was fantastic, that was so fantastic, I made it into, I have some rotating quotes on my web-site, and that made it into my quotes, that was fantastic.

Much thanks goes to Simon Douglas for transcribing this interview so quickly!

Back to top

Listeners Questions:

Is Using Off-The-Shelf Software Wrong?

Jon Writes:

I guess my question is about the use of off-the-shelf software. I must admit I feel slightly uncomfortable using it at all. As a decent sized agency of 9 people, with our own very capable developers, I can’t escape the nagging feeling that we are “cheating” slightly by using an off-the-shelf platform at all. Although we adhere strictly to licensing requirements, most of our customers do not know that their stores are powered by what is essentially a ready made system, which we then skin, configure and populate.

What are your views about off-the-shelf stuff and the pros and cons of using it on client work?

Thanks and keep up the good work!

I think the main source of your discomfort is the fact that your clients don’t know you are using off-the-shelf software for their projects, which raises the question why not?

Your clients have approached you to provide them with a service they cannot perform themselves. Whether that is building a system from scratch or integrating and customizing an third-party system to meet their needs, you are still the expert.

There are very powerful off-the-shelf e-commerce systems, blog engines and CMS’s that should be thought of as weapons in your arsenal rather than “cheating”. Explaining to your clients why you are going to use a particular system for their project can be hugely beneficial. It shows that you don’t want to waist their time and money re-inventing the wheel.

Therefore, the pro’s are:

  • It meets there project aims
  • You are experienced with the system
  • It’s supported by a third-party team of developers who are dedicated to that one product and includes a vast community of other users who support each other
  • It can be implemented in a shorter period of time than building from scratch (i.e. cheaper for the client all round)
  • It’s a tried and tested system (You could even give your client a list of other successful companies that are using it)
  • It is also more than likely that a third-party product that has been around for several years is a more reliable and robust system than the one you develop in a couple of months.

That said there are always inherent risks in using anything third-party, whether it be API’s, frameworks, libraries or software and I have a general rule of thumb that I try to always adhere
to:

Don’t implement something you don’t understand!

If it breaks, it costs you time and money to fix the problem, and that’s once you’ve diagnosed what that problem is. The longer it takes you to fix the higher the risk that your client is going to lose confidence in your ability to deliver.

So take the time to do some dissecting and learn how to use your tools as fully as you can prior to implementation.

How do you price and quote different projects?

Jamie who’s just started up his own web development company is having trouble working out how to price and quote different projects and wonders if we have any tips that we’ve found helpful when quoting for clients?

One of the hardest things when starting out, and even for established businesses is finding your feet with pricing. I think the biggest lesson I learnt is not to under-quote just to gain the business, even though you are in need of clients. It makes no business sense to work for peanuts, you’re better holding off for a client who respects the work you do and pays honestly for that work rather than being a design machine churning out work just to make ends meet.

The other important thing I learnt in my first year of business is, clients who barter with your prices are generally bad news. We’ve all heard it, “if you can do this one at x-amount we have plenty of other work in the pipeline we want to use you for” – while this sounds tempting, 9 times out of 10 the promise of the further work never comes off, even if it does they would normally expect further work at the “cheap” price they paid you before, as you accepted it so you must be happy to work for that right? Wrong.

I always find it helpful to ask the client for a ballpark figure prior to laying out the full proposal, this negates you wasting time putting together the proposal of cost plus terms and conditions only to find the client wants to build ebay on a budget of £300.

I also find ballpark figures helpful because I find it easier to provide the client with options, even if they have a relatively small budget there is normally still something you can do, even if it is very basic – but it gives you a starting block to explain if their budget was a bigger they could bolt on a CMS system or have a better shopping cart, then explain the benefits of those. You’d be suprised how much the budgets are then increased by.

It’s all about providing the client with the best solution for their project at the end of the day, and if you think the best solution would be bolting on Expression Engine or the like, you need to give the client the choice to do this and expand their budget if necessary rather than cut them out of the equation because of it, it’s all about educating the client.

10 tips for efficient design

Being a good designer is not always enough to survive hard economic times. You need to be efficient too.

I don’t want this to be another ‘recession’ post. Sure, being more efficient in the way we work as web designers, makes us more competitive and keeps us employed. However, that is not the only reason we should endeavour to ‘work smarter’.

Working as efficiently as possible brings other benefits too…

  • More time – The faster you can turn around work, the more time you have for personal projects, family and friends. I don’t know about you but this is a major motivator for me.
  • Better promotion prospects – It takes more than good design skills to be promoted. You need to demonstrate that you are proactive and efficient in the way you work. Management will value you more if you generate a higher return.
  • Increased profit – If you are a freelancer it is all about maximising profit. The smarter you work, the more money you earn. It’s that simple.

So how can you be more efficient and begin to work smarter? Here are 10 tips that will get you started.

1. Use snippets

Coda Clips Palette

Let’s start with the obvious technical stuff. First make sure you have a library of code snippets that can be easily reused. These could include Eric Meyers CSS Reset or your own code for dealing with common HTML content such as news listings or pagination.

These libraries of snippets provide two benefits. First, they save a lot of typing. However more importantly, they ensure consistency across projects. Because you are using the same code for each project, all of the IDs, classes and structure remain consistent. This will save a lot of time when trying to remember why you built something in a certain way or how it works.

2. Use a Javascript library

In a similar vein to snippets I would highly recommend you adopt a Javascript library. Personally, I am a huge fan of jQuery because it is designed for those familiar with CSS. It is also amazingly easy to learn and very lightweight.

Using a library like jQuery has proved a massive time saver for me. It has allowed me to avoid endlessly battling with browser inconsistencies (at least in Javascript!) and avoid reinventing the wheel.

jQuery Homepage

jQuery (like most Javascript libraries) also supports a large number of plug-ins produced by third parties. These too can be a massive time saver. However, a word of warning – be careful using a plug-in you do not fully understand. The quality of plug-ins varies massively and if you discover a problem with one, you can waste many hours trying to fix it, if you do not understand how it works.

3. Configure your tools properly

Often in our haste to ‘get on with a project’ we fail to take the time to prepare properly. One example is in how our software is configured. We settle for working with tools ‘out of the box’ when some minor modifications could improve our efficiency.

Photoshop is a good example of this. It has all kinds of configuration options from keyboard shortcuts to palette layout. Take a few moments to set these up for your workflow, and you could save hours of unnecessary clicking over the long run.

Photoshop Palettes

Look at whatever tools you use to build websites and consider how their interface can be tweaked to your needs.

4. Have one system for tasks

For fear of reinforcing a stereotype, designers tend not to be the most organised people. Not only do we need to organise the structure of our software tools, we also need to do the same for our projects.

Fortunately, not all of us have to manage entire projects. However, we do all have tasks that need completing. How we organise those tasks can dramatically affect our efficiency.

A common mistake with task management is to have tasks spread across multiple places. Some tasks exist as emails, some in a todo list, still more in a notebook or on your mobile phone. The result is that things get overlooked.

In order to efficiently manage your tasks they need to be gathered into a single central location. For me that is a task organiser called Omnifocus, which syncs between my desktop and iPhone.

Omnifocus Screenshot

Tasks are still collected using multiple methods. However, once a day I transfer them to Omnifocus. If I attend a meeting and take physical notes that include tasks, I put the notebook into my in-tray until I can add the tasks to Omnifocus. If I receive an email with a task, I drag that email into Omnifocus. Ultimately everything ends up in Omnifocus.

By being this regimented about the way I organise tasks, I ensure nothing ever gets missed. I also avoid wasting time trying to track down the details of a task I have lost.

5. Embrace and manage admin

Inbox Zero - The original 43 folders series

Part of the problem we face is that answering email and organising tasks feels like a waste of time. Its not ‘proper work’. This is especially true when the pressure is on and deadlines are tight. We arrive at work in the morning and launch into our projects without checking our task list. The result is that we prioritise the wrong work and miss deadlines.

I begin each day by doing two things. I answer and file all my emails (I always achieve inbox zero). I then review all of my tasks and identify the ones that I wish to complete that day.

However, I don’t stop there. I have designated admin time. Once I am done my morning review I close my tasks and email until lunchtime. I focus solely on work and avoid admin entirely. This prevents email and other admin from interrupting the flow of my production work. It keeps me focused.

6. Distractions must die

TweetDeck

Of course it is not just email that distract us from work. There is instant messaging, Twitter, Facebook, RSS and… lets face it… the entire internet!

Don’t misunderstand me, some distraction is good. I have a very short attention span and so if I work on a single thing for more than about 30-40 minutes I start to ‘zone out’. However, there is a difference between ‘having a break from work’ and ‘getting distracted’.

Every 40 minutes or so I will take a 5 minute break and fire up Tweetdeck or Google reader. What I try to avoid is keeping these applications permanently open (although with twitter I have to confess I often fail).

By leaving an application open that can distract you with notifications (‘You have a new tweet’, ‘You have mail’, etc.), you risk it interrupting your flow of work. These constant micro-interruptions make it hard to ‘get into the zone’.

7. Keep a tidy environment

Distractions extend beyond your PC as well. Your work environment can also have an impact on efficiently.

If you work from home, endeavour to keep your personal and work life separate. Ensure you can close the door on the rest of the house and that the rest of the family know not to interrupt. Also if possible, try to keep your working area separate from the rest of the house. A garage or loft are ideal. I used to work in a small room directly between our lounge and kitchen. It was impossible to focus on anything with the constant noise from the two rooms.

My Desk

Pay attention to your desk as well. Keep it clean and uncluttered. This reduces distractions but also creates a better mental state conducive to work. Ensure your physical files and disks are easy to find. Knowing you took some notes that are in a notebook somewhere does not make them easy to find. This is especially true when your desk is three feet deep under paper work!

Personally I scan what notes and physical paper I can. What I have to keep in physical form, I file in a single filing cabinet organised alphabetically.

8. Avoid multi tasking

There is a myth that multi tasking makes you more efficient – it doesn’t! As designers we like to ‘flit’ from one thing to another. However, ultimately this is damaging to productivity. We need to learn to focus on a single task and follow it through to completion.

As I have already said, I find it hard to focus for any length of time. In order to help me focus I break my tasks down into smaller ones. That way I rarely have to do one thing for too long. Take this post for example. To write the whole thing from beginning to end would take a couple of hours. That is longer than I could focus for. So, in order to stop me getting distracted and jumping onto another task, I break it down. This post was made up of three tasks…

Task List: Create an outline, write initial draft, add imagery and edit

Once I complete one task, I switch to another project for a while. Once I have completed a task on that project I may switch back to this post.

Although this is a kind of multi-tasking, it is more structured and ensures I spend as long as my attention allows on each project. I do not simply drift between projects.

Depending on your character this might be too extremely. You may find it easy to concentrate for extended periods. However, if you struggle to concentrate, do not use multi-tasks as an excuse to be distracted.

9. Don’t do excessive hours

Another widely held myth of productivity is that the longer you work, the more you get done. After all, on face value this makes sense. However, I sincerely believe this is not true, especially if your job relies on you generating ideas and being creative.

Obviously we have to put the hours in, if we want to pay the bills. However, do not allow your boss or clients to force you into excessive hours. The occasional all-nighter is one thing, regular 12 hour days is another.

It is incredibly easy to get burnt out as a web designer. You are expected to continually be creative, as well as keeping up with one of the fasting moving sectors on the planet. Things are continually changing and evolving and it is a struggle to stay current.

Twitter post of somebody saying they are burnt out by work

Working long hours damages your capability to take on board new information and cripples creative thinking. Ensure you limit your hours and book regular holidays. Do not push yourself too hard or you will fail to deliver.

Finally, accept your natural cycle. When you are ‘in the zone’ work every hour God gives you. However, you must also accept that sometimes you need to just stop and rest. Don’t feel guilty about the days when you hardly do anything.

10. Communicate better

I would like to end this post with possibly the best efficiency tip of all – If you want to avoid wasting time, learn to communicate better.

So much of our time is wasted because of miscommunication and misunderstanding. How many times have you had to redo a design because you misunderstood the client or showed them work too late in the process.

Take the time to really engage with the client and understand their requirements. Make sure that you include them in the design process and show them work often and early.

Example Mood board

Finally, use tools such as gallery sites, mood boards and sketches to ensure everybody has the same understanding and is working towards the same goal.

By effectively communicating with clients, you can potentially save days on each project that would have been wasted on reworks and amendments.

If you recognise that the mobile web is important and you need help deciding on a strategy, then book a mobile consultancy clinic.

Book a consultancy clinic or contact Rob about a more in-depth review.

150. User Manipulation

On this week’s show: Liz Danzico talks about user research. Paul explains how to create an effective call to action and we discover how one button cost $300 million in sales

Download this show.

Launch our podcast player

News and events

The $300 Million Button

Our first news story is an incredibly tale from usability expert Jared Spool, which really shows the power of usability testing.

In the post he writes about a client who had a fairly standard checkout process on his website. The process began with a login form:

The form was simple. The fields were Email Address and Password. The buttons were Login and Register. The link was Forgot Password.

It is the kind of form I have seen on many ecommerce websites. This feature, which had been designed to help repeat customers, created two distinct problems:

  • New users resented the idea of having to register. One user said: "I’m not here to enter into a relationship. I just want to buy something."
  • Repeat users rarely remembered their username or password. They wasted substantial time guessing, before eventually resorted to creating a new account. In fact after examining the database Jared discovered that 45% of all customers had multiple registrations. Some did go as far as clicking on the forgotten password link but of those only 25% went on to place an order.

In the end the site was redesigned, allowing the user to continue without registering. Within a year this created a $300 million increase in sales.

Of course $300 million is a meaningless figure in itself. It is the percentage increase that matters. In this case is was a 45% increase. That is a staggering number and one that really drives home the importance of testing with real users.

Read the ‘$300 million button’

The UK government and graded browser support

A couple of weeks ago I wrote about the importance of graded browser support. In my post I explained how we should not limit our support to the browsers we test and how it is unrealistic to push for identical support across all browsers.

This is an approach which has been adopted by the likes of Yahoo! and the BBC for some time, but which now also extends to public sector website in the UK.

According to The Web Standards Project the rules surrounding browser testing on public sector websites have been changed to better reflect best practice in graded browser support.

Changes include an emphasise on functionality over identical layout across browsers (paragraph 39):

You should check that the content, functionality and display all work as intended. There may be minor differences in the way that the website is displayed. The intent is not that it should be pixel perfect across browsers, but that a user of a particular browser does not notice anything appears wrong.

As well as support for progressive enhancement (paragraphs 17-18):

You should follow a progressive enhancement approach to developing websites to ensure that content is accessible to the widest possible number of browsers.

This is excellent news and certainly provides a great reference for UK designers and website owners looking to convince others of the importance of graded browser support.

BBC Graded Browser Support Table

Read the UK government guidance on browser testing

50 Illustrator tutorials

List of Illustrator tutorials

From development to design now, and a list of 50 tutorials that help you get your head around Adobe Illustrator.

The list is compiled by UK web designer Chris Spooner. He echoes my own experiences when he writes:

Adobe Illustrator can be a little tricky to get your head around, particularly after getting used to the workflow as applications such as Photoshop. The difference between layer use and creating and editing shapes can be especially strange at first hand.

I am a Photoshop man and I have found it very difficult to make the transition to a vector based world, so this list was particularly appealing to me.

Its a great list that you will definitely want to check out, if like me you have never got to grips with Illustrator before.

Read 50 illustrator tutorials every designer should see

A new approach to PNG Support

Finally today I would like to draw your attention to a new technique that has been developed by Drew Diller for using PNG transparency in IE6.

Unlike previous techniques this one allows you to use PNGs as background images instead of just as IMG tags. This opens up a world of possibilities and overcomes one of the most annoying limitations of IE6.

This minor miracle is achieved not by using AlphaImageLoader as has been done in the past, but with VML.

Implementation seems fairly straightforward and involves adding a Javascript library to your page. Because this is for IE6 only you can embed the code within a conditional comment. This means other browsers will not even download it.

Although I have yet to use this approach myself, I have high hopes that this will finally solve the IE6/PNG barrier.

Download DD_belatedPNG now.

Back to top

Interview: Liz Danzico on User Research

Paul: So joining me today for our little interview is Liz Danzico. Liz, why don’t you start off by introducing yourself a little bit. Telling us a bit about yourself and your background.

Liz: Sure. Um, I am a user experience consultant, I am here in New York City, I have been developing web sites and user experiences online for about 12 years now. Um, I do a lot of work with Happy Cog Studios here in New York, with Jeffrey Zeldman and Jason Santa Maria. Um, I’m also chair of the new MFA interactions design program.

Paul: Okay.

Liz: At the School of Visual Arts in New York.

Paul: Excellent. I mean, so, to say that you’re an expert in user experience would be a slight understatement then, Liz.

Liz: Well I wouldn’t go that far.

Paul: You’d be too modest, obviously, to say that. Okay, so we got Liz on the show, I met Liz when I went to Future of Web Design and we got talking. Um, she’s got some fascinating insights into the whole area of user research, and usability generally, so I thought let’s get her on the show and let’s maybe, you know, try and cover things from, from the very basic level, a kind of introduction to this concept of user research. Um, so, perhaps a good place to start, if you’re okay Liz, um, would be, how would you go about defining the area of user research? What would you include, what would you exclude from that?

Liz: Right. So … user research, even today, we’ve been doing user research on the web since, uh, the very beginning, so it’s a very old concept but it’s still fairly controversial. So the basic concept is it tells you what really happens when real people interact with your product or service. So, there are no real rules about what it includes and what it doesn’t [inaudible]. You can basically speculate about what your users want, or you can find that out, um, you know? And uh, and the, uh, the latter is probably a more useful approach for you to take than speculation. But with either one, thinking about your audience is useful no matter what. And so, so there are no real rules, now um, when you disconnect thinking about your audience from your business objectives, and you start getting, you know, very excited about behaviors that they’re doing that are sort of disconnected from the real mission that you’re trying to sort of accomplish, then it becomes, um, a bit murky, and confusing. But thinking about your audience is, just in general, is an extremely useful approach.

Paul: Okay. I mean one of the things that, that, um, I’ve heard said before by, particularly cynical clients I have to say, but I’ve heard it said before, you know, ultimately user research, and all of this kind of stuff feels in some ways like, um, just another way for web designers to suck a bit of extra money out of us, you know that fundamentally how, I know my audience already, is the kind of attitude that many web site owners have, so why do you see it as an important part of the process?

Liz: Well uh, you know, as we’ve been seeing design flaws often translate to lost business opportunities, you know, usability is becoming more important than ever as the number of web sites and products is, you know, increasing more and more every day. So, we design these products and services, and we are at the same time users of them, but there’s no way that we can really tell what are users, um, might want. And the best way to, you know, usability research doesn’t cost a lot of money, so, the best way that you can help your clients kind of understand that you need to do usability research in some way is to let them know that usability research is important and it doesn’t need to, um, suck up a lot of time or money in the, in the process. So there’s a great fantastic book by Steve Krug, called Don’t Make Me Think, which I’m sure you’re probably well aware of.

Paul: Uh huh.

Liz: And in one of the chapters towards the end, he has a chapter called "Usability Research on a Shoestring", or it’s probably better titled, which talks of this approach of going out into the hallway and kind of grabbing people, and just sitting them down, and putting them in front of your product or service, and getting some feedback. So getting some feedback from people, no matter who they are, is better than getting none at all. And so, I think starting there with clients, instead of the, you know, $100,000 user research project that’s going to take you across 8 markets, you know, in the United States, the UK, and Asia, then, is going to be a much better approach than kind of intimidating them with the very extensive projects.

Paul: Mmm, I mean, when it, the kind of one scenario that I’ve come across before, um, is where we’ve come across with clients that say "Well we’ve already done user research, we already know our audience ’cause we’ve got somebody in to do this or that." Is there a difference between user research that’s been done primarily with an offline audience, and those with, you know, when you’re interacting with people online? Is there a difference in the kind of results and information that you’re after, and even the techniques, maybe, that you use?

Liz: So, they are probably, when they say that they’ve done user research, they’re probably talking about focus groups. I would venture to guess that when they talk about that they’re probably talking about either focus groups or surveys of some kind and those are not, well, I wouldn’t say that they are, those are bad things to do, but those are not the kinds of user research techniques that are going to give them feedback about their product’s usability. Those kinds of techniques are going to give them good information about, um, certain kinds of things but they are not going to give them information about whether or not people can use the product or service that they’re looking at. So, you want to find out exactly what kinds of user research they’ve conducted. If they say the words "focus group" then you know you want to move them towards something that is a one on one kind of interview. Focus groups tend to be conducted with groups of people, as the name might suggest, um, and when groups of people get together to talk about, you know, they put forth a question for these people, and when they, you know, groups of people get together to talk about the question they might influence one another in their answers, they’re typically aren’t talking about an interface, they’re typically talking about ideas, so you’re not getting good feedback, like in a one on one kind of scenario. So you want to sort of guide them to a more individual, one on one kind of experience. Surveys, on the other hand, are good, but they don’t get that kind of personal experience with a moderator, sitting with an individual, kind of looking at an interface in a kind of task-based scenario.

Paul: Okay, yeah that makes a lot of sense. I mean, let’s then talk about some of the techniques that can be used to better understand individuals, or how those individuals will interact with your product. What different kind of techniques do you use? I mean, there’s the kind of very basic usability session, but do you do, or are there other things above and beyond that, that you do?

Liz: Right. Well, the sort of big secret is that, there are names and there are certainly techniques, but the big secret is there are really no sort of techniques beyond knowing who your users are, kind of documenting what you’re seeing, and then kind of analyzing/prioritizing the results of what you see. So, you can, I’m gonna tell you a number of techniques that we can go through, but if those basic sort of constructs are there, then you’ve done sort of good user research. Now, that being said, the techniques that you can do are usability testing, usability testing traditionally has taken place in a user lab where a moderator is sitting with an individual looking at a screen, or a product, or a sketch of an interface and going through questions in sort of a task-based way, asking people "Show me how you would search for x" or "Show me how you would check out," or, you know, and seeing, measuring the success or failure of that kind of task. The clients are typically sitting behind a one-way, a one-way glass, or mirror, and observing these kinds of things. People have been not so thrilled about this technique recently, saying that it kind of, um, is not, it doesn’t produce natural reactions from users, but that is one kind of technique. There is, uh, kind of creating personas, and using personas, user personas which are an archetype of your site or product’s users, and getting everyone involved in activities around those personas, whether that be using those personas as your talking through features around, you know, a brainstorming session, and getting people to sort of role-play those personas. That’s another user research method. There are, there’s sort of the ethnography kind of take, where a lot of people have been doing kind of in-home interviews and observations recently. Ethnography, cultural anthropologists and people who have been doing traditional ethnography have been watching closely the design research that we’ve been doing recently, and wondering if we’ve been doing it right and so on, but ethnography, in that sort of observing users in their "natural environment", has been I would say a more successful way recently of watching people use products and services, um, so I would say that those three things, usability testing in a lab, sort of using personas and scenarios, and ethnography or kind of going out into the field and watching users, whether they’re in their homes or their offices, are the three kind of key ways to gather user research with users. The fourth way that I’ll mention, and we can talk about this in a little bit, is not with users directly, but it is certainly user research that’s available more and more now, and that is data on sort of analytics, which you can gather from Google Analytics, Shaun Inman’s Mint, these kinds of things. Watching site data and user behavior through site analytics is another form of user research that gives you, you know, some information, and you can watch these traffic patterns on your site. It doesn’t answer the question "Why?" but it does show you some evidence as to how users are behaving on your site.

Paul: It’s quite interesting that you bring up eth, ethnography, whoa I can’t even speak today, because, that’s of interest to me, because that’s an area that we’re beginning to explore a little bit more, and have kind of discovered the same thing, that there’s a real value of going into you know, somebody’s home, seeing the environment that they access the internet on, you know, do they have kids under their feet? You know, where they access their PC, can they sit comfortably at it? All those kinds of things. Um, I guess it’s also an advantage you don’t have to hire an expensive usability lab and all of the rest of it. But I have to confess, I’m a little bit new at it, so talk me through maybe some of the things, you know, how does it differ from a usability test that you would do in a usability lab, other than that you’re in a different environment?

Liz: Well, uh, it depends. It doesn’t have to differ at all — it depends on the goals of the test. I would say that you could construct a test that’s exactly like one that you’d conduct in a lab, it just happens in someone’s home or office, or in a different environment. But as you said, you get the more realistic interruptions, and that kind of thing, and are they going to be able to complete this task given the natural kind of occurrences of their day. And that, depending on what kind of test you are constructing, that’s either going to inform your results or not. If you are doing task-based testing, so I could maybe talk about the different kind of usability testing that you could do.

Paul: Yeah, that’s good.

Liz: Yeah so there are different ways that you could conduct a usability test. Um, traditionally there is task-based testing, where you set up pre-written questions, before you get to the test, that are based on the goals of the testing. So, if we were testing a photo site, we would test whether or not users could upload photos, could they task photos, you know, those kinds of things. So we would write those kinds of questions up beforehand, and then ask those questions during the test. Um, that’s one kind of test. You could do that in a lab, and you can do that same test in someone’s home. In a lab there would not be the children screaming, and the phone ringing, and that kind of thing, or, if someone say were uploading a photo, you would never be able to tell if sort of, timing out, would be an issue, or if anything with time or space or motion would be an issue. If those kinds of things are a goal of your test, then you might want to think about doing it in real time, in someone’s home environment. Another type of testing is something that, I’ll say it was first coined by Mark Hurst, who is a user experience consultant at Good Experience, I think he coined it, it’s called "Listening Labs". Listening labs are, I’ll call them experimental, but they’ve probably been going on long before I was aware of them, where people are designing usability tests in real time. So in other words, you go into the test with absolutely nothing written down, and you sit down with users, and based on your initial interview with them, you hear who they are, and after understanding a little bit about how they use photos in general, say, then you kind of write the questions on the fly, and then sort of develop a test around who that person is and their behavior, with your product, or product type.

Paul: Which I guess, makes people more engaged with the test, because it’s about what they specifically interested in. Is that the idea?

Liz: Exactly. So it’s a more natural way of doing the test. That’s the idea. That kind of thing you could do either way, and probably is even more rewarding if you’re doing it in someone’s natural environment. And then the third type of test is sort of a web, a web wide kind of test, where you have people just surf the internet, as it were, and uh, and just have them think out loud, and that kind of thing is also, I’ve found, more rewarding and fruitful in someone’s home environment, because they have their bookmarks there, and they have their post-it notes. Whereas you put them in a sort of artificial setting and they don’t have those things around them. So, if you, it kind of just depends on the type of testing that you’re doing. If you’re doing just the first kind I talked about, just task analysis and having people go through that kind of task-based testing, doing it in a traditional usability lab is great, you know, I mean you really do get the answers that you’re looking for, and it just depends on your goals.

Paul: I mean, it’s interesting, going back to Steve Krug’s book that you mentioned, I mean he talks about, I guess his agenda in that book is to get people to do testing who perhaps aren’t previously, and so, you know, he really downplays the demographic of who it is that you test, and that it’s more important that you test than that you get the right people, you know and all of that kind of thing. Um, but when you’re going into somebody’s home, and interacting with them, I’m guessing it’s more important to get the right demographic? Is that right?

Liz: Yeah, I mean one of the, um, I think it’s always important to, it’s always important to get the right demographic. Um, but, well I would say that there is a hierarchy of common mistakes around usability testing that kind of has a trickle down effect. You know, the number one mistake is not conducting any research at all, um, and conducting research on the wrong audience is kind of further down the list. So, you know, yeah if you’re doing research on the wrong audience, it’s not going to affect, whether you do it in a lab or you’re doing it at your desk, or at the water cooler, or at home, it’s going to affect your results and your analysis, you know, no matter where it takes place. So, you know, I think that the drawback is you are going to waste more time going out to that person’s time going out to that person’s time, so it’s going to be a drawback for you, but I don’t think that, it doesn’t matter really where it happens, because if you’re testing on the wrong audience, you’re testing on the wrong audience. Um, you’re probably going to get more information out of that experience if you’re in someone’s home, than if you’re not, so if you’re going to test on the wrong audience, do it in someone’s home, because you’re going to, it’s a richer experience, you’re going to get more information out of it than if you’re just testing in a lab.

Paul: No that makes perfect sense, I kind of see that. No, it’s difficult, isn’t it? Because, uh, obviously finding the right demographic of people, and picking the right people to test on is tricky, you know, it’s a more difficult thing and it can be time consuming. So have you got any advice about that? What really matters here? You know, for example, if you’re designing a web site for an over-60s audience, you know, are you, do you want to concentrate on the age aspect of that? Or the technical literacy aspect of that? You know, is it okay to have somebody younger if they’re not as good with the internet, if your audience is, do you, I’m kind of not wording this very well, but you get the idea — what’s important when you’re trying to match demographics?

Liz: Um, well, it’s very specific to your clients. Developing a, so, whenever you are trying to match demographics, you want to work with your clients to develop what’s called a screener, and a screener is a, I would say, whether you’re trying to develop a pretty rigorous recruiting demographic with a professional recruiter, to say, recruit 300 people for an extensive study, or whether you’re going to go out into the hallway and grab some people, or whether you’re going to recruit from something called Craigslist, which a lot of people are familiar with, um, which a lot of people do, I would say developing a screener which kind of outlines your demographic is a really good idea.

Paul: And what kind of things would that include? Sorry I interrupted you.

Liz: Yeah, what a screener is, it kind of goes through, it’s a questionnaire that outlines a number of questions that you would ask a potential recruit, that says, if this person can answer a particular question we should keep them in or out, so it’s actually a really good exercise to go through that allows you to kind of think through the type of demographic that you would have. So that doesn’t answer your question in any way.

Paul: It’s very interesting, though. Can you give me an example? Sorry, I’m interested in this screener thing, cause I haven’t come across it before. Can you give me an example of the type of questions? I mean obviously they’re going to be specific to the individual client, all the rest of it, but what kind of questions?

Liz: Um, what kind of questions? So, let’s see, would this person, so, let’s see, has this person, I mean typical questions could be around financial demographics, age demographics, you know the sort of typical things. But let me think of some more interesting things. So, is this person a full-time student? Has this person been fired from a job in the last 6 months? Has this person participated in usability research in the last 6 months? Those types of things, so if the person answers yes or no, then they’re not a good candidate. But there are other kinds of things you could put into that screener that would be more specific to the project.

Paul: So could it include something like is this person aware of a certain brand, because you want to associate with that brand?

Liz: Absolutely, so does this person drink Coca-Cola on a regular basis, yes or no? That kind of thing. But I’ve found that the screener, because the clients that you work with are often kind of speaking in those terms about their audience, the screener is a really good way to kind of help them understand how you’re recruiting audiences, and a good tool to kind of work together with them to narrow down who you want to be in the target audience for your testing, or your research in general. So, that said, how do you develop a good kind of set of participants for a research study for, say, a product for people over 60? Um, what’s most important, you know it depends on, and I know I hate to say that it depends, but you’re going to develop a goal for the testing, right? And the goal might be about usability, the goal might be about navigation, it might be about design, it might be about, it’s going to have, you have to first identify the goal, and depending on what that goal is, then you can identify the audience. So, the audience, you know the goal might have nothing to do with age, although the product has to do with age. So you can kind of strip away, you can pull apart the product from the goal of the testing a bit, and sort of just focus on the goal of the test. That’s why developing goals for user research is so critical, um, because often times you can separate those and therefore develop a better set of participants for that user research.

Paul: Mmm, that’s really good. I think what we’ve done here, is, a lot of people that listen to this show probably have a basic understanding of user testing. Maybe they’ve done some basic user testing before, or maybe they’ve even written a persona before, but I think what we’ve done, or what you’ve done, is push people a little bit further to kind of consider it in a little bit more detail what they’re doing in order to kind of refine the results that they’re getting back, and that’s really, really great. I mean, if somebody has just kind of done the very basics, you know, they’ve grabbed some people, they’ve done some user testing, maybe in their own office in front of their own PC, and they’ve got a few people in, um maybe they’ve created a couple of personas, what’s the next step for them? What should they be pushing? Is it through this screener? Is that the number one thing they should be doing? Is the goals more important? Is getting a better demographic more important? What’s the kind of next step for them?

Liz: Mmm, that’s a good question. I think that one of the most, well, doing the research is really key. Analyzing the research and connecting the research to the next iteration of a design is also key. We haven’t talked about that at all.

Paul: No, we haven’t, we ought to.

Liz: It’s often a grey area, um, you know there are lots of reports that are produced, you know, diagrams and things, but there’s a lot of kind of intuition that happens between sort of translating the research and putting that research, feeding that research back into the design. There are hunches, leaps of faith, um, you know kind of between that analysis and design. I mean there are clear cut recommendations that one can make, but then there are a lot of more grey areas. So I would say that, I still think, even though I mentioned we’ve been doing this kind of research for at least, you know, more than a decade online, and you know quite a long time offline, I think we still need to get better at the rigor at which we translate those recommendations and findings. So that’s one place I think we need to focus. Um, in terms of the actual research itself, uh, you know, there’s something, I think there are other sorts of techniques. I’m interested in these kinds of emergent, I would say emergent techniques like the listening labs, um, you know where the kinds of things that we’re looking at today with kind of mobile research, where people are, we need to be looking at how people are using our sites not just in the browser on their desktop but, you know, in the browser on their phone, and how their context is changing constantly and how we need to sort of look at that adaptation. So how do we develop tests that are more emergent and can be a bit more flexible, rIght? So I think there’s something interesting about that listening lab, where we kind of understand the person, and then develop the questions around a person and how they use a product, rather than having a pre-written set of questions. So, something that’s more emergent, I think that’s an area that’s interesting to kind of look at. Then, uh, ethnography, really understanding, goes right along with this sort of, emergent, as you said you’ve been getting more excited about ethnography as well, so, thinking more about kind of fine-tuning our approach to people’s own context, whether that be ethnography, going into their homes, their offices, you know, where people are using our products, whether that be on the street, in the hallway, wherever it is, but really understanding how to find people where they’re using our products and test them or do some research around that, I think that’s really exciting and a really interesting opportunity. Um so that, that’s the next step for us, uh, and I think that the way that people are designing tests and doing some usability testing now, is, you know, is good, I don’t think that there’s a big next step that we can all take together, but I think these are three areas that I think as a discipline that we’re going to see people moving forward together in.

Paul: Excellent. Let’s finish off, then, with a kind of where people should go if, you know, they’ve been excited by this interview, they want to learn a little bit more, um, about user research and user testing. You’ve mentioned Steve Krug’s book. What other resources are out there that people should be looking towards?

Liz: Well, let’s see. You know, I was thinking about, I was thinking about that and there are physical places that people can go, but they’re all in San Francisco in the United States, so that’s not going to help anyone. There is, you know, A List Apart has a User Science topic that often publishes user research related methods-like articles, there’s always BoxesandArrows.com which publishes user research related topics, um, Adaptive Path, which is a user research consultancy, or at least one aspect of what they do, they have published a number of articles but they also do events. A lot of events are in the United States right now, but they may have international events as well. But they do kind of give away a lot of their content. Um, and then last but not least, there’s a new-ish publisher called Rosenfeld Media, and the books that Rosenfeld Media publishes are about methods in user experience and, one recently in web form design, was about the usability of web form design by Luke Wroblewski (called Web Form Design: Filling in the Blanks).

Paul: Yeah, I saw that. That looked very good, I have to say.

Liz: Yeah, so that’s something to keep an eye on as well.

Paul: Excellent. Thank you so much, Liz, that was absolutely superb. And I will be fascinated to get you back on the show in the future to talk more depth about some of these issues. Thank you very much for your time, Liz.

Liz: My pleasure.

Thanks goes to Jason Rhodes for transcribing this interview.

Back to top

Listeners feedback:

Every website should have a call to action, a response you want users to complete. But how do you encourage users to act? How do you create an effective call to action. Read More

Back to top

Snape and Keith, separated at birth?

146. Obsessive

On this week’s show, Paul interviews Nicholas Felton about designing with data, we celebrate the return of 24Ways, and explain how community can keep users coming back for more.

Play

Download this show.

Launch our podcast player

Housekeeping

Two pieces of housekeeping before we begin:

  • First, Jaysone wrote in asking about the chat room we mention on the show. He wanted to know what it was and whether anybody could join. The chat room is associated with the shows we occasionally stream live. You can watch these shows at http://boagworld.com/live and interact with us as we record via the chat room. Anyone is welcome although you will probably need to follow me on Twitter to see when the shows are being recorded.
  • Talking of streaming shows, the next live show will be our 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

24 Ways is back

This week sees the return of 24 Ways. 24 ways is the advent calendar for web geeks. Each day throughout December they publish a daily dose of web design and development goodness to bring a little Christmas cheer.

I am not sure whether it is the quality of the posts or that 24 Ways appears just before Christmas, but I always get excited when they return.

This year it returns with a somewhat controversial new look (personally I think it is great they are experimenting) and a whole new set of posts. They still offer a complete archive of previous posts so be sure to look through that, as well as subscribe to their RSS feed.

There is something very special about 24 Ways. I think part of the reason I like it so much is because the writers are given a free hand. They can write on whatever they want and so inevitably write about their passions. This leads to a better quality of post.

As if that glowing recommendation is not enough, I should also point out that our very own Marcus Lillington has a post coming soon. Surely that will be enough to encourage you to subscribe!

iPhone designers kit

In the past I have been slightly rude to the guys over at Smashing Magazine about their endless lists of other people’s creativity (we love them really). However, this week they have released something that is genuinely useful.

The iPhone Starter Kit, is a set of button elements and various iPhone interface options, bundled in a Photoshop PSD. The pack is ideal for mobile developers and front-end designers who need a professional way to show mock-ups or try out ideas.

You can use the set for free and without restriction. This includes both private and commercial projects. The only thing they ask is that you do not resell it.

Admittedly you may not be doing work on the iPhone right now. However, I suspect it will only be a matter of time before we will all be working on a mobile application of some description.

The mobile sector is incredibly exciting at the moment and this is another useful little weapon in our arsenal.

5 Ways to Get Usability Testing on the Cheap

Our next post is from the sitepoint blog and is entitled ‘5 Ways to Get Usability Testing on the Cheap‘.

Usability testing is a good idea for any new web site. Increasing the usability of your web site is good because it will increase visitor satisfaction, which in turn increases sales and user loyalty. On the business savings side, usability testing can also save you money in development, maintenance, and support costs.

The problem is website owners often perceive it as expensive, failing to grasp the high return on investment. However, it doesn’t need to be and any project can incorporate some user testing, no matter what the budget.

The sitepoint post makes 5 suggestions of how you can keep the cost down…

  • Use a service like usertesting.com, which provides a video of users interacting with your site.
  • Get a written user response to your site from Feedback Army for as little as $7.
  • Use a DIY user testing tool like Silverback for the mac or Morae for Windows.
  • Ask friends and family to take a look at the site. Alternatively ask for some feedback on the boagworld forum.
  • Use services like Crazy Egg or Click Density to get heatmaps showing how users interact with your site.

Whatever approach you choose, always make sure you have at least some user testing in every project.

Site search options

One of the things I hate most about the Boagworld website is its search facility. The built in search mechanism that comes with my blogging software sucks! This is particularly embarrassing as I am always banging on to clients about how important search is. After all half your users will turn to the search box before even considering browsing the site. Search has to be right.

I have half heartedly looked around for something that would do the job. I remember looking at Atomz a while back and also there is the obvious Google integration route, but nothing inspired me.

This week however another post from Sitepoint caught my eye. It was talking about the new site search from Yahoo! Recently adopted by Techcrunch it has some fairly impressive features…

  • Real-time indexing of content – When new blog posts or comments are added to the site, the search index updates almost immediately.
  • Customised ranking – You can fine tune the algorithm to fit your audience and user experience.
  • Structured search – You can build your own refinement mechanisms. For example I could allow users to filter posts by category, number of comments, tag or any other criteria I set.
  • Blending Web with site results – Users can search both site and web content and see the results blended together in a single display.

If your site search sucks as much as mine, you might want to check this out.

Back to top

Interview: Nicholas Felton on ‘Designing Data’

Paul: So joining me to day is Nicholas Felton. Good to have you on the show Nicholas!

Nicholas: Thanks so much Paul, it’s a pleasure being here.

Paul: It’s the first time that I’ve really spoken to you. I only first saw you or heard about your work at Future of Web Design and I have to say you completely blew me away with a presentation that was very different from the majority of stuff that was being talked about because it wasn’t really fundamentally about Web design, I guess in a way.

Nicholas: No, I think in a way it’s about a weird hobby that’s kind of developed into a tiny Web phenomenon.

Paul: Well, from what I can gather it’s a fairly big Web phenomenon according to Keir from Carsonified who was raving about you afterwards. For those people that haven’t come across you before, tell us a bit about yourself. Who are you? What is it that you do? Where is it you work? A bit of background basically.

Nicholas: Sure, sure. Well again, my name is Nicholas Felton. I’m a graphic designer, predominantly print but I definitely dabble in the web and am there more and more frequently. I went to art school, I studied graphic design about ten years ago here in America at the Rhode Island School of Design and I’ve worked in graphic design firms and advertising doing identity and on the side I’ve started my personal website called Feltron where I’ve grown these annual reports that have become something that I’m sort of getting well known for.

Paul: So let’s talk about these annual reports, because this is what you were talking about at Future of Web Design. There’s a lot of people that might be listening to this thinking “Well, hang on a minute he’s just said that he’s primarily a print designer, this is a web design podcast. Why have we got him on the show?” Well just to kind of deal with that to start with, I mean obviously web design should be a lot broader, we should be looking outside of the web for inspiration and I’ve found these Felton Annual Reports incredibly inspiring. For those that don’t know, tell us a little bit about what they are.

Nicholas: Alright. Well, I really latched onto this name for them because I think it communicates pretty quickly what it’s about. Everyone understands what an annual report is. It’s the summation of a year. I’ve just attached my name, more precisely my sort of Web name, which is Feltron. My last name is Felton. But these started in 2004. I was just trying to get a grip on the year and wrap it up and I looked around at the websites I was looking at and the books I enjoyed and I put that all on my site but I snuck in a couple of little details, like the number of postcards that I sent and worked out the number of air miles that I traveled and those sort of, they hooked me. And so the next year I went back through my records and I put together a multi-page feature for my website where I looked at my travel in more detail, making pie charts of the countries that I went to. I split up my photography into all these different metrics that I could examine and between that I came up with about six pages I think of exploration of my eating and drinking habits and the culture that I enjoyed for the year and this is something I thought would only be appealing to people who knew me well, it would be a little bonus for them at the end of the year and it turned out to be a little viral and people started sending it to their friends and I started hearing from strangers that they thought it was fantastic and people saying, “I want to do this,” so I’ve tried to spend more and more time on it each year to stay in the forefront of this desire that I see building for people to encapsulate their year in this kind of report.

Paul: For me personally, when I heard you speak I immediately came away with a desire to do the same thing, just as you described.

Nicholas: That’s fantastic.

Paul: But the question that’s burning in me is, “Why?” Why do I feel the desire to do that? Why did you do it? Where did the idea come from? How did this all start?

Nicholas: I think it wasn’t that hard for me to do. The first one that I described, which was a multi-page document I actually didn’t do anything different than I’d been doing for previous years. I just had this natural habit that in my calendar I would write down where I went socially as well as what I did for work and I was able to look at that and between the names of the restaurants I knew this was a Thai restaurant so I could sort of make pie charts of what types of meals I was eating and I knew how many bars I had been to and I guess after that year I decided I was really going to formally examine this and decided to strictly track more things over the course of the year. I guess for me it’s driven by curiosity, I think I’m a pretty naturally curious person, maybe you are as well and it’s not about changing my behavior. I really don’t want the reports or this recording of my year to affect what I do over the year. I think I find a lot of solace in the numbers that come out of it. Just knowing how many beers I had or how many coffees I had or how many air miles I traveled is really comforting to me. It’s a way of tackling some of the unknown in our life.

Paul: It’s interesting because when you describe it, if someone hasn’t seen these reports you kind of think of an annual general report that’s published by a company, which are tediously dull documents but the things that you produce are graphically stunning as well. So I’m interested, is it primarily a kind of data collection exercise for you, or is it more a graphic design exercise? Is it about, I mean you kind of indicated that it’s about the data that you’re gathering rather than maybe the graphics, but the graphics are obviously what sells it to other people I guess. I don’t know.

Nicholas: Yeah, it’s hard for me to split it, but I have to say it’s absolutely about the finished product which is a piece of graphic design and the better the data is the better the story I have to tell so it’s a narrative of my year. It’s all encapsulated. It’s primarily a visual piece and I do put a lot of time and effort into making sure that it’s very visual and very easy to read quickly but that there are little details in it you can pull out if you want to spend more time with it.

Paul: Yeah. I mean that’s the immediate thing that you said there, it’s very time consuming.

Nicholas: Yes.

Paul: Not only from a design point of view, and I’m sure it must take you just an unbelievable number of hours to produce something that is so exquisitely designed but I mean tracking all this stuff, you must spend, I mean I’m surprised there isn’t a big part of one of your pie charts that’s just entitled “Tracking” you know where you spend hours just tracking all this information. What keeps you going? Why do you continue to do this?

Nicholas: Well first of all, it just doesn’t take that much time actually. I tend to sit down in the morning in front of my calendar and write down the meaningful things from the previous day but at most five to ten minutes a day. It’s definitely a background process that’s running in me all the time as, “Do I need to take note of this for my reporting?” And when I do leave my routine, when I travel, it’s a bit more complicated because then I’m doing new things and I want to make sure I get them right but it’s something I think you get into the habit of doing. For anyone who writes a diary or does these sort of recordings of the day I think after a while it’s not a burden at all. Last year I did find out, I decided out of this curiosity that I wanted to record every street that I’d walked down in New York City and that did become a little burdensome, but it was well worth it.

Paul: It’s interesting that you picked that one out because that was the one that I really looked at and went “Wow, that must have taken a long time.”

Nicholas: Yes. But it was well worth it. A year is a long time but it’s actually not that long of a time and I had a lot of hunches going into it about where I would go and where I didn’t go and it’s phenomenal to see how little of the city my routine is actually settled into.

Paul: Yeah, it’s a fascinating exercise. Just kind of give us a little bit of an idea, you know tell us you just mentioned walking down certain streets. Tell the listeners some of the other things that you collect, the other bits of information.

Nicholas: Well last year I was keeping track of every single alcoholic beverage that I had. For some reason I think drinking is really easy to keep track of because it is sort of a binary act, it’s like “one drink” versus a meal which can be more complicated but so alcoholic beverages I had 968 in 2007. I had 83,565 milligrams of caffeine through all my coffee beverages which by examining my weight and the caffeine content of each type I was able to deduce was approximately 6.8 lethal doses. I knew there’d be a couple lethal doses in there I just wasn’t sure how many and I worked it out.

Paul: That’s just horrifying. How do you decide what it is you’re going to track?

Nicholas: It usually just leads naturally out of the previous year. So like in June I will decide, “I wish I’d been tracking that this year,” and so next year I’ll make a point of doing that. So last year I started delving into the distances I’ve traveled, I worked out that I traveled about 1075 miles on the New York City subways. So this year I’ve taken a much closer look at the distances I’ve traveled. I’ve worn a pedometer all year so I could figure out how far I’ve walked and yeah.

Paul: What kind of other stuff are you tracking at the moment? You’re tracking how far you’ve walked, what other things?

Nicholas: Mostly the same things from previous years, but I’d like to look at it all through the lens of distance so it’ll be a different measure of the year rather than relating things to days or hours how does that relate to how far in terms of length I was through the year.

Paul: I mean you mentioned a pedometer there. What other kind of tools do you use for collecting data when you’re out there? When you’re out and about I feel like you need a really handy little iPhone app or something here that kind of records all this stuff for you but what tools are you using?

Nicholas: Well yes the iPhone is great I’ve tried to have some sort of smart phone where I can take notes at all times through this project but often times it’s just as simple as sending an email to myself so I have this little note that gets collected and goes into a folder and I make sure that I enter that into my calendar. It mostly all goes into iCal. I also use Backpack by the 37signals guys to keep running lists of the clothes that I purchase through the year or the movies that I saw and then when it all comes together it’s Excel. Everything needs to get into a spreadsheet so that all the math can get done and that’s probably half of the time it takes to design is just collating all the numbers.

Paul: Yeah, I’ll bet. Wow. This is absolutely fascinating. It’s something very addictive about the whole idea. I mean OK, for somebody like me, let’s say I wanted to go for this and I wanted to try it. What kind of advice would you give me starting out?

Nicholas: Well probably the best advice is to pick something that you’re going to be able to track, that you’re not just picking “What websites do I visit?” because it’s going to be overwhelming and you’re just going to pass on it after a week or two so pick something that’s easy that you do, not too infrequently that it’s not interesting but frequently enough that you’re going to get a good data set out of it. And so like if you see a lot of concerts I think concerts attended is great and then what aspects of that that are interesting? Who did you see and where was it or how long was it? So I think definitely in this website I’ve been developing to help other people create their own annual reports or just personal reporting in a way you can just have one really rich data set and by slicing it in different ways I think you can get a lot of interesting presentations out of it.

Paul: You mentioned a site there that you’re developing. Tell us a bit about that.

Nicholas: OK, it’s called daytum.com. It’s D-A-Y-T-U-M and it’s just a place where I’ve tried to remove a lot of the boundaries for creating a document like this. So there are two parts of it, there’s the recording element that can get complicated so we want to make a way that’s really easy for you to count things and then the display part of it which is practically inaccessible to a lot of people so there are a lot of built-in pie charts and stack line graphs and counting methods that are all built in, in a sort of clean design and you can just make this page that fills up with graphs and numeric intricacies of your life.

Paul: I must admit I’ve had a quick look at it and I haven’t signed up for it yet and you know it has that same clean look that your reports have and you know it’s obviously beautifully designed as well I mean we’ve spent a long time haven’t we talking about the collecting of the data I think that’s probably the most fascinating bit but as this is a web design podcast I feel like we should be talking about the design a little bit as well.

Nicholas: Absolutely.

Paul: You know I think the kind of key thing that really struck me is that you’re presenting, you know, fairly dry data and don’t get me wrong, I’m not implying that your life is boring but at the end of the day it’s data that you’re presenting and you’re doing that in a kind of visually stunning way. Tell us a bit about how the design comes together, you know. What’s your design process?

Nicholas: Well I have the benefit of being in control of all the data so if something isn’t looking right one way I can explore it a different way or I can rewrite a headline which is one of the greatest advantages that any designer can have rather than working for someone else. And then I sort of have an infographics approach where I really eschew using keys or trying to make your eye go in too many places to understand something so whenever possible I try and keep everything really focused so you can look in one spot and hopefully understand what’s going on there immediately rather than having to look at color codes or translate symbols unnaturally.

Paul: I mean is it, a lot of graphic designers out there that kind of find working with data and, you know, things like that incredibly dull. How do you keep inspired? How do you get something out of it? Because you’re not working with gorgeous imagery or anything like that, you know it’s quite dry, what inspires you about doing this kind of stuff?

Nicholas: Well I guess they’re kind of like puzzles for me. Um, I will see the establishing of infographics sort of like the data’s there and it wants to look interesting so how can I make a system that’s going to present it in the most instructional way? So I’ll play with that system so that it will line up in a dramatic way rather than just sitting in a static predictable line graph or bar chart or something like that.

Paul: I mean also you seem to use typography very heavily so I’m guessing that’s something you’re particularly passionate about.

Nicholas: Yeah I guess it’s my two natural loves in one place: the numbers and type.

Paul: Oh dear. So what advice would you give for us Web designers that are kind of, you know we do work with data a fair amount, you know from surveys through to content management systems that provide reporting and things like that. What do you think the key is to presenting data in an understandable and approachable format?

Nicholas: I think that one of the key things is just getting away from the default options that you’re given like I’ve found it’s really impossible to get a nice looking graph out of Excel or out of Apple’s Numbers and the same is kind of true for the Google Chart API which is what we use for daytum.com which is basically a way to send a URL to Google and they return a pie chart or a line graph but they can get really overly complicated and ugly very quickly so it’s a matter of stripping it down and making sure that this is something that’s going to be dramatic and simple to understand.

Paul: It’s that simplicity thing again that, you know, have taken something complex and as you say stripping it down and keeping it simple.

Nicholas: Absolutely, and even if you have the benefit being able to edit your material so that I’m looking at a pie chart that has four or five slices rather than seventeen I think it’s going to benefit your readers enormously.

Paul: So Daytum, that you are in the process, is that actually live now or is that still in the process of being developed? I can’t remember whether it was generally accessible or whether it was in a closed beta.

Nicholas: It’s in a beta but the wait list is down to less than a week now so it’s just a queue basically to protect out severs. But yeah, we’re adding new features all the time. We’re about to add averages there so you can examine your average cup of coffee or your average commute time and we just plan on trying to preserve the user experience by making sure we don’t get too swamped and growing it over time.

Paul: So how did this come about? You keep saying “we” so who’s the team that’s behind that?

Nicholas: Yes it’s my partner Ryan Case who is more on the development side but is also a fantastic user interface designer and he came to me in January or February of this year and like many people had said we should figure out a way to do this year reports on the web so that other people can do it but he had the technical chops and motivation to really get the ball rolling and he’s become actually a great data tracker himself and has been keeping track of all his beers religiously and all the trains he’s been taking, which I didn’t know he had in him. So I think it goes to show anybody with the proper motivation could get started.

Paul: So is this your full-time job now or is it a part-time project?

Nicholas: It’s about half-time at this point. I still have my editorial clients and web clients and identity clients that I work for but this definitely occupies as much free time as I can give to it.

Paul: Well I found the whole thing incredibly inspiring.

Nicholas: Thank you so much.

Paul: It made me look from a completely different perspective at graphic design and also at life in general I guess and we have so many people who come on the show that are talking about the stock and trade of web design and thought it’d be really good to get you on just to give a different perspective and make us look outside of our little boxes. Thank you so much for coming on and I wish you all the best in your various projects.

Nicholas: Thank you Paul. Thank you.

Paul: Good to talk to you.

Nicholas: OK, take care. Bye bye.

Thanks goes to Todd Dietrich for transcribing this interview.

Back to top

Listeners feedback:

This week’s listener contribution is a question from Dave. He writes:

I am having real problem maintaining users. They visit the site once and then I never seen them again. I have good content, the site is usable and so I am at a loss as to what I should do.

Should I be worried? Are repeat users really important? What can I do to keep them coming back which doesn’t cost a fortunate?

It is such a good question that it spawned an entire post on using community as a retention tool.

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

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

128. Details

On this weeks show I’m accompanied by our Producer Ryan and Researcher Stanton. We Interview Dan Rubin on the Details of Design, and answer your questions on managing a bigger team and terms and conditions.

Play

Download this show.

Launch our podcast player

News and events

Silverback Launches

This week has seen the release of Silverback, the highly anticipated app from the guys at Clear:Left. After months of speculations about what Silverback actually was, the “spontaneous, unobtrusive, usability testing software for web designers” is finally available for download.

We’re sure a majority of you know all about Silverback, but for those of you who don’t, Silverback, which is available exclusively for the Mac, is Clear:Left’s answer to convenient usability testing on the go. Utilising the iSight and screen capture facilities of the Mac, user’s experiences can be recorded and reviewed at a later date, taking away the costly and often difficult to setup up approach of using specialist equipment like multiple camcorders which can lead to hours of time spent trawling through video footage.

PatternTap

Whether you’re a designer or developer, there are many occasions where you go on the hunt for inspiration in interface design. Normal CSS Gallery sites give you great examples of full site design, but usually don’t focus on the small details of interface design. The only site i’ve ever been aware of is Christian Watsons “Elements of Design“, which is a great resource showing examples of elements like comment forms, calendars & date pickers, footers, image captions and so on.

There’s a new site I’ve come across this week called PatternTap.com which also wants to collect these design patterns and focus on specific elements of design and to help you to reference, collect and organise them for your own needs.

PatternTap is shaping up to be an absolute goldmine of inspiration, and looks like it will build into a large resource of design element exmples. There’s currently 46 collections, everything from 404 pages, audio players, pagination and search boxes. It let’s you create your own “lightbox” style user sets, so you can keep your favourite examples organised for future reference.

I’ll definitely be adding this to my toolbox of design inspiration links, and recommend you give it a look too.

Google App Engine Update

This week also sees the release of a small update to the Google Apps Engine. The Google Apps Engine allows developers to build applications on Googles own infrastructure. I have to admit that the Google Apps Engine is not something I’ve developed with personally however that doesn’t stop us talking about it so let’s run through the list:

  • Firstly you can now have up to 10 apps on your account as opposed to the previous limit of three 3, the Engine also limits developers to 1000 files per application, so the increase in the number of apps you can now have is a welcome addition.
  • Time windows for Dashboard graphs: Zoom in on the data in your dashboard to get a more accurate picture of whats going on. You can zoom in to see graphs for the last 24, 12, and 6 hour periods.
  • Log files can now be downloaded in plain text.
  • And finally you can send email as the logged in user: If you’re using the users API, you can now send email from the email address of the currently-logged-in user were as before it was only possible from the administrators account.

S3

So some of you may be aware that Amazon’s S3 service suffered from some 6 hours of downtime recently, this echoes the issues of service availability that happened back in February.

For those of you who don’t know, the S3, or “Simple Storage Service” is a scalable and inexpensive data storage infrastructure, which allows you to store and retrieve any amount of data.

So this is a fantastic idea – in theory, it means that if you’re developing a large website or web app and need lots of storage, you don’t have to pay for huge webhosting plans with lots of physical diskspace, you store your assets “in the cloud” as it were, and you’re charged based on how much storage space you, and how much bandwidth you consume.

Lots of large sites rely on the S3 service for their storage needs, Twitter, BaseCamp and SlideShare to name but 3 and the recent downtime has raised the age old issue, “are we putting all our eggs in one basket?” Jonathan Boutelle put it best in a recent blog post, stating “When S3 goes down, the internet goes down”. Aral Balkan also wrote recently urging people to have contingency plans in case events like this happen again, stating that the Open Source Google App Engine SDK could be the answer.

Back to top

Interview: Dan Rubin The Details Of Design

Paul:Joining me today is Dan Rubin who I recently saw at the @media conference. Good to see you or speak to you again Dan should I say?

Dan Rubin:Good to speak to you Paul.

Paul:It was good to meet up with you at @media. It feels like a long time since we met up and it was great to hear you speaking there. That was a first for me.

Dan Rubin:Thanks. It was a privilege to be able to help out Patrick it being very last-minute.

Paul:Oh was it?

Dan Rubin:He sent me an email about two weeks prior saying someone had dropped out and of course I wasn’t going to say no.

Paul: laughs

Dan Rubin:It’s been over 10 years since my last trip to the UK, so it was a great opportunity.

Paul:Cool. Well I have to say considering you only had two weeks to put together the presentation, it was truly phenomenal. It was an excellent presentation and I really enjoyed it. You were talking about ‘design is in the detail’ I guess was the kind of subject you were tackling?

Dan Rubin: I’ve been talking a lot lately about the level of detail, the attention to detail and the design and I’ve done a couple of presentations with Brian Veloso over the last year on that same kind of topic. This was an extension of that injecting some of my own little personal preferences into the talk and got to cover things like typography and some of the simple practical things that you can improve very easily that result in a big improvement and typography, and little tricks in using grids, not on how to make them but how to actually implement them and how they can help workflow and bring things together and make layouts tighter and better without
that much effort and the same thing with digital transformations in photography and a lot of pixel detail that a lot of people don’t notice and its all about the subtle level of design.

Paul:I got this vague feeling that as you were talking you were a little bit appologetic for some of these manushi that kind of individually you sit there and go ‘how is anyone going to notice that?’, but accumulatively they have this effect on the design don’t they?

Dan Rubin:Well that’s the thing. It comes down more to feeling than seeing but its about as a designer what you feel with your eyes more than anything else and how that translates to what users or viewers or readers also feel but since they don’t know it is there, they are likely to never actually see it, but as a designer you’ll know it is there, you can see it, and the trick is to get it to the point of you can still see it but it is not really visible it is just felt.

Paul:A subconscious expression?

Dan Rubin:Yes.

Paul:You covered loads of tips in your presentation and there was some excellent stuff in there but if you had to pick out one that has the biggest impact on a design, which of the many things you talked about would that be?

Dan Rubin:I think what it would be is to really underscore trusting your eyes and it seems a really simple concept and whenever I put that up on the screen you get giggles from the audience. The truth is many of us don’t actually take the time as designers to just step away and look at what we’re working on. It doesn’t matter whether it is for screen or print. The medium is a material at this point and it is just having faith in what you see and what you feel. That’s what being a visual creative is all about. It is trusting what you see. It is the same as being a good musician comes down to trusting what you hear and sometimes we forget that, and we start getting into designing based on the rules or how we think we are supposed to do things or designing on technical limitations alone. When we do that we stop using our eyes.

Paul:It’s interesting in the presentation you talk quite a lot about some of the details and the mechanics of design. You were talking about font sizes going incrementally up, your heading and your sub headings and there being a mathematical relationship in their sizes. You talked about being consistent in your margins and padding and how all those things inter-relate. Are we saying that design is something that can be learnt and it is a mathematical thing and it’s a set of rules that you just adhere to? Or is there some sort of underlying artistic thing, some people just know how to do it and it’s not something that can be learnt. What’s your opinion on it because I get mixed feelings from you? On one hand you talk about these rules and on the other hand you talk about stepping back and looking at your design and it feels more kind of arty-farty if that makes sense!

Dan Rubin:What a load of questions and rightfully so! It’s something I’ve written about before years ago and had a bit of back and forth on the topic with Paul Scrivvens of 9 Rules, with him arguing that you don’t need any natural artistic ability because he didn’t think he had any, yet he was clearly doing things that looked good. I was arguing the opposite but when it comes down to it it’s really not something that you can say definitively either way. Just as there are people who naturally seem to be good musicians or good athletes or good at math and programming, there are people who seem to naturally be good at design and any kind of creative endeavours. It is really difficult to tell whether that seeming innate ability has come from something that happened in very early childhood development or if they were born with it. I do think that however difficult it is to put a finger on it, once you get old enough, especially to the point w here probably most of your listeners are doing what your doing for a living already or you are thinking of changing from one thing to another, you’re past that point of subconscious development where you need to put conscious effort into something and you can. I think you can be trained to do most of the things designers do. You can even train yourself to see the way that creatives see. The older you get the harder it becomes to incorporate into the way you view the world. That is a big part of it. That comes down to sometimes the different personalities. How hard is it to put a finger on what makes you ‘you’. I would say as a teacher, and I spend a lot of time teaching high school students over here about music as well, since that’s my other passion, and it’s specifically not just playing music but it’s specifically singing which is one of those things that you can either carry a tune or you can’t. I’ve also seen kids who can’t carry a tune when they start singing learn how they train themselves. They learn the proper muscle memory, and it’s amazing to see what people can actually accomplish when they put their mind to it. If you are listening out there and you want to become a better designer or maybe you’re not a designer and you’re a programmer or a web standards junkie, and I can say that because I am one too, and there isn’t any reason that you can’t become a better designer, or become a designer from scratch if you realy really want to.

Paul:I think that’s really important to say because I think so many people are intimidated from getting involved in design because there’s almost a bit of snobbery. If you’re not artistic, you’re not artistic there’s nothing you can do about that. I personnaly don’t believe that that’s true. Like you say I think there are some people that are naturally inclined that way but I think a lot of the principles that you were talking about in your presentation pretty much anybody can pick up on and do, which is what encouraged me so much hearing you talk.

Dan Rubin:That is one of the reasons why one of the reasons I say one of the most important thing is to trust your eyes and that’s instinctual. These rules, as a good teacher you have to teach these rules. When you start learning any discipline the first things that you are taught are the basics.The basics are things that many people, once they learn enough, don’t conciously think about, but what you find if you deconstruct their work is that they are doing them, they have incorporated into their flow into their process so it’s second nature to them. What we think of as instinct is really just experience.

Paul:Yeah. One of the things you did mention in the presentation that grabbed my attention is you talked a lot about texture and adding more texture to your design and about how that creates a real feel. There seems to be a slight skism, I don’t know if that is the right word, but like 2 different camps in design at the moment. People like yourself, Elliot Jay Stock is another example that does very rich, very textured design. It’s absolutely gorgeous. At the other end of the extreme you’ve got people like 37signals doing this minimalistic functional design. How do you feel those two sides fit togeth
er? Is there a role for one or the other or have they both got their place

Dan Rubin:I really think that both have their place and more than that it’s popular to create divisions. Not just these days, if you look at any industry that spends a lot of its time looking at itself, like we do, you start to find reasons to create little clicks within it or factions or what have you. If you just ignore those splits that happen because we spend way too much time looking at what we do and try to deconstruct it and answer that question of ‘why’. What you find is that it’s all the same thing. When I talk about texture it is important to understand that it doesn’t just mean rough or ??bulap or brick. Texture can also mean smooth and polished and speaking directly about 37signals for instance. I’ve used their apps and I’ve loved them since the first time they came out. If you look at the first versions of Base Camp and Backpack, before their incremental re-design they’ve actually added the little drop shadow over time. If y ou look at it as a designer you see the flaws in the way they’ve done it because it doesn’t look real and it just ends at some edges, it has hard edges, but that’s not the point. The point is they added it because it created a separation, they added it because they felt it needed it. The rest of the interface doesn’t need any other texture because it isn’t supposed to have a feel to it. It’s actually supposed to totally get out of the way and there are different approaches to minimalism. You can use minimalism in subtle detail where you add in things like I was showing in my presentation, or you can use minimalism where you keep taking away and 37signals apps feel right, they always have felt right to me so as far as I’m concerned that means they’ve hit the nail on the head. It shows when you see people trying to recreate the application interface and theat style that 37signals uses and they get stuck in this pattern of adding things, like they feel ‘well, that’s 37siganls l ook so I think we have to add things to make it better, to make it better, and they never work as well because it’s not just about that. So the answer is, and I try to underscore this when I talk to people about this or present about it or even write about it, as much as these things can be presented as rules and definitive this is the way to do something. the fact is you have to do what works best for you and your particular project or circumstance or situation, and you also have to be open to the fact that what works for you right now might change. It might be different next year, next month or next week, and being able to adapt to your situation as a designer specially is really important, because you have to adapt if you’re doing client work, you have to adapt from project to project, because your style might work for one client but you might need to tweek your style to do what’s best for another client. If your working on your own applications, what works for your users now might not work for your users once they become users that have used your app for a year and they’re experts now.

Paul:You talk about tweaking your style. How easy is that, do you think, to do in reality? I mean I’ve got a very strong style in my design, and I really struggle and I look at someone like Cameron Moll’s style and I just love it. I love the light-handed feel, he’s very delicate, beautiful design, and I wish I was more like that, but there is no way I can make myself become like that, or can I? Is there a way of changing your style?

Dan Rubin:I think we’re all naturally mimics. I’m not going to dig into my opinions on human adapability too much. I spend a lot of time thinking about that as far as evaluating how people use things, whether it’s interfaces or products and it’s interesting to start to see those patterns but you can see it on a global scale too. Historically human beings are species very, very adaptable and that happens on macro and micro levels. If you want to adapt your style you can. You look for the inflences you want to model yourself after. This is just how people learn to be designers when they’re starting out, or learn to be artists. When I took my first watercolour and oil painting classes when I was 11 or 12, the way we learnt was to recreate examples that were painted by masters. So learn how to use the brush strokes they use, to learn how to mix colours the way that they use them, to learn how to use the tools the way that they use them becau se you only discover your preferences and your style by mimicing, copying others. You find out what works and you decide what works for you and what doesn’t. So changing how you design and how you see is not necessarily easy, because at a certain point you’re reprogramming muscle memory and from my experience with singing I know how difficult that is to do. Once muscle memory has been built up to the point where you don’t think about it and you just react, it’s very difficult to break that down and re-build it. Difficult does not mean impossible.

Paul:That’s really interesting that you say that because I’ve always very much struggled to design in any other way than I already do, but I obviously need to push myself in this area. Talking of 37signals, I’m sure you have been following their recent post and various reactions to it about skipping Photoshop, and how they move straight into building with HTML and CSS and I just wondered what your opinion was on that.

Dan Rubin:I know I’d get roped into this discussion somehow. There has already been some great responses from people like Jeff Croft and Mark Boulten to the 37signals post on that, and even interestingly enough a follow-up post sourced by 37signals announcing that they were looking for an additional designer for their team that can push them into different directions that they havent been going naturally. That comes back to the whole adaptability and willing us to change and being open to it. In the argument itself I can’t say I always start in Photoshop or Fireworks or some sort of visual tool. I think Jeff said 37signals starts with a visual tool, it’s pencil and paper. I think even if your tool is a marker on a whiteboard to a certain extent everybody tends to start there, even if you don’t start there you start with a picture in your mind. So there’s some level in the process where a visualisation is occuring, if that’s fair to say. When it comes down to it why does the tool that you’re using to visualise really matter? It starts in your head if you’re a primarily visual person you can either realise that vision by programming it and seeing it in the browser or using Photoshop as a tool. All of these are just tools when it comes down to it, they’re not the end result. They’re just part of the process. I’ve done both. I’ve built straight from XHTML and CSS many times and I do tend to find that most visual designers that have weighed in on this conversation also find that in my opinion the result ends up being more simplistic. that’s not necessarily to say bad. It’s just different and you’ll find that the tools that you use as a visual creative influsence the end result because that comes down to constraints. 37signals of course is huge on constraints and you do save time when you’re doing straight HTML and CSS, you skip a lot of the temptation to play around like I know I do with layers and layer setting s and percentages of opacity. I spend a lot of time playing when I’m in Photoshop, I don’t think that’s bad. That’s part of the creative process when using that tool. When I used to paint which I havent done in way too long. I would play with my
palatte, when I was doing oils my palatte and my palatte knife was tool before I got to the canvas, and I would play with mixing my colours ‘and that’s not quite right’ and ‘wait and go over here’ and sometimes you get it onto the canvas and it doesn’t look the way you want it to and have to wait for it to dry and then you paint over it because that’s what you do with that tool. When you’re doing watercolours you don’t have that forgiveness of the tool, you have extra constraints, so you don’t experiment as much putting it on the paper, putting the paint to paper because you know once it’s dried and there you can’t go back. you can’t paint over it. So you adjust your style depending on the tools and the workflow and it’s all good, it ‘s just all different and you have to I think do yourself a favour and experiment to find which works best for you and don’t be afraid if you’re working on a project and you think ‘this doesn’t feel like it needs a lot of subtle gradients and lines and shadows and Photoshop work. I might just be able to build this without using Photoshop at all’. So do it if it feels like that will work best go that route. If you feel the opposite go the other route. If you feel like it should involve a lot more natural media pull out your watercolour pad and paint something and scan it in and incorporate that

Paul:It really down to the right tool for the job thought process.

Dan Rubin:Exactly. The thing that 37signals does really well is stick to their guns. They state their opinion so firmly that people can easily interpret it as law and I think that’s very important. In any industry it’s very important to have people who do that, who can stick to what they believe so strongly and apply it so universally that it creates this set of rules, but it doesn’t mean that they have to be followed or cant be partially followed or bent or broken and you find just as much as 37signals is enfatic about skipping Photoshop. There are other people who would never in a million years go straight to HTML and CSS, doesn’t mean that either camp is right.

Paul:OK. One last question just to wrap this up. We’re running out of time but there’s something I wanted to ask you which is: We’ve been already talking about that there are people that may be want to learn to be better designers, to find their style and to move into this area, perhaps they’ve been a developer background and they’ve been previously put off exploring design because they have been made to feel inadequate. What kind of resources would you encourage people to look for or look at in order to get going I guess?

Dan Rubin:Whether you’re starting from scratch or just trying to improve what you already have it’s important to touch on a couple of specific areas, and those are typography, layout and working with colour. This applies just to design because it’s worked whether you’re designing on the web or designing in print or branding or whatever you’re doing. Typography is kind of my first love with design and if you want to learn about typography you have to go out and buy ‘The Elements of Typographic Style’ by Robert Bringhurst. It’s the bible for typographers. It’s really easy to read too because he’s a well respected Canadian poet as well. He just happens to be an excellent typographer and book designer, so if you are in a rush, you cant get to the book store or Amazon right away Mark Boulton’s series ‘Five Simple Steps To Better Typography’ is a great place to start as well and he references a ton of other good resources. Start there if you a re going to start online but no matter what buy ‘The Elements of Typographic Style’. When it comes to layout there are a lot of things that you can learn about layout but you’ve got to learn about grids, even if you never use them. Do yourself a favour of learning and I’ll reference Mark again, actually I’ll reference Mark in all three of these. He’s got great starter tutorials about this stuff so ‘Five Simple Steps To Designing Grid Systems’ is really a great place to start. Cameron Moll has written about Griding The 960 and read up over on Khoi Vinh’s site about grids. ‘Grids Are Good’ is a great demonstration as well, and if you want to get a physical book to hold ‘Grid Systems In Graphic Design’ is a great, great phyisical book and I think it’s important to as web designers to also reference ‘Print’, because Print is where all these design rules come from and typography rules and colour rules, so learn from these different implem entations and you’ll figure out things that you can do that you didn’t think about, because you haven’t seen them on the web. So ‘Grid Systems In Graphic Design’ is by Josef Müller Brockmann I believe would be the pronounciation, look that up. Colour, and this is something that’s very preferential maybe but read up again Mark Boulton’s ‘Five Simple Steps To Designing With Colour’. He’s great at teaching, he’s great at communicating all these things. Also play around with some of the online tools like Adobe Kuler, is fun. Look at what other people are putting together, look at combinations, again feel is important. Whatever feels right for what you’re trying to do. Another cool tool is Colorjack. You got a couple of ways of mixing colours and it’s really, really cool to look at. Finally on the topic of colour whenever using colours in an interface please be aware of the different types of colourbl indness that exist, and there are lots of tools online. Photoshop CS4 will have some tools built in as well but there are plug-ins that you can get right now for all sorts of tools and online tools as well that allow you to see what you’re designing, or even just a colour palatte. See them through the eyes of someone that has these various colourblindness afflictions and make sure that whatever you do doesn’t render something unuseable to what ends up being a large percentage of the viewing public when it comes down to it.

Paul:WOW !! That’s a good set of resources !! My word.

Dan Rubin:You didn’t think I’d be that prepared did you?

Paul:That’s a superb list. I certainly didn’t know about all those posts from Mark Boulton. there was some great stuff in there – Thank you very much Dan. Just to say that Dan’s talk at @media will be no doubt going live at some point and you’ll be able to download it and listen to it. Definitely do that, it was superb. So check that out. You will be able to go the shownotes for this episode for all those links that will be useful as well. No doubt you won’t be able to remember them all. Dan thanks for coming on the show, it’s very much appreciated and we will get you back on in the future.

Dan Rubin:Thanks very much for having me Paul. It was a pleasure.

Thanks to Sarah Galley for transcribing this interview.

Linkage

You can find Dan Rubins site, Superfluous Banter here.

Typography
Layout
Colour

Back to top

Listeners feedback:

Managing a Bigger Team

Jon asks: We are a company of 4 people – myself (owner, design lead and general business development/project management person), one designer, and 2 developers.

We are hopefully about to merge with a slightly larger company in a neighbouring town who have slightly more staff than we do (7 in all), and who have more of a project management structure – 2 project managers, using the services of 1 designer, 3 developers, and 1 designer/developer. I would end up as owner/MD of the enlarged company.

My question is really about project management? What do you think is the best organizational structure for a company of 11 people? I was feeling pushed on the project management side before this merger came along, and the merger will bring 2 project managers with it. How does Headscape do it for example – I think you have project managers there – do the designers and developers report to project managers, or do the project managers pick from a pool of design and development resource as required? What are your thoughts generally on the whole project management side of things.

A-ha… this is part two to a question I answered a few weeks back relating to pricing work after two companies merge. I wanted more detail at the time and now I have it!

Comparing to Headscape, we have 4 designers, 4 developers, 3 project managers, 2 business development/analysts and 1 lazy good-for-nothing called Paul … seriously though, Paul effectively markets Headscape and I have to say he’s rather good at it (ungrits teeth…)

Following the merger Jon will have a team of 11. As he is new MD, I think it is imperative that he much reduces the design and PM aspects of his role and concentrates on bringing in business as there are quite a few more mouths to feed.

That leaves roughly 3 designers, 5 developers and 2 PMs. Depending on the work you’re doing I think that is ok especially considering Jon can bolster both the design and PM groups if needed.

Regarding the allocation of work, project managers should rule the roost. Full stop.

It is their job to manage resources. Delivering projects effectively and on time means that they must know that they are in charge regarding who does what and when they need to do it by. A certain amount of fitting the right person to the job should be done but generally, the rule should be that the next piece of work goes to the next available person. This would be particularly useful advice in a merged company where it would much easier to keep going back to ‘your’ guys because you trust them.

One thing that has worked really well for us is to set invoicing targets for the project managers. We don’t operate performance related targets but it still really helps to focus minds on hitting milestones at the end of months.

Terms and Conditions

Adam writes: I am developing my own web application. In summary, it’s a site with user submission of content in a social networking format with video uploads. Anyone can register an account.

I of course have to try and write Terms of Service for this and I am getting stuck. I am wondering what Headscape uses, especially for Getsignoff, and whether you found a pre-written terms of service, or had a specialist write one.

What’s your solution to the problem, and what should / should not be included.

I have to confess to conferring with Headscape’s fount of all legalese knowledge on this – our MD Chris Scott. I tried to get him on the show but he’s still a little jittery after the last time all those years ago… anyway, Chris put together the TOS for Getsignoff and these are his thoughts on it:

For Getsignoff I looked at the TOS of other online services like Harvest, Basecamp, Youtube and Flickr. I’m not a legal person, but this gave me enough material to be able to identify the key issues that I thought we needed to cover in our TOS.

I assembled this into a brief for our legal adviser that was part overview of what we wanted to achieve and part draft TOS using adapted clauses from other TOSs.

Our legal adviser pretty much re-wrote what I had given him but this was from a position where he had a good understanding of how we wanted Getsignoff to work.

The bottom line with this sort of thing is that you really need to get a professional legal person to assist.

Back to top

 

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

121. Coda

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

Download this show.

Launch our podcast player

Watch the behind the scenes video

News and events

Skipping Photoshop

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

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

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

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

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

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

Web Designers should do their own HTML/CSS

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

At the end of the article they write…

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

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

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

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

Beyond CAPTCHA

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

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

An example of CAPTCHA in action

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

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

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

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

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

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

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

Website Owner’s Manual

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

Back to top

Feature: Quick Fix Accessibility

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

Back to top

Review: Coda

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

Back to top

Listeners feedback:

Team working environment

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

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

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

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

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

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

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

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

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

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

Internal Search

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

Love the new site!

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

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

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

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

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

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

Back to top