Michael Richard Murphy

I very often neglect writing here in favor of devoting that time to paying work. But recently I found something that might be helpful to somebody else so I thought I’d take advantage of that.

Over the last few months, a handful of our clients have had customers report issues with their websites. Online searches at the time didn’t turn up anything that sounded like the problem I was trying to fix so I figured writing about its resolution now might help someone else in the same boat I was.

The most common bug reported was that customers ended up on the site homepage when they clicked links that should go somewhere (or do something) else. For the few that reported it, clicking a tab on a Moosejaw product page to view additional details sent them to the homepage instead. Or clicking the Sign-In link up at the top of the same page sent them to the sign-in page instead of revealing a small inline sign-in form.

The sign-in link bug was more of a minor inconvenience since users still ended up at a sign-in page. They just missed the benefit of being able to do it without leaving their current page. The product tab issue was more critical however since users affected by the bug weren’t able to view information that may or may not affect their decision to buy.

All of the users who reported problems were using Internet Explorer 7 on either Windows XP or Vista. While the majority of the browsing public meets that criteria, we were still getting very few reports of problems. Unfortunately no one in our office or the clients’ could reproduce the problem. It had to be some setup unique enough that not every one using Windows/IE was experiencing it (thank god) but common enough among the half dozen people who took the time to report it.

Luckily we had a customer willing to help us diagnose the problem. He easily reproduced the error for us during a Go-To Meeting and also patiently labored through test pages that we tweaked on the fly to try to solve the problem. To no avail.

Without getting too bogged down in detail, the product tab links look like this:

<a href="#" onclick="somefunction();">tab text</a>

Normal behavior is that javascript code in somefunction is executed when the onclick event fires and the browser is prevented from changing its location to the value of the href attribute by a return false; statement at the end of somefunction. In this case, the content of each tab is written when the page is rendered and somefunction sets the display attribute of the clicked tab to block and the display attributes of the other tabs to none. Simple.

Except that for some users, clicking the tab was taking them to the location specified in the href attribute, #, the root of the site. At first we thought there was a scripting error that was causing the function to fail before the return false; could be executed. But Internet Explorer wasn’t reporting any errors on the page. We tried moving the return false; statement inside the onclick to be on the safe side.

<a href="#" onclick="somefunction();return false;">tab text</a>

That didn’t work either. Although with a return false; statement in the function itself and no script errors being generated, I didn’t really expect it to make any difference.

We tried changing the href attribute to

<a href="javascript: void();" onclick="somefunction();">tab text</a>

Which is a common technique for using a elements to execute code rather than changing locations. But all that did was stop the browser from going to the homepage. Our tab content still wasn’t showing. somefunction was still not being executed.

Eventually fixing the bug ended up on the back burner because of the extremely low volume of people reporting it. My heart sank recently when another complaint surfaced. What were we going to tell this customer when we had exhausted possible solutions before and come up with nothing?

Luckily the most recent complainant was pretty comfortable technically and started investigating possible causes on his own. The best news came when he reported that restoring Internet Explorer to its default settings and disabling all his add-ons solved the problem and the onclick events started behaving as expected again. Then he re-enabled his add-ons until he isolated the cause as the McAfee anti-phishing filter installed by his McAfee anti-virus suite.

At the time of this writing, a Google search for ‘McAfee anti-phishing filter’ has only turned up complaints of it causing sites to load slowly. Nothing regarding its effect on Javascript code. I couldn’t find any evidence on McAfee’s website that this is a known issue. Supposedly, the customer reported it to McAfee so hopefully I’ll have additional details soon. Such as a possible work-around. Other than simply disabling the filter. Interestingly, Internet Explorer’s built-in anti-phishing filter does not exhibit the same behavior.

On a side note, this bug draws attention to an interesting usability question. The product tabs, whose href attribute is set to #, completely failed for those users affected by the bug. While the Sign-In link, whose href attribute was set to a sign-in page URL, was still usable even though the onclick event’s failure to fire prevented the inline sign-in form from appearing.

