Improve Form pages

[plante-msft]

Description of the new feature / enhancement

Form pages are a bit messy from both a UX and extension dev experience standpoint - we need to improve them to meet the following requirements:

• Extension developers can specify one or more fields and field titles to be included in the form
• Devs can provide clickable button information and associated action on user click
• Users can insert text data into each field

Scenario when this would be used?

Example scenario:

A user wants to create a quicklink to search a certain website quickly from CommandPalette. A user can enter in the base url and fields via text boxes in the form page, and on click, the quicklink is created as a new command.

Supporting information

No response

[zadjii]

@plante-msft Can you clarify what's different between this issue, and something like #123 / #141?

Pretty sure forms can do all of this today

[plante-msft]

This one might have been opened late from an issue list that @joadoumie and I had from after the hackathon. From the #141 it seems like these requirements are largely met so I'm fine to close this.

[plante-msft]

If we need a separate issue in the future for improving the UX design of FormPages specifically, I can open one.

[joadoumie]

Settings helpers are great, AND I think this is actually maybe something that will come up over time of "it's just JSON" but it's messy. One missed comma, leads to a lot of noisy debugging. I feel like maybe just a standard we use where the JSON snippets are stored as their own .json files and we can help folks parse that file properly. Maybe a documentation + guidelines situation for now until we get dev feedback.

[plante-msft]

Can't we help check this though? There must be methods/parsing libraries out there that check for malformed JSON and we can throw the right error at runtime in that event, no?

[joadoumie]

Yeah I think we should catch at compile time though and/or in the IDE itself before building so it's clear to the developer what is going wrong so they can fix it right there before running. I feel like some tweaking of the solution's analyzers would be a reasonable approach but not sure how we'd want to discern between adaptive card JSON vs just regular old JSON.

@krschau and I were chatting at some point about some additional potentially cool outcomes too:

• using adaptive card visualizer but in some integrated way for folks to visualize what their JSON looks like (would still need clear indicators for when things are formatted badly). The best most costly thing would be adaptive card designer visual studio extension that would be kinda like the xaml live preview.
• throwing in a web view only in a special command like the create extension command that uses the web adaptive card designer (web views in general in cmdpal seem wrong though to me still) so I'm less interested in this idea than the first one.

[zadjii-msft]

it's just JSON" but it's messy. One missed comma, leads to a lot of noisy debugging.

that check for malformed JSON and we can throw the right error at runtime in that event, no?

Guys yea, I already did #101 in #132

using adaptive card visualizer but in some integrated way for folks to visualize what their JSON looks like

You mean like #116

throwing in a web view

HARD VETO.

[joadoumie]

Oh wow. That was fast 😮.

As for #116 I'll move any additional convos there, because I'm not sure I follow it all but seems right.