White Space Matters

So far today I’ve read two really good articles dealing with web analytics: Metrics and Dimensions and Reports — Oh My! from the Omniture blog and The Complete Beginner’s Guide to Web Analytics and Measurement from UX Booth.

But seeing these two articles open in adjacent tabs lead me to do some side by side comparisons. I noticed my gut reaction the the Omniture blog was “I don’t want to read all that!” The UX Booth article was considerably longer, but it didn’t illicit such a knee jerk reaction. I think the reason for this is white space. UX Booth gives their content a bit more room to breath.

Screen Shots

The following screen shots show the first 910-ish characters of content. I attempted to preserve the white space between this content and off screen elements. I’m using PNG-8 to avoid jpg compression making the text fuzzy. The downside is the photo from Oniture ends up looking a bit off. My fault, not theirs. Also, Blogger appears to be scaling these images to be the same width. The Omniture Blog screen shot is actually about 20px wider, for what that’s worth.

Omniture Blog

UX Booth

Counting Pixels

The textual content here are within 5 characters of each other, 912 characters for Omniture vs. 907 characters for UX Booth. Both spend some screen real estate on supplementary content, a photo or a table of contents. But I find the UX Booth content much more inviting. And by my count they use about a third more pixels to present their content.

What Do You Think?

Do you notice a difference anything like what I’m talking about? Or am I “putting the ‘anal’ in analytics” to borrow a phrase from the Omniture blog? Either way, the quality of the content in both cases is top notch. Definitely worth a read if you’re into that sort of thing.

Optimizing Site Performance

Purpose & Goal

Right now I’m running some tests through webpagetest.org to establish baselines for site performance. This week I hope to generate some CSS sprites for our common images and set up gzip and xpiration headers on the server. Those are the last 3 big things pointed out by YSlow (actually I’m using Google Page Speed, but YSlow is cool too). Hopefully soon I'll be able to run a new set of tests to compare to the baselines I'm running now.

Sampling

I'm trying to get a representative sample of of pages to test. The home page gets the most traffic, followed by the Current Students page. Pride Online has the most popular departmental home page, but it's utilitarian and not representative of other pages. That moves us down to the home page for the library.

Those 3 pages realistically represent only about 1/6 of our total pages, but it’s the most heavily visited 1/6. I could add one more test case and increase my representativeness to the majority of our pages, but we’d see diminishing returns in terms of traffic (only about 16% of total site traffic). Also, the remaining 5/6 of pages are mostly text heavy and image lite. The benefits to those pages will come from optimizing the overall site template, which will be partially reflected in the 3 chosen test cases.

Thanks to Google Analytics for the ability to access that info easily.

The Site Performance widget in Google Webmaster Tools says we gained nearly half a second in our rendering time around June 6th. That half second was enough to move us up from around the 73rd percentile to the 82nd percentile. I have no idea why we saw this jump in overall site performance but I'm glad to have it. Maybe we can even hold onto it.

The Results Are (Mostly) In

The 3rd and final test is still running as I type this. I’ll link out to the results as they become available.

• Home Page
• Current Students Page
• Library

Step 1: CSS Sprites

I'm using SpriteMe and my own best judgement to create some CSS sprites for commonly used background images. I'm assuming SpriteMe already has something like Smush.it built in.

Results

• Home Page
• Current Students page
• Library Home page

Ok, maybe I need to smush my sprites after all. I've added about 60kb to each page load while freeing up about 15 http requests. Smush.it can’t find anything to optimize, but the image optimizer in YSlow can shave about 5k total from 2 of the sprites. SpriteMe makes some less than optimal choices, even occasionally introducing bugs. But like all software it has to make certain assumptions and those don’t always pan out. I need to improve upon the default sprites while I’m at it. With these newly optimized sprites, let’s look at the trade offs.

jQuery UI Theme Icons for Play Controls

The first sprite I made was actually already made for me thanks to the jQuery UI Theme Roller. I used the blue and red versions of the UI sprite to replace the play control icons under the featured stories on the home page. The bad news is that almost doubles raw file size. In exchange, I pre-load a lot of UI elements that we're not currently using anywhere else. But I plan to make more use of the jQuery UI in the future. So I think this is a worthwhile change.

	Baseline	With Sprites	Change
HTTP Requests	8	2	-6
Total Bytes	5,310	9,724	+4,414

Stripes Sprite

Both the header and the footer have background stripes that go all the way across the page. These were tiny, 1 pixel wide repeated images. But they were easy enough to combine.

	Baseline	With Sprites	Change
HTTP Requests	2	1	-1
Total Bytes	905	122	-783

Image & Badge Drop Shadows

Some day I’ll be able to pull this off with pure CSS but in the meantime I’m stuck with background images. The one for the standard large image gets used on most pages. The one for smaller images at the same aspect ratio and the badges gets used fairly often too. The other 2 don’t see as much use. Some pages don’t use any of these, but the majority of our high traffic pages do. The image produced by SpriteMe left extra white space to the right of the 16px icons screwing up the placement. I had to edit the sprite in Photoshop. After that Smush.it actually did a better job compressing the resulting image than YSlow.

	Baseline	With Sprites	Change
HTTP Requests	4	1	-3
Total Bytes	4,018	5,092	+1,074

Icons

The image produced by SpriteMe left extra white space to the right of the 16px icons screwing up the placement. I had to edit the sprite in Photoshop. After that Smush.it actually did a better job compressing the resulting image than YSlow.

	Baseline	With Sprites	Change
