Trusting Second Guessing My Gut

Since December I've been blogging on the new multi-user WordPress server at work, but it's currently down. Once we get it back I need to figure out how to automate cross posting. This blog space belongs to me, Derek Pennycuff. The blog on the WordPress server technically belongs to the webmaster position at Vol State. If/When I leave Vol State this will still be mine. The other will not. Echos of the knowledge management course.

The Web as She Is Used

Anyway, right now I'm struggling with some stuff that my gut tells me is right but I have no evidence to support or refute it. I'll try to lay it out here and cite some specific examples.

Email Links

The default behavior of a mailto link is to launch your default email client. Here at work that means Outlook. On a default install of Windows it usually means Outlook Express. Our audience does not make heavy use of email. Most of them probably don't have a default email client. What email they use is probably web based. Some browsers let us set our web based email client of choice as the default, but how many users actually bother to do that? Personally, I tend to use Firefox's "copy email address" feature from the contextual menu when I right click a mailto link. But I've spent enough time working tech support to know that most people don't know much about advanced features such as right click menus.

So I prefer to use the actual email address as the link text for mailto links. In addition to all of the above, it's a nice visual cue to differentiate a mailto link from a standard hyperlink.

Telephone Numbers

Making that change introduced a new problem. The easiest way for me to make this change is to add a column at the end of the table and move the email addresses there. But that puts the telephone numbers in the middle of the table. A mailto link is designed to be used online. A telephone number is non-interactive.

