Three things of note happened this week:
First, many thanks go to the efforts of the Shanghai Library, which has provided us with the text for a Chinese localization of the LibraryH3lp chat widget.
Second, we've made some enhancements to the admin UI, so that it is now possible to register new admin accounts, as well as create queues and users in non-English languages. *EDIT* Earlier I stated that it was not possible to login to the webchat client with a non-English username. That problem has been corrected.
Third, we're now hosting the widget on servers in Hong Kong and Tokyo (in addition to existing servers throughout the US and Europe), thanks to Amazon's new Cloudfront service. This should provide better load times and performance for Asian users.
Sunday, November 23, 2008
Saturday, November 15, 2008
New Admin Interface
You may notice if you sign into your admin account to manage your services that the UI is, well, somewhat radically different. We've been working hard over the last couple of weeks on designing something that is more intuitive and easier-to-use for new users (and prettier and more "2.0"). Specifically:
We're going to be working the rest of the weekend on writing and integrating new documentation, so that it won't be so scary come Monday.
- User, queue, and gateway management is now all on one page, so that it is easier to view your entire service structure at a glance.
- The old configurator and servinator have been merged into a single wizard that walks you step-by-step through the process of generating HTML for inclusion into your web pages.
We're going to be working the rest of the weekend on writing and integrating new documentation, so that it won't be so scary come Monday.
Friday, November 7, 2008
SMS Texting Services
Texting services are becoming popular, with libraries beginning to really experiment in ways to best deliver this service to cell phone users.
Currently, many LibraryH3lp libraries are using various short code hacks, such as the "AIM hack" to offer this service. It works.
With the AIM hack, patrons text their message to 265010. In the message, they specify your library's AIM buddy name. If you have an AIM gateway in LibraryH3lp, those text messages show up for all of your librarians just like any other traffic coming through the system. If you are using our Pidgin plugin or our new webchat client, your librarians will be able to see that the patron is coming in through a phone number, which can tip them off that they need to provide brief responses.
Once again, this does work. The less-than-optimal thing about it is that the patron's cell phone can't usually store your buddy name to make repeat usage easier. The phone can store the short code (265010) just like a cell phone number, but not your buddy name. When they text their friends, they're generally texting a real phone number, which their phone can easily store for later usage.
We are interested in building a better kind of SMS gateway, one that would allow patrons to text an actual phone number, so that it would work exactly like it does when they are texting their friends and family. We have a couple of ideas about ways to make this happen. Is anyone interested in working with us to integrate a true SMS gateway into their LibraryH3lp service? We can't develop this independently because SMS messages must be purchased, and we don't want to push costs up for everyone on the system, even if they're not using SMS. A library would buy the messages for their use independently, and then we would build the gateway.
Currently, many LibraryH3lp libraries are using various short code hacks, such as the "AIM hack" to offer this service. It works.
With the AIM hack, patrons text their message to 265010. In the message, they specify your library's AIM buddy name. If you have an AIM gateway in LibraryH3lp, those text messages show up for all of your librarians just like any other traffic coming through the system. If you are using our Pidgin plugin or our new webchat client, your librarians will be able to see that the patron is coming in through a phone number, which can tip them off that they need to provide brief responses.
Once again, this does work. The less-than-optimal thing about it is that the patron's cell phone can't usually store your buddy name to make repeat usage easier. The phone can store the short code (265010) just like a cell phone number, but not your buddy name. When they text their friends, they're generally texting a real phone number, which their phone can easily store for later usage.
We are interested in building a better kind of SMS gateway, one that would allow patrons to text an actual phone number, so that it would work exactly like it does when they are texting their friends and family. We have a couple of ideas about ways to make this happen. Is anyone interested in working with us to integrate a true SMS gateway into their LibraryH3lp service? We can't develop this independently because SMS messages must be purchased, and we don't want to push costs up for everyone on the system, even if they're not using SMS. A library would buy the messages for their use independently, and then we would build the gateway.
Subscribe to:
Posts (Atom)
.png)
