Drupal – Page 4 – Lane Community College Web Team

Content Redevelopment

Welcome to the first of a series of posts on rewriting your content to be friendlier, easier to read, and easier for search engines to find.

As employees of an educational institution, we’re constantly reading and writing to our peers. I know that I spend a lot of time in Groupwise – I read 16,134 words in emails just this week – and we’re only three days in! If my emails were a final paper for a class, they’d be an A+ guaranteeing 66 pages of Times New Roman, double spaced. Of course, like many of us, I’m on a few committees as well. There’s a ton of words in minutes and papers read preparing for meetings. And all this reading isn’t lightweight – email alone averaged a 10th grade reading level – pretty good, considering the number of emails that were just “Thanks!” or “Sounds Good”, both of which are really only a step from “See Spot Run”. And I can’t be anywhere near the worst – some of you must have it a lot worse.

At work, we deal with complex topics like student retention or math completion, with lots of complex statistics and intricacies that demand exacting language. In our classrooms, we’re responsible for educating students, and part of that is helping students learn to read and write at a college level. And the content we provide in our classes reflects that.

So far, so good. But the website isn’t work communication, and it usually isn’t a teaching venue. The website is a marketing and recruiting tool that sometimes does double-duty as a repository of knowledge for students, employees, and community members. That means content needs to be findable and readily digested.

Over the next few weeks, we’ll be completely rewriting a page on the website. The owner of that page has graciously volunteered to let me tear it apart and write about it here. I chose this page for two reasons: first, it accurately represents the type of writing we see all over the Lane website, and second, it’s a manageable length. There’s a few pages that are thousands of words long that desperately need help, but for a blog post, we need something we can read in one sitting.

Tools

The primary tool we’ll be using to rewrite this page is HemingwayApp, an amazing website that will provide us with instant readability feedback. Though HemingwayApp won’t tell us how to write, it will tell us some of the places we’ve gone wrong.

We’ll also look at the ToneAnalyzer, a tool that tries to figure out the emotional tone of some body of text. Generally speaking, we want a tone that’s social (but maybe a different kind of social than you’re thinking).

Finally, the web team has been preparing to roll out some integrated tools in Drupal that will help you analyze the readability and the SEO friendliness of your content. We’ll see a preview of what those will look like after we’ve finished rewriting.

Do as I say, not as I do

One of our goals in rewriting the content will be end up at a 3rd to 6th grade reading level. That might feel surprisingly low, especially at an academic institution. So why so low? Two reasons. First, a large number of people both in our target audience and across the country can’t read at a college or even high school reading level. We have a responsibility to present our content at a level where the majority of our audience can understand it.

But also because people generally don’t want to work hard when we read. Everyone knows that sitting down and reading Joyce or Proust is a great personal development exercise. But for most of us, it isn’t fun (observe the layer of dust on that shelf in my living room). The fun books, the best sellers, the ones we enjoy reading and not just having read were often written at a surprisingly low reading level. We should strive to do the same on the web.

Of course, these blog posts may fall short of that ideal. And that’s ok – this blog is meant to be educational and technical. So while it’s still important I follow the basic rules – like avoiding passive voice, providing meaningful hierarchy, and meticulously avoiding excessive use of modifiers – I’m judging my audience to be capable of handing the added difficulty and writing for them.

Sometimes that’s ok on the Lane website, too. It’s probably alright that the Graham-Leech-Bliley Procedure is at a grade 20 reading level and is more than a thousand words long. That’s appropriate for the target audience for that page. And sometimes, we’re stuck with difficult language as well. I tried really hard to make our privacy statement accessible, but ultimately it’s a legal agreement, and language choices were limited (it’s grade 10). But we have to do as best we can.

Game Plan

Next post, we’ll review the content on our sample page and the context of the site where it lives.

All the posts in this series:

Call to Actions

This weekend, while rolling out some minor module updates, we also added a way to convert a link from this:

to this:

If you’re not a fan of orange, you can also use the blue version:

These big, hard to miss buttons are the page’s Call To Action (CTA). When you’re working on a page, you should be thinking about what the CTA for each of your pages is. What do you want the visitor to do on that page? Is your page purely informational (example: financial aid disbursement schedule)? Or are you trying to get them to take some sort of action (example: register for the Convening the State event)? If your page falls into the latter, you may want to consider the above CTA buttons.

To use them, you’ll need to add two classes to your link. For orange, you’d add cta and cta-orange, for blue you’d add cta and cta-blue. Don’t know what that means? Don’t worry about it! Just give Lori a call and she’ll walk you through it. Super easy.

