This October I attended the GNOME Shell Hackfest 2019 in the Netherlands. It was originally just planned as a small hackfest for core Shell developers, but then us designers decided to crash the party and it became a pretty big thing. In the end we were about 15 people from lots of different companies, including Red Hat, Endless, Purism, and Canonical. The venue was the Revspace hackerspace in Leidschendam, which is somewhere between the Hague and Leiden.
The venue was very cool, with plenty of hackerspace-y gadgets and a room with couches and a whiteboard, which was perfect for the design team’s planning sessions.
Allan, Jakub, and I were primarily there to make progress on some long-standing issues with GNOME Shell, such as new user onboarding, the app grid, and the spatial model of the Shell. We’ve wanted to address many of these things for a long time (in fact, some of them were already discussed at the London hackfest 2 years ago). In the weeks leading up to the hackfest we had already been working on this (together with Sam Hewitt who couldn’t make it to the hackfest unfortunately), preparing a number of concepts to be worked out in more detail.
At the hackfest we made these concepts more concrete, worked on mockups and prototypes, and discussed them with Shell developers. It’s still early days for all of this, but we’re very excited about sharing it more widely soon.
We also worked on a number of other things, such as the new lock screen design, which Georges has started to implement, prettier Shell dialogs, and some changes to the system status menu.
Thanks to Carlos Garnacho and Hans de Goede for organizing, Revspace for hosting us, and the GNOME Foundation for sponsoring my travel and accommodation!
A few weeks ago I attended the Linux App Summit in Barcelona. I arrived very late on Monday night by bus, after almost not making it to Spain that day (my train from Paris stopped in Montpellier due to the rails being destroyed by a storm and the highway was blocked by a protest). Adrien, Julian and I had a shared accommodation, which conveniently was just down the street from the venue.
On Tuesday and Wednesday I attended some talks, but was mostly focused on preparing the talk Jordan and I had on Wednesday afternoon. Talks with multiple presenters are always tough, especially if there’s not much time for practicing, but I think it went okay given the circumstances. There’s a recording on Youtube in the day 2 live stream video.
Over the course of the conference I had lots of good conversations about the state of free software with people from GNOME and other projects. In some areas it’s exciting how far we’ve come (e.g. Flatpak), but in others it’s frustrating how little has changed over the past decades (e.g. fragmentation).
Adrien gave a talk about how GNOME Mobile slowly materialized over the past two years, especially on the application and toolkit side. I was also happy to see not one but two talks (by Florian and Daniel) about how very very dead the Systray is, without anyone really disagreeing. It’s nice to see most people maybe finally on the same page on this. Now we just need Ubuntu to stop shipping a certain extension… ;)
Later in the week I also managed to do a bit of hacking. Now that the GNOME OS images can get updates the main missing piece is an installer, so we discussed that with Javier and Valentin from Codethink. I was also very happy to meet Manuel (the maintainer of UberWriter) in person, and talk about some cool future stuff for that app.
Overall the conference was great! Because there were so many GNOME friends it almost felt like a second GUADEC, but I also met many cool new people. Thanks to the organizers for putting together a great event, to Purism for paying for our accommodation, and the GNOME Foundation for covering my travel.
On Sunday I gave a talk about adaptive patterns and making GNOME apps that work well across form factors, from phones all the way to desktops. There is a video of my talk, and the slides are here.
I spent most of Monday in the GTK BoF, where we discussed (among other things) menus, dark styles, upstreaming Libhandy widgets, and a new pattern library for GNOME. Since there were so many app maintainers in the room, we inevitably also talked about random things in various apps, such as the Mouse/Touchpad settings, the Display settings, and Evince.
One of the things we’ve talked a lot about recently on the GNOME design team is making it easier to implement our UI patterns.
Many of the platform widgets are in GTK directly, which makes them easy to use, but hard to iterate on since we don’t want to break API there. Other things are in third party libraries, such as Libzazzle or Libhandy, but those are not “official”, and app developers have to know about them. Other widgets are just copy-pasted between apps, or completely custom everywhere. This makes it needlessly complex to follow our design guidelines, and has resulted in inconsistency in how different apps implement patterns. One idea to fix this was to have a separate official pattern library, and a new widget factory that showcases these patterns. This library could move significantly faster than GTK, and its release cycle could be better aligned with GNOME.
On a parallel track we’ve also been discussing for some time (both within Purism and GNOME) how best to upstream the widgets in Libhandy. Some of the things in there are fairly generic and should go into GTK (e.g. HdyColumn), but since GTK3 is stable we can’t upstream them directly before GTK4. Other widgets are more GNOME-specific (e.g. HdyPreferencesWindow), and would ideally be able to move at a faster speed, so a separate library would be a better fit.
We discussed this at length over the course of GUADEC, and this seems like the most likely way forward: For GTK4 we’ll have a separate GNOME pattern library outside GTK, which contains “official” widgets implementing patterns from the GNOME HIG. Some of these widgets would come from currently separate libraries such as Libhandy, while others might be moved out of GTK (e.g. GtkShortcutsWindow). The new library would have a clearly defined inclusion/review process for new widgets, and would be kept in sync with the HIG.
For GTK3 it seems like the path of least resistance is to just adopt Libhandy upstream, after removing a few things that are too specific or no longer needed (e.g. HdyDialer and HdyArrows), and instituting the same review process for new widgets as for the GTK4 library.
It’s still early days for all of this, but this is the current consensus as I understood it from various conversations at GUADEC.
Tuesday: Vendor Themes
On Tuesday we had a BoF with various interested parties (including design team, distros, and app developers) to discuss a possible future Vendor Styles API.
GNOME does not currently support making changes to the platform stylesheet/icons, and app developers build their apps with this in mind. Changing these means ripping out API from under developers, which often results in apps looking broken. Some downstreams are doing it however, which is a problem for our overall platform developer story.
The good news is that some of these downstreams realize this is an issue, and are willing to work upstream to improve the situation. During the BoF we discussed the motivations for changing the platform style, and the kinds of changes they’re interested in. We broadly categorized these changes in 3 groups:
“Accent Colors”: Making it possible to change some UI colors (at both the system and app level) without breaking things
“Upstreamable”: Stylistic changes which upstream might be interested in (such as rounded menus, flatter checkboxes, etc.)
“Here Be Dragons”: Anything that touches widget sizing, margins, and the like (because changes to these break apps the hardest)
We spent most of the BoF discussing the “Accent Colors” category, because that’s where most of the low-hanging fruit is. The main things we need to figure out for this are
Which and how many variables do we want (and can realistically be supported)?
How would app developers test for different color combinations? What kind of tooling do we need to make that easier?
How do we ensure good contrast?
Can colors be set arbitrarily or are there constraints?
How are the colors set? What should that API look like?
Could we do this for GTK3 given that it’s stable? Would it be GTK4 only?
How would we handle Appstream screenshots looking different from the app once installed?
We discussed most of these questions in some detail, but all of this needs a lot more work before we can definitively say if and how we’ll go forward with it. At the BoF we outlined some first steps in this direction, namely documenting the current set of color variables within Adwaita, and looking at what other variables we might need. For more on this read the Discourse topic.
Once all of that is figured out though, there are some pretty exciting things on the horizon. For example, some third party app developers would like to use color in more interesting ways in their apps, but the way Adwaita is set up, this is currently not easy. If done right, making Adwaita more flexible would not only allow for vendor styles, but also empower app developers to do more cool stuff.
Another potential benefit is that a lot of the work around ensuring contrast on different background colors, better documentation around color variables, etc. would be needed anyway if we get a global “prefer dark” preference. If and when that happens, it will be a much easier transition if we’ve already worked out some of these things.
Software Freedom/Ethics Ratings
I also sat down with François on Tuesday to discuss the software ethics rating system we’ve been thinking about for a while. The goal of this initiative is to make the value of software freedom more tangible to people when they’re looking for applications in an app store (e.g. “this app won’t leak your data” instead of “this app is licensed GPLv3+”). On the developer side, the goal is to encourage ethical practices (e.g. encryption) and discourage unethical ones (e.g. tracking). So far we’ve mostly discussed this idea internally at Purism, but as with everything else we’d ideally want it to be a ecosystem-wide thing others can benefit from rather than something we do downstream.
There’s plenty of relevant art for nudging people towards more ethical choices. In other industries there are many examples for both info badges/warnings (e.g. food labels with nutritional information) and indirect incentives (e.g. higher taxes on unhealthy foods). In the software realm, interesting examples include FDroid’s anti-feature warnings, and Terms of Service; Didn’t Read, which has curated summaries and letter grades.
In our case we have limited options in the short term, because we have to deal with multiple different software sources (someone might have apps from a distribution repo, multiple Flatpak remotes, and who knows what else). In addition to that, giving a simple answer to the question “Is this app safe to use?” is often complicated and somewhat subjective. For example, it’s impossible to build an email client that doesn’t send unencrypted messages, or an RSS app that doesn’t connect to servers which could track you. Does that mean we should mark these apps as insecure/unethical?
There currently isn’t a trusted entity which could make the complex value judgements that are involved with deciding whether applications are ethical at scale, for many different software sources.
My feeling is that instead of coming up with a complicated process that may or may not work the way we expect it to, it would be good to first experiment with some leaner solutions and test the general approach. A potential first step we discussed could be something similar to the anti-features on FDroid, perhaps tied in with the existing Appstream metadata we have. In combination with Flatpak sandboxing/permissions there are a number of cases where you can actually say with relative certainty that an app is safe/ethical without complicated judgement calls (e.g. fully sandboxed apps without network access). If we can find a few such categories of apps this could be a good starting point, to see if this helps us reach our goals.
Obviously this needs a lot more work, but I’m hoping to do at least some mockups/prototypes soon. Also, I haven’t talked to a ton of people about this so far, but I imagine other projects with a focus in software freedom/ethics might be interested in this problem as well. If you work on such a project and have ideas/comments/concerns, let’s chat!
Wednesday: Beach BoF!
After 5 intense days of GUADEC and BoFs we had a more chill day at the beach on Wednesday. We still had lots of productive discussions about GNOME stuff there of course, maybe even better in some ways because we didn’t have our laptops distracting us :)
I’d like to thank the organizers for putting together an awesome GUADEC, all of my GNOME friends old and new for being there, and the GNOME Foundation for sponsoring my attendance!
So you’ve decided to make a new app for GNOME, and designed a great interface for it. Now you want to start building it, so you open Gitlab to create a new repository. But then, oh no — it wants a name for the repository. Existential dread sets in.
Naming things is hard, and naming user-facing things is even more so. App names are read, pronounced, heard, and remembered by lots of people. The name is, along with the icon, the most important identifier for your project. With this tutorial I hope to make finding a great name for your app a bit easier.
“An application’s name is vital. It is what users will be first exposed to, and will help them decide whether they want to use an application or not. It is a major part of your application’s public face.”
Finding a good name is not always easy, but putting in a bit of effort up-front is worth it, because renaming the app once it’s established is much harder and messier.
A good name should:
Consist of one or two simple nouns
Be related to the app’s domain (e.g. Celluloid for a video app)
Be short (less than 15 characters)
Be easy to pronounce
Make it easy to come up with a good icon (e.g. by referencing a physical object that could be used as the icon)
Use title case (e.g. Icon Preview instead of iconPreview)
A good name should avoid:
Using trademarks or names of other projects (e.g. GNOME MPV)
Having a “G” prefix (e.g. GParted)
Overly complicated names and acronyms (e.g. GIMP)
Puns and inside jokes (e.g. D-Feet)
Non-standard punctuation or whitespace (e.g. UberWriter)
Made-up words or word combinations (e.g. Inkscape)
Over the years I’ve been involved with naming a lot of projects, and at this point I have a process which consistently produces pretty good results. It more or less goes like this:
Write down all the words related to the app’s domain you can think of
Do a thesaurus search for some of those words to find even more related words
When you have about 15, start picking out some of the best-sounding ones, and look at their other qualities. Are they too long? Easy enough to pronounce? Do they have any unintended negative connotations?
Once you have picked a handful of favorites, do a quick check to see if the names are already taken
Among the ones not taken, pick your favorite one
Of course, when naming an app which is part of GNOME itself, the rules are a little different because these apps have completely generic names describing their function or the type content they show (e.g. Files, Image Viewer, Fonts, Music). That’s a much more rare (and usually easier) case though, so in this tutorial I’ll focus on independent third-party apps.
Let’s look at a real-world example of this process. A few months ago I was involved in renaming an internet radio app. At the time it was called Gradio, which was a bad name for many of the reasons mentioned above, and we wanted a nicer name for the new, completely rewritten version of the app.
So, internet radio. What words immediately come to mind?
These are pretty generic, so let’s branch out a bit. As with most digital technologies it’s hard to find nice metaphors, but we can make use of the analog predecessor to it (i.e. analog radio). Are there physical objects related to that which we could use?
Maybe something related to analog radio technology?
What about names of people who worked on the technology?
Now that we have a few words to start with, let’s plug them into a thesaurus and see if there are any good related words. This is usually pretty hit or miss, as most related words you’ll find will not be relevant to the domain or make sense as names. However, after a few searches I always find a few good options that I didn’t think of before.
Update: I recently found another good website to find related words, appropriately named relatedwords.org.
Here are a few additional words from thesaurus searches:
In this particular case we also had a brainstorming session on Matrix with a group of people from the community, which produced a few more options:
3. Pick the best ones
Now we have about 20 words, which is a good place to stop brainstorming and start looking at which ones would make good names.
This process is not very scientific, just look at each word and imagine it as the name of the app. In particular, pay attention to the length of the name, ease of pronunciation, and whether it sounds nice.
In this case, some of my favorites are:
They’re all relatively short, easy to pronounce, and sound good as app names. The main question at this point is whether we can use them or if they’re already taken.
4. Check if they’re taken
I usually start off by searching directly on Github, to see if there are other FOSS projects already using the name. If I don’t find anything there, I search for the name on on Duckduckgo, adding “app” or “open source”.
In many cases you’ll find something somewhere using the name already. That doesn’t necessarily have to be a problem if it’s an app/project/company in a different domain, but it’s good to avoid large projects and companies.
In this case, it turns out “Transistor” is already a radio app for Android. Since it’s an app doing something very similar, people might think our radio app is affiliated with this project, which we want to avoid.
“Hertz” is the name of a car rental service. It’s a pretty big company, so best to stay away from that as well.
“Spectrum” is already the name of a forum software (which looks really cool btw). The potential for confusion is low, but the project looks well-established with 6000+ stars on Github, so not a great option.
“Shortwave” is used by a bookmarking app, and there are some search results related to actual analog radio software, but nothing that looks big or problematic. This seems like a viable option.
5. Pick a winner
At this point you probably already know which of the viable options you like best, so just go ahead and make it official. In our example,”Shortwave” won because it was short but distinct-sounding, related to the domain, a pronounceable English word, and not taken by any major projects or companies.
If you find that all your favorites are taken, go back to the first steps and do some more brainstorming. The perfect name for your app is out there, and you’ll find it!
Bonus: Good Examples
For inspiration, here are some examples of well-named third party apps in the GNOME ecosystem, and what makes their names great:
Fragments — A torrent app. The name is great because it’s unique among torrent app names (which usually reference water, e.g. Deluge), yet still clearly connected to the domain (BitTorrent splits up files into lots of tiny parts and sends them in random order).
Peek — A GIF screen recorder. The name is very appropriate since the app is for making short recordings of small parts of the screen. The app feels small, quick, and frictionless, which the name perfectly encapsulates.
Teleport — Sends files across the local network. The idea behind Teleport is to make sending a file across the local network effortless compared to other methods, such as using web services or USB drives. Using a sci-fi metaphor in the name lends itself well to that.
So you’re excited about the Librem 5 and GNOME going mobile, and want to start building an app for it. Of course, the first step is to design your app. This can seem quite challenging if you’re just starting out with a new platform, but fear not! In this blog post I’ll walk you through some of the most important UI patterns, and the process of going from idea to mockups step by step. Throughout this I’ll be using a read-it-later app as an example.
The GNOME design philosophy
Before starting to design for a platform, it’s good to familiarize yourself with the design philosophy of the platform. The GNOME Human Interface Guidelines have a “design principles” page which I encourage you to read in its entirety, but will paraphrase a few highlights from here:
Simplicity and Focus — Make sure you have clear goals for your app from the outset, and focus on those. Often it’s better to make a separate application to cover an additional use case rather than cramming too many things into one app (e.g. video podcasts are different enough from audio podcasts to be better off as their own app).
Search and Undo — If there are large amounts of content in your app, provide full-text search to make it easy to find things. Be forgiving about people making mistakes by making it hard to lose data, and never use a warning when you mean undo.
Avoid Preferences — “Just adding an option” often seems like a quick fix, but in most cases you’re just treating symptoms rather than the root cause. It’s better to figure out what that root cause is and fix the problem for everyone, rather than papering over the cracks with a preference. I highly recommend this article by Havoc Pennington on the topic.
Now that we’re full of high-minded ideals, let’s jump into the actual design process. Let’s design a great read-it-later app.
We will follow the GNOME design process, which primarily consists of three steps (plus iterations):
Define goals and non-goals for your app
Collect relevant art, i.e. examples of similar apps to borrow ideas from
Make sketches/mockups of the main views and user flows
1. Define Goals
The app we’re designing is going to be a native client for read-it-later web services (such as Pocket). These services allow you to store articles and other web pages that you are interested in, but don’t have time to read right now. That way you can catch up on all the stuff you saved later on, when you have more time. As such, our primary goals are:
Listing your saved articles
Providing a great, focused experience for reading articles in the app
Helping you actually catch up with your reading list
Storing articles offline, so they can be read without a network connection
Some non-goals, i.e. things that are out of scope for this application:
2. Relevant Art
The next step is to find some examples of existing apps that do similar things. It’s good to look at how other people have solved the same problems, what they do well, and what could be improved before jumping into designing a new app.
So let’s check out the competition:
Pocket on Android has a lot of features, and a pretty complicated interface. It has lots of categories, social features, a discover section, text-to-speech, and much more. I’ve personally never used most of these features, and they make the app feel quite cluttered. In my experience Pocket is also not very good at helping me get through the list of things I’ve already saved. It feels like it mostly wants me to discover new things to save (and then not read).
Clearly there are some lessons to be learned here for our app.
I’ve never used the app myself, but judging from screenshots, Instapaper’s UI feels a lot saner and more focused than Pocket. I also really like the rich article previews in the list view and the nice typography.
Wallabag is a self-hosted alternative to Pocket and Instapaper. This Android client for it (also called Wallabag) is not very sophisticated UI-wise, but it’s a good example of a very simple native client for this kind of service.
Structurally, these apps are all quite similar: a main view with a list of articles, and an article view that just displays the article in a clean, readable format.
Depending on the service, there are multiple lists for different types of articles such as Archive, Highlights, Favorites, Notes, etc. To keep things simple, and because we’re targeting Wallabag first and foremost (since it’s the only self-hosted service), we’re going with only three categories: Unread, Archive, and Favorites.
This means that our application is going to have four main screens we need to design: the three article categories mentioned above plus a reader view, which displays the article content.
Now that we have a basic idea of the structure of the app, we can finally dive into designing the UI. Personally, I like starting off with sketches on paper and then move to Inkscape for more detailed mockups, but you can use any tool you’re familiar with. You don’t need to be good at drawing or a particular application for this, just find a way to visualize your ideas which works for you :)
If you’re using Inkscape for mockups, you might want to check out the GNOME mockup template which contains some common layouts and patterns to use in your designs. If you are looking for GNOME-style symbolic icons for your mockups, you can find them here, here, and here.
When it comes to the layout of an interface, one of the first things to consider is what navigation structure makes the most sense for the type of content you have.
The most common navigation patterns in GNOME apps are the Stack, the View Switcher, and the Sidebar List.
The Stack pattern is when you have completely separate views with no shared UI, and a back button to go back to the overview. This is what Photos does for navigating between the stream of photos and the detailed view of an individual photo, for example. There is a bit more friction to switch between views than with other patterns, but it’s also more focused. This pattern is great for situations where you don’t switch between views a lot.
The View Switcher is for cases where there are a small number of views that are equally important or need to always be easily accessible. It’s used in GNOME apps such as Clocks, Music, and Software as the primary navigation. On the desktop, this switcher is always in the headerbar, but there’s work on a new adaptive version of it, which moves to the bottom of the screen for mobile. This is not quite ready yet, but will hit a version of Libhandy near you soon™.
The Sidebar List is for cases where there are a lot of views that you need to switch between often. For example, it’s used in Fractal for the room list, because it gives an overview of all rooms and allows for quick context switching. Of course, on mobile there’s not enough space for a content pane and a sidebar, so there is a Libhandy widget called Leaflet, which transforms from a Sidebar List on desktop to a Stack on mobile.
For our read-it-later app, we need navigation to switch between the different lists (Unread, Archive, Favorites), and to switch between list and article views.
For the latter we could either use a stack or a sidebar list (using the Leaflet widget so it works on mobile). Since we want this app to be a focused reading experience and switching back and forth quickly between articles is not a very common use case, a Stack is probably the best solution here.
This means that our main screens will look something like this:
Article List Screens
Now that we have a basic navigation structure we can design the individual screens in more detail. The three article list screens are basically the same lists with different content.
The main purpose of these screens is to provide a nice, legible list of the saved articles that entices people to catch up with their reading list. In order to do this we’re going with a comfortable layout including article title, preview, and some information about the article.
To help people catch up with their saved articles, we should also try to make the content as interesting as possible. A simple reverse-chronological list of saved items is quite boring, and I’ve noticed in my own use that I often scroll down the list randomly to discover older articles. A potential way to build this into the core experience would be to show the reading list in randomized order, and show the most recently saved articles at the top in a separate category. I’ve tried that in the mockups below.
In terms of actions, we need to expose search and selection mode (for operations on multiple elements), as well as the application’s primary menu. The primary menu contains global app-level things such as Help, Preferences, and About.
In selection mode we need the ability to move articles to Favorites and Archive, and delete them from our reading list. Since this is not essential functionality though, we won’t be doing designs for it yet. If you want to learn more, have a look at the selection mode page in the GNOME HIG. The same goes for search (relevant HIG page).
The article screen’s job is pretty straightforward: provide a great reading experience for the saved articles. Since many websites kind of suck in this regard, a reader mode (like Epiphany and Firefox have) should be the default view whenever possible. However, since there’s no guarantee that a given article will be rendered perfectly, we need some way to show to the website with its native styling when necessary.
We also need a way to move an article to Favorites and Archive, delete it, and share it. The most important actions are usually exposed directly in the header bar, but for less important actions (or if there’s not enough space), we can use a secondary menu.
We now know more or less what the app looks like on mobile, but what about the desktop? As with responsive web design, if you design your app for mobile first, it’s usually pretty easy to make it work well on larger screens too.
In this case, since we don’t have any sidebars or other complicated layout elements, the main change happening at larger sizes is that the content column width grows with the window, until it reaches a maximum width comfortable for reading. This can be implemented by wrapping the content area in an HdyColumn. The view switcher also moves up to the header bar, and there is a close button on the right side.
What we now have is the basic structure and most important screens of the application, but that’s of course far from everything. We don’t yet have designs for login and account settings, empty states, first run experience, errors, search, and a number of other things. I wanted to stick to the basics for this post, but perhaps I could expand on these things in future blog posts if there’s interest.
It’s also worth noting that mockups are never final, and interfaces almost always change during implementation, as you learn more about use cases, the underlying technology, and other constraints. Ideally you’d also do some informal user testing on real people, and get feedback on the design that way.
I hope this has been useful as an introduction to designing apps for the Librem 5 (and GNOME more generally). If you have any questions feel free to drop by on #gnome-design on IRC/Matrix or the Librem 5 apps Matrix room (#community-librem-apps:talk.puri.sm).
Earlier this month I attended FOSDEM in Brussels. This year was much more relaxed than last year because I didn’t have a talk or other major responsibilities. That meant I had a lot more time to talk to fellow GNOME people and other friends working on different projects.
I spent a lot of time at our booth, talking to people coming by, and planning new projects with fellow developers. The only talk I ended up going to was Zeeshan’s on Rust. I really wanted to go see Jordan’s talk as well, but the Rust devroom was way too packed on Sunday. I also attended the Mobile Free Software BoF, where Nicole gave a status update about the Librem 5 to interested community members, and people could ask questions.
Julian and I also did some work on Fractal, and we had very productive conversations with Adrien and Bilal about adaptive widgets and mobile GNOME apps. I’m very excited about all of these things progressing, and already feel like 2019 is going to be an amazing year for GNOME :)
All in all it was great fun, and I’ll definitely try to go again next year. Thanks to Bastian for organizing the apartment, and the GNOME Foundation for sponsoring my attendance!
Last week I was in Seville, Spain for our second Fractal Hackfest this year. This time it was organized by Daniel Garica Moreno, and held on the University of Seville campus. It was a small event with mostly core developers, focused on driving forward the backend changes and refactoring needed to make our future plans (end-to-end and the app split) possible. We also had some local newcomers join (shoutout to Alejandro Domínguez).
The main reason why we wanted to have another hackfest was to drive forward the long-term effort of making the application more modular, in order to add persistent storage and allow for the app split. The work done over the past few months (such Julian’s room history refactor) has gotten us much closer to that, but there were still some missing pieces and open questions.
During the hackfest we discussed some of these things, and decided, among other things, to split the backend out into a separate crate and move to SQLite for persistent storage. Daniel and Julian already started working on these things, see their blog posts for more details.
GNOME Newcomer Experience
The other focus for the hackfest was discussing an improved GNOME Newcomer experience. Finding the right rooms to join is currently quite confusing, as there is no central directory of all GNOME rooms. The main way people discover rooms seems to be word of mouth or googling for them, which is clearly not great.
Since one of the main goals for Fractal is to provide a more modern alternative to IRC for GNOME developers, we’ve been thinking about how to make it seamless to discover and join GNOME rooms for some time.
In theory Matrix has communities, which would address use cases like this one. However, since the spec for this is not really settled yet, and implementing it would be a lot of work, we’d like to do something simpler for now.
Looking at some relevant art we found Builder’s integration of Newcomer apps on the project screen quite interesting, because it’s very accessible but doesn’t get in the way.
The idea we came up with is combining the newcomer UX with the room directory into a new discovery view, and moving it to a more prominent location in the sidebar. There are still some open questions about how exactly we’d implement this, but it’s an exciting direction to be working towards.
Hacking, Housekeeping, and Best Practices
We did a lot of overdue housekeeping and organizational work, like moving to GNOME/ on Gitlab (thanks Carlos!), getting a new policy for code reviews and QA in place, issue triage, fixing bugs, and starting the process of documenting best practices we’d like contributors make use of.
Lastly, we made a push to fix some of the last outstanding blocker bugs to get a new stable release out the door, which is long overdue (the last release was in September, which is an eternity by our standards). A ton of exciting stuff has landed on master since then: a more legible layout for the message view (using Libhandy’s HdyColumn), smoother message loading, a reorganized header bar with in-window primary menu, and support for large emoji. I’m very excited to finally get these things in the hands of users.
The new release now almost ready, and will be on Flathub very soon. Since there were a lot of big changes under the hood, there will probably be some exciting new bugs as well, so please file issues on Gitlab :)
Thanks to everyone who attended the hackfest, Daniel for organizing, and the University of Seville for hosting us. Thanks also to my employer Purism for sponsoring my travel and accommodation, and the GNOME Foundation, SUGUS, and Plan4D for sponsoring some lunches and dinners. See you next time o/
It’s been an exciting year for Fractal, the GNOME Matrix client. Since our last hackfest in May, we’ve decided to split the application, refactored large parts of the backend, implemented new features such as the media viewer, made the message history adaptive, and laid the groundwork for end-to-end encryption.
Now that we have most of the foundations in place that will enable our long-term goals (such as adaptive layout, E2E, and the app split), we’re getting together again to push these initiatives forward. This is why we’re having another hackfest on December 11-14 in Seville, Spain.
The main focus of the hackfest will be finalizing the backend refactor, and tying up various loose ends related to this, so we can start working on E2E and the app split. The other area we want to focus on is improving Fractal as a tool for GNOME developers, and IRC replacement. In particular, we’re interested in providing a smooth, integrated GNOME Newcomer experience, because finding the right rooms to join is currently a big pain point for new contributors.
tl;dr: If you want to change how an app looks, you need a designer in the loop.
Over the past few months we’ve had a lively debate about “theming” in GNOME, and how it affects our ecosystem. In this discussion I’ve found that there is a divide between people who design and/or develop apps, and people who don’t. I have yet to see an app developer who thinks the current approach to “theming” can work, while many people who aren’t app developers are arguing that it can.
After a few long discussions I started to realize that part of the reason why there’s so little agreement and so much drama around this issue is that we don’t agree what the problem is. Those who don’t work on apps often can’t see the issues with theming and think we want to remove things for no reason, while those who do are very frustrated that the other side doesn’t want to acknowledge how broken everything is.
The basic issue we’re arguing about is whether it’s possible to restyle applications automatically, at scale, without breaking them. In this post I’ll try to explain why I think that it isn’t possible, and why trying to do it is hurting our ecosystem.
There are no themes, just CSS
A fundamental misconception a lot of people have is that GTK 3 supports theming. This is not true, as there is no clearly defined theming API. There are CSS stylesheets, but they were only ever meant to be used by the platform and app developers. The platform stylesheet is called Adwaita (“the only one” in Sanskrit) for a reason.
However, some people (inlcluding major distributions) have been using custom stylesheets as a hacky approximation of “themes” for so long now that nobody even remembers that they are not a real theming API.
Since CSS is a huge API surface, which is used by both app developers and “theme” developers, it’s very easy for the two to conflict. This leads to apps looking broken unless you manually do QA for every app/theme combination.
“You’re exaggerating, it’s not that bad.”
One of the most frustrating things about the current situation is that to users, it looks like it almost works. For the most part, third-party themes look and work okayish, there are just a few small bugs here and there. A button with too little contrast, an underline clashing with a border, a really large loading spinner. Not that big a deal, you’d think.
However, this view of the situation misses a few really important realities:
App developers are doing a lot of bug fixing to account for “theming”, because people complain to them when their app is broken on certain distros. The current situation essentially forces developers to fix bugs for setups they never intended to support in the first place. They’re not happy about it, but they’re doing it because they don’t want their users to have broken apps.
App developers are trying hard not do anything innovative or visual in their apps, because they know it will break with other stylesheets.
“Theme” developers are fixing a lot of bugs for edge cases in individual apps in their stylesheets. Of course, this is a never-ending task because as soon as a new version of an app is released, something will very likely be broken again.
All of this only kinda sorta works because we have very few apps. If we ever hope to grow our ecosystem past a few dozen apps things have to change, because maintaining a “theme” gets less sustainable with every new app.
There is also the question of what your definition of “broken” is. Some people think that things like these are acceptable:
I believe this is nowhere near ok. App developers put a lot of effort into making sure their apps look and feel right, fixing bugs, and doing QA. Having distributors change their apps (often in ways that break things) with no QA before users get to experience them is developer-hostile, and would be unacceptable in any other context.
Can you imagine Samsung restyling every third-party app on their phones, without testing them, and when Instagram complains that the text on their buttons is illegible Samsung just shrug and say “Sorry, but branding is very important to us. Why don’t you change your app?”.
“But it’s fine as long as you follow best practices!”
This is a common sentiment among some people. “If only app developers followed best practices, used CSS variables, and derived their colors from theme colors, everything would be fine”, the argument goes. While it’s true that these things are important and make apps more flexible in terms of appearance, this doesn’t come close to solving the entire problem.
If every app only used default GTK controls, in very simple layouts, with no custom widgets or in-app CSS, then best practices would perhaps be enough to prevent apps from breaking. But the reality is that a) this is not the case, and b) we really don’t want it to be the case.
Human Interface Guidelines are just that: guidelines. They have to be implemented manually, they change and evolve over time, and the best apps on any platform push their boundaries in some places and experiment with new patterns (which then sometimes make their way back into the HIG).
This kind of experimentation means that it’s impossible to “theme” apps automatically. Visual design and interaction design are very closely linked, so if you want to change the style, you need a designer to actually think about what a widget should look like.
For example: How should the Pop theme know what a “flat” variant of the new Nautilus path bar should look like? It’s impossible to do this automatically, because it’s a new pattern.
This is not a rare situation, even among core GNOME apps. Many of the apps I’ve personally worked on have their own equivalent of the Nautilus path bar. And that’s the way it should be. Apps have different needs that sometimes require custom solutions, and this experimentation is good for the ecosystem. However, it also means that automatic restyling is impossible.
“But what about Adwaita Dark and High Contrast?”
The point that the dark and high contrast variants of Adwaita can be seen as GTK 3 kinda sorta supporting themes is technically accurate, but misguided. Adwaita variants may technically just be different stylesheets, but this is just an implementation detail. There are very clear differences between them and third-party “themes”.
They are very very close to Adwaita code-wise, and therefore much less likely to break.
There’s a finite number of them, and they are part of the platform. This makes them a tangible target for developers to test for and support, which is completely different from third-party “themes” which just apply random CSS to every app without any QA.
They are part of the same design language, so they require very little extra work to adapt to from a design point of view. If you follow the best practices mentioned above, often no work at all.
“But what about consistency? I want all my apps to look the same!”
“Consistency” is a word you hear a lot in debates about theming, but it seems to mean different things to different people.
To some, consistency effectively means “everything should use the same colors”. This is relatively easy to achieve for some apps, even across toolkits, if you simply provide a “theme” for each toolkit.
However, this “consistency” is very shallow. Just because a Qt app uses the Adwaita colors it doesn’t automatically fit in with the GNOME platform. UI patterns are much more important, and they can’t be changed with theming. There is no magic that can redesign menu bar apps with header bars.
Real consistency can only happen by design, and requires the app developer to build it into the app at every step. If you want all your apps to look the same, only use apps built for your platform’s HIG. “Fixing” apps after the fact with theming isn’t really making your system more consistent, but it’s hurting app developers a great deal.
Of course, even the very shallow “everything uses the same colors” consistency is impossible to enforce across all apps and toolkits. Apps like Blender, Telegram, or Steam don’t respond to system theming at all, and even Firefox and Chromium only do so in a very limited fashion.
“But users *want* themes!”
“Users” want a lot of things, but just because you want something impossible that doesn’t make it possible. In this case, it’s important to be aware of the costs of giving complete visual freedom to “themes”, both in individual app developer effort, and chilling effects on the ecosystem. If given a choice between customization and more, better apps, I’m confident the majority of people would prefer the latter.
Would it be nice if there were a way to be able to restyle every app to make them look like Material Design, or macOS, or Windows 95, and have them all look as if they were built for that style? Absolutely! I would love that! However, as I’ve tried to explain in this blog post, this is simply not realistic.
So, what can we do?
As the recent discussions have shown, talking about solutions before we agree what the problem is isn’t very productive, so for now I’m mostly interested in making sure we’re all aware of the problem and its various facets. There are several different stakeholders with different perspectives on this issue, and making progress will mean making some hard choices. At this year’s GUADEC we had a Theming & Ecosystem BoF where we talked about a number of potential directions, and I hope we can move forward on that path.
No matter what we come up with though, I think it’s crucial that we start taking the needs of app developers seriously. Developers are the lifeblood of any platform, and we’ve been treating them very poorly. If we want to grow our ecosystem and actually compete with other major platforms, we need to fix that.
Note: The examples in this post have been chosen because the themes in question ship with major distributions, so app developers tend to get complaints about them. It’s not my intention to single them out, this problem applies to all third-party themes equally.
A few weeks ago I attended GUADEC in Almeria, Spain. The travel was a bit of an adventure, because Julian and I went there and back from Italy by train. It was great though, because we had lots of time to hack on Fractal on the train.
The conference days were great, though I didn’t manage to see many talks because I kept getting tied up in interesting discussions (first world problem, I know :D). I did give a talk of my own though, about my work at Purism on UI patterns for making GNOME apps work on mobile. There is a video recording of the talk, and here are my slides.
The main thing I tried to get across is that Purism isn’t trying to create a separate ecosystem or platform, but to make the GNOME platform better upstream. We ship vanilla GNOME on our laptops, and we want to do the same on phones. It’s of course early days, and it will take a while for everything to get into place, but it feels great to work for a company that has upstream-first as a core principle.
The biggest area where our efforts will make an impact upstream in the short term are the Libhandy widgets Adrien and Guido have been working on. These widgets allow regular GNOME/GTK apps to scale to smaller sizes using adaptive UI patterns. The patterns are extending GNOME’s existing HIG in a few small details only, and can be used to make many existing GNOME apps adaptive without requiring major UI changes. We’re still experimenting with them, but once the patterns are solid and the widgets stable, we will work to upstream them into GTK.
Using Libhandy widgets will not only enable apps to run on phones, but also yield benefits on the desktop. For example, HdyColumn solves a very old problem many GTK apps have: Lists that need to grow with the window’s width, but also need a maximum width to ensure legibility. By enabling this, HdyColumn allows apps to work better on both very small and very large screens.
The BoF days were packed with interesting sessions, but sadly many of them happened simultaneously, so I was only able to attend a few of them. However, the ones I did attend were all incredibly productive and interesting, and I’m excited about the things we worked on and planned for the future.
Monday: Librem 5
On Monday I attended the all-day Librem 5 BoF, together with my colleagues from Purism, and some community members, such as Jordan and Julian from Fractal.
We talked about apps, particularly the messaging situation and Fractal. We discussed what will be needed in order to split the app, make the UI adaptive, and get end-to-end encryption. Daniel’s work on the database and Julian’s message history refactor are currently laying the groundwork for these.
On the shell side we talked through the design of various parts of the shell, such as keyboard, notifications, multitasking, and gestures. Though many of those things won’t be implemented in the near future, we have a plan for where we’re going with these, and getting designers and developers in one room was very productive for working out some of the details.
We also discussed a number of exciting new widgets to make it easier to get GNOME apps to work at smaller sizes, such as a new adaptive preferences window, and a way to allow modal windows to take up the entire screen at small sizes.
Multi-Monitor & Theming
On Tuesday we had a Multi-Monitor BoF, where we discussed multi-monitor behaviors with people from System76 and Ubuntu, among others. The most interesting parts to me were the discussions about adding some usecase-driven modes, such as a presentation mode, and a potential new keyboard-driven app switching interface (think Alt-Tab, but good). All of this will require a lot of work, but it’s great to see downstreams like System76 interested in driving initiatives like this.
In the afternoon we had the Theming & Ecosystem BoF, where we got designers, upstream GNOME developers, and people from various downstreams together to talk about the state of theming, and its impact on our ecosystem.
The basic problem we were discussing is that app developers want stable APIs and control over what their app looks like on user’s systems, while some distributions want to apply their own branding to everything. The current situation is pretty bad, because users end up with broken apps, developers constantly need to fix bugs for setups they didn’t want to support in the first place, and distributions need to invest lots of resources into building forever-slightly-broken custom themes. We discussed a number of possible approaches to tackle this problem, in order to make our platform easier to target. I’ll blog about this in more detail, but I’m excited about the possibility of finally solving this long-standing problem.
We also talked about some of our future plans with regard to icons. This includes a new “library” of symbolics, and a push for app developers to ship symbolic icons with their apps, rather than linking to random strings which have to be maintained forever. We also introduced the new app icon style initiative, which will make it drastically easier to make icons because they are simpler, more geometric, and there are fewer sizes to draw. All of this will still develop over the next cycle, since it’s not going to ship until 3.32.
Wednesday: What is a GNOME app?
On Wednesday we had a small but very productive BoF to work on a proposal for a policy for including new apps as part of GNOME, and more generally getting a clearer definition of what it means for a project to be part of GNOME. There is currently no clear process for the inclusion of new projects as part of GNOME, so it doesn’t happen very often, and usually in a very disorganized fashion. This is a problem, because it leaves people who are excited about making new GNOME apps without a clear path to do so.
For example, both Fractal and Podcasts were built from the ground up to be GNOME apps, but still haven’t made it to the GNOME/ group on Gitlab officially, because there’s no clear policy. The new Calls app Bob is building for the Librem 5 is in the same limbo, just waiting around for someone to say if/how it can become a part of GNOME officially.
At the BoF we drafted a proposal for an explicit inclusion policy. The idea is for apps that a follow a set of criteria (e.g. follows the HIG, uses our tech stack) to be able to apply for inclusion, and have some kind of committee that could review these requests.
This is only a very rough proposal for now, but I’m excited about the potential it has to bring in more developers from the wider ecosystem. And of course, as the designer of a half dozen semi-official GNOME apps I’m very selfishly interested in getting this in place ;)
In addition to all of the above, it was great to meet and hang out with so many of the awesome people in our community at social events, beach BoFs, and ad-hoc hacking sessions on the corridor. It’s hard to believe that one year ago I came to GUADEC as a newcomer. This year it felt like coming home.
One of the biggest problems with Fractal at the moment is that 1-1 messaging is pretty terrible. Since the rooms in the sidebar are sorted by most recent activity, high-traffic public rooms (such as GNOME IRC channels) tend to drown out rooms with less traffic, such as 1-1s and small groups. This is problematic because the signal-to-noise ratio in 1-1 chats and small groups tends to be much higher than in high-traffic public rooms. This leaves the user constantly searching for the rooms they care about, while the rooms they don’t care about are always at the top.
One way to solve this problem is having a favorites group for “important” rooms. This is a feature Fractal has had for a while, and it does solve some of the problems with a room list sorted purely by recent activity. However, it only works well for rooms that are important over long periods of time, and needs to be managed manually. 1-1 chats are often brief, and there can be many of them in parallel. Putting them in favorites doesn’t make sense in many cases, as it would balloon the size of the favorites group, and require lots of manual work when starting or ending a conversation.
The “obvious” solution would be doing what Riot does: Having a separate group of 1-1 rooms in the sidebar, and thereby keeping the 1-1 conversations in one consistent place. However, this creates more problems than it solves. In practice, it results in multiple groups of arbitrary length competing for real estate in the sidebar. If you have a lot of 1-1s, this means that you’ll be able to see very few rooms (even when most of the 1-1s are old and not relevant at the moment). In Riot, this group is capped at 10 visible rooms by default, but that’s still not great if you only need 2 of them at the moment. The category can be collapsed, but then you can’t see which 1-1s have new messages, and it also means lots of busywork collapsing/expanding the group. Clearly this isn’t an ideal solution, which is why we were very hesitant to go down this path.
A way out?
As we were discussing this issue over the past few months, I started looking more closely at the way people use different messaging tools. One thing I found puzzling is that despite the fact that Matrix theoretically supports the use cases covered by popular apps like Whatsapp and Telegram, few people are actually using it to replace those apps. Instead, they use it to replace IRC and Slack.
Why? My theory is that most chat rooms fall in one of three categories: Private Chats, which include 1-1s and small groups; Team Chats, which are larger, but still private and invite-only; and Public Rooms, which are basically like IRC.
Team Chats and Public Rooms share many characteristics: Both have relatively high amounts of traffic, and there’s a lot of noise. The main difference is that Team Chats are private and the members rarely change (e.g. a company’s internal Slack), while Public Rooms can be joined by anyone at any time, and there is no expectation of privacy (e.g. #gnome-hackers on IRC).
However, Private Chats have relatively little in common with the other two categories: They are low-traffic, and have little or no noise. This may sound like a small difference, but I think it’s the reason why 1-1s suck in Fractal/Riot/IRC, and why people aren’t using Matrix to replace Telegram.
The Banquet and the Barbecue
I’ve come to the conclusion that one app can’t cover all the use cases that the Matrix protocol supports, and still provide competitive UX. If you design an app to deal with lots of high-traffic rooms (e.g. Riot as it is today), it will suck for 1-1s, so people will use something else for those. Similarly, Telegram is primarily designed for 1-1s and small groups, which is why it’s a terrible experience if you have many high-traffic groups.
If we want Matrix to succeed as more than an IRC/Slack replacement we need multiple apps, each focusing on a distinct use case. For messaging, I think the most important distinction to make is between what I call the Banquet and the Barbecue.
The Banquet is a big, loud place. There are tons of people, and you don’t know many of them. Lots of things are happening all the time, and it’s hard to keep track of everything. This is what Matrix is currently mostly used for. Slack, IRC, and Discord are also all in this category.
The Barbecue is at the other end of the spectrum: It’s a calm, private environment where friends, family, co-workers, and other acquaintances hang out. Conversations are mostly between 2 or 3 people, slow, and often very personal. Telegram, Whatsapp, iMessage, Facebook Messenger, and a myriad of other chat apps are optimized for this use case.
Now, what does this mean for Fractal? After a long discussion on Thursday, we decided to split up Fractal into two separate apps with different interfaces, each containing a subset of the user’s Matrix rooms.
Exactly how rooms will be split between the two apps is not 100% clear yet. 1-1s are clearly Barbecue, public rooms are clearly Banquet, but private groups could go either way. For these cases we may need a way to explicitly move rooms between apps. The distinction should probably be part of the Matrix spec, so the intent for a room to be a Barbecue or Banquet room could be set when creating a room, and persist across devices.
The two apps will share practically all the internals, and even large parts of the interface. However, the split will allow us to do some things differently in each app to optimize the interfaces for the different use cases. Some of the changes we’re considering are a bubble-style message view in the Barbecue app, and more room categories (such as low-priority) in the Banquet app’s sidebar.
How exactly the apps will be branded (and what will happen to the Fractal name we all love) is still being decided, but there is some consensus to move to GNOME-style generic names. The Barbecue app will almost certainly be called “Messages”. For the Banquet app there’s less agreement, but my current favorite is “Discussions”.
The Fractal brand will not go away though: We’re thinking of keeping it around as the name of the community project that develops both GNOME Matrix apps, and/or using it for the backend powering both apps.
There are lots of details to be figured out in this transition, both from a design and an implementation perspective, but I’m very excited about this new direction. If you’d like to join the effort, come talk to us on Matrix.
Note: I have no illusions that this change will magically get everyone to leave Whatsapp/Telegram/iMessage and move to Matrix. In the short term, the goal is simply to make Matrix 1-1s a good experience. That said, if we ever want Matrix to make inroads with the general public, I think a move in this direction is an important precondition.
Last week we had an intense 4-day hackfest in Strasbourg to map out the future of Fractal, a native GNOME Matrix messaging app. The event was held at Epitech in Strasbourg’s old town, and organized by Alexandre Franke. Among the attendees were core Fractal contributors Daniel, Alexandre, Eisha, and Julian, as well as Dorota, Adrien, and Francois from Purism. Special thanks go to Matthew from the Matrix core team for joining us on the first two days.
Our main priorities for the hackfest were to plan the roadmap for the next months, decide on the tasks for our GSoC students (Eisha and Julian), and work on the design of some important missing features, like the room settings.
I personally attended the hackfest in both my role as designer on the Fractal project and as a Purism employee currently working on the apps for the Librem 5. One of the reasons why several members of the Librem 5 team attended the hackfest was that we will need a Matrix messaging app on the phone and wanted to explore a potential collaboration.
The hackfest was extremely productive, so much so that I’ll need multiple blog posts to report on all the things we worked on. Here’s a quick outline of some of the most important things that happened:
We’re splitting the app into two separate apps (more on this in a future blog post)
A big refactor of the backend is happening soon to enable the split
We discussed having a system-level Matrix daemon, which different apps could use as a backend (e.g. the two different messaging apps and a calls app)
Matthew explained that room types will be simplified into 1-1, private groups and public groups in the future (which nicely complements our split). We discussed whether 1-1s should be immutable (they should :P)
Matthew explained how end-to-end encryption and calls work in Matrix, and how we could get them in Fractal
We came up with an initial design for multi-account (which basically consists of an account chooser at startup, and a separate window for each account)
We discussed a design for read receipts. Not quite done yet, but we’re on the right path, I think.
We talked about what it will take to make Fractal work on mobile. Not too big of a problem design-wise, but we’ll need Rust bindings for libhandy and emeus
Eisha will be investigating i18n, because we really want to make the app translatable (currently this is hard to do because we use Rust)
Julian will be working on a big message history UI refactor/redesign, as well as other UI stuff, such as user account settings
There is a huge number of message types we don’t support yet and we discussed the design for most of them (including in-app viewers and a history of sent files)
We fought our way though the garbage fire that is the Join and History settings in Riot, and emerged with a design that isn’t terrible (thanks Dorota and Julian!)
Thanks everyone for attending, Epitech and Alexandre for the venue, and Purism for sponsoring the hackfest! It was amazingly productive to have everyone in one place, and I look forward to seeing you all at GUADEC in July :)
For the past few months, I’ve been contributing to a new group messaging app called Fractal. Its aim is to be so good that we can maybe, eventually, finally replace IRC as the primary communication channel for GNOME development.
IRC is old
Though IRC has been around forever, it’s hardly a good user experience by today’s standards, and can be a significant hurdle to onboarding new contributors (especially non-technical ones). Some of the main issues are:
No easy way to use it from mobile
You can only receive messages while online
Sending images or files is only possible via URL
This has led to some free software projects going so far as to use proprietary services such as Slack. However, even then you’re stuck with an Electron app, which is slow and not integrated with the desktop at all.
Enter the Matrix
The Matrix protocol is a modern alternative to IRC. It provides features such as persistence, inline media, and multi-device syncing. Importantly for GNOME, it is also backwards-compatible to IRC using bridges, allowing us to use the fancy new Matrix features without being cut off from the rest of the community.
Over the past few years, some GNOME developers have started using Matrix, but the lack of a good native client has held back adoption.
And that’s where Fractal comes in: It’s a native Matrix client for GNOME, with an interface focused on the IRC use case (discussions in large, high-volume rooms). We want it to be a fast, native alternative to Slack that can compete on UX, and doesn’t require non-free network services.
I started contributing in late October, when the app was still called Guillotine, and looked like this:
I got involved after Daniel Garcia Moreno, the app’s primary developer, mentioned that he was looking for a designer to help out with his Matrix app on #gnome-design. We then started working on revamping the somewhat haphazardly designed interface, and making it look like a proper GNOME app.
Over the past few months the community has grown from just Daniel and I to over 120 people in our Matrix room, and a number of regular contributors. We’ve redesigned every part of the app (except for the room directory), and added a number of small but essential features, such as invites, room creation, and username autocomplete.
The app now looks like this (though the design is still evolving quite rapidly):
For the past months we’ve mainly been working on overhauling the interface, but we haven’t added many new features. As most of the foundational interface work is done now, we can start planning larger new initiatives.
That’s why next month (May 10th-13th) we’re going to have a Fractal Hackfest in Strasbourg. The core contributors will meet for the first time and discuss exciting new things, such as a better onboarding flow, a new responsive layout, and support for more Matrix features.
Among the people joining the hackfest will be Matthew from Matrix, and some of my coworkers from Purism. It will be a great opportunity for plotting future collaborations.
I’m very happy to announce that I’ve joined Purism. It’s awesome to be working for a company that not only cares about software freedom, but also has Ethical Design as a core principle. My role there is UI/UX designer on the Librem 5, a phone built from the ground up to run free software and GNU/Linux.
As a past user of first Firefox OS and then Ubuntu Touch, I couldn’t be more excited about this. Unlike these previous failed efforts, the Librem 5 is focused on freedom and privacy, because it’s made by people who share that philosophy. It’s using PureOS (a full GNU/Linux distro based on Debian), instead of a completely different technology stack with Android drivers (like Firefox OS and Ubuntu Touch did). To make things even sweeter, the UI will be GTK-based, and we’re using upstream GNOME apps (which we’re adapting with a responsive layout). We’ll also be working on new applications for the phone, such as Calls and Messages, which will work on the desktop as well. We want as much of this work as possible to go upstream, so it can benefit all GNOME users.
It’s still early days, but some of the work around apps should become more concrete in the coming weeks, so expect phone-related discussions in #gnome-design. Let’s make a killer GNOME phone!
Unless you’re one of a very lucky few, you probably use apps with title bars. In case you’ve never come across that term, title bars are the largely empty bars at the top of some application windows. They contain only the window title and a close button, and are completely separate from the window’s content. This makes them very inflexible, as they can not contain any additional UI elements, or integrate with the application window’s content.
All GNOME apps (except for Terminal) have moved to header bars over the past few years, and so have many third-party apps. However, there are still a few holdouts. Sadly, these include some of the most important productivity apps people rely on every day (e.g. LibreOffice, Inkscape, and Blender).
Thereareways to hide title bars on maximized and tiled windows, but these do not (and will never) work on Wayland (Note: I’m talking about GNOME Shell on Wayland here, not other desktops). All window decorations are client-side on Wayland (even when they look like title bars), so there is no way to hide them at a window manager level.
The CSD Initiative
The only way to solve this problem long-term is to patch applications upstream to not use title bars. So this is what we’ll have to do.
That is why I’m hereby announcing the CSD Initiative, an effort to get as many applications as possible to drop title bars in favor of client-side decorations. This won’t be quick or easy, and will require work on many levels. However, with Wayland already being shipped as the default session by some distros, it’s high time we got started on this.
For a glimpse at what this kind of transition will look like in practice, we can look to Firefox and Chromium. Chromium has recently shipped GNOME-style client-side decorations in v63, and Firefox has them in experimental CSD builds. These are great examples for other apps to follow, as they show that apps don’t have to be 100% native GTK in order to use CSD effectively.
What is the goal?
This initiative doesn’t aim to make all apps look and act exactly like native GNOME apps. If an app uses GTK, we do of course want it to respect the GNOME HIG. However, it isn’t realistic to assume that apps like Blender or Telegram will ever look like perfectly native GNOME apps. In these cases, we’re are aiming for functional, not visual consistency. For example, it’s fine if an Electron app has custom close/maximize/minimize icons, as long as they use the same metaphors as the native icons.
Thus, our goal is for as many apps as possible to have the following properites:
No title bar
Native-looking close/maximize/minimize icons
Respects the setting for showing/hiding minimize and maximize
Respects the setting for buttons to be on the left/right side of the window
Which apps are affected?
Basically, all applications not using GTK3 (and a few that do use GTK3). That includes GTK2, Qt, and Electron apps. There’s a list of some of the most popular affected apps on this initiative’s Wiki page.
The process will be different for each app, and the changes required will range from “can be done in a weekend” to “holy shit we have to redesign the entire app”. For example, GTK3 apps are relatively easy to port to header bars because they can just use the native GTK component. GTK2 apps first need to be ported to GTK3, which is a major undertaking in itself. Some apps will require major redesigns, because removing the title bar goes hand in hand with moving from old-style menu bars to more modern, contextual menus.
Many Electron apps might be low-hanging fruit, because they already use CSD on macOS. This means it should be possible to make this happen on GNU/Linux as well without major changes to the app. However, some underlying work in Electron to expose the necessary settings to apps might be required first.
Apps with custom design languages will have to be evaluated on a case-by-case basis. For example, Telegram’s design should be easy to adapt to a header bar layout. Removing the title bar and adding window buttons in the toolbar would come very close to a native GNOME header bar functionally.
How can I help?
The first step will be making a list of all the apps affected by this initiative. You can add apps to the list on this Wiki page.
Then we’ll need to do the following things for each app:
Talk to the maintainers and convince them that this is a good idea
Do the design work of adapting the layout
Figure out what is required at a technical level
Implement the new layout and get it merged
In addition, we need to evaluate what we can do at the toolkit level to make it easier to implement CSD (e.g. in Electron or Qt apps). This will require lots of work from lots of people with different skills, and nothing will happen overnight. However, the sooner we start, the sooner we’ll live in an awesome CSD-only future.
And that’s where you come in! Are you a developer who needs help updating your app to a header bar layout? A designer who would like to help redesign apps? A web developer who’d like to help make CSD work seamlessly in Electron apps? Come to #gnome-design on IRC/Matrix and talk to us. We can do this!
There have been some misunderstandings about what I meant regarding server-side decorations on Wayland. As far as I know (and take this with a grain of salt), Wayland uses CSD by default, but it is possible to add SSD support via protocol extensions. KDE has proposed such a protocol, and support for this protocol has been contributed to GTK by the Sway developers. However, GNOME Shell does not support it and its developers have stated that they have no plans to support it at the moment.
This is what I was referring to by saying that “it will never work on Wayland”. I can see how this could be misinterpreted from the point of view of other desktop environments but that was not my intention, it was simply unfortunate wording. I have updated the relevant part of this post to clarify.
Also, some people seem to have taken from this that we plan on lobbying for removing title bar support from third-party apps in a way that affects other desktops. The goal of this initiative is for GNOME users to get a better experience by having fewer applications with badly integrated title bars on their systems. That doesn’t preclude applications from having title bars on different desktops, or having a preference for this (like Chromium does, for example).
Last week I took part in the GNOME Shell UX Hackfest in London, along with other designers and developers from GNOME and adjacent communities such as Endless, Pop!, and elementary. We talked about big, fundamental things, like app launching and the lock/login screen, as well as some smaller items, like the first-run experience and legacy window decorations.
I won’t recap everything in detail, because Cassidy from System76 has already done a great job at that. Instead, I want to highlight some of the things I found most interesting.
One of my main interests for this hackfest was to push for better animations and making better use of the spatial dimension in GNOME Shell. If you’ve seen my GUADEC Talk, you know about my grand plan to introduce semantic animations across all of GNOME, and the Shell is obviously no exception. I’m happy to report that we made good progress towards a clear, unified spatial model for GNOME Shell last week.
Everything we came up with are very early stage concepts at this point, but I’m especially excited about the possibility of having the login/unlock screen be part of the same space as the rest of the system, and making the transition between these fluid and semantic.
Another utopian dream of mine is a tiling-first desktop. I’ve long felt that overlapping windows are not the best way to do multitasking on screens, and tiling is something I’m very interested in exploring as an alternative. Tiling window managers have long done this, but their UX is usually subpar. However, some text editors like Atom have pretty nice graphical implementations of tiling window managers nowadays, and I feel like this approach might be scalable enough to cover most OS-level use cases as well (perhaps with something like a picture-in-picture mode for certain use cases).
We touched on this topic at various points during this hackfest, especially in relation to the resizable half-tiling introduced in 3.26, and the coming quarter-tiling. However, our current tech stack and the design of most apps are not well suited to a tiling-first approach, so this is unlikely ot happen anytime soon. That said, I want to keep exploring alternatives to free-floating, overlapping windows, and will report on my progress here.
Header bars everywhere
A topic we only briefly touched on, but which I care about a lot, was legacy window decorations (aka title bars). Even though header bars have been around for a while, there are still a lot of apps we all rely on with ugly, space-eating bars at the top (Inkscape, I’m looking at you).
We discussed possible solutions such as conditionally hiding title bars in certain situations, but finally decided that the best course of action is to work with apps upstream to add support for header bars. Firefox and Chromium are currently in the process of implementing this, and we want to encourage other third-party apps to do the same.
This will be a long and difficult process, but it will result in better apps for everyone, instead of hacky partial solutions. The work on this has just begun, and I’ll blog more about it as this initiative develops.
In summary, I think the hackfest set a clear direction for the future of GNOME Shell, and one that I’m excited to work towards. I’d like to thank the GNOME Foundation for sponsoring my attendance, Allan and Mario for organizing the hackfest, and everyone who attended for being there, and being awesome! Until next time!