This post is a part of a short series, in which I’m setting out what I think could be the beginnings of a UX strategy for GNOME. In this, the second post, I’m going to describe a potential GNOME UX strategy in high-level terms. These goals are a response to the research and analysis that was described in the previous post and, it is hoped, point the way forward for how GNOME can achieve new success in the desktop market.
Strategic goals
For me, the main goals of a GNOME UX strategy could be:
1. Deliver quality
If GNOME is going to succeed in today’s desktop market, UX quality has to be job #1.
UX quality includes what the software looks like and how it is designed, but it also refers to how the software functions. Performance and bugs (or the lack of them) are both aspects of UX!
More than anything else, people are looking for a desktop that Just Works: they want a solution that allows them to get their work done without getting in their way. This means having a desktop that is reliable, stable, which does what people want, and which is easy to use.
People value solutions that Just Work. They’re also prepared to abandon them when they don’t Just Work.
To its credit, the GNOME project has historically recognised the importance of Just Works, and it has delivered huge improvements in this area. However, there is still a lot of work to be done.
My sense is that driving up quality is one of the key strategic challenges that the GNOME project needs to face up to; I’ll be returning to this topic!
2. Factor in the cloud
In my previous post, I worte about how the cloud has reconfigured the landscape in which GNOME operates. Accordingly, it’s important for our UX strategy to account for the cloud. There are various ways we can do this:
- Focus on those bits of the desktop that are used by all users, even if they mainly use a web browser. This includes all the parts of the core system, as well as the most essential desktop apps.
- Enable and encourage native cloud applications (including Electron and Progressive Web Apps)
- Add value with high-quality native apps.
- Integrate with existing cloud services, when it is safe to do so.
The last point might seem counter-intuitive, but it makes sense: in a world where the web is dominant, a fantastic set of native apps can be a powerful differentiator.
At the same time, GNOME needs to be careful when it comes to directly competing with sophisticated web apps and services, and it needs to recognise that, nowadays, many apps aren’t worth doing if they don’t have a cloud/cross-device component.
3. Grow the app ecosystem
The primary purpose of a platform like GNOME is to run apps, so it stands to reason that the number and quality of the apps that are available for the platform is of critical importance.
Recently, Flatpak has allowed the GNOME project to make great progress around application distribution, and this is already positively impacting app availability for GNOME. However, there is a lot of work still to be done, particularly around GNOME’s application development platform. This includes work for both designers and developers.
4. Support modern hardware
One of the things that my research revealed is that, for most users, their choice of desktop OS is thoroughly entwined with hardware purchasing choices, with hardware and software typically being seen as part of the same package. Attracting users to GNOME therefore requires that GNOME be available for, work well with, and be associated with high-quality hardware.
A lot of hardware enablement work is done by distros, but a lot also happens in GNOME, including things like high-definition display support, touchscreen support, screen casting, and more. This is important work!
Do less, prioritise
Any UX strategy should address the question of prioritisation: it ought to be able to determine how resources can be directed in order to have maximum impact. This is particularly important for the GNOME project, because its resources are limited: the core community is fairly small, and there’s a lot of code to maintain.
The idea of prioritisation has therefore both influenced the goals I’ve set out above, as well as how I’ve been trying to put them into practice.
When thinking about prioritisation in the context of GNOME UX, there are various principles that we can follow, including:
- User exposure, both in terms of the proportion of people that use a feature, and also the frequency with which they use it. Improvements to features that everyone uses all the time have a bigger impact than improvements to features that are only used occasionally by a subset of the user base.
- User needs and desires: features that are viewed as being highly attractive by a lot of people are more impactful than those which are only interesting to a small subset.
- Common underpinnings: we can prioritise by focusing on common subsystems and technical components. The key example here is something like GTK, where improvements can surface themselves in all the apps that use the toolkit.
When we decide which design and development initiatives we want to focus on (either by working on them ourselves, or advertising them to potential contributors), principles like these, along with the high-level goals that I’ve described above, can be very helpful.
I also believe that, in some cases, the GNOME project needs to have some hard conversations, and think about giving up some of its existing software. If quality is job #1, one obvious answer is to reduce the amount of software we care about, in order to increase the overall quality of everything else. This is particularly relevant for those parts of our software that don’t have great quality today.
Of course, these kinds of conversations need to be handled delicately. Resources aren’t fungible in an upstream project like GNOME, and contributors can and should be free to work on what they want.
What’s next
In my previous post, I described the research and analysis that serves as inputs to the strategy I’m setting out. In this post I’ve translated that background into a high-level plan: four strategic goals, and an overarching principle of prioritisation.
In the next post, I’m going to introduce a raft of design work which I think fits into the strategy that I’ve started to lay out. GNOME is lucky to have a great design team at the moment, which has been pumping out high-quality design work over the past year, so this is a great opportunity to showcase what we’ve been doing, but what I want to do is also show how it fits into context.
Can’t wait to see the design work / mock-ups!!
What does it mean for GNOME to succeed on the desktop?
Hey Kev, the fairly crude measure that I’m using for this exercise is: expand the number of users, and increase the satisfaction of our existing users.
Clearly there is more to success than this, but I think that it is sufficient to get started.
Thanks for writing this up, Allan!
The “Do less, prioritise” idea really resonates with me. The problem however is that in practice, a lot of the most “exposed” pieces of the desktop (things like GTK, GNOME Shell, Nautilus etc.) are hard to hack on, especially for newcomers, and not very sexy.
I’d be interested in exploring ways to make working on this core infrastructure both easier (via tooling, documentation, etc.) and more attractive for contributors (by making it more visible maybe?).
Simply put, I think the question is how can we make fixing the printing dialog as easy/fun/exciting as making a new app?
Totally. It’s bad that the most critical technologies often tend to be the least approachable. GNOME needs new blood, and I fear that we’re not going to get it in these key areas, if we don’t do something to make them easier to hack on.
I suspect that different technologies require different solutions and approaches. Switching to high-level languages will help in some cases. Simply cleaning up the code base will help in others. Splitting up libraries and components might also help (like having separate libraries of GTK widgets or even – *gosh* – splitting up the shell).
With the shell, the big challenge is setting up a development environment; I’m not sure what the answer is there… we can do better with the existing tooling, but it’s never going to be a fantastic experience.
“Enable and encourage native cloud applications (including Electron and Progressive Web Apps)”
I’m afraid of that one… What do you mean more specifically? What would be the benefit of that over an app written traditionally in C for exemple?
I have always got bad experiences (performance mostly) with apps based on Electron, eg: VSCode…
Whether you have issues with Electron or not, there are a huge number of high quality Electron apps out there right now (see this directory). So, when it comes to increasing the number of high quality apps that are available for GNOME, this is an obvious opportunity. Even more so, when you consider that people are still prevented from migrating to GNOME because we are missing quality apps in particular areas.
Progressive Web Apps are a bit different from Electron, but the signs are that they are going to become the standard offering for many vendors. So again, there’s an opportunity to get the same high quality apps available for GNOME as are available on other platforms.
Attracting Electron apps is probably mostly a matter of evangelism, documentation and tooling. For PWAs, we’d need to look into building support into the platform, particularly by leveraging WebKitGTK.
Hi Allan, thanks for your reply.
Since the point of this post is all about “what user want”, including performance, I believe my point is legitimate and shouldn’t be disregarded? Especially that it’s not just my point but a fact that Electron apps are really slow, we feel it when we use them… I mean we can find related posts all over the web…
I don’t see any problem with supporting PWA, this is a very different need.
Thanks for your time.
“What would be the benefit of that over an app written traditionally in C for exemple?”
To me that seems like a pretty unrealistic comparison. Often the alternative to an Electron app won’t be a native Gnome app written in C. It will be nothing at all, at least nothing that runs on Linux.
Hi alex, thanks for your input.
“To me that seems like a pretty unrealistic comparison. Often the alternative to an Electron app won’t be a native Gnome app written in C. It will be nothing at all, at least nothing that runs on Linux.”
I see, but if we suppose that encouraging Electron lead to “increase the number of high quality apps that are available for GNOME”, couldn’t we assume the possibility that a bunch (if not most) of Gnome apps would be based on Electron then de facto replace traditional desktop apps?
I’m not desktop app developer, hence I just seek for information and clarification without any other judgement than my user’s point being that Electron apps are slow. I mean it’s not only me who experience that, eg: https://medium.com/commitlog/electron-is-cancer-b066108e6c32
The biggest UI problem in my view is the inconsistency and fragmentation, which is getting worse and worse. Back in the Unity days, you had all toolkits looking nearly identical on Unity. Today, you have “modern” Gnome apps, traditional GTK apps, QT apps, Kirigami, Elementary, Electron, Java etc. There is no common theme or UI language and the main cause for that is the widening fracture between QT and GTK. And with Gnome wayland you won’t even get consistent window decorations, which makes the inconsistency “in you face”.
You install vanilla Gnome and out of the box you have a few clean, consistent apps. So far so good, but when you install the programs you actually need to use, all of the “Gnome design” goes right out of the window, because none of these apps are built with this design in mind, not even GTK apps like Gimp. And most apps simply cannot be built “for Gnome” because their developers can’t recreate Gnome CSD or replace their menu bars with hamburgers. So *in real world use*, there is no “Gnome UI”.
Gnome alone can’t create an ecosystem of applications with good UI. Neither can Elementary. Unless a solution is found that will allow QT, Electron and Java developers to create native-looking applications for Gnome (and allow Gnome developers to create native-looking applications for KDE), the UI will continue to suck and the app ecosystem will suffer because because people are going to recreate the same type of app in multiple toolkits instead of just making one good one.
Mac OS set out to solve the consistency problem from the get go, that’s why people like their UI. The Mac user doesn’t need to worry about which toolkit the app is using, they all look good. There are no square edges on Firefox’s CSD, no weird-looking QT apps on Mac. If you want a good UI on Linux, you’d have to do the same thing. Better late than never.
Actually macOS succeeded by allowing third-parties to deviate from their HIG. Office for mac looks like a port of the Windows version and not a specially tailored app. Same goes for all the monstrosities from Adobe, Avid etc.
> User needs and desires: features that are viewed as being highly attractive by a lot of people
Global/locally-integrated menu, HUD and consistent decorations are viewed as being attractive by many users, probably a majority. They save space and improve consistency by centralizing menu bars and window decorations.
Some very good observations here. I think in some ways Gnome has been very forward-looking, and in some ways, overreaching. The Gnome community understood from early on that “options have a cost”, but with Gnome Shell, it became obvious also that “paradigm shifts have a cost”, if you will. From the outside it looks like the Gnome community admires the Apple culture of top-down, opinionated, perfectionist, and occasionally revolutionary design, but unfortunately doesn’t have the resources to really pull it off. Canonical with Unity were better resourced, and were arguably closer to making it work, but eventually gave up. Maybe the Apple way is just culturally a poor match to communities consisting largely of volunteers?
The Apple way is also related to the question of brand identity. When you use a Mac, you can’t really not notice you’re using a Mac. It seems many voices in the Gnome community would like Gnome to have a similarly unmistakable brand identity. I think attempting this on the level of the desktop shell and core apps can be a mistake, if you’re not following through with the kind of resources and vertical integration that Apple have (hardware, OS, 3rd party app ecosystem, retail stores, support). It may certainly feel like a thankless job making a desktop shell with great effort only to have some vendor to change something, stamp their logo on top and call it their own operating system. But I think those vendors are actually in a much better position to deliver a Apple-equivalent UX with distinct brand identity than Gnome Foundation is. If the vendors are smart, they will support Gnome and if the Gnome community are smart, they will support the vendors.