The most obvious reason why windowing systems get worse is that at each major release the developers (or their marketers) want to show that the new version is “new” and “better”. This causes them to add features which look different but may actually be less convenient to use than before—but might be patentable to ensure a platform-specific look and to lock out those who create competing development toolchains.
One obvious example is the Windows ribbon. This is touted as being easier to use, but seems more confusing than the menus and toolbars it has replaced. Furthermore it is less productive than menus and toolbars. To click a toolbar button takes one click. But to click a button on a ribbon takes—on average—more than one click. Most of the time, the button is on the visible ribbon and needs only one click. But sometimes the button is on another ribbon so needs a click on the ribbon and then on the button, thus increasing the average number of clicks.
Another example is the macOS sheet. This is essentially a modal dialog that “grows” out of the window it is invoked from, thus making it more obvious why it is there. Since some users get confused by dialogs popping up, this may well be an improvement. But will you see it on any other platform? Ask a patent lawyer.
Nowadays though, probably the main reason for desktops getting worse is the peculiar idea that a windowing system for a desktop or laptop computer (big screen, keyboard, and mouse or touchpad) should be the same as one for a mobile device (small touch screen).
Clearly it is cheaper to design one user interface for all systems, but it turns out that such development cheapness comes at a high price for users.
For example, in Windows and modern GNOME many applications no longer have a menu bar. Instead they have a menu button (just like on mobile devices). So now, hundreds of millions of desktop and laptop computer users are disadvantaged. How so? Because a big screen means there's room for a menu bar. And a menu bar is informative—it shows you what the main menus are. Also, to invoke a menu option using a menu bar is a two-click process: click the menu, then click the menu option. But with a menu button, it is a three-click process: click the menu button, then the menu, then the menu option. Think of hundreds of millions of people now having to do 50% more mouse clicks just so that their desktop application can look like its mobile equivalent. How much time and productivity do those needless extra clicks cost?
Some applications (e.g., Firefox) at least let you get the menu bar back. But the Firefox default, even on desktop systems, is to have a menu button. Clearly this should be the other way around. Still, better than those applications—like Epiphany on Linux—that don't even give you the choice.
On Linux desktops the taskbar often shows various indicator icons. Some use colors and provide helpful information in tooltips if you hover over them. Others are black and white and will only tell you anything if you click them. Why this ugly mixture? Because some of the indicators are trying to mimic modern macOS's minimalism. This creates inconsistency and inconvenience on Linux desktops.
For example, a few years ago the power indicator on my systems showed the battery status using color (red for low, green for high), and provided a useful tooltip of the percentage of power left. Now I just get a barely visible black and white indicator that ignores mouse hover.
A new GNOME release came out some years ago that was once again trying to mimic macOS (or Mac OS X as it was then). But this time it had a genuine innovation: scrollbar warp.
Traditionally, when you click a scrollbar gutter (i.e., above or below the proportional page indicator), you would get the effect of pressing the Page Up or Page Down key. But with warp when you click you go to the part of the page that's in due proportion to where you clicked. This makes navigating to the top or bottom very easy—and makes navigating a page at a time hard to do with consistent accuracy.
But of course not every GNOME application supported warp. So I found that for any given application I didn't know if a scrollbar click was going to do the conventional navigation or warp. And this turned out to be a show-stopper for me—it drove me nuts! And all because they didn't put warp on the right click. Had they done that, everyone could left click any scrollbar and get the behavior they were used to: and those in the know and who needed it, could right click to warp.
For me the genuinely useful but misplaced warp feature finally drove me away from GNOME. (And for Windows, I use 7 wherever possible since at least its buttons look clickable unlike in Windows 10. Not to mention that Windows 7 start up is a lot faster than 10's, and it runs CPU-intensive applications (a bit) faster on the same hardware.)
Now I use Xfce. I also turn warp off for any Gtk 3
programs using the file
whose content is:
[Settings] gtk-primary-button-warps-slider = false
One other mobile-influenced annoyance with Linux desktop scrollbars is “scrollbar overlays‟. These basically cause your scrollbars to be hidden most of the time, and when they do appear, they are bare without even the arrows at top and bottom. Fixing this isn't easy. Here's a link to what works for me with Xubuntu 18.04: How to remove overlay-scrollbars. This works imperfectly with some applications, but is still better than overlays.
Usability depends on the user clearly seeing what's going on, and being able to see how to do the tasks they want. Naturally users want to use attractive systems, but they don't really want change: at least not unless it brings genuine and significant productivity gains. Desktop and laptop computers are very different from mobile devices. Application user interfaces for desktop and laptop systems should take full advantage of their big screens, keyboards and mice.
Your Privacy • Copyright © 2006 Qtrac Ltd. All Rights Reserved.