Should the tab links have real values in their href attributes? Since each tab content doesn’t have its own URL, where should the link point to? Is it necessary to create server-side programming that accepts URL querystring parameters and uses it to show the appropriate tab in the event the onclick event fails and the page is redirected? I know in at least one case, the failure of the product tabs code caused a customer to order from a competitor where he could view the information he needed to make his decision.

I’m pretty excited that this week I added some pretty cool drag and drop functionality to an application I’ve been working on. I talked about Yahoo!’s UI library here a while ago and finally put it to use.

I’ve been converting a PowerPoint presentation and exercises used by Human Resources to train new hires into a web application and drag and drop seemed like the perfect design for a term matching exercise.

The application isn’t available outside our corporate network but I hope (I use that term loosely given the frequency of my posts lately) to post some examples of what’s possible at some point.

I don’t want to downplay my Javascript skills but Yahoo! has made it pretty easy to implement these libraries. There’s a downloadable zip of dependent files for each library that developers link to in their applications. After that, the API provides you with the methods for adding whatever interaction you like. I was able to put together a passable application in an afternoon and now it just needs some polishing and finishing touches.

Check out Yahoo!’s UI Library and create!

While writing this recognition application for The Student Loan Corporation, overlapping roles has been a constant thorn in my side.

Application administrators and managers have access to certain functions, such as the ability to approve nominations of different levels, that general users do not.

Managers were relatively easy to handle. Creating an employee table that correlated managers and their direct reports allowed me to move nominations for specific employees to the appropriate manager’s queue.

Adminstrators are a whole different beast however. Not only do admins need to be able to function as normal users and administrators, they can also be people managers. As far as approvals were concerned, it was tricky (but doable) to figure out when a nomination needed to be approved by a specific employee acting as an administrator and when that specific employee needed to function as a people manager. Their role in these instances affected whether or not the nomination moved on and to where.

I solved this problem by creating different statuses to indicate where each nomination was in the approval process. Based on that information, I was able to determine where it should go next. That problem has been behind me for a little while now and it’s been smooth sailing until recently.

Roles are starting to get muddled again now that I’m working on the redemption portion of the application. The idea is that an employee’s accumulated recognition points can be redeemed for prizes. These prizes reside in an inventory maintained by the administrator.

This is where it gets slightly complicated. Because quite a few of the prizes are company branded and the program sponsor is Human Resources, these items are also used for other purposes such as charity give-aways or gifts for visiting executives. The admin now needs to be able to remove items from inventory from time to time for these purposes. Since the recognition program depends upon an accurate count of the items available for redemption, these withdrawals really need to take place through the system. The rub for me was how to determine when the administrator is removing these items as an adminstrator for the purposes just discussed and when they are legitimately redeeming credits accumulated as a normal user. In one instance, this action would mean reducing their accumulated credits for the redeemed prizes while in the other, it would not.

The idea that I’d need to figure this out eventually has been floating around in the back of my mind nagging me. I kept putting it off because I didn’t want to invest the brain power I thought would be necessary to figure it out. Little did I know how short an amount of time it would actually take.

SLC is rapidly outgrowing the available space in their current location so people are tight. I’ve had a tough time concentrating lately with anywhere from 6 to 8 people within three feet of me all having their own conversations and working. Maybe I just have superhuman hearing but there’s this constant chatter than once I pick up on, I can’t drown out, even with headphones.

Anyway, I’m getting down to the wire on this project and this functionality is one of the few remaining pieces so I decided it was time to just knock it out.

Yesterday at lunch I headed over to a trail nearby with the idea that I would get some fresh air (and quiet), focus exclusively on this problem, and come back to work with a solution. I’m proud to report that less than two minutes from the trailhead, I had everything worked out. About an hour after returning to work, the solution was implemented.

I guess the next time I’m strugging with something, instead of putting it off, I’ll just take a walk.

Ajax freaks working in the .Net environment should run right out and download Atlas, a new development framework from Microsoft. I said run.

Atlas integrates client-side script libraries with the server-based services of ASP.NET in order to create some really rich, interactive UIs. I watched a demo in which Microsoftie Scott Guthrie created a simple to-do list with tons of functionality in less than 20 minutes. The mini-application let users sort by task status, insert new tasks, and modify existing tasks all without page refreshes.

