Big Red Tin

HTML5 for Web Designers

2010-09-02T23:47:30Z

We haven’t yet moved onto HTML5 at Soupgiant. We still code in strict XHTML 1.0 for reasons that Peter knows a lot better than I, but I suspect it has something to do with familiarity and knowing that it works. There’s a safety in that.

We believe very strongly in semantic mark-up and getting things working as much as possible in as many places. We believe in graceful degradation. I believe in closing tags once they’re opened and I didn’t like how HTML5 didn’t demand a trailing slash on stand alone elements. That just seemed like chaos.

Jeremy Keith‘s new book, HTML5 for Web Designers is a no-nonsense 85 pages of the good and bad in the HTML5 specification. It explains how the spec is a lot more open and forgiving than previous specs. It also explains how much work was done to ensure better semantics than previous versions of HTML.

You’re probably thinking exactly what I was. How can any 85 page book tell me what I need to know about the largest HTML specification thus far? Is 85 pages even a book or is it more like an extended pamphlet? How can I take this seriously?

We bought the book largely because we trust the work Jeffrey Zeldman does. This is the first book he has published under Happy Cog’s new A Book Apart label. I thought that if anybody can get a writer to condense all the info I need into a short read, it’s Zeldman. But no pressure, JZ.

The important things it explains is how HTML5 can be used to include rich media on your websites, how it improves web forms (which got me really excited) and how it improves on semantics. And yes, it does actually explain them.

It explains these topics in enough detail that I could start using them today.

I want to keep learning and improving my knowledge of web-based coding. At the same time, I’m running a business now as well as continuing to produce a weekly podcast and trying to have a life. It’s hard to keep up with all the details of a new spec.

It turns out, all I ever wanted was an 85 page book that explained everything I needed to know and cut out all the stuff I’ll never use. I don’t need a beginner’s book but I also don’t want an expert’s tome. I want an executive summary and that’s exactly what this book is. If that’s all you need, look no further.

HTML5 for Web Designers by Jeremy Keith is available from the A List Apart store in paperback or ePub.

JavaScript Localisation in WordPress

2010-09-02T00:51:05Z

Recently on Twitter @iamcracks asked

Attention WordPress Wizards & Gurus. Is it possible to “get WordPress to write a custom field into a javascript variable”?

– source

While I wouldn’t be so bold as to claim I’m either a wizard or a guru, I happen to know the answer to @iamcracks question.

A while back I wrote a two part tutorial on using JavaScript the WordPress way, the code below builds on that. The first step is to load the JavaScript in functions.php using wp_enqueue_script() as detailed in the earlier tutorial:

<?php
function brt_load_scripts() {
  if (!is_admin()) {
    wp_enqueue_script(
      'brt-sample-script', //handle
      '/path/2/script.js', //source
      null, //no dependancies
      '1.0.1', //version
      true //load in html footer
    );
  }
}

add_action('wp_print_scripts', 'brt_load_scripts');
?>

This outputs the html required for the JavaScript when wp_footer() is called in footer.php

Localising the script is done using the function wp_localize_script() it takes three variables:

$handle – (string) the handle defined when registering the script with wp_enqueue_script
$javascriptObject – (string) name of the JavaScript object that contains the passed variables.
$variables – (array) the variables to be passed

To pass the site’s home page and the theme directory, we’d add this function call below the wp_enqueue_script call above:

<?php
...
wp_localize_script('brt-sample-script', 'brtSampleVars', array(
  'url' => get_bloginfo('url'),
  'theme_dir' => get_bloginfo('stylesheet_directory')
  )
);
...
?>

The output html would be:

<script type='text/javascript'>
/* <![CDATA[ */
var brtSampleVars = {
  url: "http://bigredtin.com",
  theme_dir: "http://bigredtin.com/wp-content/themes/bigredtin"
};
/* ]]> */
</script>
<script type='text/javascript' src='/path/2/script.js?ver=1.0.1'></script>

Accessing the variables within JavaScript is done using the standard dot notation, for example brtSampleVars.theme_dir to access the theme directory.

