Last weekend I attended the Core Apps hackfest in Berlin. This was a reboot of the Content Apps hackfest we held last year around the same time of year, with a slightly broader focus. One motivation behind these events was to try and make sure that GNOME has a UX focused event in Europe at the beginning of the Autumn/Spring development cycle, since this is a really good time to come together and plan what we want to work on for the next GNOME version.
The format of the hackfest worked extremely well this year (something that everyone who attended seemed to agree on). The scope of the event felt just right – it allowed a good level of participation, with slightly over 20 attendees, a mixed agenda, and also opportunities for collaboration and cross-cutting discussion.
We had three designers in attendance, in the form of Jakub, Andreas and myself. This felt extremely helpful, as we were able to both work on tricky design tasks together as well as split up in order to support groups of hackers in parallel. We worked non-stop over the course of the event and pumped out a serious amount of design work.
In all the event felt extremely productive and is something I would love to repeat in the future.
What we worked on
One of the main design areas at the hackfest was how to allow the content applications (Documents, Music, Photos and Videos) the ability to open items in the Files application. This is something that has been on the cards for a while and we had already had designs for. However, reviewing the plan we had, we realised that it needed improvement, and we spent a good chunk of the hackfest evaluating different options before settling on an improved design.
Software was another focus for the hackfest, as we had several Software hackers in attendance. On the design side, we worked on how to better integrate shell extensions. We also worked on improving the UI for browsing categories of applications and add-ons. The result was some fairly detailed mockups for changes we hope to make this cycle.
Towards the end of the event, Cosimo, Andreas, Jakub, Joaquim and I discussed plans for “content selection”. This is the idea of being able to open content items that are provided by sandboxed applications, in a similar method to the existing file chooser dialog, but without actually interacting with the file system. This way, applications will be able to make content available that isn’t stored in a shared home directory or might not even be stored locally on the device. It’s a tricky design problem that will require more work, but we made a good start on establishing the parameters of the design.
In addition to these main areas, there were lots of other smaller design tasks and discussions. We worked a bit on Music, talked a bit about Usage and even had a bit of time for GTK+ Inspector.
Acknowledgements
These events only happen due to the work of community members and support from GNOME’s partners and donors. Special thanks has to go to Carlos Soriano for organising the event. Also a big thank you to Kinvolk for hosting and providing snacks and to Chris Kühl and Joaquim Rocha for acting as our local guides. Finally, thank you to Collabora for helping to feed and water everyone!
Last week I attended the GTK+ hackfest in Toronto. We had a really good group of people for the event, which lasted 4 days in total, and felt really productive.
There were a number of interesting discussion and planning sessions, from a design point of view, including a session on Flatpak “portals” and another on responsive design patterns.
I also got to spend a bunch of time talking about developer documentation with Christian and the two Philips and did a bunch of work on a series of designs for a web front end for Hotdoc (work on these is ongoing).
Finally, after the *ahem* online discussion around GTK+ versioning and lifecycles, I helped to document what’s being proposed in order to clear up any confusion. And I drew some diagrams, because diagrams are important.
Thanks to Matthias for organising the event, Red Hat Toronto for hosting, and Allison Lortie for being a great guide!
For a small team, GNOME design generates a huge amount of work. While we try to publicise as much of it as possible, not everything gets blogged about. In this post, I’m going to present design material from our archives that hasn’t featured in a blog post previously, and which you might not have encountered before. A lot of it is for less critical applications which, while interesting and important, aren’t the core focus of our activities.
The mockups that I’m including here are the raw wireframes that we’ve had sitting around in our design repository – they haven’t been finessed or polished for public consumption, so don’t be surprised if there’s the odd mistake or unfinished pieces here and there. The aim is to give an insight into the work, warts and all.
Usage
Usage is the name us designers have for a revamped System Monitor application. The name reflects the fact that we don’t want the app to be just about what your computer is doing right now – we also want it to be a place where you can get historical information about usage of resources like battery power or network.
We’ve had some designs sitting around for the Usage application for a while. Not so long ago I decided to update them a bit. In doing so, I added a section for disk usage, which is probably the worst part of the existing System Monitor app, and is loosely based on our Disk Usage Analyzer (aka Baobab).
Open to view the full wireframes
Tweak Tool
Ah the trusty Tweak Tool! Some people seem to think that us designers don’t like it, which is quite the opposite of the truth: we’re the ones that conceived it in the first place! Anyway, the Tweak Tool could use a bit of love in some areas, so some time ago I produced a complete set of updated wireframes for it.
The new designs are primarily intended as a polish exercise: a lot of the UI has been refined to be nicer looking and easier to use.
Open to view the full wireframes
Passwords & Keys
Yes, GNOME’s trusty passwords app has had a redesign! This one is further advanced than some of the others: Daiki Ueno has been working on the new version. The aim is to update the app to use modern design patterns, so it is consistent with the rest of GNOME 3. The current application exposes a lot of technical details about how passwords are stored, which isn’t helpful in a lot of cases, so we’re trying to only show those unless they are needed.
Open to view the full wireframes
Chat
The world seems to have moved on from open chat protocols, unfortunately, and demand for chat clients that support them isn’t what it used to be. Nevertheless, there are still cases where they get used. With that in mind, we have some basic initial wireframes for a GNOME 3 chat application. These primarily exist in case anyone fancies having a go at writing a replacement for Empathy. They are intentionally incomplete, and are supposed to be just enough to get a developer started.
Open to view the full wireframes
gitg
gitg, the GNOME Git client, had a few nice improvements last release. One or two of them were a result of a batch of mockups I did early in the last development cycle; there’s a lot more to these which it would be great to have implemented in the future, though.
The mockups make the toggle for switching between the history and staging/commit views much more prominent, which is appropriate considering how fundamental they are to the design, and subsequently makes key functions easier to discover. They also aim to make it really quick to stage, commit and stash changes, since these are some of the most frequent operations that people do with Git: it’s one click to stage a file and another to commit it (well, once you’ve written a commit message).
These designs are currently being discussing these with the gitg maintainers, and may well evolve in the near future.
Open to view the full wireframes
That’s not all
This is just a summary of some of the things that we haven’t got around to publicising in the past, and they aren’t the main priorities that us designers are focusing on. In fact, we are already busy with the 3.20 cycle, working on Software, Nautilus, Polari, Settings, Web, Photos, Music and more, and there is plenty that needs doing in those areas. Nevertheless, if any of these designs do resonate with you, then you should definitely get in touch to help out.
A couple of weeks ago, I had the pleasure of attending a design hackfest in Rio de Janeiro, which was hosted by the good people at Endless. The main purpose of the event was to foster a closer relationship between the design teams at GNOME and Endless. Those of us on the GNOME side also wanted to learn more about Endless users, so that we can support them better.
The first two days of the event were taken up with field visits, first at a favela in Rio itself, and second in a more rural setting about an hour and a half’s drive out of town. In both cases we got to meet Endless field testers, ask them questions about their lives and computer usage.
After the field trips, it was time to hit the office for three days of intensive design discussions. We started from a high level, discussing the background of GNOME 3, and looking at the similarities and differences between Endless’s OS and GNOME 3. Then, over the course of three days, we focused on specific areas where we have a mutual interest, like the shell, search, Software and app stores, and content apps like Photos, Music and Videos.
All in all, the event was a big success. Everyone at Endless was really friendly and easy to work with, and we had lots of similar concerns and aspirations. We’ve started on a process of working closer together, and I expect there to be more joint design initiatives in the future.
I’d like to give a big thank you to Endless for hosting, and for sponsoring the event. I’d also like to thank the GNOME Foundation for providing travel sponsorship.
Over recent months, a fair amount of work has been done on the design of GNOME’s settings. Quite a lot of this work is experimental, but I wanted to share the work in progress and explain some of the reasoning behind it.
A major feature of the latest settings designs is a rethink of the GNOME Settings “shell” (that is, the overall framework of the settings application). We want to move from the current model, that uses an icon grid and fixed window size, to one that uses a list sidebar for navigation, and has a resizeable window.
While icon grids are an established approach for system settings, they aren’t the only solution, and we have encountered limitations with them. The main drawback of the icon grid is that it is hard to promote some settings over others. We have quite a lot of settings, and some are more frequently used and more interesting than others. To make this easy for users to deal with, we want to make some settings more prominent than others, so that users are guided into the interface in a logical way, rather than being presented with a wall of stuff that equally competes for attention.
There are other issues with the icon grid approach. It is difficult to accommodate new settings panels, and some settings don’t fit well into the constrained space of the fixed size window. This also doesn’t work very well on convertible devices (primary windows really need to be maximized when in “tablet mode”).
Moving to a list sidebar and resizeable window will address these issues, and create a much more guided experience where the order of the settings becomes familiar through use. It will also make the Settings application feel much more integrated and like a single unit, rather than being a collection of separate parts. It should make it quicker to navigate and more inviting to browse.
Settings organization: this features a dynamic devices section, and groups the settings sections in order to aid navigation
Moving to a list-based approach for settings involves both design and implementation challenges, and it is definitely not going to happen tomorrow. However, this is the general direction that we are aiming towards in the long term. On the design side, it requires that a number of settings panels be redesigned in order to fit into the new shell. This isn’t actually a bad thing though: most of these panels are in need of some design love anyway.
In what remains of this post, I’ll review our plans for the groups of settings where we have planned changes.
Network
Network settings are notoriously difficult to get right. I think it’s fair to say that the current ones in GNOME could be better, and they’re something that I’ve wanted to take another run at for some time. One particular issue we want to eliminate is the overcomplexity of the settings for simple, common, cases. Many of the more advanced settings could be easier to use, also.
Networking is one area that is heavily impacted by the settings shell redesign plans. We want to split Wi-Fi and Mobile Broadband out into their own panels, leaving a general Networks panel for wired connections, VPN and network proxy settings. This allows the most commonly used network settings to be made more prominent and easier to access, which will make the settings more convenient to use.
Wi-Fi settings, featuring a simple connection settings dialog
Another goal for this panel is to make greater use of progressive disclosure. Again we’re focusing on the common cases, and making them easy – like changing a Wi-Fi password without being exposed to IP routing settings.
Advanced network configuration dialog; the new design condenses six sections down to four tabs
We do also want to improve the advanced network settings too, of course: by making them more compact, reducing the amount of navigation that is required, and making them more straightforward to use.
We’ve wanted to redesign the sound settings for some time, along with a redesign of how volumes work generally. Per-application volumes don’t work well for transient system sounds or when there are lots of multimedia apps open at once (this is especially an issue when browser tabs contain music or video), and the relationship between application and system volume often results in unpredictability. We plan to replace these with three more generic volume levels (media, alerts and alarms), which will merge system and application volumes.
Sound settings, with everything on one page
Another issue that we plan to address is the overcomplexity of the sound settings UI itself. This isn’t necessary for what is actually a fairly simple set of features. It also prevents being able to easily get an overview of the current configuration. These issues are addressed by the new designs.
Displays
The display settings were last updated for GNOME 3.10. These changes succeeded in redefining display settings as not just being about joining displays together. In particular, it put an emphasis on using displays for presentations, where there previously hadn’t been much concern at all. However, this design tends to work best when there are a lot of displays, which is obviously not the most common case, and can be a bit too much work to use.
I’ve therefore recently been experimenting with how to modify the current design to optimise it for the two display case – which is when these settings are most commonly used. These designs are still fairly experimental, and aren’t particularly connected to the settings shell redesign that I’ve discussed above.
Display settings with two joined displays
The new designs attempt to bring the most important settings to the front, without requiring the user to delve into dialog windows every time. They are also structured around global modes, rather than purely consisting of per-display settings: this should make it clearer what’s going on at any one time.
The changes to the Users, Keyboard and Printers settings are fairly similar, and aren’t as sweeping as some of the other design proposals. Each of these settings panels currently includes a selection list of its own, which wouldn’t work so well with the new settings shell that we’re planning. We are therefore looking to remove these selection lists. In some cases this has some real advantages, like in the Users panel, where it enables us to provide a better experience when there is only one user on the system (which is the case a lot of the time). In others it is more of a simple reorganisation.
All of the designs include various refinements and improvements on the existing designs. There are a lot of visual improvements to the printer settings, for example, and there’s improved feedback for changing shortcuts in the keyboard settings.
Conclusion
In this post, I’ve outlined the general direction that we are hoping to take with GNOME’s settings. There isn’t a fixed roadmap for any of these changes, and it might be some time until they are all implemented. However, we are making progress. One part of the plans has been implemented during the current GNOME development cycle, with the new Mouse and Touchpad settings panel, and I’m hopeful that we will continue to make push forward with this in the future.
One reason for publicising these plans when they are still at an experimental stage is to get feedback, so we can improve the designs before they are implemented. So, if you do have any thoughts on this, please get in touch, either through the comments on this post, IRC, or via one of the relevant design pages.
