Take a look at these two sentences:

• You can read the post on the Web Team Blog.
• You can read the post at blogs.lanecc.edu/webteam/2013/12/13/search-engines/

Which is better?

Answer? the first one. There’s a couple reasons.

First, it turns out that descriptive text in links like this is actually really helpful for search engines to determine what’s on that page. So providing descriptive links can really help improve search.

Second, if you’re linking to another Lane page from within Drupal, if you use descriptive text you don’t need to worry about ever updating the link. We’ll take care of it for you. If you use the URL as your link text, then you might get a weird situation where the link text no longer matches the url you’re linking to – it says “lanecc.edu/science/bio” but you’re actually sent to “lanecc.edu/science/biology”.

Third, it simply looks better. No one wants to read long, ugly looking urls as part of their text.

“But wait,” you say, “what about when someone prints the page?”

We’ve thought of that. When you print a page from the Lane website, we automatically include the url next to the linked text. Of course, we’d rather you didn’t print web pages in the first place, but that’s a discussion for a different day.

Of course, there’s exceptions to this rule. Use common sense.

We’ve added a check to our linkchecker, so from here on out we’ll be actively hunting for these links. We’ll fix some of them for you, but we may also contact you for some help rewording your content.

As always, if you have any questions about best practices with content, send Lori an email.

Back when we first started the website redesign, we received a lot of feedback about how our search engine – https://search.lanecc.edu – didn’t work very well. Now most of our questions are about altering the behavior of the search engine to make it work differently. Over the next few posts, I’d like to explore what changed, as well as why not every request can be responded to, as well as dig a little bit into what you, as a Drupal editor, can do to improve how the search engine views your pages.

How does search work at Lane?

We use a Google Mini search engine, which allows us to index and search up to 50,000 documents. We have complete control over what pages are in our search (the “index”), and limited control over what’s shown in the results. Also, it’s blue, which is a nice contrast to the beige and black of most of the machines in the data center.

The first big change we made to search as part of the redesign was to upgrade our Google Mini, which we did in early 2012, switching to a brand new search server with upgraded hardware and software. We found a pretty immediate improvement – no longer did it feel like using an old search engine from ’05 or ’06, and instead it felt like using one from ’10 or ’11. Unfortunately, Google has discontinued the Mini, and there will be no further upgrades. We’ll need to find a new solution in the future (Apache Lucerne?).

Along came a migration

Then we started migrating pages to Drupal. This brought with it a bunch of new practices that we’ll get into some other time, but all of which dramatically increased the relevance of search. The down side is that we changed virtually all of the URLs for pages on lanecc.edu (Yes Sir Tim, I know it was a bad idea). While we’ll hopefully never need to do this again, it meant there was some confusion in the results for a while.

The migration also meant that we cut a lot of pages. More than 10,000 of them. Enough pages that cutting them significantly changed how the mini calculated page rank. We’re still removing these from the search index. It’s a slow process, since we don’t want to delete more than one or two folders worth of files each day, so that if someone was still depending on a page or image that didn’t get migrated, it won’t be as hard to get that person their missing files.

Reset

Since the mini wasn’t removing pages that had long since disappeared, we decided to reset our search index. This is pretty much what it sounds like. We tell the mini to forget about all the pages it knows, and start over from the beginning. When we did this last, around Thanksgiving, our document count in the index went from about 40,000 all the way down to 16,000. We think results improved quite a bit.

We’ll reset again around Christmas, which is traditionally one of the slowest days on the website. Hopefully that’ll bring the document count down even more, and make results even better.

Biasing

At the same time as our last reset, I figured out that I’d been using Results Biasing incorrectly. Results Biasing is a way that we an introduce rules into the search engine to influence the results. Our first rule tells the mini to significantly decrease the pagerank of urls that end with xls or xlsx, under the assumption that when you’re searching Lane, you’re probably not interested in some Excel sheet.

I thought that by simply entering rules in the Results Biasing page on the mini administrative interface, I was affecting the search results. Turns out this isn’t actually true. There’s a second radio button to hit on the Frontend Filter, where you actually enable Result Biasing on the collection that frontend is searching. What are containers and frontends? A container is a collections of urls that match certain patterns. For example, we have a container of just pages that match pages related to our COPPS pages, and another just for the Library. Frontends are the user interface to those collections, where you can customize what the search button says, what the background color of the results is, etc. You can use any front end with any collection, but in our case each frontend belongs to just one collection.

Feedback

