Web-based chat widget face-off

I’m part of a group using Meebo for chat reference, and while it’s been fine so far, it lacks a couple of features we’d like to have. One: the ability for the user to leave the chat page without ending the session. Two: the ability for the user to leave us a message if s/he arrives when we’re not on.

I’m poking around in other web-chased chat options, and so far I’m turning up a couple of options.

  • Meebo: No limit on concurrent users, as far as I know. Requires the librarian to keep the Meebo.com page open in a browser in order to stay on the service. (Although they now also offer a sidebar widget that may remove that requirement.)
  • Plugoo: Only five concurrent users. Doesn’t require the librarian to keep a web page open, because it doesn’t offer a proprietary chat client–instead, it works through an existing chat account such as Meebo, AIM, YM, etc. Users can leave a message if they access the service when the librarian isn’t on.
  • Hab.la: Allows user to navigate away from the web page without ending the session. (See this post on infodoodad.) Has a dedicated page for library services. Only allows 5 concurrent users. Only allows one librarian at a time (but they’re working on more.) Hab.la also seems like an interesting new delivery model, in that the chat bar sits unobtrusively in the bottom corner of any page you want; to chat, users click on it to open a window. So instead of devoting a single library web page to chat, you could put chat bars on every web page and not worry about whether people could find their way to the single service point. Sort of like having librarians roaming all over the library. (Of course, that limit on concurrent users could get sticky.)

None of these tools archives chat transcripts, which is a drawback. On the other hand, they all offer anonymity to both participants in the conversation, which is a plus.

So, to sum up (click through for full-size version):

Web-Based Chat Comparison

If I got anything wrong, or have outdated information here, please let me know.

Advertisements

Accessible screencasting

I’ve been thinking a lot lately about whether screencast tutorials are accessible. Or, more accurately, about how accessible they can be made to be.

I use Adobe Captivate to create tutorials for the library, and I include interactive features like click buttons, links, mouse-overs, etc. From a pedagogical and usability standpoint (if it’s done right), all this is a bonus–it encourages active learning, engagement, and time on task. A major benefit of screencasting is that it can reach visual learners, who’d rather watch a process than read a description of it. Audio narration can reach learners who like to hear material rather than read it. Students with learning disabilities (or anyone, for that matter) can review the material repeatedly, at their own pace, whenever and wherever they want. All good.

However.

Captivate includes a number of accessibility features, including output for screen readers and closed captioning. I’ve used those features, and I’ve seen my tutorials used via a screen reader. (Thanks to the campus web access group for this.) The result was far from pretty, and also pretty far from meaningful compliance with Section 508. (The subpart to pay attention to in this case is C: Functional Performance Criteria.) An experienced screen reader user couldn’t navigate through the interactive features without difficulty, and in some cases we hit brick walls.

It all makes me wonder–how often do we really take accessibility into account when we develop screencast tutorials, or for that matter, any new library services? If we can’t make all delivery methods equally accessible, do we try to ensure that we provide alternative means or support for users? According to Section 508, that’s what we should be doing (assuming we receive Federal funds.)

I’d be interested to hear from anyone who’s worked on making their screencast tutorials accessible, or who’s thinking about ways to supplement screencasts with more accessible types of online instruction. I’d also be interested to hear about how other libraries have tackled this, from a policy perspective. It seems to me that having a clear policy and shared understanding about how to balance innovation and accessibility is a baseline requirement for libraries doing online instruction.

Google Sites vs. course management systems

Well, it’s probably too soon to say “vs.,” but if I were a faculty member who wanted to make a quick, easy, low-risk, low-maintenance site for my class, I’d definitely be interested in Google Sites. Here’s what I’d find most intriguing:

  • I don’t have to know HTML.
  • I can limit membership to just the people I choose–the whole world doesn’t get to see my Google Site. (Unless I want them to.)
  • I can collaborate with other instructors at my institution (Google Sites lets me invite others with the same email domain.)
  • I get some very groovy Google Site themes, without having to wrangle a single graphic.
  • I can create and insert spreadsheets, documents, slideshows, images, presentations, and YouTube or Google Video videos into my page with a click.
  • I can insert Google Gadgets (like Google calendar, a mini web search, a stock ticker, RSS feeds, or Pac Man) into my page with a click.
  • Users can comment on my pages automatically, the way they can on a wiki or a blog.
  • I can change the look and feel or layout of the site (where the navigation sidebar appears, for example) with a click, or a drag-and-drop.

What can’t I do? Well, I can’t associate my students’ IDs and grades with the site, so the online gradebook would have to be a separate tool. That might be a killer. But for a lightweight, free, easy-to-administer course site, Google Sites gets a lot right.

Want to see what a Google Site might look like? Here’s an example of a K-12 classroom site (mentally modify for higher ed), and here’s a sample team project site.