Cassidy James Blaede

How and Why to Get Verified on Mastodon

Wed, 11 Oct 2023 00:00:00 +0000

I run a little family Mastodon server so that I can have @cassidy@blaede.family and feel comfortable sharing random photos of my kids with people while remaining in control of how they’re shared. Part of running a Mastodon server is that the admin can curate what hashtags, posts, and links are allowed to trend; e.g. if #furryNSFW is popular across your server’s corner of the Internet, you might not want that to be recommended to your mom on the trending page (true story!). So admins can explicitly allow or disallow each trend before it’s shown to their users. Once a trend is allowed, it will be able to trend again at any point in the future, cutting down on work for seasonal or naturally recurring trends (like #SilentSunday or #SuperbOwl).

This also works for individual links and posts, but a more powerful feature is that admins can explicitly allow (or disallow) certain accounts or publishers to trend. This can greatly cut down on moderation work, as admins can allow-list reputable news sites or people they know are generally good people who stick to the rules and are unlikely to post something they don’t want trending; I personally use this for virtually anyone I actually know in real life or from various open source projects. However, I’ve started becoming a bit more lenient than that, as for my small instance there’s a pretty low risk of abuse: I allow-list anyone with a verified account that looks decent at a glance. I check in on the trends regularly and can always revoke that, but if someone has proven they are who they say they are and aren’t regularly posting things I wouldn’t want to trend, I don’t want to have to go approve every post that might trend!

So my call to anyone and everyone on Mastodon—but especially journalists and well-known personalities—is: get verified! It greatly helps people like me and mods of larger servers know you’re you, and makes it more likely that people will find you in search, follow you, and see you on trending page in their Mastodon app or server.

Okay, but how?

If you’re coming from X (the social network formerly known as Twitter and still available at twitter.com) or a Meta network like Instagram, you might think being verified is some process requiring payment, government ID verification, bribery, etc. With Mastodon, that’s not so! Verification is built on web standards and proves one thing: your account is associated with a specific page on the Internet. That might seem like less of a guarantee (it doesn’t explicitly prove your real human identity), it’s powerful. Here are some recommended ways to use verification to prove you’re, well, you:

Personal website: this is the most flexible and in your control; if you have a website where you direct people, use that for verification! It proves that your Mastodon account belongs to the same person as the website.
GitHub account: GitHub supports Mastodon links on profiles and will add the right markup to support verification. For open source people, this is a great way to associate your work with your social media presence.
Organization about page: if you work for an organization like a news site, see if you can add a link to your Mastodon account on your profile page there. This associates your work at that organization with your Mastodon account and proves your authority when talking about your work.

Another neat thing: you can verify multiple links! So I have cassidyjames.com, blaede.family, and my GitHub account all verified on my profile. The first link is what will show in some contexts like search results, so put the most well-known associated link first.

Technical details

If you’re manually adding a link on your own site (or talking to a web developer to get support added to your organization’s site), here’s what you need to know:

The page needs to link back to your public profile, either with an <a> on the page or a <link> in the <head>
The link needs to include rel="me" to distinguish it from just linking to someone else’s account
The page needs to be secure (served over https)
There’s a 1 MB page limit; if your page is too heavy, it won’t work

Use Commit from Flatpak Both Inside and Outside of Toolbx

Mon, 09 Oct 2023 00:00:00 +0000

This one’s gonna be a short one, and is mostly for my own notes. :)

I like to use the Commit app as a visual editor when committing changes to a git repo; it’s a simple dialog that gives some niceties over using the CLI, like spell check, a visual indication of line length, graying out comments, etc. It’s nice!

Here are the instructions provided by Commit to edit your git config:

git config --global core.editor "flatpak run re.sonny.Commit"

Since I’m often in a toolbx container when developing, ~~I can’t directly access my host’s Flatpaks (which makes sense!), and thus the provided instructions don’t work in this context~~.

Update: Just Install Flatpak in the Toolbx Container!

Thanks to Felipe and Sebastian in the comments, I learned Flatpak inside a toolbx container is actually smart, and will launch host Flatpaks on the host! So all you actually need to do is:

sudo dnf install flatpak

…or your toolbx container distro’s equivalent, then the instructions provided by Commit should Just Work™️.

If you get an error about unpacking rpm package flatpak, you may be on an older version of toolbx and need to work around a bug; just sudo umount /var/lib/flatpak, then install Flatpak, then restart your container exit it, then podman stop fedora-toolbox-39 (or your container name), then toolbox enter fedora-toolbox-39 (or your container name) again.

Edit the Git Config (Outdated!)

I could modify my git config to work in the container by using flatpak-spawn (which, despite its name, you can use to spawn things outside of toolbx containers as well as outside of flatpaks), but then it won’t work on the host, which I also need! So I have to dynamically handle both cases…

After a bit of trial and error, I came up with this kludge:

git config --global core.editor 'if [ -f /run/.toolboxenv ]; then prefix="flatpak-spawn --host"; fi && $prefix flatpak run re.sonny.Commit'

If all you wanted was for this to work for you, copy the above and you’re done. :)

How it works

Let’s step through it to better understand what’s going on. I’m going to break it into lines to make it easier to read; I know this can’t be parsed as-is by bash, but just bear with the visual:

git config --global core.editor '
  if [ -f /run/.toolboxenv ]; then 
    prefix="
      flatpak-spawn --host
    ";
  fi 
  && 
  $prefix flatpak run re.sonny.Commit
'

