Web Team goals for 17-18

It’s the end of the academic year, which means it’s time to start thinking about goals for next year. Our first set of goals will be similar to our goals from last year:

  1. Reduce the total number of pages on the Lane website by 5% (from 5550 to 5273)
  2. Reduce the number of pages with more than 15,000 characters by 10% (from 249 to 224)
  3. Reduce the average character count of our pages by 10% (from 4650 to 4185)
  4. Improve the average age of our pages (the average late updated date) by 4 months (from 16 months to 12 months)

We’re also going to add two goals relate to page use:

  1. Increase session counts for www.lanecc.edu during the period 6/14/17-6/14/18 compared to the previous year by 5%, from 3,228,904 to 3,390,349
  2. Decrease the bounce rate for www.lanecc.edu during the period 6/14/17-6/14/18 compared to the previous year by 5%, from 37.05% to 35.19%

We’ve never had page use goals like that, so this will be interesting for us as we really dig into how to increase engagement and findability of our pages.

If you’d like to help us meet our goals, just edit your pages! We’ve made a lot of progress in making our pages more recent – many pages used to be over two years old! We’re happy to help. Just email Lori and she’ll get you pointed in the right direction.

Using all Capital Letters

An instructor asked me the other day, “How does a screen reader read text in ALL CAPITAL LETTERS?”

I didn’t know, and through it was a great question, and had to figure it out. Let’s start with some sample text:

It’s VERY important you remember these:

  • USPS
  • NASA
  • DVD

There’s four words in all caps there. Let’s look at each one, from the bottom to the top:

DVD is an initialism, meaning you read each letter in it, like CPU or FBI. NASA is an acronym, meaning you read it as a word, even though each letter stands for a word. USPS is another initialism. But VERY is just a word, with all capital letters being used for emphasis.

Of course, it’s wrong to use capital letters in this way – you should instead be using an em or strong tag (though which one is complex, and I didn’t find the examples in the specification very helpful). But the instructor’s question wasn’t about what should happen, it was about what does happen. How can a screen reader know which of those words it should treat as words or acronyms (which are like words, in terms of pronunciation), and which it should treat as initialism (and read letters instead of the word)?

I ran each of the examples through the say program on my Mac, and here’s what I got (sentence case was pronounced like lowercase):

Word Uppercase Lowercase
Very word word
USPS letters word
NASA word word
DVD letters letters

