Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor(web): stick product selector form actions to bottom #1769

Merged
merged 2 commits into from
Nov 15, 2024

Conversation

dgdavid
Copy link
Contributor

@dgdavid dgdavid commented Nov 15, 2024

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)

@dgdavid dgdavid requested a review from imobachgs November 15, 2024 08:56
@dgdavid dgdavid merged commit d3a3e92 into master Nov 15, 2024
5 checks passed
@dgdavid dgdavid deleted the fixed-product-selection-actions branch November 15, 2024 16:53
dgdavid added a commit that referenced this pull request Jan 8, 2025
## Problem

The `Cancel` action at product selection page should be only rendered if
there is a product already selected. By mistake, such a behavior was
drop in #1769, when sticking
actions to the bottom of the page.

## Solution

Restore the conditional rendering for the mentioned action and add a
unit test to be aware if come change breaks it again.

## Testing

- Added a new unit test
- Tested manually
@imobachgs imobachgs mentioned this pull request Jan 10, 2025
imobachgs added a commit that referenced this pull request Jan 13, 2025
Update to release version 11.

* #1495
* #1564
* #1617
* #1618
* #1625
* #1626
* #1627
* #1628
* #1630
* #1631
* #1632
* #1633
* #1634
* #1635
* #1636
* #1639
* #1640
* #1641
* #1642
* #1643
* #1644
* #1645
* #1646
* #1647
* #1648
* #1649
* #1650
* #1651
* #1652
* #1654
* #1655
* #1656
* #1657
* #1660
* #1663
* #1666
* #1667
* #1668
* #1670
* #1671
* #1673
* #1674
* #1675
* #1676
* #1677
* #1681
* #1682
* #1683
* #1684
* #1687
* #1688
* #1689
* #1690
* #1691
* #1692
* #1693
* #1694
* #1695
* #1696
* #1698
* #1699
* #1702
* #1703
* #1704
* #1705
* #1707
* #1708
* #1709
* #1710
* #1711
* #1712
* #1713
* #1714
* #1715
* #1716
* #1717
* #1718
* #1720
* #1721
* #1722
* #1723
* #1727
* #1728
* #1729
* #1731
* #1732
* #1733
* #1734
* #1735
* #1736
* #1737
* #1740
* #1741
* #1743
* #1744
* #1745
* #1746
* #1751
* #1753
* #1754
* #1755
* #1757
* #1762
* #1763
* #1764
* #1765
* #1766
* #1767
* #1769
* #1771
* #1772
* #1773
* #1774
* #1777
* #1778
* #1785
* #1786
* #1787
* #1788
* #1789
* #1790
* #1791
* #1792
* #1793
* #1794
* #1795
* #1796
* #1797
* #1798
* #1799
* #1800
* #1802
* #1803
* #1804
* #1805
* #1807
* #1808
* #1809
* #1810
* #1811
* #1812
* #1814
* #1815
* #1821
* #1822
* #1823
* #1824
* #1825
* #1826
* #1827
* #1828
* #1830
* #1831
* #1832
* #1833
* #1834
* #1835
* #1836
* #1837
* #1838
* #1839
* #1840
* #1841
* #1842
* #1843
* #1844
* #1845
* #1847
* #1848
* #1849
* #1850
* #1851
* #1854
* #1855
* #1856
* #1857
* #1860
* #1861
* #1863
* #1864
* #1865
* #1866
* #1867
* #1871
* #1872
* #1873
* #1875
* #1876
* #1877
* #1878
* #1880
* #1881
* #1882
* #1883
* #1884
* #1885
* #1886
* #1888
* #1889
* #1890
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants