EDUCAUSE 2014

Brian Farr and I will be discussing our library website rebuild and the ins and outs of successfully using Wordpress as a CMS at this year's EDUCAUSE conference in Orlando, Florida. We'll be presenting at 2:30pm on Tuesday, in Meeting Room W311F-H. [Tuesday schedule]

Our talk, Building Academic Websites (in the Real World) will also be webcast, so if you'll be attending the virtual conference, you can catch us there too!



As usual, I'll include links to any of the resources we talk about, and try to keep the list updated as new topics or questions arise:

• List of Helpful WordPress Resources
• Tutorial for using scripts to add functionality to Google Forms

And, because animated gifs don't work in slideshare, here's the run-through of the evolution of the new site. Agile development FTW!

CUNY IT Conference - Building Academic Websites (in the Real World)

I'm presenting tomorrow at the 2013 CUNY IT Conference, where Brian Farr (our Systems Manager) and I will be talking about the process of developing our new library website. If you'll be at the conference, consider coming to see our talk at 2:15pm. [Conference schedule]

• Slides from our talk
• List of Helpful WordPress Resources
• Tutorial for using scripts to add functionality to Google Forms
• Slides from a similar talk I gave for ACRL-NY, which are more boring, but also more informational

I also have some fun slideshows of the site-building process, with screenshots and mockups and crazy marked up documents, which I'll add next week.

anatomy of a crash, part deux

So say your site gets hacked, and you try fixing the index and config files, as I mentioned in the last post. And you try checking the server logs to see what files were messed with so you can replace them with backups. And you turn on error-reporting in your CMS to try to see what's going wrong. And you Google some of the malicious code you found in your files. And say none of these fixes work, or yield any useful information. What now?

Well next you'll want to search for common hacks to your specific CMS and version, to see if anyone can walk you through fixing them. Here's a pro-tip though: in the end, most fixes will just tell you to install a fresh version of the software, and if you're in my situation that's not an option, so learn from our fail. Set up your website in such a way that disaster recovery is a relatively easy job, or at LEAST a viable option.

I will admit that much of this advice is based on my experience with Joomla and Wordpress. I have much less experience with Drupal, so some of it may not apply there. If you're a Drupal person, and have advice for keeping your site safe from hackers, please post it in the comments!

1. Keep your site software up to date.
   Also your plug-ins. Also your themes. Because chances are, if they're all from reputable sources, the developers will be addressing vulnerabilities as they pop up. The world of hacking is a shifting landscape, and what's secure today is not necessarily secure tomorrow.
 

2. Keep your customization modular.
   In WordPress, this means using a child theme, rather than making changes to the main theme. When you update a theme, it will override any changes you made to those files. Now you're in a situation where you have stop updating your theme, and are thus breaking RULE NUMBER ONE. You will regret this.
 

3. Keep your site root clean.
   Actually, not just the site root, but all its sub-directories. Part of the problem with our site is that the root folder is cluttered up with custom includes, images, project folders, etc. If you're not the one who put them there (as in my case, where I'm taking over a site from someone who is no longer here) it's hard to know what folders are part of the CMS's software, and which ones are not.
   
   In general, if you re-install the software, it should just ignore these unrelated files and folders, but if the software contains new files and folders that have the same name as yours, you can accidentally overwrite your files. I'd say either place these files one level up, OR, if you want them to have the site root's url, create one folder in the site root, and put all of it in there. Clearly mark that that folder is NOT part of the CMS's file structure.
 

4. Documentation!!!
   Srsly. Updating or re-installing your CMS may not be a difficult process, but YOU may not be around when it needs to be done. YOU may be on another continent, or at another job. YOU may have gotten hit on the head or killed those particular brain cells with alcohol. There are so many pieces to a CMS (plugins, templates, images, forms, database(s), etc,) it's supremely helpful to know which of these need to be backed up in like six places before you re-install, so you don't lose the hours and hours of work you put into customizing them. Which leads to...
 

