Having identified our target market, it was time to define our users’ goals so that we could create content that is useful and usable to our site visitors. We established that there would be three main user goals, achieved when the user carries out one or more tasks.

(1) A user needs to hire a web agency

In part 2 of this blog series, I identified the types of clients we would like to work with and explained the benefits of each. Assuming that these potential clients eventually land on our website, and are looking to see if we would be a good hire, they would carry out the following tasks. I have divided the tasks into passive (things the user will do to help them make up their mind) and active (things the user will do once they are considering hiring us).

Passive tasks – judge the design of our agency website; judge our previous work; read about us; learn about our design process; read our blog posts and tweets; read testimonials;

Active tasks – contact us; fill out a project requirement form; follow us on Twitter; connect to us on LinkedIn;

(2) Designers and developers who are looking for work

In part 1 of this blog series, we discussed our business goals and how our website would contribute to achieving them. One of our business goals was to establish a strong reputation, and one of the ways we plan to do this is to hire great designers and developers to help us produce top quality work. This meant our website needed to cater for designers and developers who are looking for work, and would, therefore, carry out the following tasks:

Passive tasks – judge the design of our agency website; look at our previous work; read about us; learn about our design process; read our blog posts and tweets;

Active tasks – comment on our blog posts; apply for job advertisements; contact us; follow us on twitter; connect to us on LinkedIn;

(3) Students, designers and developers looking to learn

Another way we will try to establish a strong reputation is to contribute to the web design community, specifically by blogging and teaching web design. Students, and amateur designers and developers, will arrive on our site to learn, and will carry out the following tasks:

Passive tasks – read blog posts; read about our design process; look at our previous work; read our case studies; learn about who influences us;

Active tasks – contact us for advice; follow us on Twitter; connect to us on LinkedIn; enrol on our web design courses;

Deciding on our content

These three goals, along with their corresponding tasks, give us insight into what content we need to create. The following diagram depicts our proposed website structure which acts as a guide into content creation.

Conclusion

Content is king – it’s a cliché, but it will always remain true. We take a content-first approach with our client work, and our own website should be treated no different. Defining user goals and tasks helps to develop content that is useful and useable to website visitors, which tempts them to return for more. If this happens, it goes a long way to meeting the business goals of any organisation.

A separate site for mobile? Nope!

Nielsen suggests organisations should build a separate website for mobile users, and casually throws in “if you can afford it”, as if it’s an afterthought. He then suggests that making a mobile app is even better.

Firstly, building and monitoring two separate websites, one for the desktop, and one for mobile devices, is a content strategy nightmare, and creates content forking. The costs won’t just be incurred in the initial build of the two separate websites, but also in resources during the life of the system, because time and manpower will have to be dedicated for content management.

As for the mobile app suggestion, that, too, is costly. Separate native apps will need to be developed in many different operating systems, such as iOS, Android and Windows Phone, if an organisation’s user base is spread across different mobile brands.

In the real world, we web designers have to come up with cost-effective solutions for our clients, and suggesting that they build separate sites just isn’t feasible, most of the time. Clients are a bit more open to building mobile apps, but that’s just because it’s a buzzword, or current trend, and much of the time they don’t even want to make use of the mobile GPS or accelerometer – which are the main reasons to choose a native app over a web-based app – which is why responsive web design should be the answer.

Cut features and content? Nope!

Nielsen goes on to suggest that we should cut features and content that are ‘not core to the mobile use case’. This was a big red flag for me, and I’ve written before about why we shouldn’t make sweeping assumptions about mobile users. Designing from the basis that all mobile users are on-the-go and just need quick access to contact details, or other snippets of information, is both ill-informed and, quite frankly, lazy. There are many users who browse the web on their mobile device over WIFI, while sitting on the couch. Other users browse on the mobile device at work, for entertainment. Removing content from a site, based on the device a user is browsing from, is discriminatory. It’s far better to hide content in accordions or drop down blocks that the user can reveal as and when they need it.

Links to the full site? Nope!

Jakob then tries to remedy this removal of content by recommending we place a link to the full desktop website. This is utter nonsense. Let’s break it down. What he’s proposing here is that we should make a user land on a mobile-optimized layout, where the fonts are large, the interface is fat and finger-friendly, and the content is sparse and minimal; and then we should force them to load a completely different layout half-way through the user journey, just to get to the content they wanted in the first place, but was removed because of their browsing device! When the full site loads, the page will most probably be zoomed out, as is default on most smartphones, so the interface and content will be much smaller.