Using a post’s custom fields is slightly more complicated so I’ll write out the code in full:

<?php
function brt_load_scripts() {
  if (is_singular()) {
    wp_enqueue_script(
      'brt-sample-script', //handle
      '/path/2/script.js', //source
      null, //no dependancies
      '1.0.1', //version
      true //load in html footer
    );

    the_post();
    $allPostMeta = get_post_custom();
    wp_localize_script('brt-sample-script', 'brtSampleVars',
    array(
      'petersTwitter' => $allPostMeta['myTwitter'][0],
      'joshsTwitter' => $allPostMeta['joshsTwitter'][0]
      )
    );
    rewind_posts();
  }
}

add_action('wp_print_scripts', 'brt_load_scripts');
?>

Only pages and posts have custom fields so the check at the start of the function has become is_singlular() to check the user is on either a post or a page, earlier we were testing if the user was anywhere on the front end. The arguments for wp_enqueue_script have not changed.

the_post() needs to be called to start the loop and initiate the $post object so the associated custom fields can be accessed in the following line and put in an array.

With the custom fields easily available, the information can then be passed to wp_localize_script() as earlier demonstrated. The final step is to rewind the loop so next time the_post() is called, from either single.php or page.php, the post data is available.

The html output from the sample above would be:

<script type='text/javascript'>
/* <![CDATA[ */
var brtSampleVars = {
  petersTwitter: "@pwcc",
  joshsTwitter: "@sealfur"
};
/* ]]> */
</script>
<script type='text/javascript' src='/path/2/script.js?ver=1.0.1'></script>

Delay Print Stylesheets Plugin

2010-08-27T06:07:57Z

A few weeks ago I wrote a post in which I adapted an idea from a zOompf article to delay the loading of print stylesheets until after a web page has fully rendered. I finished that post with the following point/question:

Another question to ask is whether all this is actually worth the effort – even when reduced through automation. On Big Red Tin, the print.css is 595 bytes, the delay in rendering is negligible.

Chris and Jeff at Digging into WordPress picked up the article and posted it on their site. In turn it was picked up elsewhere and became the surprise hit of the summer at Big Red Tin. Not bad when one is shivering through a bitter Melbourne winter.

As a result of the interest, I decided to convert the code from the original post into a plugin and add it to the WordPress plugin directory.

Further Testing

As I warned in the original article, I’d tested the code in very limited circumstances and found it had worked. Fine for a code sample but not enough for a sub version-1.0-release plugin. Additional testing showed:

Stylesheets intended for IE, through conditional comments, were loading in all browsers
When loading multiple stylesheets, the correct order was not maintained in all browsers

If jQuery was available I wanted to use it for JavaScript event management otherwise I’d use purpose-written JavaScript. There’s no point, after all, of worrying about the rendering delay caused by 600-1000 bytes only to load a 71KB (or 24KB gzipped) file in its place.

Other things I wanted to do included:

Put the PHP in a class to reduce the risk of clashing function/class names
Put the JavaScript in its own namespace
Keep the output code as small as possible

To support conditional comments for IE required adding each stylesheet within a separate <script> tag, using this method the output HTML takes the following form:

<script>
  // add global print.css
</script>
<!--[if IE 6]>
  <script type='text/javascript'>
    // add ie6 specific print.css
  </script>
<![endif]-->

This violates my aim to keep output as small as possible but footprint has to take second place to bug-free. I could have translated the code to use JavaScript conditional comments by translating the IE version to the JavaScript engine it uses but this could lead to future-proofing problems.

To maintain the order of stylesheets, I added each event to an array of functions and then used a single event to loop through the array of functions. If jQuery is used, I add multiple events because jQuery runs events on a first in first out basis.

Putting the PHP in a class and the JavaScript in its own namespace is fairly self-explanatory. Google is your friend if you wish to read up further on this.

Minimising the footprint was also a simple step. I wrote the JavaScript out in full with friendly variable names. Once I was happy with the code, I ran the code through the YUI JavaScript compressor, commented out the original JavaScript in the plugin file and output the compressed version in its place.

