No Mod Required

Remember the “Small Site Enhancement” I introduced last month? For a refresher I linked all of the images in my gallery flow. Instead of simply being static, they now link through to the next image in the gallery flow. I did this hoping to increase the number of page views per user by making it easier for them to click around and do those things that users love to do After nearly a month of the change being in place, I have some preliminary results:

For the period from 2008/05/03 to 2008/06/01 I averaged 4.79 pages per visit

For the period from 2008/04/03 to 2008/05/02 I averaged 4.38 pages per visit

Those numbers represent an increase of 9.37% or .41 pages per visit. I’m not going to make Google tremble, but I’ll take it.

I made the image in my gallery pages “hot” today. Each gallery image now points to the next image in the gallery flow. It’ll be interesting to see if that increases the average number of page views per user. I’m thinking it will as a lot of people use that technique so I’ll hopefully be leveraging that learned behavior. Logically it just makes sense as those back, home and next buttons are way too small. I’ll report the results in a couple of weeks…

Check it out here.

I’m actually in the process of recoding all the gallery pages (with the exception of the alphabet I posted yesterday, which was built that way from the beginning) to have an actual anchor tag wrapped around the image. For now I’m doing it with a little bit of JavaScript:

var imgs = $("artimg").getElementsByTagName("img");
for (var i=0; i< imgs.length; i++) {
    imgs[0].onclick= function() {
        document.location.href=$("next").href;
    }
}

where “next” is the existing ID applied to the next link in gallery pages. I love being able to use such simple JavaScript to enhance the user experience in such a (potentially) large way.

Don’t Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition

I’d never read this web usability classic before and my to-the-point review is this:

There’s a reason this book is a classic in the field. It’s smart, well written, funny and damned easy to read through*.

Quick hit reviews aside, I was surprised to learn that this book was at least partially written in a Bruegger’s that I frequent. It’s true. Steve Krug lives in the next town over and tapped out at least some of the book in a Bruegger’s just a couple of miles from here. I feel just that much smarter by association

*It’s a perfect book for a plane trip, so if you work on the web and haven’t read this book pick it up before the next coast-to-coast or transatlantic (or pacific) flight. You’ll be a better designer/developer/manager when you land on the other side.

Designing the Obvious: A Common Sense Approach to Web Application Design Another excellent book. The ideas outlined here would be of benefit to any web application. Small or large, the idea of paring down features to only those “necessary for the users to complete the activity the site is meant to support” is a noble one. I’ve, more often than I’m comfortable admitting, worked on projects where feature bloat ruled the day and I can tell you from bitter experience, giving in to “nice to have” features can be the absolute death of a project. The biggest disaster I’ve ever worked on was mostly sunk by feature bloat and lack of focus*.

There’s plenty to take away from this well written examination of what’s right and wrong with modern web application design. I read this on vacation and while I wouldn’t have traded the hammock I was on or the excellent wine I was drinking for anything, some small part of me thought “wow, I’d love to be able to put some of this stuff to work immediately.”

One thing I don’t fully agree with is Hoekman’s admonition, later on in the book, to throw away specifications and requirement documents. While that might work for the less complication applications he outlines in his book (excellent applications all), there’s no way to do, for example, a detailed financial services application without relying on solid documentation. When there are complicated business rules in place throwing a developer and a designer in a room with a white board and having them “work it out” just isn’t going to cut it.

Still, with a smaller scale, less structured application, the techniques and approaches in Designing the Obvious will be of benefit to anyone working in field of web application design and development. This is a recommended read.

*there was also a painful stab in the chest by a web application framework from hell to help that project into its grave.

Remember when I redesigned my home page? No? I made some changes based on the guidelines provided by usability.gov. Basically I cut down the amount of prose text and clarified the site choices available.

Well, not quite a month has passed, but I wanted to share the preliminary results with everyone anyway. By the metrics that I was targeting on that page (bounce rate and % of exit) the redesign was a resounding success. Here are the numbers:

So people are spending less time trying to figure out what to do, are less likely to immediately leave (bounce) and are less likely overall to make my home page the last page they visit on the site. I’ll take improvements like that any time. Big ups to the Research-Based Web Design & Usability Guidelines

Once I get my laptop back from HP, I’ll be looking to see if I can experiment with a few more nuggets from that excellent resource. I’m definitely eying adjustments to some of the navigation pages around here. I’ll be sure to publish the results as I get them.

Support: This technique is supported by IE 5.+, Firefox (and the rest of the Mozilla family) and Safari 3.0*. It is not supported by Opera** (any version), Netscape 6.2 and earlier or Camino.

Warning: I haven’t thought this all the way through, so if you see any problems with this technique other than the above support caveats, then please let me know I’m really just writing this up because I just thought of doing it, I tried it and it worked…

The issue and solution: Occasionally I need to use an image, with text, for the background of an input button. It’s rare, but occasionally it needs to happen. Thing about that is, I still want to have a regular value in there so that screen readers and people surfing without CSS at all can still figure out what the input says. I’ve usually encountered this issue on on fast-paced, get-em-out-the-door projects, so I’ve never had time to actually sit down and think about a solution. I’ve never actually come up with a solution that I liked for this. Negative text indent doesn’t work, so I’ve always done random hacks to get it to work correctly. Recently I achieved it by shrinking it way down and coloring it the same size as the background.

Painful.

