Hacker News Reader

The only egocentrism I see is all in the pompous article requesting that users do not make perfectly reasonable choices on their own computers. Then attempts to justify on some absurdly contrived grounds. Neither reasonable nor sensible.

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.

It EXPLICITLY says that it does not talk about users changing things on their machines, but wants it to be something the user sets instead of a distro applying by default.

I may choose a distro that specifically looks a certain way - like the one that tries to look just like MacOS. That's a perfectly reasonable thing to want to do. Just as it's perfectly reasonable to regret consistency on a platform that doesn't have distros - as you may want to vary.

"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.

If a distro is committed to modifying the style sheets to look like macOS, then it should be the distro’s responsibility to maintain the applications. Precisely because the distro market for Linux is so varied, it is hard for Gnome app developers to support all possible theme configurations.

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.

> it doesn’t say there shouldn’t be distros with custom theming.

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.

Choosing a Linux distro with a specific theme rather than one using Adwaita or sticking with the pre-installed Windows is the user changing things on their machine.

I'm not sure they're saying that end-users shouldn't make those decisions, simply warning that customised versions of their software won't be supported by upstream to the same degree, and thus distributers should leave the styling as-is. On the first point, to quote the article:

"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."

I think that's the point they're trying to make - there is a certain amount of caveat emptor associated with theming. But they don't make it well when they say "don't them our apps".

They're not addressing this to end users. There is a notice at the top of the article in a bright yellow box.

> 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.

> Please read the letter all the way to the end

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?

It's unreasonable to expect a developer to support third-party modifications to the software--especially when that software and support are free.

To my view of the world, the reasonable grain of truth in the article is "Don't break our apps when you theme them to match distro". A perfectly reasonable request, and stance that most could support without caveat.

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.

Good thing theming doesn't modify the software. It's reasonable to expect a developer to support software being used in an environment that does not 100% match what they use (to the extent it's reasonable to expect support in the first place).

> Good thing theming doesn't modify the software.

Changing the UI changes the software from the user perspective.

That's why they're users and not developers.

It's always a good sign that you're communicating clearly when you have to add a big yellow disclaimer at the top.

The article isn't complaining about users changing things; it's complaining about the desktop unilaterally applying a style on all apps without testing.

I see your point. But beware that if you make app developers go mad, they can stop using gnome and use some fw that doesn't allow theming (there is only certain level you can piss off the people :).

> Your entire comment feels awfully dismissive and egocentric.

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.

> And diplomacy is not my strong point.

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.

Well said.

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?

It’s the same mindset that gave us obligatory Web Fonts. I control my computer not some developer or website builder.

Web Fonts are a bit different - it's still semantically just text, and you have the option to override with a user stylesheet.

For many websites, web fonts have been an improvement, especially considering the sorry state of "web-safe" fonts back in the day.

The color change-inducing-friction complaint seems like an issue with lack of built-in theme sanity checking. There exist numerous partial solutions for this already, I'll link to the four best ones I know, albeit I wish someone would combine their approaches into one unified super-product:

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:

https://news.ycombinator.com/item?id=19983604

Thanks! Those are all super useful tools. I'm terrible at picking colors myself.

Adobe also has a very interesting color picker:

https://color.adobe.com/

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.

> Even the slightest change in color can introduce friction between UI elements.

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.

> And the overarching topic is essentially User Experience.

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.

It's not so egocentric if you factor in the fashion aspect. Not everybody wears the same matching clothes.

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?

The letter is about distributions not end users. It says end users are allowed to do as they wish. So that accessibility concern is covered.

It says distributions should not theme because it doesn't work. If theming doesn't work when a distribution does it, it doesn't work either when an end user does it for accessibility.

"Doesn't work" is far too broad a statement. An end user might choose a theme that works fine for the handful of particular applications they care about; yet that same theme might disrupt many other applications on the same distribution.

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.

> "Doesn't work" is far too broad a statement.

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.

Expecting distro maintainers to test every GUI feature on every piece of software on Linux is a tad unrealistic don’t you think?

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.

Actually no that’s not what it said. Or at least not in the way that your terse paraphrased summary suggests.

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.

One of the reasons they cite for distro theming being bad is that it that it makes applications unusable. I think that can be validly summarized as "theming doesn't work".

“Can” is not the same as “does”.

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.

> Your entire comment feels awfully dismissive

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 author presents valid concerns, but the user is still higher priority.

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.

> Your entire comment feels awfully dismissive and egocentric.

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.

Did you read the original post? Its about distributions providing themes, not users who tweak their desktops.

I did.

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.