Nielsen’s suggest we make the user learn one system (the mobile website) and then force them to learn a completely different one (the full website), which, to me, doesn’t improve usability one iota.

Mobile-first, responsive web design and designing form emotion

We are coming up to the two-year anniversary of Ethan Marcotte’s seminal article on A List Apart, where he first introduced responsive web design, and reading these recommendations by Jakob Nielsen has only reinforced my long-held suspicion that he is out of touch with the current practices in the web community. The sad thing is, there are university students and lecturers (who I have met) who take Nielsen’s words as gospel, almost as if they are written in stone. This can be dangerous for our community, and it’s up to us to spread the teachings of heroes like Ethan Marcotte, Luke Wroblewski and Aaron Walter, to ensure that we continue to move forward and evolve our craft.

Instagram has only been around for a couple of years, and its development was funded by various venture capitalist firms. Its founder, Kevin Systrom, has 40% ownership, netting him $400million from the deal, and his 13 employees are due to receive millions, too, which is absolutely crazy if you consider that it’s only a small iOS and Android app.

Bad news for Instagram users

In my opinion, the small team at Instagram have hit the jackpot, and I congratulate them. But the community of 30 million who use the app should be worried. The service which contains their photos, messages, GPS locations and personal information, has suddenly become the property of Zuckerberg & Co. While the Facebook founder has said he intends to keep Instagram as a separate company, there is nothing stopping his social network from making changes to the terms and conditions, after all, they have paid $1billion for just that right. How long until Instagram will be used to target advertising? How long until Facebook’s facial recognition software is incorporated into the Instagram app? Only time will tell, but I’m pretty sure many of the devout Instagram users are already looking for an alternative photo-sharing platform.

Bad news for social and app users

An even more important question – will the current Instagram users get any say as to what new features or policies are introduced? The answer is a big fat NO. That’s because they didn’t have a say before Instagram was sold, so why should they now? And this is true for all social network platforms or community apps. The tradeoff that users must make to use these free web services is that they must accept whatever terms are put to them, and if a user doesn’t agree, they shouldn’t sign up and put their personal information on their servers.

When we use services like Facebook, Twitter, Google Plus, LinkedIn etc., we are not paying with money, we are paying with our identities. Our profiles, messages and online friendships are the currency, which the social networks convert to real currency by opening up their platforms to advertising.

The Instagram acquisition will only add to the culture of flipping start-ups, where the aim is to build a product only to cash in a couple of years later when a bigger brand makes a takeover offer. The users of that product, who have invested their time and money, become a secondary cause.

Bad news for business

On the other side of the coin it’s the same story. Businesses who advertise on social networks are leaving themselves vulnerable to poor return-on-investment, caused by the changing politics and policies of the platform owners. The fall of MySpace is a great example of this. As with any corporate takeover, there comes an added pressure from investors to perform well, but for the founders of MySpace the insistence to increase advertising revenue became their downfall.

When we did the Google deal, we basically doubled the ads on our site, making it more cluttered. The size, quality, and placement of ads became another source of tension (Gillette 2011).

MySpace’s demise came about because the developers chose to please their investors over their users. Ultimately, the user experience declined, which frustrated users and caused them to search for an alternative.

Many organisations spent all their time and money either maintaining their MySpace presence or building and buying an advertising strategy on the social media site. When disgruntled users migrated to Facebook and other social networks, these companies lost out. Why? Because the boardroom politics inside the MySpace headquarters were not in their control, and their business model was not independent enough.

The same could happen with brands that have built profiles on Instagram, or, for that matter, on Facebook itself. The mammoth social network may have 500 million users today, but the fall of MySpace has shown that anything can happen.

Gillette, F. (2011) The Rise and Inglorious Fall of Myspace. Available at: http:// www.businessweek.com/magazine/content/11_27/b4235053917570.htm

On Tuesday, they released a list of their design principles, and what struck me immediately is how each of them is just as important when designing for clients in the private sector.

1. Start with needs

The design process must start with identifying and thinking about real user needs. We should design around those — not around the way the ‘official process’ is at the moment.

