Yes and no. There are a few tradeoffs there; some have workarounds, but the workarounds have costs.
One is that the voice signal quality cellphones support is nowhere near as good as you can get with a good local microphone and signal processing. That will degrade the speech recognition quality and drive up the computational cost.
Another is that it's reasonably easy to personalize the speech recognition system in a PDA, where so much of the system is intended to be personalized; it takes more server-side support to personalize the speech recognition system for every client of a cell-phone service.
In the PDA/phone realm there's also the question of whether you want your PDA's input functionality to depend on whether you have a cell tower in range.
I used to work on speech recognition, for both large and small systems. Variations on this have been done for a while at a number of places. Small vocabularies are easier to deal with, but if you're dealing with more than a tiny vocabulary, there are a bunch of interesting problems, some of which are specific to handhelds.
Processing power: this is a nuisance. It's not that you can't get enough processing power into a handheld or cellphone these days, but:
You can't get the resources you can on a desktop, which means you're likely to do worse on large vocabulary tasks than desktop products.
The cost of the processing power makes it hard to put the speech recognition where you really want it. (Someone else mentioned cell-phones: in the U.S., at least, all but the highest-end cell phone hardware is extremely cost-sensitive, since it winds up being subsidized by service providers. Does higher-end speech recognition offer enough value to offset the added hardware cost?
User expectations (a.k.a., the Star Trek problem, a.k.a., even that clunker without circuit breakers that Kirk talked to could always understand him perfectly): This is a general speech-recognition problem, but it gets more intense the more mass-market you go. Palm pilots are largely successful because they don't try to do too much, but do what they do well. It's hard to set that kind of expectation reasonably for nontrivial speech recognition. Even worse, I think that people are actually more demanding of a self-contained special-purpose device (with more limited resources, as above) than they are of general PC software.
User interface design: this is still a largely unsolved problem; how do you really want to interact with a PDA by voice? It's hard to arrange a device so you can look at it and be close to the microphone at the same time, which complicates the picture. Dragon Systems back in their pre-acquisition days sold a product called "Dragon NaturallySpeaking Mobile Organizer" that was an interesting step along the way. They didn't put the speech recognition into the handheld -- speech was recorded into a handheld recorder, recognized on a PC and synched up with PDA later -- but the product did attempt to deal with the interface questions of large-vocabulary PDA-based speech recognition; e.g., when you say something, is it intended for your calendar, your email, or your address book? How many variations of "next Tuesday" can the device understand? The general interface problem, once everything's in the same device, is still open and interesting.
But if your database is currently dominated by ASCII or even typical Latin-1 text, that's a reasonable tradeoff; no increase for ASCII text, a slight increase for Latin-1 text (100% on a minority of the characters in actual text; anyone have actual stats handy?), 50% increase for the rest of the 16-bit range, and the same maximum character size (U+10000 - U+1fffff take 4 bytes in both UTF-8 and UTF-16). And then you have the other advantages already mentioned: compatibility with 7-bit ASCII, NUL-terminated C strings, and ordinary 8-bit clean text channels. If you're currently in the ASCII or Latin-1 domain the question isn't even what you expect to store in the future, so much as how much cheaper disk space will be when you finally need to store it.
Thinking of collecting donations for this currently nonexistent PAC: All we need is the mouse-click equivalent of a 900 number; say, an Amazon one-click donation link, or the equivalent. Then we get the URL posted in a lead article on/. and the/. effect produces an instant lobbying fund, the money supporting efforts against strategies like this so we can prevent anyone else doing the same thing.
Laws and sausages are made much the same, but sausages are better with mustard.
Design flaws are less a product of programming methodology, and more a product of not completely knowing the problem. [...] Sometimes the lack of a working crystal ball can be a real nuisance.....
For this purpose, I have a working crystal ball; it always says "Reply Hazy, Try Again." It's never wrong.
You never know the full set of requirements and constraints for any nontrivial project; what does help is to assume that you've got it wrong. That implies:
Version information should be the first thing in any interface.
Persistent formats are part of your interface (where persistent means "outliving a single invocation of a single executable" not "intended to be exposed to the user").
Assume that every interface will be used. This implies that interfaces should made as few and as well-defined as you can get away with, for when you have to put in backward compatability layers.
You can't know what your users want, because they don't know it themselves. But make sure you know who they are, so you'll know what you're breaking when you have to break things.
When the above is applied to developer interfaces, I'd also add:
You have to be cruel to be kind: when clients exceed your spec, die. Die hard; die fast; and leave a good-looking corpse (i.e., a clear error report.)
This is all a pain in the neck. There are tools that make some of it easier; e.g., some of the OO frameworks people have mentioned elsewhere include versioning facilities, if you think to use them. None of the tools handle the general design problem, though, and some are actively damaging in that they attempt to be as permissive as possible to the user, regardless of what this does to future compatibility efforts. Remembering that you've almost certainly got it wrong and you're going to have to fix it later can make it a lot easier to do that fix. And the next one.
Slashdot Mirror
Processing power: this is a nuisance. It's not that you can't get enough processing power into a handheld or cellphone these days, but:
User expectations (a.k.a., the Star Trek problem, a.k.a., even that clunker without circuit breakers that Kirk talked to could always understand him perfectly): This is a general speech-recognition problem, but it gets more intense the more mass-market you go. Palm pilots are largely successful because they don't try to do too much, but do what they do well. It's hard to set that kind of expectation reasonably for nontrivial speech recognition. Even worse, I think that people are actually more demanding of a self-contained special-purpose device (with more limited resources, as above) than they are of general PC software.
User interface design: this is still a largely unsolved problem; how do you really want to interact with a PDA by voice? It's hard to arrange a device so you can look at it and be close to the microphone at the same time, which complicates the picture. Dragon Systems back in their pre-acquisition days sold a product called "Dragon NaturallySpeaking Mobile Organizer" that was an interesting step along the way. They didn't put the speech recognition into the handheld -- speech was recorded into a handheld recorder, recognized on a PC and synched up with PDA later -- but the product did attempt to deal with the interface questions of large-vocabulary PDA-based speech recognition; e.g., when you say something, is it intended for your calendar, your email, or your address book? How many variations of "next Tuesday" can the device understand? The general interface problem, once everything's in the same device, is still open and interesting.
Riff: "Straight-pins vs. inflatable technology: the straight-pin always wins" [sluggy.com]
But if your database is currently dominated by ASCII or even typical Latin-1 text, that's a reasonable tradeoff; no increase for ASCII text, a slight increase for Latin-1 text (100% on a minority of the characters in actual text; anyone have actual stats handy?), 50% increase for the rest of the 16-bit range, and the same maximum character size (U+10000 - U+1fffff take 4 bytes in both UTF-8 and UTF-16). And then you have the other advantages already mentioned: compatibility with 7-bit ASCII, NUL-terminated C strings, and ordinary 8-bit clean text channels. If you're currently in the ASCII or Latin-1 domain the question isn't even what you expect to store in the future, so much as how much cheaper disk space will be when you finally need to store it.
Thinking of collecting donations for this currently nonexistent PAC: All we need is the mouse-click equivalent of a 900 number; say, an Amazon one-click donation link, or the equivalent. Then we get the URL posted in a lead article on /. and the /. effect produces an instant lobbying fund, the money supporting efforts against strategies like this so we can prevent anyone else doing the same thing.
Laws and sausages are made much the same, but sausages are better with mustard.
Some more sketchy details I haven't read here yet, soon to be invalidated I'm sure:
One of the planes was AA flight 11 BOS-LAX, a 767.
Both of the WTC towers are now down.
Another plane (?) hit the Pentagon, and part of that has collapsed.
There was a threat against the Capitol; Capitol evacuated.
And there was a car bomb (?) outside the state dept.?
Another hijacked plane is now travelling along the East Coast being trailed by an F16.
You never know the full set of requirements and constraints for any nontrivial project; what does help is to assume that you've got it wrong. That implies:
- Version information should be the first thing in any interface.
- Persistent formats are part of your interface (where persistent means "outliving a single invocation of a single executable" not "intended to be exposed to the user").
- Assume that every interface will be used. This implies that interfaces should made as few and as well-defined as you can get away with, for when you have to put in backward compatability layers.
- You can't know what your users want, because they don't know it themselves. But make sure you know who they are, so you'll know what you're breaking when you have to break things.
When the above is applied to developer interfaces, I'd also add:- You have to be cruel to be kind: when clients exceed your spec, die. Die hard; die fast; and leave a good-looking corpse (i.e., a clear error report.)
This is all a pain in the neck. There are tools that make some of it easier; e.g., some of the OO frameworks people have mentioned elsewhere include versioning facilities, if you think to use them. None of the tools handle the general design problem, though, and some are actively damaging in that they attempt to be as permissive as possible to the user, regardless of what this does to future compatibility efforts. Remembering that you've almost certainly got it wrong and you're going to have to fix it later can make it a lot easier to do that fix. And the next one.