Looked at defining the connected scenes effort, now considering a smaller effort less about upfront design and more about visualizing based on what's in the Studio.

Continuing on defining that effort today.
Also looking at supporting upcoming IDE release with content for the resource library and website.

Content around the IDE, including a diagram of the Rasa components. Lookin got wrap that up today, as well as the definition of the next big design effort (formerly connected scenes).






Worked with Seth on new navigator and sample dialogs.
Wrapped up IDE content for the home page and resource library.

Work with Annie to get home page changes ready to go on staging.
Wrap up definition of the new design effort.





Forest-for-the-trees: It’s very difficult to fully understand an app and the conversations it supports from looking at Rasa artifacts. 
Stale artifacts: “Design” artifacts that teams create convey those insights, but those are hard to keep up-to-date, especially when using highly iterative CDD.
Turn-at-a-time: Functioning app release reveals only one turn of one path at a time; not overview or branching.
Path-at-a-time: The Studio’s sample dialog context view shows only one path at a time; understanding branching requires comparing the various paths. 




affirm
ask_transfer_charge
check_balance
check_earnings
check_recipients
deny
goodbye
greet
help
human_handoff
inform
out_of_scope
pay_cc
search_transactions
thankyou
transfer_money

Capture enough of the design intent to
- communicate with stakeholders
- build out the details later

Managing Content in Jargon
- Jargon's content model
-- *Interaction/Domain Model and Training Data*
-- Structured Responses
-- Standalone Resources
-- Managing content in Jargon (?)
-- Managing other app elements in Jargon (optional)

Publishing Content Changes
- Authoring content
- Authoring responses
- *Authoring interaction and domain model components*

*Domain Model and Training Data (Rasa)*
- Intents
- Slots
- Forms
- Entities
- Synonyms
- RegEx
- Custom Actions
- Rules
- Stories



Something I think we need to deal with is the overlap between Responses and Other App Components. "App responds" can mean a regular response, a form-related response (otherwise the same) or a custom action. If I want to know Jargon doesn't limit my ability to create "custom" content/responses (custom actions), I probably want to see that mentioned under responses (without "custom actions" being fully described there, but probably cross-linked at the minimum.
The other part of this I think is clarifying (in both sections) how they are explicitly different, i.e. things that do and don't require retraining/involving devs etc.














Not a design tool. Not a simulator.






Do we keep investing in voice? Do we keep putting it on equal footing in the product?


Less self-onboarding.
More onboarding to project by invitation.
More need for multilingual.
More opportunity for in-person support.
More collaboration.









Bell
- What languages?
- What platforms and channels? Voice and chat?
- How many teams?
- Type of apps?
- Review/approval process?
- Rasa experience?
- Varies by province?
- Current conversational apps?
- State of design/development?
- What kind of variation do you plan (initially) vs always same for everyone?
- 20 users




Good amount of items that are no longer relevant in Clubhouse.



* ignore all entities








Visualizing the app and its connected dialogs. 
Autocomplete











Taking the abstract components in the Studio, and visualizing how they stitch together into connected sample dialogs (generated).

Reassess core product improvements in light of Bell.

Are we offering enough for managing a multi-lingual app? How can we help the Bell team translate what needs to be translated, without completely starting over again and not having things synced?




Platform for conversational apps.
Chatbots, voicebots and multimodal apps.





Decision to use sample dialogs only for Stories, rather than what it was designed for: responses and intents.






utter_ask_email
What is your email address?

utter_ask_incident_title
What should we use for the title of this incident?

utter_ask_problem_description
What is the problem description for the issue?

utter_ask_priority
What is the priority of this issue? Buttons: low, medium, high

utter_ask_use_previous_email
Would you like to use the last email address you used, {previous_email}?

utter_ask_confirm
Should I open an incident with the following details? email: {email} / problem description: {problem_description} / title: {incident_title} / priority: {priority}" 
buttons: Yes / No, cancel the incident







(M&S on Friday) focusing on new messaging & visuals for IDE introduction
Pulling together fixes needed before onboarding Bell
Continuing with visualization of an app & its dialogs






Jargon combines the power of an IDE and CMS is optimized for the unique demands of building logic and managing responses in a collaborative space.

Creating successful conversational apps is hard.  Jargon gives your team full control with powerful IDE and CMS capabilities, optimized for the unique challenges of conversation-driven development.




Catch and fix errors
 - syntax
 - semantic (gaps, misspellings)
Speed up creation
 - auto-suggest
Integrated