5. Keep backups of important files and folders.
   Yes, I know you're backing up your entire site on a regular basis, because to not do so would be INSANE, but even so, keep an extra copy of important stuff, JUST. IN. CASE. I have a folder on my desktop with my config file, my entire child theme folder, and my custom plugin folders. WordPress is smart, and names the blank config file something else, so when you update, that default config file doesn't overwrite yours, but still. (Remember to update these backups every time you make a change. I got in that habit anyway, because I keep an entirely local copy of the site to make changes to before making them live, so it's kind of a reflex at this point that when I make a change in one place, I update those files everywhere else.)
 

6. Minimize the use of 3rd party modules or vulnerable code.
   Wherever possible on our WordPress site, I used CSS/jQuery to create my own custom features (like our tabbed search box) rather than install another plugins. Plugins can increase the vulnerability of your site, so use them with caution (and, not to drill it into your head or anything, but keep them updated!) We've also made the switch to Google forms for all our forms, so we have the benefit of their security features (and so the forms are connected to off-site databases, rather than databases on our servers.)
 

7. Create a simple html backup site ready to go at all times.
   Honestly, I never even thought of this until the head of Media Services suggested it. Libraries subscribe to many services that are hosted off-site (such as the catalog, research guides, databases, resource managers, and discovery services.) These services are the core of our business, and are still available even when your site is down. Create a simple site that links to whatever services and resources are still available, as well as basic information like hours and contact info. I just downloaded a free CSS template and created a quick and dirty 2 page website that can be put up during downtime (unless the entire server is down. Then I guess you have to put them elsewhere and do a redirect? ACK! SERVER STUFF FRIGHTENS AND CONFUSES ME.)

So ok, there you have it. I am by no means an expert on the topic of hacking, or disaster recovery, or even web development for that matter. This is just an attempt to learn from my own experiences, and to put what I learned out there, just in case it can help someone else in a similar situation. If anyone else has some advice on these matters, please share in the comments!

Crappy image maps messing with my mind

Please, for the life of Brian, give adequate thought to creating image maps (images that contain multiple links, mapped to different areas of the image.) While they can be useful, and even creative, they can also be confusing. (The one in the linked Wikipedia entry is a good example of a creatively-designed image map, that has some functional issues.)

In web design, you rely on certain conventions to indicate to the user what can be clicked on (ie-a link.) If you use an image as a link, users can see the image is click-able by mousing over it, and seeing if the pointer changes from an arrow to a hand. However, if you make an image into an image map, but divide the entire image into click-able sections, it can be hard to tell the different areas of the image link to different places. You can help alleviate this problem by restricting the click-able areas to distinct areas, separated by some non-click-able space, and also by using tool-tips or title tags to describe the link hidden in that part of the image.

My motivation for this post? My own damn library's website. Check out the header on this page: http://www.library.csi.cuny.edu. It took me a moment to realize that the entire header didn't link back to our website, but also contained a link to the school's website. After much clicking and confusion, I realized that the bottom part of that image not only contains a link to the *school's* website, but also the school *system.* Now, maybe you got that at first glance, but I honestly didn't, and I highly doubt I'm the only one to make that mistake. Part of the problem is that the site was created years ago, and as I mentioned in the Harvard Library website post, alt tags are no longer rendered as tool tips by all browsers (I'm using Chrome, and they don't show up when you hover over the links in it.)

I opened the page in Dreamweaver to be able to visualize where the links were mapped to (see below,) and I can honestly say that they tried to keep the links tight to the text, but I think that the bottom two links are just too close together for it to be quickly apparent to the user that they link to two separate places.

How would I have done it? I would have probably made the "CSI" part link to the school, and the rest would link to the library. I'd probably add the "City University of New York" as a regular text link, underneath the header image, or possibly just in the footer.

Just remember when creating image maps: unless the user hovers over various areas of the image to find the links/tool tips, there is no external indicator as to what part of the image links to what (ie-you can't tell just by looking at it.) You have to rely on visual cues and web design standards to cue the user in to the fact that the image contains a.) a link and/or b.) multiple links. They may not take the time to wave their cursor across the whole image to discover just how many links there are, and what they link to.*

*Some cues that there are multiple links are:

• Scrolling over the image and noticing that the entire image is not click-able. Many developers will not bother creating an image map to insert a single link in an image, unless they have a good reason to; they'll just make the entire image the link.
• Patterns... If it's a picture of the solar system, and the first two planets are links, the user will guess that the rest of the planets are too. Same thing with maps where more than one location is linked, or groups of people where more than one person is linked. (etc, etc...)
• Added visual cues such as numbers, letters, or symbols that indicate where the user might find a link. (Example: http://www.frankmanno.com/ideas/css-imagemap/#ex)

FORKED!

The list of library tech peeps was starting to get a bit unwieldy, so I forked it! Sheet 1 of the list is website and user experience types, while sheet 2 is digital projects/eResources/systems/repository types. I know there's some overlap, so when in doubt, I tried to think if I would classify that particular person as "front-end" or "back-end." And yes, I do giggle whenever I think of someone as a "back-end" person. I AM TEH MAHTYUR.

If you think I've mis-classified you, or if I have your link(s) wrong, just let me know, and I'll fix it ASAP, because I now have a Gdrive app on my phone so I can be fly on the fly. Waitwhat? Shuddup it's Monday and I've had 3 cups of coffee already.

Catching Up On the World of Library WebTech

So, I thought myself fairly knowledgeable in the area of library technology. Turns out, every aspect of library technology has its own communities, its own published body of knowledge, its own go-to gals and guys. Yes, you say, well, duh. I thought much of my experience in social media and online marketing would carry over into my new web services position, but I'm finding out that this is a wonderful new pond, with wonderful new fish.

As I learn of this stuff, so shall you, because I'm pedantic like that. I mean generous. Whatevs. Either way, I am starting a list for myself of web services-type librarians. I'm mostly concerned with blogs I should be reading, people I should be following on Twitter, and library websites I should look to for best practices. You should help me with this endeavor, because you're a nice person, and you totally just thought of someone or something I left off the list.



Who is missing from this list? Let me know in the comments!

PS - If you're having trouble viewing the silly embedded spreadsheet, you can view the full spreadsheet here.

PPS - Yes, I should have linked those twitter usernames. I will. Tomorrow. [DONE]

PPPS - I split the list into 2 lists.

Just one more thing...

One thing I forgot to mention in yesterday's post on Harvard's library site... They have a really sleek user feedback system. When you click on the "Tell Us" button at the top of the page, you get the following javascript pop up:

I love that it not only gives you a place to provide feedback, but also tracks and reports on known issues. This saves time for both the user, and the helpdesk, since the helpdesk is used to receiving untold numbers of reports on the same printer being broken, or the wireless being down. This system allows users to see what issues are currently being dealt with before submitting their comment. Users can also comment on or "vote up" issues without having to submit a new ticket.

I did a little snooping around in the code, and it would seem that they are using (and correct me if I'm wrong here) an online helpdesk system called UserVoice. I like not only the functionality of the software, but also the sleek way it integrates into your website, and provides a social aspect to the online helpdesk. Nicely done, all around!

Harvard Library: a closer look

I took a look at the Harvard Library website over the weekend, to pick apart the elements of the site that I really like. First and foremost, I love the minimalist layout and color scheme. The white background makes it look less boxy, and the sections are separated by horizontal lines instead of rectangular borders. I know library websites are chock full of content that we want our users to be aware of, but when there's too much content on a page, I find I can't focus on anything.

When it comes to details, I like the mix of text and images. They use icons in the upper right corner to draw attention to popular services (1). I think these are fairly good icon choices, but in general you have to be careful with them. You can get creative, but don't use an icon that's commonly known for one thing, for something else. For example, a wrench or gear(s) is often used for "settings," so this icon can cause confusion when linking to something else. I think they're ok here, though, since they include easy-to-read labels under the icons. (Joshua Porter just posted on the use of labels with icons. How fortuitous!)

It's common practice these days, but I'll mention it anyway: I like having the search box function front and center (2). I think this site does the service one better though, in including a "What am I searching?" feature. Library collections can be confusing, and often we have different search functions for different collections (catalog for books, integrated search for databases, digital repository for archives, discovery service for everything...) I know not everyone will read the text, but it's concise enough not to be obtrusive, and adds useful information for anyone willing to scan over it.

The scrolling news items at the bottom of the page (3) offer another graphical element on an otherwise sparse page, and allow you to highlight events, collections and perhaps even offer a place for alternate entry points to resources for specific communities or to commonly-asked-about services. For example, you could create one specifically for students or faculty, or have one for using Blackboard, logging onto the campus network, or finding textbooks in the library. 

The drop-down links at the top of the page (4) use symbols to denote internal links (which open in the same window) and external links (which open in a new window/tab.) This is especially important in library sites, as many resources we offer are provided by third-party vendors, and it can be disconcerting to click on a link and be faced with a different website, with a completely different look and feel from your own. 

I'm just gonna go ahead and say it. I like deep footers (5). It was at a workshop a few years ago, where a presenter was talking about the NYPL migrating to Drupal, where I first met the deep footer (you can see it in action here), and though I can't remember if it clicked for me right away, or if it upset my 2002 web developer sensibilities, I now think of it as a great, unobtrusive way to add relevant links to your site. I like it especially as a place for all your social media links/icons, as well as for links to content that your users might find useful, but that are outside your own site. For academic libraries, those links might be to the school registrar, the writing and/or tutoring center, and the academic calendar. Especially since many university home pages are catered towards prospective students, rather than current students, these links can help position the library's homepage as a portal for students who want to access information and resources for the school as a whole. 

Finally, I like that when you scroll over the drop down link boxes, you can not only click on the links that appear in that drop down menu, but also the main category under which they are grouped. This gives you a landing page for each category, and a chance to help guide users who want more information on that category, or aren't sure which link they need in the group. The only thing that threw me a bit, was that the landing page links did not match up more closely with the options in the drop down (6). This creates a bit of a logical disconnect in terms of "training" users on navigation. (ie- If they visit the landing page on their first visit, does that help them understand and be able to use the quick navigation on their next visit?)

One final note regarding accessibility: When I learned html (many moons ago) you used the "alt" attribute for both accessibility and as a way to provide information via mouse-over text (or "tooltips".) While poking around in the code of this site, I noticed that they were using both an "alt" *and* a "title" attribute with most of the images. Apparently, it's now standard to include both of these, as not all browsers will render the "alt" tag as a tooltip if the "title" is absent (which used to be the case.) So you want to include an "alt" description for accessibility (and for images that don't display) and a "title" description with whatever information you want the user to see when they mouse over the link or image. For a more thorough explanation of the alt vs title attribute, see: http://www.456bereastreet.com/archive/200412/the_alt_and_title_attributes/ 

To learn more about how screen readers treat various html elements, I found this resource helpful: http://webaim.org/techniques/screenreader/ (If your library uses LibGuides, they also have an accessibility page, with info on what they do, and what you need to do, to ensure 508 compliance: http://help.springshare.com/accessibility)

Onward Toward the Next Next Gen Library Website

I want to do a series of posts on designing and building a website for an academic library. I'm mostly doing it for myself, as a way to organize my thoughts on the process (since I will be building a library site this semester,) but I thought it might also be useful to share some of the resources I am and will be collecting. And, of course, it's always helpful to have a place to think out loud, so you can get feedback from outside sources.

I do want to make a point before I get started though; these posts are meant to be critique, not criticism. (Or, at least *constructive* criticism.) I don't want to tear anyone down, or poke fun at anyone's efforts. I understand how hard it is to get things done in libraries, given our limited budgets, and the multiple roles everyone on staff must play. Rarely does a library have the staff or the money to hire a specialist to design and build a website, and even when they do, it's hard to find someone with that skill set who also understands libraries and library culture. I feel lucky that I'm in the unique position of having been a reference and instruction librarian for 7 years, and am now in a job that allows me to use the insights I gained working directly with faculty and students to make our website work better for them.

If sacrifices must be made, due to the afore-mentioned budget and time constraints, I can give you a wee piece of advice on the topic: sacrifice style for function, every time. Choose the easiest-to-use software, and make the most popular resources and services the easiest to find. People may snicker at your color choices (I recommend checking out design seeds to help with that) but that's much better than them being frustrated by not being able to find what they're looking for. Snarky users are not necessarily unhappy users. Frustrated users are pretty much *always* unhappy users.

In searching around, I found (and was directed to) several library sites (both academic and public) that I like, and am using for inspiration. Check out:

Harvard Library
Salt Lake City Public Library
Detroit Public Library

I'll tell you why I like them. With the rise in popularity of open source content management systems like Drupal, Joomla and WordPress, websites got very "boxy." Because these CMS's are organized around interchangeable modules, people tend to just drop those module boxes into their site like a puzzle. The above-three sites (at least 2 of which use Drupal) get around that boxy look by using a white background, so the content boxes blend into the rest of the site. This style also works well with responsive design, which uses stylesheets to create a website that is automatically optimized for whatever screen-size or orientation it is viewed at. The trend towards ubiquitous computing means sites have to be able to easily "jump" from desktop to laptop to tablet to smartphone with minimal sacrifices to functionality.

I think for the next couple of posts I might actually pick one site for each, and go over what I like about it. In the mean time, if you're just getting started with web design (or even if you're an old pro,) I highly recommend taking a look at Hongkiat, which has great design and technical tips, as well as tutorials and guides for all aspects of web design and development.