Sponsored Link •
|
Summary
The folks at FtpVoyager have done it again. First, they created the best interface for remote syncrhonization I've ever seen. Now they've come up with the best online support tool. It's even better than my design...something I've given a *lot* of thought.
Advertisement
|
After casting about for the right tool to upload pages to my website, I finally settled on FtpVoyager. They just did things right. I'll start by describing the features that made it my pick. Then I'll describe their astonishingly useful online support system.
FtpVoyager's main feature is its customizable "sync" utility. It's pretty much the only feature I use. They put the list of server files in an upper window, and the local file list underneath it. Then they put a button next to each window. Click the upper one to "upload" changes to the server. Click the lower one to "download" changes to your system. So simple. So natural. So intuitive. And yet, among the 7 or 8 tools I examined, theirs was the only one that did it.
In true "explorer" style, a pane on the side shows the directory hierarchy on each system, so you can easily select the target folder and source folder. You can also select individual files and click a button to upload or download, and you can delete things, rename them, or create folders.
The sync is customizable, too. That's really helpful. So when there are files in the target directory that don't exist in the source file, you can tell it to automatically delete them, ask you if want to delete them, or ignore them altogether. And you can tell it whether or not to include subfolders. (I always do.) There are other synchronization options, but those are the main one I use to get the kind of synchronization I want.
The interface is so good, in fact, that I've been pleading with them to keep the interface, drop the FTP library, and give me a version of the program that will let me sync to a USB flashcard, for example, or to a mirror backup disk (MediaVoyager?). So far, I haven't had any no luck, but I keep my hopes up. (In the meantime, I understand that rsync works on Windows. Have to look into that. I should be able to run it in my CygWin shell, at any rate.)
FtpVoyager also has a scheduler, a "sys op chat", and some other functions that I know nothing about. They probably do something useful, but the features I use are more than enough to justify the (quite reasonable) price.
Note: Unfortunately, when you go to buy the program, the web page sounds as though you're buying a license that's only good for a limited time. In my correspondence with them, they assure me that you are indeed buying the program, along with "upgrade protection" for one or two years, depending on whether you spend $40 or $50. That's the right kind of pricing for a great program, so they get my money. Hopefully, they'll fix their web page to make it clear.
Ok. That was the reason I liked the program. But I was really blown away when I went to their online support site. I've been thinking about how such a site should work for years, and I've had a few ideas on the subject. They not only implemented the right kind of system, in the right kind of way, the did it even better than my best design. Did I mention I like it? It's a case study. It exemplifies the right way to do online support.
My design was based on the observation that purely automated support systems are routinely horrible. They never get it right, so you wind up needing to talk to a person--so an automated system that attempts to completely replace people is a non-starter.
At the same time, it's important to offload the support staff when you can. So FAQ pages and such are great. But when they get large enough to contain the information you need, they get too large to find it anymore. So you want some kind automation, but you want to integrate into the human support system so you can evolve it over time.
To meet those goals, it seemed clear to me that you would start by sending a message to support. An automated system would intercept the message and send you back a response if it could. If the response was helpful, you'd say so (hopefully). If it wasn't, you would say "no" and you would be connected with a real person who would be able to help you using the information in your message. Over time, the system would get smarter as the developers fine tuned it. They would have the success statistic to tell you how much smarter it was getting, and users would have the benefit of describing their problem one time, instead of once to the automated system and again to the support folks.
There was a small problem with that design, in that you couldn't distinguish a successful response from one that made people give up in disgust, but I figured the potential level of inaccuracy was acceptable, given the other benefits. It was the best possible way, I thought. I had even written a paper on the design for Sun's knowledge engineering group.
Then I saw FTPVoyager's implementation. Wow. (I'd be jealous, but their implentation is even better. And now that are out in public, I can talk about them freely.)
In their system, you type your problem into an email form. It has your return address, a summary line, and a detailed description. The system then searches its FAQ database for possible matches and gives you a list of the summaries with a button next to each that takes you to the full description.
This is where the system gets brilliant. When you click on a button, you not only see the FAQ entry, you have the email form on the same page. All of the entries are filled out so you can edit the message and send it, or you can back up and visit another entry.
The system astonished me. It works on so many levels that I had to write about it. In the first place, I actually found the information I needed. That impressed me, becuase it has never happened before. Not ever--not even with online support systems written by much bigger companies. I scanned something like 16 entries, and visited 3. It didn't feel hard, and I knew that I could send my message at any time, so I was relaxed. On the third entry, I found the answer I needed.
From a user perspective, then, the system was great. But from a designers perspective, it was even better. Think of how much information they're gathering! Every click on a topic makes it possible to rate it as either "potentially interesting" or "ultimately successful", so it can sort higher up on the list. And anytime a user choses not to send their message, you know they got the information they need. Any time they do, the support person has some additional information to go on.
Back on the user side, the fact that email form is adjacent to the FAQ entry is very powerful. One of the problems in a support system is that the customer (generally me!) doesn't know the right terminology to use. If they did, an FAQ page would be sufficient. But since they don't, the FAQ page becomes virtually useless, even if it contains the answer they need.
So a big part of an automated system is "terminology translation". A person may say their system is hosed, down, broken, or crashed. When a match that should be found is missed, the system designers can often fix the problem by telling the system about synonyms it needs to know so it becomes "better educated".
Note: In my ideal design, a support person can respond to a query by sending back information from the data base. That response can then be copied to the designers, which gives them an immediate high-priority list of things the system could have recognized, but didn't. I don't know if the FtpVoyager system works that way, but it would be a relatively small addition to what they've already done.
So either the automted system does the terminology translation, or a support person winds up doing. If the feedback loop is closed, the system gets smart enough to do more, so the support people cn do less. That much was clear to me. But with FtpVoyager's implementation, the automated system can also help the user get smarter.
One of the benefits of talking to a person at the other end of the support line is that you get smarter. They educate you, giving you "just in time information", so pick up what you need to know, when you need it. The good ones do, anyway. Not all are that good. But many of them are. (They've certainly had to be patient with me, at times.)
As you get smarter, you learn how to diagnose your problem, the terminology to use when talking about it, and how things work. The better your description, the less translating the support person has to do, and the more likely you'll get a good answer.
And that's where the FtpVoyager support system excells. One improvement over my design was the way it replies with multiple responses instead of the "Are you feeling lucky?" single response that I had been envisioning, and that most other systems implement. But an even bigger stroke of genius was something that never occurred to me--displaying the email form alongside the FAQ entry.
As a user, that arrangement gives you a chance to get smarter. It lets you change the question you're asking as you learn more about the terminology to use and the way things work. It feels "rewarding", in the same way that you feel rewarded when a helpful support person educates you a little, so you know a bit more than you did before.
There is something about learning things and having a brainstorm that "puts things together" that is just incredibly rewarding. It's just about the best feeling I know. As a species, it probably accounts for why we'be built so much and learned so much. In that sense, FtpVoyager's online support system is very rewarding. It's a case study, and a role model.
Have an opinion? Be the first to post a comment about this weblog entry.
If you'd like to be notified whenever Eric Armstrong adds a new entry to his weblog, subscribe to his RSS feed.
Eric Armstrong has been programming and writing professionally since before there were personal computers. His production experience includes artificial intelligence (AI) programs, system libraries, real-time programs, and business applications in a variety of languages. He works as a writer and software consultant in the San Francisco Bay Area. He wrote The JBuilder2 Bible and authored the Java/XML programming tutorial available at http://java.sun.com. Eric is also involved in efforts to design knowledge-based collaboration systems. |
Sponsored Links
|