Feedback & Questions on Bixby Support



@rubenaeg Thank you so much for the Bixby implementation. Great work!

Here is some feedback/discussion starters:

  1. I am adding Bixby support to an existing Alexa skill built with Jovo v2. My TTS responses contained SSML which Bixby didn’t like. By switching to Speech Markdown and using the Jovo Plugin for Speech Markdown (, unsupported tags were automatically removed. As Bixby adds additional SSML tags, Bixby support in Speech Markdown will make them available.

  2. In the Bixby Layouts doc, you show the following:

  message {
    template("#{value (response._JOVO_SPEECH_)}")

But that assumes that the text displayed on the screen and spoken by Bixby are text and not SSML. The SSML example should be something like this:

  message {
    template("#{value (response._JOVO_LAYOUT_.text)}") {
      speech ("#{value (response._JOVO_SPEECH_)}")

Maybe there needs to be a standard way to pass back SPEECH (i.e. SSML) for the speech and the equivalent text-only output for the template tag or for use in a Bixby Dialog file.

  1. If I want to pass back a JSON array of items from the Jovo intent handler to Bixby to show as a result view, is this.$bixbyCapsule.addLayoutAttribute the way to do that? Does it support arrays?

  2. For each Action.model.bxb file, you can specify the output as JovoResponse or a structure that extends JovoResponse. What is a good strategy for this? If most actions extended the JovoResponse with any action data (passed from the remote server) then developers could build views that matched the specific result. Alternatively, there could be a well-known property on a JovoResponse (i.e. response ID) which could be passed from the server and then views could be conditioned on that.

  3. Similarly, what is the long-term strategy for extending JovoLayout? Will it include lots of optional properties that grows as more actions are added or is there a way to define some key properties that could be reused in many different situations?

These questions have all resulted from work that I have been doing over the last few weeks on porting a voice app to Bixby. Your great work has got us here so far.

Thanks again,



Hey @marktucker,

sorry for answering this just now, the last weeks were really stressful, but now I want to take the time to respond to your feedback. First up, thank you for your kind words. The support for Bixby has been astonishing and I feel overwhelmed with questions for additional features. That being said, I really appreciate it and couldn’t have had imagined such a great response to the platform integration. :rocket: Regarding your feedback, please see my comments below:

  1. Great idea! The fact that Bixby only supports a handful of SSML tags is a bit limiting, and we already had an internal discussion about filtering the response for “invalid” SSML tags, but it isn’t of high priority at the moment.

  2. Great catch, will look into this one!

  3. The layout functionality is very rudimentary right now, but this.$bixbyCapsule.addLayoutAttribute() supports any value. So you can just pass an array as an argument like so this.$bixbyCapsule.addLayoutAttribute('array', [...elements]) and then access the property array in your capsule.

  4. If you want to match a specific view with your response, I’d say extending the JovoResponse is a solid way to do it. Not only will it make debugging easier by showing you the exact type of response returned, it will also help prevent clustering your view files. If you don’t want to add any features to the JovoResponse, but still want to specify the type of your response, you can use the role-of feature.

  5. I’m still not sure about this one. Personally, I think that we could add many helpers to a dedicated JovoLayout class, for text, lists and images alone. I’m not sure when you can expect this to be published, but it has a very high priority in the development pipeline!

I hope I could answer your questions, I’m looking forward to your thoughts on this.

Have a good one,