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.
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.
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.
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:
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?
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.
> 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.
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?
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".
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.
“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.
1) use offset colours, like specifying to move 10% in Hue off the theme colour.
2) specify all foreground + background colours and admit that this is special and won't conform to any user or distro theming
Instead, they go around saying that there is only one GTK theme and then leave a convenient backdoor open for hacks with a nudge and a wink. Either open the front door and roll out a carpet or close all the doors and windows.
How do you think GTK+3 handles theming (or lacks handling for it)? It sounds like you're confusing GTK+3 theming for GTK+2 theming (which was based on "engines", which were quite a mess). Now it's very "proper and defined", it's accomplished with a strict subset of CSS which has fairly consistent behaviour.
I personally don't see the point in elaborate theming systems (I'd prefer to just have control over the colours, and maybe one or two of the spacing variables), and it is obvious that they cost a lot of cycles at run time....
but GTK+3's theming system is not braindead, it's just ambitious.
Consistency and overriding bad decisions.
(I don't have a horse in the Electron-is-great-or-crap race)
That's a hard problem to solve, since there are many ways of styling Electron - Bootstrap/Bulma/Material Design/custom stuff. So it's hard to just override CSS rules.
On the other hand, it's the kind of problem perfectly suited for Machine Learning - just take the whole screenshot/image of the app and use a stylistic ML to change it - make it Dark Theme/whatever...
I suspect in 10 years OSes will support ML-based automatic themeing/customization of all apps, regardless of what they are written in.
GTK stylesheets - mostly a problem of different GTK versions they're made for, because GTK versioning is a mess.
App Icons - so what? I think most people like consistency - look at Windows 10 and its ~4years of development, it's still a mess and if I had an option I'd switch right away
All in all I think the choice should be left on the user after distro install, use default gnome look by default and have an option to switch to another with a warning. I agree that devs shouldn't have to deal with someones custom stylesheet issues.
Why? There is already a standard. It does not specify what icons look like, but what they mean. Replacing an icon with another that has the same meaning is not a problem. Of course, if you, say, abuse the "system-search" icon to show a looking glass, this will not work with a theme using a different metaphor.
The icon theme displayed in the open letter is just garbage. Using it as an an example is like saying distributions should not change the default font because they might choose Wingdings.
A lot of icon themes are pure garbage, or at least incomplete. I don't think the example chosen here is any worse than what I've seen on my own system. Honestly, most icon themes are a failure; visual metaphors are just plain hard, and there's no substitute for literacy.
For example, what happens when there's system searching element that needs to be in visual proximity to a magnification, zooming or loupe-inspection element? It's impossible to know if an icon theme is going to maintain consistency and/or disambiguity with the default theme.
The situation is even more tricky as what is being modified is not even the software itself but the system dependencies. Essentially the developers in this letter say: do not run our software on an environment that is not the one we support (in practice fedora or a close clone of it) and if you create a distro make sure its a clone of what we support.
I understand the fact that developers do not want to support bugs due to user modifications and strange environments. Free software doesn't imply free support so they can put any restriction on what they want to do. The letter however would have been much less weird if it said "we cannot ensure quality of software X except on our build running on a supported environment, if you run the software elsewhere or with changes (and theming is a change) please don't call it X to avoid confusion and remember you are on your own".
What Firefox did I think its a smart solution to this problem. " We offer Firefox on platform x,y,z. If you build it on something else, call it something else, if you run it on another platform remember you're on your own".
There currently is a growing conflict between upstream developers and distributions, because some of their interactions and dependencies bare badly managed.
For example, upstream maintainers see an influx of bug reports and angry users due to bugs, where the distributions are at fault. Sources for this can be changes to the code that the distributions make for various reasons like backwards compatibility, themes that break user interfaces or simply outdated packages or missing backports.
The GNOME upstream maintainers all are having their ass hanging out on a public gitlab repo, while some of the distributors, who break stuff, are very hard to find, with sometimes ancient bugtrackers.
I trust that the community will find a way to update their relationships and solve these issues, but it starts with seeing what's going wrong and where we have bad incentive structures.
Distros are agents of their users. A user can't make each choice involved in assembling a distro themselves (except for the few who use LFS), so they express their choices by choosing a distro.
How many do so, anyway? I know Ubuntu has the Yaru[2] theme by default.
I'll add that I personally find the stock Adwaita theme to be total garbage. I've been using the Vimix dark themes[3] for as long as I can remember because they don't make the title bar of windows 30 storeys tall and they don't use beige.
1. https://github.com/do-not-theme/do-not-theme.github.io/commi...
I mean, it doesn't really matter if it's garbage or not; it matters that it's what GNOME app developers are testing their UX against, so if you create a theme that changes the metrics drastically from the ones in Adwaita, your theme is going to break those apps.
You can probably get away with tweaks on color, squashing some elements narrower, whatever, but that's not what the post is really talking about. Things that could be called "variations on Adwaita", or "Adwaita if it had a fancy control panel with metrics sliders and color pickers", aren't gonna break anyone's apps.
They're talking about themes that e.g. change fonts on control labels to ones that don't have the same em-widths or x-heights for some characters, and so things stop lining up flush; or which replacing the icons with an icon set that isn't just "the same icon designs but now in monochrome/superflat/etc." but now has new designs, different to the same degree that the iOS vs. Android emoji themes are different, such that your gun becomes a water gun (or your homedir becomes a hand throwing devil-horns.)
Although I dislike it when people significantly change UI controls.
This article is antithetical to the whole cultural foundation that GNOME builds on, without which there would probably not be an open source desktop ecosystem to build apps for.
I strongly urge the authors to take in the arguments of the top comments and reevaluate their positions.
And you know what? The more you enable and facilitate customization, the better and richer will the options provided by the community be. I can see how the argument makes sense for particular distributions like Elementary OS and maybe Linux Mint that are aiming at a unified experience for novice users. I really hope other distro maintainers don't pay attention.
This is what I take issue with as a user. A major reason why I prefer GTK is exactly because I can get a homogenous look without having to tweak every single app individually. There are definitely issues with the way this is handled (and I'm TBH still confused about squaring Qt and GTK styles), but let's not throw out the baby with the bathwater.
I think that if we're going to have toolkits that support custom, nested widgets, those widgets need to be designed to support the context they are in. There will always arise situations where normally-light widgets need to appear on a dark background, or vice versa. The nested path bar example is exactly this - it's a widget that supports a single context (light background), but is having two contexts forced on it by leaky style cascades (light text, but also light background).
How about we bake the concept of "light" and "dark" into the widgets themselves and take advantage of the cascading nature to switch the theme of a widget depending on the context it is in.
Realistically though, GNOME 3 was rather short-sighted when it came to themes. Windows 95 showed us the way 24 years ago: you can change the colours of anything you want. You can tweak the size of most things. You can change the fonts. You can change the icons. Simple API that gets applied on top of an existing theme. Expand this for 2019 with dark and light variants for each theme, and I bet we'd satisfy almost all users.
Another thing Havoc Pennington liked to talk about in developing GNOME 2 was 'crack'. These were things in GNOME 1 that were bad for the community, but that a lot of users were addicted to. Like, for instance, an overabundance of user settings.
By all accounts, it's hard to write a GUI app for the Linux desktop, in part because of the huge variety of distros and desktops, and apparently even themes within a single desktop. And as a user, my biggest complaint about desktop Linux is the relative paucity of high-quality applications. (Yes, I know there are many high-quality desktop Linux applications. But there aren't as many as on Windows or MacOS.) I can't help but wonder if most of the community wouldn't be better off if a single distro, hopefully with a single desktop and a single theme, decisively 'won' and claimed a dominant usage share of the Linux desktop. Then third-party developers would be incentivized to just develop for that distro, which might make the lives of both users and developers better in the long run.
And of course, since it's open source, if 'the one true distro' went off the rails eventually, someone else could fork it and become the new 'one true distro', with relatively little danger of vendor lock-in.
https://blogs.gnome.org/tbernard/2018/10/15/restyling-apps-a...
That blog post was linked to from here:
https://github.com/do-not-theme/do-not-theme.github.io/issue...
I also agree that if you make an app screenshot/tutorial it is better to use the default theme unless you are targeting users for specific distro.
However I see some flaws in Adwaita (the default GTK theme) and a lot other themes regarding the titlebars:
1. They are too tall for no obvious reason.
2. the most irritating thing is that it is very hard to tell the active window. I mean it is a bit lighter but that's all.
> 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.
Which is a sentiment I can get behind. Telling distributors that they need to make it clear the styling might break things is not wholly unreasonable.
I'll stop themeing apps and their icons once I don't see a single piece of software that has an UI and an icon look like as it were made in the 90s, also implement dark theme. Providing a more consistent UI for new users on a distro is also better idea than leaving it up for the developers.
The GNOME back button being wrongly themed is solved by switching GNOME to dark mode (`gnome-tweak-tool`) and a dark theme. The engine isn't the best but devs don't make it easy either.
The issue's primarily addressing distros and projects that ship their own GTK themes as default to users, like Ubuntu and Elementary and System76. My wife's desktop runs Ubuntu, and if something doesn't look right, she doesn't even know she's running something called GNOME - she just knows that the problem is with software (OS, desktop environment, kernel, video drivers, GTK style sheet, whatever).
Most people aren't going to blame GNOME for broken style sheets, they'll be blaming the creator of the style sheet, whether they know what GNOME and GTK is or not.
And now seriously. If linux developers turn away from native ui libs (like KDE or GNOME), this might be one of the reasons. The other option is specifically ban disrespectful distros in the license terms.
I strongly believe in freedom (but not as GNU - absolute user freedom). Freedom IMO should be on both sides. If app developers doesn't want his/her app to be themed, then we should respect that. Our freedom is too look somewhere else to satisfy our need.
Meh about the in-app theming. Probably should not be bundled, but sadly most OSS ist lacking in the front-end and can really use some polish.
Yeah so, this is bullshit. Why would anyone have any say what my computer looks like.
One of the things I like most about gtk apps is the ability to theme them to achieve a uniform look across all my apps. I would rather use a slightly less functional gtk app than a qt/kde thing for this reason.
Users who care enough to mess with themes by necessity accept that sometimes things may need some tweaking. Most popular themes are on gh and have responsive maintainers who are invested in their themes looking good/uniform. The burden should be placed on the theme maintainers and the users who choose to use non-default configuration, rather than disabling themes on an ad-hoc basis.
