Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
refactor(web): stick product selector form actions to bottom (#1769)
## 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_ * 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. ## Testing - Tested manually --- Related to https://trello.com/c/ZdOMjg3r (internal link)
- Loading branch information