The Importance of Revisioning

Posted on by
Reply

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!

DrupalCon Portland, and the evils of <i> and <b>

Posted on by
Reply

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

Posted on by

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:

Homepage:

Future Students:

Current Students:

Community:

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 http://www.lanecc.edu/esfs, or http://www.lanecc.edu/finaid), 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 http://www.etre.com/tools/colourblindsimulator/

Google Mini Issues

Posted on by

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.

Caching Changes

Posted on by

Once again, we’re on a quest to make the website as fast as possible. Drupal doesn’t make this easy – on an average page load, our request for that page passes through three servers, sometimes generating hundreds of database calls and touching dozens of files. But through caching, we’re able to skip most of those steps and serve you content that was already waiting for you.

Now that we’re a couple of weeks post launch, we’re going to start making our caching a little more aggressive. If you’re a web editor, this might impact you.

Previously, the cache time on all of the objects (pictures, fonts, stylesheets, etc) on our pages was set to six hours. This makes sense the first few days after a big launch – we were anticipating lots of changes. But now that things have stabilized some, we’re turning up the cache lifetime on our stylesheets and javascript files to one year, and turning the cache lifetime of images up to one month. For 99% of visitors to the Lane website, this will result in up to 17 fewer requests to our servers – a 70% savings – creating a significantly faster web experience.

Unfortunately, this also means that there’s certain circumstances when a picture you’ve added to your website remains in the cache, and you’re unable to force someone to use a new one. Let’s say that you have a picture, called “kitten.jpg”, of a kitten eating a hamburger. You save your page, and people flock to see your awesome image. Every one of their browsers sees that the picture has an expires header of 111600 seconds – 31 days. Next time they visit your page, their browser won’t attempt to download that picture again unless at least 111600 seconds has passed.

The bad situation happens when you want to replace your kitten picture with a better one (say, a picture of your kitten eating a cheeseburger). You upload your new file as “kitten.jpg”. But your visitors will never see the new picture – their browsers see the same filename, and they know that particular file hasn’t expired from their cache yet.

So how do you fix it? Well, for one, remember that the picture will automatically fix after 31 days. But if you need an immediate fix, there’s a simple trick. Just rename your picture as “kitten2.jpg” and add it to your page like a new image. Now when the browser visits the page it’ll realize that it doesn’t need kitten.jpg anymore, and grab kitten2.jpg instead. We’re setting the cache at 1 year for JavaScript and stylesheets because we’re able to depend on Drupal to create new stylesheet and JavaScript names automatically when they change, and effectively do the same thing as we did with kitten.jpg in the example.

Things are actually a bit more involved than what’s above, but it’s not worth the extra confusion. If you’re interested in how we’re actually implementing caching, please send me an email or leave a comment.

I know this extra renaming step might seem painful, but we can’t ignore page speed. Google is incorporating speed into their rankings, and for users on slow connections (3g, in particular), we want to make sure the page renders in less than 1 second. Caching will take us a long way towards where we want to be.

Curriculum & Scheduling and Facilities Deployed

Posted on by

Two chunks deployed today:

This upcoming weekend we’re tentatively planning to try switching www and www2, which is one of the final steps in our migration process. There will be no further deployments ntil then. Also, this will require a short outage Friday night while we rewrite a bunch of URLs and do some DNS changes. Expect the outage during the myLane maintenance window, some time between 6pm and 11pm. We’ll try to tweet more details later in the week.

7 departments and less than 500 pages to go!