Tuesday, October 10, 2006

The user experience

RELease 1.0, April 23, 1993, by Kris Land

Most of what we have described so far just helps users collect even more names that need to be replicated everywhere. Luckily, next-generation OSes will support API-addressable directory services and address-exchange protocols. That means a user need maintain only one address book locally. The OS will make that list available to all a user's applications, replacing her address books with the central book.

The X.500 spec says nothing about the user interface. That's where vendors can differentiate themselves. MAPI, OCt, PenPoint, Telescript, MIME (the Multimedia Internet Nessage Exchange) and other such systems will act as the glue that allows users to choose the front-end they prefer, yet still be good citizens in the distributed systems architecture. To succeed, the companies leading these efforts have to agree on interchange standards.

Wouldn't you like to be able to have the Resources & Phone Numbers at the end of each issue of Release 1.0 put automatically in your PIM

Super PIM?
PIMs will be effective tools only when they are aware of the surrounding infrastructure and can collaborate with it. The ideal PIN is a smart shell that owns and stores as little information locally as possible. Where it can, it funnels queries to other applications or data stores. The addressbook facet of a PIN helps users set up ad-hoc conference calls or create and disband workgroups. Users shouldn't have to worry about the intricacies of addressing schemes and source routing; PIMs should hand addresses to other applications in the proper transmission format.

"If users have to spend more than one minute a day maintaining their addresses, it won't work."'
-- Mark Jackson, AT&T EasyLink

As we mentioned already (page 3), some applications and operating systems are moving in this direction, such as GO's PenPoint, which includes a Dialing Location Sheet. Today, every time the user changes status by leaving the office or traveling to a different area code, she has to find the Sheet and manually change the settings. A future version will sport an easy-to-change menu item. Long term, portable devices will monitor their own status and switch settings automatically. They will also communicate their status to message hubs via wireless links. That should iron the kinks out of many offerings that are Just not convenient enough today.

OCTUS: PLAY PONG WITH YOUR CALLERS
As important as an individual's PIM is the interface that facilitates interaction between individuals. Octus has done a nice job of combining GUI ease of use with call-management functions usually missing from pc products.

Nolan Bushnell, creator of the Pong videogame that helped launch this industry, and founder of Atari and the Chuck E. Cheese Pizza Parlors, is at it again. Nolan, Kris Land [12] and a team of 30 engineers are working to resolve the problems we encounter as we wrestle with our phones, e-mail, faxes, etc. Their approach starts locally, with address books and small workgroups; it's the other end of the spectrum from the Brobdingnagian, network-based services we described earlier.

With Subway, Octus' product suite, users can place calls, swap business-card data with other Subway users during (or before) a conversation and decide what to do with incoming calls -- answer, take voicemail, play a message ("hold on, I'll be right with you") or forward them elsewhere -- automatically. Subway holds contact information about others you communicate with. It also monitors the recency and frequency of calls, and tries to make those numbers handiest.

Make the possible, visible
When you try to communicate, Subway's interface will make visible what is possible at any given time. Want to send e-mail to Zoe? She has no e-mail account listed, but we can turn your note into a fax and send it on its way. Subway, currently in beta testing, will eventually feature voice recording and playback, and will act as a simple voicemail or voice-response system, or record and play back clips of audio, including your phone conversations. Subway requires the installation of an OctoBox at each desk, between the workstation and phone.

More interesting, though, are the ways Subway helps manage communication in a small workgroup. For example, the first time Zoe calls, a receptionist can log her into Octus's address book, which is no more effort than typing the information into e-mail phone messages. The next time she calls, the receptionist can pick her name from the existing list (if Caller ID doesn't do it first), which brings up a flash note with all the right information (as long as she isn't calling from a friend's office). The receptionist sends it to the person being called, who can associate different rings with different callers and manage the call with the options described above. Octus eventually plans to add more powerful rule-building capabilities, and perhaps support for wireless phones. Subway is for office workers who must receive phone calls and faxes often, and who have been losing the assistants they once took for granted.

