Kang Bro Wiratma

Home > All posts

Hierarchy

It's not always immediately clear to new users why we make the distinction between "admin" and "user" accounts on the LibraryH3lp system. The short answer is that, with regard to issues of security and patron privacy, we need to be able to answer the question of anyone: who is the boss of you? When you create an admin account by signing up through the web interface, you're actually creating an administrative domain. You can create any number of queues, for any purposes, and any number of users. You can assign those users to queues in any fashion: for instance, someone might be both a subject expert and a general reference librarian, and should monitor multiple queues when logged in---you can do that. By creating those user accounts within the admin interface, you're explicitly defining the "boss" relationship. If everyone registered their own top-level account, we'd have to find some (more complicated) method of determining who can assign who to monitor what queues. (And who can view transcripts, etc.) But there's more to it than that. Within an administrative domain, your users are all "friends." If you created queues for reference and circulation, the operators on those queues can transfer chats to each other. Your reference staff can transfer chats to subject experts and vice-versa. You have a lot of ways to connect the patron to the librarian best suited to help them, quickly. But there's even more to it than that. Because aside from the boss relationship, there's really no difference between an admin account and an ordinary user account. More specifically, the users you create can in turn create their own users and queues and define their own service models. For example, if you started using LibraryH3lp in your university's main library and wanted to grow your service, you might start by creating accounts for each of your branch libraries. Then your branch libraries create their own users and define their own queues, and you don't have to manage all those details. But, because you created those accounts initially, everything they do falls under your administrative domain. Now you can transfer chats not only from reference to circulation, but you can directly connect patrons to your law library or health-sciences library. You can start thinking about staffing collaborative services with other libraries, either after-hours only or full-on collaboration, all the time. Even in the collaborative scenario, transcripts (if you opt-in to them) are still secure. The recipient of a transfer can, of course, see the prior history of that chat. But outside of that special case, librarians can only see transcripts of the queues they're assigned to, and only the owner of a queue can delete a transcript. And a reminder: this all applies equally to IMs. LibraryH3lp is more than just a pretty widget. Lastly, I want to note that, if by accident of history you do have multiple top-level admin accounts that you would like to consolidate into one domain, as described above, just let us know. We can make it happen.

It's not always immediately clear to new users why we make the distinction between "admin" and "user" accounts on th...

Transfers without Transcript Storage

Not quite a month ago, we released transfers and transcripts simultaneously. Transfers let your librarians send a chat or an IM (from a gateway) to another librarian or to another queue on your system. This gives patrons another way to become connected to the librarian best able to answer their question. Originally, admins had to opt into storage of transcripts on libraryh3p.com in order for transfers to work. This is no longer required. Now, transfers are enabled even when transcripts are not being stored. These sessions are only kept in temporary memory for the duration of the actual chat. Storing the session this way means that librarians receiving transfers can read the prior text of the chat, so that patrons do not have to repeat themselves. But once that chat is over, the transcript is *poof* gone. Of course, if you've enabled transcripts for any of your queues, things will continue to work as usual, and you can always delete individual transcripts. In the future, we will be adding more features to the admin interface to give you even more control over the management of your transcripts.

Not quite a month ago, we released transfers and transcripts simultaneously. Transfers let your librarians send a chat or an IM (from a gat...

E-Mail Transcripts

Both patrons and librarians now have the ability to e-mail chat transcripts to any e-mail address they specify. For the patrons, there is a new "mail" icon right inside the widget. For librarians, there is a link in the web interface. Operators can follow the link at the top of any chat or IM and sign into libraryh3lp.com with their operator username and password. From there, they can e-mail a transcript. This is the same web page they will use to perform other tasks, such as transfer the patron to another librarian or queue. In both cases, the transcript is sent immediately, so this is probably best done at the end of a chat. In the patrons' widget, you might also notice we've replaced the "turn sound on/off" text control with a small image. Some of the embedded widgets in production were pretty narrow, and the text versions of the user options ("turn sound on," "pop out," and now "e-mail transcript") were long enough that we needed to find a way to save space since the text was starting to wrap in the narrower widgets. Using small icons with tooltips for continued accessibility seemed like a good way to address this.

Both patrons and librarians now have the ability to e-mail chat transcripts to any e-mail address they specify. For the patrons, there is a...

Improved Follow-Me Widget

A couple of weeks ago, we quietly released some improvements to the "follow-me" widget. The main improvement is that the patron no longer has to click on a link inside the chat window in order to initiate the "follow-me" behavior. Now, the follow-me behavior starts immediately upon the patron beginning a chat. Why is this important? It has to do with usability and widget placement. Previously, since the follow-me feature only began after the patron clicked a link from inside the chat session itself, it was easy for the patron to accidentally navigate away from the chat by first following a link on the same web page or by doing a search in any search dialog present on the page. For example, one place I think the follow-me widget may be useful is inside a catalog, an environment with pervasive search boxes and links. Now, with the improvement, if the patron starts a chat and then performs a search while inside that same browser window, the chat will continue to work and stay on top of the catalog results page. The same thing applies to the patron following a link found on the same web page as the chat. Librarians do not have to try to remember to get the patron to first follow a link from the chat. See the <a href="http://nubgames.com/w/images/screencasts/new-follow-me-widget/follow-me.htm">movie</a> for a quick demo. The API has also been enhanced, and you can use the Configurator and Servinator to create follow-me widgets and customize their options.

A couple of weeks ago, we quietly released some improvements to the "follow-me" widget. The main improvement is that the patron n...

New controls for your patrons

We have two new features that are really for patrons. The first is a control to play a sound when the librarian sends a new message. We're hoping this will help usability and accessibility. If you and the patron are off working in separate windows while researching a question, the patron can be alerted when you send a new message. The sound alert is currently off by default, but you, as the creator of your widget, can use The Configurator to turn it on by default if you wish. The sound alert requires the patron's browser to have a Flash plugin; we tried using a wav file instead, but it was not as portable. The chat itself still only requires Javascript and will work just fine without Flash. In web browsers without a Flash player, a message that sound requires Flash displays instead of the "turn sound on" control. The second new feature is a "pop out" option intended for users of embedded widgets. This turns an embedded widget into a standard little pop-up window. This should help patrons who are trying to have detailed reference interactions in small embedded widgets. The pop up window can then be resized as needed, and the chat history can conveniently stay open in its own window if the patron wants to refer to it later. Have fun and let us know of any bugs!

We have two new features that are really for patrons. The first is a control to play a sound when the librarian sends a new message. We...

Son of Configurator

Where the Configurator lets you customize and generate HTML for a single chat widget, the Servinator (you try coming up with names for all ...

Enter the Configurator

This weekend we put together a new WYSIWYG widget editor. (It got me out of doing yardwork.) Now you can customize every little detail of ...