The JavaScript is output inline (within the HTML) to avoid additional HTTP requests. I was in two minds about this because browser caching is lost in the process. So it may change in a later version.

I’ve worked out another way to keep the footprint small. Rather than creating a function to pass the stylesheet’s URL and ID to brt_print.add(url, id), I wrote out the full function for each style sheet. I’ll fix that in the next release.

You can download the Delay Print CSS Plugin from the WordPress plugin repository.

An Answer to the Twitter Question

2010-08-19T07:20:44Z

One of the questions we’re often asked by clients when doing an initial consultation is “what about twitter?” It goes along with “should we have a Facebook page?” and “how do I get MySpace friends?”

Social networking, of the web-based variety, is something that people will be writing books about for years to come. It’s as hot now as it was 3 years ago and 5 years ago. That is to say, it continues to be hot because there continue to be new social networks that become popular and die out and then become popular and then die out again.

The trick for a business is to be able to appropriately surf that wave of social network highs and lows and never put all eggs into a single basket.

There are big businesses that do great work on Twitter. Airlines like Virgin Blue and Southwest have a team dedicated to monitoring social websites to see what people are saying about them. So do telecommunications companies like Optus.

For customers the advantage is that they can have a direct line to vent their frustrations. Shout out on Twitter about how outrageously incorrect your bill seems to be and you can not only have friends console you or also share their experiences, but there’s a fairly good chance someone from the company will be in touch to help you through your issue.

For companies the advantage is largely and expectedly the reverse. It’s easy to monitor exactly what people are saying about your company, your industry or your competitors. It’s also really easy to reach out to a customer and make them feel a little bit special by personally helping them with their problem.

Twitter, however, is not the place to try to influence customers or get them to change their habits. It is not as effective as an advertising campaign or a media release but it is a good place to see what people are saying about your latest ad campaign etc. Twitter for companies is more about measurement and accessibility than direct marketing and that’s important to remember.

Nobody likes to be spammed at. Nobody needs to get a direct message because they followed your company. People don’t hang around with Twitter because they enjoy being bombarded with irrelevant messages. They use the service because it helps them feel connected and part of a community. That’s important to remember because, while it might be hard to build up a good reputation on Twitter, it will only take minutes to be burnt and razed to the ground with no one around to sweep up your ashes.

A recent radio piece about Comic-Con featured a genre film promoter talking about changing people’s opinions and excitement about a product. He told a story about going to Comic-Con to convince an audience of die-hard Batman fans that the, then, new movie (1989) would not be the camp 1960s Batman despite the involvement of the director of a Pee-Wee Herman film and the guy from Mr Mom. Within minutes he managed to turn the audience from a booing mass to applauding fans excited with anticipation.

An opinion turn-around like that could never be achieved on Twitter. The value Twitter has, though, is that if something like that were to happen today, the people in that room would tweet about it and excitement about the product would spread exponentially and almost instantly

Twitter is the buzz. If our clients are on Twitter they are in a much better position to have their finger on the pulse and give them more information about the zeitgeist. They might not have a million followers but at the very least they’ll be able to gauge influence.

Twitter gives companies the ability to do something they’ve never done before. They have a direct link into their customers’ thoughts and conversations. That’s a very powerful tool and it needs to be approached with patience and a lot of thought.

Use Experience to build Experience

2010-08-12T05:28:25Z

Working on redesigning the user interface for an online store, I found myself digging deep into my own experiences to be able to anticipate the needs of the customer.

For 8 years, from the ages of 14 to 22, I worked in retail. My parents ran a couple of manchester stores and I worked there after school and on weekends. In two of those years I also worked in a video library*.

The thing about designing for the web is, we often don’t take into account, not only what our audience’s real-world experience is, but also our own.

When laying out a ‘brick & mortar’ retail store, there is a logical flow to entice customers further in. A clothing retailer, for example, has the changing rooms at the back of the store so you have to walk past all the racks first. Trestle tables with specials are outside the store to entice the customer to come in.

‘Brick & mortar’ stores have their differences to online stores but customers expect a similar experience. The shopping brain has certain established neural pathways. It’s easier to capitalise on those than to try to forge new pathways.

