Webbin' Rebels

Happy New Year!  It's kind of late but it's my first blog post of 2010.  It's been a while since we last had any discussion about "Going Mobile" so here's an update.

I participated in an Educause webminar last week titled "Library in Your Pocket".  Both presenters were from NCSU Libraries and they provided a great overview of their mobile web project.

NC State mobile web presentation.ppt

Couple of sections worth highlighting for our discussion:

When thinking about the kind of content we want on our mobile web site, consider the following questions:

• What services are currently available?
• What services are applicable on a mobile device?
• What services translate well to the mobile environment?
• What tools can be created easily?
• What would be fun to see?

You might be surprised to hear that the most accessed NCSU Libraries mobile web page is their coffee shop webcam page!

Coming Soon!

• Study room reservation service
• Patron account information (checkouts & renewals)
• Access to electronic reserves for classes
• Building wayfinding
• Tools for staff
• Initiative for mobile projects at NCSU Libraries

I'm pretty confident that we can create a comparable (or better) web site to the current NCSU's mobile site but most of the planned items under the "Coming Soon!" slide will impose some technical challenges for us.  I don't see how we could easily interface with our vendor apps to serve its content on a mobile platform.  Study room reservation service does not currently exist at UNLV so we may end up developing the mobile version to introduce and deliver this new service.

Where are we now with the Going Mobile Initiative?

• FAQ have been selected
• Home page design for mobile web - complete
• Content for phase 1 selected
• Working prototype will be available for review late February

If you have any questions or comments, feel free to comment on this post.

Summary

The Web Management Committee (WMC) -- in cooperation with the rest of the Libraries -- needs to decide exactly what we want the website to accomplish, and formulate a navigation scheme and information architecture to support those goals.

Content Strategies

I've been thinking a lot lately about the Libraries sites content strategy (some excellent background is here: http://www.alistapart.com/articles/thedisciplineofcontentstrategy/).

The entire article is worth reading, but there are 2 closely related ideas mentioned that I think we should give serious thought to. Those are:

• key themes and messages
• content purpose

What is our message?

To find our message, it's worth repeating the Mission Statement and part of the charge  of the WMC:

Mission Statement: The University Libraries web site promotes the discoverability of information and resources in a variety of formats, provides on-line access to library collections, and supports research and self-sufficient use of resources by a wide variety of users.

To me, this says our primary goals are discovery, access, and instruction.

Charge: The UNLV Libraries public website is designed to serve the following multiple functions:

• serving as a repository of information about the libraries, their services and operations
• serving as a communication medium that allows library staff and users to exchange information [...]
  
• serving as a public relations tool to engage members of our community in the Libraries mission and activities and to publicize those activities to the world

This brings in the rest of what we do: communication and marketing.

With these in mind, the WMC needs to figure out what if anything might be missing here, and to decide which of all these things we think are most important in order to focus our structure and design on those areas. I'm not saying that we can't do all these things; rather, I believe we need to move away from the mostly flat structure we've maintained until now and create a site that more directly targets the needs of MOST users while still fulfilling the needs of everyone else.

Flat structure

Currently the site is quite flat. Looking at the home page, we don't necessarily give priority to any one area, and there's never been much discussion about the ones we do give priority to. The large main image is devoted primarily to marketing, the tabbed search box to discovery, subject-specific research is hidden in a drop-down box, services get a few links, instruction is very nearly ignored. Additionally, it's difficult to tell in a glance where the main navigation lies. Is it the tabs along the top, or at the top of the search box? The right side menu? The boxes under the search box? The right side?

The lack of clear navigation focus carries over into other parts of the site. We include identical top, bottom, and left side menus on every page, ignoring the fact that a user on the Services page probably wants to focus on services, or on the Computing page probably wants to focus on computing. We use contextual menus and marketing only very sparingly, and usually at the department level.

This isn't a criticism of the relatively new home page or template designs! The current design is a clear  improvement aesthetically and usability-wise over previous ones. But the design reflects an information architecture that has developed accidentally, rather than one created purposefully and carefully.

Questions we should ask ourselves

Perhaps the most important question we should ask is, "What do we want users to see right away on the site?" What should the home page instantly convey? Should we push our services? If so, which ones? Ask a librarian? Instruction? Should we focus on discovery? If so, what resources should get top billing? Journals? Books?