Many clients in the private sector need to be reminded that the website or web service that is being built is not for them, but for their customers. In the same way the GDS doesn’t design around the “official process”, we need to ensure that the systems we create in the private sector are not based on vague assumptions and in-house terminology that only the client understands.

2. Do less

We’ll make better services and save more money by focusing resources where they’ll do the most good.

Designers are often tasked with doing work that they know will be a waste of time and money, but are hesitant to challenge the client for fear of losing work. We need to be confident in voicing our opinions, and ensure we back up our suggestions with hard data – speaking in the language they understand: business goals, client retention, increased sales, customer service.

3. Design with data

 …we can learn from real world behaviour. We should do this, but we should make sure we continue this into the build and development process — prototyping and testing with real users on the live web.

We have a whole host of tools to monitor user behaviour once a website or web app has been launched. When working with clients, designers should promote long-term monitoring and evolution, not to get more money out of the client, but to ensure that their site is working for them as an efficient business tool.

4. Do the hard work to make it simple

Making something look simple is easy; making something simple to use is much harder — especially when the underlying systems are complex — but that’s what we should be doing.

We need to promote simplicity above most other things. Just because a client wants everything plus the kitchen sink on their site, we shouldn’t just go ahead and deliver it. Designers need to communicate the importance of usable systems, and move clients away from thinking of sites as merely online brochures.

5. Iterate. Then iterate again.

The best way to build effective services is to start small and iterate wildly

Clients are always eager to have what they paid for as soon as possible. We as designers  need to do a lot more to explain the benefits of iteration and evolution over time, again speaking in a language they understand: a better user experience will increase the willingness of their customers to spend.

6. Build for inclusion

Accessible design is good design. We should build a product that’s as inclusive, legible and readable as possible.

Thanks to the work of web standards evangelists like Jeffery Zeldman, these days web designers know the importance of accessibility. But do our clients? Have our clients ever considered what percentage of their users have visual impairments, mobility issues or cognitive disabilities? We need to tackle discrimination-through-design as much as possible.

7. Understand context

We’re not designing for a screen, we’re designing for people. We need to think hard about the context in which they’re using our services.

Yes! This is so important these days especially because of the uptake in mobile web browsing with smartphones and tablets. Designers need to adopt responsive web design and mobile-first approaches into their process and teach clients the importance of designing for context.

8. Build digital services, not websites

Our service doesn’t begin and end at our website.

With the exception of exclusively e-commerce businesses, most clients in the private sector actually deliver their business outside of the world wide web. Designers need to remember this, and ask more questions about the way the client works. Their website is rarely the last interaction with a customer, and is more likely one part in a chain of events, so the more the designers know about the whole user experience, the better equipped they are to design well.

9. Be consistent, not uniform

Wherever possible we should use the same language and the same design patterns — this helps people get familiar with our services.

Consistency is so important in making a system learnable, not just across a single website, but across the multiple web presences that a client might use. Be consistent as much as possible, whether designing the client’s website, payment process, social media portal or web app.

10. Make things open: it makes things better

We should share what we’re doing whenever we can. With colleagues, with users, with the world. Share code, share designs, share ideas, share intentions, share failures.

One of the best things about working in the web is the generosity and openness of many practitioners. I have benefitted greatly from the willingness of great designers and developers to share their knowledge and experience, and, although our expertise is the key of our business, we take every opportunity to share our knowledge and experience with clients and peers.

But openness isn’t just important with regard to knowledge. In a previous post, I spoke about the importance of using open source as much as possible as a way of empowering our clients. If we build client sites with popular systems like Drupal, WordPress or Joomla, then they are not tied to one web agency’s bespoke system, and can easily hire another developer who can pick up where the previous left off.

Serving citizens well

The public sector often gets berated for being behind the times and out of touch – sometimes the criticism is justified, other times its unfair. But credit, where credit is due – this type of approach to digital service design is brilliant.

I’ve worked a lot with organisations in the public sector, especially in higher education, and I have seen first-hand the difficulty of developing systems that are user-centred, when there are inter-departmental politics, centralised policy making and multiple stakeholders involved. These factors must be multiplied ten times over in central government, so what the GDS team is accomplishing is amazing. They seem to be in touch with current web trends, and actively participate in discussions in the industry, and I welcome that immensely.

The Government has a duty to serve its citizens well in all areas of life, and while there is a lot wrong with many policies and laws handed down by the powers above, it is a relief to see something as important as the GOV.UK project being tackled in the right way.

