Latest Featured Post

Responsive Web Design Lessons

So the dust is starting to settle as we become familiar with a number of techniques for developing responsive websites, but for myself, this road has not exactly been as problem-free as I thought it was going to be. First, a quick overview for those unfamiliar with the concept of responsive web design.

Read More

Responsive Web Design Lessons

Posted by Mikey McCorry | Posted in Featured | Posted on 31-07-2012

Tags: , , , , , ,

0

So the dust is starting to settle as we become familiar with a number of techniques for developing responsive websites, but for myself, this road has not exactly been as problem-free as I thought it was going to be. First, a quick overview for those unfamiliar with the concept of responsive web design.

“Day by day, the number of devices, platforms, and browsers that need to work with your site grows. Responsive web design represents a fundamental shift in how we’ll build websites for the decade to come.” - Jeffrey Veen

Responsive web design is a name given to the process of designing and building a website that responds to the device which is accessing it, delivering an appropriate layout. For example, instead of the traditional approach of designing a small-screen version of a site for mobile users, this approach requires only one website, including behaviour and styling rules to determine how it should appear on any-sized display.

This is not a new idea: as early as mid-2007, I’ve added support for both 760 and 960 pixel widths for sites with JavaScript, however more recent support for CSS3 media queries from modern browsers, plus great articles from Ethan Marcotte and Jeremy Keith, have helped move this process into the mainstream. Many have also called responsive web design the new “best practice”, essential for moving our profession into the future.

In theory, it’s quite a simple premise: serve different styles for different view-port widths, however it’s been a fairly long learning curve from a development perspective. We’ve adopted a lot of new processes, tools and methodologies to try and make life a bit easier for ourselves.

In my day job, we’re currently putting together a full redevelopment of our website. This will be the fifth responsive web design project that I’ve been involved with.

Getting in the right head-space

For the design side of things, we’re designing to a 12-column fluid grid, making sure that everything snaps to this grid. A grid imposes order to web pages and provides a solid visual and structural balance and consistency to the layouts. As the width of the browser’s viewport changes, certain content containers change the number of columns they use and re-wrap and flow to provide an optimum layout for that width.

We’re using a modified version of the Semantic Grid System by TwigKit. We are also using SASS to write our stylesheets, which I’ve fallen in love with, and has become an invaluable tool for CSS development.

Because this is a CMS website with any number of possible page content configurations, we needed to find a grid that will work for all possible situations. We went with 12 columns, as 12 can be divided by 2, 3, 4, and 6 equally, providing a large number of combinations to best display our content, regardless of the screen width. Once we had the grid and gutters set up, it makes it lot easier to try different layouts.

Work in progress screenshot showing grid overlay.

Work in progress screenshot showing grid overlay.

One of the biggest challenges is deciding the best possible order to display the content on the page. When the view-port is narrow, everything gets shifted into a linear layout with one column for everything. When the user is scrolling through the page on their smartphone, tablet or smart TV, which content should be at the top? How much space should the top header take up? Should the local page navigation go above or below the page content? Should the image go above or below the intro paragraph? Or below the entire article? Is there anything in the sidebar that needs to be at the top of the page or can it all shift to the end, just above the footer? There have been a lot of these sorts of questions.

The other thing to think about is page download times. Unfortunately, there’s still no ideal standard solution for responsive images. This means that we still need to serve larger resolution images to small-screen users. We’ve tried to address this by greatly simplifying our overall design with a focus on serving leaner, faster pages for everybody. By removing many of the unnecessary background images, patterns and other flavour imagery from our template, we’ve freed up hundreds of KB of bandwidth per page, which can be better utilised in serving higher quality relevant photos.

Many of the early responsive web design tutorials recommended setting about four “standard” break-points (page widths where the layout changes to fit the screen): smartphone, tablet (portrait), tablet (landscape) and desktop. We decided it’s best not to specifically work towards these break-points, but rather design for the content with a fluid layout. It’s a bit more involved, but it’s much safer to not assume which devices the user is viewing the website on. There are heaps of different phones, tablets, game consoles, smart fridges :-), etc, each with their own resolutions and portrait/landscape modes.

