Lane Community College Web Team

Filehost has been upgraded to OwnCloud 7

Filehost has been upgraded to the latest version of OwnCloud. Here’s a very brief overview of some of the changes:

Responsive UI. Now it won’t look so bad when you are browsing the web ui on your phone or tablet.
The left nav bar is now a drop down that appears when you click the menu to the right of the OwnCloud cloud icon.
There is now a sidebar on the left that makes it much easier to figure out the status of your shared files.
To find the webdav link, just click the gear icon in the bottom left corner.
There are now limited odt and doc editing capabilities. Very limited. Just select Documents in the nav menu.

I’d also encourage you to check and update your sync clients if there’s an update available.

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.

New Changes to the Employee Directory

This is just a quick post to point you to the new changes available when you edit your employee directory profile.

First, the office hours field has received a WYSIWYG editor. That should make it much easier to format your hours.

Second, we have added a new Professional Biography field. Basically, it’s a place where you can add extra information about yourself that will help students and your fellow employees accomplish what they need to here at Lane Community College.

I’d also like to note that a most people have no picture in the directory. It’s really easy to add a picture, so I’d encourage you to do so!

In case you’ve forgotten, the link to log into the directory is in the footer of every directory page. It’s labeled “Edit/View your Directory Profile.” Only employees who are in the directory can log in.

Announcing Filehost: Lane’s very own internal cloud storage!

As of right now, every single active Lane Community College employee has access to their own https://filehost.lanecc.edu account. They just have to log in with their normal L# and passphrase combination.

What is it?

Filehost is a Lane specific file syncing and sharing service, running on an application called OwnCloud. It is a service very similar to Dropbox, you could almost call it a clone. OwnCloud is an open source application that we manage ourselves, on our own hardware.

OwnCloud’s sync apps keep your files synced across almost any device you have, Mac, Windows, Android, or iOS. To manage sharing files, and single file uploads, there is a web interface accessible from any modern browser.

Details about the service

Log in information:

Filehost log in screen

Location: https://filehost.lanecc.edu
Username: Your MyLane/Moodle L-Number
Passphrase: Your MyLane/Moodle passphrase

Other information:

How much you can store: 10GB
If you need more storage, contact the ATC.
If you had more than that in your current Media Server account, your space should already have been expanded.
Filehost internally saves deleted files for a time. Don’t rely on it, though.
Backups are completed daily and stored for 14 days. If you need something restored that is not in your deleted files section, contact the ATC with the path to your file, and your L-Number.

How could you use it?

Share a folder with contents from a project between everyone who is working on that project.
Embed an image, mp3, or video in a Moodle course.
Share a password protected directory with your students.
Keep your Lane related projects synced between your home computer and your work computer, all without involving third party services like Dropbox or Google.

Wait a sec, what about the Media Server?

Embedding media in Moodle courses and sharing folders with students is something already provided by the media.lanecc.edu server. Thus, a really good question arises. Why not just use the Media Server?

The answer: As soon as we can do so without causing instructors and students a lot of problems, we will be retiring the Media Server from service. Don’t panic, you will not be losing any data, and we will make sure to let you know of any major changes before the changes actually occur.

Why retire the Media Server?

The main reason we are retiring it, boils down to security. The Media Server runs on software that is not easily upgraded. Thus, when that software releases a security update, it can take a while for us to get that update applied to the Media Server.

So far we have not had any problems. But, prevention is a much better method than having to fix things after we’ve been hit. So, what we need to do is move the Media Server to a platform that is easily updated. That platform is Filehost.

We also want to provide a better user experience. The Media Server is only accessible with a FTP client. FTP clients are not all that easy to use. The ATC frequently has to help users with them.

Even just the initial set up of a Media Server account is a bad experience on both sides of the system. The user has to talk to the ATC, the ATC has to talk to the sysadmin, the sysadmin has to set the account up, and then the ATC has to talk to the user again. The way Filehost just lets you log in if you’re an active employee, is much better.

Password protecting files on the Media Server is so painful, we stopped telling people we could do it.