Having established the business goals that we, as an organisation, want to achieve, it was time to focus on our target audience. Everyone who runs a business has an ideal customer or client – the super rich, frivolous spender, who is willing to try out any of your suggestions – but it would be unwise to tailor your website to this user persona if, in fact, that type of customer is out of reach. With us, we wanted to be realistic about who our target market is currently, and also in the next three years. The following characteristics are what we look for in potential clients:

Small and medium sized enterprises (SMEs)

We have to be honest with ourselves that none of the big names in the world would hire us now because we aren’t an established brand yet. If we were to try and pitch for work to O2, Tesco or Sony, it’s unlikely we would be hired. The more realistic clients for us are small and medium sized enterprises (SMEs) with annual turnovers of £250,000 to £3million. We are particularly interested in the Alternative Investment Market (AIM), which is a sub-market of the London Stock Exchange. It includes businesses that are successful and growing, which means they have the marketing budgets that would allow us to carry out our in-depth process.

E-Commerce businesses

The best part about working on e-commerce sites is the opportunity it gives to measure success. With other websites, testing whether it is doing a good job at garnering interest in a product or generating leads is not an exact science. E-commerce sites can show us success for the business down to the last penny, and using analytics we can track the customer journey from the moment they enter the site, until they have checked out. E-commerce clients also give us an opportunity to tie our income to performance, where we can take a percentage of their increase in profit.

Companies that are required to have a website by law

Some organisations must have a public website for legislative or regulatory reasons, much like the AIM companies mentioned above. It would be unwise for us to ignore these types of customers because the argument about the need for a website has already been won. There will be no resistance from the stakeholders who don’t believe a website is necessary for their organisation, and so the time is better spent on discussing new site features and functionality.

Companies that have a marketing department and allocated budget

In our experience, businesses that do not have a proper marketing department with an allocated budget, are more reluctant to spend the money required to make a website redesign worthwhile. By working with a marketing department, they can often be used as an ally when negotiating the need for certain website functionality with the businesses owner. Often, marketing professionals have a greater understand of the power of a website to generate business, and will give weight to discussions on return-on-investment.

Companies seeking long-term website evolution

We also want to work with companies who appreciate the need for long-term monitoring and evolution of a website. When a website launches it is the beginning of something, not the end, where an iterative cycle can begin to improve its weaknesses, and capitalise on its strengths. Working with such a client is ideal for us because it shows their understanding that success on the web isn’t free, it takes time, patience and money.

Companies involved in film, music and home entertainment

Strictly from a creative output perspective, working with people involved in pop culture will give us opportunities to build really visually stunning, artistic websites. It might even boost our street cred, too.

Conclusion

Establishing characteristics of our target market allowed us to make decisions on our website structure and content. In the next post in this series, I will discuss our users’ goals and how they dictated what content we included on our website.

Last week our new agency responsive website went live. It is the product of a long, on-again-off-again process, as agency site redesigns often are due to client work coming first, and it started way back in October of last year. We had just finished reading Ethan Marcotte’s book on Responsive Web Design and Luke Wroblewski’s book on Mobile First, and like many who’ve read those two short books, we were buzzing with ideas on how to adopt this fundamental shift in the web design process.

Admittedly, in our excitement, we jumped right into wireframing for different screen sizes, but struggled with content positioning/hiding on smaller screen widths, a subject matter I posted about in November. So, we decided to stop, regroup and treat it like we would approach one of our client projects – by starting with business goals.

General business goals

Establishing what we wanted to achieve as a business helped us to determine how our website and online strategy could play a part in delivering this. We agreed that as a business we want to:

• Make money
• Establish a strong reputation
• Develop contacts in the web design industry

But this wasn’t specific enough to develop online business goals, so we broke it down further:

• Make money
• Produce 10-15 bespoke websites per annum
• Generate regular recurring income from retainer work
• Consult on aspects of web design and online marketing
• Sell our own products or designs online
• Get paid teaching work in higher or further education
• Get paid speaking gigs
• Write (and maybe publish) a book
• Establish a strong reputation
• Produce brilliant work
• Good word of mouth
• Contribute to the web design industry (forums, blogs, Twitter, LinkedIn)
• Attend conferences and events
• Contribute articles to online and print journals
• Host our own events for educating people about using the web for business
• Develop contacts in the web design industry
• Attend conferences and events
• Make connections through social media
• Comment on blogs & forums