What should our site be? A research tool? A marketing tool? A communications tool? All of these things? Are any more important than the others?

What about contextual navigation? To me, this is one of the great things about Whitehouse.gov. Go to The Administration  and there's a menu to drill down into various Administration areas. Choose one of these links, and the menu remains (though in a different area). We saw the success of contextual menus on the Media site in the usability testing of that area; the redesign will let us greatly expand their use, but this in turn will require us to think carefully about the new site structure.

It's even possible that the current home page design -- tabbed search box with links all around it -- meets our goals for the website, but if so, that should be a conscious decision rather than something that evolved based on decisions made by other people years ago.

What about Usability?

There is no doubt that card sorting will help us with the new structure. But while it will inform us as to how our users would categorize our content, it won't tell us how we should prioritize this content -- only we can do that. Statistics will also help somewhat (for example, by showing us which content is most important to users). But we really  need to decide what matters most to us as an organization so that we can focus the site on those things, and maybe weed out what we find less important or no longer relevant.

Putting it together

Drupal will help us a great deal in developing a sustainable and scalable content management strategy, but that's only half the battle. Creating a content strategy -- including a navigation scheme, information architecture, and site focus -- that is usable and useful to all our classes of users is a much more important challenge that needs to be addressed at the outset of this redesign.

In the previous blog post I discussed the guidelines I suggested we follow with regard to web accessibility. Although that discussion remains open, and I encourage more feedback, I think it would make sense not to get too hung up on that conversation.

Today, I would like to discuss the various action items this task force needs to accomplish and the timeframe in which they can be accomplished, and then begin dividing up the work.

Action Items

Here are the major action items I think would make sense for this task force to undertake, with the proposed name of the leader for that action item, proposed start date, and a few sub-items to give a little more information on the work involved with each part. It should be noted, the “leader” just means who will head up a particular subsection of this effort. For example, I don’t expect Cory to rewrite the style guide herself, but I would hope that she could take responsibility for that part of the task force to get the guide rewritten.

1. Style Guide Revisions (Cory Lampert) – Start Date: January
1. Formalize coding standards everyone has to follow
2. Require Alt Tags
3. No “Click here” links, etc…
2. Automated Accessibility Testing (Brian Egan) – Start Date: January
1. Choose the tool(s) (AChecker/CynthiaSays/Lift/etc)
2. Create a plan to check all current pages with AChecker and our determined guidelines
3. Build Accessibility into the Drupal Publishing workflow
1. Use an editor with Achecker built in
4. Generate lists of updated/modified pages that need testing
3. Live Accessibility Testing (Alexis & Michael) – Start Date: January, testing begins when new CML site is finished
1. Establish Working relationship with DRC
2. Identify Tests that need to be run
3. Which browsers need checking?
4. Which pages are most important at first?
5. Establish testing standards / methods of testing
6. Who will run tests?
7. How will they be scheduled?
8. How often will they occur?
9. Recruitment
1. Work with DRC to find students who can help us perform live tests
2. Possibly coordinate incentives
4. Web Developers Training (Kee) – Start Date: January
1. Create Screencasts / Presentations for Web Dev Meetings
2. Common Accessibility Pitfalls
3. Working with the automated accessibility checker in Drupal
5. Modify / Add to our website (Brian Egan) – Start Date: January
1. Accessibility Feedback Form, something like: http://library.buffalo.edu/libraries/aboutus/policies-use/accessibility.php

Volunteer!

Ok, I’ve been kind enough to put some of your names on these items (you’re welcome! =P), but that was just my best guess as to who would be interested in leading each particular section. In addition to leaders, we need a volunteers to help with each section, particularly the Live Testing. If you have an interest in helping out with one of these sections, please let us know in the comments!

Many thanks to Cory for getting the Web Accessibility Task Force off the ground! This is a great step forward for the accessibility of our site, but it’s just the beginning. We need to sustain the momentum and begin to plan our activities so the committee produces positive outcomes. I hope to lay the groundwork for that planning today by establishing the goal of the committee and discussing the guidelines our website should follow.

Goal

