Provider Form Violates Usability Principles

[terezanovotna]

With the current pluggable provider work, I came across some demos demonstrating forms in MIQ. As new providers are being added to MIQ, developers are trying to be consistent with current form pattern, but that pattern does not follow PatternFly and even violates basic usability principles.

Usability Heuristic Problems

• when the user opens a form, red color appears and shows that the user has done things wrong even though he hasn't started typing
• required fields are displayed as "you made an error"
• when the user makes a mistakes, he is not directed to see where it happened and how to fix it

PatternFly has already existing pattern for this behavior as well as displaying errors .

Can we make it more user friendly? @dclarizio @Loicavenel @martinpovolny
Happy to provide guidance

[martinpovolny]

The current provider forms are broken and unfixable due to a number of issues and design flaws. We should rewrite one or two providers as a POC cleanly and with the proper UX and then decide what to do next.

[martinpovolny]

@Hyperkid123 has prepared a number of components needed (not only) by the provider forms here: https://github.com/ManageIQ/react-ui-components/tree/master/src/dynamic-form

[AparnaKarve]

@terezanovotna Currently, all angular based forms in MIQ (developed since 2015) follow this pattern where we show the invalid fields in red, right when the form loads.

We discussed this UX in V2V as well with Serena and team, and have made some good changes there like -

• When the form loads, Required fields would not be marked in red. They would have an asterisk (Name *) to indicate that they are Required
• Required fields would be marked in red only after the user visits the field and wanders away without populating the field.

So, since this is the approach that we are now taking, I would imagine, going forward we would need ALL forms in MIQ to adhere to this UX.

[terezanovotna]

Thanks @AparnaKarve for explanation!
If the provider work is prioritized, I would love to see your mentions in bullet points being implemented, which would add to usability and user-friendliness.

[martinpovolny]

So, since this is the approach that we are now taking, I would imagine, going forward we would need ALL forms in MIQ to adhere to this UX.

The provider forms are the first thing everyone (developer) trying to add a provider or add features or a new version of a provider needs to deal with. And we have the feedback from those people (negative).

We also have issues with bugfixes and code review in that area. (Noone wants to review those PRs.)

It's also one of the first parts of the UI a new user sees. There we could use the UX to make a good first impression.

From that perspective it's an important piece. So on your statement:

So, since this is the approach that we are now taking, I would imagine, going forward we would need ALL forms in MIQ to adhere to this UX.

I don't agree. We need to prioritize.

[dclarizio]

@martinpovolny @terezanovotna @AparnaKarve Sounds like the best plan is to POC one or two of the provider forms and use that as a basis for any new or refactored forms going forward. I know the provider forms were our first attempt at the more complex forms (using angular), so I'm sure a rewrite/refactor into react would be something we want to do first to create a pattern we can follow going forward.

[Loicavenel]

Good ideas here, I will suggest we start with RHV provider

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 6 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions!

[JPrause]

@terezanovotna is this still a valid issue? If yes, lease remove the stale label. If not can you close.
If there's no update by next week, I'll be closing this issue.

[terezanovotna]

@JPrause still an issue. We will definitely talk about this at CF 4.8 Planning meeting

[JPrause]

Thanks @terezanovotna
@miq-bot remove_label stale

[martinpovolny]

Definitely still an issue. However now it seems that we got enough progress with the data-driven forms that this can be revisited and fixed with those.

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 6 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions!

[Fryguy]

Will be part of the effort in ManageIQ/manageiq#18818

[gtanzillo]

Closing via ManageIQ/manageiq#18818