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

261–270 of 293 posts

Re: Gnome Files: A detailed UI examination

#261

Post by consteval »

criticalfault wrote: post #142
IshKebab wrote: post #122

Earlier quoted context omitted.

> their visuals are a disaster. Believe what you will, but visual consistency and attention to detail is what gnome has. They are not perfect, so there are some issues as OP points out, but they are on a different level from kde. KDE looks like it was frankensteined, while gnome it looks like it was designed. Yeah I totally agree with that. KDE has terrible aesthetics and great usability, Gnome has great aesthetics a…

I would disagree that gnome has terrible usability. It has a very good one. Nobody's saying it is perfect, but I and many other people can use it without issues. KDE has more features, so maybe *some* things are a bit easier. But everything else is way worse. Including lack of certain apps like a decent VM manager. I feel sorry for kde, the community there is way friendlier and whatnot, but this Frankenstein approach…

I don't know, I love the way KDE looks and feels. It's very fast and it's quite beautiful. Breeze, to me, is a very aesthetically pleasing theme.

And I'm not just saying that. Since the move to breeze in 5.0 I've thought it was pretty. Since then it's only improved. I really like the icons too - they're vibrant, but not completely flat. I like bright colors, sharp lines, higher contrast.

I really, really don't see this Frankenstein approach viewpoint. To me every KDE app feels and functions like a KDE app. GTK apps stick out like a sore thumb in the desktop world. They have big buttons, nothing is labeled, the title bar is huge for some reason. You kinda just have to guess what clicking buttons does. KDE apps are more closely aligned with traditional desktop applications I've been familiar with since XP. I like that.

On a usability note, I think KDE is super good here too. I really like the apps, many I consider best-in-class.

Kate is really good, dolphin is the best file manager I've used, kdevelop is a fantastic ide. Even random things, like kinfocenter (the system information pop-up) are really, really good. Krunner is great, the new system monitor is the best I've ever used. The new application menu is perfect.

Re: Gnome Files: A detailed UI examination

#262

Post by mixmastamyk »

yoavm wrote: post #240
mixmastamyk wrote: post #221

Earlier quoted context omitted.

You may have a uncommon idea of non-technical people. Such folks don’t know what a list view even is, and would have to have it explained. Not to mention a filesystem.

I told them something like "I'm going to show you an app showing files as a bunch of icons, can you try to make it show the files as a list instead?". You seem to be very skeptical - did you try asking someone around you and got a different result?

Yes—we can see it's a suboptimal design on its face.[1] Bunch of repetitive dots and lines, with misleading clues. Not everyone is going to respond to it the same way of course. Some folks don't bother with clues.

The main point is that this problem has been solved already, better and in the past, by products delivered to tens of millions of seats. Merely copying prior art would have sufficed.

Responding with, "I found some non-techies who didn't have a problem" is not a direct response to the idea that the design could be improved. Folks can persevere and ultimately succeed through poor designs... in fact we all do it every day.

Some of us would like to use products that are a little more thoughtful than the bare minimum attainable-through-perseverance functionality, however.

[1] https://ux.stackexchange.com/questions/1795/when-to-use-icon...

Re: Gnome Files: A detailed UI examination

#263

Post by berniedurfee »

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 think this is the same behavior in Finder on MacOS. Sometimes right clicking requires some pixel-perfect sniping to hit just the right spot.

Re: Gnome Files: A detailed UI examination

#264

Post by akho »

hedora wrote: post #38
comex wrote: post #9

Decent critique, but it mixes together two things: the design language, and UI papercuts showing a lack of attention to detail. Consider the current macOS Finder: https://a.qoid.us/20240907-finder.png Finder's design is extremely similar to GNOME Files! And so the inherent downsides of the design language are present in Finder too, such as it being harder to drag windows around or click to activate windows. But macOS…

The current version of Finder is a massive regression from what it used to be. If you don’t believe me, fire up https://macos9.app on a machine with a mouse, and try organizing / browsing some files.

> a massive regression from what it used to be

