We are concerned about the User Experience we are delivering with Konveyor in regard to enabling/disabling certain features as "default" with an install.
We currently have features that are implemented and available to an end user, but are intentionally disabled and not rendered in the webUI unless an Administrator explicitly modifes the configuration to enable.
An example is with the new ability to download analysis reports. By default this functionality is disabled AND hidden from the Migrator perspective:
An Administrator can login and change to the Administrator view and go to 'General' configuration to Enable downloads for HTML reports
Now, going back to Migrator view, the Download report: HTML link appears
Why is this a problem?
We are worried that disabling functionality may lead to friction in user experience, but even more than that the pattern we've adopted of disabling and NOT rendering features in the webUI hides the capability, reducing the likelihood a new user will be able to explore and learn on their own without reading documentation.
On the flip side, we recognize there are enterprise production users who will want the default values selected and may want those features not rendered to keep the UI 'clean'.
This appears to be an issue of differing perspectives of intended usage scenarios that are in conflict with each other.
For example we have at least 2 different usage scenarios identified (probably more will emerge):
Enterprise production install: Favors 'security' so some features are desired to be disabled
Upstream trial exploration: Favors all features being available to help gain a sense of solutions capabilities
Proposed solutions to consider
Introduce a 'profile' to group default values for initial install
Allow grouping default configuration values into a concept of 'profiles'
From the Operator CR we can select which 'profile' we want which will only affect the default values to be seeded, i.e. after Konveyor has been installed we wouldn't intend to watch the 'profile' value and update if a user changed the CR's 'profile' to a different profile value.
What is the problem?
We are concerned about the User Experience we are delivering with Konveyor in regard to enabling/disabling certain features as "default" with an install.
We currently have features that are implemented and available to an end user, but are intentionally disabled and not rendered in the webUI unless an Administrator explicitly modifes the configuration to enable.
An example is with the new ability to download analysis reports. By default this functionality is disabled AND hidden from the Migrator perspective:
An Administrator can login and change to the Administrator view and go to 'General' configuration to
Enable downloads for HTML reportsNow, going back to Migrator view, the
Download report: HTMLlink appearsWhy is this a problem?
We are worried that disabling functionality may lead to friction in user experience, but even more than that the pattern we've adopted of disabling and NOT rendering features in the webUI hides the capability, reducing the likelihood a new user will be able to explore and learn on their own without reading documentation.
On the flip side, we recognize there are enterprise production users who will want the default values selected and may want those features not rendered to keep the UI 'clean'.
This appears to be an issue of differing perspectives of intended usage scenarios that are in conflict with each other. For example we have at least 2 different usage scenarios identified (probably more will emerge):
Proposed solutions to consider
Introduce a 'profile' to group default values for initial install
Allow grouping default configuration values into a concept of 'profiles' From the Operator CR we can select which 'profile' we want which will only affect the default values to be seeded, i.e. after Konveyor has been installed we wouldn't intend to watch the 'profile' value and update if a user changed the CR's 'profile' to a different profile value.