microsoft / BotFramework-Composer

Dialog creation and management for Microsoft Bot Framework Applications
https://docs.microsoft.com/en-us/composer/
MIT License
870 stars 371 forks source link

"Create a skill in your bot" should be renamed to "Add a new skill" #7115

Closed sgellock closed 3 years ago

sgellock commented 3 years ago

Describe the bug

When you have an existing bot project open and you go through the flow to create a new skill, the title of the dialog we display is "Create a skill in your bot". We don't create anything in a bot. We are actually adding a new skill to a bot projects.

Using Visual Studio as a guild, that use very simple language which would equate to "Add a new skill" or if we love the verb create, calling it "Create a new skill" would work as well.

Version

Version: 1.4.0-nightly.236490.3735dd3 Electron: 8.2.4 Chrome: 80.0.3987.165 NodeJS: 12.13.0 V8: 8.0.426.27-electron.0

Browser

OS

To Reproduce

Steps to reproduce the behavior:

  1. Launch Composer
  2. Open an existing bot project
  3. From the main authoring screen, click the "+ Add" menu item at the top of the project window
  4. Click the "Create a new skill" menu item, this will launch the dialog of I referring to
  5. Note the title of that modal.

Expected behavior

A more simplified title that more accurately represents the action and purpose of the modal

Screenshots

Screen Shot 2021-04-19 at 1 43 30 PM
emivers8 commented 3 years ago

I think "Add a new skill" is good--consistent with the button that got them in the modal.

mewa1024 commented 3 years ago