Online business goals

We then asked ourselves how can a website help towards meeting any of the above general business goals? The answers became our online business goals, and our new website design would be tailored to deliver them. They were as follows:

• Be a showcase of our design skills
• Host a blog to express our ideas and processes
• Host an e-commerce element to sell our products/designs/apps
• Streamline our production processes through clients section
• Advertise our own events/classes
• Promote our individual skills and knowledge for speaking/teaching opportunities
• Promote our other online/offline activities

Conclusion

Before starting any web project, it is vital to perform a Definition Stage, where online business goals are formed as possible solutions to delivering on an organisation’s general business objectives.

We see all the time with our clients how eye opening this can be. Often a client will have a business objective that they didn’t realise could be achieved via their website, or social media activity. Of course, we wouldn’t be able to suggest a way of delivering that objective if we didn’t sit down and have them explain their short and long term goals.

With our business goals identified, our next step was to determine our target audience, so that we could begin to develop content that was pertinent to them. This will be discussed further in the next post in this making-of series.

We’re pretty excited about this, as it means we can more effectively empower our clients by building them websites that are truly platform-agnostic, meaning they are more accessible for their customers. For many of them, this will go a long way in helping achieve their online business objectives.

Our latest responsive project was a website for our friends at GV Film. With the help of HTML5 Boilerplate, and a sprinkle of Andy Clarke’s 320 and Up add-on, we built a site that can deliver a portfolio of trailers to visitors on desktop computers, tablets and mobile devices, without the site’s content being compromised by smaller screensizes.

Respons-ify a Drupal theme, I challenge thee!

The GV Film site was built on a small CMS called Pulse, which integrates very easily with static HTML and CSS, but when trying to use responsive design techniques on a large CMS like Drupal, there are a few challenges.

A project we are working on for a major London Charity has given us the opportunity to develop a responsive Drupal site as a real world case study. It uses Drupal 6 and the theme is being coded from scratch, using HTML5 boilerplate as a starting template. I will write a more in-depth blog post after the site is launched, but for now I will mention a few issues we’ve come across.

Drupal isn’t mobile-first by default

Drupal’s theming engine hasn’t been a problem, so far. We’ve managed to include the usual API variables and hooks to create and display the theme on various screen sizes using media queries. This was expected; at the end of the day Drupal is just a system that outputs HTML and CSS, so there should be no reason media queries would cause a problem.

What has been a bit of a struggle is getting the CMS to output un-bloated code in its views and blocks templates. Drupal started as an open-source project many years ago and hasn’t yet adjusted to the new mobile-first approach that many are attempting. As default, the system generates many, many nested divs with multiple id’s and classes, which is great for granularity when styling, but not so great when aiming for small data sizes, and quick page loads on mobile devices. Of course, the solution is to create customised template pages for the blocks and views that are being displayed, but this takes time and also adds to theme folder size – meaning the system has to work that much harder to display a page.

Third-party module developers have their work cut out

The beauty of an open source system like Drupal is the availability of add-ons built by developers the world over. Of course, these developers work at their own pace and have their own priorities, so ensuring their modules are compatible with the latest web trends (like responsive web design) is way down on their list. Because of this, third-party modules can output code that breaks a responsive web site.

I had this exact problem with the image module. It extends a Drupal site to allow a single image to be uploaded, and then derivatives of that image to be produced automatically into pre-set sizes. The fatal flaw occurs when the module outputs img tags that specify a width and a height. This, of course, prevents an image from resizing on a responsive web site because the use of CSS’s max-width : 100% becomes overwitten by the dimensions in the HTML img tag. The result is a site whose images are far too large and fall off the side of the page on small-screened devices.

We could re-write the image module to output the images without widths and heights, but that requires time and resources, something that most clients can’t spare. Other image modules, like imagecache, may be more compatible, and this is what we are experimenting with currently.

Changes come slowly

There is a slow rise in development of modules that are compatible with the responsive web design approach, most of them being implemented in Drupal 7. Hopefully, 2012 will see more developers building their modules’ functionality from a mobile-first perspective so that we can continue to empower our clients.

The website owner is a user too!

