GNOME Human Interface Guidelines Being Updated For GTK4, Other Modern Features

[Vistaus]

Again with all the crap in the titlebar ?
Does Gnome people never drag the titlebar to the top or left and right sides of the screen and use the keyboard instead ?
They think that Windows developers haven't thought about this already and then they decided to drop it ?
Glad I'm not a Gnome user and the GTK programs that I use don't strictly follow these weird things.

I don't like headerbars either, but fact is that they aren't a GNOME thing. Xerox GlobalView (http://toastytech.com/guis/gv.html) started the whole thing, then later on macOS and GNOME adapted it and now Deepin is using it as well using a patched version of KWin. elementaryOS also switched to headerbars and IIRC there's a proposal for KDE to switch as well.

Again: I don't like headerbars, but they sure are used outside of GNOME, so they are kinda trending.

[Vistaus]

Haters gonna hate. Dude, you can drag the window by clicking on almost anything in the headerbar.

That's unintuitive. When I see a button, I expect it to perform the action it indicates, not do something else that isn't indicated.

[Vistaus]

kpedersen It’s 2021 and you can’t imagine people using a 2in1 laptop/tablet in vertical mode? Anyway GnomeOS is preparing support for RISC-V so there’s more hardware you can pretend doesn’t exist.

https://gitlab.gnome.org/GNOME/gnome..._requests/1112

Wait a sec, are you saying there are RISC-V 2-in-laptops/tablets coming? Did I miss that news? 'Cause that would be huge!

[Vistaus]

To be fair there are both the librem 5 and the pinephone

…which aren't running GNOME 3 directly but Phosh.

[reba]

Well... I don't know.

It looks like a usability clusterf*ck to me and I get the impression there went either too much or not enough thought into this:


1. Why is the magnifier-button one time at the left and one time at the right side?
- Do they have the same purpose? Do they have a different purpose?
- Where do I have to expect which one in which case?
- What do I filter or search here? What's the context?



2. There is one "=" symbol and one "..." symbol
- What is their exact purpose?
- What's the exact difference between those two?
- Which actions can I expect in the one and the other? Which one do I use in which case?
- What's my expected behaviour? Does a pop-up-menu appear? A dialog?
- Can there be more than one "=" and/or more than one "..."?



3. Why is the search-term-input-field in a separate row?
- This wastes space, doesn't it?
- Does it squeeze up between header bar and content? Does the content shift down? Would this disrupt the layout? Or my sensomotorics because everything shifts around and what I have had looked at is now somewhere else?
- Do I know on what this search field applies to?
- Does the "=" react to the open search line? Does it change its contents because the contextual meaning of the page has changed?



4. What is the "+" for? What is the "OK" (?) button for?
- Does the "+" add another "Category"? What does it do?
- Does the checkmark close the dialog and pass on my selections or whatever I have done?
- Why is it cramped between other stuff that is clearly not meant for navigation / proceed?



5. Navigational elements do not belong in the headerbar!
- This is unergonomic because I usually read the stuff which is shown to me so my eyes are 99% of the time at the bottom of the content, be it right or left (RTL/LTR)



6. What's the difference between "Cancel / Submit" and "Cancel / Do it"?
- Because the former is on top in the header bar and the latter is at the bottom of the content
- How do these two dialogs differ?
- When do I expect to be presented which type?
- Can the latter have a title at all? Do I know exactly which context this dialog belongs to?
- What's the default action of the latter?
- Where is the focus currently (think: tabbing through input elements)?



This list could go on...

[rastersoft]

Except that I have to waste my time to think on what not to click.

Then you neither want a "close" button in your bar, nor "maximize" or "minimize" :-P

[gedgon]

Except that I have to waste my time to think on what not to click.

What? Really? Wait, I forgot it's phoronix forum. My bad.

That's unintuitive. When I see a button, I expect it to perform the action it indicates, not do something else that isn't indicated.

And it will, on click, as expected.

[zareami10]

What? Really? Wait, I forgot it's phoronix forum. My bad.




And it will, on click, as expected.

I wonder how they even manage to comment here. Considering it needs lots of "thinking" and actions which are not "indicated".

[remenic]

That's unintuitive. When I see a button, I expect it to perform the action it indicates, not do something else that isn't indicated.

What exactly do you expect to happen when dragging a button? If moving the window is not the answer, then what is the rationale behind that? The window is glued to the desktop? Or is it just too heavy and only the title bar has the power to move it? Or maybe it magically unlocks the window from its current position but touching it.

[reba]

What exactly do you expect to happen when dragging a button? If moving the window is not the answer, then what is the rationale behind that? The window is glued to the desktop? Or is it just too heavy and only the title bar has the power to move it? Or maybe it magically unlocks the window from its current position but touching it.

Strictly speaking: there is no rationale in dragging a button - because buttons are not able to be dragged; or how many buttons, switches or flips have you dragged in your kitchen so far?

It is natural to drag sliders (some Hi-Fi have them or audio mixers), turn knobs - or even drag and detach tabs, if you think of them as "pages" in a book with a tab attached on the page's edge.

Please explain to me the expected behaviour of these elements in the headerbar when draging:
- a text-field: does it select text or drag the window?
- a slider: does it change the value? drag the window? only then hitting the "knob" or only when hitting the "bar" or only when hitting above/below the bar and the knob?
- a tab: does it detach? move the window?

In short: overloading elements with special, not intuitive and "unrealistic" behaviour only works because the effect is so unnatural it does not conflict with naturally expected behaviour.
But then again, what will be gained by adding unnatural behaviour to elements that otherwise mimic real-life everyday elements?