Scott also used some new, cool ASP.NET 2.0 methods that make handy things like pagination and alternating row colors super easy. There’s also another new method that makes it easy to display update statuses. As interfaces use page refreshes less and less to fetch data, letting the user know what’s going on becomes more important. Scott demonstrated this new method makes that as simple as drag and drop from the tool palette. Cool.

I was originally going to tell you how this book I’ve been reading, Ajax in Action by Dave Crane and Eric Pascarello with Darren James, has made me a Javascript phenom and how I’m putting together amazingly interactive interfaces using Ajax.

Instead, I’ll just tell you how Yahoo!’s Developer Network has pre-built interfaces and design patterns. All open source under BSD license. Want to implement drag n’ drop functionality? How about breadcrumbs or pagination? Auto-complete? Look no further, it’s all there. Quite a few of these have sparked my interest and will no doubt save time on future projects.

I’ll probably still finish the book however.

A while ago I read an article in Wired about a traffic engineer who removed all the traffic signs from a village in Holland. No street signs, no lane markers, no crosswalks, not even markers to indicate where the road stops and sidewalks begin. What residents found is that it reduced accidents because without any explicit direction, people were more focused on the task at hand, mainly driving. It interested me at the time but it also seemed pretty idealistic to trust people to pay attention. I filed this nugget away in my brain and promptly forgot about it until Jason Fried posted about it over at 37signals.com.

What does any of this have to do with web design? I think the point Jason made and I’d like to reiterate is that less is sometimes more. Have you heard about the million dollar homepage? It was thought up by an English lad as a way to pay for school. Basically he divided up his homepage into a million pixels and sells them to advertisers for a $1. While it’s got him rolling in cash, looking at it is enough to trigger a seizure. It’s a great gimmick for sure but there’s way too much going on.

Users can get overwhelmed by information so before you put pad to pen, think about the purpose of your design. What do you want from the user? Look at Blogger’s home page. I think they’ve narrowed it down to two main reasons why someone would visit their site: 1. An existing user wants to use their account. Good, the login area is featured prominently at the top of the page. 2. A potential new user wants information and/or to sign up. Again, the necessary information is displayed right smack in the middle of the page. That’s pretty much it. Simple and elegant. Even the dimmest bulb could figure out how to login or where to click to create a blog.

Cameron Moll had a great article on breaking a design down to only the necessary elements. Unfortunately, I couldn’t find it on his site when I went to write this but if you troll his archives you just might get lucky. Derek Powazek has also written a great piece at A List Apart about home page goals and how to design to meet them. The moral of the story is that complexity or features don’t necessarily make something better. There’s a reason KISS rocks.

Editor’s Note: You can also find this published on fad.tastic’s home page.

Just an FYI to interested parties. Joel Spolsky of Fog Creek Software is publishing a series of essays on design. He doesn’t mean design like deciding between two colors, we’re talking usability. I’ve always taken something away from his writings so be sure to check them out.

I’ve really been testing my usability knowledge with this recognition program I’m working on. In my old position, we had a core set of components or features for our sites that we didn’t really deviate from. Since they were already developed, the only questions was where on the page to put them.

Not so with this new application. While the recognition program itself has existed for a number of years, an application that brings it online and automates quite a few processes is new territory. We’ve had to put together new forms. Forms mean validation and usability issues.

I’ve been reaching into my bag of tricks for things I haven’t used in a quite a while and learning a bunch of new ones as well. I’ve also been writing Javascript like nobody’s business. I’ve found quite a few great scripts as well and when I can, I’ll give the authors credit and post links to them. In the meantime, here’s 10 Tips To A Better Form at ParticleTree.com. There’s some great advice and links to some very nice implementations of that advice. Enjoy.

Check out Panic.com’s Goods to see a cool drag & drop shopping cart. Pick a t-shirt and a size and drag the image right into a big wide footer area that acts as the cart. Even better, once added, see the image there. As near as I can tell, it’s accomplished all through Javascript and CSS. Smooth.

