Live data from Hacker News

Please don’t theme our apps

stopthemingmy.app

201–206 of 206 posts

Re: Please don’t theme our apps

#201

Earlier quoted context omitted.

> 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 volunta…

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.

Re: Please don’t theme our apps

#202

Earlier quoted context omitted.

Your entire comment feels awfully dismissive and egocentric. 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…

> 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 volunta…

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?

Re: Please don’t theme our apps

#203

I honestly think we just need to have light and dark modes built in. If you want to modify the dark theme a bit, go ahead, but since the original dev knew the background should be dark and the foreground light, it should be OK. The problem is when people implicitly assume a light theme, but then use a dark one. If we could "tag" a theme as light or dark, a lot of this problem would go away.

I think you're onto something, but I don't think it's as simple as just having a "light theme" and a "dark theme".

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.

Re: Please don’t theme our apps

#204

Earlier quoted context omitted.

Just the inconsistency makes it very unusable.

I respectfully disagree for the large part. My own brain seems to have no issue coupling functionality to visual design. Yes it's probably less optimal for novice-to-expert transition than having colour variants, but conversely it also gives stronger immediate affordance as to what subreddit you're using..

It might depend on one's browsing habits. True, I believe the intention was to give subs their own identity, as if they were individual websites. However, I frequently click between subs. The fact is that it's a single website.

I have no question that every study of user interface ever published would indicate that buttons changing visual appearance, position, or availability with no predictability several times in a browsing session is a high friction interface.

Re: Please don’t theme our apps

#205
I have a lot of sympathy for the signers of this letter. As Havoc Pennington (team lead of the GNOME 2 project) liked to point out, every option you provide to users has a cost to the developers in terms of testing and maintenance. Maybe a better way for the letter signers to communicate their position would be to simply say "We don't support nonstandard GNOME themes". Certainly, they're within their rights to say this, and you're within your rights to not use their apps if you don't like it.

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.

Re: Please don’t theme our apps

#206

I have a lot of sympathy for the signers of this letter. As Havoc Pennington (team lead of the GNOME 2 project) liked to point out, every option you provide to users has a cost to the developers in terms of testing and maintenance. Maybe a better way for the letter signers to communicate their position would be to simply say "We don't support nonstandard GNOME themes". Certainly, they're within their rights to say th…

This blog post provides rebuttals to some of the points made in this comment thread:

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

Post reply on HN