Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gnome Files: A detailed UI examination

datagubbe.se

Post reply on HN
Print view View original

211–220 of 293 posts

Re: Gnome Files: A detailed UI examination

#211

Post by savolai »

kaba0 wrote: post #195
savolai wrote: post #164

Earlier quoted context omitted.

This should help you trace the argumentation to cited research that is certainly not ”tone deaf”: https://www.nngroup.com/articles/ten-usability-heuristics/ 1. *Consistency and Standards* Claim: "The 'View Options' dropdown didn't contain view options, but rather sort options, and I didn't realize it was a split button with two completely different functions." Violation: This breaks Consistency and Standards. The use…

Something like this would have been a better post than the linked one, but even this is not necessarily objective on each count - and design has a fundamentally subjective, human element based on our collective experience with every kind of interface, ever, which is affected by experience/culture, everything. E.g. in your list: there is no “dropdown name”, it’s a misidentified element by the post writer. Add to it th…

Please get to know how comprehensively the heuristics have been condensed into that short list from a much longer list of ovservations and decades of research.

To take into account the remaining subjectivity, there is usability testing. Most findings start to repeat themselves after 5 representative test subjects. But if you don’t test at all, you’re just shooting in the dark, as may have been with this gnome design.

Re: Gnome Files: A detailed UI examination

#212

Post by savolai »

627467 wrote: post #184
savolai wrote: post #162

Earlier quoted context omitted.

1. Users have plenty of individual characteristics. If even ordinarily capable user’s can’t deduce what button does what, forget people with disbilities. It’s obvious you need to usability test this stuff. Gnome has neglected their basic duties. https://www.nngroup.com/articles/usability-testing-101/ 2. Human-Computer Interaction is a scientific field within Computer Science, and this is stuff from any 101 course. Do…

...and here is my missing point 3. "Citing Norman heuristics like gospel"

The citations you asked for are on those pages. If you can actually dispute them, I’d be more than willing to hear about it.

Re: Gnome Files: A detailed UI examination

#213

Post by gawa »

Cockbrand wrote: post #144
jiehong wrote: post #65

This reminds me of not being able to right click in Files in list view for creating a new document or pasting something, because it only accepts a right click in an empty area. Yet, in list view, as soon as you have a few files and the window is full, you’re given no empty area to click in. I saw some people have the same issue [0] in the past, and it’s not really been fixed either [1]. [0]: https://ubuntuforums.org/…

I find this debatable from a UI/UX perspective. I think that the designers made the right choice here, because a context menu should show actions which can be applied to the object I right clicked on. "New Document" isn't really some function of a file or folder icon. Even worse: when I right click on a folder, should the "New Document" menu item create a new doc in the current folder? Or in the one I clicked on? It…

Interesting opinion. I think it would be so much less confusing to have only one menu. The easiest for power-users and newcomers alike would be to put on the top of this unique right-click menu the folder-level options (create new folder, open terminal here, paste here, ...), and the selection-specific options bellow. This way it would be predictable and we can build habits (muscle memory).

But you're right it's debatable. A matter of preference. I guess I'm just in the camp of "more explicit is better than implicit". And I'm willing to pay the verbosity cost (having a longer menu in this case). The alternative seems like a complex decision tree to me: Am I in list-view? Yes. Is my folder full of files? Yes. What menu do I need, depending on the task I want to accomplish? I want to create a new folder. Ah, so I have to find some empty pixels to conjure the menu with that option...

Re: Gnome Files: A detailed UI examination

#214

Post by mixmastamyk »

nextos wrote: post #8
uniq7 wrote: post #6

Earlier quoted context omitted.

From the article's summary: > Some common features are only accessible - and discoverable - through keyboard shortcuts. The keyboard shortcuts listing is non-interactive, modal, and incurs a substantial mental context switch.

That's something natural, touch interfaces need to be simpler. I didn't miss any normal functionality without access to a keyboard.

Not my experience:

https://news.ycombinator.com/item?id=41481555

Re: Gnome Files: A detailed UI examination

#215

Post by mixmastamyk »

michaelmrose wrote: post #16
nextos wrote: post #3

I don't use Gnome since the days of version 2, which was really nice and friendly. But I was impressed by how well the latest iteration works in a tablet. That's a great advantage, because it's the same UI as a desktop. Plus, they have made sure all core applications work well using a touch UI.

Nobody uses tablet laptops in tablet mode because generally speaking it sucks. Using a touch screen to type sucks and sucks so much worse than your phone because its bigger and more awkward. Holding it in tablet mode is garbage because of size and weight. As soon as you have it propped up you might as well use the keyboard. It joins using a stylus for a phone and touch screen all in ones in the list of neat but compl…

I use them primarily for movies/TV.

Re: Gnome Files: A detailed UI examination

#216

Post by yoavm »

mixmastamyk wrote: post #207
yoavm wrote: post #114

this is anecdotal, but I just asked three non-techie friends who never seen GNOME before to change my Nautilus app to list view. Neither of them needed more than 5 seconds to do it.

Non-disabled folks can hit all toolbar buttons sequentially in under five seconds. The point are the hieroglyphics and misleading clues.

