Reason 1 – Planning for Usability Testing Helps Keep Your Project On Track

Even if it only gets one row in the GANTT chart, having usability testing as a step in your overall project plan will give you a tangible goal to work towards that will help you move forward on your overall project.

In order to run any form of usability test, you will need to come up with mockups or prototypes of some form – be it crude Photoshop mockups or paper prototypes, or functional wireframes with a bare bones design – you need to have something to run the test on.

In this respect, having usability testing as part of your project plan helps break your big project down into smaller, more manageable chunks, which in turn helps you keep on top of your progress.

Reason 2 – Usability Testing Will Teach You Things You Didn’t Know Before

If you get a chance to do usability testing with a good variety of your targeted end-users, you may be surprised at what you find. Quite often, new insights come from watching someone use your website. What was natural and intuitive to you and your team suddenly doesn’t seem so logical when 4 out 5 of your testers can’t complete the task you originally set out for them to do.

Usability testing also gives your site a fresh set of eyes to help uncover new ideas and even possibly new features to add to your site. Sometimes it’s just a passing comment from one of your testers that might spawn the idea for a new core feature that you would never have thought of on your own.

You and your team probably also have some hunches on what will work with your target audience – maybe it’s something like a colour scheme to something more complex like the steps required to recover your username and password. Usability testing gives you that feedback to confirm your hunches.

Reason 3 – Usability Testing Gives You Data to Back Your Decisions

Unless you’re working on a personal project without any real accountability to another stakeholder or client, odds are the website or application you are working on will have to go through some levels of approval and sign off. In this process, you will be questioned about a design decision or asked to squeeze something else in. For example:

• Why is the font so small?
• Is there a reason why we can’t use the full width of the page?
• We have another 12 links that need to get into the sub navigation. Where can we put them in?
• That link down there needs to go into the top row of links on the homepage. Why isn’t it there?
• The photo on the homepage needs to be bigger. Like, way bigger. Like, ten times bigger than it is right now.

Usability testing has the potential to give you instant data to help back your design decisions. Armed with information gleaned from watching real people actually use your site (or working prototype), you will have greater credibility and more to stand on than just your opinion. Usability testing will give you real metrics you can use to support your position.

Reason 4 – Usability Testing Gives You Documentation that You Can Re-use for Future Projects

If you do a good job of documenting the findings from your usability testing, that whole process itself will serve as a valuable start the next go-around. Depending on the type of project and work being done, you may even be able to use the findings from previous tests to help get you and your team off on the right foot moving forward on your next project.

Similar to how usability testing gives you data to help defend your decisions to clients and stakeholders, that same data arms you with some information that you can use yourself. This is particularly useful when you’re confronted with making a seemingly arbitrary decision during your design phase.

Having a completely blank slate with endless possibilities and no constraints can actually be a very challenging and even frustrating space to design in – this is when arbitrary decisions are at their worst. It’s much easier to make a design decision when you have some form of constraint or guideline, really anything that can set you in one direction. And this is exactly what previous usability testing results can sometimes provide. With some baseline information on what worked and what didn’t work in the last design, you now have a starting point for this next design.

Reason 5 – Usability Testing Gives You an Opportunity to Field Test New Ideas

Usability testing doesn’t have to always be about testing something you’ve created. In fact, quite often, you could use the same exercise to test something that is, at this stage, nothing more than an idea.

In sales they would call this something like the foot in the door technique where you get someone to agree to a large request by first having them agree to a smaller one. What you’d want to do here is a little less sinister and more along the lines of trying to make the most of this valuable time you have with and end-user of your site.

Run your usability test and get your data, but then also try running some of your as-of-yet-unproven ideas and see what sort of feedback you get.

Face it, there’s definitely some administrative overhead that comes with running usability tests. If nothing else, there’s the simple task of scheduling and taking the time from people’s days to get them into the sessions. You might as well make the best use of this time and use it as a real opportunity to uncover some of the most valuable information you’ll get.

But Wait, There’s More!

This is all fine and dandy, but let’s bring this back full circle – what if you’re under a tight timeline, or don’t have the budget to get a robust usability test into your project cycle? All this is a lot of fluff if you can’t actually run the tests.

Well, usability testing doesn’t have to be that hard, and it can be done at any time in your development lifecycle – even after you’ve launched. You probably already engage in some form of usability testing yourself when you’re building your websites or applications, probably without even realizing it. We’ll go into these and other topics in the coming weeks.

In the meantime, let me know what you think! Why else would you do usability testing? Or why shouldn’t you do usability testing? If you’ve wanted to do usability testing before, why haven’t you? What’s holding you back?

Tooltips are nice small additions that can improve the user experience. They are so common that Dojo and other javascript frameworks provide precanned ways of creating them. In dojo, they provide dijits (their widgets) that can do some amazing things on the user interaction side. That being said, when you want to customize them in any way, you can run into many walls.