So is Gnome Files, and in very similar ways.

Re: Gnome Files: A detailed UI examination

#265

Post by akho »

senko wrote: post #244
eviks wrote: post #230

Earlier 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…

> I haven't seen any terminal apps that actually do what you praise

Micro editor, Emacs with CUA-mode.

Very few TUIs respect Ctrl-C. Note how it doesn’t quit your shell, for example. It’s more that it’s bound to something already, and there is no common concept of a clipboard between terminal applications anyway.

Asking the terminal itself to copy on Ctrl-C, and send Ctrl-C on Ctrl-Shift-C, is usually uncomplicated. If that’s something the user wants. We allow all sorts.

Re: Gnome Files: A detailed UI examination

#266

Post by greatgib »

comex wrote: post #9

Decent critique, but it mixes together two things: the design language, and UI papercuts showing a lack of attention to detail. Consider the current macOS Finder: https://a.qoid.us/20240907-finder.png Finder's design is extremely similar to GNOME Files! And so the inherent downsides of the design language are present in Finder too, such as it being harder to drag windows around or click to activate windows. But macOS…

In my opinion, OS X Finder is the most defective file browser of them all.

It always makes me laugh when some people believe the marketing of Apple saying that their OS is the most ergonomic when it is totally not the case.

Things like creating a new folder is a nightmare, if you are in the kind of a tree view and try to create a folder or paste a file, it will end up in the top parent folder.

When you sort by recent date it does not make any sense: you have files from the most recent to the oldest, but for a given day, like the last day or week, they are ordered in the opposite way (oldest to newest).

There are hundreds of other stupid decisions like that.

In the same way, who had this brillant (ie stupid) idea that the enter key will edit the file name name instead of opening it? Using a major keyboard key for an operation that you rarely do!

Re: Gnome Files: A detailed UI examination

#267

Post by yoavm »

mixmastamyk wrote: post #262
yoavm wrote: post #240

Earlier quoted context omitted.

I told them something like "I'm going to show you an app showing files as a bunch of icons, can you try to make it show the files as a list instead?". You seem to be very skeptical - did you try asking someone around you and got a different result?

Yes—we can see it's a suboptimal design on its face.[1] Bunch of repetitive dots and lines, with misleading clues. Not everyone is going to respond to it the same way of course. Some folks don't bother with clues. The main point is that this problem has been solved already, better and in the past, by products delivered to tens of millions of seats. Merely copying prior art would have sufficed. Responding with, "I fou…

That's a very long and quite condescending way to say you actually didn't ask anyone.

Re: Gnome Files: A detailed UI examination

#268

Post by hulitu »

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…

> It would be better to have these common tasks in a separate menu item in the icon bar where they are always available,

And which icon shall have this menu ? Points and lines are already taken. /s

Re: Gnome Files: A detailed UI examination

#269

Post by hulitu »

comex wrote: post #9

Decent critique, but it mixes together two things: the design language, and UI papercuts showing a lack of attention to detail. Consider the current macOS Finder: https://a.qoid.us/20240907-finder.png Finder's design is extremely similar to GNOME Files! And so the inherent downsides of the design language are present in Finder too, such as it being harder to drag windows around or click to activate windows. But macOS…

> Finder's design is extremely similar to GNOME Files!

So MacOSX is going also downhill in GUI design. Good to know. /s

Re: Gnome Files: A detailed UI examination

#270

Post by hulitu »

kaba0 wrote: post #81
savolai wrote: post #60

Earlier 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

What data does he have? OP wrote a basic opinion-piece on what they dislike. It’s just as valuable as the parent commenter’s opinion, so we can only say that one user found some feature hard to find. There is no ultimate design, and striving for 100% of users knowing everything immediately is just unrealistic. If we are at opinions, I really dislike this absolutely tone-deaf attacking of GNOME that is always happenin…

> There is definitely places to improve, though, but the style of writing matters.

And which kind of "style of writing" would tell them that their GUI sucks big time and they should not reinvent the wheel and should not copy Microsoft and Apple ?

Post reply on HN