Mei 2008

Home > Archives for Mei 2008

Send File for Patrons and Librarians

A couple of days ago, a "send file" option began appearing for operators who follow the chat management link at the start of a chat or IM. Today, this option was put into the patron's widget (it's the little folder/arrow icon in the widget). When a file is sent, a link appears in the chat for the receiving party in the form of: download from http://libraryh3lp.com/download/filename.ext Files sent during a chat are temporarily stored on the LibraryH3lp server. They currently have a shelf life of two days before being deleted. There is a size limitation of 10 MB per file. A file of any type can be sent. The ability to send a file during a chat can be very handy. Often, patrons chat when they are stuck on some kind of access problem. In a typical scenario, for whatever reason (off-campus user with proxy server trouble, a vendor with an out-of-date IP range, etc), your patron should be able to access something, and they just cannot. We all try to straighten these problems out at the root, but often, that takes time, and what the patron really needs right then is just a PDF or two so they can carry on with their research. Rather than e-mail these, you can now send them directly during the chat. Sometimes it's also nice for the patron to be able to send files to the librarian. One situation that sticks out in my mind is a patron with a question about how to cite something. She was trying to explain it to me, but then she simply sent her actual bibliography and paper, and it was suddenly much easier for me to understand her question. On another occasion, a patron sent me a PDF from one of our e-journals; the article had some missing pages, and I was able to see the problem immediately, look for a complete version, and notify the vendor of the problem. Enjoy! This is the last user control we have planned for the widget. For now. :)

A couple of days ago, a "send file" option began appearing for operators who follow the chat management link at the start of a chat or IM. Today, this option was put into the patron's widget (it's the little folder/arrow icon in the widget). When a…

Plugin for Pidgin

Today we're releasing the first version of our LibraryH3lp plugin for Pidgin (Windows version). It has the following features: <ol><li>Displays the full roll-back of a chat to the recipient of a transfer.</li><li>Repeats an incoming chat alert noise at a configurable interval in seconds until a librarian sends a message to the patron.</li><li>Automatically approves incoming buddy requests.</li><li>Automatically cleans up all those guest123456@libraryh3lp.com buddies that accumulate in your buddy list. </li></ol>The first feature, showing the full history of a chat to the recipient of a transfer, is a very helpful time saver. It means the the librarian answering a transferred chat does not need to follow the "chat management" link in order to read the prior discussion between the patron and the first librarian. The second feature, the repeating new chat alert sound, is especially handy for staffing models where it is not guaranteed that a librarian will be physically looking for incoming chats visually all the time. In my library's main chat service, we answer the chats on computers near, but not actually right at, the reference desk. We rely on sound alerts to let us know of incoming chats, and the looping sound prevents us from accidentally missing anything when the phone rings or we're away from the desk for a short time. It also lets staff nearby in their offices know when the desk is slammed and no one is immediately picking up a chat, so that we can pitch in on the fly to help out. You can set the repeat sound to suit your preferences: 60 seconds, 30 seconds, etc... Notes: <ol><li>The sound will not repeat for simple new responses from the patron once a chat is underway; it is limited to their initial message (see important configuration notes at the end of this post). </li><li>If more than one computer with the plugin receives a chat because multiple librarians are signed into the queue in question, the sound will stop looping on all the computers when the first librarian sends a response to the patron.</li></ol>The third feature, automatic approval of buddy requests, is useful for buddying other librarians who are staffing your services. This provides an easy method of librarian-to-librarian communication. To buddy another LibraryH3lp user, pick Buddies-->Add Buddy and enter the desired account. Example: marian-the-librarian@libraryh3lp.com. If you're using other accounts besides LibraryH3lp accounts in Pidgin, be sure to buddy to the right one. The plugin should also auto-approve similar requests from other systems. The last feature, automatic clean-up of guest accounts left by your patrons' chat sessions, is a nice housekeeping feature. To get the plugin: <ol><li>Save <a href="http://code.google.com/p/libraryh3lp/downloads/list">the plugin's zip file</a> from our wiki. </li><li>Unzip and save the libraryh3lp.dll file in Pidgin's plugins directory (usually c:\program files\pidgin\plugins\). </li><li>Enable the plugin in Pidgin at Tools-->Plugins. </li><li>Click configure plugin and set the desired interval for the new message alert sound.</li><li>Check Tools-->Preferences--Sounds and select message received begins new conversation. This is not turned on by default.</li></ol>(Edited 26 May 2008 to reflect the automatic buddy clean-up feature.) (Edited 16 Nov 2008 to generalize link to plugin zip file download.)

Today we're releasing the first version of our LibraryH3lp plugin for Pidgin (Windows version). It has the following features:Displays the full roll-back of a chat to the recipient of a transfer.Repeats an incoming chat alert noise at a configurable…

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 the LibraryH3lp system. The short answer is that, with regard to issues of security and patron privacy, we need to be able to answer 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 gateway) to another librarian or to another queue on your system. This gives patrons another way to become conne…

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 new "mail" icon right inside the widget. For librarians, there is a link in the web interface. Operators can…

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 no longer has to click on a link inside the chat window in order to initiate the "follow-me" behavior. Now, the follow-m…

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're hoping this will help usability and accessibility. If you and the patron are off working in separate windows …

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 this stuff):https://libraryh3lp.com/servinatoris a tool to help you design your overall chat service. You can …

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 your widget's appearance interactively online and save your settings on our server. The widget isn't actually…

Kang Bro Wiratma