I can’t remember where but I read recently that it you wanted to see cutting edge work and hot design, that one need look no further than Panic.com. After talking a look at their site, that certainly seems pretty accurate. I’m definitely impressed.

I found interesting research involving eyetracking the other day at PoynterOnline. When I went to the home page, I wasn’t quite sure what a site about journalism had to do with eyetracking for websites…until I realized the research is specific to news sites. Nonetheless, where a user’s eyes focus on a web page is useful information to designers regardless of the type of site it is.

Worth checking out, there’s very detailed graphs, etc showing the movement of a user’s eyes as they scan a page from top to bottom, highlighting where they spend the most amounts of time. They also spend a good deal of time discussing navigation location, advertising, paragraph length, writing style, image size (dimension), headline format, type size, and more. An interesting read to say the least.

So we had our first usability test of the new recognition web app I’m writing and things went swimmingly.

Imagine that, usability testing…with real users. It was a pleasant change for me. We got tons of great feedback and fortunately it tells me that I’m really on the right track.

This is a high visibility project and it can’t be bad when the CEO drops in to see how things are progressing and the Director of HR comes down to participate in the tests. The project sponsor told me today people are pressuring her to get things wrapped up because they want me on their upcoming projects. Not bad for 6 weeks on the job.

Ok, time to stop tooting my own horn and write something useful to somebody.

I saw a discussion somewhere recently about the May 1^st reboot. If I’m correct, the idea is that every May 1^st, designers and developers will unveil redesigns of their sites. www.may1reboot.com will serve as a focal point for people to find those creatives participating in the program. I think there might be prizes (besides Internet fame) for best design but I’m not sure.

One of the reasons The reason I don’t have more information to offer about the program is the god awfulness of their web site. I don’t want to mercilessly bash it but I’m not sure I have even one good thing to say.

I should preface the following by saying that I’m no Nielsen when it comes to usability. I like images, I sometimes deviate from #00f as a link color, and I hate to tell you Jakob but sometimes I don’t even underline them. That being said, the reboot site (for me anyway) is totally unusable.

First things first, you need Flash in order to view anything at all. I know, people will tell me that Flash has like 98% penetration…whatever. I’m using a new install of Firefox and I had to go download it. My mom isn’t going to go get Flash to look at any web site. Granted, my mom is not their target audience…but as a professional web developer, I would assume that I am their audience. People are doing ridiculously cool things with Flash but it should add something to the presentation that can’t be accomplished any other way. As near as I can tell, they didn’t use Flash for anything that a little intermediate level knowledge of CSS couldn’t pull off.

“As near as I can tell” brings me to my number two beef with this site. I can’t read anything on it. That’s right, I CAN’T READ ANYTHING ON IT. Ok, that’s a slight exaggeration but once I got Flash installed and actually took a look at the site, I found very little contrast between any of the design elements. Dark red, faded grey, or pale yellow text against a black background. To make matters worse, it displays in the super small font that only the really super über hip and in the know designers are fond of. The text can’t be resized because it’s all in Flash and my young eyes just can’t take it. The default display of the links is in a color that’s either the same color as the background or pretty close to it. To me they’re totally invisible until I stumble across them with the mouse and then they light up. Maybe there’s more contrast on Mac because the colors aren’t so dark but I have to figure I’m not the only developer working on a PC. Some of us might like to participate in the reboot but like me can’t get the information they need to do it.

Did I mention the annoying music that plays INCESSANTLY in the background? I couldn’t stand it and I had to keep opening and closing the tab the site was running in as I flipped back and forth for reference while writing this.

I understand art for art’s sake and even being weird just for the sake of being weird. I can understand if some of the submissions are experimental, cutting edge, and/or not entirely usable because of it. But in this instance, the site is intended as a tool to convey information about the event and in that regard, it just fails. Miserably.

Anyway, I’m not sure there was any point to this post other than a chance to rant like a usability fanatic and possibly as a general outline for what NOT to do when developing. I’m going to start work shortly on a redesign of my site and I was interested in participating but now I’m not so sure I want to be associated.