Recent searches
Search options
@tchambers @ScottStarkey I would definitely love it if some of my ideas were to get implemented in Mastodon’s default theme. But I’m also not sure they’d be welcomed by the team — and I wouldn’t feel motivated to work on PRs that will never get merged.
@nileane @tchambers @ScottStarkey We’re working on documentation in the new year to explain our design process and get more alignment on how design should work in an OSS environment. But in the meantime, PRs that aren’t radical undertakings and can be backed up with some amount of objectivity would probably be received well.
*disclaimer, i’m just a contract designer working on the 1st party mastodon app, i don’t speak for the core dev team or the web team.
@nileane @tchambers @ScottStarkey as an aside while i’ve got you all here, what would be helpful in a Mastodon HIG-style document? open ended, i’m trying to collect as much feedback as early as possible to guide what the resulting doc will be like
@samhenrigold @tchambers @ScottStarkey I might be! I don’t know if I can truly help in creating such a document, but do feel free to ping me anytime if you’re looking for feedback on things!
@samhenrigold @tchambers @ScottStarkey Alrighty, noted :)
@samhenrigold @nileane @ScottStarkey
On this exact topic, I'd say the same thing for @rolle and @cheeaun and @elk UX folks and early PR feature requests to the Mastodon core...
@tchambers @samhenrigold @nileane @ScottStarkey @cheeaun @elk I’ve had this discussion many times. But it is good to always reopen a discussion about this as there are CSS and UI developers amongst us.
For me there are several reasons that prevent me doing it:
1. Time and commitment (I barely have time for the Bird UI right now from customer projects)
2. Different structure (the core needs rewriting before that happens, most importantly CSS vars instead of SCSS vars)
3. Not sure if they get merged / not sure if worth it (afraid of ”looks too Twitter” reactions, because that is actually the driving motivation for me) - Mastodon core changes are often nitpicked, and as I mostly see that as a good thing, it sometimes limits the development. Eugen can even dismiss his own changes sometimes 
I like the fact there is this certain barrier in committing, even with it we have a platform with the best features available. But what would we have here if it was less strict? I feel contradicted about this.
There is this certain kind of freedom in external theming. You can do whatever you please. While some small things are awesome (I’m still convinced that my threaded lines and the message structure inspired them to go to the core even without me), I personally am not interested in adding in the small things when I even don’t know what are good adds. I agree that @nileane’s translate button (that’s awesome btw!) could be, but would it be just one hack without the Mastodon core styles rewrite?
Now that we have :has in #CSS almost anything is possible. But instead of using hacks we should utilize the real deal, Mastodon core SCSS. And that is currently far behind…
Also explained here: https://github.com/ronilaukkarinen/mastodon-bird-ui#i-like-it-so-much-why-it-cant-be-the-default-mastodon-ui
@rolle @tchambers @samhenrigold @ScottStarkey @cheeaun @elk I agree. It's about the same for me. Looking at Mastodon's current code for its UI, it seems like a big commitment to even try and contribute the little improvements I would like made. Both Bird UI and Tangerine UI have been built on top of a base that would need to be re-thought to be more accessible to outside designers. We can't just submit our CSS ‘hacks’ in a PR. 