Dojo tooltip

Problem & Goal of this Article

The main goal of this article is to show you how to stylize the tooltips so that you can create your own type of tooltip. This article will go through the css required and how to structure your code so that you can create more than one tooltip.

To extend the style of dojo’s dijit, it’s best to copy one of the existing themes and create your own custom theme. In this tutorial, I’ve copied the “tundra” theme so all the following css code will use the “tundra” selector. You could replace the tundra selectors with your own custom name, but it may be more work than it’s worth.

Prerequisites – tools you’ll need setup:

• Firefox
  You should have this
• IE 6 or IETester
  You’ll want to make it IE6 compliant right? Or maybe not…
• Firebug
  Every developer and especially UI developer should have this.
• Dojo framework setup
  Follow their documentation on setting up the includes

The Steps

1. Setup a new theme
-Open up the dojo dijit theme folder
-dojo-release-1.1.1dijitthemes
2. Create a copy of the “tundra” folder.
3. Rename it to the name of your theme. (e.g. – “tundraextended”)
4. Include the dojo style and your extended theme in your header code:

<style type=”text/css”>
@import “pathtodojo/dojo-release-1.1.1/dijit/themes/tundraextended/tundra.css”;
@import “pathtodojo/dojo-release-1.1.1/dojo/resources/dojo.css”
</style>

5. Include the tool tip dijit:

<script type=”text/javascript”>
dojo.require(”dojo.parser”);
dojo.require(”dijit.Tooltip”);
</script>

6. Add the tool tip code

<body class=”tundra”> <!– you need to set the body to load the dijit styles –>

<a id=”theId” href=”#”>Hover over this</a>

<div dojoType=”dijit.Tooltip” style=”display:none” position=”left” connectId=”theId”>
<div class=”custom_tooltip”>tool tip content</div>
</div>

Note the attribute “position=left”. This should remain the same for all tooltips that are defined by the inner class “custom_tooltip”. I don’t really use the position attribute and rely on css position.

At this point you should have a simple tool tip hover when the mouse goes over the link. If you don’t, then open up firebug and see if you have any errors. If you do, then you most likely didn’t setup dojo properly.

If all is good now, then you have a nice basic tooltip. Now, the hard part is how to extend the look:
7. Create a new css file – dojoextended.css
This style sheet should be included last. As its name suggests, it extends (overrides and resets) the dojo stylesheet.

<style type=”text/css”>
@import “pathtodojo/dojo-release-1.1.1/dijit/themes/tundraextended/tundra.css”;
@import “pathtodojo/dojo-release-1.1.1/dojo/resources/dojo.css”
@import “pathtocss/dojoextended.css”
</style>

8. Add the following css to the extended css file

/*Reset the generic tooltip container */
.tundra .dijitTooltipContainer
{
background:none;
padding:0;
margin:0;
border:none;
height:auto;
width:auto;
}

/*defines the div inside the tooltip – your custom tooltip*/
.custom_tooltip
{
/*this defines your tooltip*/
position:relative;
left:5px; /*use left and top to position it */
top:15px;
width:125px;
height:100px;
background-image:url(”yourimage.png”);
}

/*if your tooltip uses transparency, define a ie6 specific one below */
.dj_ie6 .tundra .custom_tooltip
{
background-image:url(”yourimage_ie6.png”); /*an 8-bit png*/
}

/*hide the connector – an arrow that connects the tooltip to the hovered item */

.tundra .dijitTooltipAbove .dijitTooltipConnector { background:none; }
.tundra .dijitTooltipLeft .dijitTooltipConnector { background:none; }
.tundra .dijitTooltipBelow .dijitTooltipConnector { background:none; }
.tundra .dijitTooltipRight .dijitTooltipConnector { background:none; }

You’re done!

You can now create as many styles for your tooltips as you need by defining a specific div and a new style (e.g. – custom_tooltip2). You will likely have to do a lot of tweaking on the positioning image, but it’s pretty straightforward when you look at it. The longest part is determining which css selectors you need to use, if you look at the tundra.css class you’ll notice there are more selectors I didn’t look at.

Pros

-Quick to code.
-Easy to understand, there’s only one div to deal with.
-IE6 compliant. It’s always a bonus .
-Extendability. You can now create as many tooltips as you want for one project. With the standard tooltip, you would be stuck with one tooltip for an entire project.

Cons

-Inefficient: Resetting styles is cumbersome and requires more data to be loaded.
-Upgrading dojo could break the custom tooltips if they change the way the tooltip are rendered.
-Tooltipconnector: I didn’t use the tooltipconnector which allows you to position the tooltip in various positions easily.

Conclusion
That wraps up the first tutorial on dojo. I hope you found it useful, and I appreciate all feedback. If you have a better way, I would like to know about it. My next article will look at how to combine dojo’s ajax with the zend framework.