@Conan_Kudo I just don’t see where in the post I suggest we gut the essence of what GNOME is, that we give up on personality, etc. That seems like a huge stretch from what I actually wrote, which is why I questioned if you’d read it. I’m explicitly saying we should retain personality, and I think I lay out a fairly natural evolution of *what the community has already been doing* design-wise.
@Conan_Kudo the foot is quirky—and actively hard to work with. Rather than use a logo at all, we've repeatedly seen it just completely dropped from spaces _anyway_.
Instead, I'm proposing we come up with something better, even if whimsical and quirky, but that actually works in the contexts we need to use it.
I don’t think any of the modern GNOME design work has been “giving up the ‘personality’ of projects and communities.” In fact, quite the opposite as I feel like GNOME’s is strongest now.
Friday night? Perfect time to drop a blog post that might sound like clickbait, but that I genuinely hope can help forge a path forward while making everyone happy—or at least pissing everyone off equally (sometimes the best you can ask for!)
@jorge@downey not explicitly, but a growing number of GNOME Foundation members and volunteers have been hoping we could improve the brand. The foot has a legacy but also has practical issues.
Nobody has explicitly approved getting rid of it, but also the board approved the new website design afaik; they could have said, “Looks great, but it needs the foot,” but as far as I’m aware, that didn’t happen.
@jorge@downey maybe I should just bite the bullet and propose a referendum or whatever; I’d have to look up how that all works.
The two main arguments I have heard are, “But we like the foot!” which of course, anyone will say about their baby, and “Ugh trademarks are expensive,” which, okay, fine, but also that shouldn’t mean we are stuck with something that a bunch of contributors actively dislike.
@ebassi@jorge@downey nobody snuck anything; the website was being worked on for months and was signed off on by the board.
Also, that sentiment hardly seems productive. GNOME has had three or more logos over its existence. Why is the current one (with practical, observed issues in the wild) somehow the best that ever could be? How would you feel if you thought a particular codebase was bad, but a contributor told you you could pry the current code from their cold dead hands? 🤷♂️
Something fun we’ve been doing at @EndlessOS is running learning programs where we help learners get used to actual open source collaboration—with video games!
WAIT
Not “educational games” or “gamified learning”—no, actually contributing to a real game using real open source workflows. Here are some fun results from one cohort so far; check out the Extra Levels in Everlasting Candy, an extension of the open source game Candy Wrapper:
Dynamic actions aren't currently part of the spec, but are implemented on many desktops with the Unity LauncherEntry API. I hope that support will be added to GNOME either for this API or another one, specifically because that’s something we identified as missing from the Background portal as a replacement for status icons.
Do I know any designers explicitly experienced in *brand* design who would be willing to help out an open source project? I’m working with a project that is interested in a new logo, and I’d love to connect you.
Unfortunately I don’t know that there’s a budget, so this would likely be a volunteer/pro bono effort unless we think we could crowdfund/find a sponsor to pay for the work. Still, if you’re interested, let me know in a reply, please!
Local-first peer-to-peer GNOME people… if I wanted to make a GNOME app similar to those party games where you enter a code and then all join one host's game, then compete for trivia questions or something, is that relatively straightforward to do with our current tech stack? What would I use to do that?
I'm tempted to make a FOSS Kahoot-alike game in Godot, but it could be fun as a GNOME app, instead.
Designing for the Digital Age is a great one that is dense like a textbook but extremely comprehensive; it's what we used at Visual Logic and taught me most of my formal UX knowledge (in addition to the actual internship and excellent mentorship from the designers there).
I still have a digital copy but don't ever find myself flipping through the physical one, so I'd love someone else to be able to.
I have a bunch of physical UX/design books that I'm getting rid of; I've had them for years and honestly just never read all the way through them, as most of my experience was from a specific internship and textbook and then real world experience—and lots of blogs and ebooks rather than physical books.
Is anyone in the Denver area interested? I would rather give them to someone who is getting into UX than just donate or sell them to a generic book store.
How do I help people understand that *for an indie app store,* taking only a 30% cut of each app purchase is literally not even sustainable on its own?
And suggesting that 10% is too high and that it should be 5% for proprietary apps and 0% for FOSS apps is just… literally impossible??
We’re not talking Apple or Google here—we’re talking a small, indie open source app store that doesn’t collect personal data, respects and protects privacy, prioritizes FOSS apps, and does everything openly.
Of course these are sweeping generalizations; I know not every game dev thinks/works in these ways. My point, though, is that “game development” in many ways is a *parallel* field to “software development,” and expecting them to be the same is going to give you a bad time.
We’re trying to instill good software dev practices when teaching game-making at Endless due to the upsides (like easier collaboration and maintenance), but this disconnect is something I think we’ll always come up against.
Tooling is another big one: devs are not writing their games line-by-line. Or, they are for game logic, but their game engine’s editor is also making a bunch of changes to their project files behind the scenes. This makes it particularly hard to apply literal line-by-line text-based patches, for example. It also makes “proper” version control difficult. As a result, game devs might not follow what we see as best practices in the open source world because the tooling is not set up for it at all.
Another is in approach to cleverness: I was taught that being clever was not actually a good thing in software development; it's more important to do things clearly and in a maintainable fashion—even if there are mild performance downsides.
In game development, it skews much further in the other direction: the player’s experience is *all* that matters. Take as many clever shortcuts along the way to eke out as many frames as possible—after all, you don’t have to maintain it once it’s shipped!
Example: devs often see their game as a work of art, similar to a movie. They worked on it, crunched during development to get it done, and finally released it. It's done. They've moved on to their next project!
Sure, they might drop a patch release here or there to fix a bug in the game, but in many cases, games are effectively “unmaintained software” the moment they’re released. You can balk at that, or you can try to understand why some assumptions about software development might not apply.
Game development smells a lot like other software development (and *can* be done that way), but it’s an entirely different world with decades of industry norms and expectations. Oftentimes, trying to apply the same approach as other software will seem baffling to game developers at best—and actively antagonistic at worst.
Building useful, usable, delightful products that respect privacy.:eos: Partner success at @EndlessOS Foundation:gnome: @gnome Foundation member:flathub: @flathub contributorPreviously: co-founder & CXO at elementary OS, UX architect at System76.I have a background in UX architecture, open source, product design, & communication.Still an emo kid at heart. 🖤⁂#OpenSource #GNOME #Flatpak #StarWars #LEGO #3DPrinting #HomeAssistant