Back in the time, It was internally proposed to have a different layout for easily distinguish between screens that allow users to fine tuning the installation of the selected product from the rest of screens.
The idea was to easily give the user a sense of different context in order to avoid mixing the product selection or installer settings with the configuration of installation itself. A good idea, to be honest.
When the Agama UI was completely changed to a more PatternFly layout, we tried make it a reality by applying below changes when user visiting a route out of the installation settings scope
No topbar title (probably a mistake)
No topbar actions (a mistake)
Using same background for topbar and main content in an attempt of creating the illusion there is no topbar at all
Using neither, footbar nor sidebar.
Although not perfect, the above allowed to create such a visually context change
Quickly, we realize we needed the topbar actions in these layout too to allow users Download the logs (along other global actions) from the same place across all Agama screens.
Problem
Not a problem at all, but perhaps a minor inconsistency: while the permanent sticky footer was completely dropped, Agama still keeps the main actions fixed at the bottom of viewport when users are selecting from a long list within the installation settings scope. E.G., when selecting a keyboard layout, a language, or even software patterns.
In contrast, this behavior changes when selecting a product, where the "Accept" and "Cancel" actions might fall out of the viewport depending on several factors like screen size, resolution, orientation, or zoom level to name a few.
This isn’t a major issue, as we’re using a simple, well-structured HTML form that users around the world are familiar with: a list of options presented as a radio button group that supports keyboard navigation, including submitting the selected option by pressing "Enter."
That said, maintaining consistency with the rest of the UI by keeping the form actions always visible at the bottom of the viewport wouldn’t hurt (or at least it shouldn’t). Still, this approach is far from ideal when it comes to truly helping users complete the task at hand. Additionally, I’m concerned it might lead to yet another scroll complaint (more on this in an upcoming discussion).
Solution
Force product selection form actions to be stick at the bottom of viewport.
Context
Back in the time, It was internally proposed to have a different layout for easily distinguish between screens that allow users to fine tuning the installation of the selected product from the rest of screens.
The idea was to easily give the user a sense of different context in order to avoid mixing the product selection or installer settings with the configuration of installation itself. A good idea, to be honest.
When the Agama UI was completely changed to a more PatternFly layout, we tried make it a reality by applying below changes when user visiting a route out of the installation settings scope
Although not perfect, the above allowed to create such a visually context change
Quickly, we realize we needed the topbar actions in these layout too to allow users Download the logs (along other global actions) from the same place across all Agama screens.
Problem
Not a problem at all, but perhaps a minor inconsistency: while the permanent sticky footer was completely dropped, Agama still keeps the main actions fixed at the bottom of viewport when users are selecting from a long list within the installation settings scope. E.G., when selecting a keyboard layout, a language, or even software patterns.
In contrast, this behavior changes when selecting a product, where the "Accept" and "Cancel" actions might fall out of the viewport depending on several factors like screen size, resolution, orientation, or zoom level to name a few.
This isn’t a major issue, as we’re using a simple, well-structured HTML form that users around the world are familiar with: a list of options presented as a radio button group that supports keyboard navigation, including submitting the selected option by pressing "Enter."
That said, maintaining consistency with the rest of the UI by keeping the form actions always visible at the bottom of the viewport wouldn’t hurt (or at least it shouldn’t). Still, this approach is far from ideal when it comes to truly helping users complete the task at hand. Additionally, I’m concerned it might lead to yet another scroll complaint (more on this in an upcoming discussion).
Solution
Force product selection form actions to be stick at the bottom of viewport.
Testing
Related to https://trello.com/c/ZdOMjg3r (internal link)