I wonder where this trend - fortunately a limited one - with putting confirm buttons at the top comes from? Humans naturally read from top to bottom. It naturally follows that the final action in any UI should be at the bottom.
I find these buttons at the top extremely confusing, as I often - from my experience with reading - after I've dealt with the subject at hand (in this case, picking a file), assume the natural place to confirm my choice would be after it (i.e. below it).
What are the UX arguments for placing the confirm buttons at the top of a dialog?
When Windows 95 came, (if I'm not wrong), it had an accompanying HIG book backed by actual research - I think their main inspiration was book pages, but I can't be 100% sure. OK (Confirmation) intentionally was on the left side, far away from accidental click, assuming this is a destructive, irreversible operation. "Cancel/Close" on the other hand, is closer for most users (right side), and it will just close the window.
Making Confirm/Cancel buttons this way makes no sense. I'll assume they added this just because it looks cool, as someone mentioned as well.
> Original small screen iPhone, where it's easier to reach the top than the bottom…
With phones, it's always been easier to reach the bottom. This is why tab bars have always been at the bottom. This is why soft keyboards have always been at the bottom. This is why Apple moved Safari's controls to the bottom by default.
The comment mentions original iPhone screens. They were 3.5" and we hold phones differently because of the sub 4" displays.
The idea back then was maybe to separate the confirm action from other actions located at the bottom bar.
Human Interface Guidelines changed a lot as Apple changed the iPhone form factor. But with a 3.5", most of the screen is "uniformly" reachable and the bottom is slight less reachable as you usually need to flex the thumb.
Not to mention the lack of top and bottom bevels that we only still find on the iPhone SE (3rd gen) now.
Maybe I’m an outlier, but it’s been over a year and I still don’t like how in accessible the top and bottom of the screen on my 13 mini are for one handed use. I swipe to text one handed, but pressing the numbers its emoji button requires serious contortion and dexterity. Maybe the fact that I tend to use my left hand (despite being a righty) contributes to this.
I don't have a problem reaching the bottom of the screen, and also generally use my left hand for one-handed use. The phone rests on my pinky, with the middle three fingers supporting the body.
How are you holding your phone? I'm typing this comment one-handed using a soft keyboard on the bottom of my phone. My thumb actually cannot reach the top of the screen without shifting the phone to a different grip.
GP is not saying that the top is easier to reach than the bottom. Reaching to the very bottom of the display one-handed is still straining, compared to the Home button iPhones.
> With phones, it's always been easier to reach the bottom.
The _original_ iPhone is tiny by today's standards. It's 15% shorter than a current iPhone SE, with a relatively huge chin. At that point the top corner is where the thumb is when it's straight up.
Read the second section, labeled "Thumbs vs Touchscreens", which shows the sweet spot for accessing content via left or right thumb or both. The lower corner closest to the base of the thumb is hard to reach. Unless the user was using both thumbs, placing target UI in one of those corners would hurt one-handed users.
Also note which areas are labeled as HARD to reach for either/both thumbs - the location where GTK4 has placed the main buttons in the File Chooser dialog.
I wish Gnome did not try so hard to be macOS. If I wanted to use macOS, I'd get me a Mac.
But I see that the other Unix machine most Gnome developers use is a Macbook, so they try to make things familiar, because they sort of like that UI. (Those who don't but still want a coherent desktop can pick KDE.)
It's not even macOS; it's iOS. It's a GUI for phablets and phones.
Fortunately, I think more projects are abandoning GTK than onboarding it thanks to GTK's horrible documentation, instability, opinionatedness, and simply how much better Qt is to develop for[0], which I can only hope will gradually de-throne GNOME as "the default DE".
Yep; as I’ve said before GNOME is what you’d get if you tried to clone iPadOS and turn it into desktop OS.
It still feels more polished and accessible overall than alternatives though, and so it will probably continue to be “the default DE” for the foreseeable future.
KDE has the most potential to replace it, but I think its configuration is still intimidating (to the point that you regularly see people ask which KDE distros have good defaults), as well as quirks you don’t see anywhere else, like turning file copy dialogs into notification toasts. It’s technically functional but comes off as weird.
The other GTK DEs (XFCE and Cinnamon) I think are in a better place in terms of their settings panes not being scary and generally feeling well designed, but lack resources.
> like turning file copy dialogs into notification toasts
That's a great thing that I'm surprised other DEs don't do. Works really well for file downloads too. It makes intuitive sense and the fact that finished state is retained in notification history is such a helpful thing that genuinely improves user experience for someone with such a poor working memory as mine that it's really weird to see someone calling it weird.
I don’t mind seeing completions in my notifications and having the option to show progress in notifications is fine, but I also want the option for a boring old dialog, preferably with the ability to expand and show a high level of detail (think Windows file copy dialogs) that isn’t practical in a notification bubble.
> preferably with the ability to expand and show a high level of detail (think Windows file copy dialogs) that isn’t practical in a notification bubble.
Why do you think it's not practical? That's what Plasma offers already and I'm using it often.
I really hope that’s not the case. GTK4 is highly polished and getting better.
Even if for the sake of argument we accept that Gnome/GTK’s UI choices are poor, the consistency across applications elevates the overall experience.
If, for example, you disagree with the placement of buttons, you know that all the GTK buttons will have the button in the same place which greatly reduces cognitive load.
The same is, unfortunately, not true of other Linux UI kits.
> you know that all the GTK buttons will have the button in the same place
This is vehemently untrue. You know that all GNOME applications will have the buttons in the same place (GNOME writes their own HID) but GTK doesn't have an HID. GTK is simply a GUI toolkit, I can put my topbar at the bottom of my window if I want. It's not 'correct' but I can still do it and ship my application.
As a developer of a couple GTK apps, I look at the deprecations in GTK4 and GTK5 with horror. At least one app I'm going to stop maintaining latest with GTK5.
GIMP still doesn't have stable release out with GTK3. Inkscape took a long time. I bet both will have great trouble in the future. It seems we're moving towards GTK apps being either core GNOME (maintained as paid work by Red Hat) or trivial little apps like on mobile (either simple to port or just short-lived). Everything else will slowly die out.
Sometimes I wish Mate would have also forked GTK2. GTK3 is just heavier in general and going forward, GTK4 seems to be even more Gnome focused, so a fork might become inevitable anyway.
From a developer standpoint, I actually really liked how composable GTK3 was. It's fair to complain about the stylesheets and the funky touch-centric interface, but it did still let you build GTK2-style apps. It was full of weird/nice features and felt like a decent iteration on GTK2. GTK4 has been a waking nightmare in comparison, and I'm not sure why they feel obligated to throw out so much of the previous toolkit.
Qt being a pain to bind (and thus having few high quality bindings) is definitely a big reason why I’ve avoided it. I don’t really want to be writing UI in C++.
You forgot to mention, that filename entry field is also in the middle of titlebar. While that might help to defend placing "Save" button next to it on the right, but now all primary save dialog functionality is contained in titlebar. Folder selection is clearly separated and made secondary action. It would be interesting to see usage statistics, how many users save files without selecting folder first.
Sadly there would be no stats for people screaming obscenities to authors of this... dialog, because they tried to move the dialog but instead got to the filename editbox.
I wonder how feasible would it be to support a fork that added that feature. It seems self-contained enough to not require any public API changes. Just building the GTK source with some flag would turn on that feature, and dynamically linking against that GTK lib.so would make the thumbnails view accessible to the user.
Did anybody care enough to try?
(I personally don't; I use the file manager for any views I want, and drag the files from it onto an app, or onto a file chooser dialog. That feature, which is also present in macOS, was very much worth reproducing.)
As a ux designer, putting the confirm button at the top right is madness. I can’t comprehend the thought process that led to it being put where the close action usually goes.
I’d love to watch an eye tracking study of it in use.
I loathe applications that put controls all over the title bar.
The title bar is supposed to be a mostly empty expanse that you can grab with a mouse. Now it's littered with controls, and I can hardly bring windows to focus or move them around without accidentally searching something or confirming something.
Agreed - especially if I'm remoted into a box and not necessarily running a full-resolution screen. Bad UI design is magnified when you're at 1024x768.
I find it somewhat ironic given current GNOME that when I was choosing between GNOME 2 or KDE 3 back in the day, GNOME 2 won as bits wouldn't float off my screen...
I used to agree, then I moved to Linux (KDE specifically) and found out I could set my DE up so Super+LMB anywhere on a window moves it, and Super+RMB resizes it, it's is way more convenient, I haven't found myself using the title bar any more.
Title bars also serve to more quickly recognize where windows are. If every application fills up the title bar with different stuff, it becomes harder to “parse” where windows are on the screen. There is an inherent benefit in windows having uniform “chrome”.
I have Alt-LMB for moving, but that all falls to pot when I remote into another machine -- alt-lmb moves my rdp/vnc/browser, not the one in the screen I'm connected to.
I'm not advocating for this to become the default functionality across the world for everyone, it's definitely very opt-in.
In that case you don't need discoverability for something you set up yourself.
It's also very fun to play with when using the Wobbly Windows effect, you can stretch them in different ways depending on where exactly you picked the window up from.
Ah yes. Instead it pollutes the title bar with multiple things with wildly different behaviours with no error margin
"less vertical space" so let's have a hamburger menu on a desktop screen. Right next to the window close button.
"less vertical space" so let's have a tiny search icon right next to the select button
"less vertical space" so let's have search consistently in the left corner, no in the middle, no to the right
"less vertical space", so let's have tabs, buttons, icons, and hamburger menu in one row. There's no space for the actual title or little space to drag the window? But THERE'S LESS VERTICAL SPACE ENJOY
The 16:9 screens. Once upon a time they were called widescreens because many people were used to small (in inches) CRTs or LCDs (even with square panels.) Basically they were 12:9 and those 4 extra units on the horizontal axis become real extra space. Unfortunately most people only got 768p screens on their laptops while all TV sets had 1080p and some of the old monitors were 1024p or 1200p. So "less vertical space". And then when you have a 13" laptop you don't have much vertical space no matter the resolution.
We're talking about things like dialog windows that don't take much vertical space even when putting all confirmation buttons in separate rows; this is a set of applications that often easily fit on half the screen. I know what you're talking about, I'm writing this on a laptop with 13" screen and I'm using a browser with vertical tab bar for a reason, but this isn't that case.
>Humans naturally read from top to bottom. It naturally follows that the final action in any UI should be at the bottom.
Pretty bold of you to assume such thought process occurred at any point during design. Someone just thought "this looks good", where good may mean "modern-looking", "trendy", or "looks great on a screenshot for a product page", and slapped the button there.
I wonder if this is designed by primarily laptop users. They may conceivably prefer buttons at the top because it’s closer to the center of their field of view.
Of course, laptops used with their builtin display and keyboard are a usability disaster already, so that shouldn’t be a criterion.
For what it worth, gnome is very good to use with a trackpad, swiping left-right to switch between desktops is very smooth, probably the best laptop experience out of any OS/DE.
I find these buttons at the top extremely confusing, as I often - from my experience with reading - after I've dealt with the subject at hand (in this case, picking a file), assume the natural place to confirm my choice would be after it (i.e. below it).
What are the UX arguments for placing the confirm buttons at the top of a dialog?