Today, for whatever reason, I took it one step further and set font-size:0;, hit F12 and saw, *GASP*, it worked. Browsercam verifies that it works for the above named browsers.

Here’s a sample:

And here’s the code for the above #go button.

#go {
	background: url(images/go.jpg);
	height: 25px;
	width: 41px;
	font-size: 0px;
        border:0;
}

This is one of those things that seems so obvious in hindsight. I just never thought to do it before today. hrm.

*Safari 1.2 and 2.0 ignore both the font-size AND the background image.
**Opera displays something like 6pt type.

One of my favorite guidelines from the Research-Based Web Design & Usability Guidelines is the following:

10:1 Use Meaningful Link Labels

Guideline: Use link labels and concepts that are meaningful, understandable, and easily differentiated by users rather than designers.

Comments: To avoid user confusion, use link labels that clearly differentiate one link from another. Users should be able to look at each link and learn something about the link’s destination. Using terms like ’Click Here’ can be counterproductive.
Clear labeling is especially important as users navigate down through the available links. The more decisions that users are required to make concerning links, the more opportunities they have to make a wrong decision.

My emphasis. In terms of web design and development pet peeves, I hate “click here” even more than I hate opening a new window for off-site links* to “keep people on your site,” so it’s always nice to have some place with gravity to point to when telling people “click here? that’s a bad idea.”

*imagine how much I hate clicking here to to open a new window….

In case you all haven’t noticed, I’m constantly working on this site. Week to week I’m always trying different things to see what works and what doesn’t. It’s cool for me because I get the benefit of a better site (and who doesn’t want that?) and it’s cool for my company and clients since they get the benefit of he lessons learned from all that tinkering without having to pay for it (or even identify that said tinkering should be done in the first place.)

All of which allows me to smoothly announce- I unveiled a new version of my home page today

Why? Why not? It is my home page after all, so there’s a lot to be said for making it perform more efficiently.

That and I was reading the Research-Based Web Design & Usability Guidelines published by the US Government and was struck by the clarity of guidelines 5:3 through 5:5. They deal with home page design and are all 4s and 5s (out of 5) on their importance scale, so it seemed like I ought to sit up and take notice. I especially grabbed onto 5:5:

5:5 Limit Prose Text on the Homepage
Guideline: Limit the amount of prose text on the homepage.
Comments: The first action of most users is to scan the homepage for link titles and major headings. Requiring users to read large amounts of prose text can slow them considerably, or they may avoid reading it altogether.

My research showed that no one was clicking on the links buried in the prose blocks on my home page, so the above seemed like it was speaking right to my site. Based on that convergence I figured losing all that prose wasn’t going to hurt anything, so we’ll see how the simplified links work out.

Want to see it in all its simplified glory?

Make with the clicking.

The Design of Everyday Things I’m embarrassed it’s taken me this long to (a) start reading this book and (b) finish it. It’s been on my radar for several years and it was only earlier this year that I got off my butt to read it. Once I started it, it would continually get pushed to the back burner by work or other reading (fiction, mostly,) so it took something like four months to work through. In hindsight this is the sort of book I should have just locked myself in a room for a weekend to read maybe a decade ago. It’s really that good, especially since I’m supposed to help advocate for the user as part of my day-to-day existence. The book is basic, but still iinsightful and helps to clarifies many concepts that float around in the world of usable design but might not be fully understood, even by people bandying the concepts around. Want to know what the jackass down the hall is really taking about when he vaguely goes on about “affordances?” This book is for you

Highly recommended.

I was looking at the CSS 2.1 Candidate Recommendation today and notices that there’s a New ‘display’ value- ‘inline-block’. That caught my eye as I’m long actually familiar with the inline-block display value. I’ve used it a couple of times for IE-specific browser hacks and I’ve always thought it would be cool if it were picked up by Firefox. Hopefully now that it’s made its way into a candidate recommendation and, presumably a real specification, they’ll add support and then I’ll be happy- in a really nerdy way.

Oh… you want to know why?

Basically inline-block does what it sounds like it does. It’s an inline element (it’s displayed within a containing block and flows in the same line) that behaves like a block (which in practical terms means it can have explicit height, width, padding and margins, etc.) The one place I would use it all the time is in the all-too common “logo inline in a corporate footer” situation. Here are a couple of examples of ones I’ve implemented recently, so you know of what I speak.

From MSLifeLines – Offering multiple sclerosis (MS) education & support:

From EForAllExpo.com:

As you can imagine they’re both implemented with an image and a link. In the case of the EForAll site, something like this:

An <a href="http://www.idgworldexpo.com/"><img src="/themes/idg_assets/images/idg_world_expo.gif" alt="IDG World Expo"></a> Event

With inline-block, I could instead do something like this and I would have a nice computer (or human with a screen reader) sentence instead of some text with an image rammed in the middle obscuring the actual meaning:

An <a href="http://www.idgworldexpo.com/" id="idg-link" >IDG World Expo</a> Event

Here’s the CSS:


#idg-link {
background:url(idg_world_expo.gif) no-repeat;
display:inline-block;
width:150px;
height:60px;
text-indent:-9999px;
}

It’s a very typical image replacement, but with inline-block you can have an image replaced anchor behave just like an image. That’s useful to me. I approve.

Here’s a sample. IE6/7, Safari 1.2+ and Opera 9.+ should see this work (with some variation in Opera.) Firefox? Not so much.