Community
Participate
Working Groups
I've attached a patch that adds text input to VoiceXMLBrowserInputView.
Created attachment 97451 [details] add text input to VoiceXML Browser view forgot to fill all the description when I submitted the bug
I have downloaded this patch and applied it to the current VoiceXMLBrowserInputView. In live test, the results look very good. I am not able to check functionality (passing text to browser), but the UI is good. I suggest an alternative UI, however: In the present implementation, the text input box is quite small, and off to the left of the area that displays the log output from the browser. It has been proposed to allow for toggling the log display on/off to enable the text box to be larger. Instead, let's place the text box above the log display, and the full width of the log display. Then when the view's maximize button is pressed, the whole view gets bigger, text box and log display alike. I think this is fine, because when debugging, one is more interested in the log results than in other views of the application, so the display real estate can be given over to the input view. I will work up the code for that soon. Why can I not reassign this bug to myself?
I have prepared code to create the alternative UI that I suggested in my previous comment. I have attached a couple of screen captures showing the InputView window with and without the CAPABILITY_TEXT. Please look these over and indicate whether this will be satisfactory. Then I can commit the code.
Created attachment 104125 [details] image of proposed browser input view window when there is no CAPABILITY_TEXT This image shows the voice browser input view window when the browser does not have CAPABILITY_TEXT. This should look like the unmodified, existing window.
Created attachment 104127 [details] image of proposed browser input view window when there IS CAPABILITY_TEXT This view shows my suggested changes to the previous code to move the INPUT text box above the log display area. This is conditional on the CAPABILITY_TEXT property of the voice browser. Note that when the window is resized, the text box and the log display resize with it.
another feature that it might be useful is to have inside the text panel is a multi line text box that will show the user/browser conversation. I realize that the log window might have that information but it will look nice when you debug the application
Aaah, creeping featurism appears. Let's get all the requirements on the table before going any further. It would be pretty hard to design a reasonable UI that has two unbounded, resizable text displays in a small window such as is available. I strongly recommend that the Log display table be used for the purpose of displaying the sequence of text input and responses. They could be tagged somehow to stand out among the log entries so they are easily readable among any other cruft that might also be shown. OR, a filter could be proposed so that activating the filter causes only the browser input/output to be shown, suppressing the technical log messages.
I consider having the text input/outbut boxex the basic standard for a VoiceXML browser that supports CAPABILITY_TEXT. What I propose is designing the UI in a diffrent way to get more screen space: will create two tabs one that has the dtmf input and text input/output boxes and another one that will have the debug logs Will this approach works better?
(In reply to comment #8) > I consider having the text input/outbut boxex the basic standard for a VoiceXML > browser that supports CAPABILITY_TEXT. > Of course! As was suggested, my code displays the text input/output boxes if the browser has CAPABILITY_TEXT, and not otherwise. > What I propose is designing the UI in a diffrent way to get more screen space: > will create two tabs one that has the dtmf input and text input/output boxes > and another one that will have the debug logs > > Will this approach works better? > I do not have available to me a browser that has the capability, so it is difficult for me to quite see how that would actually work out in practice. I suggest that the first rule for your design is that the current view open first and the second tab is to be chosen separately. If you want something different from what I have done, feel free to code away. I have not yet checked in my code that corresponds to the images I attached to the bug. Let me check that code into the jvoicexml branch of the SVN repository, and then you can take off from there.