All in all, retiring the Media Server will give users a better experience, and make maintenance issues simpler. It’s a win-win for both users and supporters.

What about my Media Server account?

File access

If you have a current Media Server account, you can already access and manage your files through Filehost. If you log into Filehost, you will see a directory call “mediaserver”. That directory contains the exact same content as you would see in your ftp client. Uploading/deleting files via Filehost does exactly the same thing as if you did so via your FTP client.

At this point in time, you are strongly urged to use Filehost for all Media Server file management. If you have issues, contact the ATC.

Eventually we will turn off FTP client access to Media Server files. Of course, we’ll give you plenty of notice beforehand, and you will always be able to manage your files via Filehost.

media.lanecc.edu urls

We currently plan on keeping your media.lanecc.edu urls working, even after FTP client access is turned off. The complicated part is that we would like to eventually retire the media.lanecc.edu urls and free up media.lanecc.edu for other uses.

Of course, that would mean a bunch of your links would stop working. So we have to figure out how to turn off the urls without causing you a lot of problems. We’re still figuring that out.

Rest assured, if we ever do figure it out, we will give you plenty of notice.

For now, your URLs will keep working the way they always have.

All that said, it would be awesome if you’d start switching all your links to Media Server files over to links from Filehost. In the long run, sharing via Filehost will provide more features than anything the Media Server urls can do.

Gotchas

If you are running a website in your Media Server account, then sharing the mediaserver folder in Filehost, could open up security issues. Specifically, the way Filehost shares folders would enable people to download your site files. Including any dynamic scripts or other files. So, if you have a website on the Media Server, do NOT share the mediaserver folder in Filehost.

If we do retire media.lanecc.edu URLs, then all sites hosted on the Media Server will cease functioning. Filehost only serves files. It cannot serve websites. If you need a website hosted on Lane servers for functionality not provided by Moodle or blogs.lanecc.edu, then come talk to us. We do have a solution for you.

Usage Guidelines

Resources at Lane are not infinite. No matter how much we try to make them so. Thus, we ask that you only store college related files on Filehost. Please do not store personal music, pictures, books, etc.

We’d also ask that you make sure to share all your files with appropriate people. In the event you are unable to work, we don’t want essential files trapped in your account when your backup person needs them.

(Side note: in development is a way to share with groups of people, it’s still buggy right now, so we aren’t releasing it, but in the future you’ll be able to share with your whole department at once, instead of selecting each individual member by name.)

Conclusion

Filehost is an awesome new service that should help increase productivity. We hope you enjoy it!

Resources

IE8 Support Discontinued

Last month, for the first time ever, Internet Explorer 8 usage on the Lane website (www.lanecc.edu) slipped below 3% overall. Normally, we discontinue support for a browser when it dips below 5%. But IE8, as the most recent version of the default web browser supplied with Windows XP, got a special exception.

But, unfortunately, supporting Internet Explorer 8 requires a disproportionate amount of time, and since that usage continues to fall, we’re making the decision to no longer actively develop webpages for IE8.

We will not be removing any existing support, so the Lane website should continue to look mostly ok in IE8 for some time. But, eventually, it will start to break. For that reason, we recommend you use a more recent browser that does work on Windows XP, such as Firefox, Chrome, or Opera.

Of course, if you are stuck using Windows XP, we also recommend that you consider replacing or upgrading your PC as soon as possible. Microsoft will be discontinuing support for Windows XP this year, meaning it will soon no longer be receiving security updates.

Lastly, there are a couple of applications on campus where the recommended browser is IE8 – notably Banner. If that sounds like you, have no fear! You can continue to use IE8 to access Banner. But you should use one of the other browsers – like Firefox or Chrome – for all of your other web browsing needs.

Link text standards

Take a look at these two sentences:

You can read the post on the Web Team Blog.
You can read the post at https://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.

Search Engines

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.

Common Pitfalls – Alt Text

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="/dog.png" alt="dog.png">

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="/dog.png" alt="goldenRetrieverPuppy">

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="/dog.png" alt="picture">

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.

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