When I explained the concept of the customer’s journey through the store to my client I could speak with experienced knowledge of how a customer expects to be treated.

I was able to draw on my knowledge and experience in working with shoppers to design and explain how an online shop needs to feel. I used parts of the screen real-estate as if they were parts of the shop floor:

The shopping cart is like the cashier’s counter. It needs to be visible, obvious but unobtrusive to the flow of the store. That’s why it’s in the top right, squarish and about one third the width of the content area.
The front page is like the window-dressing. It needs to show popular, attractive, sought-after, and new items in an enticing way. It’s a lot easier in a web-store because you can actually give areas of the screen titles like “Popular Items”, “Highest Rated” and “Recently Added”. Cookies and user history also give the opportunity to tailor the store to the visitor.
There’s a section of the front page that has a different coloured header and displays some heavily discounted items like the trestle tables on the footpath in front of the shop.

There are plenty of times when I’ve worked on websites in areas of business where I didn’t have 8 years’ experience. In those situations I’ve sat down with clients and asked them to show me every aspect of their business I can think of. I go through business processes with them for hours so that I can accurately recreate real world experiences.

We have a tendency, because we work with computers, to isolate ourselves from the real world. We forget, sometimes, that people in the real world often just want to replicate their own experience with some added convenience. It’s up to us to be able to capture the essence of the real world to make our audiences feel more comfortable online. Sometimes that means digging into our own past and sometimes it means distilling someone else’s knowledge but the aim should always remain: Make the user’s transition from real world to online as seamless as possible.

*The older people in the audience may need to explain that concept to the young ‘uns.

Delay loading of print CSS

2010-08-27T05:07:48Z

Recently I stumbled across an article on zOompf detailing browser performance with the CSS print media type. In most recent browsers, Safari being the exception, the print stylesheet held up rendering of the page.

The zOomph article suggests a solution, to load print stylesheets using JavaScript once the page has rendered (ie, on the window.onload event), with a backup for the JavaScript impaired. You can see their code in the original article.

Automating the task for WordPress

Most sites I develop are in WordPress so I decided to automate the process. This relies on using wp_enqueue_style to register the stylesheets:

function enqueue_css(){
  if (!is_admin()){
    wp_enqueue_style (
      'bigred-print', /* handle */
      '/path-to/print.css', /* source */
      null, /* no requirements */
      '1.0', /* version */
      'print' /* media type */
    );
  }
}
add_action('wp_print_styles', 'enqueue_css');

The above code will output the following HTML in the header:

<link rel='stylesheet' id='bigred-print-css'  href='/path-to/print.css?ver=1.0' type='text/css' media='print' />

The first step is to wrap the above html in noscript tags, the WordPress filter style_loader_tag is ideal for this.

function js_printcss($tag, $handle) {
  global $wp_styles;
  if ($wp_styles->registered[$handle]->args == 'print') {
    $tag = "<noscript>" . $tag . "</noscript>";
  }
  return $tag;
}
add_filter('style_loader_tag', 'js_printcss', 5, 2);

The filter runs for all stylesheets, regardless of media type, so the function checks for print stylesheets and wraps them in the noscript tag, other media types are left alone.

The first two arguments are the filter and function names respectively, the third argument specifies the timing (5 is the default) and the final argument tells WordPress how many arguments to pass to the filter – two – in this case $tag and $handle.

With the new filter, WordPress now outputs following HTML in the header:

<noscript>
<link rel='stylesheet' id='bigred-print-css'  href='/path-to/print.css?ver=1' type='text/css' media='print' />
</noscript>

The next step is to add the JavaScript to load the stylesheets, we can do this by changing our original function, js_printcss, and making use of a global variable:

$printCSS = '';

