Updated GNOME User Interface Guidelines are now official(developer.gnome.org)
developer.gnome.org
Updated GNOME User Interface Guidelines are now official
https://developer.gnome.org/hig/
79 comments
I've been using Gnome for years and it's basically the best kept secret among desktop environments. Simple, unobtrusive, and continuously improving without many sudden changes that force one to relearn how to use it. I've tried tiling window managers but they just eat up time configuring to my liking. Compared with Windows and MacOS, I'm delighted with how easy it is to configure and use Gnome right out of the box. The UI is consistent and these guidelines are refreshingly concise.
> and continuously improving without many sudden changes that force one to relearn how to use it.
LOL. Have we used the same GNOME? Their evolution is nothing but removing features and maximizing useless padding.
LOL. Have we used the same GNOME? Their evolution is nothing but removing features and maximizing useless padding.
I'd have to agree. GNOME is notorious for this. We used to joke on slashdot over a decade ago about how one day GNOME would just have a single giant "do stuff" button.
I remember that. And I also remember people commenting that an UI with a single button that does exactly what is expected would be a supreme UI.
Obligatory The Onion: https://www.youtube.com/watch?v=9BnLbv6QYcA
What features are you missing? Because I've had to tweak some dconf settings over the years but I've never found myself wanting something I could do before but is now impossible.
No sudden changes? Gnome3 was a pox and broke literally everything.
The entire family of touch friendly interfaces on non touch systems can fall into a black hole, and the world would be better for it.
The entire family of touch friendly interfaces on non touch systems can fall into a black hole, and the world would be better for it.
> No sudden changes? Gnome3 was a pox and broke literally everything.
And it was released 10 years ago... perhaps it's time to move on from old grudges
And it was released 10 years ago... perhaps it's time to move on from old grudges
> perhaps it's time to move on from old grudges
I'll be happy to move on from my grudge over their promulgating Gnome3 at the expense of Gnome2 when they stop promulgating Gnome3 and resume support of Gnome2.
I'll be happy to move on from my grudge over their promulgating Gnome3 at the expense of Gnome2 when they stop promulgating Gnome3 and resume support of Gnome2.
It was never fixed though...
I hear people complaining about gnome3 the same way I heard people complaining about kde4. Then I get happy when I reason that these events occurred more than a decade ago.
Make all your Gnome windows maximized and it's the next best thing to i3, except way more polished and stable.
"polished" is subjective enough that I won't say you're wrong (although I don't agree), but how can you be more stable than i3, in any sense? It doesn't leak memory (https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem...), it doesn't crash, it doesn't change (UI/UX is a kind of stable, too), and it can seamlessly restart itself in place without any disruption to the actual user session.
> It doesn't leak memory (https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem...), it doesn't crash, it doesn't change (UI/UX is a kind of stable, too), and it can seamlessly restart itself in place without any disruption to the actual user session.
None of that was true when I last used i3. YMMV.
None of that was true when I last used i3. YMMV.
> The entire family of touch friendly interfaces on non touch systems can fall into a black hole, and the world would be better for it.
There's really no reason for this inflammatory response and starting a flame war
Obviously, others disagree with you. The world would not be better if everyone conformed to your view of what a UI should be
There's really no reason for this inflammatory response and starting a flame war
Obviously, others disagree with you. The world would not be better if everyone conformed to your view of what a UI should be
Gnome is great for its touch-native support, but on most desktops and laptops where touch just isn't a thing I find Xfce to be more intuitive, and also lighter on system resources.
Gnome (specially gnome-shell) is also very keyboard centric (not as much as tiling WMs obviously), which works really well for normal laptops.
> ...Simple, unobtrusive, and continuously improving without many sudden changes that force one to relearn how to use it.
In all those past decades of Desktop Env evolution, one thing I learned to appreciate is no need to be aware of the actual kind of Environment. Ideal DE should just be transparent to user, just as the underlying OS.
We interact with tools, the environment just lets us find them and helps us organize our stuff.
I get aware of the DE when it somehow gets in my way. For example, I remember from Ubuntu 18 in Gnome Terminal context menu two entries shared the same hot-key (_Preferences and _Paste in this order). Or in File manager, there was no direct way to enter full path. Or in Save As dialog the file name would loose its highlight after switching back from selecting the destination folder.
Sure, other DEs have their share of annoyance, but generally I think that transparency will be upon us... soon.
In all those past decades of Desktop Env evolution, one thing I learned to appreciate is no need to be aware of the actual kind of Environment. Ideal DE should just be transparent to user, just as the underlying OS.
We interact with tools, the environment just lets us find them and helps us organize our stuff.
I get aware of the DE when it somehow gets in my way. For example, I remember from Ubuntu 18 in Gnome Terminal context menu two entries shared the same hot-key (_Preferences and _Paste in this order). Or in File manager, there was no direct way to enter full path. Or in Save As dialog the file name would loose its highlight after switching back from selecting the destination folder.
Sure, other DEs have their share of annoyance, but generally I think that transparency will be upon us... soon.
How is Gnome a secret, when it's the default DE on nearly every distro? KDE gets that title from me.
Compared to Windows and MacOS it's a secret. I don't consider Ubuntu's desktop environment as pure GNOME, otherwise why would https://ubuntugnome.org/ exist?
That project looks pretty dead.
I highly recommend Regolith Linux (which can also just be installed as a package on Ubuntu).
It offers a nicely setup i3 tiling WM, without having to do any configuration, and things like external displays, bluetooth and so on working out of the box, since it relies on various pieces of GNOME to do that.
It offers a nicely setup i3 tiling WM, without having to do any configuration, and things like external displays, bluetooth and so on working out of the box, since it relies on various pieces of GNOME to do that.
I recently switched from KDE to GNOME and I was pleasantly surprised to see the finesse of it. I realized that my misconceptions about GNOME was due to poor integrations in the distros which had it by default.
Installing vanilla GNOME over Arch gave me a new outlook of it, Other comments about it's padding and non-Linux like UI approach might be valid but I'm sure that will enable someone from macOS feel at home as I've used that for a decade as well.
Installing vanilla GNOME over Arch gave me a new outlook of it, Other comments about it's padding and non-Linux like UI approach might be valid but I'm sure that will enable someone from macOS feel at home as I've used that for a decade as well.
It would seem not many here agree with you, but I do. Gnome 38/40 has been a pleasurable daily work env for me
I'm pleasantly surprised seeing how great Gnome looks and runs on my colleague's System76. If I ever decided to quit MacBooks I would definitely like to try using it full time.
How do you configure Gnome to show thumbnails in the filepicker? I've never been able to do that.
Click on the Show grid/list toggle icon on the top right. When showing icons in a grid I see thumbnails.
In which version does this grid/list togge icon exist? It's not in Ubuntu 20.04 LTS (which we use at work at the moment).
In my Ubuntu 20.04 LTS, i see the grid/list toggle icon in the top right just to the left of the minimize/maximize/close icons on the top bar of the File browser window. Once you click that, you can adjust the size of the thumbnail(s) by CTRL-scrolling or CTRL-+/-
That must be a different window - the file browser. The open file dialog doesn't have close buttons, so you're not looking at that. I believe the main discussion here is about the open file dialog, the "file picker".
The file picker shows thumbnails by default.
The file picker I see uses a list with thumbnails, but since it's a list the pictures are tiny for each file, not very usable.
I'm reading the design principles right now. A lot of them are sane and reasonable; my issue is with what's missing.
>Resist the pull to try and make an app that suits all people in all situations. Focus on one situation, one type of experience.
A kitchen sink is bad. An incomplete program is even worse. So, even if focusing on one situation and one target audience, make sure that your program is reasonably complete.
>Don’t overwhelm people with too many elements at once. Use progressive disclosure and navigation structures to provide a guided experience.
Tracking complexity is more important than the "raw" number of elements being shown. That's why consistency is so important. Refer also to what I said about "incomplete programs", it applies to the UI.
Guiding user experience is good, but remember that your user is not a moron, and does not want to be treated as one. There's a difference between pointing the right direction and pulling someone by a dog choker.
Poorly used progressive disclosure makes every non-trivial task a chore, so make sure you're doing it right.
>Frequently used actions should be close at hand, with less important actions being further away.
Ultimately who decides which actions are "more" or "less" important is not you, but the user; you can at most estimate it, for your typical user, in typical user cases. So make sure even the less important actions are close enough.
>If something can be done automatically, do it automatically.
>Try to anticipate and prevent mistakes.
Don't be an assumer. Don't code your program to be an assumer either. Nothing is more aggravating than a program incorrectly automating something, based on assumptions. Or preventing the user from doing something sane in context, that the developer didn't take into account.
>Resist the pull to try and make an app that suits all people in all situations. Focus on one situation, one type of experience.
A kitchen sink is bad. An incomplete program is even worse. So, even if focusing on one situation and one target audience, make sure that your program is reasonably complete.
>Don’t overwhelm people with too many elements at once. Use progressive disclosure and navigation structures to provide a guided experience.
Tracking complexity is more important than the "raw" number of elements being shown. That's why consistency is so important. Refer also to what I said about "incomplete programs", it applies to the UI.
Guiding user experience is good, but remember that your user is not a moron, and does not want to be treated as one. There's a difference between pointing the right direction and pulling someone by a dog choker.
Poorly used progressive disclosure makes every non-trivial task a chore, so make sure you're doing it right.
>Frequently used actions should be close at hand, with less important actions being further away.
Ultimately who decides which actions are "more" or "less" important is not you, but the user; you can at most estimate it, for your typical user, in typical user cases. So make sure even the less important actions are close enough.
>If something can be done automatically, do it automatically.
>Try to anticipate and prevent mistakes.
Don't be an assumer. Don't code your program to be an assumer either. Nothing is more aggravating than a program incorrectly automating something, based on assumptions. Or preventing the user from doing something sane in context, that the developer didn't take into account.
'The inmates are running the asylum' has a discussion about an element I think they are missing: personas.
The book discussed how 'user' is elastic: The average user is defined so vague that you can stretch the definition in every way you want. Enter personas. Each is a description of an invented but recognizable person, including name, lifestyle, background, ... A bit of an advanced cliché. Then you can say how well your program fits for that persona.
For gnome, you could have Ginny the grandmother who prefers everything easy and with a cat background. You have Eddy the console addicted linux expert. You have Danny the 9 to 5 bigco developer who just wants to get his work done and go home, and some higher up forced GNOME on him.
When these personas are reasonably well known, the development team as a whole can discuss UI changes in their terms. We're going to remove all but one shutdown option? Ginny will like it, Eddy's gonna hate us. But Eddy knows all hotkeys, maybe hide the more advanced option under the ALT button? You can even exclude personas: Gnome is developed for Ginny, Eddy should go away and use KDE.
The book discussed how 'user' is elastic: The average user is defined so vague that you can stretch the definition in every way you want. Enter personas. Each is a description of an invented but recognizable person, including name, lifestyle, background, ... A bit of an advanced cliché. Then you can say how well your program fits for that persona.
For gnome, you could have Ginny the grandmother who prefers everything easy and with a cat background. You have Eddy the console addicted linux expert. You have Danny the 9 to 5 bigco developer who just wants to get his work done and go home, and some higher up forced GNOME on him.
When these personas are reasonably well known, the development team as a whole can discuss UI changes in their terms. We're going to remove all but one shutdown option? Ginny will like it, Eddy's gonna hate us. But Eddy knows all hotkeys, maybe hide the more advanced option under the ALT button? You can even exclude personas: Gnome is developed for Ginny, Eddy should go away and use KDE.
That's a good approach. If you back it up with a study of your target audience, and creates the personae in a way that it represents it well, you could even take decisions like "We could annoy Ginny for the sake of Eddy and Frank, it'll make the software better for most people... but we're better off throwing her a bone too."
I don't think GNOME devs have such an insight. They claim to be right too often, too soon; I don't trust people like this to take smart decisions.
I don't think GNOME devs have such an insight. They claim to be right too often, too soon; I don't trust people like this to take smart decisions.
A few days ago HN had an article about dumb vs stupid or something. The first being a low quality brain, but the second could happen when smart people work with the wrong mental framework.
I fear GNOME is locked in the second problem. Clearly they have a lot of smart people over there, but I also see a lot of wasted effort and dumbing down. One aspect of the wrong mental framework would be working for the nonexistant elastic average user. Another example would be their stance on the unimportance of backward compatibility.
I fear GNOME is locked in the second problem. Clearly they have a lot of smart people over there, but I also see a lot of wasted effort and dumbing down. One aspect of the wrong mental framework would be working for the nonexistant elastic average user. Another example would be their stance on the unimportance of backward compatibility.
Well, Eddy will not install Gnome for Ginny when he thinks that Gnome is crap. We will just install KDE.
I really like the app naming guidelines.
https://developer.gnome.org/hig/guidelines/app-naming.html
> [Avoid] puns and inside jokes.
https://developer.gnome.org/hig/guidelines/app-naming.html
> [Avoid] puns and inside jokes.
Atleast logos are an exception
https://gitlab.gnome.org/Teams/Circle/-/issues/50
https://gitlab.gnome.org/Teams/Circle/-/issues/50
> > [Avoid] puns and inside jokes
Those are only allowed in KDE universe.
Those are only allowed in KDE universe.
> [Avoid] Having a “G” prefix (for example: GMusic).
Those are not allowed in KDE universe. You need "K" prefix instead.
Those are not allowed in KDE universe. You need "K" prefix instead.
I remember a friend of mine arguing prefixing names with g, q and k was a reason linux on the desktop failed. I asked "So, how do you explain the success of ipod, iphone, ipad and itunes?"
Because it's a vowel and always followed by a consonant, so you can always intuitively pronounce those names.
[deleted]
consonants vs. vowel?
I feel what your friend is saying. I'm not sure why, but the K prefix in a name always felt "unprofessional" and/or ugly.
I can't exactly put my finger on why it feels that way
I can't exactly put my finger on why it feels that way
[deleted]
I never liked them because it fragmented the space of apps available on Linux. You'd be looking for an app that replaces something on windows, and inevitably you'd find something, but it starts with a 'k' and you're on gnome. And now you're not sure whether it'll work for you, or whether you need to install a bunch of extra stuff to run one app, or whether you should keep looking for another 'g' alternative, or whether you need to just dual boot windows.
> You need "K" prefix instead.
You mean when I start up the Plasma desktop, open my home folder in Dolphin, start playing a movie in Dragon Player while I edit a document in the Calligra office suite?
"Need" is an exaggeration.
You mean when I start up the Plasma desktop, open my home folder in Dolphin, start playing a movie in Dragon Player while I edit a document in the Calligra office suite?
"Need" is an exaggeration.
We have Gcompris but in general K-Names in KDE are also not recommended for new applications.
The ultimate litmus test for any GUI is to ask a relative with average computer skills to perform basic tasks in your program.
If he/she asks questions like "why the fuck is the Confirm button up with on the window handle?" Or "Where are the small previews when I'm selecting images?" you have failed. In its current state GTK is not only a footgun, but a footgun factory with the biggest manufacturing throughput in the GUI library world.
And I'm not writing this out of spite. I want GTK to be successful and I do believe some of the underlying tech is great but the actual ui/ux choices it want's to steer you towards are consistently terrible almost to the point of "want to do $THING? Check how gnome apps do it and do the complete opposite."
If he/she asks questions like "why the fuck is the Confirm button up with on the window handle?" Or "Where are the small previews when I'm selecting images?" you have failed. In its current state GTK is not only a footgun, but a footgun factory with the biggest manufacturing throughput in the GUI library world.
And I'm not writing this out of spite. I want GTK to be successful and I do believe some of the underlying tech is great but the actual ui/ux choices it want's to steer you towards are consistently terrible almost to the point of "want to do $THING? Check how gnome apps do it and do the complete opposite."
> The ultimate litmus test for any GUI is to ask a relative with average computer skills to perform basic tasks in your program.
I strongly disagree! People with "average computer skills" expect that "to perform basic tasks" things must be done EXACTLY the way they are used to. It doesn't matter if the different way is better, faster, more efficient, more intuitive... if it is different they will likely complain.
I strongly disagree! People with "average computer skills" expect that "to perform basic tasks" things must be done EXACTLY the way they are used to. It doesn't matter if the different way is better, faster, more efficient, more intuitive... if it is different they will likely complain.
To me it seems like GNOME apps/gtk have positioned themselves as the "GUI for the masses" as they follow all the terrible trends from others like massive padding,low content density, phone like controls. But that also means catering to the usage patterns and expectations of this demograpic.
1) Actually intuitive (this is rare—if you think your novel idea is, it likely isn't),
2) The same way the user's used to or expects,
3) Everything else
GUI approaches, ranked best to worst. Something from #3 should always strongly demonstrate that it's actually in category #1 before displacing something from category #2, or otherwise provide immense value.
UI churn keeping interfaces mostly stuck in #3 is a curse on computing.
[EDIT] Oh, and, an adjacent principal: consistency of placement & behavior beats everything else. Which is another strong point against modifying UIs without very good reason.
2) The same way the user's used to or expects,
3) Everything else
GUI approaches, ranked best to worst. Something from #3 should always strongly demonstrate that it's actually in category #1 before displacing something from category #2, or otherwise provide immense value.
UI churn keeping interfaces mostly stuck in #3 is a curse on computing.
[EDIT] Oh, and, an adjacent principal: consistency of placement & behavior beats everything else. Which is another strong point against modifying UIs without very good reason.
Intuitive maybe == skeuomorphic which in turns means that it builds on the training and the expectations of all a lifetime.
There is little of intuitive in the UIs I used since the 80s. The first X11 windows manager I used (twm?) didn't have a menu or a dock or whatever. I stated the applications from a xterm and I could iconize them to the desktop, move the icon around, resume them by double clicking the icon. That was intuitive for me. The Windows task bar was an important improvement, more than the start menu. Virtual desktops where great and sorely missed on Windows. Anything else, less important.
There is little of intuitive in the UIs I used since the 80s. The first X11 windows manager I used (twm?) didn't have a menu or a dock or whatever. I stated the applications from a xterm and I could iconize them to the desktop, move the icon around, resume them by double clicking the icon. That was intuitive for me. The Windows task bar was an important improvement, more than the start menu. Virtual desktops where great and sorely missed on Windows. Anything else, less important.
> Intuitive maybe == skeuomorphic which in turns means that it builds on the training and the expectations of all a lifetime.
Sure, but everyone brings some familiarity with the physical world to the table. The first things babies learn are the effects of pushing on things, some idea of weight & momentum & gravity, et c. The best UIs build on that when possible. If you push two things together and they "click", they should stay stuck together until "pulled" apart somehow. This is why touch screens can be (but aren't often, since iOS took a big shift in version 7, anyway) very intuitive—they allow more natural and direct interaction with what's happening on the screen. You can "push" two things together, you can "pull" them apart, you can "squeeze" things, you can press on them, and there's not even the abstraction of a mouse in the way. Even with a mouse, clicking is abstract (I'm clicking down here, something's happening up on the screen), motion is surrogate, "dragging" is very abstract when you think about it, et c, and that's where you start with desktop UIs, before you even throw in anything else.
Sure, but everyone brings some familiarity with the physical world to the table. The first things babies learn are the effects of pushing on things, some idea of weight & momentum & gravity, et c. The best UIs build on that when possible. If you push two things together and they "click", they should stay stuck together until "pulled" apart somehow. This is why touch screens can be (but aren't often, since iOS took a big shift in version 7, anyway) very intuitive—they allow more natural and direct interaction with what's happening on the screen. You can "push" two things together, you can "pull" them apart, you can "squeeze" things, you can press on them, and there's not even the abstraction of a mouse in the way. Even with a mouse, clicking is abstract (I'm clicking down here, something's happening up on the screen), motion is surrogate, "dragging" is very abstract when you think about it, et c, and that's where you start with desktop UIs, before you even throw in anything else.
> Actually intuitive
I would say that 'discoverable' is much more important and also better defined than 'intuitive'.
I would say that 'discoverable' is much more important and also better defined than 'intuitive'.
Intuitiveness is about matching expectations. The more universal the expectations, or the experience they're based on, the more successful leveraging "intuitive" design will be. That's why intuitive design tends to be tied to physical metaphors or stand-ins.
I agree that discoverability is great, and it's also something computer UIs tend to be terrible at. The #1 distinguishing characteristic of a discoverable UI is that the user feels very safe experimenting. If they're afraid to try things, they can't discover much. UIs rarely achieve this, and you can see the effect in how anxious most people get doing anything even slightly unfamiliar on their computer.
I agree that discoverability is great, and it's also something computer UIs tend to be terrible at. The #1 distinguishing characteristic of a discoverable UI is that the user feels very safe experimenting. If they're afraid to try things, they can't discover much. UIs rarely achieve this, and you can see the effect in how anxious most people get doing anything even slightly unfamiliar on their computer.
What would be some examples of actually intuitive?
To me, intuitive ~= familiar, similar to something you already know how to use.
To me, intuitive ~= familiar, similar to something you already know how to use.
You are 100% correct - intuitive only makes sense from a particular frame of refrence
Guestures on phones are considered intuitive, but take my phone to 1980 and it would be considered quite difficult to use.
Guestures on phones are considered intuitive, but take my phone to 1980 and it would be considered quite difficult to use.
I think the concept that one can touch a screen and make something happen would be alien enough to throw people off (it might simply not occur to them to try), but I'm pretty sure there are at least examples of UI elements on touchscreen phones—though not entire systems—that would be fairly intuitive even to someone in the 1960s, let alone the 1980s.
Modern "slide (or swipe) screen to unlock" would throw them (what the fuck does it mean to "slide" or "swipe" the screen"?) but (to pick an example I used in another post) I bet an iOS6 "slide to unlock" would be very easy for them. What do you slide? The thing that looks like it slides. Easy. How do you do it? Exactly the way you'd guess you do. I may not know what it means to "unlock" in this context, but there's not much else to do, so trying it... ta da, something happened, and there's a bunch more stuff on the screen now.
Modern "slide (or swipe) screen to unlock" would throw them (what the fuck does it mean to "slide" or "swipe" the screen"?) but (to pick an example I used in another post) I bet an iOS6 "slide to unlock" would be very easy for them. What do you slide? The thing that looks like it slides. Easy. How do you do it? Exactly the way you'd guess you do. I may not know what it means to "unlock" in this context, but there's not much else to do, so trying it... ta da, something happened, and there's a bunch more stuff on the screen now.
Entirely true. In computing, making something intuitive has a lot to do with leveraging familiarity with he physical world, and avoiding making things too abstract or "computery", and with making the effect be what one would expect for the action based on prior experience, especially outside computing. This is hard to do well, and often complexity of what software needs to do makes it practically impossible, so it's not always achievable (I noted that it's rare).
Heavy users of computers develop intuition for more computery, abstract interfaces through exposure, but this is a small slice of people—the rest follow tried & true patterns but just hope for the best, with little confidence or understanding, which is why UI changes are so damaging for them—and is kinda related to how various conventions in video games can read as intuitive and pick-up-and-play to seasoned gamers but are not at all to newbies—watch a young kid with no gaming experience struggle with Super Mario Brothers 1-1 with a D-Pad (four discrete directions) and just 2 buttons. This is a level that acts as a natural tutorial to the game, but it's still a bunch of trial-and-error as an experience, and is difficult because the mapping of the six button presses to actions on the screen is (I think this isn't well-enough appreciated) very abstract. Compare with watching a kid learn to drive an electric kids' car (like a Powerwheel) with forward, reverse, and steering. Similarly complex, but in my experience they pick it up faster. The controls map more closely to the effect, I think is the reason, even though the wheel is fairly abstract. Stick forward, you're going forward. Stick back, you're going back. Push pedal, go. Turn wheel right, go right. Turn wheel left, go left. The least-intuitive thing is easily the brake pedal (if there is one—often they just stop when you let off the "gas"), and of course reversing messes up adults, even, by switching everything around (right to go left, push pedal forward to go backward, et c.).
Examples that I used on here just the other day: the iOS 6 and earlier unlock slider (obviously interactive, looks like a familiar control from the real world that's sometimes used to undo a latch, the only obviously-interactive thing on the screen, follows the motion of your finger as if you were moving a real object—you hardly even need the instructions "slide to unlock"), and the way "folders" worked on same, mostly the way that they made them feel like a physical thing existing under the Home Screen so there was no state change across the entire screen—the screen "split apart" to reveal what was ("always") "under it", leaving part of the Home Screen visible, and sure enough, touching that still-visible part would slide the folder shut again. The folders were also limited in capacity—no abstract scrolling, they were like a physical space, with limits.
Spatial finder on pre-OSX macOS is another, more subtle example. 3-pane browsing, file managers that change as one browses folders rather than opening a new window, and file managers that do open new windows but don't retain their position on the screen, are all more abstract to various degrees. They break the connection between action and effect, and the connection between what's visible and what's being operated on ("this window was that folder, but now it's this other folder? Where'd the first one go?"). In that case (and many), the more-intuitive option may be strictly at-odds with more efficient operation for seasoned users.
Basically: can a user leverage what they know, or do they have to learn how their actions connect to whatever thing you've made those actions do? Everyone exists and grows up in a physical world, which remains fairly static over long periods of time, so things they know from that work well. Computer interfaces have developed some long-lived conventions, but a lot of it churns way too much to be reliably "intuitive".
Heavy users of computers develop intuition for more computery, abstract interfaces through exposure, but this is a small slice of people—the rest follow tried & true patterns but just hope for the best, with little confidence or understanding, which is why UI changes are so damaging for them—and is kinda related to how various conventions in video games can read as intuitive and pick-up-and-play to seasoned gamers but are not at all to newbies—watch a young kid with no gaming experience struggle with Super Mario Brothers 1-1 with a D-Pad (four discrete directions) and just 2 buttons. This is a level that acts as a natural tutorial to the game, but it's still a bunch of trial-and-error as an experience, and is difficult because the mapping of the six button presses to actions on the screen is (I think this isn't well-enough appreciated) very abstract. Compare with watching a kid learn to drive an electric kids' car (like a Powerwheel) with forward, reverse, and steering. Similarly complex, but in my experience they pick it up faster. The controls map more closely to the effect, I think is the reason, even though the wheel is fairly abstract. Stick forward, you're going forward. Stick back, you're going back. Push pedal, go. Turn wheel right, go right. Turn wheel left, go left. The least-intuitive thing is easily the brake pedal (if there is one—often they just stop when you let off the "gas"), and of course reversing messes up adults, even, by switching everything around (right to go left, push pedal forward to go backward, et c.).
Examples that I used on here just the other day: the iOS 6 and earlier unlock slider (obviously interactive, looks like a familiar control from the real world that's sometimes used to undo a latch, the only obviously-interactive thing on the screen, follows the motion of your finger as if you were moving a real object—you hardly even need the instructions "slide to unlock"), and the way "folders" worked on same, mostly the way that they made them feel like a physical thing existing under the Home Screen so there was no state change across the entire screen—the screen "split apart" to reveal what was ("always") "under it", leaving part of the Home Screen visible, and sure enough, touching that still-visible part would slide the folder shut again. The folders were also limited in capacity—no abstract scrolling, they were like a physical space, with limits.
Spatial finder on pre-OSX macOS is another, more subtle example. 3-pane browsing, file managers that change as one browses folders rather than opening a new window, and file managers that do open new windows but don't retain their position on the screen, are all more abstract to various degrees. They break the connection between action and effect, and the connection between what's visible and what's being operated on ("this window was that folder, but now it's this other folder? Where'd the first one go?"). In that case (and many), the more-intuitive option may be strictly at-odds with more efficient operation for seasoned users.
Basically: can a user leverage what they know, or do they have to learn how their actions connect to whatever thing you've made those actions do? Everyone exists and grows up in a physical world, which remains fairly static over long periods of time, so things they know from that work well. Computer interfaces have developed some long-lived conventions, but a lot of it churns way too much to be reliably "intuitive".
The average person understands the Windows UI and is lost on a Mac and on any Linux. Maybe not on KDE which 7 years ago looked like Windows quite a lot, don't know now.
you're too harsh, you can always find an average user that will freak out on something unexpected
good to think about average users, but IMO there's a balance between altruism and value of change, if that change brings a lot of benefits to the average users
good to think about average users, but IMO there's a balance between altruism and value of change, if that change brings a lot of benefits to the average users
Are we getting thumbnails in the filepicker? https://jayfax.neocities.org/mediocrity/gnome-has-no-thumbna...
Outside of that little joke (although it's a real problem), it's nice to have something like this. It will help developers to make coherent interfaces and the GNOME ecosystem will get better with this. I personally like GNOME, I use it mainly through Pop!_OS as I really don't like snaps.
Outside of that little joke (although it's a real problem), it's nice to have something like this. It will help developers to make coherent interfaces and the GNOME ecosystem will get better with this. I personally like GNOME, I use it mainly through Pop!_OS as I really don't like snaps.
I used the Gnome 3.38 desktop for about a year, and it may have been one of my favorite desktop experiences yet. GTK+ felt robust and mature for my needs, stuff looked pretty and functioned mostly the same way. The guidelines weren't perfect, but years of incremental improvement got it pretty damn close. Gnome 40's "no sacred cows" approach is throwing a lot of that work away, and it ultimately deterred me from staying on rolling-release Gnome. Adding insult to injury, GTK4 support is basically in pre-alpha right now. The widget website and design reference was broken for weeks, and transitioning Gnome 3.38 code to 40 just isn't worth the trouble.
GTK3 isn't deprecated (like GTK2 is), and there is no rush to port things to GTK4 yet. In terms of it being 'pre-alpha' (besides the docs, which in my experience before was always lagging behind), everything in the roadmap is basically done: https://wiki.gnome.org/Projects/GTK/Roadmap/GTK4
On the other hand, the changes in Gnome 40 were not as massive as the change from 2 to 3, and to me at least the change felt more incremental than disruptive (of course, the transition period is always a bit rough, some non-essential extensions for gnome-shell didn't work for me after the change, but eventually everything I needed was ported--I even dropped some extensions). I feel that saying that 'a lot of the work from 3 was thrown away' is an overstatement.
On the other hand, the changes in Gnome 40 were not as massive as the change from 2 to 3, and to me at least the change felt more incremental than disruptive (of course, the transition period is always a bit rough, some non-essential extensions for gnome-shell didn't work for me after the change, but eventually everything I needed was ported--I even dropped some extensions). I feel that saying that 'a lot of the work from 3 was thrown away' is an overstatement.
I'm excited for the Debian 11 release this weekend, because that means the testing repository unfreeze will allow Gnome 40 to come into play soon
Did you know that since GNOME 3.36 extensions are automatically updated, and you can't officially turn off the feature? On top of it, I think updates from GNOME Shell Extensions aren't even signed.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2514
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2514
It doesn't update when I use Nix to manage extensions, so maybe that's a saving grace here.
Granted, nothing updates unless I update it via Nix, so perhaps that's not entirely desirable to everyone.
Granted, nothing updates unless I update it via Nix, so perhaps that's not entirely desirable to everyone.
> nothing updates unless I update it
That how computers (or really, things-that-exist in general) are supposed to work.
That how computers (or really, things-that-exist in general) are supposed to work.
A lot of good stuff in there. I enjoy Gnome quite a bit and aesthetics and flow are large part of that
Is there a changelog or “what’s new” page somewhere?