Our site redesign [Part 1] – Defining business goals

Posted on by
Reply

This is the first in a series of blog posts detailing the design and development of our new agency website. While the site is by no means finished, I wanted to write about the process and what we’ve learnt along the way. 

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.

Responsive web design with Drupal: Some early thoughts

Posted on by
Reply

In the last few months we at Joy and Revolution have begun to change the way we design websites. In a nutshell, we have decided that all of our future client projects will be built as responsive websites, as long as there is a valid business case.

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.

Good UXD isn’t just for users, it’s for website owners too

Posted on by
Reply

Last Monday marked the launch of a website for one of our favourite clients. Reader, I’d like you to meet www.ajbam.co.uk, fresh out the oven! A J Buckley Asset Management is a small investment management firm in Surrey who we have been working with for over a year now. For the last few months we have been quietly working away at re-branding their online presence, to reflect their in-house restructuring and changes within their industry. But that’s not what I want to talk about now! Instead I wanted to discuss the website owners’ experience.

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.

Empower your clients with open source

Posted on by
Reply

In my quest to cure insanity one website at a time, I have come to realise that we in the web community are not doing enough to empower our clients. We all need to make a living – that is obvious – but some of us, in our desperation to guarantee income, have resorted to the dark practice of building highly bespoke CMSs with the sole purpose of giving clients almost no choice but to be tied to them, and them only.

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.

One Web, Multiple Experiences

Posted on by
Reply

The whole industry seems to be neck deep in responsive web design at the moment, with sites popping up all over the place. It’s been almost 18 months since Ethan Marcotte’s infamous introduction to the concept, and the launch two weeks ago of the Boston Globe responsive site is its first real test on a high-traffic, high-powered content management system.

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.

Mobile First: A shift in thinking

Posted on by
Reply

Having just reached the final few pages of Ethan Marcotte’s book on Responsive Web Design, I was completely thrown by his suggestion to design websites for the mobile platform first, and then cater for larger screen sizes afterwards. I had just spent the better part of two days wrapping my head around fluid grids, flexible images and media queries and had so many ideas for the Joy and Revolution site redesign, but I felt it odd that he left it to the last minute to mention this huge shift in process.

I say huge because that’s what it is: huge. Designing a site to be mobile-sized first forces you to prioritise the content, think about context of use, and really question the use of images. It’s so easy to design a full-sized website in Photoshop and throw supplemental content in the right column of every page in the name of content promotion. However, persuading a client that he or she needs to agree to shrink, or even completely remove content on their pages is going to be a challenge.

Know your audience
One of the challenges we are facing in redesigning our agency site to be responsive, is how to prioritise the content for our mobile users. Admittedly, we are in our early days as an organisation so access to our audience for user research is somewhat limited. Our initial assumption was that users accessing our site on mobile devices would be on the move in the outside world, and only interested in reading our About Us text and getting in touch using the contact form.

However, Luke Wroblewski mentions in his latest book Mobile First a survey that found 84% of people used their smartphones at home, and 64% used them at work. This quashes our earlier assumption about mobile users. Smartphone owners are not just accessing the web because they need to (i.e find directions, contact details), they are browsing the web because they want to. Mobile browsing is becoming the default web experience for many people, especially the younger generation. And it makes sense. Why turn on your desktop computer when you can sit on the couch or lie in bed and access the same content?

This forced us to rethink our content priorities, and bring our project case studies to the fore. Despite the smaller screen size of an iPhone or Android phone, potential clients will still want to read about our previous projects.

The site is still in development, but I plan to post more on our attempts to create a responsive web design for mobile first, soon.