I want the goal and scope of this committee to be fairly limited. While we need to focus on accessibility, it shouldn’t be an all-consuming time-beast. Therefore, the goal I envision for the committee is to:

Determine guidelines for accessibility and create a set of sustainable processes that help our website meet those guidelines.

Guidelines

In my view, before we begin testing, rewriting the style guide, or planning training, we should probably figure out what guidelines we’re testing, writing, and planning for. Once we determine the guidelines, we can create processes which conform to them. From the web design perspective, there are three major guidelines we need to consider (you don’t need to read all of this as these are mostly technical documents aimed at web developers, but it would be helpful to glance through these pages a bit to understand the basics):

1. Section 508 – These are the guidelines set forth by congress which apply to all Federal agencies. These generally do not apply to state universities, although the situation can become a bit trickier when federal grants/funds are involved.
2. Web Content Accessibility Guidelines (WCAG) 1.0 – The original web content accessibility guidelines. Set forth a number of best practices, but many are outdated by this point. Still useful for review and perspective.
3. Web Content Accessibility Guidelines (WCAG) 2.0 – The current best practices as set forth by the World Wide Web consortium (the body responsible for all web standards). These are by far the most up-to-date and best organized set of guidelines. This is a technical document, and may not be all that interesting to read. Check out the intro to WCAG 2.0 for a more human-friendly overview. WCAG can also be rated for conformance on a scale from A (lowest) to AAA (highest), depending on how well a website conforms to the guidelines.

Suggested Guidelines to follow

These are the most important documents I know of with regard to web accessibility guidelines. From my limited research, the State of Nevada and UNLV have no special requirements for web accessibility that we need to follow. However, if I’ve missed anything, or more documents need to be taken into consideration, please provide me with the information in the comments section!

My recommendation for guidelines is to simply follow Section 508 and WCAG 2.0 with AA conformance. While all projects won’t be bound to Section 508 laws, we might as well make our sites 508 compliant in case we land any federal grants or funding that could necessitate 508 compliance. WCAG 2.0 is simply the most up-to-date set of best practices, and the guidelines were written with live and automated testing in mind. Tools already exist to check for Section 508 and WCAG 2.0 compliance, and I think it would be impractical for us to create a set of guidelines and tools comparable in quality. That said, there may be additional, unique considerations we need to make. If I’m not taking something into consideration, please let me know!

What do you think?

I’ve put a fair amount out there, and I want to take some time to gather feedback. What do you think about the goal of the committee? For those that have joined, does that seem like a commitment you can make? Do you think the guidelines I’ve recommended are sufficient, or are there more guidelines we should incorporate? Are there any special considerations we have to make due to state or even local law that anyone knows about and which I missed?

Updated Below!

With the help of the Media Department and Systems, we recently launched the LabMaps kiosk, located on the first floor next to the copier. The kiosk shows patrons the number of computers available on each floor, and if a patron clicks on one of the floors, a LabMap will display showing a map of where the available computers are located. If you didn’t see the kiosk before 5:00pm, you’ll have missed the first interface I made for it, and that saves me some embarrassment =)

First Interface

But I’m gonna embarrass myself anyway. The first interface was incomplete, and came at the problem from the wrong angle. For those of you who didn’t get a chance to see it, here are a couple of screenshots to give you an idea of how it worked.

Opening Screen, the user would click on one of these links to go into a LabMap:

LabMap Screen, shrunk to fit. The big gray box is the “Back” button.

Design Pros

1. Focuses on large, clickable links that should be easy to touch with your finger on the kiosk screen.
2. That’s about it.

Design Cons

1. Hard to read from a distance. While there was a focus on “large” links, large is a relative term. The text appears quite large on a screen that you’re sitting next to, but wasn’t readable from more than 5 feet away.
2. Hidden Information? I was thinking in terms of the web when I made this interface. The links are underlined, the boxes are a subtle gray. It doesn’t look like something you could walk up to and press, and I wanted to convey instantly to people that there was more information hidden that you could access by clicking a button.
3. Hideously ugly. Nuff said.
4. Thinking in the wrong context. It functioned like a web page, not a desktop application. Click a link, it takes you to another page, and then you click another link to go back. I would say, overall, thinking in the wrong context was my biggest problem with the first interface.

