Created attachment 135925 [details] Screenshot of the network applet SUMMARY The current implementation of multiple widgets has buttons that cover up information and end up being distracting. Two examples are the "connect/disconnect" buttons in the "network" widget and the "safely remove" button in the "device notifier" widget. In the case of the network widget, the text is highly distracting as it fills up a large portion of the available space and diverts the attention from the most important element, which is the network name; plus, it covers up the current network speed. The discussion is cyclical an keeps on turning up whenever a change happens: people were complaining when the buttons weren't there and they're (I am) complaining now that they are. Finding a compromise is difficult, but I think that the current implementation is worse than the previous one because it ends up hiding information and making the interface much more cluttered and less clear. The cure is, in my opinion, worse than the disease in this case. A rethinking of the current design is in my opinion necessary to make the applets more usable. SOFTWARE/OS VERSIONS Linux: KDE Neon Focal KDE Plasma Version: 5.21.0 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION
This was changed in response to a request in Bug 428624. We can revert the change, but then we will have to re-open that bug report. I sort of agree with you on the issue at hand: having all these always-visible buttons is kind of ugly, and causes long text to be elided. That's all true. However making them appear only on hover re-introduces issues with discoverability, particularly on touch for 2-in-1 devices in tablet mode, since there is no concept of hover there. I'm sort of at a loss for what to do. VDG input would be appreciated.
I'm tempted to just revert the "no more hover" change because we use hover all over the place already and it already does handle touch.
I understand the point made in the other bug report, but I think there is a problem with that line of reasoning. Do we have buttons on windows that say "close", "maximise" and "minimise"? No, because we expect the user to either: A: be familiar with how window controls work; B: try a few actions and learn by themselves how things work. The first option assumes that you have gone through the second one or that someone else told you how things work. The second one is how we learn in general. The same happens with tray icons: they're not stylised as buttons. They're just icons. How can a person know they are supposed to click on them to get access to the related features? I'll make an example regarding this using mobile platforms: on Android and iOS they're just icons, so you're not supposed to do anything with them. By fiddling around, you can discover that doing a downward gesture opens the notification shade and that from there you can do a few things. You can imagine my surprise, then, when I used Ubuntu Touch for the first time and I discovered that on that platform the icons are actually meant to be used a bit like on KDE! Discoverability on Android, iOS and Ubuntu is zero - you have to try for yourself to learn how things work. My point is that finding the action buttons might be difficult the first time you use them, but from then on it's pretty logical and easy to find and use them. So yes, discoverability for the first use might be an issue but, if hovering is used, then I can argue that the action required to discover the features is not a very complex and long one that requires lots of effort and dedication from the user. It's the simplest you can think. Moreover, hovering actions are quite common among user interfaces. We might say that the equivalent in the mobile space is a long-press: it may not be immediately, unequivocally clear that you need to perform that action in order for the thing you want to happen, but after the first time you experience it it is quite self-evident. As you say, hovering is used in multiple places throughout Plasma (the first example that comes to my mind is the "colours" section of the settings), so it's not a concept that is only and exclusively used here. It's one that most people that have used a computer in their lives are familiar with. To wrap it all up, I think we have two options: - provide better discoverability for a basic feature that is widely used throughout the rest of the Plasma experience at the expense of readability, clarity and access to parts of the UI; - provide better readability, clarity and full access to the UI at the expense of the feature not being immediately discoverable to the few people who have rarely used a computer in the past 20 years (now that might be a bit of an exaggeration, but the concept of hovering was there well before Windows 2000 and its use is extensive on any platform and UI concept out there). I stand with the second option.
I opened a Phab task about this so we can have the discussion in one place rather than scattered around all over the place. Everyone is invited to participate, of course! However as this is a place for developer discussions, please think before you post and try to honestly and openly consider other people's points of view. :) Also try to avoid walls of text as people don't tend to read them. :) Brevity is appreciated! https://phabricator.kde.org/T14172