Instead, we’ve concentrated on a device-agnostic approach, designing the individual parts of the page separately, as components, like Lego blogs, that can be fit together into a layout. For example, what does the main navigation look like? What does a form look like? What about a narrow version of a form? The search bar? The breadcrumbs nav?

We do most of our designing directly in the browser where we can get a good idea of not only how everything will look, but also how it behaves at different widths. We do some of this “atmosphere” work in Photoshop, where the tools allow for better visual brainstorming, but then we work to move it into the browser as soon as we can.

Work in progress screenshot showing examples of atmosphere design elements.

Work in progress screenshot showing examples of atmosphere design elements.

We also use Photoshop to mix up our site’s colour palette, making sure that contrast ratios all conform to the WCAG 2.0 accessibility guidelines.

GSCC Palette Swatch

Many people recommend a “mobile first” approach to design, starting with the base mobile experience then scaling up. I combine this approach with my old methodology, first working on the wire-frames at the very start of the process to see how the layouts could potentially look at different widths. These are used to try out ideas before writing any code, but they usually change once they’re in the browser with real content. (Apologies for the crappy camera phone photo below.)

GSCC Wireframes

After deciding on the content order and developing the mark-up, the page content is set out linearly, then we start scaling the browser up until it starts looking wrong. During this process, we apply a number of rules that dictate how the page layout should work. For example, I like to use an ideal text line length for optimised readability of around 75 to 100 characters per line. If the text lines get too long, we reduce the column width, increase the font-size or otherwise re-balance the page.

Testing

We’ve set a base-line of browsers that we test in and make sure our site is optimised for.

  • Latest IE, Chrome, Firefox, Opera and Safari on the desktop.
  • Stock Android browser and Mobile Safari on iOS devices. I’ve got an iPad2 and iPod Touch 4G (with Retina screen) for iOS, and on the Android side I’ve got a Samsung Galaxy S2 and a 7-inch tablet, that is, until we can get some budget to buy ourselves some more testing devices :-)
  • IE8 and below do not support CSS media queries, so we employ Respond.js, a javascript patch (or polyfill) that emulates the responsive breakpoints, which works pretty well. Also see CSS3-MediaQueries.js, a larger script, but with greater support for different media queries.
  • IE7 has become our second-class citizen with about 4% usage. Everything still works, but it’s pain to get it all working the same as the newer browsers, so we get to a point where near enough is good enough and move on. It’s better to invest our time and money into working towards the future than supporting the broken past.
  • Support for IE6 has been dropped, with less than 1% usage. Although all content is still viewable, there are just a lot of odd layouts, weird floated elements, etc.

Limitations

Fluid layouts can still be a problem. Fluid layouts use decimal-percentage-based column widths that round up to the nearest pixel. Unfortunately, this pixel rounding can be quite different from browser to browser. Most browsers round down to avoid adjacent floats from breaking, but this can result in being a few pixels out once you get to the edge of the page, even more so if you have many, nested columns. This can be designed around when building a new site, but I’ve had difficulties with this when trying to convert a fixed-layout to be responsive.

Apart from the other browser support stuff above (I’d love to be rid of IE7 and IE8 for good and use IE9 as a base level for support, but that won’t happen for a while…), something else to be aware of is that we can no longer rely on mouse hover states for things like drop-down menus, as there is no such thing as hover on touchscreen devices.

I believe the very most important thing is simply to consider how you can give the leanest, fastest, most streamlined experience for all users, removing unnecessary fluff from the page and focussing on how to best present your content. This is not a limitation, but rather the way web design will need to be going forward. There are some tough problems to solve, but heading towards a more ubiquitous web, we will be much better for it.

P.S. Yes, the irony of talking about the importance of responsive web design on a non-responsive site is not lost on me. I’m workin’ on it! :)

What features should a commercial CMS have?

Posted by Mikey McCorry | Posted in Featured | Posted on 23-09-2011

Tags: , , , , ,

3

I’ve recently had the pleasure of properly working with ExpressionEngine for the first time on a couple of client projects. The experience with EllisLab‘s flagship content management system so far has been mostly great; there is a lot of power under the hood and a solid methodology behind one of EE‘s greatest strengths: the ability to manage almost any kind of content you can think of.

EE has managed to do quite well for itself, despite costing $299 for a commercial license, and competing against hundreds of free, open-source products such as WordPress, CMSMS, Joomla and Drupal.

