The author presents valid and sensible issues with the state of theming on the GNOME platform. And the overarching topic is essentially User Experience.
Even the slightest change in color can introduce friction between UI elements. Or to be more extreme, if a theme turns your entire app into a white blurry mess, you would get mad at the application, and not the theme. Although many of the same design principles are used in the making of either a chair or a graphical user interface, they are definitely not the same in any regard.
On the topic of icons: just like language, they evolve over time. On top of that, icons can have different meaning depending on your background. Icons can be combined to form a composite icon, and now imagine one of those icons is not displayed as you intended it to be. The entire meaning can change because the design intentions are lost.
On the topic of branding: it's not about your desktop being a billboard. It's about being able to recognize the brand across different operating systems, and it's also - more or less - the only thing about the product that is not designed for the purpose of user experience (but in a sense, they still are). And let's be honest: most apps we use in our day to day life have very tame brands and adhere to certain standards. That is because the apps we use are usually good, and we throw the bad, obnoxious ones away really quickly.
All in all, the author presents valid concerns, especially if you don't project them on how you prefer your UI, but rather, how potential Linux / GNOME users could have additional difficulties because of theming issues.
Imagine if Apple asked users not to apply stickers to their laptop as it denies Apple the possibility to control their brand, or could make the laptop look broken, even unusable - shock I may even apply a sticker that shows a broken circuit board or simulates cracked aluminium. Apple's view is that applying a sticker to the case or keyboard render Appley documentation useless as they don't look like the pictures we screenshotted in moments.
> Even the slightest change in color can introduce friction between UI elements
Yeah, and? They might be the difference between unusable discomfort and usable, or allow ageing eyes to cope with arrogant and restricted developer choices, or missing sense of aesthetic. You might not like the colour car I buy or the decorating scheme I choose for my house. Mind your own damn business.
> On the topic of branding
Yeah, about that. It's branding that has led computer and phone makers to give highly limited theming capability. Firefox or my desktop is no longer my own to adjust and fiddle to unusability (sic) or perfection - as I see fit. Like the paint I use inside my house, mind your own damn business. I might LIKE my phone, Windows box and Linux box to all look highly distinct from each other for my own personal reasons. Mind your own damn business.
It is not another surface on which to stimulate my neurons to be further programmed by the brand. Baa.
Edit: Specifically on icons, I have been changing icons since the days of Workbench 1.3 in about 1986 or 87. I won't stop now. I've chosen wildly different icons for some apps at times - because they worked better for me. Icons as space for a logo is an entirely negative fashion to my mind as I prefer a hint, however vague, of what that a rarely used app does.
"However, if you change things like stylesheets and icons, you should be aware that you’re in unsupported territory."
Unsupported territory, for changing a desktop icon, or adding a higher or lower contrast stylesheet? Wow. That's pompous and absurd for me. Doesn't sound like it's explicitly made a reasonable exception though, just piles on a layer of entitlement for a damn brand.
Read the banner at the top of the page again. It doesn’t ask users to stop customizing, and it doesn’t say there shouldn’t be distros with custom theming. It just asks distros to stop shipping broken apps as a result of theming, and it asserts that if that’s the route you want to go, then you are on your own.
Reading carefully between the lines, I think they actually do hint at that:
> Please don’t theme our apps
> This is why we ask respectfully that our applications not be themed.
> On a platform level, we believe GTK should stop forcing a single stylesheet on all apps by default.
> If you are a distribution who changes the system stylesheet and icons, please reconsider this decision.
> If you do, we ask that you please stop theming our apps.
"If you like to tinker with your own system, that’s fine with us. However, if you change things like stylesheets and icons, you should be aware that you’re in unsupported territory. Any issues you encounter should be reported to the theme developer, not the app developer."
> Please read the letter all the way to the end. This is aimed at distributions breaking apps by default, not tinkerers playing with their own setup.
I did thanks.
"If you like to tinker with your own system, that’s fine with us ... However, if you change things like stylesheets and icons, you should be aware that you’re in unsupported territory."
Unsupported territory for choosing a distro that looks unusual, or applies theming, or for changing my own damn desktop icon?
Which is then thoroughly buried by a point of view that feels the app is the only arbiter, and tries to justify that on consistency of brand, icons not representing what the developer wishes etc, and that even individual user customisation is a big favour - an unsupported edge case.
What of the users?
It's reasonable to expect an app to both allow, and to work correctly with any theming built into the platform or distro. Bugs may be on either side. I concede it's mainly the major platforms that have done most to take away choices here, so you can no longer download new iconsets - to transform everything into ST:TNG or whatever. Where a distro seeks to theme everything it's the one app that won't, for brand experience, or developer wishes - that now sticks out like a sore thumb.
That is to be regretted, as much as platforms removing ability to build a custom night mode or extreme low contrast theme, or even add some slight 3d back to Windows. It's the end user who loses out to a worse experience or usability each and every time.
Changing the UI changes the software from the user perspective.
Actually, it's dismissive of the app developers' egocentrism. In so far as theming breaks usability, they do have a point. Distributions shouldn't make potentially incompatible changes to the default theme without QA. But it's not all the fault of distributions and not respecting branding is not a UX problem.
Yes, I may be too harsh towards people voluntarily writing free software. Developers putting their branding and their "vision" before usability and user control is just a major pet peeve of mine. And diplomacy is not my strong point.
> Even the slightest change in color can introduce friction between UI elements. Or to be more extreme, if a theme turns your entire app into a white blurry mess, you would get mad at the application, and not the theme.
Actually I would blame the theme, but yeah, the average user would. Wrongly assigned blame is a broader issue with free software and the distribution system though.
> On the topic of icons: just like language, they evolve over time.
The XDG Icon Naming Specification does not actually specify the names of concrete icons, but of meanings. For example, there is no "looking-glass" icon, but there is a "system-search" icon. If you use the "system-search" icon to display a looking glass because that's the metaphor the icon theme you're testing with uses, your application may display the wrong icon with a different icon theme.
If an application needs an icon that is not standardized, it can include it similarly to its own application icon.
> It's about being able to recognize the brand across different operating systems
No, it's about the user recognizing the application. Which they can. The Firefox icon the open letter used as an example is very much the Firefox icon, just in a different style.
> it's also [...] not designed for the purpose of user experience (but in a sense, they still are)
Exactly. User experience >>> branding.
As someone who struggles with this too: The world doesn't care that you own it and admit it; they only care if you fix it, or at least work around it for them.
The Firefox/Thunderbird example is absolutely ridiculous - it's not up to these application developers to decide what icon or colour the user sees. It's up to them to provide defaults. As you say, it's clearly still Firefox - but even if it weren't, there are several good reasons I can think of that a distribution might want to change it.
What bugs me is the attitude that the solution is to reduce the usage of themes, as opposed to improve the theme engines and app dev toolkits. Why shouldn't the OS be able to impose a global stylesheet for colours, images used for semantic icons, sizes of common elements? If I, as a user, want to starting fiddling with my system theme, is it not likely that I might want all the apps on the system to play ball? Sounds pretty jarring to me to have one or two apps with their stubborn hardcoded "branding". (Oh wait, that's what we already have with Electron apps that don't respect the OS theme or conventions, and they suck!).
Oh, apps can't be restyled without manual work they say. "Until this perception changes..." they say. NO!
In an ideal world, applications could be built easily in such a way that allowed them to be themed without causing major UI bugs. The fact that this is such a large issue with GTK apps is surely further evidence that GTK has a bit of a problem - especially considering that other UI platforms are able to do a better job.
Perhaps - and I'm really pushing it here (/s) - solving the root causes of issues arising from custom themes relating to sizing and spacing might actually have other benefits as well. Like better support for UI scaling. Maybe the scope of themes needs to be reduced a little so it's easier for application developers to support?
For many websites, web fonts have been an improvement, especially considering the sorry state of "web-safe" fonts back in the day.
1. http://www.hsluv.org/examples/ These palettes will absolutely NEVER clash. But they might have contrast issues. Which brings us to:
2. https://news.ycombinator.com/item?id=19800718 Lyft primarily designed ColorBox.io to always reach WCAG 2.0 contrast ratios. Something I'd claim a ton of UX themes mess up. Unfortunately from what I can tell, it lacks the anti-clash guarantees of #1
3. Much less related, but still important, albeit only for very specific parts of any UX:
The color map generation approach in Matplotlib: https://www.youtube.com/watch?v=xAoljeRJ3lU (btw.: Seaborn, as mentioned in #1, builds on top of Matplotlib.)
For even more color madness, see this recent Hacker News comment by me as well as the other comments linked to there:
But, unfortunately, it too only serves as a partial solution (since, as far as I know—someone please correct me if I got that wrong—it doesn't address any of the matters discussed above), PLUS it seems highly likely that Adobe has software patents on it.
No two displays that I own produce the same colours. It depends on the hardware, the brightness, the daytime colour cycling I have, and so on.
I feel like if slight changes to colour can wreck your app then your app leans too heavily on colour reproduction.
Which is User experience and not Developer experience. As a developer I can agree with them but as a user I couldn't care less about their brand. Sorry if I sound rude. It's not as if they are paying me to keep their brand consistent among desktops.
I theme a little my desktop because I like the general idea of the GNOME desktop but I don't like many of their graphical choices. Colors, scrollbars, margins are all wrong IMHO.
I'm sorry that those developers are suffering and I know that somebody is thinking about reducing the ability to theme GNOME, but I'll keep doing it as long as I can and if I screw something (my emacs scrollbars) it's on me.
Then more crucial aspects of ability - such as eyesight being a major one. Some people can't see some colours that well, some need larger fonts. Things like that in which theme's are the saviour and for many a developer - how they cater for disability usage.
Sure some theme's can break the UI, but to blame the user, which is the case here - now that's egocentric IMHO.
As for branding - how many users care about that?
End users can make that choice with regard to the extremely limited set of applications and use-cases that matter to them. A distribution has a far wider landscape to consider.
If you consider something that does not work reliably to work, you're right. I don't.
A distribution has to consider more applications and use cases, but it also has more resources. Doing things at the distribution level is much more efficient than each user doing their own thing, that's why they exist.
You’d expect (hope) core applications would be tested but what about stuff that’s not in the official repos? Or stuff that is but had a new feature unbeknown to the distro maintainers?
On HN last week there was a GUI bug in a core OSX utility being discussed that slipped through Apples testing. If they managed to overlook something in their own OS, then a smaller team of people, likely working for free in their spare time (remember a lot of the distros that ship non-standard themes as a default are spin offs) is unlikely to test every GUI form and dialog that can be rendered o. Linux.
What it actually does is list a number of reasons why distro themes are bad (in their opinion). Some of those reasons amarettos equally true for end users theming and some of those reasons are not. The letter also does say that end users are welcome to theme themselves but they should do so under the knowledge that there be (potential) dragons.
What it doesn’t say is that theming “doesn’t work”
Personally speaking, I’m on the fence about whether I agree that distro theming is bad. However I do think their points are perfectly valid and that a considerable number of HN commentators have taken the letter completely out of context.
Edit: and I’m also a little peeved that there is so much knee jerk down voting of comments on here. Particularly when those comments are quite literally correct. It’s a really pity you guys couldn’t be bothered to read the letter before abusing your right to moderate.
Theming literally can break the UI in unexpected ways, however if often doesn’t. But if one manages the theme themselves then they are able to manage those edge cases themselves. If a distro does it then they can’t guarantee the end users are even aware that the unexpected UI is the fault of the distro.
That point was clearly laid out in the letter too. If people had bothered to read it.
What's dismissive is this word "dismissive". Sometimes, a comment really is just a random low-effort personal swipe that don't engage with the substance of the subject. The GP did not write one of those comments. Instead, wrote a valid and substantive critique of the article, and you don't get to score rhetorical points by smearing that work with vague labels like "dismissive".
The consistent theme across apps is more important than the developer's brand. Suggestions for a theme is useful, essentially ordering others how to use their app and theme should be outright dismissed.
I've had this comment on my mind for about an hour now, and it strikes me as both correct and yet the behaviour you identify is inoffensive to me in this context.
In particular, I don't disagree with users behaving in an egocentric manner regarding their desktop environment, the software they choose, and the way their hardware operates. That's an intimate and personal space where many spend most of their waking hours; they ought to feel empowered to control and operate it as they wish.
And if that's the case, it may be warranted to have a dismissive attitude towards those who would undermine that power.
Two things to consider:
- Distributions are users
- Users may choose a distribution that suits their desired aesthetic
Not everyone who wants a custom desktop aesthetic is technically adept enough to undertake the customization themselves, or perhaps they simply don't want to expend the effort. That's where distributions come in to assist.
> Good. My computer is not your billboard.
Yes, seriously. If a user runs a free software desktop, chances are the ability to change things according to their wishes is part of why they use it.
> Changing third-party apps without any QA is reckless, and would be unacceptable on any other platform.
Which is why I use a platform that does grant me that freedom as a user.
I’m not against open software or user customization, but this approach does not result in quality software. Distros should be working with application developers and not against them. Here you have a large group of Linux app developers undersigning a plea to stop breaking their software and all they get is scorn and dismissal.
More Elementary, less winamp-skin-distros.
Their letter is titled "Please don't theme our apps", not "Please don't break our apps".
Hell there’s even a paragraph aim directly at end users.
> If you like to tinker with your own system, that’s fine with us.
You’ve completely dismissed all of their concerns out of hand, in an entirely unhelpful and hostile manner.
Why did you even bother writing a comment?
But I do take issue with attacking developers who write applications for free, and contribute to the Linux ecosystem, for making a reasonable request to platform developers.
It is unreasonable to expect each end user to build their own custom themes, it makes far more sense for distros to do the work once.
> If you like to tinker with your own system, that’s fine with us. However, if you change things like stylesheets and icons, you should be aware that you’re in unsupported territory. Any issues you encounter should be reported to the theme developer, not the app developer.
Just not with the same vehemence as its message directed at distros.
This all seems like a huge issue made about nothing on consequence
If the letter was aimed at end users, that qualifier would have been redundant. Therefore the letter is not aimed at end users.
I understand that the devs do not want to be responsible for bugs stemming from broken themes, but this is the wrong solution. Ultimately the solution is a better theme API, not this which would essentially stop custom themes all together for most end users.
In other comments people argue that this isn't aimed at end users, but end users would of course also be impacted from this.
I don't see a good technical solution here, but I see two social ones: a) developers of FLOSS must understand they're writing software that can and will be modified and re-released by others, sometimes individuals and sometimes organized groups (like people making Linux distributions); and b) users need to understand that if they have a problem with their software, they should reach out to people from whom they got that software for support. If you got a program from developer's home page, you should contact them directly. If you got it from your distro, then distro maintainers should be your first line of support.
(Also c), some users won't understand b), and forwarding support requests to appropriate people is just part of publishing FLOSS.)
If themes are so important to you, pick your app based on that criteria. If you think an app is garbage because it doesn’t theme well, fork it and write a better version yourself.
That is an unfair inference because the author of the post explicitly says otherwise. To the extent he is speaking to you, he is only saying "thar be dragons" and that he will not explicitly support your use of a theme—therefore you should file any theme-induced bugs with the theme author and not with him.
How is releasing software under a license and asking people not do things allowed by that license reasonable?
If GTK3 still does not support theming, that explains why theming causes issues. In which case it would be better to implement proper theming support because stopping distributions from theming clearly doesn't work.
Oh yes, people have always done it, via one hack or another, and as long as it was more of a "for people who really want to fiddle" it wasn't that much of an issue.
But now expectations have risen, people expect more solid behaviour and look/feel from their apps, and distros routinely have quite different GTK themes.
Good question. Why did I write things like the following if you don't read it anyway?
> One way for the user to express their choice is to choose a distribution whose theme they like.
There does seem to be a weird user-hostile school of GUI design and I would really like to know where it comes from, so that we may try to mount a re-education effort.
Edit: And if you really need your app to not be themed, just force Adwaita on startup. This doesn't seem like it should need a complete upheaval in how we use GUIs.
The Web. It comes from the Web.
Web development has this bullshit school of UI/UX design that prioritizes branding, dark patterns, and treating users like toddlers, at the expense of making the software functional and usable. Since we all get industry news from the Web, the Web patterns are the most well-known, and they pollute desktop software development too (doubly so when desktop software is nowadays built as webpages bundled to a browser runtime).
It's not that the Web school of UX is completely wrong; the problem is that it mixes ergonomics with a whole range of tricks designed to make the software more popular and more sellable in spite of the utility reduction they cause, and then sells the whole bundle as "scientifically validated" and "data driven".
But not if they don't even try.
Themes are imposing a real cost on developers who let's be honest are doing the Linux platform a massive favour by even bothering to write apps for it. I hope the audience of that article are a little more sympathetic than yourself.
>If it's a bug in the theme, the application developer is just not responsible for it.
And how many times would they have to tell the end user who opened an issue on their app's tracker that?
I'm afraid there is no way around that issue with free software.
There's a super clever life hack my wife used when working in e-commerce. She kept a text file with prepared replies to most common issues and questions, and used the OS's built-in copy-paste functionality to quickly responding to messages asking about the same thing. I hear this kind of functionality is even supported directly in desktop e-mail clients these days.
The users always blame the app. And then when they can't get the app to work they stop using it.
Which means the developer just lost a potential customer.
If you don't like people modifying your software, don't publish it under permissive license.
How do you solve the social problem of a large majority who feel entitled to everything for free?
My solution was to give up, publish free stuff anonymously with zero support, and charge for anything I actually care about. My charged-for software has multiple orders of magnitude more users than the free software, and effectively funds the free software that nobody actually uses.
I regularly think about not publishing the free stuff anymore, but I figure that even if a single person benefits from it, it's a net-positive, and so I keep going. It doesn't stop it being incredibly demoralising.
You can have it on a website where users can talk to other users. And if you like, you can chime in. Say some code sharing platform. My experience is that people will help each other out usefully. You can even nudge them in this direction.
> How do you solve the social problem of a large majority who feel entitled to everything for free?
You don't. Why would you? You don't need to react to what you judge being an entitlement. You can misjudge though.
I've had reactions when contributing bug reports that I felt other person thought of me as being entitled, after I've spent considerable time identifying the root issue and suggesting a code change.
I've also thought of someone being entitled initially, when in the end the person ended up contributing useful service to other users of my program.
“It's possible to do X wrong” is insufficient to support “You should not do X”.
completely agree with this point.
It's also not the distro's billboard, but you seem happy for them to impose their branding upon your desktop, even if they break functionality.
Bugs are bad, yes.
> Icon Themes can change icon metaphors, leading to interfaces with icons that don’t express what the developer intended.
That is not a problem if you use icons for the purpose they are intended for.
> Changing an app’s icon denies the developer the possibility to control their brand.
Good. My computer is not your billboard. Consistency is more important than your "brand".
> Appstream Screenshots (the screenshots used in GNOME Software or Flathub) are not very useful if they look nothing like the real app does once you install it.
> User Help and Documentation are similarly useless if UI elements on your system are different from the ones described in the documentation.
Nonsense. Theming doesn't affect the layout of a program. If people were that bad at abstraction, then how do they recognize they can sit on a metal chair if they are familiar with wooden ones?
> They are built and tested for the upstream GNOME stylesheet, icons, and fonts, so that’s what they should look like on peoples’ systems.
No. They should look like the user chooses them to look. One way for the user to express their choice is to choose a distribution whose theme they like.
> Changing third-party apps without any QA is reckless, and would be unacceptable on any other platform.
∀x. x without any QA is reckless.