HTTP Requests	18	1	-17
Total Bytes	14,589	13,677	-912

Logos

I combined our logo with the RODP logo that’s featured on every page. But that only nets us 1 less HTTP request and as you’ll see below costs us significant bytes due to the differences between .jpg and .png image formats.

	Baseline	With Sprites	Change
HTTP Requests	2	1	-1
Total Bytes	12,270	39,876	+27,606

In a Nutshell

In a best case, a single page that references all these images (which is not terribly realistic), we’ve traded 28 fewer HTTP requests for 31,399 more bytes. That’s about 22 additional HTTP packets. Based on our test cases we’re realistically saving 12 – 15 HTTP requests per page. I know we’ll see a big pay off when we start effectively caching and gzipping this stuff, but I have to admit I’m disappointed with this first round of results.

Step 1.1: Learning from Mistakes

Ok, now I understand why the RODP logo was initially flagged as not to be included in a sprite due to being a jpg. I need to roll back the Logos sprite. I also need to alter the way we’re doing the random headers. We’ve been using something based on Dan Benjamin’s method from A List Apart but in terms of site performance it’s one of our slowest resources.

Results

• Home Page
• Current Students Page
• Library Home Page

We’re starting to see some minor pay off on the repeat viewing. Start render time on the current students page is now under 1 second. That’s pretty awesome, but we’ve still got work to do.

Step 2: GZip

I followed this guide as well as some official documentation from Microsoft. This online gzip test says we’re still not using compression but my web developer tool bar begs to differ.

Results

• Home Page
• Current Students Page
• Library Home Page

I just alphabetized the properties in each CSS declaration, primarily as a way to clean up my CSS and make it easier to manage. But Google’s Page Speed documentation points out the possibility of alphabetized CSS seeing more efficient gzip compression. Checking the alphabetized, minified, and gzipped version against the just minified and gzipped version with the Web Developer Toolbar (Information —> View Document Size) shows 8k either way. It doesn’t break it down into units any smaller than that. So maybe it saved me a few bytes, but not a kilobyte. So if we saw any gzip efficiency change from alphabetizing the CSS it’s less than 12.5%. If we assume rounding, then it’s less than 6.25%.

Step 3: Browser Cache

This one will be labor intensive. Before I put in the hours to set expiration dates and last modified dates for our various static resources I want to make sure they are properly optimized. We’ve covered CSS and JavaScript, but all the images that didn’t find their way into a sprite will need to be tested. I started this entry on Monday morning. It is now 1:30 on Wednesday. I this step will probably keep me busy the rest of today and a good chunk of tomorrow.

Ok, the clean up and optimization process has saved me about 10,000,000 bytes and 400 files. Gzip has been running for a full day and server’s resources don’t seem to be at all taxed. So far so good. Time to dive into Leverage Browser Caching.

I have a problem in that IIS reports the wrong last-modified date for certain files. Images seem fine. PHP files and other plain text files are not. Maybe I’m missing something in Dreamweaver. Our server also sends E-Tag hashes, which are newer than and in theory superior to last-modified headers. But they are also redundant together. E-Tags are apparently frowned upon when using multiple servers, such as a Content Delivery Network. All our content comes from just the one server so I don’t think it’s an issue with us. At worst we’s sending a single redundant HTTP response header.

So half the browser caching equation was essentially taken care of for us by IIS’s default settings. The other end of that equation is content expiration. I did not like that IIS just gave me a single check box to turn content expiration on. I wanted to be able to set it up by file extension. No such luck. I turned it on and did some testing with the Live HTTP Headers extension for Firefox. I was able to confirm that our php pages were not caching. Which is good. The last thing I want is someone to spend the next 6 months with an unchanging copy of our home page stuck in their browser cache. CSS and JavaScript files were caching, along with images. I already use version numbering on CSS, JavaScript, and image sprites. For the most part other images will have specific names anyway, so that’s good. Then I tested PDF files and did not like what I found.

I downloaded the PDF of our campus map and saw that the response headers told the browser to cache it for the next 6 months as well. We may need to update the map in the next 6 months. Maybe an office location changes to a new building or something. Worse still, many of our PDFs are newsletters. Monthly newsletters. Some offices have an archive listing years’ worth of issues while others just link to the most recent issue. In the latter case, I just save the new issue over the old issue on the server. With browsers caching these files, that wouldn’t work anymore. I’d have to give each issue a distinct name and adjust the HTML links to match, greatly complicating that process.

I rolled back those changes and tried setting up expiration on a directory by directory basis. So far I’ve only done /images/, /css/, and /js/. That covers the vast majority of our static files. Occasionally a directory off of root will have its own images directory. For now I’m leaving those alone. The handful of child directories inside /images/ also apparently did not did inherit the expiration settings of their parent folder.

The downside to all this experimenting is I have to bounce the IIS service for changes to take effect. That only takes about 8 seconds by my count, but I’t to think of someone submitting their final form for online orientation during that tiny window.

Page Speed still says we fail the browser cache check, but that’s due to the FEMA widget currently on our site. All resources being served from volstate.edu pass. So let’s run another batch of tests.

Results

• Home Page
• Current Students Page
• Library Home Page

Conclusion

This has been less a blog entry and more 4 days of notes to myself. Tomorrow I will try to recap the high points and present my data analysis.

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.