function js_printcss($tag, $handle){
  global $wp_styles, $printCSS;
  if ($wp_styles->registered[$handle]->args == 'print') {

    $tag = "<noscript>" . $tag . "</noscript>";

    preg_match("/<\s*link\s+[^>]*href\s*=\s*[\"']?([^\"' >]+)[\"' >]/", $tag, $hrefArray);
    $href = $hrefArray[1];

    $printCSS .= "var cssNode = document.createElement('link');";
    $printCSS .= "cssNode.type = 'text/css';";
    $printCSS .= "cssNode.rel = 'stylesheet';";
    $printCSS .= "cssNode.href = '" . esc_js($href) . "';";
    $printCSS .= "cssNode.media = 'print';";
    $printCSS .= "document.getElementsByTagName(\"head\")[0].appendChild(cssNode);";
  }
  return $tag;
}

The code creates the PHP variable $printCSS globally, which is then called into the function using the global command.

After wrapping the tag in the noscript tags, the new function uses a regular expression to extract the URL of the stylesheet from the link tag and placing it the variable $href.

Having extracted the stylesheet’s URL, the function then appends the required JavaScript to the PHP global variable $printCSS.

The final step is to add the JavaScript to the footer of the HTML using the wp_footer action in WordPress. The PHP to do this is:

function printCSS_scriptTags(){
  global $printCSS;
  if ($printCSS != '') {
    echo "<script type='text/javascript'>\n";
    echo "window.onload = function(){\n";
    echo $printCSS;
    echo "}\n</script>";
  }
}

add_action('wp_footer', 'printCSS_scriptTags');

The above code uses window.onload as dictated in the original article. A better method would be to use an event listener to do the work, for those using jQuery we would change the function to:

function printCSS_scriptTags(){
  global $printCSS;
  if ($printCSS != '') {
    echo "<script type='text/javascript'>\n";
    echo "jQuery(window).ready(function(){\n";
    echo $printCSS;
    echo "});\n</script>";
 }

}
add_action('wp_footer', 'printCSS_scriptTags');

The above solution had been tested for very limited circumstances only and found to have worked. Were I to use the function in a production environment I would undertake further testing.

Another question to ask is whether all this is actually worth the effort – even when reduced through automation. On Big Red Tin, the print.css is 595 bytes, the delay in rendering is negligible.

Update Aug 23, 2010: Fixed a type in the code block redefining js_printcss.

Update Aug 27, 2010: I’ve decided to release this as a plugin, get the skinny and the plugin from the followup article.

Thesis V WordPress, Pearson V Mullenweg

2010-07-19T01:23:28Z

Reading my WordPress feeds this-morning, it appears a war of words broke out overnight between Matt Mullenweg (the lead developer of WordPress) and Chris Pearson, the developer of the Thesis theme.

In brief, Mullenweg believes that, because WordPress is released under the GPLv2 license, all themes and plugins developed for WordPress must also be released under the same license. Pearson disagrees.

This situation has never affected us directly at Soupgiant so we haven’t needed to, and this is important, ask our lawyer if my interpretation is correct. This is a layman’s opinion and should be treated as such.

The battle comes down to these clauses in the GPLv2 license:

You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.

–source GPLv2 license

Due to the second clause quoted above, I believe that Mullenweg is wrong. WordPress themes can operate on other blogging platforms with minimal changes. This has been done before with the Sandbox theme for WordPress which was successfully ported to Movable Type.

WordPress themes output HTML with a series of calls to the blogging platform. To output the post’s title and contents in our base theme, we use the code:

<h2 class="entry-title"><?php the_title() ?></h2>
<div class="entry-content">
    <?php the_content("Continue reading " . the_title('', '', false)); ?>
</div>

To output the same HTML in a Movable Type theme, we would output:

<h2 class="entry-title"><$mt:EntryTitle$></h2>
<div class="entry-content">
    <$mt:EntryBody$> <$mt:EntryMore$>
</div>

In terms of a page’s output, the above code is a minor part of the page. The theme’s template is mostly made up of HTML and CSS, HTML and CSS operate in the browser and not in the blogging platform. It’s for that reason that I believe that Pearson is correct in this case.

I acknowledge that WordPress hooks may complicate the matter but these hooks output such a minor part of a theme’s HTML, that I consider the theme uses the platform but isn’t derived from the platform. I’ve left plugins out of this discussion as these are a more complicated matter: they can output HTML or they can build on the platform.