So the outer-most part is that we’re setting the core.editor variable globally with git config, just as Commit’s original instructions say. We’re using single-quotes (') here because we don’t want our $prefix to be interpreted as string replacement at the time we set the variable, which double-quotes (") would do; we just want to include that in the literal string (to be replaced when git runs it).

Next we have an if to check if the file /run/.toolboxenv exists; this exists in all toolbx containers, so it’s an easy way to know if we’re running in toolbx.

If we’re in toolbx, we set a new variable prefix to flatpak-spawn --host since we need to run the actual editor on the host, not in our container. We use double-quotes (") here since we’re inside of the single-quoted (') string.

After we successfully do the toolbx check and optionally set the prefix, && will tell the shell that’s calling the commit program to execute the next bit.

We include the actual original flatpak run re.sonny.Commit, this time prefixed by $prefix, which will either be string-replaced by a harmless empty string, or by our flatpak-spawn --host if we’re in a toolbx container.

We have to leave the command for the end of our kludged string because git will append the temporary filename of the commit message to the end of the whole core.editor string; if we included flatpak-span --host flatpak run re.sonny.Commit inside the if statement, it would never get the name of the file to edit, and wouldn’t work (ask me how I know…).

So there we are. It’s super ugly, but hey, it works. How would you solve this in a better way? Let me know on social media. :)

Endless ♥ GNOME at GUADEC 2023

Tue, 03 Oct 2023 00:00:00 +0000

In July, my employer Endless sponsored and attended the annual GNOME conference, GUADEC, in Rīga, Latvia. Endless has a long history of supporting and collaborating within the GNOME open source project, and it was great to support GUADEC again this year as the platinum sponsor of the event.

Our support of GUADEC and GNOME is more than just a sponsorship, though; we showed up and participated all week to present and plan for our continued contributions to GNOME. The conference is designed around a one-day advisory board meeting, a few days of talks, and a few days of working sessions.

Advisory Board Meeting

We joined representatives from other organizations using and invested in the success of GNOME in meeting with the GNOME Foundation Board of Directors for an all-day Advisory Board meeting. There we discussed improving the accessibility of GNOME, the travel sponsorship process, reproducible builds for apps, how organizations can better upstream their non-code contributions to GNOME, and other topics raised by member organizations.

Talks

Endless OS Foundation employees presented a total of nine talks across three broad topics:

1. Design

GNOME Design State of the Union: I co-presented as part of the GNOME design team, showing our work over the past year and some plans for the future
How to Make a Delightful App Listing: I taught app developers how to present their apps in their best light in app stores like GNOME Software, Flathub, and more

Reaching New Users With GNOME: Robert McQueen shared insights, knowledge, and ways forward learned by our work at Endless
Maintaining Healthy Upstream Relationships as a Small Team: Dylan McCall shared techniques for effectively communicating upstream, fostering a culture of collaboration, and managing disagreements
What is the GNOME Advisory Board? I gave this impromptu “lightning talk” (five-minute talk prepared day-of) about my experience on the GNOME Advisory Board including what it is, how it works, and why more organizations should join

3. Technical

State of the Shell: Georges Basile Stavracas Neto and other GNOME Shell developers shared the improvements, highlights, and latest development plans in Mutter and GNOME Shell
Reducing Power & Bandwidth Use in Apps to Keep Users Happy: Philip Withnall taught app developers how and why to change app behavior to save power and bandwidth when appropriate
Slow Progress on App Save/Restore Support: Philip Withnall shared an overview of the progress towards saving and restoring app state across restarts, including what’s left to do

Working Sessions

Endless OS Foundation employees attended a variety of workshops including GTK Planning, GNOME Release Team, and GNOME OS. Throughout the week we also had countless conversations in hallways and over meals with other GNOME contributors—all of which helps share knowledge and shape the direction of GNOME.

I’m proud to be part of an organization that takes this critical work seriously, collaborating deeply with and within GNOME to widen our impact far beyond just users of Endless OS.

What is GNOME?

GNOME is an expansive open source community developing an entirely free and open source modern computing ecosystem. GNOME technologies serve as the user interface and much of the technical stack of the most popular Linux-based operating systems including Endless OS, Ubuntu, Fedora, Red Hat Enterprise Linux, and more.

Anyone can use and contribute to GNOME technologies to provide an alternative to Microsoft Windows, Google ChromeOS and Android, or Apple macOS and iOS.

GNOME Advisory Board

The GNOME Foundation is the non-profit organization that supports the GNOME community with staff, infrastructure, trademarks, legal framework, etc. The GNOME Foundation Board of Directors is democratically elected by the community to support and guide GNOME.

Since GNOME technologies are so widely used, it’s beneficial to get the input and advice from other organizations that are invested in the success of GNOME—like Endless OS Foundation! The GNOME Advisory Board is an advisory committee made up of such organizations and meets with each other and the elected GNOME Foundation Board of Directors twice annually. There’s no decision-making authority, but it’s a way to collaborate and share individual organizations’ plans as they relate to their financial, technical, or labor investments into GNOME for the coming year.

I’m back from GUADEC 2023

Sun, 06 Aug 2023 00:00:00 +0000

I’m back from Rīga, Latvia where I attended GUADEC 2023—the annual GNOME conference. It was my first time attending since 2019 due to COVID-19 plus having had another child in 2022. It simultaneously felt like it had been ages since seeing everyone, and like we picked back up after no time at all.

For me, attending GUADEC in person is exceptionally important: the face-to-face conversations, exploration of the host city, eating and drinking together, and spontaneous hacking all serve as powerful bonding experiences and help develop mutual understandings of the actual humans behind online usernames and avatars. We come away from GUADEC with fresh ideas, new perspectives, stronger friendships, and renewed energy to make GNOME and the open technologies we all care about better than before. You can get a small fraction of that from remote attendance—and remote participation is important to make the event as accessible and inclusive as possible—but I greatly prefer in-person participation if at all possible.

While traveling from the US was as long and grueling as ever (and meant nearly two weeks away from my family), it was ultimately worth it to be in person. I just hope we can spread GUADEC out a bit more in coming years so it’s not this hard every year. 😅 More on that in a bit…

GNOME Advisory Board
My Talks
Hallway Chats
Summary & Thanks

GNOME Advisory Board

I was given the opportunity to attend the GNOME Advisory Board meeting for the first time, representing Endless. The Advisory Board is a group of organizations involved in and with a vested interest in the success of GNOME that meets twice annually—at GUADEC and FOSDEM. There is no decision making authority, but it serves as a time for people from these organizations to get together with one another and the elected GNOME Foundation Board of Directors to discuss their ongoing and upcoming plans as they relate to GNOME.

There is a shared understanding of both collaboration and confidentiality—we share with one another what we can to coordinate our efforts, ultimately multiplying our individual organizations’ impact. Because of the understanding of confidentiality, I won’t go into detail; but here were common threads and conversations:

Accessibility

Multiple people mentioned investing efforts into improving accessibility of GNOME technologies. Platform modernization with Wayland and GTK4 brought troves of technical improvements, but the resources for tackling accessibility to ensure it remains as good as or better than in the past have been lacking in recent years. This has been recognized and I’m confident it will be well-addressed.

In addition to resources provided by organizations, there may be funding from grants to help in these areas in the coming years. If you are someone who is aware of grant application processes or knows of specific grant programs, this is a huge way you can contribute to GNOME; reach out to the Foundation to help coordinate securing additional funding in this area. Or contact me, and I can point you in the right direction—my contact details are in the footer!

Member Participation

Due to a variety of reasons, the Advisory Board meeting was less-attended this year than in the past. We discussed this a bit—particularly over the lunch hour—and brainstormed ways to ensure everyone can be represented. One area identified was that the move from mailing lists to Discourse and GitLab may have left some folks behind, and this will be addressed. We also identified outdated contact details and planned to speak to specific individuals to help ensure member organizations knew of the meeting and knew their attendance was welcome and encouraged.

We also chatted a bit—both at the meeting and throughout the week—about how we could encourage other organizations to join the Advisory Board to represent diverse interests. This inspired me to sign up for a “What is the GNOME Advisory Board?” lightning talk as a first step towards demystifying the Advisory Board—and encouraging more organizations to join.

Travel Sponsorship & Hackfest Locations

A member of one organization reported that they were able to help GNOME by providing physical space at their organization’s offices for hackfests, which is another great way organizations can contribute to GNOME; travel is one aspect of organizing meetups, but having a well-resourced location is important as well. If you work for an organization that could help out in this area as well, let the Foundation know—or contact me via the details in the footer and I can forward it on.

There was also feedback about the travel sponsorship process; this was an area the Foundation knew was a bit painful this year as things moved to GitLab, and some outdated information persisted in other places. But it’s being addressed.

Reproducibility of Flatpaks

We heard an update from Flathub as well as at least one member organization that there are mutual interests in getting reproducible Flatpak builds integrated with Flathub.

I’m not deeply into the enterprise world, so forgive me if I don’t quite get this right, but; my understanding of one example was that if an enterprise distribution wants to encourage their customers to use Flathub because it’s where the apps are, they should be able to sign off on a hash of the app build built on their own infrastructure—even if the customer ends up downloading that build from Flathub’s infrastructure. If the apps are built reproducibly, the hashes would match, so it wouldn’t matter where the bits themselves came from.

I know this is an important step in the overall trust model of a neutral infrastructure like Flathub, anyway; you should be able to trust the middleware not because of the people who are involved (and they’re good people!), but because it’s entirely transparent and auditable.

Upstreaming More than Code

Something raised was: how can the Foundation and Advisory Board organizations better support upstreaming more than just code contributions—that is, things like metrics, survey results, user study results, and rationale behind design decisions? For example, some downstream distributions make design decisions that aren’t upstreamed into GNOME (think: adding a dock, changing stylesheets, etc.). While downstream differentiation is important to those organizations, are there ways we can better support that or learn from those changes upstream to make GNOME a better product for all the downstreams?

This was more of a “get the gears turning” discussion without any specific immediate actions or outcomes, but it was an interesting conversation nonetheless.

My Talks

I originally planned to give one talk this year: an updated and more GNOME-specific version of a talk I gave last year at the Ubuntu Summit. Since I was involved with the GNOME Design team over the past year, I also ended up volunteering to co-present the annual GNOME Design State of the Union talk, then I signed up for the aforementioned What is the GNOME Advisory Board lightning talk—and then I was almost roped into co-presenting another talk but ended up just helping write and prepare slides for it. 😅️

I actually really enjoyed being so involved this year, and I regret not getting signed up to help with introducing speakers, A/V, or some other volunteer position. Maybe I’ll make up for it next year…

How to Make a Delightful App Listing

This was a fun talk, but I committed one of the conference sins I always try to avoid: I rewrote much of it the night before. 😬️ It was honestly not that bad since I’d presented a version of it last year, but it turns out that Flathub had since published really great AppData guidelines—and I only learned of this at a bar the night before my talk. So… I rewrote the last section of my talk incorporating some of that advice.

In the end, I think it made the talk far better. It was a good taster of the guidelines and I hope it encouraged app developers—both of core GNOME apps, GNOME Circle apps, and the broader ecosystem—to revisit their app listings to present them in the best light possible.

I’ve published the slides, speaker notes, and a link to the stream.

GNOME Design: State of the Union

The annual update from the GNOME Design team was fun to participate in. While I wasn’t deeply involved in making mockups, icons, or major design decisions, I was involved nearly every week over the past year in providing feedback and insight. We divided the talk into a six sections plus an intro and summary, with us each presenting two of those. I took the Intro and Core Apps; while they were brief, it was great to be able to share the stage with (and show off the work of) talented folks constantly pushing GNOME design forward.

Here are the slides and a link to the stream.

What is the GNOME Advisory Board?

This was the lightning talk I decided to put on the schedule after attending my first GNOME Advisory Board meeting. It was pretty rapid-fire, and most of the actual content came straight from the GNOME wiki, but I got a lot of feedback afterwards that it helped demystify the Advisory Board—and even inspired a few people to reach out to organizations to encourage them to join. 🙌️

I’ve published the slides and a link to the stream.

New Users for GNOME

This was a talk by Robert McQueen, CEO of the Endless OS Foundation and President of the GNOME Foundation Board of Directors—but Will Thompson and I did help out a bit in preparing notes and some slides. 😁️

Rob pulled it all together into great talk sharing insights, knowledge, and ways forward learned by our work at Endless—particularly around how first-time computer users (including both kids and adults) are an impactful target audience for the work we do on GNOME.

YouTube Stream

Hallway Chats

A huge part of the GUADEC experience for me is the “hallway” chats often happening literally in hallways, but also over lunch, drinks, or late nights in someone’s accommodation.

GUADEC 2024: Denver, CO, USA 🎉️

A persistent focus of mine was on GUADEC itself: how it was organized, how people “did” GUADEC, and what their feedback was. This was because—as was announced in the closing ceremony—GUADEC is coming to my home town of Denver, Colorado in 2024! I think I kept the lid on it until the closing ceremony, but I made sure to pay attention people to and listen to their input.

One tiny example of feedback: yoga mats! Someone suggested that with all the travel, walking, lugging backpacks, and late nights, it would be nice to have a quiet corner somewhere with half a dozen or more yoga mats and sanitizing spray. Attendees could take a moment to stretch out or just center themselves during a break. I thought this was a great idea, and I’ll be pushing for this in Denver—maybe it will become a recurring part of GUADEC?

We also talked a lot about how to document things clearly on the GUADEC website, reducing the duplicated GUADEC communication channels (I think I counted five different channels on Matrix… and most people only used one), encouraging inclusive eating options like vegetarian, vegan, and gluten-free restaurants, and of course: all the fun things people would want to do in and around Denver (Casa Bonita? Meow Wolf? The mountains?).

Another area we focused on was climate impact: while flying a bunch of Europeans to the US obviously has its impacts, there will also be significantly reduced travel for many of us within North, Central, and South America. Even so, I’d like to encourage lower-carbon transit options as much as possible, e.g. rail and bus if possible within the US, trying to keep everything for the week of GUADEC itself along convenient public transit or walkable, and reducing our impact in smaller but meaningful ways like encouraging reusing lanyards and avoiding other single-use waste. Philip Withnall provided some great tips for me, and I’ll be taking his advice for how to approach some of these areas.

The Can of Worms: Metrics

Against my better judgment (and the advice of friends), I broached the topic of privacy-preserving metrics once or twice… In all honesty, GUADEC hallways/bars are the perfect sort of place to have these conversations without the pressure of forming an Internet Opinion™️ etched forever into the collective memory. We’ve regularly been having these sorts of conversations since at least 2018, anyway, and while recent Fedora Discourse threads of doom have made it more of “a thing” than in years past, I felt it was important to speak candidly about it in person.

I came away with a few insights.

First, there are real areas where GNOME maintainers literally don’t know if complex code paths are ever touched in the real world, and this is an area a privacy-preserving tally-counter could provide real value to users; for example, GNOME Document Viewer (Evince) apparently handles something like ten more file formats than just PDFs, but nobody we talked to at a GNOME developer conference even knew that. Document Viewer is also one of the handful of apps that hasn’t been ported to GTK4 and Libadwaita, in part due to the complexity of maintaining those codepaths. It sure would be beneficial to the maintainers to know if anyone actually uses those other formats in Document Viewer, and if not, it could greatly speed up the modernization of the app—bringing both consistent design and improved performance—by simplifying what it supports. At the same time, if it turns out that one or two other format than PDF is actually widely used in the wild, then that could inform the design of Document Viewer as well, making it better at handling the tasks it’s actually used for.

Second, people still don’t really know the details of the open source metrics system developed by Endless and proposed to be used by Fedora. For example, the system protects privacy by reducing precision on the client side while still answering broad topics, e.g. by filing off the last several digits of latitude and longitude in estimated geolocations. It can aggregate data points locally and only submit a summary of events—e.g. an aggregate count of how many times a specific feature was used over the past week rather than submitting a timestamped event every time the feature was used. This was well received, but it was also clear that it could be better communicated since people didn’t know it.

Third, the idea of further “fuzzing” data via differential privacy or randomized response (techniques from at least as far back as the 1960s to collect aggregate information while protecting individual privacy) was very popular. While the aforementioned reduction in precision is already implemented, this sort of randomized response to ensure individual event deniability is not yet—this is a clear area that could improve the system for all users.

Lastly, people seem to be scared to raise their (or affiliated organizations’) heads over the parapet to become a target of The Internet Mob. It’s understandable considering the difficulty in communicating nuance plus the knee-jerk backlash from people around the Fedora proposal. However, I think this is actually a downstream issue from the two above: if people don’t know how this works and it doesn’t handle privacy preservation in some ways as thoroughly as say, Apple (even if it does so in a much more transparent and auditable way), then it sounds easier to just avoid it. Perhaps more energy could be spent around addressing those areas—in the end, GNOME contributors are some of the most privacy-conscious people and are exactly the type of people I want designing and developing anything to do with metrics, but that’s a point that seems to be lost on the Internet at large.

Guerrilla User Testing

An entertaining and at least mildly insightful task at GUADEC was cornering unsuspecting locals and getting them to try GNOME. Okay, it wasn’t quite like that: we did find friendly faces at coffee shops and around town who were willing to take a few moments to run through some impromptu user testing around the Activities button and the new proposed design. This included locals, staff of venues, and attendees’ partners who are not currently GNOME users.

I think there will be more shared on this process in the future, but my take-away was that the informal nature of this served as a sort of vibe check more than anything; we weren’t disciplined in how we took notes, what leading questions we asked or avoided, and how we presented it from person to person. Allan Day did write up a great more formal process that I’d like us to follow to get better results from, though.

Stars & Thumbs: Ratings & Reviews

The topic of ratings and reviews (e.g. in GNOME Software) came up a few times, inspired from feedback from the Bottles developers, attendees of my App Listing talk, and other hallway chats. I’ve summarized my thoughts in a blog post published last week; give it a read!

Summary & Thanks

I originally set out to detail every talk I attended, each social venue, etc. but there was so much to talk about around the “hallway” track that I wanted to detail that, instead. I would highly recommend taking a look at the YouTube Playlist of talks: they were all professionally recorded and streamed, and a gracious commentor has provided timestamps to each talk. 🙏️

I hope this write-up provided some insight into the goings-on of GUADEC and my experience there.

I’d like to thank my employer, the Endless OS Foundation, for allowing me to spend an entire week of work at GUADEC; it’s an incredibly valuable aspect of GNOME, and I love that Endless sees that. I’d also like to thank the GNOME Foundation for partially sponsoring my attendance as a member of the GNOME Foundation; ensuring people can get to these events is crucial for community building and all of the high-bandwidth communication that can really only happen in person.

Stars & Thumbs

Mon, 31 Jul 2023 00:00:00 +0000

I’m on my way back from GUADEC in Rīga, Latvia and one recurring discussion (of many) was centered around how ratings and reviews are presented in GNOME software and other app stores.

I’ve been building open app ecosystems for over a decade now. Ratings (quantitative feedback) and reviews (qualitative feedback) of apps can serve useful purposes: a powerful signal for ranking, a way to provide feedback to a developer, a way to demonstrate “social proof” (like testimonials or positive social media posts on a website), and a heads-up to other users for positive or negative experiences. But the widely-used five-star and review system has its problems.

Since I’m sitting in an airport killing time while waiting to my flight back to Denver (where GUADEC 2024 is happening, if you haven’t heard!), let’s dig into this.

What’s wrong with five-star ratings?

The meaning of the five-star rating system changes depending on culture, and even at its best, is a skewed system. If you’ve ever ridden in a ride-share like Lyft, Uber, or Bolt, you’re expected to give a five-star review unless something went wrong—and at least as of 2017, drivers with an average rating of less than 4.6 stars can lose their job. This is a circular problem: as more people are pressured to give drivers in general five stars, the average rating raises, which in turn raises the threshold at which ride-sharing companies will fire the drivers.

There’s also the ambiguity: ask ten people what they would rate a product from an online retailer that they found “just fine,” and you’re likely to get at least three different answers: 2, 3, or 4 stars. If the spread is that wide, is it really a useful system? We’ve seen popular apps and platforms learn this over the years, too—and many have already abandoned the five-star rating system.

YouTube used five-star reviews until 2009, when they pointed out the issues across their growing platform: most people gave five stars, some gave one star, and basically nobody gave two or three stars. As a result, they switched to a like/dislike system.

Netflix used five stars until 2017, and replaced them with thumbs-up and thumbs-down—though for slightly different reasoning; they use the ratings as a signal for recommendations rather than showing those ratings to other users. But by lowering the friction of providing feedback, they increased the amount of feedback given by over 200%.

Even back in 2009, TechCrunch pointed out that the Apple App Store’s five-star rating shared the same problems.

Specifically in the case of the Open Desktop Ratings Service (ODRS) which is used to display ratings and reviews in app stores like GNOME Software, I’ve personally heard from app developers that a five-star rating system seems ill-suited when there are few total ratings; if just a few people give the app a low rating, it looks like the app is low quality—and it’s hard to get people to update those ratings, even after any raised issues are fixed.

What’s wrong with written reviews?

Five-star ratings often come with free-form written reviews to explain why a specific rating was given, but these have their own problems, too.

Accepting written reviews can enable review bombing and harassment of developers—even for reasons unrelated to their app. This happens pretty regularly on Steam and app stores like Google Play. Think about it: soliciting written reviews is basically making a comments section. All of the problems we’ve learned with comments sections over the years apply here.

One solution could be having the app developer moderate their apps comments, but this too has problems: first, if a developer is being harassed, it’s not good for their mental health to make them be the one required to read every review. At the same time, if an app developer is ultimately in charge of what reviews are displayed, it creates an incentive to hide any negative reviews—potentially defeating the purpose of them in the first place. As a result, it should be a requirement to have a neutral third party screen reviews—and that’s very hard to scale properly, especially as an ecosystem grows.

After a review is screened by some neutral party, you very much do want the developer to be notified about it—otherwise it’s a post to other potential users without giving the developer the opportunity to improve. If people are going to spend their precious time writing a review, it should be as easy as possible for the developer of that app to actually receive the feedback!

Especially if you’re thinking from the context of a relatively small or largely volunteer-driven app ecosystem, it seems like reviews are a very difficult problem that is unsolved by some of the largest platforms at best, and a net negative on the ecosystem at worst.

What would be better?

I’ve long felt that the issues with the five-star rating plus review system could be remedied by using a simpler setup. So what’s the alternative?

My first suggestion is to use a simpler signal for ratings: something like a thumbs-up or heart icon to signal that someone likes the app. Combined with a tally of how many downloads there have been, this can give you relative rankings of apps with very little interaction overhead. If many people install an app and nobody gives it a thumbs-up, it probably shouldn’t rank as highly as an app that has a medium number of installs but a very high thumbs-up:installs ratio.

If you want to get more granular feedback, I still feel like something we discussed back in 2017 at an elementary sprint could work: quantitative feedback in predetermined categories, e.g. binary options for “fast,” “useful,” or “works well.”

I personally would avoid written reviews completely. Each time an update is released, it could render all reviews irrelevant, or it could be an entirely non-visible change—any there’s no reliable way to know that from an app store point of view. A specific bug behind a one-star rating could have been fixed, yet that one-star rating will likely stay on the app’s listing in perpetuity—especially if it’s difficult or impossible for a user to update that rating if they’ve reinstalled their OS or just never visit the app’s listing again. Encouraging users to revisit old ratings could be possible in the context of the same OS installation or if there is an account system, but that introduces a ton of complexity to a concept (written reviews) that even at its best has issues of review bombing, moderation, and localization.

An idea I’ve floated with mixed response has been to wire a thumbs-down to actually just open the AppStream MetaInfo issue reporting URL as a way to encourage people to directly file issues rather than leaving feedback somewhere simultaneously more public to users and less-viewed by the developers. However, this could seem a bit awkward or technical, so I’m not sure it’s a great idea—and there is already a “report an issue” item in GNOME Software today if that metadata is provided by the developer.

What about the ODRS?

To be clear, I’m immensely impressed by and grateful for all the work that has gone into ODRS so far: Richard Hughes has done an incredibly thoughtful and admirable job at building something nobody else was doing in the open desktop space—that’s kind of his thing! At the same time, it seems like the traction behind ODRS—especially when it comes to scaling moderation and inspiring outside contributions—has been lower than would be sustainable. So… let’s iterate and improve!

We have several interested parties in the ecosystem: GNOME Core and Circle apps, KDE apps, Flathub as an app store, cross-platform apps targeting Flatpak, elementary AppCenter and third-party apps, and downstream distros benefiting from the app ecosystem and repackaging apps for their own repos like Fedora, Debian, Ubuntu, Pop!_OS, and many more.

Perhaps it’s time to reinvigorate ODRS with the kind of cross-desktop collaboration that makes our open ecosystem as a whole stronger: the beautiful coopertition of working together on shared interests and technologies while striving to make what we each think is the best experience possible. I’m chatting with Richard and some of those folks mentioned to see how we can best direct this energy, and am looking forward to helping however I can—and if you’re interested in joining the effort, let me know!

Toot toot! Mastodon-powered Blog Comments

Thu, 06 Jul 2023 00:00:00 +0000

If you follow me on Mastodon, you’ve probably heard that I’ve added Mastodon-powered comments to this here blog. If you missed it, check it out!

Read on to dive into my process, the first few iterations of how I did it, and what my hopes are for the future. There are lots of links to the source code on GitHub if you want to follow along, as well. Oh, and throughout this post I’ll be referring to “Mastodon” comments, but technically any Fediverse account that uses ActivityPub can comment on my blog by replying to the the associated Mastodon post—and I do directly use the Mastodon API to get those replies and associated data from my own instance.

Inspiration

At some point, I had seen other folks on Mastodon sharing that they’d added comments to their websites powered by ActivityPub, but it always seemed daunting. After all, I don’t love complex web development and could see rolling my own commenting system as a never-ending web development project. At the same time, I have built a few static websites and spent years iterating on them to feel more like something running on a dynamic server, all while being blazing fast. So the challenge sounded at least vaguely interesting. At some point, WordPress also acquired an ActivityPub plugin, which seemed really cool for people using WordPress. Still, I forgot about it for a while.

I was reminded about it when Jan Wildeboer shared “Client-side comments with Mastodon on a static Jekyll website” on his blog—this seemed perfect! I peeked at it, bookmarked it, and moved on.

Finally, when I was sharing my FreeDesktop Accent Colors proposal for GNOME, I really wanted a better way for people to follow the conversation; that inspired me to finally actually dig in.

First Iteration

As a very first proof-of-concept, I read through Jan’s post again (do so if you are interested in implementing this!), then just took his code verbatim and bolted it onto my own Jekyll site. It actually worked! That allowed me to start really understanding how it works.

They’re comments, and they work!

I’ll leave a lot of the details for his post, but the super-simplified gist is:

Write a blog post
Post about it on Mastodon
Grab the resulting post ID and plug it back into the static site
The blog uses the Mastodon API client-side to fetch replies to the given post
Those replies are spit out onto the page and styled

The majority of my work to ship the first iteration was spent on tweaking the DOM that gets spit out and styling it up to fit the style of my site. It was a bit rough, but it worked!

Oops, Emoji and Avatars 🤦️

I excitedly shared a few posts with comments enabled, then someone pointed out: custom emoji (in the :shortcode: format) didn’t work! Womp womp. Luckily, Jan had already solved this for display names, so I was able to copy it for the comment itself pretty easily.

:oops:, also note the interactions cluttering things up at the bottom

Then it was pointed out they weren’t animated! Well, yeah, because I was requesting the static versions of emoji (and user avatars, actually), so that was expected. I added support for animated emoji and avatars while respecting the prefers-reduced-motion media query that can be set by OSes and browsers. Neat!

Someone pointed out that the avatar styling I was using wasn’t the prettiest with certain profile pictures, so I rewrote that across my whole site—and then I noticed some avatars were provided at a too-small size, so I fixed that, too.

Clean Up

Along the way I noticed a few things that could be cleaned up. First, inline links were included in full, which is pretty ugly. Luckily the Mastodon API returns links with helpful utility classes included, meaning you just have to use a tiny bit of CSS to imitate what Mastodon does on the web and in its apps. Second, I wasn’t handling accounts without an explicit display name as gracefully as I could; I first used some dirty string splitting, then realized I could just use the username from the API.

Check out that wrapping in the middle comment—that’s no good!

I noticed wrapping was super broken with long names and small screen sizes, so I took the time to finally learn CSS grid; check out the excellent-as-usual CSS-Tricks complete guide if you’ve been putting it off like me. This allowed me to fine-tune the layout of the replies exactly how I wanted in a way that made sense to my brain.

At this point, I was really getting unhappy with the massive blobs of HTML inside of JS inside of HTML—and my text editor’s syntax highlighting wasn’t a fan, either. So I spent some time iterating, rewriting, and simplifying things. First, since I was doing the same thing with emoji twice, I pulled out the emoji-replacing into its own function. Rather than using string replacement on large blobs of HTML, I (re)learned how to directly create and manipulate DOM elements with JavaScript. This was so much cleaner in the resulting code, even if it technically takes a few more lines.

After having a good experience switching to actual JavaScript DOM instead of strings, I took the plunge and rewrote the whole thing in the same fashion. This was my favorite part of the process because it felt like I really finally understood every line of code—and I was in charge of how it worked! Even if it’s not the best way to write JavaScript (I don’t claim to be an expert, here), it really reminded me of whipping up native code in Vala for GTK apps. If you’ve spent any time reading or writing elementary Vala code, you can probably tell I have spent a lot of time doing so as well. 😅️

Design Iteration

Something I noticed when sharing links was that if I had a thread about a blog post, the first post was being omitted because I was only pulling its replies in as comments. I fixed this by hitting the Mastodon API to grab that first post before grabbing its replies.

As a part of the above-mentioned JavaScript rewriting, I spent time thinking about how to clean up the visuals as well. I wanted to make the avatars a bit bigger and just declutter things a bit. I was especially unhappy with having a ton of default-styled links in the header of each reply, including the somewhat daunting full @username@example.com next to every single commenter’s display name.

Literally while I was working on this, Facebook/Meta/Instagram launched their Threads app. I poked at it for a few minutes to see if ActivityPub/federation was working, and it wasn’t enabled yet, so I moved on. While I was poking at it, I noticed something interesting pointing towards that federation, though: on user profiles, Threads includes a little badge with your instance name (currently just threads.net since they’re not federating). I liked this styling, and wondered if I could do something similar to clean up the @username@example.com styling that I didn’t like. So I took a stab at it!

I made the decision to actually heavily deprioritize usernames in favor of display names plus instance badges. This is still a little disjointed as inline @-mentions show usernames, but over all I really like the look. To ensure readers can tell users apart, I added tooltips to the avatar and instance badge to expose the full username—and clicking either will open the commenter’s profile on their own instance. On mobile (at least in the browsers I am able to test), tapping-and-holding either will show the link to the profile which serves the same purpose.

I also wanted a way to visually distinguish my own comments (and more generally, highlight the original poster or “OP” like on Reddit), so I added a sort of “verified” styling to any comments coming from my private instance; I add a check mark badged on my avatar and style the instance badge with a check mark and distinct accent color. I’d like to make this more generalized so if you theoretically had multiple authors on your blog, you could still highlight OP and/or trusted accounts—but that’s a problem for another day.

I went back and forth a few times with if/how to handle post interactions like favorites and boosts; if I was going all-in, I’d figure out a way to use the reader’s Mastodon account to actually directly interact with posts, but that’s… a lot more work. With all my excited sharing about this project on Mastodon, I inspired at least one other person; Julian Fietkau wrote and shared his own implementation. His version also uses JavaScript DOM manipulation, but does a lot more like handling threading, re-ordering replies, stripping leading @-mentions, and more. I still have to dig into it and see if there is more I can pull into my implementation. I did like his styling of favorites, though, so I did something similar for the time being.

Culmination of these design iterations

What’s Next

To be clear, this whole project was just something I’ve been hacking on for my own site in the evenings and in between my regular work—I don’t promise any future plans! That said, I figure it’s good to actually write up what I’d like to tackle next, if only for my own accountability.

Improved loading state: along the way, I made the decision to auto-load the posts instead of requiring user interaction. However, with that change, the comments just pop in once loaded—all with no progress indication. This seems like a clear improvement to make with some sort of placeholder state.
Cache at build time then update client-side? I’ve seen some Opinions™ about this since it would require storing others’ data, but this integration intentionally only handles non-private posts, so I think it would be okay? After all, ActivityPub servers cache content in a similar way, edited/deleted posts could be modified/removed client-side after page load, and all the data would be refreshed on the next site build to re-cache the changes. I think this would lead to an improved experience on page load since the comments would be there from the start and only the changes would need to load/shift on the page. Then again, it increases the complexity quite a bit, and basically means I have to maintain code in two places: at build time, and at page load.
Threading? At one point I had some CSS to indent replies to other posts or to style them similarly to Twitter/Bluesky/Threads replies, but that quickly turns into a nightmare layout-wise. Naively indenting every reply results in terrible layouts as well. Julian’s implementation does handle some amount of threading, so perhaps I could revisit this and choose to just support one nested level for replies.
Reduce links out to make it feel more integrated: instead of just always linking to the commenter’s profile, I could use the data already fetched by the Mastodon API to do something custom like a profile card when tapping or hovering the avatar. This could provide a commenter’s header image, bio, verified links, etc. in a nice digestable format instead of requiring people to follow links. Similarly, I wonder if I could use the Mastodon API to list people who fave’d a post locally/inline, instead of hackily linking to the /favourites URL like now? It’d be neat to have the little overlapping avatars for faves, anyway.
Auto-post to Mastodon with the API?? This would be the dream: write a blog post, publish it, then CI actually handles posting to Mastodon on my behalf, logs the resulting post ID, and makes comments appear automatically. Hmm… 🤔️
Make reusable! Right now this is somewhat reusable by others with static sites, but I know there are some weird me-isms included (like hardcoding my instance). It would be great to make this even more reusable by others.

Did I Miss Anything?

Okay, you got this far, so you’re dedicated. Let me know if you notice any glaring issues, have a brilliant idea, or have any kind of feedback for me by replying below. After all, dog food is the best food!

Give your SVGs light/dark style support

Fri, 30 Jun 2023 00:00:00 +0000

I’ve recently been contributing to Flathub and updating my own website a bit, and I found myself wanting to recolor SVGs for light and dark style support. Let’s look at some examples:

Inline SVG

When using an inline SVG (including it directly in the DOM), I still recommend using your site or page’s CSS to style your icons.

An SVG icon should look something like this, with the actual path data in the d attribute:

<svg>
  <path d="…" />
</svg>

You’ll want to make sure the SVG file doesn’t have its own styling, as that can override your page’s styles depending on specificity—it follows the “cascading” part of CSS, after all. Then just treat it like any other part of your page, remembering that paths use the fill property (instead of the color or background as you might expect).

.example svg path {
  fill: #f00;
}

Inline SVGs can inherit styles like any other element, so I always recommend specifying both color and fill anywhere you want to set the foreground color on your site, so your icons pick up the text color automatically. So for your CSS:

svg path {
  fill: inherit;
}

.example-1 {
  color: red;
  fill: red;
}

And then on your page:

<div class="example-1">
  <svg>
    <path d="…" />
  </svg>
  Some text
</div>

Result:

Some text

And as you might expect, the inline SVG will follow your page or site’s media queries for dark style support:

.example-2 {
  color: maroon;
  fill: maroon;
}

@media (prefers-color-scheme: dark) {
  .example-2 {
    color: pink;
    fill: pink;
  }
}

Result (go ahead and try toggling your OS/browser’s dark style preference!):

Some text

This is how I use SVGs if I can, as you get more flexibility over the styling, and can do things like changing the color on hover (e.g. for SVGs in a link). That all makes sense because the SVG is directly in the DOM and thus can be treated like any other element. But sometimes you aren’t including the SVG inline—what then?

`<img />` or CSS background image

When you use an SVG in an <img /> tag or as a background image in CSS, it doesn’t follow the CSS rules given to DOM elements—the SVG and thus its included <path>s are not actually in the DOM. In this case, if you control the SVG file I recommend using a <style> element in the SVG itself! This is where it gets really cool: you can use media queries directly in the SVG:

<svg>
  <path d="…" />
  <style>
    path { fill: #273445 }

    @media (prefers-color-scheme: dark) {
      path { fill: #fafafa }
    }
  </style>
</svg>

Result (toggle your browser’s dark style):

This does not allow you to dynamically recolor the SVG from your site or page’s CSS, so it has its limitations. But for brand icons where you want a light and a dark version, I love it.

Favicons

I discovered something thanks to my friend, GNOME designer, and Flathub brand designer Jakub Steiner: you can use a prefers-color-scheme media query directly in an SVG, and browsers will Do the Right Thing™! We are using this on the new Flathub website; go ahead and toggle your OS’s dark style preference and watch the favicon in your browser’s UI.

If you use this, make sure you provide a fallback PNG that works on both light and dark backgrounds, as not all browsers support SVG favicons; check Can I Use… for the details.

CSS filters

Another option you have when using SVGs (or really, any images) on the page is to use CSS filters in light/dark style. Depending on how you use this, it can feel a bit more hack-ish, especially if you start manipulating colors—but it works. I used this on my Star Wars: Andor page for the logo:

@media (prefers-color-scheme: light) {
  .example-4 img {
    filter: 
      brightness(0) 
      invert(14%) 
      sepia(43%) 
      saturate(4969%) 
      hue-rotate(343deg) 
      brightness(89%) 
      contrast(107%);
  }
}

As you can see, the resulting filters are really messy, and it’s impossible to tell what it’s going to look like by reading it, which I don’t love. You can use an online color to CSS filter converter to help compute the filters, as well.

Result (toggle your browser’s dark style):

Thanks for reading!

I hope this helps someone out there on the Internet, even if it’s just me the next time I go to manipulate SVGs. :)

Accent Colors: A Proposal for GNOME

Mon, 26 Jun 2023 00:00:00 +0000

If you’ve been following GNOME development over the past few years you may be familiar with discussions around accent colors. Specifically, could GNOME support some nice user expression upstream while enabling downstream distributions to differentiate themselves—all while considering the wants and needs of the expanding app developer community?

I’m happy to report that we* now have a proposal and some prototype work of how to solve this complex request. Before we get into implementation details, let’s talk about the approaches we considered and how we arrived with this proposal.

When solving a complex design problem, you have to consider the stakeholders. Of course it’s easy to think of yourself (or whatever group you’re contributing to) as the sole stakeholder, but—especially with a space as complicated as FreeDesktop—there are several other parties involved.

When I contributed to designing the FreeDesktop color scheme preference (enabling the system-wide dark style preference) I was initially concerned about elementary OS and its users, but also actively engaged GNOME contributors, app developers, and other FreeDesktop platforms to get their input and ensure the spec could work for them. The reality is that this sort of feature only really works for users if it works for most of their apps, not just the handful they use that were designed explicitly for their corner of the wider ecosystem. As a result, the FreeDesktop color scheme spec is implemented across elementary OS, KDE, GNOME, and their ecosystems—including major cross-platform apps from large ISVs like Mozilla Firefox, Google Chrome, Brave Browser, and Microsoft Edge.

We’re doing our best to take the same approach with accent colors.

The Stakeholders
Possible Accent Color Approaches
Proposal
GNOME Design Considerations
Prototype Progress
Next Steps for GNOME Design
Thanks for Reading!

The Stakeholders

For accent colors, we’ve specifically identified the following stakeholders based on extensive discussions and experience in the space:

Downstream distributions: Ubuntu, Fedora, Vanilla OS, etc.
FreeDesktop platforms: GNOME, elementary OS/Pantheon, KDE, etc.
App developers: those making apps for GNOME Circle, KDE, elementary AppCenter, and cross-desktop
End users: people using the thing!

Downstream distributions have expressed the want to brand their experience via the default look and feel. Some distros like Ubuntu have done this with a different system stylesheet since the very beginning, while others like Fedora take more of a light-touch approach with wallpapers and logos in spots provided by the GNOME desktop. Distributions see their role as being close to end users and providing an experience they believe those users will want, and will recognize when they see it across the room or on the big screen.

FreeDesktop platforms want to create what they believe is the best ecosystem of apps and desktop experience. This means shipping features their users want, but also cooperating in ensuring the different platforms remain interoperable with one another. We also have to consider accessibility and maintainability of the platforms as a whole, and how different features are used by different downstreams.

App developers want to design and make apps that look and work how they expect across supported platforms. They might want their app to look exactly the same across Ubuntu, elementary OS, and KDE, or they might want it to adapt to each platform in some way they define—but either way, it should be easy to achieve.

End users want apps that work on their platform of choice, and if possible look and feel native—though that’s a secondary concern to the app being usable in the first place. They also want their environment to look and feel like their own, whether for aesthetic or accessibility concerns, e.g. by setting a wallpaper, a light or dark style, a font size, etc.

Possible Accent Color Approaches

When thinking through how we could approach this as a generic FreeDesktop spec, we came up with three potential approaches that could, in theory, work. Each has trade-offs.

1. Arbitrary Color

A naive approach would be to enable the system (e.g. a distributor or user) to define an arbitrary accent color, and then toolkits would be expected to just… use that. This would theoretically provide the most flexibility for end users and distributions, but it falls apart.

From the GNOME/Libadwaita side, we already support setting arbitrary accent colors from the app developer side, where the app developer is expected to design and test their app to work or provide custom CSS to expand upon that. However, there’s no simple way the system setting any potential arbitrary color would work for app developers, as it would mean developers can no longer use accent colors in interesting ways with guarantees of contrast and thus accessibility—plus Libadwaita requires a set of colors for different contexts (background and foreground, light style and dark style), not just a single base color.

Libadwaita (and all toolkits) would need to not just accept the color as-is, but perform some amount of complicated and ultimately subjective transforms on the color to derive an accent palette that can then be used by apps. This might sound feasible, but it really falls apart when the provided color is gray, yellow, brown, or any number of other shades of colors. An implementation would need to algorithmically perform subjective color science like hue-rotating certain colors in certain directions and other colors in other directions when used as shadows or highlights, determine contrasting colors for the various contexts accents are used like text-on-background or icons-on-views, and all in both light and dark style variants, etc. while ensuring the colors never look plain… ugly (which again, is subjective). It’s very complex and hand-wavy work and frankly seems like it would be extraordinarily over-engineered for a result that wouldn’t even spit out the original color that was chosen in the first place.

Different toolkits would inevitably use different color science and subjective implementations, resulting in mismatched colors across apps as well—if you chose Ubuntu orange, for example, there’s no guarantee that actual exact color would even appear anywhere in the UI—but some possible muddied or hue-shifted version could. It’s not exactly on-brand in that way.

However, this is the most flexible option and puts the complexity in the toolkits instead of in the spec.

2. (or 1b.) Nearest Accent

A different solution to (or variation on) the first approach would be to define the spec as accepting an arbitrary color, but then letting the toolkit (or in this case, Libadwaita) algorithmically choose the “nearest” accent color from its existing palette. This approach could offer toolkits the most flexibility (as they’d need to only support a limited number of known colors), but it could have the same sort of end result problem as the first option. It would be up to the individual platforms to decide how to expose this to users, whether they expose a full color picker, or just some predefined values.

An issue we could see is that color palettes between platforms differ, for example. If someone chooses a nice deep teal color for their accent, it might map to elementary’s lighter “Mint” accent color or even GNOME’s (slightly blue-leaning) green color. A GNOME/Libadwaita app would use one color while an app using the Ubuntu stylesheet might map to any of four different green-ish accent options.

There’s potential for unpredictability and inconsistency, though it’s not quite as complex as the first approach needing to support any color in the toolkits.

3. Named Colors

The last approach continues the line of thinking from the previous two: if you can’t perform a bunch of color science on an arbitrary color, and it’s not ideal to map an arbitrary color to a set of potential accent colors, what if you remove the arbitrary part, and make it more-well-defined? That’s what Named Colors attempts to solve.

In this approach, the spec would define a set of named colors, like “red,” “orange, “yellow,” etc. that platforms could commit to supporting. The exact values of these colors are intentionally not defined in the spec, enabling the toolkit to take that color and present something from its own palette that fits. Like the nearest accent approach, it eases the burden a bit from implementors as they would only need to test against a defined set of colors, and it allows for expression in each toolkit or stylesheet’s own interpretation of a color. It also codifies setting user expectations of not necessarily picking “I want this exact shade of blurple,” but more, “I chose the ‘green’ option, so apps are using green accents!”

We do have a great starting point for colors that’s been shipping to users for years: elementary OS! They have defined their own branded versions of red, orange, yellow, green, mint, blue, purple, pink, brown, and slate (a chromatic gray). These ten colors seem like an excellent jumping off point and could be adopted as Named Colors in the FreeDesktop spec. This would give a clear migration path for elementary OS, covers the spectrum of GNOME accent colors, and nearly matches the options in KDE today. Ubuntu specifically would likely need to change or remove a single accent color option they’re shipping today.

The risks of this approach center around agreeing on that set of named colors in the first place—for example, Ubuntu currently ships accent color options that don’t neatly fit into a generic color spectrum, with several different shades of green. Some desktops that want to offer arbitrary colors might feel limited by this implementation, and you could still have inconsistency where different toolkits interpret named colors in ways unexpected by the user. There are also open questions around appending the spec with new colors in the future, should people want to.

Proposal

Named Colors was our preferred approach initially, as it seemed to be the least-bad and least complex option for GNOME and elementary OS. However, it didn’t really align with the direction for KDE, COSMIC, or tauOS contributors who were proposing the FreeDesktop portal implementation in the first place.

Given the above—and after literally a years-long process with multiple hours-long discussions and hundreds of comments from across the ecosystem—we have decided to back Arbitrary Color for the FreeDesktop spec, proposed to be implemented as Nearest Accent for GNOME/Libadwaita (and likely elementary OS as well). While a bit more complex for GNOME to implement than strict Named Colors, it does seem to offer a balance of flexibility for platforms, distribution differentiation, predictability and testability for GNOME-targeting app devs, and lower implementation complexity for GNOME than complete Arbitrary Colors—all while still enabling a lot of end user expression.

Given an arbitrary color, platforms (e.g. via the toolkit or a platform library) would need to derive their palette that can be used by that platform’s apps. The exact implementation is up to each platform, but essentially if the FreeDesktop Portal says the accent color is #f00, platforms should take that and decide how to use it in a way that makes sense for them.

Adwaita Demo using a prototype pink accent color

For GNOME, we envision mapping it to the nearest accent color—perhaps including some additions inspired from the elementary palette, like pink and slate; so if the portal says #f00, we’d match that to our existing red palette. elementary OS could do something similar by having Granite automatically set the closest-matching stylesheet variant, similar to how they handle wallpaper-based accent colors today. In KDE (please excuse my limited knowledge of the inner workings!), I believe the chosen color could be given directly to QPalette. On Ubuntu, GNOME apps could map to the nearest palette color; the palette could be defined in the Yaru stylesheet as it is today. Flutter apps could potentially use an accent color directly e.g. to seed its Material Design 3 (“Material You”) support.

In the future, if some sufficiently talented and motivated developer wanted to try to add arbitrary color support to GNOME in a way that ensures both accessibility and aesthetic quality, that could theoretically be possible—or it could even be implemented as a third-party library on top of GTK; the FreeDesktop spec wouldn’t limit how the accent color could be used down the road.

GNOME Design Considerations

Let’s get into GNOME and Libadwaita specifics; if you were just here for the FreeDesktop stuff, that’s a wrap, and thanks for reading!

First, we want to be clear: even though the FreeDesktop portal might accept and store arbitrary values, we see that as an implementation detail on GNOME desktop—we propose that the set of well-defined choices be exposed in Appearance Settings in a way similar to how elementary OS and Ubuntu display them today.

While thinking through this proposal for GNOME, some of the other biggest considerations were:

Not adding an undue burden for app developers
How to ensure we retain semantic color (e.g. for destructive actions or warnings)
How it looks across the platform, e.g. in places like suggested actions in dialogs
How we would implement it in Shell
How downstream distributors could use this for differentiation

App Developers

For app developers, an important thing to remember is that they’re always in control of how their app works. While Libadwaita could support FreeDesktop accent colors by default, a developer can always override the accent color used by their app, as they see fit for their design and brand—just like today with the default blue accent color.

Calendar with a prototype red accent color

This is identical to how the FreeDesktop color scheme preference was implemented in Libadwaita for the dark style. If a developer wants to support accent colors, they would need to test with the colors in the GNOME palette—but by following best practices around color usage, they can be fairly confident the palette will just work for them by default.

Semantic Color

While color should never be used as the only way to understand context (due to color blindness, inaccurate displays, and even Night Light altering visible colors), color can be used effectively to enhance the semantics of the desktop. However, this is a challenge when colors like red, yellow, and green exist in the set of potential accent colors in addition to being used semantically for things like “destructive,” “warning,” or “success.”

Clocks with a prototype accent colors and new destructive button style

elementary OS alleviates this by using a lighter tint style for accent-colored buttons, while using a more aggressively-contrasty red style for destructive actions. We actually came to align on the same (well, opposite) approach: use the selected accent color similarly to how the blue accent is used in GNOME today, but tone down and differentiate destructive actions. This is actually recommended by UX Movement precisely to avoid mistaking destructive actions as the suggested call to action—and it works well here, too.

A prototype slate accent color

Something nice about a chromatic gray “slate” accent color is that it can reduce the amount of bright, potentially-distracting accent colors throughout the OS while retaining their semantic meaning—being different and distinct from non-accent buttons, labels, icons, etc. This accent color would also make other semantic colors like destructive actions stand out even more, which could be seen as an accessibility boon.

Dialogs

For suggested actions in dialogs specifically, we had a different problem: the accent-colored text of red, pink, and orange could be very similar to the destructive red text, making it unclear which is the suggested and which is the destructive action. We could just make the suggestion action an accent background, but we did this in Adwaita for GTK3 and didn’t love it—it makes the dialog feel very unbalanced and overly aggressive.

Left: Accent-colored text | Right: Accent-colored background

We considered making the suggested action just a bit more prominent—using an elementary-like tint in this context—while keeping the destructive action more toned down. This is what we currently do for the hover styles, so we’d need to adapt those a bit, too.

Suggested action hover styles

However, this still didn’t feel right with colors close to the destructive style because it matches the new proposed destructive style elsewhere, leading to potential confusion.

Your browser does not support the video tag. Download.

While thinking it through and playing with different styles, we thought: what if we simplify the styling in dialogs a bit, keeping the general layout, but treating buttons more similarly to everywhere else?

Left: New proposed dialog style | Right: Adapted to vertical buttons

Once we started playing with this, it just felt right. It feels a bit simpler and more modern than the old GTK3 styles or the current GTK4 styles while not fundamentally changing the layout. This has been one of the more controversial proposals within the GNOME design team, though, so we’ll see if it works or if we come up with something different.

Shell

Shell uses its own toolkit, st, rather than GTK. As such, we’re working on an implementation of accent colors there, as well.

Prototype Shell support for accent color

This was actually easier than we expected it to be when we set out, and we think the results are nice!

Downstream Distribution Examples

As a fun sort of exercise, I wanted to see if—theoretically—the proposed accent colors plus the existing color scheme preference could be a tool distributions use for differentiation. Using a very early prototype of accent colors in Libadwaita, see if you can identify each distro by a screenshot of its theoretical default settings:

Reveal Spoilers

Top to bottom: Ubuntu, Pop!_OS, Fedora, Manjaro, Vanilla OS

Did you get them all? Okay, perhaps that was too easy with the wallpapers, fonts, Shell extensions, etc… but that is kind of the point! I personally would love to see distributions using well-defined preferences for their differentiation while not resorting to the nuclear option of changing the entire system stylesheet out from under third-party apps. Using the accent color instead helps ensure apps can feel more at home across distributions right out of the box while also being predictable for the app developers.

Open Questions

That just about wraps this up, but just for completeness-sake, we wanted to let you know that we do have some remaining questions that will need to be solved.

There are places in the Shell styling that use images—like checks and switches—that will either need to be ported to CSS, or (as a last resort) we’ll need to provide colored SVGs in all the accent colors.

GNOME currently has (very nice!) blue folder icons, visible in GNOME Files and the file picker. With a user-selected accent color, would we want those to follow along? Does that create a lot more work for maintaining the icon set? Is it fine if the folders are always GNOME-blue, regardless of the accent color? This is something we need to think about and discuss with the design team and icon maintainers.

The actual accent color palettes for each of the ten colors needs to be chosen, and along with that, we should probably have internal guidelines/metrics for contrast and accessibility. E.g. we need to ensure yellow is as accessible as blue, and have a measure of how we know that.

Lastly, there’s still more thought and discussion needed around semantic colors and how to ensure e.g. destructive and error states are visually distinct when using accent colors. For example, do we use different shades of the semantic colors with some of the accent colors? Do we avoid supporting a “red” accent color altogether (as a fan of red, I’m not a fan of that idea!)? Do we avoid using semantic color in most contexts altogether to allow the accent color to shine through more? These are all being discussed within GNOME, and I’m not sure where we’ll end up.

Prototype Progress

There’s an open pull request for the FreeDesktop portal we were involved in to add the tiny amount of support—and importantly, specification—needed for accent colors. We’ve also opened draft merge requests for the GNOME desktop schemas and Libadwaita which will be required to support accent colors.

We’ve proposed updates to destructive styles and message dialog styles in Libadwaita which would address some of the considerations raised above.

Finally, we’ve opened draft merge requests for GNOME Shell and GNOME Settings for accent color support to bring it all together.

Next Steps for GNOME Design

We’ve presented this proposal within the GNOME design team, and are actively working through the details to see if we can come to an agreement on the best way forward. There is still a lot of work to be done if it’s accepted, though!

We would need to update the GNOME Human Interface Guidelines to provide guidance to developers in using accent colors—including when to opt into the accent color, when to use and avoid semantic colors, and how to test against the supported accent colors. We would need to audit existing GNOME apps for color usage, e.g. in illustrations, animations, and semantic colors. For animations (like in the Mouse & Touchpad settings), we would need to update the source videos and styling to be recolorable based on the accent color.

And there are probably 100 other, smaller things I’m forgetting that would need to be done.

Thanks for Reading!

I know that was a monster of a blog post, so props for getting through it to the end. We hope this proposal makes sense and serves as a kicking-off point for a long-awaited way for users to make their desktop their own, distributions to differentiate themselves in well-defined ways, and app developers to not be overwhelmed with the implementation. 😅️ Thanks to Alice, Chris, and Jamie for their collaboration, and for future related posts, be sure to follow my blog, Alice’s blog, and Chris’ blog—or just subscribe to GNOME Planet to get it all!

And to reiterate one more time, the “we” in this blog post is inclusive of myself, Alice, Chris, and Jamie—and ultimately, I wrote this blog post, so any mistakes are my own. We’ve been involved in discussions with other folks quite a bit, but we’re the ones attaching our names to this specific proposal. :) At the same time, we can’t promise that this will be accepted or come to fruition the way we’ve mapped out—in the next GNOME release or really, ever—but we wanted to put it out there for feedback and discussion. Thanks again for reading!

3D Printing on Endless OS

Tue, 07 Mar 2023 00:00:00 +0000

I recently got a 3D printer for my birthday, and I have been absolutely loving tinkering, printing, and learning with it. There is such a wealth of openly-shared and -licensed models out there, I’ve been having fun finding things to print for myself, my friends, and especially my toddler. The best part for me, though? The fact that I can dive deep into this whole new world of 3D modeling, slicing, and printing using the computer I already have with freely-available software right in the app store I already use on Endless OS: App Center with Flathub.

I got a Creality Ender 3 v2 printer, which is to say: a popular and well-reviewed printer that didn’t break the bank. For a super quick (and over-simplified) look at the 3D printing process, there are a few steps to get from nothing to a physical 3D object in your hands:

Design a thing; this can be on a whiteboard, in a 2D design app, or whatever. The point is, you have to start with some sort of specification/measurements.
Model that thing; you have to take the idea you have and turn it into a 3D shape on the computer. You can use a modeling program like Blender if you know what you’re doing or want to use your model in different contexts, or you can use a computer-aided drawing (CAD) tool to define the shapes for your object.
Slice the model; this is the process of taking a defined 3D object and turning it into actual instructions for your specific printer, filament, etc. 3D printer companies usually offer free slicing programs designed with their own printers in mind, but it’s mostly all inter-compatible and based on the same few open source projects.
Print the model; slicing outputs a GCODE file, which is very literal instructions for your printer to follow. You have to get that GCODE file onto your printer, either with an SD card, a USB connection, or a network connection. Then it can be printed!

With all the open source software that powers 3D printing combined with the open sharing culture, you can accomplish each of these steps on Endless OS or any other Linux-based OS that has access to Flathub. Let’s look at each step and the options you have:

1. Design a thing

I love whiteboards, so I usually start there if I’m designing a new thing from scratch. I’ll sketch a few angles out until I’m confident the measurements make sense, then I’ll move on to modeling.

Inkscape

Vector Graphics Editor

However, if you’re trying to convert a 2D object into 3D, or you just want to play around in a 2D space first, I recommend Inkscape! It’s a great vector image editor, and it’s available on Flathub. You can lay things out and make sure they make sense in 2D space before moving onto the more complex 3D modeling.

Blender

Free and open source 3D creation suite

If you already live in Blender, you can of course use it to design your object from the start, as well. It’s also available on Flathub.

2. Model that thing

Modeling is my weakest point personally, as I haven’t taken the time to really learn Blender or the open source CAD tools. So for me, I only tackle simple 3D models—and I use the web-based Autodesk Tinkercad to do it.

Luckily on Endless OS you can trivially install web apps like Tinkercad from the included Chromium web browser; just hit the little “Install” button that pops up on the address bar when you’re on the site. Then Tinkercad’s icon will be added to the app grid on your home screen and you can add it to your favorites on the dash.

Web

Web browser for GNOME

GNOME Web also supports web apps, Tinkercad works there as well. If you use Google Chrome or any other browser based on Chromium, it should also have an easy to use install button. If you use Firefox, you can always use Tinkercad from in the browser itself.

FreeCAD

An open source parametric 3D CAD modeler

OpenSCAD

The Programmer’s Solid 3D CAD Modeller

If you’re more experienced (or adventurous than I am now), you can also try something like FreeCAD or OpenSCAD from Flathub—available in App Center right out of the box on Endless OS.

3. Slice the model

Slicing is the most exciting step of the process to me, if only because people keep innovating in 3D printing purely on the software side to get more speed, performance, etc. out of existing hardware—and that all happens in the slicers.

Cura

The world’s most advanced 3D printer software

Popular 3D printer companies like UltiMaker/MakerBot, Prusa Labs, and FlashForge have their slicers available on Flathub. While others might offer downloads for their software on their website, my experience has been it’s less integrated over all; I’d stick to the ones on Flathub.

PrusaSlicer

Get perfect 3D prints!

If whoever makes your printer doesn’t have a slicer on Flathub, fret not! They’re basically all inter-compatible, as the slicers are all based on the same handful of open source projects. Personally, I prefer UltiMaker Cura, and I could even add my Creality-brand Ender 3 v2 from in Cura’s UI with all the right preset values. Some people prefer PrusaSlicer, and it’s a similar story there.

FlashPrint

Slicer for the FlashForge 3D printers

4. Print the model

The simplest/most old-school way of printing is to save your sliced GCODE file out to a microSD card, eject it, then stick it in your printer, and use your printer’s physical screen and wheel to select the print file. And that will work just fine! You can also connect your printer over USB and print directly from your slicing software.

If you want to learn more about how your model will print before actually printing, you can use your slicer or a separate program to preview the GCODE file. While Cura has a preview built in, sometimes I like using PrusaSlicer’s included GCODE viewer app (installed alongside PrusaSlicer) to inspect a specific GCODE file, too.

If you really want to go all out and have a spare Raspberry Pi, you can install OctoPrint with the OctoPi OS, and print to, monitor, and control your printer remotely. I won’t get into all the details, but you can get started with the official Raspberry Pi Imager by navigating to install an “other specific-purpose OS,” “3D printing,” and then “OctoPi.”

Raspberry Pi Imager

Raspberry Pi imaging utility

Hopefully these apps and tips are useful to you! I’ve been super happy with the experience of designing, modeling, slicing, and printing all entirely from Endless OS—and if you have access to Flathub on your OS of choice, you can do it, too!

Endless OS Foundation at Ubuntu Summit 2022

Mon, 28 Nov 2022 00:00:00 +0000

Cassidy James Blaede

How and Why to Get Verified on Mastodon

Okay, but how?

Technical details

Read more

Use Commit from Flatpak Both Inside and Outside of Toolbx

Update: Just Install Flatpak in the Toolbx Container!

Edit the Git Config (Outdated!)

How it works

Endless ♥ GNOME at GUADEC 2023

Advisory Board Meeting

Talks

1. Design

2. Sharing Knowledge

3. Technical

Working Sessions

Read More

What is GNOME?

GNOME Advisory Board

I’m back from GUADEC 2023

GNOME Advisory Board

Accessibility

Member Participation

Travel Sponsorship & Hackfest Locations

Reproducibility of Flatpaks

Upstreaming More than Code

My Talks

How to Make a Delightful App Listing

GNOME Design: State of the Union

What is the GNOME Advisory Board?

New Users for GNOME

Hallway Chats

GUADEC 2024: Denver, CO, USA 🎉️

The Can of Worms: Metrics

Guerrilla User Testing

Stars & Thumbs: Ratings & Reviews

Summary & Thanks

Stars & Thumbs

What’s wrong with five-star ratings?

What’s wrong with written reviews?

What would be better?

What about the ODRS?

Toot toot! Mastodon-powered Blog Comments

Inspiration

First Iteration

Oops, Emoji and Avatars 🤦️

Clean Up

Design Iteration

What’s Next

Did I Miss Anything?

Give your SVGs light/dark style support

Inline SVG

<img /> or CSS background image

Favicons

CSS filters

Thanks for reading!

Accent Colors: A Proposal for GNOME

The Stakeholders

Possible Accent Color Approaches

1. Arbitrary Color

2. (or 1b.) Nearest Accent

3. Named Colors

Proposal

GNOME Design Considerations

App Developers

Semantic Color

Dialogs

Shell

Downstream Distribution Examples

Open Questions

Prototype Progress

Next Steps for GNOME Design

Thanks for Reading!

3D Printing on Endless OS

1. Design a thing

2. Model that thing

3. Slice the model

4. Print the model

Endless OS Foundation at Ubuntu Summit 2022

`<img />` or CSS background image