Mobile Traffic Milestone

Graph of mobile traffic, showing a clear pattern of year over year growth, including one day when 20% of visitors were mobile.
Percentage of visitors each day using a mobile device over the last two years

Last Sunday, for the first time ever, more than 20% of visitors to the website were mobile. And I don’t think the general trend can be missed: we’re up 38% on mobile compared to last year. Just more proof that we can’t ignore mobile when thinking about the web.

Also interesting? I was surprised to find that Saturdays and Sundays are our biggest mobile days. Each of the small spikes on the graph (not the gigantic ones) is a weekend. Anyone have any ideas why?

Changes in Drupal Land

There’s a couple changes happening in Drupal that you might want to be aware of:

Google Analytics Modifications

Currently, we’re using the old style Google Analytics embed code, and adding it directly via our template in html.tpl.php. This works, but it isn’t optimal. For a long time we’ve known that there’s a couple users that use the website in a way that doesn’t reflect real visitors: the Lane Web Team.

To take me as an example, yesterday I looked for old links to www2 urls, and found them on sixty different pages. I directly navigated to each of those pages, stayed on them for about fifteen seconds, loaded the edit window, made a change, saved the page, and left, directly navigating to another page. The statistics for that day are now ever so slightly skewed toward a person that appears to change pages at random, staying on them for almost no time at all, and who appears to come from nowhere. I’m making it harder to understand what people do on our website, and how we can serve their needs. And it isn’t just me – the whole webteam could tell a similar story.

So, this weekend 9/20/14, we’ll be installing the Google Analytics module. With it, the tracking code will automatically be disabled for our administrative roles, who together represent a disproportionate number of visits. How does this impact you? Soon it will look like our traffic numbers went down – probably about 2% – just because we’re not tracking those three roles. So, if you get an analytics report mailed to you, don’t be too alarmed if the numbers go down, just adapt to the new baseline. And remember, you can always contact us if you’d like help thinking through your analytics numbers.

Friendlier URLs

By default, Drupal uses ugly URLs. The contact page is technically something like We’re using a couple of modules (Path Alias, part Drupal Core, and Pathologic) to make those urls look friendlier, like But, ever notice what happens when you try to edit a page? You get another ugly url, like This weekend, we’re also going to try to fix those, using the Extended Path Alias module. All of those pages that previously had a node number in them will now have a nice, aliased URL, like

I’m sure that doesn’t seem very exciting. But it is, because when someone submits a webform, they were previously taken to a confirmation page with an alias like Because that url starts with /node, Drupal isn’t able to figure out which menus to include, meaning the person that just submitted your webform is effectively no longer on your part of the website.

Of course, by replacing all those technical looking URLs with friendly ones, that makes it harder for you to tell us the node number, or to paste a node number into the link dialog when editing a page. So we’re also going to make it easier to find those node numbers – starting next week, just look to the right side of your screen while logged in and you’ll find a little black tab with the node number written on it.

EDIT (7/9) – Unfortunately, we had to roll this one back. With this enabled, /it/somepage.html would actually go to /it/, meaning no 404 was served. We’re still looking for a solution at this time.

Print Styles

This one is actually live right now! We’ve added a print style sheet to the pages, which attempts to make webpages more useful when printed out on paper. It’ll probably work best in Firefox or Chrome, but when you print:

  • The left menu will be hidden
  • The header of the page will be hidden, except for the department title (if present)
  • The megamenu will be hidden
  • The footer will be hidden, except on the landing pages
  • Links will have their urls added to them, so that if you stumble across a link in a printed page that you’re interested in, you can at least type that link into a browser manually.

If you notice any bugs (There’s a LOT of printers on this campus, and its impossible for me to test all of them), please let me know.

The Importance of Revisioning

When you’re editing one of our Drupal pages, you may have noticed a little tab down at the bottom, right above the save button:

A picture of the bottom of our Drupal Edit screen. Of note is the "Revision Information" tab which defaults to closed.See that little grey box? The one that says “Revision Information”? That’s actually a very helpful box. In there, you’ll find a place to enter a revision log message, where you can describe the changes you made to the page, like this:

Shows a revision message added to a node: "Modified the header style"You may not have been aware, but if you click on the revisions tab at the top of a page, you can get a list of who made changes, and when those changes were made. If everyone also includes revision log messages, then we can also, at a glance, see what was changed. And that can be super helpful:

The revision log for our sample node, at the top is the revision made in the previous picture, including the message left. Other revisions didn't have a message.
Unfortunately, this example may be a case of “Do as I say, not as I do”

As you can see, the first 4 revisions, by me, have no revision message. It’s very difficult to see at a glance what changes I made, or why I made them. But the most recent message, “Modified the Header Style” tells you exactly what I changed.

If we wanted an ever better message, we could have written “Changed page header from a paragraph to an H2, in accordance with the guidelines provided by the webteam”. Then we’d know not only what was changed, but why.

So revisions are awesome, right? But they work best when everyone uses them, so that if I modify your page, you’ll know what I did, and I’ll know what you did before me. For that reason, this weekend we’ll be turning on a module that enforces a revision log message. In other words, if you forget to enter a revision message, you’ll get a nasty red message that highlights the revision message box and asks you to fill it in. Please take the time to write a brief, meaningful message. It’ll help everyone out.

This change is part of a broader set of changes we’re hoping to make to the Drupal editing experience to allow more flexible workflows. Expect more details in the upcoming weeks!

Archives Deployed

It took a bit longer than expected, but today we deployed our largest remaining chunk, with some 197 pages in it:

Also impressive? Internally, we’re down to just 17 404 errors on the entire site. Just 4 chunks, and 259 pages, left to go!

DrupalCon Portland, and the evils of and

Last week, two Lane Web Team members went up to DrupalCon Portland.

The Drupal "Drop" under a pendulum at the Portland Convention Center
Did you know Oregon has the world’s largest Foucault Pendulum?

In addition to opportunities to network with other institutions running Drupal around the state and world, there were a ton of awesome speakers and “Bids of Feather” sessions, where groups of like minded people got together to talk about issues relevant to them. Take a look:

A whiteboard, showing a grid of different sessions at various times, including such sessions as "Pantheon and HigherEd" and "Higher Ed Content Strategies"
This seems like a weird thing to take a picture of, but the BOF listing couldn’t be found on the web anywhere – wifi at conferences is notoriously poor, so it wouldn’t have done us much good.

The second day’s keynote, by Karen McGrane, was about user experience and design, and provided some excellent insights for us (watch it here!). The one that will impact you most is our removal of the <i> (italics) and <b> (boldface) elements from the list of allowable elements on Drupal content pages.

As per why, it has to do with two things: Future Proofing, and Accessibility. Back in the day, when content was designed for paper, boldface and italics made a lot of sense. So the <b> and <i> HTML elements were used to replicate this on the web. But, not too long later, people realized that these elements didn’t actually convey any semantic information – they were purely visual. So they added the <strong> and <em> (emphasis) elements.

Now, here’s the thing. Strong text, and emphasized text look exactly the same as boldfaced and italicized text – this sentence actually uses <strong> and <em> tags. So the average web user won’t notice any difference. But what happens if you’re using some futuristic wearable computing device that reads web pages to you? With <strong>, your device would know to read a certain word or sentence strongly, and to emphasize text in <em> tags. But if they were <b> or <i> tags, you wouldn’t have even known they were there . Turns out this is the same way screen readers work.

As of this morning, we’re filtering out <i> tags and <b> tags. There’s a 99% chance this doesn’t impact you at all – using the buttons in the WYSIWYG on Drupal automatically uses <em> and <strong> instead. But if you’ve been doing something fancy after disabling the rich text editor, you might need to change your page some.


Color Blindness Testing

As we prepared to launch the new design, one of the things we were sure to focus on was accessibility. While that’s been covered in previous posts, there’s another area of web accessibility that’s often forgotten that I’d like to highlight here: Color Blindness.

Color Blindness is a complex condition, manifesting one at least ten different ways, and  affecting some ten million Americans. Although most color blind individuals are actually color weak – meaning some vision of a color, but trouble distinguishing it from nearby colors – we chose to do our tests on the more severe form, rationalizing that if we can design a website that works for true color blindness, it will also work for weakness.

Here’s some simulations of different areas of our site for different types of color blindness:


Future Students:

Current Students:


Content Page:

The primary thing to look for in those images is contrast. Do the color choices of our design ever create a situation where a color blind person wouldn’t be able to find some of the text? For example, if the design had adjacent green and orange elements, a person with Protanopia would probably be unable to tell them apart. From what I can see, we’re in pretty good shape. And just to make sure, I double checked with a colorblind coworker.

Another thing to think about with Color Blindness is the use of color to convey important information. For example, say you receive a message on a website, “The email was not sent”. If that message is in red, most of us would assume that it was a bad thing – the email we were trying to send didn’t make it. But if that message was in green, then most of us would assume it was a good thing – the message we desperately didn’t want to send was canceled. For this reason, Drupal includes a checkbox next to “good” messages, and an X next to “bad” messages, so that the intent of the message is always clear, even if the color isn’t apparent.

Although we tried our best to test a few regular content pages (like, or, with over 4000 pages, it isn’t possible for me to hand check every one. For that reason, if you’re a content editor, please try to keep contrast and intent in mind when you’re working on your pages.

I created those images using GIMP, a free software program, using the Color Deficiency Filter (under Views). If you’d like to try seeing your page, there’s a number of color blindness simulators online. I’d recommend

Google Mini Issues

We’ve mentioned a few times in meetings around Campus that we’re tracking search volume on our Google Mini. Our plan has been to use the last year’s data to see how the new website impacted visitor’s abilities to find different things. In other words, if for the last year everyone searched for “Schedule”, and now suddenly no one searches for “Schedule”, we can assume that we succeeded in making Schedule more visible. On the other hand, if no one used to search for “Moodle”, and now suddenly everyone is searching for “Moodle”, we know it’s hard to find Moodle.

We also tried to make the MegaMenu as small and as lightweight as possible, to make it load as quickly as possible. Right now the entire Megamenu uses about 30k – less than your average Internet Cat Picture.

Picture of a cat in a hollowed out computer monitor, with the caption 'I'm in your internet, clogging your tubes" (spelled wrong)
For example, this picture uses 31k.

But unfortunately, when we put these two things together – a super optimized mega menu and a desire to track search engine statistics – something broke.

The Google Mini has different collections. For example, we have a collection that searches just our COPPS documents. The biggest collection is the default collection, which searches all the pages in the index (all collections, plus pages not in any other collection). When you search the Mini, a bunch of parameters are sent in with your query, telling the Mini which collection to use, which set of styles to apply, etc. If you omit all of these parameters, search still works – the default collection is searched and you’re shown your results in the default front end. I assume that also meant that the searches were logged as belonging to the default collection.

Unfortunately, it turns out this is not the case. Here’s a streamgraph of our search traffic:

Search volume to Lane, showing varying ups and downs throughout the year, then a sudden dropoff for the last two weeks
428/12 – 4/13/13

See that real small area on the right hand side, where traffic falls off a clif? For the last two weeks searches were correctly logged in the search engine, but are not given to the default collection for inclusion in search reports – effectively making them invisible to us.

We added the hidden parameters to the search bar in the MegaMenu, and verified today that we’re seeing an 800% increase in search traffic in reports over what we saw yesterday. Apparently those parameters are not as optional as I thought.

In a way, this error isn’t a big deal. Right after launch, we expected a surge in search traffic as people searched for things before getting comfortable with the new layout. So we’d always anticipated throwing out the last two weeks of data in our analysis. But as a bit of a data nerd, I’m always sad when any data is lost, and we’ve had a hard time interpreting how people are interacting with the new site.

I’d also like to point out that we added the MegaMenu to the search results page. If you search for something via the search engine and discover that you’re not getting the results you want, you can also try AskLane from the search box on the MegaMenu. Of course, we’d also encourage you to submit some search feedback to us (the form moved to the bottom right), so we can try to improve the search engine to give you better results.

Two final notes. If you ever find yourself managing a Google Mini, and pulling your hair out because the new XSLT you applied isn’t rendering your new styles, it’s because you need to add &proxyreload=1 to a search string, to clear the style cache. Second, this weekend we’ll swapping www and www2 (don’t worry – all links will continue to work regardless which one you use), and as part of that we’ll be resetting the search engine index. That should clear out a lot of old pages that aren’t really relevant any more, and are no longer linked, but are still out there on our old web server. It’ll take most the weekend to rebuild the index, but hopefully next week you’ll get even better search results.