(Adding @vivekkshankar since he's working on the UX for the skills flows).

But can we just reuse the modal from the "+ New" (New project). It has the conveniently generic header of "Select a template": image

mewa1024 commented 3 years ago

related question, after the template picker modal, Composer shows the "Create a bot project" modal: image

which creates a new bot project rather than just a bot. Is that intentional?

I got an error, so I don't know if this is the intended behavior, but the folders appear in my MRU list (bot project within the bot project is highlighted):

image

I tried this on Version: 1.4.0-nightly.236875.b9e46c2

mewa1024 commented 3 years ago

@clearab do you know if the intended behavior for creating a new skill/bot is to create a bot project?

emivers8 commented 3 years ago

Hmm, also, should you really be able to add an Enterprise skill to an Enterprise project, for example? I understand not wanting to be overly restrictive if people want to do weird stuff, but this doesn't feel like it's guiding me to selecting an appropriate template choice for a skill.

mareekuh commented 3 years ago

+1 on @mewa1024 's suggestion. Any dialog or modal should capture what the user is looking at or supposed to do. The 2nd line can add further content or more detailed instructions.

clearab commented 3 years ago

Some thoughts and responses:

mewa1024 commented 3 years ago
  • Currently, you aren't adding a skill, you're just creating a new bot in your bot project. Not sure if the new skill flows change this behavior, but saying "add a skill" is misleading currently (@darrenj may want to comment)

@clearab if I understand you correctly, the intended experience should be to allow users to just create a new bot in your existing bot project? In 1.4.0-nightly.236875.b9e46c2, it looks like we are doing the opposite--we create a new bot projec and don't provide any way to create just a bot in your existing project.

This is what I got when I created a blank bot (empty_0419) and added a new blank bot as a skill to it (emptyskill2). Composer created a emptyskill2 project within the empty_0419 project instead of providing an option to create just the skill: image

sgellock commented 3 years ago

We are kind of getting confused because we have a bot project, and it actually behaves like a visual studio solution. If you look at multi-asset constructs in VS and where they use the term "solution" you replace that with what we call a "project" you'd get the following model.

The project is kind of invisible. We don't ask our users to create them. We don't have something called an "empty bot project" which literally is an empty project with no other assets. Don't confuse this term with what we've long called Emptyh Bot. Visual Studio allows a developer to create a completely solution, and then later add application assets. I think our decision to auto create the bot project upon first bot creation is totally fine.

The very first bot, by default creates a project. it's named the same as the bot. it serves as a container for multiple assets, though having multiple assets is not required. In this context, I'm using the term assets to mean, you can create a single bot (1 asset), and the bot project will contain that single bot. I can create an enterprise assistant, and that bot project will contain 3 assets (1 bot + 2 skills).

When I have a bot project, due to having previously created a bot, and I decide to add an additional asset to the "project" the choice we are presenting to the use is to add a skill, in 1 of three forms. when the user performs this action, they have a single bot project that now has two assets. the bot and now a new skill.

Because we don't ask the user to create a project, and because one is created for the user upon the initial bot creation, we should decide if we ever want to surface the term "project" in our experience. I would suggest that using the term "project" in our experience is meaningful in two places.

  1. The home screen's MRU list is not a list of bots. It's actually a list of Bot Projects. If I have a project that has 1 bot and 1 skill, the current heading used for this list doesn't capture that. Changing the heading of the home page MRU from "Recent Bots" to "Recent Bot Projects" seems more appropriate.
  2. once I open a bot project, the left hand tree control, the panel that shows the bot name, the dialogs the bot has, and the triggers the dialog handles, is actually a project view. when there is more than one bot asset here, say 1 bot and 1 skill, you are looking at the contents of the bot project as the top level, and then are drilling into the details of the conversational assets for each bot within that project.

I find the Add drop down kind of confusing. When I see the verb "Add" I'm expecting to add things to my project. What I actually as being asked to do is "Add a Create..."

Screen Shot 2021-04-19 at 7 16 57 PM

What would seem more natural to me would be: Add -> A New Skill Add -> A Local Skill Add -> A Remote Skill

The act of "Add -> A New Skill" would display our new "create from template modal", with a title that maps to the action I just selection. e.g. Add a new skill.

I also think this flow, beyond the terminology is making an assumption I'm not sure is valid. And the assumption is this: Can I take every New Bot Template that we produce and have its root bot actually work as a callable skill? I'm 100% certain the enterprise assistant hasn't be deployed as a skill that is callable by another bot.

And that leads to the second modal that @mewa1024 highlights above. In the Add new skill flow we are not adding a project to a project. we are adding a bot and a manifest to an existing bot project. so yes, the title of this modal is not correct in this flow.

Regarding the Add a new bot or add a new skill discussion that is happening earlier in the thread. The action the user selects is using the term "skill". "Create a new skill". So I would expect if I select this that I'm going to get what's required to have a skill, meaning I would expect to have a manifest. what I wouldn't expect is that I get another bot, and then have to take the following action in order to make it a skill.

Screen Shot 2021-04-19 at 7 27 20 PM
cwhitten commented 3 years ago

It seems that a sensible solution here would be for the Creation UX to offer including a skill manifest with the generated assets, and for the templates/generators to support this. It should feasibly layer into any existing template, beyond the complex template like Enterprise Assistant for reasons outside the scope of this discussion.

This is the right northstar aim as well. We want users to be authoring and leveraging skill manifests when authoring local skills as well as working with remote skills.

cwhitten commented 3 years ago

Posting @mewa1024's comment here:

Summary: in the current build of Composer, we have 3 options for adding skills: (1) "Add new skill, (2) "Connect to local skill", (3) Connect to remote skill". We are combining 1 and 2 into one menu, with the fork between new local skill/bot or existing local skill/bot moved into the flow:

  1. Choose option to "Add bot"
  2. Choose the bot, then
    • Select an existing bot: DONE WITH THIS FLOW, or
    • Choose to create a new bot: we select the blank bot (not shown in the UI), Composer shows a modal to provide name, description, runtime type and location of the new bot (same as the second modal in the Creation flow)

The UI is just iterations of the same steps--the only difference is the prominence of the ability to create a new bot while in the flow of adding a bot to your project.

RE: design/figma choice -- Option C

mewa1024 commented 3 years ago

Option C: https://www.figma.com/file/4kfahZUjBdrxdDGZih7PVP/Composer-1.5-E2E-flows?node-id=802%3A53854

image

mewa1024 commented 3 years ago

Just want to clarify, are when user goes through the of "Add bot > Create a new bot" are we creating this for them? image

or just the stuff selected here: image

pavolum commented 3 years ago

@mewa1024 the first one

mewa1024 commented 3 years ago

Thanks! that's what I thought, but just wanted to check.