The other big thing we did to our search was to add a feedback form in the bottom right hand corner of the search results page. To date we’ve had 40 people let us know about their  searches that didn’t get them the results they needed. Many of those have resulted in us making a tweak to the search engine, either adding pages to the index, or adding a KeyMatch, or fixing something on the page to improve its visibility.

Feedback has started to taper some, while queries have stayed steady (if you adjust for changes in enrollment), so our assumption is that search is working pretty well. If it isn’t, please submit some feedback!

Next time

Now that we’ve got some basics out of the way, next time we can dig into how search engines calculate results (If you’d like some homework, here’s a bit of light reading), as well as more of what we can do to influence those results.

On some Drupal pages, there’s links to department social media on the left hand sidebar, right at the bottom of the navigation menu (for an example, check out the Marketing and Public Relations site). Recently, we’ve added a few more social media options that you can add to your website. The whole list of options is:

• Blogs
• Facebook
• Flickr
• GooglePlus
• Instagram
• LinkedIn
• Pinterest
• Twitter
• Tumblr
• YouTube

If you don’t currently have permission to add social media sites to your department’s pages, talk to Lori about becoming an advanced content editor. And if there’s any other social media sites that you think we’re missing, let us know.

As always, make sure to follow the Social Media Standards!

Recently we updated our link checking script to hunt for some common mistakes in image alt text.

As you may recall from your initial Drupal training, alt text is very important for accessibility, as it’s the text that’s read to the visually impaired to describe what’s in the image. Close your eyes for a second and pretend whatever you put in the alt text is being read to you. Is what’s being read so short that it’s meaningless? So long that you get bored just listening to it? Does it repeat something that you already say in the text, making it redundant?

But we’re interested in even worse problems today. Sometimes people put in alt text that doesn’t event attempt to describe the image. For example, some people use the file name as the alt text. Like this:

<img src="/img/spacer.gif"> 
If you were using a screen reader, your software would get to that image and read you “dog dot p n g”, which is summarily unhelpful. Reading the file name won’t help anyone better understand what’s in that image. Also unhelpful is this:
<img src="/img/spacer.gif"> 
which we haven’t seen recently, but has come up in the past. That’d just cause the program to attempt to read goldenRetrieverPuppy as a word, possibly completely unintelligibly.
And then some people are just lazy:
<img src="/img/spacer.gif"> 
Completely unhelpful.
Remember, for us (as it should be for everyone) being accessible isn’t optional. Starting today, we’ll be scanning for these errors automatically, and emailing content editors that need to touch up their alt tags a bit.
 
					

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!)

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, ‘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)

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:

A cat chewing on a monitor

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.

Over the last year, one feature we’ve heard requested over and over again is the ability to save a draft of your content and come back to it later. This last weekend we finally got it working, using a module called Workbench Moderation.

This module actually makes some pretty significant changes for everyone, even if you never use drafts, so let’s take a look.

The most easily noticed changes are the tabs along the top of pages you edit. The first one, “View Published”, is the same as the old “View” tab. You’d use this tab to see the content that the world currently sees. The second tab, “New Draft”, replaces the “Edit” tab. The last change is the new “Moderate” tab, which replaces the old “Revisions” tab.

For most people, your workflow shouldn’t really change. When you want to make an edit, click “New Draft”, make your changes, enter your revision message, and click save.

But if you’d like to save your work for later, click on the “Revision Information” horizontal tab at the bottom of the page. Below the log message you’ll find a dropdown showing three states: Draft, Needs Review, and Published.

If you set your Moderation State to “Draft”, and click Save, Drupal will make a draft for you. Alternatively, you could set your state to “Needs Review”. This is an intermediate state – you’re no longer making changes to it, but you need someone else to take a look at it before you publish it.

You can manage the states of your page using the Moderate tab:

This is a bit confusing at first, but it makes sense after you’re used to it. The top entry is the current revision of this node – the one that’s been saved as a draft. If you’d like to change it to Needs Review or to publish it, you can use the dropdown on the right hand side. The second entry is the currently published version – the one everyone sees.

The second big change we made was to the forms module, where we upgraded four minor versions. On the webform tabs, you’ll see some extra options for your forms, including the ability to add a progress bar on multipage forms. You should also see improved handling of unicode characters (non-latin alphabet) and better Excel exports.

If you’re a content editor, expect an email with further details soon. And, as always, if you’d like more information about forms or draft, just email Lori.

The other day we launched our last major deployment:

• IT & Academic Technology

With that, we’re now 99.86% complete. Now we can start the long process of making absolutely sure that it’s ok to turn off the old server.

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?