One more thing: your page should only have one CTA. If there’s absolutely, positively, no way at all in the world you can have just one CTA, you can maybe add a second. If you have a bunch of CTA’s, you’re not helping people find what they need, you’re splitting their attention and making it unclear what they should do. And wherever possible, we should be trying to make it clear what we want people do on our pages – remember, people skim more than they read.

Drupal does CAS

For the last two years, the IT department has been working on a project to improve identity, communications, and passwords across campus. We’re finally ready to start rolling pieces of that out. And you, lucky Drupalers, are getting to test one of the very first pieces.

Starting on October 9th, when you log into Drupal, you’ll be automatically taken to the CAS login page. What’s CAS? CAS provides a Central Authentication Service, which means that when you log into it, you’re actually logging into all the services that CAS is aware of. And when you log out, you’re logging out of all the services that CAS is aware of.

In the future, this is going to let us do some pretty neat things. For example, that means after you log into Drupal, when you go to myLane and press login, you’ll just automagically be logged in – without having to enter your L Number and password all over again. But for now, it’s just going to look like a different login page. So what’s it look like?

No, really, that’s it. When you go to the Drupal login page, it’ll automatically go to the CAS login page. After you log in, you’ll go back to Drupal.

It’s super important that you remember to log out when you’re all done. Since logging into CAS logs you into all services, if you forget to log out that means the next person that comes up to that computer could not only use Drupal as you, but also use any other CAS enabled service (and eventually, that’ll mean almost everything at Lane!). So please, hit the log out button when you’re done!

Encrypt all the things!

Over the last few weeks, we’ve been battling a problem where the web server would sometimes forget its own name. Some days it would want to go by www.lanecc.edu, other days it would want to go by 163.41.113.43 (our public IP address), and other days it would use our internal server name. We gave it a stern talking to, but it refused to cooperate.

The solution is to specify Drupal’s base_url variable. Normally, Drupal tries to identify what server name to use and it does a pretty good job. But clearly our server isn’t so great at that anymore. Specifying the base_url forces Drupal to use what we tell it.

But the base_url needs to be a full URL, complete with protocol. So it needs to be “http://www.lanecc.edu” or “https://www.lanecc.edu” – we’re not allowed to just say “www.lanecc.edu”. Why does that matter? Because even though the difference is just one letter – an “s” – that turns out to be one of the most important letters on the Internet.

HTTP is the protocol that defines how a lot of content on the internet moves around. It’s part of how this page got to you. But it’s a completely unencrypted format. When you’re browsing the web in HTTP, you’re sending everything in clear text – anyone that can listen in (for example, on an unencrypted WiFi connection) can read whatever you’re sending. But if we add the “s”, and browse via HTTPS, then everything we do is encrypted, and no one can listen in*.

But there’s some gotchas with HTTPS pages. For instance, most webpages actually consist of multiple requests – the Lane homepage has 34. If even one of those requests is made over HTTP instead of HTTPS, then we have a “mixed mode content error”, and the browser hides that content.

And that’s kept us from specifying our base_url so far. If we set it to “http://www.lanecc.edu”, then on pages that are HTTPS, like webforms, then all the styles and javascript will break, since those would be sent over HTTP. And if we went the other way, and set the base_url to “https://www.lanecc.edu”, then our caching infrastructure, which is built assuming most connections are over HTTP, would break, significantly slowing down the site. So we’ve been stuck running a mixed-mode site – most people use HTTP, but authenticated people and webform users use HTTPS.

There’s a number of reasons that isn’t ideal, which are well outside the scope of this already too long blog post. And the wider Internet is moving forward with using HTTPS only everywhere. So yesterday, we deployed new caching infrastructure which will allow us to go with using HTTPS only. Going forward, all connections with www.lanecc.edu will be encrypted.

This should be a almost completely transparent transition, but if you notice any problems, email us at webmaster@lanecc.edu and let us know!

* strictly speaking, this isn’t true, and there’s a a whole category of attacks that can still work on HTTPS. But there’s a fix for that too, and we’re working on rolling that out too some time in the future.

Some Announcements

Over the last few weeks, we’ve added some features to Drupal that may interest you.

First, we’ve added some new buttons to the WYSIWYG editor:

The “K” button works much the same way as the Flickr button, and allows you to embed Kaltura Videos (hosted on http://). For more information, talk to Dean Middleton
The map button allows you to embed the new style Google Maps maps. Google changed both the Google Maps interface and the embed codes recently. If you see a white box on the left hand side of Google Maps, you’re using the old version, and should continue to just paste the map link into the WYSIWYG on its own line, like always. But if Google Maps takes up the entire screen, you need to copy the embed code and paste it using the new Google Maps button in the toolbar.

Second, we’ve had some problems with revision messages. Here’s a real life sample of some of the message we’ve seen the last few weeks:

z
.
Revised page
Update1
page update
routine
same
got it

Clearly, these are incredibly unhelpful. Log messages should be concise and descriptive. Here’s some great ones:

Revised office hours and added fall term hours
Update reference to Retail AAS
added IT maintenance window event spud
updated links to event flyers
added link to BP040

When we’re trying to figure out when something changed, it’s a lot easier if we can skim through the revision log. And it helps you – that way you can see who else changed your pages, and what they did.

Due to the number of really poor revision log messages, we’ve been forced to add some checks within Drupal for obviously bad ones. If your message doesn’t meet the terribly low bar we’ve established, your node will not save, and you’ll be asked to enter a better message.

Remember, if you find yourself constantly entering messages like “Trying again” or “One more time”, you should try using the Preview button to make sure what you’re adding is what you want. That way you’re not creating 3 or 4 revisions for one small change.

There’s also a couple of people who include their initials with the log message. Although we used to really like having that information when we were using Contribute, we track your login when you make changes now, so there’s no need to also have your initials. Save a few keystrokes!

Finally, we’ve also open sourced a piece of our Drupal Migration. if you visit our GitHub page, you can find the source of our Migration Tracker, which kept track of the old and new URLs, and made it possible for us to migrate over several months, rather than needing to do it overnight.

A Static Server

As I may have blogged once or twice previously, making websites really fast is important to me. Recently, we’ve made a change that should help us improve the speed of not only www.lanecc.edu, but of many of Lane’s other websites, including this one.

When you request a webpage, in addition to fetching the page itself, you usually end up requesting each individual image, font, css sheet, and javascript sheet. Making those requests is expensive. There’s a sliding window, which limits how many requests you can make at once. So if the window size is 5, but you need to make 6 requests, you need to wait for one of the first 5 requests to finish before you can make the 6th. On the other hand, if you only need to make 5 requests, your browser can start rendering the page a lot sooner.

One way is to combine images into a css sprite. Here’s ours:

That’s 15 different images combined into one. And even though there’s empty space on the bottom right, it’s actually usually faster to fetch a slightly bigger image then it is to fetch each icon individually.

Another way is CSS and JavaScript aggregation. Most pages on our website have 35 CSS sheets and 35 JavaScript files – but after aggregation, you only end up requesting 7 of each (there’s reasons why 7 of each is better then just 1 CSS and 1 JS, but that’s outside the scope of what we’re doing here).

But the easiest way to speed up a request is to not make it at all. When you make a request, you send some request headers with it, that tell us things like if you’ll accept a compressed version and what language you prefer. Then we respond with a header that tells you how long you should keep our response cached on your computer. If you need that resource again before the expires time we gave you, you just use the local one, rather than fetching a new one.

In addition to sending headers with your request, and us sending different ones, we also send each other cookies.

A picture of some cookies — baked by https://www.flickr.com/photos/plutor/3646688/in/photostream/

Cookies are always set on a domain. When you log into Moodle, cookies are set on the domain classes.lanecc.edu, so Moodle knows on every page load that you’re logged in. But here, on the Lane website, we’re not so lucky, as you can actually use the website on either www.lanecc.edu, or on just lanecc.edu. So we set our cookies on .lanecc.edu. That little dot before lanecc.edu is critical. That tells your browser to send your cookies to all domains that end in lanecc.edu.

The downside is that those cookies are sent on every request to our domain – even requests that don’t need them, like the request your browser made to show you the picture of those cookies up there.

What does this have to do with static?

We’ve started moving relatively static (unchanging) resources, like the college logo and the megamenu onto the static asset server, which we’re putting on the domain static.lanecc.net. Since these resources are relatively unchanging, we can set a long expires time – maybe 30 or even 45 days in the future (for now, it’s set to 0minutes in the future, for testing). Once your browser has fetched them, you won’t need to fetch them again for a whole month. And because they’re not under the lanecc.edu domain, you won’t send any cookies (and we won’t send any back), making the few requests you do need to make even smaller.

If you’re really curious about the inner workings of our new static asset server, I’ve added some extra geeky content to the Our Tech Stack post.

In the months to come, we’ll keep migrating content onto the static asset server, trying to reuse resources between websites, so that the logo you see on myLane is served from the same URL as the logo you see in Moodle, reducing the number of requests you need to make, and making it simpler for us to update things in the future.

Last Deployment?

No, seriously. This will be the last deployment blog post you ever see.

Done today:

Telecomm

We also did a couple touchups in other areas of the site, correcting URLs and page titles,

In the upcoming weeks we’ll be looking through the areas of Drupal that migrating touched, trying to clean up some of the excess redirects and url alias’s we’ve developed. But as of right now, we’re done with the migration (check out the embedded graph in our progress page!)

Spelling, Internet Explorer, and Easier Linking

Currently, we use a plugin called LinkIt to handle linking between our pages (for a discussion of how we use it, see https://blogs.lanecc.edu/webteam/2013/02/05/common-pitfall-links/). LinkIt is pretty neat, and helpful. But it was always a pain for people to link to internal pages. We’d often get a scenario where someone wanted to link to some page, say, their department contact page. So they dutifully use LinkIt, and start searching for pages with titles like ‘contact’. But since every department has a contact page, they’d get fifty results and spend forever hunting for the right page.

Not helpful.

In fact, it was so unhelpful that people were directly pasting links to their pages into the page, meaning that when page titles changed, things started to 404, and things just got nasty. So I spent some time investigating why LinkIt couldn’t just figure out if a given URL is internal, and if so look up the node number and properly insert the link like a good little plugin.

Turns out the developers had already thought of this. Right there on line 388 there was a little todo that explained our problem. Like any responsible web site, we’re forcing page edits to happen on HTTPS. But for non-administrative users, we’re serving up most pages via HTTP (so we can take advantage of the speed our Varnish server provides us). So when an editor copied a link into LinkIt, the server would check the link (for example, ‘http://www.lanecc.edu/contact’) and see if the start of that link matched the scheme and server name of the current page. Since we’re forcing https, that’d end up being something like https://www.lanecc.edu/node/1337/edit. The server name matches, but the scheme doesn’t, and LinkIt would report that this link was external.

One simple change later, and now when you paste in a link it decides not to check the scheme. So from now on, if you’re linking to an internal page, just paste your url into the top box, and you’ll see something like this:

When that little green popup appears, simply click on it and LinkIt will automatically identify your node number and insert it as the target path. Click Insert Link, like normal, and you’re good to go.

The second change is that we got spell check working on Internet Explorer 9. For others with a similar problem, our issue was on Drupal 7, using TinyMCE 3.something, with the wysiwyg_spellcheck module and wysiwyg modules enabled. Turns out that when you enable the module, you also need to make some changes to wysiwyg/editors/tinymce.inc. In the function wysiwyg_tinymce_settings, you need to add add another key to the settings array:
'spellchecker_rpc_url' => '/libraries/tinymce/jscripts/tiny_mce/plugins/spellchecker/rpc.php',

You should, of course, adjust that path to whatever is appropriate for your site. One final note, the problem described with LinkIt is actually fixed in the new 7.x-3.x version. But we’re using the older, 7.x-2.x version, which is no longer in active development (and which has no migration path to 7.x-3.x)

More New Features

Two more new features to report.

First, you can now add a caption to your images. When you insert an image, as always, you’re prompted with a dialog where you can enter a title, and where you can enter a description. At the end of last week, we started automatically converting whatever you put in as the title of your image to be a caption, appearing in boldface just below the image.

It’s important that these two fields – title and description – are used correctly. When implementing this feature, we found close to two hundred images where they were exactly the same text. Imagine a screen reader comes across this picture:

Since both the alt text and the caption are the same, and it wants to make sure to read all the text to you, it’ll actually read the exact same thing to you twice! And don’t get me started with the people that used the file name (“cat123.jpg”) as the alt text, or even worse, the word “picture” as the alt text.

So what to do?

In a conversational blog post like this one, it’d be perfectly fair to make the alt text descriptive (“A cat, chewing on a monitor”), and to use an amusing title/caption (“Delicious!”). But if you have a more serious picture, say a picture of some people, you’re actually allowed to explicitly set the alt text to empty, since the description now lives on as a caption. That way the screen reader knows to skip the alt text and just read the text (caption) surrounding the picture. So if you have a picture of two people, Alice and Bob, you could make the alt text be “” (that’s literally what’s called an ’empty string’, meaning there’s nothing inside the quotes, but the quotes are present), and the title be “Pictured, left to right, Alice and Bob.”.

The second feature we’ve implemented is FAQ questions. If your department has, or would like a FAQ page, contact us for a quick crash course in how to use the FAQ module.