Hacker News Reader

Comment by Svip | Hacker News Reader

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?

View on HN

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.

> I wonder where this trend - fortunately a limited one - with putting confirm buttons at the top comes from

Original small screen iPhone, where it's easier to reach the top than the bottom, and it's less likely to be an accidental touch.

But now it's cargo-culted everywhere.

> 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.

Anyone else agree?

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.

If you use your phone one-handed often enough, iOS Reachability works pretty well: https://support.apple.com/en-ca/guide/iphone/iph145eba8e9/io...

It’s doable, but it’s certainly more straining than on the Home button iPhones. The same goes for the bottom swipe that activates Reachability.

The bottom of the phone is incredibly hard to reach in single handed operation while also holding the phone.

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.

I think most people (myself included) hold the phone with the bottom resting in their palm (and often further supported by their pinky/little finger).

Do you hold your phone from the top, with the bottom ending unsupported and hanging out? And if so, why?

Obvious downsides: if you loosen your grip then the phone will fall to the ground; you can’t reach the on screen keyboard.

> 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.

https://www.phonearena.com/phones/size/Apple-iPhone-SE-2022,...

Please read https://www.smashingmagazine.com/2016/09/the-thumb-zone-desi...

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.

Yet Next, Back, Done, Cancel, etc., are at the top on iOS, for some reason.

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".

0: https://en.wikipedia.org/wiki/GTK#Criticism

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.

Edit: s/HID/HIG

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.

As a developer of a couple GTK apps I really like the direction the project has gone in. Its a more flexible and performant toolkit than ever before.

Gimp switching to FLTK or Elementary / Enlightenment would be a fun thing. (I suppose it will never pick up C++ in the code base, so not Qt.)

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.

GTK is pure C, while Qt is C++. It's both a blessing, and a curse.

E.g. I did not write, but just looked through the hoops PyQt has to jump to interface with Qt nicely. Quite impressive.

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++.

In my opinion not using managed languages is a huge hindrance to these platforms.

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.

They give us what we wanted after years of pleading, but we pay dearly and mercilessly in other ways. Truly Faustian.

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.)

Gtk-mushrooms was one such fork, but I think gnome will make it pretty hard to maintain a fork if one starts getting popular.

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 wonder where this trend - fortunately a limited one - with putting confirm buttons at the top comes from?

it comes from gnome developers wanting to do things different for difference's sake.

it makes no sense and brings no advantage. truly an unnecessary change.

I think it comes from Apple and Android actually.

It takes less vertical space because it reuses the (mostly empty) title bar.

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...

It annoys me particularly when I want to move a Firefox window. I have to find that one tiny spot that still allows me to move the thing.

I was under the impression this was controllable.

+100 couldn't agree more. And it's not a rational decision, it's a UI trend.

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.

Discoverability rears its head. I don't see how moving that functionality into some obscure button combination is better than obvious behavior.

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.

But using the title bar is what most of us are used to.

https://xkcd.com/1172/

At least on gnome you can drag or resize a window from anywhere by holding Super.

And you can, of course, reassign that key.

Resizing takes grabbing an edge though.

Alt+drag by default, but I remap it to super in dconf.

With GTK you can at least drag the window by grabbing controls in the titlebar.

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

> "less vertical space" so let's have a hamburger menu on a desktop screen.

hamburger menu on desktop should be abolished

Minimizing used space is often (usually?) at odds with good UX, so I guess the actual question is: why is minimizing vertical space even a goal there?

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.

As opposed to the space in the mostly unused bottom bar?

Less space on a UHD monitor (meaning these days we have enough pixels). In the 640x480 px days then it might made sense to really squeeze btn’s in…

>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 call this dribbble-driven design. Looks good on a heavy photoshopped screenshot, ship it

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.

As I use XFCE as my daily driver, I never understand why the buttons in file dialog located as such.

Is it decision from GTK or XFCE team ? I almost put the blame on XFCE team for this, :-(

Can app devs who use GTK library overwrite this style?

Reply on news.ycombinator.com