Fractal Hackfest in Strasbourg

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)
  • With Matthew’s help, Daniel fixed the slow initial sync
  • Julian worked on a nicer UI for the GTK emoji chooser and Rust bindings for gspell
  • Alexandre landed the new, prettier default avatars
  • Quentin started packaging Fractal for macOS
  • 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!)
Matthew explaining device verification for E2E chats

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 :)

 

Announcing the 2018 Fractal Hackfest

tl;dr: Fractal is a new Matrix app for GNOME. Come join our hackfest May 10-13th in Strasbourg!

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.

Riot in Revolt
The Riot web app works, but it’s not exactly a clean, focused experience

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.

Fractal

I started contributing in late October, when the app was still called Guillotine, and looked like this:

guillotine.png

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):

Though it’s still a bit rough, Fractal is already very usable as a day-to-day Matrix client. You can install the Flatpak from Flathub and try it yourself. Bug reports are always appreciated.

The Hackfest

So where do we go from here?

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. I think it’ll be a great opportunity for plotting future collaborations, so if you’re interested in

If you’re interested in joining the hackfest, add yourself to the hackfest wiki page or come talk to us in the Fractal Matrix room.

 

 

UX Hackfest London

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.

Spatial model

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.

Tiling

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

Tiling in the Atom text editor
Tiling in the Atom text editor

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

Screenshot of a full-screen Blender window with a title bar
On a 1366x768px display, a 35px title bar takes up close to 5% of the entire screen.

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.

Screenshot of Firefox with client-side decorations
Firefox with client-side decorations (in development)

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!

GNOME foundation sponsorship badge