Replies: 1 comment 4 replies
-
|
Find below some additional comments to above text. |
Beta Was this translation helpful? Give feedback.
-
Not pretty sure, but looks like on Linux it is using According to release notes,
In fact, I could find it at Settings -> General -> Browsing -> Always show scrollbars
Which is translated to user_pref("widget.gtk.overlay-scrollbars.enabled", false);in the pref.js file at the profile directory. However, not sure if Firefox will follow/honor a system preference on Linux. Of course, such a default setting has been controversial for some users. Among many other places, you can have a look at https://connect.mozilla.org/t5/discussions/scrollbars-disappear-in-firefox-100/m-p/6358 or https://support.mozilla.org/en-US/questions/1420887. |
Beta Was this translation helpful? Give feedback.
-
Although the overlay scrollbars are something at desktop environment / operating system level and user could be familiar with them anyway. But let's keep assuming that users installing Agama from the live ISO are facing something "completely new" for them. The most safer fix still the same: to update the pref.js of the Agama live ISO for always displaying the scrollbars. I.e., to put the usability ahead of aesthetic instead of promoting elements to sticky positions. |
Beta Was this translation helpful? Give feedback.
-
I was actually referring to the resolution by default in a KVM virtual machine 😅 Nevertheless, I have not found where these 1024x768 comes from. I have seen how to increase it, though
In any case, my point still the same: I wouldn't adopt a default resolution as an escape hatch for placing everything visible at such resolution. |
Beta Was this translation helpful? Give feedback.
-
This is just an example and doesn't indicate to users that they can also submit their choice by pressing the Enter key. However, this isn't an issue as long as we don't alter the default behavior of forms. I don't think it would be a major problem for keyboard users if the instructions are more geared toward mouse users. Of course, it's always welcome to improve instructions to make them clearer, more concise, and helpful for all users. |
Beta Was this translation helpful? Give feedback.
-
The Scroll Dilemma
From almost the very beginning, the team has been concerned about, or even a bit intimidated by, the scroll in Agama web user interface.
While it is a completely valid concern, especially given YaST's scroll-less nature, I think it leads us to not only revisit the topic over and over, but also to overlook the real issues masked by the sitting idea that scroll might confuse users or cause them to overlook something.
Focusing on What Really Matters: A Sensible Interface Over Scroll Control
Given that it is impossible to know in advance the screen size and browsers's settings the end user will have, it would be more productive to stop focusing on the scroll and invest that valuable time on building a sensible interface that simplifies complex concepts for users. The browser will do its job by properly accommodating it according to user’s settings. In other words, would be better to go for be the browser’s mentor, not its micromanager.
To do so, the default resolution for the Agama live ISO (1024x768 ?) also needs to be set aside. While it has been argued that it should be least considered and I agree to some extent, I fear it can put us in the wrong direction by shifting the focus on eliminating the scroll instead of addressing what is missing in the interface to help users better understand what’s required of them or what actions they can take on each page or section.
Giving it too much relevance might also put interface development at risk of reaching a point where all parties involved push for certain elements to always be visible within the viewport for such a default resolution, ultimately crowding the interface without offering a clear, user-focused advantage. Not to mention how to address the situation if the default resolution is changed in the future.
Worth to remind that browser user's preferences like zoom level also contributes to make impossible to reliably predict which elements will actually remain in the visible area without hurting the accessibility and usability.
Case Study: The Product Selection Screen
Let’s take the product selection page and the below comment as an example to illustrate why blaming the presence of scroll could be masking some real issues and even introduce new ones.
First, it wasn’t scrolled by default; it was out of sight due to screen resolution and/or browser size. I understand, however, that the comment refers to it being hidden in the current default live ISO resolution, which leads to the “issue” with subtle Firefox scrollbars.
Firefox is using overlay scrollbars since its version 100 (see https://bugzilla.mozilla.org/show_bug.cgi?id=1761690). I’m not sure if this is a trend among modern browsers/applications (I’d say it is) aiming for a sleeker and more elegant interface. I think it might being sacrifiying usability in more than one situation, but I have no doubts about users being familiar with their browser’s behavior, even when they are using the default settings. Most probably, they have learned that there are chances to (potentially) still scrolling even when the scrollbar isn’t visible right away.
Click to show/hide a Github's notification interface in an smartphone not rendering the scrollbars
That said, it’s true that Agama’s live ISO provides Firefox in kiosk mode by default, which might be an unfamiliar browser for the user. In that case, the right fix would be to adjust Agama’s Firefox settings to always show the scrollbars. It may look less sleek, but it ensures all sighted users can see them and guess if there is more content to explore.
In both cases, whether overlay scrollbars are used or not, this could also be addressed by adding another element to the interface to make users aware of more content below. Something similar to the commonly used "Back to top" helpers, but inviting users to scroll down instead. However, I wouldn’t implement it prematurely without first making meaningful improvements to the interface (keep reading) or gathering concrete feedback indicating that users are genuinely overlooking the form submission button. Otherwise, there’s a risk of introducing unnecessary "noise" without addressing the core issues.
Whether or not a user might think selection will be triggered automatically is something that could happen but shouldn’t be considered as a reason to make significant decisions about the interface. In fact, that’s one of the reasons Agama’s interface is commited to rely on native HTML elements and behavior whenever possible instead of replacing them with fancy equivalents without a good reason. That’s the case why the input buttons remains in the products list. Either way, the focus shouldn’t be on whether scrollbars are present or not. Instead, the focus should be on providing clearer information to the user, as the current interface doesn’t give enough clarity about what’s on the screen or what is expected from them. The “Select a product” label is there almost by luck but still indeed poor as a single input for a whole user screen. Something like “Choose 1 of 6 products and click Select to continue” would be more helpful. Of course, it is longer, but it gives users all the information they need to understand the interface, regardless of their broswer size, zoom level or any other setting that might influence on how the broswer lay out the page content.
Unfortunately, despite these key points, the reported “button out of sight” issue was addressed by sticking the form actions at the bottom of the viewport. While it has been argued that it now follows the same pattern as other screens, it’s important to note that this is actually a completely different type of page and list. Regardless, it looks somewhat nicer now (?) for sighted users and might work well for a wizard-style design (though Agama isn’t one) but rather than enhancing the overall user experience, it has introduced new problems by failing to address the underlying issues. To keep it brief, here are just a few examples:
At the same resolution, a long product list might end up with an item perfectly aligned with the buttons, which could cause users to overlook the fact that there are more products to choose from.
With a higher resolution or a shorter product list, there could be a very long distance between the selected product and the action buttons, introducing two potential issues: making them harder to find visually and/or making it more difficult for people with musculoskeletal disorders, like hand tremor or repetitive stress injury, to reach them. (I’m overthinking and even speculating here, but I hope you get the point.)
When changing a product and the selected product is out of sight, sighted users first see a disabled “Select” button, the same one they saw when selecting the product for the first time. In other words, it’s a bit harder than before to distinguish the “Product selection” screen from the “Change selected product” screen. The issue remains the same: the lack of information and context. It should be, of course, fixed by adjusting the provided information as much as needed for both cases, the first selection and the change. However, with the information the interface is providing now looks like at least in the previous version the user had a chance to spot the selected product while "looking for" the “Select” button (realizing there is scroll). Again, an kind of extreme example, just to illustrate how the interface didn't get better simply by sticking elements in the viewport.
Related to the previous point, it worth questioning whether the already selected product should be part of the selection list. It might be better to inform the user about the selected product and the implications of switching to another, while making room in the interface for still offering a list with only eligible products.
Final Words
Please don’t misunderstand this. It isn’t about neglecting the importance of investing time looking for the best layout for each Agama screen. Quite the opposite. This is simply another reason to encourage embracing the scroll rather than fighting against it, as the latter strategy could lead to worse decisions than thought.
Also, just a friendly reminder that these are simply my thoughts based on what I know and understand at the time of writing. As I continue working on this and gather more knowledge and insights, my perspective might evolve 😉
Beta Was this translation helpful? Give feedback.
All reactions