Second Interface

Considerations

After thinking about the cons of my previous design, I began thinking about what I could do to address the problems, and here are the solutions I came up with:

1. Think about it from a kiosk, not a person sitting at their desk perspective. Fonts need to be larger, people should be able to understand the information from a distance, the interface should be “touchable.”
2. Use much, much larger fonts. Increases readability from a distance.
3. Reverse the foreground/background contrast, so that the background was dark and text white. This made the text stand out much more vividly from a distance than traditional black text on a white background.
4. Remove the header. In order to make the header readable, it would have to take up far too much of the screen. Because we have a sign on the machine which acts as a header, I figured it would make sense to just take it out, leaving more room for the buttons & maps.
5. Make buttons. The user should see the interface and know they can “press” a button, presumably to give them more info.
6. If that isn’t immediately noticeable, add a note to the screen informing users there is more info.
7. The maps are quite large, and need to fit on one screen. Scrolling on the kiosk is a pain. Rather than putting each map on its own page, using a web-style workflow, I thought I would create "overlays", which pop the map above the button interface. This is a somewhat minor change, but I thought worked better for the kiosk interface, and it looks pretty badass.
8. Make it pretty. No more ugly!
9. Make it resemble the Catalog interfaces somewhat. I figure I might as well keep some design consistency between our interfaces on the floor =)

Preview

If you haven’t seen the new interface, you can check it out live on the kiosk or by visiting the live page on your current computer! Note: The interface is designed for the browser on the kiosk, Internet Explorer 8, and may not function well with other browsers, such as Firefox, Safari, or Google Chrome.

Conclusion

I have to say, designing the new interface was a bit tricky for me. It provided a lot of fun challenges and got me to think outside of my normal web designer box. If you have any comments or suggestions for how to improve the interface further, I’d love to hear them in the comments!

Updates – 25 Nov 2009

Thanks to all who have provided suggestions for improvement thus far! In addition to the above changes, I have now added the following features:

1. “You are Here” icon. This should help orient patrons on the first floor when they’re looking at the kiosk interface.
2. Changed “Reference” to “Research & Information". Hopefully this will make the map a bit clearer, and make it easier to orient yourself.
3. Added Headings to the Maps. Before, once you clicked on a map, it didn’t indicate which map you were looking at. This was done to save space, but I was able to cram it in there without causing the user to have to scroll.

Effective January 2010, Urchin 6 will become the default/primary web traffic analysis tool forthe library.  Due to migration issues, Urchin 6 will not have the historical data currently available in version 5.  Urchin 5 will be available for sometime until an official decommission date is determined.

Link to Urchin 5  (Traffic Data from July 31.2006 to present)

Go to the Web Site Statistics page on the staff wiki for the username and password.

If you need additional information or have a question about Urchin, please contact Kee Choi.

The library also uses Google Analytics to analyze traffic on commercial systems and on certain sections of the library web site.  Much of the functionality in Google Analytics will be available on Urchin 6 so many of the GA users can choose to migrate after January 2010.  A comparison chart of Urchin 5, Urchin 6, and Google Analytics is available here.

Recently, the WMC put out a call for volunteers to participate in the Going Mobile Interest Group.  The group had its first meeting in October and a good cross section of the library were represented.

Minutes from the October 20 Meeting

The group spent some time talking about FAQs so it stood out as a topic of interest for everyone at the meeting.  There are existing FAQs scattered about the library's web site but the group agreed that a separate FAQs, targeting our mobile device users, is needed.

Brian's wireframe/prototype includes a Policies section but that will be changed to FAQs.  The FAQs will include answers to policy related questions.

Examples:

Can I eat and drink in the library?
What are the library's hours?
Where are the branch libraries located?
How do I get on the wireless network?
Do you have laptops available for use?
What are the Book'n Beans' hours?
Can I get reference help when I'm way from the library?
Where can I find out about jobs in the library?
How much does it cost to print and make copies?
Where can I find directions to the Library?

Can you think of any other frequently asked questions that would be useful to our mobile device users?  Post your suggestions as a comment.



 

The web is an exciting profession because of just how rapidly things change. Within the last few years, one phenomenon has made the lives of web designers much easier: Cascading style sheets, more commonly known as CSS.