There’s some interesting logic there. I think this table shows my Mac will always read dictionary words as words (like “very”). And I think it shows that my Mac also has a list of known acronyms and initialisms, so it knows how to read those. For words that aren’t in either list, but also aren’t in the dictionary (like USPS), it reads all capital letters as initialisms, but lowercase as a word (a reasonable assumption, since most of the time it encounters words that aren’t in the dictionary, it’s probably due to the lang attribute not being set correctly.

Of course, this is just say on my Mac, which isn’t even a screen reader. WebAIM has some general rules for how screen readers read things, but it isn’t really predictable how a screen reader is going to pronounce words in all capitals. Pronouncing typographic symbols is hit or miss as well — some, like @ and % are read correctly. But most others (like the parenthesis, or the mdash in the previous sentence) aren’t read universally. Rare punctuation, like the interrobang (‽) may not be read at all.

I was hoping that abbr would influence how screen readers pronounce words, but that doesn’t appear to be the case (and, if you’ve been around HTML for a while, remember you’re not supposed to use acronym at all — though it probably wouldn’t do anything here anyway).

What does this mean for you at Lane?

Use the abbr tag to specify acronyms and initialisms if possible. Even though screen readers won’t necessarily change how they handle pronunciation, abbr with a title attribute makes it easier for anyone to understand meaning. Try hovering over this: NASA.

If you want to use capital letters for emphasis: don’t. Instead, use either an em or a strong tag, depending on if you’re trying to emphasize something or make it note that it’s more important than surrounding text. And, of course, never use strong in place of a header.

If you want to use capital letter for aesthetic reasons, then you should use a bit of CSS to make it happen:

.all-caps {
  text-transform: uppercase;

Screen readers ignore CSS, so this use is entirely for presentation. Just make sure you don’t confuse presentation with meaning.

I ran a quick search on our website for pages that have a lot of capital letters all in a row:

SELECT entity_id
FROM   field_data_body
WHERE  body_value REGEXP BINARY '[A-Z ]{10}';

There were 748 results. Editing 748 pages obviously won’t happen overnight, and on each one we’ll need to determine if we should instead be using a header, a strong, an em, or just normal text. For now, I’ve queued a task for us to tackle in the future, but if you’re editing your page and notice some misuse of capital letters, we’d be forever appreciative if you’d fix it.

Closing out the year for the Web Team

If you’ll recall from our original goals post, or the update that followed, we had a few goals on the web team the last two months of the year:

  1. Reduce the total number of pages on the Lane website by 5% (from 5768 to 5475).
  2. Reduce the number of pages with more than 20,000 characters by 20% (from 193 to 155)
  3. Reduce the average character count of our pages by 10.5%, from 4803 to 4300.
  4. improve the average age of our pages by 6 months, from roughly 24 months old to 18 months old.

I’m very sorry to report that while we made a lot of progress, we were unable to meet any of our four goals. Here’s the graphs:

Node Count Graph, showing progress from 5768 to 5557We were able to make some progress eliminating nodes even in December, but things slowed down. Part of that is because with so many people on vacation around the holidays, it’s difficult to get permission to delete a page. We’d been shooting for a 5% reduction, but we were only able to get 3.5%.

Graph of nodes wiht more than 20k characters, showing progress from193 to 172As mentioned in the previous goals post, it turns out that many of these really long nodes are pages that are really hard to reduce, like board meeting minutes or transcripts of in-service addresses. I reviewed almost every page and removed a lot of really bad markup: things that we should have removed when initially porting pages to Drupal, boldfaced text that should have been headers, HR tags used improperly, and so very, very many   characters. We’ll tackle some of those in a future post.

We’d been looking to make a 20% improvement, but we only managed 10.8%.

Graph of average length of our pages, showing no progress in the last month.Average length was really depressing for me, especially as I’d update statistics after working on these goals for a few hours. I might spend two hours meticulously working my way through the list of really long nodes, since they’d help us meet this goal the most. And I might see a visible improvement on the body length graph. But then I’d work on eliminating some nodes, and inevitably those nodes would be really short, meaning our average body length would go right back up.

Still, we made some gains early on, and the site as a whole is improved. We’d been shooting for a 10.5% reduction, but we only made a depressing 2% improvement – about 100 characters.

Average Age, showing steady progress along our trend lineWe probably made the most progress on this goal, but our failure to make progress early in November really hurt us. Over the two months we tried to meet our goals, pages got about four months newer.

We tried to meet this goal primarily by updating our oldest pages.

Count of pages at least four years old, showing progress from 732 to 513We substantially reduced our really old pages. And while it’s great we made that progress, since we hate ROT, it just wasn’t enough for us to meet our goal.

We still have lots of tasks queued up in Basecamp for us to do related to content, that we just didn’t have time to get to as part of this challenge including reworking some tables that are used improperly, removing even more HR’s, fixing some pages that are using redundant text blocks, eliminating duplicated pages, adding headers, removing improper use of the • character (people use it for bullets, but they should be using the bullet tool), and figuring out what to do with pages where people wrote “check back for content soon” several years ago. So we expect to make more progress in the coming months.

A special things to everyone who helped out with our goals. Here are the ten champions of the last two months, who made the most edits on the site, helping us toward our goals:

Name Number of Revisions
Lori Brenden 545
Kyle Schmidt 179
Amy G 132
Emily M 91
Tammy S 58
Elizabeth P 41
Melanie B 39
Joan A 31
Wendy S 30
Penny M 27

Happy New Year everyone!

Web Goals check-in

As promised in our initial goals post, a month as passed and now it’s time to check-in and see where we are on meeting our goals. As a review, those goals were:

  1. Reduce the total number of pages on the Lane website by 5% (from 5768 to 5475).
  2. Reduce the number of pages with more than 20,000 characters by 20% (from 193 to 155)
  3. Reduce the average character count of our pages by 10.5%, from 4803 to 4300.
  4. improve the average age of our pages by 6 months, from roughly 24 months old to 18 months old.

Let’s take a look in order, along with some graphs. On each of these graphs, the straight line is the trend line – in order to keep on track for our goal, we need that line to be below the trend line.

Reduce the total number of pages on the Lane website by 5% (from 5768 to 5475)

Clearly, we’re running behind – the count as of today is 5737, about 110 more than we’d hope to have. It turns out that removing pages is really hard. While we’ve removed some things to our archive, we’re fighting an uphill battle as things like news releases and meeting minutes get added.

Reduce the number of pages with more than 20,000 characters by 20% (from 193 to 155)

We’re making progress on this one, but again, it turns out to be really hard. We have 185 nodes with more than 20,000 characters, but we were looking to only have 174 this week. Many of the pages that are really long are actually Board Minutes, which we don’t delete and can’t shorten. Right now we’re optimistic we’ll still find enough pages to fix, but this will be hard.

Reduce the average character count of our pages by 10.5%, from 4803 to 4300.

Although we’ve managed to improve from 4803 characters to 4706, we’re still 150 characters over where we wanted to be. Again, it turns out the board minutes are in large part to blame. But we’re still optimistic.

Improve the average age of our pages by 6 months, from roughly 24 months old to 18 months old.

We came closest on this one. At the start of last month, our average page had last been edited on 11/12/14. Now, that date is 2/3/15 – almost three months newer. That’s a lot of page edits. But we’re still two weeks behind our goal for today, which was 2/21/15.

When tackling this goal, we had a separate subgoal to reduce the number of pages we have that have gone more than four years without an edit. Lori’s done a lot of work on this list, reducing the number of pages on it from 732 to 612, which makes a pretty impressive graph:

Surprisingly, despite all that effort on our very oldest nodes, it wasn’t enough. But we have a month to go, so there’s still some time. We’ll check in again on January 1st!


Goals for 2017 on the web

There’s two months left in 2016, and the web team wanted to set a couple goals for the Lane website before we close out the year. An important part of our mission is to keep our pages as readable and relevant to our visitors as possible. One way to do that is to prevent and remove ROT – redundant, outdated, or trivial content on the web.

Redundant Content

Redundant content is dangerous content. If the same content appears in multiple places online, it’s only a matter of time until only one place is updated and the content is out of sync. Then we’re providing conflicting messages. Beyond that, redundant content makes it confusing for search engines to know which pages to serve. Pages are scored by search engines primarily by the number of other pages that link to them.

Here’s a (super simplified) scenario. Say we have two different places that describe our refund policies, and both of those pages link to the same page of meeting notes about changing those policies. Sites, both internal (on the www.lanecc.edu site) and external (including sites run by other organizations, but also places like moodle), link to a page on refund policy. But some link to the first place, and others link to the second page. When you search for refund policies, what do you get in your results?

We can’t be sure – and you might even get the PDF, because it’s getting some page rank from each of the two other pages. But if we had that content on just one page, everyone would link to it correctly, letting search engines value it correctly and making search better for everyone.

Outdated Content

That outdated content is an issue should be obvious, but even content that’s just several years old and no longer relevant can be an issue. We have 732 pages that haven’t been updated in over 4 years. Some of that content has certainly changed since then, and is now incorrect. It’s going to be a tremendous effort for us to go through and figure out which of those pages need updating, and which can just be removed.

Trivial Content

Trivial content is a difficult one. It might be content that you find really important – say, a photo album of an event a few years ago. But if that content isn’t helping the mission of your site and of the website as a whole and isn’t required to be there by law or by grant conditions, ultimately it’s trivial and should probably be removed..

Trivial content doesn’t need to be an entire page. Sometimes it’s just a line, like “Welcome to the Underwater Basketweaving Department!” that purports to make the department look friendly but falls flat. This excess content confuses search, and makes it dififcult for people to find what they need, ultimately leading people to feel like website is cluttered and difficult to navigate.

Long Content

We also have a problem with content length on our site. Sometimes pages are necessarily long, like COPPS policies (though there’s certainly some of those that could use help!). But often pages are so long they make it difficult to find what you need. Due to the way we store our pages, I don’t have an easy way to count words on pages, but I can count letters. These aren’t perfect counts, because they include some of the HTML that helps to style the page, but they’re a great estimate. I did a count of our pages last night and found some crazy pages: 50,000 characters. 80,000 characters. 90,000 characters. If we use an average of 6 letters per word, that’s as much as 15,000 words on a page! Positively insane. How can students find what they need?

Our Goals

As editors on the website, we’re enlisting you for help! Here’s the goals we’d love you to help us meet this year:

  1. Reduce the total number of pages on the Lane website by 5% (from 5768 to 5475).
  2. Reduce the number of pages with more than 20,000 characters by 20% (from 193 to 155)
  3. Reduce the average character count of our pages by 10.5%, from 4803 to 4300.
  4. improve the average age of our pages by 6 months, from roughly 24 months old to 18 months old.

Except for the total page count, these goals and statistics are actually calculated against what we call a “basic page”. So these don’t include news releases, COPPS pages, or the landing pages.

On December 1st, we’ll post an update with how we’re doing on each of the goals, then check in again on January 1st to see if we met them.

And of course, if you need any help getting back into editing your pages, let us know! Just contact Lori, Jim, or me and we’ll be happy to help.


Twitter Cards and Open Graph

Across the Internet, Social Media now drives almost a third of all visits to pages. At Lane, that number is substantially lower: on our main website, it’s just 1%. One way to increase the number of people who click our links in social media (our click-through rate) is to improve our link copy and picture to make our posts more readily grab people’s attention.

This blog post is going to demonstrate two ways to do that. Though we’re going to be discussing ways to customize how your link is shared, we’ve set up defaults to improve how all pages look when shared, without you having to do anything at all. But a couple minutes of work will go a long way to making your shared link stand out.

Open Graph

The behemoth of social media is, of course, Facebook, so we’ll start there. Facebook developed a standard called Open Graph, which is a way to add hidden tags that tell Facebook, Google+, LinkedIn, and others how to share your page. Let’s take a look at what it looks like when we share a link on Facebook:

Facebook share window.

A similar preview box will show up when you share a link on LinkedIn or Google+.

If you’re a social media user*, you’ll now have an extra horizontal tab down at the bottom of your edit page, called “Megatags”. If you click on that, you’ll see two blue links: Open Graph and Twitter Cards. Let’s click on Open Graph and take a look.

Drupal Metatags tab. Relevant fields are further explained in the following text

Content Title

The first field in there, Content Title, is the only one that’s absolutely mandatory. Since it’s mandatory, by default we tell it to use the page’s title (that’s what [node:title] means).

A small digression: titles within Open Graph aren’t quite the same as titles on the Lane website. On the Lane website, we automatically add the department name and college name to the end of the title. So a page that says it’s title is “Contact” would actually have a title like “Contact | Science Division | Lane Community College”. That works no the web, where you want to show hierarchy. But in social media, that’s a title everyone is going to skip right over.

Open Graph titles are probably better thought of as headlines. Think back to that first picture we had – the title in that picture was “About”. That might be a good website title, but “About” is a terrible headline. We want something that’s going to catch people’s attention, and give them a reason to read a little bit further down. So let’s change it. We’ll instead use “Ready to learn more about Lane?”


The next field, image, is probably your best opportunity to get attention. Facebook will always pick an image on the page, but sometimes you can do better. If you’d like to tell a social network what image to use, add it in here. If you’re not sure how to find the full url for an image, get in touch with us by emailing webmaster@lanecc.edu.

We’re going to leave the image in our example alone, since Facebook chose a pretty good image for us.


Open Graph has one more important field, the description. But rather than ask you to type in a description all over again, we’re going to make use of a field that you may not have known you’ve had access to all along. If you’ve ever looked at the optional fields tab, you may have seen something like this:

Our optionl files tab, which included a field named 'search engine summary'

The search engine summary field provides a meta description tag, which Google and other search engines use as a snippet in search results. We use the same tag for Open Graph. If you’ve left it empty (like we have in our example) Google, Facebook, and others will create a description for you. Here’s what Google creates:

text is cut off, but reads: Lane offers many different educational opportunities–we truly have something for everyone! students by clock tower at main campus bus station As the third

The text in black is Google’s preview for the page. But it doesn’t make any sense –  “students by the clock tower” comes out of nowhere. That’s because Google is using the alt text from a photograph as part of the description. Let’s put in a new description so Google doesn’t do that. As a rule of thumb, you want a couple of keywords that people might be searching for, and you want to keep under 160 characters. We’ll use “Explore transfer and career & technical opportunities at Lane Community College in Eugene, Florence, Cottage Grove, and online”.

With those fields updated, here’s what the page will now look like when it’s shared:

Updated facebook post, featuring the text we'd talked about earlier

Better, right? Two caches. First, you’ll notice only part of the description showed up. That makes writing descriptions tricky. Facebook shows fewer characters than Google does. So if you can, keep the important parts of your description in the beginning. Second, after you make these changes, it takes Facebook as much as a day to recognize the updates. But you can force it, if you’d like. Enter the URL you’re going to share on Facebook on their debugger. Facebook will tell you when the last time was it took a snapshot of the page. If that snap shot is from before you made your changes, you can ask Facebook to crawl it again.

Twitter Cards

Twitter doesn’t use the same Open Graph standard that most other social networks use. Instead, it uses something called Twitter Cards. There’s two primary types of cards we’re interested in: the summary card and the summary card with large image. The only real difference between the two is the size of the image.

With the summary card, your image should be square, and a minimum of 120x120px. With the summary card with large image, your image should be rectangular, and at least 280x150px. It’s important you use as appealing of an image as possible, as it’s what’s going to make your post stand out best. By default, Twitter will use the Lane logo, but their guidelines state they don’t want the same image to be used repeatedly.

Setting up your Twitter card is much like setting up Open Graph. Click the Twitter card link, set the title and image, and make sure you’ve already set the SEO summary under the Optional Fields tab. Then, when shared on social media, you’ll see a card, like this:

Sample Twitter card, containing the text from earlier, in an attractive presentation on Twitter.

If you’d like a preview, you can use the card validator on the Twitter site.

One Caveat

For good reason, we don’t allow you to set these fields on pages you don’t control. So the editor of the science page can’t set the description of the math page. So if you’re going to be sharing a link for a page and you notice a problem with one of these fields, or you think the page could really use a better picture, email us at webmaster@lanecc.edu and let us know. We’ll take care of setting the meta tags to make sure everyone has a great shared link experience.

* Not sure if you’re a social media user? If you see an error message when you click on this link and log in, you’re not. But if you see a list of the sites you manage, you’re a social media user! If you’d like to become a social media user, check the Drupal dashboard for a list of upcoming training opportunities.


Click to Expand

A few days ago, an astute employee over in Enrollment Services pointed out that our steps to enroll pages weren’t completely accessible to the blind. This is an important problem, and a surprisingly tricky one.

The current legal requirements for web accessibility (including §1194.22, which we’re most interested in) are referred to as Section 508. These standards provide some useful guidance on how to help folks with an impairment of some kind. For instance, they describe how images should have an alt text field, except for when that image doesn’t support understanding of the content (e.g. a background or filler image).

On the other hand, these standards are now old enough to vote, meaning they’re older than Facebook, Twitter, selfie sticks, Google Chrome, iPhones, the Columbus Blue Jackets, and Windows XP. Needless to say, they’re showing their age.

There’s no way to make click to expand text accessible under current 508 guidelines. Our best option would be to duplicate the page and provide a text only version. Unfortunately, that could lead to a screenreader having to read a lot of unnecessary text.

The solution relies in the proposed new standards. These are still in progress, but the web community is confident they’re going to heavily include something called WAI-ARIA. WAI-ARIA provides a way to mark up your pages with extra attributes that screen readers know how to recognize, so the blind can better use interactive pages.

Returning to our original problem, starting this evening we’re now using the hide-show accessible plugin on those pages. This plugin lets you write some fairly simple markup in your page which will then get converted to a click to expand box like on the steps to enroll.

To use, you’ll first want to click the blue link below the edit box in Drupal that says “disable rich text”. Then, if you want a simple button with some text below it, you’ll want to paste this in:

 <p class="js-expandmore">Click on me</p>
 <div class="js-to_expand">
     here is the hidden content!

Then replace “Click on me” and “to show me!” with whatever works for your page. You’ll get something like this:

plus sign with some latin text that'd normally be clickable

And when you click to expand, you’ll see this:

minus sign, with the same text as before, but now with more text shown below it

If you’d like a little bit of color, you can also use an h3 element, which would place that text in an orange box:

    <h2 class="js-expandmore">Lorem dolor si amet</h2>
    <div class="js-to_expand">
       here is the hidden content

Exactly the same as before, but now it’ll look like this:

same plus with text, but now with an orange background

This is actually the more correct use – you nearly always want to use an h element of some kind when it describes the text after it.

For really advanced use, you can also add a full class to make the button full width. Or you can add the blue class to make the orange background blue instead. Or both!

    <h3 class="js-expandmore blue full">Lorem dolor si amet</h2>
    <div class="js-to_expand">
       here is the hidden content

would look like this:

blue background, full width, with same plus and text

This is definitely getting into advanced content editing in Drupal, so if you’re stuck don’t hesitate to contact us at webmaster@lanecc.edu.

Remember, we should always try to use the right tool. For instance, these kinds of show and hide buttons might seem like they’d be perfect for an FAQ. But we already have a different setup for FAQ questions, that takes care of alphabetizing and tracking changes to each question. And remember that many of the visitors to your page won’t bother clicking the button at all. Always spend time simplifying your content to make sure the important message is apparent even without clicking to show your other text.

Writing for Readability and SEO

This is the last post in a series about rewriting content. Though you’re welcome to read it by itself, you might want to read the first four posts first: One, Two, Three, and Four.

Now that we’ve fixed our page so that it’s easier to read, we need to make sure it’s easy to find. When we talk about making things easy to find, we really mean making them easy to find by Google, as more people find our content on the website via Google than they do any other source. Writing easy to find content is one aspect of Search Engine Optimization, or SEO.

Writing for SEO

Soon, we’ll be adding a new tool to the Drupal edit interface to help you perform a keyword analysis. To use it, you’ll simply edit a page, then scroll all the way to the bottom:

The Drupal content analysis box

After we turn it on, if your user has the correct role, you’ll see that Content analysis tab. Let’s start with doing a Quick SEO analysis, and put a phrase in the box. I’ll use “Where to print”, since that’s something I think people might google to find out where to print. Then click the button.

Content Analysis Results page

Your results will pop over the page, and be very hard to miss. But don’t worry – if you accidentally close that popover, the results will still be in the page. Let’s look at each of the sections in the results.

Page Title – The title is probably the most important place to put important keywords, but it’s important not to make it too long. Our current title is “TitanPrint”. That’s also something that people might google, especially as we try to message out about TitanPrint. So I’m ok with it, and we’ll leave this alone.

Body – The body is the second best place to put your important keywords and phrases. We’re missing my phrase entirely. So I should probably fix that. Let’s rework the second to last sentence:

You can use your print allocation at locations around campus.

And instead we can write:

Curious where to print? View print locations to across campus.

And of course we’ll link print locations to to the proper page.

Meta Keywords – We don’t use these. They’re generally ignored.

Meta Description – When you search for something, Google helpfully tries to use a snippet of the page to give you a preview of what’s on the page. If you’re finding that snippet to be unhelpful, you can enter a description that Google may use instead. If you’d like to enter one, check under the “Optional Fields” tab at the bottom of the page, and fill out the Search Engine Summary field.


In the popover, there was another tab labeled readability, which provides a series of different reading level scores. Depending on your content these may vary wildly, so it’s usually best to just use the average.

The reading level content analysis interface

Our reading level has an average of 8.3 – pretty close to what HemingwayApp told us. This interface isn’t as friendly as HemingwayApp, and doesn’t provide live feedback, but it saves you a lot of copying and pasting, so we encourage you to give it a try.

That’s it!

We’re almost done testing content analysis, so hopefully by the time you read this post you’ll be able to use it. If you have any trouble finding it, or using any of the tools we’ve covered in these posts, please, please, please contact us at webmaster@lanecc.edu and we’ll help you out. Also don’t hesitate to contact us for additional help with SEO – we have a bunch of information from Google Analytics that we’d be happy to share.

And be on the lookout for some upcoming sessions where we rework some content together, live, in person. Keep checking the announcements box on the Drupal dashboard right after you log in.

Call to Actions

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

Picture of a link on the page

to this:

Picture of an Orange Call to Action Button

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

Picture of a Blue Call to Action Button

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?

Screenshot of the CAS login screen

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!