There are many valid critiques of GNOME but this isn't one of them.
A split button is an accepted and widely used pattern.
Gnome Files: A detailed UI examination
241–250 of 293 posts
Re: Gnome Files: A detailed UI examination
#242There are many valid critiques of GNOME but this isn't one of them. A split button is an accepted and widely used pattern.
A split button where a dropdown is not a superset of what is achievable by a button is, however, not common. It is a direct violation of user expectation.
Re: Gnome Files: A detailed UI examination
#243Earlier quoted context omitted.
I think a lot of this disagreement could be cleared up by using “hallway usability testing”. The test is simple: Grab the next 6-8 people who walk past your desk and say “hey do you have 5 minutes to test the usability of something?”. Ask them to do a series of actions with the application (change to a list view, go up one level in the directory hierarchy, etc). Take note of what they find easy and what they struggle…
And that would have been a good test and an interesting data point . But that’s not a step you can just skip.
Do you think the original poster is wrong about the usability problems in gnome files?
Re: Gnome Files: A detailed UI examination
#244Earlier quoted context omitted.
Ctrl-C sending a SIGINT to the program running in the terminal is the standard shortcut. Woe to the terminal arrogant enough to assume their precious copy/paste is more important. Now, Super-C vs Ctrl-Shift-C (across the UI), we can argue about.
The more important thing isn't "their precious", but "user precious", where terminal is just from of a million apps that copy on Ctrl-C, so there is no woe, but praise, to any terminal app that reflects this basic fact and doesn't subvert user expectations
I guess we have very different sets of users in mind, then.
Ctrl-C (and Ctrl-Z, Ctrl-A, Ctrl-V and many other standard command-line shortcuts) have been around for longer than many of those users have been alive, and are part of POSIX standard.
The proof is in the pudding, though. I haven't seen any terminal apps that actually do what you praise (by default, as you can always remap the shortcuts to your heart content - to each their poison).
Re: Gnome Files: A detailed UI examination
#245Earlier quoted context omitted.
The more important thing isn't "their precious", but "user precious", where terminal is just from of a million apps that copy on Ctrl-C, so there is no woe, but praise, to any terminal app that reflects this basic fact and doesn't subvert user expectations
I guess we have very different sets of users in mind, then. Ctrl-C (and Ctrl-Z, Ctrl-A, Ctrl-V and many other standard command-line shortcuts) have been around for longer than many of those users have been alive, and are part of POSIX standard. The proof is in the pudding, though. I haven't seen any terminal apps that actually do what you praise (by default, as you can always remap the shortcuts to your heart content…
Not really, all the same users, you just place way too much faith in the defaults. Case in point: your second point. Though your pudding is stale: bad defaults are a common scourge of software, so the fact that something is default means nothing positive on its own
Re: Gnome Files: A detailed UI examination
#246Earlier quoted context omitted.
You can click on the three dot menu at the right of the path, there is an option to open a terminal. You can also switch to icon view and right-click between icons to open a terminal. You can also go to parent folder, right click the folder you were before and open it in a terminal. Many workarounds but I agree it’s not really good UI.
> You can click on the three dot menu at the right of the path, there is an option to open a terminal. I use Black Box as a terminal app, but Nautilus will open only default distro-provided terminal application with its menu.
Why don't you change your default terminal in update-alternatives (if you are the sole user of thia computer) or gsettings then?
Re: Gnome Files: A detailed UI examination
#247Oh GNOME, hiding "Power off" option under additional submenu, that user wouldn't accidentally click it, and then putting "Format" right next to "Safely remove drive" in Files.
Unfair. Format is followed by ... which implies it opens a dialog. That dialog starts a 2 steps process, the last one being a warning in red telling you it will destroy every data permanently.
There is no way you can accidentally format a device.
Also, people who want a quick way to poweroff can change the behavior of the power button to ... poweroff instead of suspend.
Re: Gnome Files: A detailed UI examination
#248Earlier quoted context omitted.
The basics: you are not your users. Just because it’s easy for you, doesn’t mean it’s easy for others. That is the entire basis of usability work. I cannot believe how resistant the tech community, like above, is to the very basics of human cognition. It’s your comment that’s the rant. OP has actual data from decades of research they are applying. Quoting myself: https://news.ycombinator.com/item?id=41303387
Thankyou. I’ve been using computers for 35 years (I grew up using xtree to navigate folders on DOS). It would never have occurred to me that both sides of that view options dropdown do different things. Perhaps it’s intuitive for others, but I’ve never seen that before in my life. I’m increasingly of the opinion that I hate almost all novel interaction patterns in user interfaces. UI components and flows should stick…
Exactly. The traditional design language is that an arrow besides a button indicates that the button will show a drop-down when pressed (traditionally without a line separating the two), or that clicking on the button will do the default action while clicking on the arrow will show all the actions (traditionally with a thin line separating the two).
Reusing that design language but making the button and the arrow two completely different buttons with their own actions sets wrong expectations for no good reason.
Re: Gnome Files: A detailed UI examination
#249Earlier quoted context omitted.
> List view and view options buttons, while combined, That's it. You could've stopped here. They are combined . It's a button with a dropdown indicator. The user expects this to be a single control for a single set of features. Not two distinct controls for completely unrelated functionality that you have to pixel-hunt for
I mean, what user? Someone in his late sixties who grew up on Windows 3? Sure. Someone in their twenties/thirties...? Coming from Mobile? Young teen? I strongly suspect they all have different expectations then you. Two different hover tool tips and a distinct hover state difference on a control optimized for screen size is very much the standard there.
"Two things grouped together signify similar/same things" is age-independent
"View options should include settings for list/details view, not sorting options" is age-independent
"Control optimized for screen size".... on a desktop? It's not a mobile screen.
The fact is that "designers" and "developers" like you don't understand the problem and have trained a new generation of people to not expect anything to work as expected/natural/intuitive while throwing away decades of user interface and experience research.
Re: Gnome Files: A detailed UI examination
#250Earlier quoted context omitted.
So what should be?
OS X Snow Leopard (10.6). Apple also has a thick Human Interface Guidelines document from.. ‘97 or ‘03, I can’t remember. But it’s great. Funnily enough, if you use it as a yardstick to measure the current macOS by, macOS is full of violations of that HIG. Pulling back to the article: I wonder what desktop the writer uses, because KDE is absolutely chock full with idiosyncrasies and inconsistencies. Especially becaus…
> Absolutely horrible UX.
Hard disagree. I'd rather have some small inconsitencies (nothing consequential anyway in my KDE experience) than having all applications consisetently unusable due to top down decisions to remove and hide features as is the case with Gnome.