User experience designers are fully aware of the need to create websites that are useable and useful for their visitors. They work hard to wireframe and prototype complex interactions, and map out all the possible user journeys a site may present. What some UXDs often forget, especially when building a CMS from scratch, is that a website owner also experiences the site, and that experience is just as important as that of the anonymous website visitor.

When I say website owner, I mean the set of users that contributes, reviews and edits content on the site. They own the website in the sense that they are stakeholders in its success or failure.

What got me thinking about the whole notion of the website owners’ experience was a small problem we encountered after the soft launch of ajbam.co.uk. As with any website launch, there are always a few niggles to iron out, and in this case it was a problem with positioning images in a news item using the wysiwyg editor. We had provided CMS training to the AJBAM team, but when they came to use the system for real they just weren’t happy with the process of embedding images into text.

This made me realise just how important it is to consider the usability of the admin pages of a CMS. These contributors need to be able to login and find their way around the content. They need to know how to add their text, images and video correctly so it will display in the correct section of the website. The interface should be easily learnt, recalled and remembered, so it isn’t a struggle each time a contributor wants to publish some content.

Treat the admin pages as a web app…perhaps?

When you break it down, a CMS website is half website, half web app. A web app is commonly defined as a website that allows users to perform a small set of tasks. Well that is exactly what the admin pages of a CMS does: allows users to create, edit, publish and delete content. At least at the contributor level, anyway.

But a web app wouldn’t be launched without extensive user testing to ensure the system works appropriately. In the same vein, CMS systems shouldn’t be launched without proper research, prototyping and testing of their admin pages.

Selling it to the client

We’ve been hired to redevelop many CMS websites where the previous agency has made a pig’s ear of the admin pages. And I’m fairly certain that one defining factor plays a part in each case – budget. It’s hard enough for us to persuade clients to shell out money on things like usability studies, project management or robust hosting packages, so imagine then trying to explain the importance of testing and tweaking pages that their visitors won’t even see.

But that’s exactly what we have to do. There’s no point in developing systems that make content look nice, but are problematic when trying to edit and publish.

I’ve recently been reading The Win Without Pitching Manifesto by Blair Enns. He suggests that the only way to get clients to agree to our recommendations is to position ourselves as experts in our field, rather than members of a service sector. A patient can’t tell a doctor what healthcare he should provide, nor can a lawyer be told what to say in court. Why? Because they are experts in their field. Creative web practitioners need to adopt the same approach if we want our profession to be respected and trusted.

A false sense of empowerment

Let me explain. We recently took on a client who had had a website built for them by their previous web agency, and for whatever reason their relationship ended and the client was left with full ownership of their website. After a couple of casual discussions, a kick-off meeting and a series of remote user tests, we were tasked with making some major changes to their website to improve user journeys and calls-to-actions. Simple right? Wrong.

The previous web agency had made a pig’s ear of developing the CMS. Their code was sloppy, PHP includes were randomly scattered throughout their files and they had devised a very unorthodox template system to generate the front-end. In short, the time it would have taken to work out their spaghetti code and apply the requested changes took the client way out of their budget range. Our quote was too expensive because of the poor practice of the previous agency. The client was under a false sense of empowerment. They had paid good money for a website and they (quite rightly) assumed they had made a good investment that would stand the test of time.

We ended up scaling back the proposed changes to be mere cosmetic tweaks, which left us with a bitter taste and (in our eyes) a job half done. I had the distinct impression that the previous agency had purposely built a site that would discourage easy changes and force the client to keep returning to them. What was more worrying was their branding was all over the admin area and the names of their content types were very generic, indicating that they probably used this monstrosity for all their clients’ websites.

Open source is an open mind

If the previous web agency had built the client’s CMS on WordPress, Drupal, Joomla or any of the other open source, community supported systems, our client would have been able to afford the proposed work. The CMS would have been built with high quality, documented code, that is both standards based and also extensible using community supported modules.

In this day and age, I can’t believe web agencies are using their own bespoke systems as a product to sell. The amount of pre-built and pre-tested plugins that are available for open source development is quite frankly astonishing, so whenever I come across a bespoke site like this I always suspect foul play, or at the least that their business model is totally backwards. Would it not be more economical to use the code that a huge community of developers have built and tested for you for free? It would certainly free up time and budget to focus on the more important tasks like user testing, analytics and content strategy.

