1. Pidgin4Lib

2. Two Parts Pidgin4Lib plugin Fully customized Pidgin

3. Features Pidgin4lib plugin –Stable –Automatically authorizes Meebome, MSN, and other chat requests –Loops “new IM” alert sound every 30 seconds until librarian sends one response Fully Customized Pidgin –Still in development –Attempt at IM backend for small-medium collaborative projects –Queuing, routing –Includes pidgin4lib plugin –Dispatch and Operator Groups within Buddy Lists More later

4. DISPATCH (AIM, MSN, Yahoo!, MeeboMe Widget) AIM Patron MSN Patron Yahoo! Patron Operator (AIM, Yahoo!) Operator (MSN) Widget Patron Single Institution Model AIM Patron 1 2 3 4 5

5. Customized Pidgin Dispatch: One well-known public buddy name per protocol used on dispatch. ex: davisrefdesk accts for aim, yahoo, msn, google talk. Dispatch knows about and routes IMs to “Operators.” Operators are individual accounts librarians use to answer IMs. ex: SessomsPam, Librarian1. It is also OK to staff service from Dispatch computer. Can staff Dispatch computer plus one or more Operator computers. Patrons’ experience: IMs appear to be coming from well-known name (davisrefdesk) even when chatting with SessomsPam.

6. Operator Setup and Queueing Individual operators can have multiple accounts. Ex: SessomsPam, SessomsPam2 Operator accts can be on ANY protocol supported by Dispatch. Patron protocol does NOT need to match operator protocol. If operator wishes to handle more than one IM simultaneously, operator accts all need to be on different protocols. That is, one operator account per protocol and no two accounts on the same protocol. Max simultaneous IMs for an operator set by number of active, logged-in accounts. Patrons automatically get “All librarians busy. You are next/second/etc in line.” message from Dispatch when operator accounts are maxxed out. Next in line comes through when an existing IM window is closed.

7. How it looks An incoming IM will appear on BOTH the dispatch and operator computers. The first librarian to send text to the patron “wins” the IM. The window on the other computer automatically closes. Logging is done from the dispatch computer.

8. Annoyance Operator cannot close patron window without typing at least one text character. –Patron window will pop back up repeatedly until closed on dispatch or operator types at least one character. –This is because of queuing. –“thanks,” spam, bots: will have to train librarians to just type a space character prior to closing the window. (text does not have to sent, just typed)

9. Night Owl Duke Dispatch AIM Patron MSN Patron Yahoo! Patron Operator (3 accounts On different Protocols) Widget Patron NCSU Dispatch UNC Dispatch 1 234

10. Possible Night Owl Staffing Scenario: Start of Day Each institution fires up their Dispatch computer (minimally) They may also use various Operators throughout the day –Eases shift change procedure; no need to worry about interrupting IMs in progress.

11. Possible Night Owl Staffing Scenario: 9pm Night Owl operator accounts sign in –They have ALL institutions’ Dispatch accounts in their Dispatch Group. Can work from anywhere. Day Staff operators sign out –No need to coordinate this since operator accounts can be different and the public buddy name should look continuously online. DISPATCH MACHINE should NOT be logged out. (weak spot)

12. Possible Night Owl Staffing Scenario: Midnight Night Owl operator wraps up existing IMs. Night Owl operator sends “sign off” commands to all Dispatch machines. Night Owl operator verifies offline status of all public buddy names.

13. Weak Spots in the Proposal Staff accidentally signing dispatch accounts out at 9pm. Staff confusion over which accounts to use when. They could be named to make it more clear, perhaps. If dispatch machine is physically inaccessible to operator and it crashes, hard to fix. –Phone call to staff present near dispatch machine? –Night Owl staff have login names and passwords for all institutions’ accounts, so can login manually?