It also has a strong aftermarket for addons, modules and plugins to add useful features that are not included in the out-of-the-box package. This can be great to enhance your website beyond the scope of what is normally provided by a CMS, such as e-commerce, calendar events, image galleries, etc.

But there has been one sour note that has been making me question whether I’ll continue to recommend EE for new projects going forward: EE relies too heavily on paid addons to provide basic functionality that I feel should come out-of-the-box with any commercial CMS.

Here are just a few areas where I feel EE falls short of where it should be:

  • Websites are made of pages. It sounds obvious, but the included ‘Pages’ module is quite limited in it’s usefulness. While pages can be kinda nested into some sort of heirarchy, there’s not much you can do with that structure. The ‘Structure’ module goes a long way towards managing your website’s IA much easier, but it costs an extra $65.
  • Navigation is a drag. Most EE tutorials only cover static, hard-coded navigation which works fine until the client wants to be able to add new pages themselves. Once you have your pages organised into a nice, meaningful structure, unless you want to fumble around with awkward categories, to generate navigation dynamically from this structure will require another $35 for a navigation addon.
  • Want to crop or resize images from in the template? Lets say you want a blog post’s image to be used as a thumbnail on your homepage. Then again in your blog index. Then again on the actual blog post page. Then again for the image enlargement. That’s at least four different sizes you’ll need. EE can automatically resize or crop an image on upload, and that’s cool, but this is not explained very well in the documentation and is not very developer friendly. The ‘CE Image’ plugin has been fantastic for addressing this, albeit for an extra $15.
  • File management is a jumbled mess. The ‘Assets’ module can help you with that for an extra $55. It says something about how underdeveloped file management is in EE when the addon authors say that “at last, managing your files [can be] just as powerful and elegant as managing the rest of your content in ExpressionEngine.”

These costs all add up, and in my case, brought the overall cost of the CMS to much more than what I first quoted to the client. This is my fault more than anything for not doing the research and assuming too much about what EE would offer OOTB.

EE has a strong, passionate community who I’m sure will jump to its defence with the following:

  • the CMS provides the tools to cope with the requirements for a majority of websites;
  • it is built on a strong platform (CodeIgniter) and provides APIs for developers to extend any percieved shortcomings quite easily; and
  • the cost of the addons should simply be included in the quote for your project and passed on to the client.

These are all true, but I guess I’m really just questioning what base-level functionality should be expected in a commercial CMS of this price. What do you think?

Jcrop – Quick and easy image cropping with jQuery.

Posted by Mikey McCorry | Posted in Elsewhere | Posted on 21-09-2010

0

Jcrop from Deep Liquid is a quick and easy way to add image cropping functionality to your web application. It combines the ease-of-use of a typical jQuery plugin with a powerful cross-platform DHTML cropping engine that is faithful to familiar desktop graphics applications.

  • Attaches unobtrusively to any image
  • Supports aspect ratio locking
  • Supports minSize/maxSize setting
  • Callbacks for selection done, or while moving
  • Keyboard support for nudging selection
  • API features to create interactivity, including animation
  • Support for CSS styling

It’s definitely one of the best one’s I’ve come across. It’s about 5.5KB (minified), compatible with all browsers and its free (MIT license)! Check out the demos.

“UX Professional” may be a bullshit job title, but they’re still needed.

Posted by Mikey McCorry | Posted in Featured | Posted on 04-09-2010

2

Yesterday, Ryan Carson (of Carsonified) tweeted the following:

'UX Professional' is a bullshit job title. It's just a way to over-charge naive clients. All web designers should be UX pros.It’s always hard to concisely convey a thought, especially one as blunt as this one, in 140 characters without ruffling a few feathers, so after copping a bit of flack, Ryan followed up with a post on the Think Vitamin blog.

Ryan is a very smart guy with over 10 years experience and several successful companies under his belt, and I mostly agree with Ryan’s comments, however I felt his views may be a bit myopic.

I personally couldn’t see myself hiring a dedicated UX/UE person. I believe that any web developer (which is the catch-all term I use to describe someone who develops websites – not just programmers) worth his/her salt should have all of the skills needed to take a web project through from concept to completion. They don’t have to be an expert in every field, but they should have a strong understanding of the principles behind great user experiences. UX is a design practice; a subset of skills, not a job title.