CSS is an incredible technology because it allows designers to quickly and easily control the look of a multiple pages without touching the content. CSS can also be applied within a variety of contexts, such as for mobile browsers, regular web browsers, print, and in the future, screen readers.

As pointed out by Kee earlier this week, the latest update to our templates caused printing problems for a number of pages. Years ago, this problem would have struck fear into the hearts of designers. But today, thanks to the adoption of CSS, providing printer-friendly pages is as simple as making a few updates to our CSS files.

So that’s what we’ve done. Earlier this week, I went through our CSS files and wrote a bit of extra code to alter the output of printed pages. Now when you print something off our website, you should get clean printouts that remove all of the unnecessary elements from the page, such as navigation, quick links, and breadcrumbs, leaving only the important content for print display. Overall, this should improve readability and save ink!

Give it a try! Navigate to any page on the website and run a “Print Preview.” You should see the new print interface in all its glory! If you have any suggestions for improving the display of printed pages, please let me know in the comments!

While they may be trite and self-helpy, I’ve always enjoyed the 7 Habits of Highly Effective People. One habit I find particularly useful is the seventh: Sharpening the Saw. The basic principle is that one must continually strive for improvement in a variety of areas in order to maintain a healthy lifestyle. When applied to our web site, sharpening the saw means continually improving the look and functionality of our site to maintain a great site for our patrons.

We do this with larger-scale projects, such as enhancing our digital collections with dmBridge or the updating the home page and website template. It is just as important that we focus on smaller improvements as well as large. Smaller updates include improving the look of our maps, updating older looking pages to reflect our new template, or simply modifying the text on a page to be more accessible for screen readers.

These updates may not be as noticeable or glamorous, but it is crucial we continue to make these small improvements. We made a very good start with the latest template change, but there are still a lot of areas with room for improvement. Much of our site doesn’t quite conform to the style guide, which gives our site a piecemeal feel at times. Furthermore, our site used to be extremely difficult for screen readers to interpret. I’ve tried to simplify the code of our web site a great deal to aid this, but if text isn’t formatted correctly, that can pose a major challenge to those with disabilities. With the latest update, we created a new style for menus, and some menus still don’t quite conform to that style. Finally, there are just some things that are ugly and should be fixed.

And that’s the purpose of my weekly updates. I maintain a running list of pages that I’d like to improve, select two each week, and update the pages. So far, I’ve made a few changes, such as overhauling our directions page (old version), updating the EZProxy pages (also improved error feedback), made minor text updates to the circ pages and faculty FAQ, and converted a number of old menus into the new style.

All of this should help our site shape up a bit, and hopefully bring about a more coherent, user-friendly experience for our patrons.

The following is my current list of “To-updates.” If you would like WDS to take a look at any of your pages, please let us know in the comments section or by sending us an email! I try to scour the website for sources of improvement, but hey, I’m only human. Furthermore, I always welcome critical feedback if you don’t like something I’ve done.

1. Serial Solutions Journal Titles Search – Bug in Internet Explorer that needs fixins
2. /about/history.html
3. /nvlasvegas/index.html
4. The Calendars (pretty ugly right now)
5. /webforms/work_request.html – some slight display bugs in various browsers
6. Singapore Resources (update do new menu style)
7. Minify and Compress CSS/JavaScript (this is a technical one, but will greatly speed up the site for users with slower connections)
8. Create sprites to reduce image calls (another techy one)
9. /about/dropboxes.html
10. ILLiad

As I’ve said, this is my current running list in which I’m constantly adding and checking off items. Please let me know if you’d like your page/site/folder/application added to the list, and lets keep striving for a better website!

What is "LabMaps" you say?  LabMaps is a part of the LabStats Suite of products by Computer Lab Solutions.  The LabMaps software provides a visual layout of the computers in the library and it's status in real-time.  Basically, our patrons will be able to locate available computers on all five floors from one computer/kiosk in the library.

Preview Link- Only accessible within the library.

Systems, Media and Computer Services, and WDS all collaborated on the LabMaps project.  Providing a dedicated LabMaps display in the public area is currently up for discussion.

OIT has already implemented LabMaps for a couple of their labs and I'm told that they are planning to expand to include more labs on campus.