APPENDIX: OUR OWN LITTLE PROBLEMS
Our messaging adventure starts with our telephone numbers -- one for Connecticut, one for Manhattan, plus a fax in each place. (Lucky we don't use a cellular phone or pager yet.) Our 700 number (0-700-CURIOUS) is handy for people who need to call us often, but not simple enough to give to Just anyone (see page 10). We never (well, except when talking to AT&T or NCR people) leave the 700 number in phone messages.

When we first subscribed, we forwarded the number often, especially because it was easy: The system would pick up our inbound number, if possible, and use that as a default assignment. But AT&T removed the Caller ID feature because it could be misused. Now we usually leave the 700 number pointing to our own voicemail number (we're not comfortable relying on hotels to collect and forward all the messages), and use the 700 number to check our own message bin; the 700 number is less expensive than calling cards.

Telecommuting is no picnic
When messages arrive for us in the Manhattan office, we have no automatic way to receive them in Connecticut, since the in-office message system is Notework (from the company of the same name), a TSR that's handy on DOS machines, but weak on external connectivity. Urgent callers are asked to call Connecticut; other messages await our trips to Manhattan.

The EDventure office uses BeyondMail to connect to the rest of the world, via an MHS gateway to MCI Mail and CompuServe. BeyondMail and Notework don't communicate. We have installed BeyondMail on our Connecticut pc, as well as on our notebook pc (a Safari on loan from NCR). We would like to have this environment available on the Safari, but we're not that far yet. Instead, we log into the WELL through the CompuServe packet network using Software Ventures' MicroPhone Pro and check our mail.

The MHS gateway works nicely with the EDventure office in Manhattan (after much frustration with the notoriously troublesome Telepath modern from Gateway), but is not working with CompuServe. (BeyondMail for Windows sends attachments as a default with each message; CompuServe's MHS gateway coughs them back to us; a patch is on the way.) We have to exit BeyondMail to run the MHS gateway. In fact, we can generally only have one communication program open at a time, or the modern locks up. We also use Delrina's WinFax, though we suspect the Telepath gremlins have been at work again, because our fax/modern transmissions aren't reliable.

Our Gateway 486 is armed with AG Communication Systems' WindowPhone system, a card and software that enables a pc to detect Caller ID information, then looks up the number (if you've entered it, and if the call is from a direct line). Unfortunately, it doesn't have much opportunity, since most of our calling is interstate and no agreements on the handoffs of Caller ID data between carriers have been struck. Also, only numbers served locally by modern switches can transmit Caller ID, further reducing coverage. WindowPhone does let us autodial, which is convenient; however, it's another list of names and numbers to maintain.

A messaging maelstrom
We have a series of online accounts and e-mail addresses. From an Internet perspective, these are: jmichalski@RadioMail.net (for a Viking Express mobile radio messaging loaner we're about to surrender -- thanks, RAM Mobile); spiff@WELL.sf.ca.us (the WELL, our principal e-mail bin and online haunt); 76367.2432@CompuServe.com; Rheo@AOL.com (America Online), and Jerry. BMail@Rheomode.MHS.CompuServe.com (a BeyondMail-MHS-CompuServe triple play). All have different passwords and need to be connected to separately (not all support forwarding of messages). Ironically enough, that last, most complex address is where we'd like mail to go, because it is the only way we can read separate messages, rather than work in a terminal session (we tried several front-end programs; TapCIS's interface was too rough, and Sweeper crashed our machine, despite two downloads from the WELL).

We don't mess with this many services because we want to be difficult or clever or even for the opportunity to test each one; we do it because each network has different resources. AOL's subscribers are different from Compuserve's and from the WELL's, for instance. Unless these services adopt some common storage and interchange formats, as well as common offline readers, we'll be doing this dance forever.

We're about to return the Viking Express kit we've had on loan from RAN. It's been trusty, even impressive (send a friend e-mail while riding an airport Jitney), but carrying it plus the NCR Safari 3170 notebook plus associated recharging subsystems is a bit much. Because we don't have the HP 95LX Connectivity Pack, which would let us upload files directly, we forward e-mail that we want to keep to our WELL account.

What about groupware? File synchronization?
It gets worse. In addition to paper, we publish our newsletter via Amix, which has a less-than-ideal user interface. We have Lotus Notes installed in Connecticut, but it apparently hates the Telepath modern, so we have not used it yet to synchronize with servers at New Science Associates, the ITAA or Lotus. We loaded Microcora's Carbon Copy, but it doesn't support our monitor's resolution, so we decided to do without rather than change permanently to a lower graphics setting. Lotus Organizer is an elegant PIN, but its address book isn't very flexible, and synchronizing between Organizer on the Gateway and the Safari is difficult, so we've postponed using it. To transfer bigger files between the two, we use Traveling Software's LapLink (for which we have to unplug the mouse, change the autoexec file and reboot the Gateway several times). Needless to say, we don't do that very often.

Practically every one of the systems we've just described has an address book. None of them talk to each other. Worse still, our old contacts are in text files, exported from Apple's HyperCard and not imported into a database or address book because we Just can't figure out which one to use. Besides, importing and exporting functions are never smart enough to sort out field separators and address formats. There may well be ways to work around some of the things we've just described (we certainly hope so), but we haven't found them. So far, entropy and chaos rule.

The next time someone gives you a business card, it may be electronic
[12] Land's company, Paradox Development (now merged with Octus), built a networked fax server called FaxConductor, which captures, OURs and routes inbound faxes automatically (if senders put double parentheses around an inbound routing number). Octus is merging FaxConductor with Subway.

Kris Land is the chief technical officer of OCTUS Inc. (San Diego, CA).

0 Comments:

Post a Comment

<< Home