I’ve been playing around with mobile chat solutions for Ask-WA for the last few weeks. Mobile’s the way to go for virtual reference, and Ask-WA is going there, one way or another. We’re beginning a text-a-librarian pilot starting next month and running through September, and I’m interested to see what sorts of interest levels that garners from our users.

In the meantime, I’ve been trying out QuestionPoint’s chat “Qwidget” via the iPhone (an iPod touch, actually, but same difference), and while it leaves some things to be desired, it’s not half bad, and certainly functional. Now that I’ve tried the experience, though, I want to start thinking about how we can design to better incorporate this mobile version of the service into our websites.

You may, or may not, know that if you have a Qwidget on your website, and someone browses to that page on their iPhone, they will see a button that allows them to launch the mobile version of the Qwidget and chat directly through their device. If they then hit the “+” button at the bottom-middle of their screen, they can “Add to Home Screen” and basically have a Qwidget App that connects directly to their librarians (in theory, though they could certainly abuse the system and connect to whatever library they wanted to in the same fashion).

For the most part, this works pretty well, but has a few limitations. For instance, you don’t get to decide what you want the button to look like, they all look the same and say “Please click here to launch our mobile chat widget.” and have a blue arrow pointing down. This is fine, and functional, and clear, but you may want some more flexibility, anyway. The rest of this post details some ways to test and tinker with your mobile chat Qwidget, without the benefit of actually having an iPhone, though you will need the ability to install applications on your computer (you’ll need Safari, at any rate).

Browsing like it’s 2010

Mobile browsing is different than regular browsing; your screen is tiny and the experience can easily get overwhelming. Many sites have mobile versions, but you need to trick them into thinking you’re using a mobile device to get to them. And it’s the same with the QuestionPoint Qwidget; if you want it to show up as a “click here to launch.” button instead of a working Qwidget, you have to convince it you’re on an iPhone. There are probably a number of ways to do this, but this seems like the easiest.

First, download the Safari web browser from http://www.apple.com/safari/download/. Install Safari and run it.

Once Safari is open, located the little cog on the right of the screen that drops down your settings menu, and select first “Show menu bar” and then “Preferences.” In the Preferences sub-menu go to the “Advanced” tab and check the bottom box to “Show Developer menu in menu bar.” Exit out of the Preferences menu.

You should now have a file menu along the top of your Safari screen with a “Develop” option. Click on “Develop”, select the second option down, “User Agent”, and select any of the “Mobile Safari” options; I’m using Mobile Safari 3.1.3 – iPhone for the purposes of this post.

You have to set this any time you close Safari and then open it again, but you are now able to trick websites into thinking you’re viewing them on an iPhone. Huzzah!

Want to test it out? Try my test page at http://ahniwa.weebly.com/ with your other browser, or using the default user agent in Safari. It should load up with a fully functioning Qwidget embedded in the page (and not much else). Then try it in Safari after setting your user agent to the iPhone, and you should see the “Please click here.” button in place of the Qwidget. Neat, huh?

 

Thinking about Service

If you’re using an actual iPhone / iPod touch, it’s hard to see what’s going on behind the scenes. Now that we’re in Safari, though, we can get a better idea of what’s going on, and start to tinker. The original code on the page is your basic Qwidget snippet, looking something like this:

<!– Beginning of QuestionPoint qwidget code. –>
<div id="qpchatwidget" ></div>
<script id="qp.bootstrap" type="text/javascript" src="http://www.questionpoint.org/crs/js/qwidget/qp.bootstrap.js?langcode=1&instid=#####&skin=green&size=standard" charset="utf-8">//<noscript>Please enable javascript to chat with librarians online</noscript></script>

When browsing to the page via iPhone, however, it changes the Qwidget code to an image that links to a much simpler URL, like this:

http://www.questionpoint.org/crs/qwidget/mobileQwidget.jsp?langcode=1&instid=#####&skin=green&size=standard&referer=http%3A%2F%2Fahniwa.weebly.com%2F

And since the mobile version of the Qwidget doesn’t care what size / color you’ve chosen for your Qwidget, you can remove those elements (and either remove or spoof the referer element) to get an even simpler link, like this:

http://www.questionpoint.org/crs/qwidget/mobileQwidget.jsp?langcode=1&instid=#####

Note that in these examples I’ve #’d out the institution ID # – use your own institution ID # instead of ##### to get a better, working example. (Your # is listed on My QuestionPoint, just after you login, near the top-left where is says “Institution: My Public Library (My Queue) (#####).”)

It’s worth noting that this link will work whether or not it thinks you’re using an iPhone, so you could conceivably use it as a Qwidget replacement, if for some reason you wanted to do so (I don’t recommend it).

Now you can play around with what it looks like for your users to chat with you on their iPhones. For a much more authentic experience, though, shrink your Safari window as much as you can horizontally, and so it’s about twice as tall as it is wide; more or less iPhone-shaped. You should only be able to see about this much text in your active chat window:

“. and that you’ll use us again soon! If you provided an email, you will receive a transcript of this session shortly. You may also see a link to a survey, which you may use to rate this service. Thanks!”

This is something to keep in mind when chatting with people using these mobile Qwidgets, and particularly in sending large blocks of copied text, or in using longer scripts. The script above loses about two lines of text which go above the fold, and it’s really hard, as a user, to scroll up and recover that lost text. In a solid block you have about 200 characters to work with; in practice, I’d suggest using far less. Good chat practice suggests we use smaller messages more frequently, and I think this is even more essential when helping our users via the mobile Qwidget.

If you want, you can always check first to see if they are using the mobile Qwidget. The “Browser / OS” should read something like this:

Mozilla/5.0 (iPod; U; CPU iPhone OS 3_1_3 like Mac OS X; en-us) AppleWebKit/528.18 (KHTML, like Gecko) Version/4.0 Mobile/7E18 Safari/528.16

You can send links to a mobile user. Anything with an http:// or www. at the beginning of it will be click-through-able (e.g. http://m.cnn.com OR www.google.com; NOT m.cnn.com OR google.com, though). When clicked, these will open in a new window and the user will automatically be taken to them; I can’t make any promises that they’ll ever find their way back, but it’s fairly straightforward to use multiple windows via the iPhone Safari browser.

When it comes to follow-up, did you know that whether or not your patron enters an email address at the beginning of their Qwidget session (and you can make them do so in your Qwidget settings, if you want), it will look like they have not entered one while you’re chatting with them. If you check out the ASK module, even while the chat is in session, you should be able to verify one way or the other, but I doubt most chatting librarians have time to do this with every Qwidget session they answer.

This seems like a bug to me, and hopefully one that will be addressed, but in the meantime it seems a better practice to NOT ask for an email address at the beginning of the session, and instead ask during the actual chat session. That way you’re not bugging the patron to enter their email twice, and you can be sure that you got it before you end the session.

 

Thinking about Design

Not many libraries have mobile versions of their websites (that I’m aware of), but it’s worth starting to think about, at the least, a mobile page. And on that page, access to the mobile chat Qwidget. And you could do it the default way, by putting the Qwidget itself on the page and letting it transform into a button for the right kind of user, or you could eliminate the middle man, use your own image, and link to the shorter, cleaner MobileQwidget URL up above.

Doing it yourself provides more flexibility, though it could present its own problems if users try it with an unsupported device, perhaps, or if spambots found it.

Whichever way you do it, though, it’s a good time to start thinking about how you are providing support to your mobile users, because there are more and more of them out there, and they aren’t going away anytime soon.