I was looking at what they were doing, and they were not clicking on all the toolbar buttons. They clicked on correct button, except one of them that first clicked on the dropdown next to it, and then on the button. My point is that even non-technical users, without any prior knowledge of the GNOME design language, don't seem to actually find it difficult to figure this out.

Re: Gnome Files: A detailed UI examination

#217

Post by tmtvl »

criticalfault wrote: post #189
0x_rs wrote: post #167

Earlier quoted context omitted.

>I'm just wondering who is then target audience for KDE? Only artists that use krita? Or teenagers that like to mod stuff? What a spiteful thing to say, it's very difficult for me to believe you are asking this genuinely. Firstly, KDE has no such "lack of apps". The majority of GNOME applications are far inferior to DE-independent "apps", so much so one may wonder why effort is even being spent into developing such f…

The question was a bit assholish, because rant. Fair to call me on it. Yes, I am aware that KDE audience is broader. Just remembered an additional good product from KDE: kdenlive. Let me try to put it in a better way: most of the time I have seen Linux in the wild (let's say companies) was Ubuntu/gnome. Even tv shows. And I don't remember ever seeing kde (LiMux aside since it is dead now). I have read that it is some…

> Not sure how steamdeck fits here, depends on what valve took. Last I read was a compositor. Di they actually use whole desktop with plasmoids?

On Steam Deck when you log in you get sent into Steam's Big Picture Mode, but you can switch to desktop, which sends you to a fairly standard X11 Plasma 5 desktop.

> If things are well thought out, why do I need to tinker with the desktop [...]?

Indeed, if things are _well_ thought out, there's no need to tinker with the desktop...

But certain things about GNOME are not well thought out (or at least, not for my use case), so when the defaults don't match my needs (and I can't really change my needs), I need to be able to change the defaults. And if I can't change the defaults I have a problem. An example would be the GNOME clock: I often need to fill out forms with day of week, year, month, and day of month; and if I can't set the clock in the panel to show that information, then that's a need that's not being fulfilled.

KDE similarly has shortcomings, I definitely wouldn't call it perfect (in fact I'm currently using LXQt with the Awesome window manager because between GNOME, KDE, and Cosmic none of them ticked enough boxes for me to be able to use them full time), but for some people I can well imagine it fits their needs better than GNOME.

And the hostility that the GNOME projects faces, I believe, is a consequence of internet communication being non-conductive to mutual understanding. The members of the GNOME project who interact with outsiders appear more abrasive than they intend to be and because of that people take a similarly aggressive stance towards the GNOME project.

Re: Gnome Files: A detailed UI examination

#218

Post by ruuda »

dylan-m wrote: post #204
ruuda wrote: post #143

I switched to Nemo after I got tired of Nautilus moving all the buttons for no particular reason every Gnome release, but a few versions ago they had a pattern that was genuinely good: a dropdown next to the current directory in the navigation bar, with everything you can do in the current directory (paste, create directory, open terminal, etc.). This was really neat, traditionally you have to access those by right-c…

> This was really neat, traditionally you have to access those by right-clicking some whitespace in the list/grid view, but in the list view there is only a narrow band of empty space to right-click, usually you accidentally click a file. So this was a genuine innovation in UI design. Unfortunately they since removed it again. Wait, no? It hasn’t. I’m looking at a fresh build from the main branch right now. The menu…

Yeah those others are in the triple dots menu, but paste is gone. Maybe I’m hallucinating that it was ever there, but I notice that I miss it which would be weird if it was never there in the first place.

Re: Gnome Files: A detailed UI examination

#219

Post by josephg »

kaba0 wrote: post #195
savolai wrote: post #164

Earlier quoted context omitted.

This should help you trace the argumentation to cited research that is certainly not ”tone deaf”: https://www.nngroup.com/articles/ten-usability-heuristics/ 1. *Consistency and Standards* Claim: "The 'View Options' dropdown didn't contain view options, but rather sort options, and I didn't realize it was a split button with two completely different functions." Violation: This breaks Consistency and Standards. The use…

Something like this would have been a better post than the linked one, but even this is not necessarily objective on each count - and design has a fundamentally subjective, human element based on our collective experience with every kind of interface, ever, which is affected by experience/culture, everything. E.g. in your list: there is no “dropdown name”, it’s a misidentified element by the post writer. Add to it th…

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

I suspect that I would struggle in many of the same points as the author. I suspect many other people would as well.

If you think this UI is good, do you want to make an objective claim? Do you think 8/8 people who walk past would figure out that split drop down button? It is very easy to test.

Yes this stuff is subjective. But rules and principles fall out pretty naturally from just asking people to try out your interfaces.

Re: Gnome Files: A detailed UI examination

#220

Post by Jnr »

manmal wrote: post #59

As someone totally out of the loop, what’s the status of font rendering in Gnome? The screenshots don’t look any better than 20 years ago, a jarring difference to what I‘m used to from macOS.

Look at the official screenshots, it looks great: https://release.gnome.org/46/

Font rendering on Linux has been fixed for >10 years but the OP has obviously forgot to update his font configuration or has turned off anti-aliasing and hinting for the legacy look and feel. :)

Post reply on HN