NB: I'm one of the two inventors of Talkback (aka the Netscape Quality Feedback Agent).
But the key thing is that Netscape's error reporting only occurred in the case of a fatal crash, whereas Microsoft's patent covers non-fatal program failures as well.
Talkback catches crashes by default, with the programmer having to do very little. That is part of its base level functionality.
Talkback ALSO reports on any other error (or non-error) condition the developer cares about. It's easy, and common practice, to put a call to Talkback in an exception handler, for example.
There's even a mode that will cause Talkback to report to the server the first time the application is used. This makes it very useful to compare the number of downloads to the number of people who actually install it and run it at least once.
So even Microsoft's "unique" addition of responding to non-fatal errors still falls short of what Talkback-enabled products could do in 1997.
I am one of the two people who inveted Talkback (aka the Netscape Quality Feedback Agent).
We showed this technology to Microsoft early in 1998. We outlined the whole process, and nothing in their abstract describes any innovation over what we showed them.
The discussions in that meeting were held under NDA. As a small company, we had little choice but to use Microsoft's NDA. Their version allows them to use anything they "remember" as long as they don't disclose our specific confidential information.
We did get a patent for Talkback, one of several that were in the works before we sold the technology. Supportsoft now owns the technology and the patent.
I'm not saying that this is just another example of Microsoft having to rely on screwing small companies and coopting their innovations. You can decide that for yourself.
I can already program my TiVo remotely, and even watch what's showing (well, sorta). It didn't involve any modifications to TiVo, either, such as those required for TivoWeb.
However, it did require a bunch of equipment and a bunch of work. Basically, it looks like this--
The video output of the TiVo goes, via a switcher, to a PC that has an ATI All-in-Wonder card in it running, gasp, Windows 98. Software on the PC is my own program, and with a very long VGA cable, it acts as the TV & information appliance in my kitchen. Also on this PC is some basic webcam software that my program can start and stop.
I have a second PC dedicated to home automation running Linux. Connected to this PC is a box called an Ocelot, which, among other things, can send arbitrary IR commands. I use Xantech products to distribute the IR to the various pieces of equipment.
Finally, on the Linux box is a custom home automation server that manages all the home automation components, including the Ocelot. PHP-based web pages can talk to this server and cause it to send IR commands to my TiVo.
So, with a web page that includes the webcam output and some buttons to command the home automation system, I can interactively view and control my TiVo. It's a bit of a rube goldberg solution, but it only uses the "official" input/output (i.e. IR and video) capabilities of the TiVo, so it will work without mods and is largely immune to TiVo system software changes.
It's important to realize that remote desktop sharing/control is not the same thing as remote assistance. Desktop sharing is one tool, and a commodity one, that has been around a long time (Timbuktu, VNC, PCAnywhere,...).
To really have an alternative to traditional phone-based support, you need a lot more components. As has already been suggested, trust is a huge issue that has to be acknowledged and faced directly.
Who is going to provide the support? If everything is internal to a company, and employees are providing the help, it's a totally different world than if you're going to allow outside people to dynamically participate. If you do want to take advantage of outside people, you need to think about certification, validation, reputation, ratings, and everything else that lets you achieve the comfort level you need.
What communication mechanisms do you need? Chat is rarely enough, since it really only lends itself to the trivial, "one and done" type problems. A unified combination of chat, posted messages, email, and phone gives the most flexibility. You've also got to be able to re-enter communication after reboots, research, or even lunch breaks.
What commerce models do you need? Strictly internally, you may not really care since all employees are entitled to support at no charge. For supporting customers, there are many shades of entitlement and costs. What you really want is a way to associate different costs/prices with different severities/response times/requestors/etc.
What other support tools should be smoothly integrated? Do you need data gathering? Diagnostics? Or do you want to have to use the remote control to go and check the user's system configuration manually each time?
Slashdot Mirror
Talkback ALSO reports on any other error (or non-error) condition the developer cares about. It's easy, and common practice, to put a call to Talkback in an exception handler, for example.
There's even a mode that will cause Talkback to report to the server the first time the application is used. This makes it very useful to compare the number of downloads to the number of people who actually install it and run it at least once.
So even Microsoft's "unique" addition of responding to non-fatal errors still falls short of what Talkback-enabled products could do in 1997.
I am one of the two people who inveted Talkback (aka the Netscape Quality Feedback Agent).
We showed this technology to Microsoft early in 1998. We outlined the whole process, and nothing in their abstract describes any innovation over what we showed them.
The discussions in that meeting were held under NDA. As a small company, we had little choice but to use Microsoft's NDA. Their version allows them to use anything they "remember" as long as they don't disclose our specific confidential information.
We did get a patent for Talkback, one of several that were in the works before we sold the technology. Supportsoft now owns the technology and the patent.
I'm not saying that this is just another example of Microsoft having to rely on screwing small companies and coopting their innovations. You can decide that for yourself.
I can already program my TiVo remotely, and even watch what's showing (well, sorta). It didn't involve any modifications to TiVo, either, such as those required for TivoWeb.
However, it did require a bunch of equipment and a bunch of work. Basically, it looks like this--
The video output of the TiVo goes, via a switcher, to a PC that has an ATI All-in-Wonder card in it running, gasp, Windows 98. Software on the PC is my own program, and with a very long VGA cable, it acts as the TV & information appliance in my kitchen. Also on this PC is some basic webcam software that my program can start and stop.
I have a second PC dedicated to home automation running Linux. Connected to this PC is a box called an Ocelot, which, among other things, can send arbitrary IR commands. I use Xantech products to distribute the IR to the various pieces of equipment.
Finally, on the Linux box is a custom home automation server that manages all the home automation components, including the Ocelot. PHP-based web pages can talk to this server and cause it to send IR commands to my TiVo.
So, with a web page that includes the webcam output and some buttons to command the home automation system, I can interactively view and control my TiVo. It's a bit of a rube goldberg solution, but it only uses the "official" input/output (i.e. IR and video) capabilities of the TiVo, so it will work without mods and is largely immune to TiVo system software changes.
It's important to realize that remote desktop sharing/control is not the same thing as remote assistance. Desktop sharing is one tool, and a commodity one, that has been around a long time (Timbuktu, VNC, PCAnywhere, ...).
To really have an alternative to traditional phone-based support, you need a lot more components. As has already been suggested, trust is a huge issue that has to be acknowledged and faced directly.
Who is going to provide the support? If everything is internal to a company, and employees are providing the help, it's a totally different world than if you're going to allow outside people to dynamically participate. If you do want to take advantage of outside people, you need to think about certification, validation, reputation, ratings, and everything else that lets you achieve the comfort level you need.
What communication mechanisms do you need? Chat is rarely enough, since it really only lends itself to the trivial, "one and done" type problems. A unified combination of chat, posted messages, email, and phone gives the most flexibility. You've also got to be able to re-enter communication after reboots, research, or even lunch breaks.
What commerce models do you need? Strictly internally, you may not really care since all employees are entitled to support at no charge. For supporting customers, there are many shades of entitlement and costs. What you really want is a way to associate different costs/prices with different severities/response times/requestors/etc.
What other support tools should be smoothly integrated? Do you need data gathering? Diagnostics? Or do you want to have to use the remote control to go and check the user's system configuration manually each time?