The above said, were I to release a WordPress theme I would probably release it under the GPL as a hat tip and thank you to the community that has assisted me so much. However, if the theme was as complicated as the Thesis theme, I may feel differently about the matter when it’s crunch time.

Again, this is a layman’s opinion and should be treated as such. If you have a layman’s opinion too, we’d love to hear it in the comments.

Getting the bloginfo correctly

2010-07-13T07:17:16Z

This site runs on an WordPress MS install, along with a number of other small sites. You can see the full list of sites on the directory page.

As with most WordPress sites we use plugins to enhance WordPress, including Donncha O Caoimh‘s excellent WordPress MU Domain Mapping plugin. As the name implies, the domain mapping plugin allows us to use top level domains for each site rather than being stuck with sub-domains. In the case of this blog, without the plugin it would reside at bigredtin.pressgiant.net.

Taking care with plugins

Many plugins are tested for the single site version of WordPress only. I don’t have a problem with this as most plugins are released under the GPL and free in terms of both speech and beer. If I’m not paying for software, it’s up to me to test it in the fringe environment of WordPress MS.

Now that WordPress is WordPress MS is WordPress, more developers may test in both environments but they certainly can’t be expected to test with all manner of combinations of plugins.

The standout problem

One of the standout problems when using plugins with WordPress MS is when they define a constant for the plugin’s url as the script starts executing, the PHP code may look similar to:

<?php

  define('PLUGIN_DIR', get_bloginfo('url') . "/wp-content/plugins/peters-plugin");

  function plugin_js_css(){
    wp_enqueue_script('plugin-js', PLUGIN_DIR . '/script.js');
    wp_enqueue_style('plugin-css', PLUGIN_DIR . '/style.css');
  }

  add_action('init', 'plugin_js_css');

?>

The above stands equally for themes mapping the stylesheet directory at the start of execution:

<?php

  define('THEME_DIR', get_bloginfo('stylesheet_directory') );

  function theme_js_css(){
    wp_enqueue_script('theme-js', THEME_DIR . '/script.js');
    wp_enqueue_style('theme-css', THEME_DIR . '/style.css');
  }

  add_action('init', 'theme_js_css');

?>

The get_bloginfo and bloginfo functions return information about your blog and your theme settings including the site’s home page, the theme’s directory (as in the second code sample above) or the stylesheet url. bloginfo outputs the requested information to your HTML, get_bloginfo returns it for use in your PHP.

Outside of code samples, bloginfo and get_bloginfo are interchangeable throughout this article.

The problems occur when a subsequently loaded plugin needs to change something retrieved from bloginfo. In this site’s case, Domain Mapping changes all URLs obtained through bloginfo, but it could be a plugin that simply changes the stylesheet url to a subdomain to speed up page load.

In a recent case, a plugin – let’s call it Disqus – was defining a constant in this manner. As result an XSS error was occurring when attempting to use Facebook Connect. Replacing the constant with a bloginfo call fixed the problem.

The improved code for the first sample above is:

<?php

  function plugin_js_css(){
    wp_enqueue_script('plugin-js', get_bloginfo('url') . '/wp-content/plugins/peters-plugin/script.js');
    wp_enqueue_style('plugin-css', Pget_bloginfo('url') . '/wp-content/plugins/peters-plugin/style.css');
  }

  add_action('init', 'plugin_js_css');

?>

bloginfo doesn’t hit the database everytime

I presume the developers set their own constants because they’d like to avoid hitting the database repeatedly to receive the same information.

Having run some tests on my local install of WordPress, I can assure you this is not the case. Running bloginfo('stylesheet_directory') triggers a db call on the first occurrence, the information is then cached for subsequent calls.

I realise I sound incredibly fussy and that I’m suggesting we protect against edge cases on our edge cases. You’re right, and it’s not the first time, but as developers it’s the edge cases that we’re employed to avoid.

‘Skip to Content’ Links

2010-07-08T02:03:45Z