He is absolutely correct in saying that web developers should know these UX principles and apply them to all aspects of the web design process, however the problem is that not everyone does. Generalists are jack-of-all-trades, with one or two specialisations in their strongest fields, and unfortunately, for many web developers (especially those more on the dev/programming side) they are not UX specialists. I feel that most of UX is just common sense, but I can understand the need for dedicated UX specialists in large agencies or companies that create complex applications with fiddly UI interfaces.

However, I feel that the same job can be performed by a small team of generalists in a peer review/agile/scrum development process. In my day job I work as part of a small team of two generalists. We are always bouncing ideas, wire-frames and interface options off each other, working towards delivering the best experience for the end user.

Also, I get the understanding that in Ryan Carson World™, all web agencies must be small-medium teams or freelancers, and their projects are low-risk or single-function web apps. When there is a lot riding on a project, the risk of failure needs to be minimised as much as possible, and in some cases you need to bring in the big guns. I consider myself a half-way decent designer, and have designed logos, stationary and print advertising for clients in the past , even though it’s not my speciality. However, if a large, national client requested the same service as part of a new product launch, you can bet the farm that I’d be getting specialist help.

In his post, Ryan says:

A web site or app should be the product of a Web Designer and a Web Developer (who occasionally are the same person, as demonstrated by Shaun Inman).

In this sentence Ryan acknowledges that clever people like Shaun Inman exist. By Ryan’s own logic, why even have separate job titles for design and development. Why not just hire a crack team of Shaun Inman super-soldiers that are experts at everything and take over the world? The problem is that finding a talented, well-rounded web designer is rare, while phoney-baloney UX “experts” and “professionals” are abundant.

In the end, companies should just hire the best people they need to get the job done.

When email marketing meets online user testing

Posted by Mikey McCorry | Posted in Featured | Posted on 02-07-2010

0

A marketing email from Loop11, the maker of online usability testing software, did the rounds among local government IT managers, marketing teams and mailing groups last week claiming in it’s subject that “City Of Melbourne website ranks 2nd in Australia.”

Screenshot of the Loop11 website offering the usability case study.

Screenshot of the Loop11 website offering the usability case study.

The email, offering a usability case study on six of Australia’s capital city websites, got passed around some of the execs/managers at my day job with much interest, then passed to me for evaluation – well, actually it was more of a “TL;DR. Why aren’t we on top of this list?” (We’re not a capital city for starters. :-))

On reading the published report, there were a few things that immediately stood out for me. First of all, this post is not intended as a rant, merely an observation and commentary on both the marketing aspect of the report and the user testing process. Loop11 looks like a great tool, and this exercise has most likely drummed up quite a bit of interest in their product as well as the idea of user testing in general.

There is some obvious link-baiting going on in the email subject. Not to detract at all from Melbourne’s great website (of which I’m a fan), they came second out of six captial city websites, not exactly “2nd in Australia” as mentioned in the email’s subject. There’s no doubt that the sole purpose of the report was an attention-grabbing marketing exercise for Loop11′s user testing software. That’s not necessarily a bad thing, however the test itself seems rushed and inconclusive.

The six council websites were tested by 600 random world-wide internet users to complete one single task (100 testers per website) recruited from Amazon’s Mechanical Turk service which, to me, sounds like the internet equivalent of a sweat shop. The testers were paid 5 cents each for completing the task.

When conducting your own testing, you would be better to test a much smaller selection of people. Usability guru Jakob Nielsen believes that 85% of problems can be found with only 5 users (and a follow-up test with 5 more users should pick up most of the remaining problems.) You would also likely offer higher compensation (such as a free cinema ticket) to get a better buy-in from your participants.

The task the testers had to complete was “Find out what day your household waste is collected”. So in the end, the result is less “most usable website” and more “most prominent waste collection link“. In a real-world test scenario, you would obviously test more website functions across a number of council services.

As I said before, I actually really like Loop11′s software and think it can be really beneficial when performed adequately, however the price tag of $350USD per test ended up being a bit of a sore point for us. Being a developer of web applications who enjoys a challenge, it has definitely given me a bit to think about regarding perhaps developing my own in-house user testing application in the future.