(Although I confirmed over the weekend that a Nexus One phone does recognize a well formed phone number on a web page and makes it behave a bit like a mailto link. Among our users that's an edge case and I have no confirmation of how other mobile devices treat phone numbers. [Several people have pointed out this is de facto standard behavior on smart phones.])

My gut tells me most people will either dial the number from the screen or write it down. Either will involve a bit of eye darting on and off the screen. Have you ever had to look away from one specific table cell and then locate it again quickly when you look back? Working in Excel can cause this just as much as tabular data on a website. It's not easy. I think putting the phone number at the end of the table helps with this a bit. This brings us to a 3rd iteration of a staff listing page.

1. 
2. 
3. 

Aesthetics vs. Usability

The list above shows a progression of what my gut tells me is increasing usability. However, my eye disagrees. Aesthetically I see each version as a step down from the previous. And without any real usability data I'm at a loss as to how to resolve this cognitive dissonance. I'm dealing with opinion either way. And since so much of the usability issue hinges on action taken off-line, picking up a phone and making a call, I can't think of a way to A/B test it.

I need to standardize these pages. Inconsistency kills both the usability and the aesthetics. All I've got to go by is my own conflicting opinions, so if you've got any ideas please share them.

Update

A strong preference for option #2 is already apparent among the people who have chimed in on this issue. Apparently I'm on to something with the email address as link text for mailto links but I'm probably over thinking the telephone number thing. I'm going to continue to mull this over mentally so feel free to continue to comment or email me if you're reading this now and have anything to share. But in the interest of productivity I'm going to make option #2 the standard format and get to work. :)

Badges, Banners, and Calls to Action

The Problem

The folks in Admissions are getting phone calls from people who can’t find a link to the online application.

Probable Causes

1. Users can’t find content “below the fold”
2. General placement of call to action does not align with relative importance
3. Banner blindness

Data

When I have a problem, I like to kill it with fire attack it with data; Google Analytics to the rescue! As of today, we’ve got just over 6 weeks worth of data since launch. Here’s what the numbers tell us about this page:

How They Got There	How Many Times They Got There	Percentage of Total Traffic for This Page
Future Students Landing Page text link in content	3,314	65.2%
Home Page badge	518	10.2%
Admissions Home Page	299	5.9%
Future Students Landing Page badge	199	3.9%
External (usually Google or another search)	158	3.1%
A to Z Index	120	2.4%
Total	5,081	100.0%

That’s data pulled together from several different reports as interpreted by me. There could be some rounding on Google’s part and some fudging on mine. But the general trend we see is reliable.

What Does That Mean?

By far, the most effective way we’re sending people to this content is the link about 1/3 of the way down the Future Students landing page that clearly states “The first step is to fill out an application.” In fact, 9.66% of all the people who see this page follow that link. It’s the 3rd most popular link on that page after Programs of Study and the Current Students landing page.

Taken together, the 2 badges are the 2nd biggest traffic producer, but we have a big drop off between 65% of traffic at #1 and 14% combined for #2 and #4.

After that we get a noticeable long tail effect, but that's normal for this type of data.

Applying the Data to Possible Causes

Content Below the Fold

The problem does not seem to have anything to do with scrolling. A wealth of previous research shows that content “below the fold” doesn’t really suffer for it. But it’s nice to see confirmation of this in our own data. The most effective link to this page is only visible after a bit of scrolling even on my rather large monitor. Comparing the people who are getting to the page to those who are not getting there could be apples and oranges, right? But we know about the 2nd group because they are calling us. Both the main telephone number and the direct number to the Admissions Office require a bit of scrolling to find. These people are obviously finding that information, so scrolling isn’t presenting a significant hurdle to finding information among this population.

Sub-Optimal Placement on the Page

We could still have a misalignment of placement vs. purpose even if scrolling doesn’t enter into the equation. The purpose of the badges is to feature timely content. The application process should probably be permanently featured, but a permanent badge runs askew of the core purpose of being timely and changing often. The link to the schedule for next semester makes for an excellent badge because that content is in high demand right now but in a couple of months we should be able to safely replace it with something more timely, perhaps a badge for the Academic Calendar so that people can quickly and easily find the dates for Spring Break.

So what are some other ways we can permanently incorporate “Apply Now” into the overall site template?

The primary navigation is all user role based, so adding it there wouldn't make sense. Putting it below the primary navigation would make it look like secondary navigation. At one point the site template had a “default” secondary navigation for those pages that didn’t have such a menu. It muddied the waters as to the purpose of that area of the page and it was an early cut in the design process. The area at the top, with links for the People Finder and A – Z Index, could work, but it’s already full. We’d need to delete a link in order to make room for it and I’m not comfortable dropping anything currently there.

We could add it to the Help Center under the Registration heading. Right now everything in that category applies to students who are already admitted, but I doubt most incoming students have a clear understanding of that distinction. Ask the average senior at Gallatin High School what the difference is between applying for admissions to Vol State and registering for classes at Vol State and they’ll probably look at you like you’ve got 3 heads. I would have at 17.

We could also list it in the Help Center under the Students heading. Either of those options fail to put the link visible on the screen by default, but it is accessible from (almost) any page. The footer is also an option, although that would take a bit more work on my part. We’ve got space to spare down there, but I want each area to have a clearly defined purpose.

Banner Blindness

But I think a bigger issue has been brought to light here. I’ve just gone through the navigation summary for all 7 pages that feature badges. None of the badges appear in the list of top 10 links for those pages. That may not be a bad thing if it means people are finding what they are looking for in the actual content. But it could also indicate a bad case of banner blindness.

Or Is It?

But approaching it from the other side, 92% of the traffic coming into the Schedule of Classes page are getting there through one of the various badges. That 92% translates into about 1,225 total page views, which is so tiny in comparison to the traffic coming through the landing pages that it may not make a blip on the radar. Learning Help Centers gets about 75% of its traffic from badges. SEEK gets about 94% of its traffic from the badges. But again page views measured in the hundreds are so small in comparison to the total traffic pumping through the various landing pages it’s probably easy for those numbers to fall through the cracks.

Overall badges seem to channel a significant percentage of traffic for the sorts of things people would not otherwise be aware of, such as SEEK and the Learning Help Centers. They also seem to work well for new site content such as the dedicated page for class schedule information. Both SEEK and the Learning Help Centers are fairly recent additions to the site as well. Badges seem to preform less well for older content with high awareness and lots of paths of entry. But even in the case of the “Apply Now!” badge, 14% of total incoming traffic may not sound like a significant boost, but it still translates into 700 visits. That’s nothing to sneeze at.

Conclusions

Lots of people are eventually getting to the application page, but that doesn’t change the fact that some are not and this is driving a noticeable number of phone calls to the Admissions Office. Some of the people who are eventually getting there may not be getting their easily. Maybe 10% of them were 30 seconds away from calling us too. And for every person who calls, maybe 3 or 4 other people just give up without even calling us. We really have no way of knowing. So I’m not pulling out these numbers as a means to dismiss the problem as it was reported to me. I aim to use the data available to understand the scope and context of the problem in order to find effective solutions.

We can increase our link coverage by adding it to a few of the persistent template elements:

• Help Center —> Registration
• Quick Links —> Students
• Footer, not sure exactly where yet

We can tag and measure the performance of these links over time to gauge their effectiveness. But ultimately more data is needed. And it’s the sort of data Google Analytics can’t really give us.

In the near future, I plan to do some usability testing with potential students. Locating the online application will be one of the primary tasks for that research. The results may help us arrive at a long term solution.

First month with the new site

Yesterday was December 2nd. We launched the new site on November 2nd. So as of today, I have one solid month of data on the new site available in Google Analytics. Let’s take a look at how we’re doing compared to November 3rd through December 3rd of last year. The dates don’t match up exactly so that we start on a Monday and end on a Tuesday with both date ranges.

• Visits up 27.53%
• Unique Visitors up 89.16%
• Page views up 38.51%
• Average page views up 8.61%
• Average time on site up 22.44%
• Bounce rate down 46.09%
• Percentage of new visits up 90.69%

These are all positive changes. Bounce rate is a bad thing, so seeing that number go down is good. We’re reaching more people, who are looking at more pages and spending longer stretches of time before leaving. But I’m not ready to say all this is due to the redesign. After all, we’ve seen a significant enrollment increase this semester, so all these numbers should be improved over a year ago.

So let’s also compare the first month with the new site to a similar date range the month previous; 11/02/2009 through 12/02/2009 compared to 9/28/2009 through 10/28/2009, again starting on a Monday and ending on a Tuesday.

• Visits up 0.22%
• Unique Visitors up 15.27%
• Page views up 30.01%
• Average page views up 29.72%
• Average time on site up 41.74%
• Bounce rate down 51.39%
• Percentage of new visits up 35.89%

This comparison is less straight forward. The new site has Thanksgiving break in this data set where the old site has no breaks, which would seem to put the new site at a disadvantage. But the old site’s figures come before registration opened up for the Spring, so in other ways it’s at a disadvantage. In other words, don’t read too much into this comparison.

It does help make it clear that the sorts of metrics tied to raw traffic have little to do with the redesign. The percentage change in visits is virtually zero. But metrics that measure engagement, such as time on site and bounce rate, actually show more improvement against a month ago than they do against a year ago. This probably helps show the natural boost we get thanks to registration opening up this time of year. When we’re talking about aggregate data it’s important to keep in mind all the variables that have nothing to do with the design of the site.

I’m more comfortable attributing large shifts in metrics for specific sections of site content that have been significantly overhauled as part of the redesign. For example, the list of our programs of study saw an increase in visits of 502.65% and an increase in unique visitors of 290.45% compared to figures for October of this year. Compared to a year ago, the difference is 548.75% increase in visits, 333.29% increase in unique visitors. One of my primary goals with the redesign was to increase the visibility of this content because I think it’s an important part of the “shopping” process. I think we can safely call that a success.

Don't mind me

I just need some links from a non Vol State domain to test the custom 404 page.

• broken link
• html to php change
• invalid page, valid directory
• invalid page, invalid directory

The Culture of Technological Abundance

In one of my computer science courses the instructor asked if computing resources have reached the point where efficiency can safely be ignored. I responded with a resounding “No!” but some of the younger pups in the class disagreed. I'm begging to think I was showing my age, at least within certain contexts.

Something in my brain makes me love the idea of optimization. I actually police myself away from it, but I still find myself spending hours upon hours thinking about “better ways” to do things. I was recently debating with myself about storing telephone numbers in a database as integers vs. strings. I found the integer approach most appealing. It just felt right. But I quickly figured out that would require formatting the data to be human readable every time I needed to display it as well as a bit of trickery on the front end to get the form input (which would be in a human readable format) into a basic int structure. That consumes a lot of my time, and possibly a lot of time for the users who eventually put the collected data to use. In exchange, I save a little bit of hard drive space.

The new server has 500 gigs of RAIDed space. A formatted telephone number string, such as “(888) 555 - 1234” takes up 16 characters. That's a 17 byte VARCHAR. Even less if we default to something shorter for unrequired fields left blank by the user. But for the sake of argument let’s go with VARCHAR. Storing “8885551234” as a BIGINT requires 8 bytes, saving us 9 bytes. That’s 9 out of over 500 billion available. We’ll end up with a few hundred form fields that will see a few hundred hits per year. For the sake of argument let’s say 400 squared, or 160,000. If my attempts at optimization save an average of 9 bytes per field per record, we'll run out of space after about 350,000 years. I'm not sure what the clock cycles are involved in fetching or even comparing a 16 character string vs a 10 digit number, but probably even more negligible than the storage space. Obviously, server resources are abundant when compared to my time and the time of my users.

I’m about half way done building the forms on my to-do list and I just convinced myself to change the way I handle things. Oy vey.

If data is collected for the purpose of being later presented to humans, I will store it as a string, optimization be damned. I’ll use numeric types for data that is collected to be crunched, which in all honesty if rare right now. In situations where it could conceivably be used for both, such as dates, I’m probably better off storing both versions and fetching (or sorting by) whichever is most appropriate rather than running a timestamp through the date() function as needed or converting user input into the MySQL DATE format (which is both human readable and easily sortable).

2 years into this redesign project and I’m still not done. In hindsight, the biggest setback has been my own perfectionism. I have a hand crafted attitude towards my work. I take great pride in it. But at what cost? It feels great when I see something like Smashing Magazine’s list of current best practices in form validation and I realize I’m already doing the majority of those things simply because they “feel right”. But I spent all day yesterday working on a single form, stayed 45 minutes late, and still didn’t get it done. That felt anything but great. What’s the trade off? Where do I draw the line?

I’m even doing it now. I’m encoding my apostrophes and quote marks. Can anyone out there notice the difference between “this” and "this"? It's 12 extra key strokes for me to use the "proper" encoded characters. For all I know, Blogger auto-converts them for me anyway. (*EDIT* No, it doesn’t.) I've just developed the habit over the years of hand coding HTML. 12 keystrokes per quote pairs times 5 quotes per page times 3,000 pages at 400 characters per minute is 7.5 hours. That's a full workday over the past 2 years. Is that too high a price to pay for typographic correctness?

What's the cost of XHTML validation? Of ADA compliance? That last one could end up saving us a mint if lawsuits start getting tossed around. I know where my personal comfort level lies on most of these issues and I'm willing to re-evaluate in light of new information and fresh perspectives. As the only web guy around here I guess I get to make those judgement calls for the institution. But in a freelance situation my time is the client's money, which is definitely a scarce resource. A 0.2% markup cost for things like typographic correctness may not sit well with some clients, but there's plenty of designers out there who also don't care. Maybe they can service those clients.