- From: Satish Sampath <satish@google.com>
- Date: Wed, 3 Nov 2010 15:04:35 +0100
- To: Olli@pettay.fi
- Cc: public-xg-htmlspeech@w3.org
Thanks for the comments Olli. Some replies inline below: > In the examples the code > <input ... onspeechchange="startSearch"> doesn't work. > It should be > <input ... onspeechchange="startSearch(event)"> Makes sense. > I don't quite understand why you have decided to bind speech results > automatically some seemingly random input element types. > Why not just have something more generic and let the page author to > set the value to whatever element she/he wants to. > Making the classical "multimodal pizza" example to work using the > proposal would need some hacks; first get the value to some input element, > and using script set the value of checkboxes and radiobuttons. We've tried to limit the allowed input types mostly allow free form text input. Do you have anything in mind as to how a more generic API might look like? > Related to this, 5.6 is a bit odd. Why should input element work differently > than textarea? Even if there was automatic speech > recognition result binding to input element, I'd assume, that for > example saying a phone number, number by number, should work. The motivation here was the typical usage of these 2 different controls. Single line input fields are typically used for words and short phrases whereas textarea is used for complete sentences and paragraphs. Do you think inserting the text at the current caret position in both cases is sufficient? > I don't quite understand SpeechInputResultCollection.feedback(). > What is the use case for that? If the web app displays the n-best list to the user and allows them to select a different result than the top one, the web app can invoke the .feedback() method with the newly selected result. This is to provide feedback to the speech service that the user preferred a different item than the top one in the results. > 'continue' may cause some UI problems. > The UI must do something like start the recognition when there is a > mousedown, and stop it when there is mouseup. Otherwise user might not > realize that the recognizer is on; for example if someone interrupts the > user so that she/he doesn't look at the screen for awhile and > doesn't notice that the recognizer is running. I agree that 'continue' is tricky to get right.. mousedown/mouseup is an interesting idea, though it can be unwieldy to have the mouse button pressed for more than a second or two. -- Cheers Satish
Received on Wednesday, 3 November 2010 14:05:08 UTC