14.1p VoiceAssist feedback

Thanks for the feedback guys - we’re making some tweaks to add APIs for starting VoiceAssist on mobile and will port the feature to SGWT.

Blama, note that voice-commands are not an AI-only feature - you can write an override of doVoiceCommand() that takes a recorded command and parses it to provide voice-capabilities of your own for your app. For example, you might allow for user-commands like “menu {title}”, like “menu save”, where logic scans all menus for an item with that title, or commands like “show orders” or “report sales”, that show some specific UI or allow users quick access to parts of your app. If AI is available, the mechanism may invoke it to provide more powerful general functionality, but it can be used without AI to provide similar, targeted facilities.

Hi @Isomorphic,

interesting and good to know. I do think though that it should be possible to disable listening for voice commands, as the majority of your customers will have no-AI + no own Command implementation.
Or does this happen automagically when I hit triple-Ctrl and ISC_AI.js is not loaded and I did not override doVoiceCommand()?
It seems this might already work when supportsVoiceCommands() returns false, but I can’t see how this can be set.

Best regards
Blama

hi guys,

Blama:

  1. the “example-viewer’s toolbar” is the toolbar above the example-pane, where the Skin picker and Print button are. For the search box, in the top-left, you could focus it and then double-tap Control on desktop to fill in the value. On mobile, it should show the VoiceAssist icon naturally. Note that, if you have AI, the FeatureExplorer has a custom doVoiceCommand() implementation that detects requests for searches - so you could hold down control and say “show calendar samples” or “how do i use charts?”, and it will switch you to the sample-search panel, with an appropriate search string. You can quick-test the basic mobile behavior with an in-browser mobile emulator, or by setting Browser.isHandset to true on desktop (this isn’t valid in the real world, of course - just a quick test for default behavior)

  2. you can now set VA.canDictateValues and canDictateCommands, which will limit access to startDictatingValue/Command() (now public) respectively, and modify the content in the notify that gets shown when you call setActive(true) (either directly or via triple-tap)

MichalG:

  1. Please see the new docs for VoiceAssist - there are a bunch of new public APIs. In particular, the internal tripleTap() mechanism is replaced with VA.setActive(boolean). You would first enable VA by calling VA.enable() at the app level, then users would activate it with a button or whatever in your app, which would call VA.setActive(boolean) to start listening (on desktop) or showing the inline formItemIcon appropriately.

  2. Everything should now be available and working in SGWT, back to 14.1

I have tried:

voiceEnableButton.addClickHandler(new ClickHandler() {
            @Override
            public void onClick(ClickEvent event) {
                VoiceAssist.setActive(!VoiceAssist.getActive());
            }
        });

using v15.0d_2026-04-06/LGPL and looks like it is working as expected.
Thanks,
MichalG

Hi,
It would be helpful if VoiceAssist.setActive() method/function get callback parameter.
Thanks,
MichalG

This was a bit of a hole, given that setActive(true) is async and may take a second or two the first time it runs.

So, we’ve added an optional callback param - please retest with tomorrow’s build, dated May 15, or a later one.

Thanks for so quick reaction!
I assume that it will be also included in the 15.0d?
(the last 15.0d published version is from 9th of May)
MichalG

Yes it’s in 15.0 as well- a change was made yesterday to address the issue with the 15.0 nightly builds, so you should see today’s builds arrive.