And let’s say your relationship does eventually end with that client, it happens. Because you opted for open source development, it is much more likely that the next agency, freelancer or in-house developer can pick up where you left off without having to do a costly source code review. It means you have provided a service that extends beyond your project scope and improves business continuity. That is what we should aspire to achieve in all of our work. Products that are universal and lasting.

We are not just code monkeys or pixel pushers

Now, if only the client had someone on their team who knew just a little about the benefits of open source, this problem may have been nipped in the bud. But it’s not really their fault, they are all busy as bees doing their own job. It’s up to us to educate our clients.

The web is young and still finding its feet, and as a profession web design and development is only recently beginning to make progress towards something that people outside the industry respects. We are no longer code monkeys or pixel pushers, hired to sit in dark rooms producing work for misinformed clients. Thanks to the work of so many industry leaders (too many to even try and mention) we are starting to be heard and listened to. Clients are realising that we know a thing or two about the web, and are more open to suggestions. It is, therefore, very important that we take this chance to educate clients on the importance of building open source, portable, scalable websites. Websites that empower and protect them.

It is not enough for us to work just for our hourly rates. We need to build sites that help our clients achieve business goals and make a real tangible difference, so that our profession can be taken more seriously.

Let’s empower our clients, starting with open source.

My favourite so far, though, has been Naomi Atkinson’s responsive site – and not just because of its gorgeous design. She has used JQuery Masonry to simulate the re-ordering of the divs as the viewport’s width gets narrower. Resize your browser and check it out, it’s great! That little injection of user feedback boosts the user experience no end.

Mobile users won’t need that, right?

Whilst working on making our own agency site responsive, the question of whether to remove certain content from the mobile layout kept popping up. During the discussion, my initial gut reaction was “hell no” as I, firstly, thought it would be a mess to do technically, and secondly, am of the firm belief that we as web designers can’t possibly be able to assume what a mobile user might want to view or not. I didn’t realise it at the time but my mind was reverting back to Jeremy Keith’s article on the notion of One Web, where he states:

I think there’s a real danger in attempting to do the right thing by denying users access to content and functionality “for their own good.” It’s patronising and condescending to assume you know the wants and needs of a visitor to your site based purely on their device.

Now, here Jeremy was discussing standalone mobile sites (like those with an m. extension) versus desktop sites, but the argument is still valid for responsive design. Admittedly, others in our discussion put forward the strong case of the National Rail mobile site. It strips away everything from the desktop version of the site leaving the most important information – train times and fares for the next three departures.

This is purely on the assumption that a user would only be visiting the site on a mobile device for an urgent need to check train times. Now, I can’t argue with that particular user scenario, stripping away the rest of the content works, and works perfectly.

And there are obviously some types of content that can be removed without causing too much trouble. Paul Boag has recently responsi-fied the Boagworld blog, and he chose to remove the left sidebar on narrower screens (see Dan Sheerman’s profile on the left vanish when the browser window is narrowed).

But, to be completely honest, even this bothers me. Perhaps I am being selfish, but I want to be able read Dan Sheerman’s profile on my iPhone. I want the option to read everything on the dekstop version of a site, on my mobile device also. I feel robbed damn it!

Give up man, the screen is too small!

This whole subject has been bugging me for a while now, until this morning when I read Stephen Hay’s responsive web design article in .Net Magazine (Nov’11, p.45). It reads:

I’d suggest bringing a platform-agnostic approach to content and a platform-aware one to user experience.

I seriously couldn’t put it better myself. We as web designers shouldn’t discriminate against our mobile users by removing content. It is up to us to craft websites that reposition the content to suit the viewport’s size. This could be as simple as making everything fit into one column, or as complex as hiding content in accordions or tabbed blocks, for the user to reveal when needed. In other words, we need to build one web, and cater for multiple experiences on smartphones, older mobile phones, desktops, laptops, tablets, and even widescreen TVs.

Returning back to the case of the National Rail website, it is obviously appropriate to place the journey planner at the top of the page on small screens, but access to the rest of the content about pet travel, disabilities information, season ticket details etc, should be worked into the page below in a user friendly manner. Mobile users shouldn’t have to click three or four times to find their information.

I know it won’t always be possible, but we have to get away from these sweeping assumptions that mobile users are “on the go” and the best way to do that is by performing research, specific research, on a project-by-project basis that will inform our responsive web designs.