Big Red Tin co-author, Josh, and I were discussing the positioning of Skip to Content links on a website. In the past I’ve placed these in the first menu on the page, usually positioned under the header.

According to the fangs plugin, the JAWS screen reader reads the opening of Soupgiant.com as:

Page has seven headings and forty-three links Soupgiant vertical bar Web Production dash Internet Explorer Heading level one Link Graphic Soupgiant vertical bar Web Production Heading level five Heat and Serve Combine seventeen years of web production experience, twenty years of television and radio experience, put it all in a very large pot on a gentle heat. Stir regularly and serve. Soupgiant goes well with croutons and a touch of parsley.List of five items bullet This page link Skip to Content bullet Link Home bullet Link About bullet Link Contact bullet Link Folio

- my emphasis

That’s a lot of content to get through, on every page of the site, before the Skip to Content link. It would be much better if the skip to content link were earlier on the site.

As the HTML title of the page is read out by JAWS, the best position would be before the in-page title. The opening content would then read as:

Page has seven headings and forty-three links Soupgiant vertical bar Web Production dash Internet Explorer This page link Skip to Content Heading level one Link Graphic Soupgiant vertical bar Web Production

- again, the emphasis is mine

That gives the JAWS user the title of the page and immediately allows them to skip to the page’s content. I don’t read the header of on every page of a site, nor should I expect screen reader users to.

I realise screen readers most likely have a feature to skip around the page relatively easily, regardless of how the page is set up but our aim should not be relative ease, our aim should be absolute ease.

As a result, we’ve decided to move the skip to content links on future sites to earlier in the page.

Sadly, this revelation came up as a result of what I consider to be a limitation of the WordPress 3.0+ function wp_nav_menu, the inability to add items at the start of the menu. I should have considered the accessibility implications much earlier. It serves as a reminder, to all web developers, that we should constantly review our practices and past decisions.

If you’ve recently changed something you’ve always done, we’d love to hear about it in the comments.

Designing a User Interface with Caveat Emptor

2010-07-06T02:04:39Z

Recently an Amazon Kindle came into my life.

To test it out I obtained a free copy of The Hound of the Baskervilles from the online store and started reading. I was an instant convert. I loved the experience and I loved the concept.

Until, that is , I found my way into Chapter 2 and there were vital passages missing from the text. It soiled my experience with the Kindle.

There are a number of lessons here. Obviously, there’s the whole caveat emptor, you get what you pay for scenario. A little bit of research would have shown me this review that tells me up-front what to expect:

This edition is missing certain passages… Whenever there is a point in the story where a character reads out of a newspaper or other document, that passage is missing from this Kindle edition. Spend a dollar and get a different version.

But the other lesson is more a question for thought. Why would Amazon keep the book in their store if it’s not what people are expecting? There is no obvious avenue to inform Amazon of the problem with the book and no way to ask them to remove the book so other people don’t fall into the same trap.

When building the user interface of an online store, there are many things to take into account. Feedback is vital for any business. Amazon and Zappos have built empires with great customer service but customer service is about a lot more than just an attentive complaints department or a good returns policy.

Great customer service starts with the user interface. It’s the experience a customer has when they browse or purchase a product. A bad UI is like having a rude salesperson on the shop floor. A customer should be able to trust that the seller is looking out for them. There should be a way to bring issues of faulty products to the attention of the sellers.

Sometimes there are use-cases that just aren’t foreseen. But when they reveal themselves it’s important for an online store to be able to adapt.

So there are things that Amazon could have implemented to make my experience better. A roll-over information box that showed me the start of the most helpful review, for example, could have given me the information I needed to make my decision to purchase or not.

These are the small design things; the small usability things that we try to develop every day.

Recently I designed some wireframes for an online store. It’s hard. I had to balance the client’s budget with the limited information I had, the inclusion and prioritisation of use-cases, and a degree of future-proofing to allow for unforeseen developments.

There is a lot of information to include in an online store. There are lots of buttons and lots of icons to demand a customer’s attention. It’s important to remember, however, that customers want something very simple: They want to buy stuff and for it to behave as expected. Give them that and the rest will follow.