Notify me

Over the past several GNOME releases, we have been aiming to stabilise GNOME Shell as much as possible. We have been largely successful in this: the last major UI change was in 3.10, when we introduced the combined system status area, and the main improvements in the recent 3.12 release were for performance and bug fixing. This is a good thing. At the same time, there is one area where a number of us still feel that bigger changes are needed. This is notifications, particularly the Message Tray.

In this post, I’m going to present a new set of designs for notifications and the Message Tray, which we’re hoping to implement for the next GNOME release. As ever, these aren’t set in stone and are in a state of evolution. The aim of publicising the designs is to get feedback so we can improve them.

A bit of history

The original notifications design for GNOME 3 was introduced with 3.0. One of the main features of that design was being able to take actions directly from notifications. There was also an emphasis on integrated chat – you could reply to messages directly from a notification, and you could (and still can) see your conversations in the Message Tray and post to them from there. This feature influenced the basic design of the tray, which was structured as a set of “message sources” that you can interact with from the bottom of the screen.

The first iteration of the Message Tray implementation had some UI bugs with it, which we sought to address with a design update in 3.8. Despite these changes, we have continued to encounter a number of issues with the design of the Message Tray, and I think it’s fair to say that the tray hasn’t been performing as well as we’d hoped. Reasons for this include:

  • The layout of the tray as a strip of icons means that it doesn’t communicate a lot of information when it is first opened. It also makes it hard work to use, since each notification source has to be individually opened to get more information.
  • The tray is too difficult to open with a pointer, as it requires a lot of downward pressure against the bottom screen-edge.
  • There isn’t a way to quickly see how many notifications are in the tray, and there’s no reminder provided about waiting notifications.

Addressing these issues requires that we rethink the overall design of the Message Tray. This is also an opportunity to address a range of smaller interaction issues with the existing design.

This said, the original vision for notifications in GNOME 3 has some very positive aspects, which we want to preserve. Being able to directly act on notifications is a powerful feature, for example. The combination of a minimal message banner (the initial notification popup) which can be expanded is also good, as is the concept of having a tray where outstanding notifications can be viewed and interacted with.

Design goals

Before I get into the details of the design itself, it’s worth talking a little bit about the goals and principles behind it. As the new design has evolved, a number of themes and objectives have emerged, and reviewing these helps to clarify what the design aims to achieve. These goals include:

  • Be immediately useful. We want the tray to instantly provide useful information, and we want it to be possible to act on notifications straight away.
  • Make use of physical affordances. In particular, we want to make greater use of the screen edge when using the pointer. This should make interacting with notifications and the tray easier.
  • Sequential ordering. Notifications occur in time. Reflecting this in the layout of the Message Tray means that it will provide a more accurate representation of your notifications.
  • Advertise interactivity. Some interactive parts of the existing design often haven’t been noticed. We’ll be making these much more obvious with the new design.
  • Consistency and simplification. The existing design has been a bit burdened by its complexity, particularly because notifications are organised into different message sources. With the new design, we are pushing to simplify the design as much as possible. This should help to reduce the number of bugs, as well as improve usability, since we are aiming to ensure that notifications have a consistent appearance and layout.

The final goal is one that was at the core of the original design, and which is central to the design of GNOME 3 as a whole: that is, to be noticable and useful without being distracting. Wherever possible with GNOME 3, we have tried to produce a distraction-free experience which helps you concentrate on the task in hand. This requires a fine balancing act, which can be tricky to get right. With the new designs, we want to change that balance slightly, by making notifications a bit more noticable and by providing more effective reminders, but we still want to retain the emphasis on avoiding distraction.

A new design

The new design that we’re hoping to implement for GNOME 3.14 has been evolving for a while. There’s been a lot of experimentation in the design space, and quite a few concepts have been evaluated and thrown out. The design that is described below is the current state of that process. Since notifications can be quite complex, there are a lot of details involved. If you’re interested, there is plenty of information on the wiki.

The Message Tray

message-tray-drawer

The most striking change with the new design is the introduction of a completely new Message Tray. The previous Message Tray design presented message sources as a set of icons in a strip along the bottom of the screen. With the new design, the tray contains a list of notifications, and slides up from the same bottom screen edge. This allows simplification, since the notifications are no longer reorganised into a set of message sources. The list is time-ordered, reflecting their sequential nature. It is also immediately useful, since you can see information about each notification straight away.

https://www.youtube.com/watch?v=C4TzqY0Ct90

The new design also changes the way that the tray is opened. Hovering or pushing on the screen edge will cause the tray to peek up, along with an indication of the number of notifications in the tray. Clicking the visible portion of the tray will cause it to open and a second click will cause it to hide again. The peeking tray, along with the notification count, will always be visible in the Activities Overview, in order to provide a reminding function.

This aspect of the design is intended to provide a quick way to check if you have missed any notifications, as well as to quickly inspect the contents of the tray itself. We also want to make the action of opening the tray much easier than it is now.

Lock Screen

lock-screen

One of the primary goals of the lock screen was to show missed notifications when you return to the computer. Designs for expanding the role of lock screen notifications have existed for some time, particularly with regards to being able to activate notifications from the lock screen. I’m not sure whether we’ll get chance to implement this aspect of the design for 3.14, but it should be said that the new design makes an effort to make the Lock Screen and Message Tray notifications as consistent as possible.

Notification banners

banners-dissect

The existing formula for notification banners remains the same with the new design. Some aspects of the layout have changed, however: this enables them to have a consistent layout, irrespective of whether they are presented as a popup, are in the Message Tray, or are on the Lock Screen. The banners are bigger, which makes them more noticable.

expanded-banners-dissect

Expanded banners also remain fundamentally the same, albeit with a modified layout. Buttons are now flush against the screen edge, making them easier to target with a pointer. We also plan to use hover states more readily, in order to communicate interactivity.

Next steps

Everything I have presented here is currently being treated as experimental. Jasper has an initial implementation in the works, which we are already testing, and are going to continue evaluating as it is developed. As usual, the design might change as we try things out, and we’ll only merge this into 3.14 if and when we feel that it is worthwhile.

You can help us to develop the designs with your questions, comments and feedback.

GNOME.Asia 2014

I just got back from a great trip to Beijing, for GNOME.Asia 2014. This was my fourth GNOME.Asia, and I’ve been to every event since 2011 in Bangalore, where I participated in the GNOME 3.0 hackfest. It was great to meet up with the GNOME.Asia crew once again. They’re a fantastic bunch, and it’s always a pleasure to meet friends from Asia. Photos from the event can be found on Flickr.

This year’s GNOME.Asia was co-hosted with FUDCon APAC. Combining the conference with another event worked really well, in my opinion, and helped to boost participation and share the organisation workload. This could be an effective formula for future events.

On the Saturday I gave a talk about sandboxed applications for GNOME. This is something I’ve been working on recently (I’ll blog about it soon, I hope), and I think it’s an important topic, so it was good to get the word out. In general, I thought that the talk went pretty well, and it was a good opportunity to present our plans to Lennart Poettering and Kay Sievers.

Highlights from the conference included Lennart’s keynote on systemd and David King’s talk on GNOME 3 application development. We ended the conference with a really nice discussion about the GNOME Foundation. It was great to see so much interest in how GNOME operates.

Many thanks to the GNOME Foundation for sponsoring me to attend this event. I’d also really like to thank the conference sponsors.

DX Hackfest

Last week I participated in the 2014 Developer Experience Hackfest. It was a great event – it’s so useful to spend time focusing on this important area, and it was an invaluable opportunity to move existing work forward and agree on plans. We should definitely ensure that we have a developer experience event every year.

My personal priority for the event was to plan the future of GTK+, particularly so that it supports the GNOME 3 application designs we have. We have come a long way in this area, but there are a few outstanding design patterns that aren’t fully supported by the toolkit. Adding support for these will not only make it easy for people to create GNOME 3 style applications, but it will also enable us to publish a new version of the HIG.

During the hackfest we spent an afternoon reviewing GTK+ support for the various application designs we have, and identified the priority items that we need to take care of. We seem to have a clear plan in this area now (more details on this to come). I’m really happy that people have signed up to work on the most important tasks. Hopefully we will have support for all the key application design patterns in the not too distant future, which will enable an initial version of a GNOME 3 HIG to be published.

Another area I spent a bit of time on during the hackfest was developer documentation. I worked with Kat and Dave to clean up the material on developer.gnome.org, and I did a bit of tidying of the platform overview. This work should tie in with the advances we’re making on API reference documentation.

I’d like to say a big thank you to Chris Kühl and Endocode for hosting the hackfest. They have a great space, and were very hospitable hosts. Many thanks also to the GNOME Foundation for sponsoring the event – many of the participants would not have been able to attend without this support.

benjamin-and-cosimo

documenters

hackers

jon-and-jakub

GNOME Developer Experience Hackfest, 2014 Edition

I’m about to travel to Berlin, to attend the 2014 GNOME Developer Experience Hackfest. We have about 22 confirmed participants, with a nice spread of expertise from both GTK+ to developer documentation.

Last year we had a great Developer Experience Hackfest in February, and the hope is that we can keep this going by having a similar event every year. Developer experience is important, and we want to keep focusing on making it really easy for people to make applications for GNOME.

It is a significant time for the GNOME developer experience right now. GTK+ has been getting a lot of major improvements, and our application developer platform is improving in general. People are working hard in this area, and the result of that work is beginning to show. There are still some rough edges and missing pieces, of course, and I’m hopeful that we can use this event to coordinate, plan, and gather momentum to get deal with those.

Huge thanks to Endocode (particularly Chris Kühl) for providing the venue for the hackfest, and to the GNOME Foundation for sponsorship. Expect updates as the event unfolds.

Contributions Welcome

If you are interested in coding for GNOME, but haven’t figured out what to work on, this post is for you.

In my last post, I described an experiment that I’m running for the GNOME 3.14 development cycle. The goal is to make it easier of people to contribute to GNOME, by making it easy to find tasks to work on and getting rapid and effective feedback.

Since I wrote that post, I’ve been working with a number of GNOME application maintainers to get their bugs in a state where it is easy for people to contribute. The result is three apps that have a clear set of bugs that contributors can get to work on today.

Music

Music Screenshot

The Music app has been around for a couple of cycles now. It is currently fairly basic, but manages playback fairly well and gives a really nice view of your music collection. This cycle some big new features are planned, like new and improved search and Last.fm integration.

Music has a great development team around it, and is written in Python.

As of today, there are 32 bugs that are available for contributors. Every one of these is in a state where you can get to work on them, and they have all been reviewed by Vadim (the Music maintainer) and myself – so you can be sure that they are things we want.

Some of the bugs are small and address UI niggles, like bug 723144: which aims to give the Artists view a consistent visual style to other sidebars in GNOME. Other bugs are for bigger features, like allowing you to view and play music stored in ownCloud instances. There’s plenty to choose from, and there should be a bug to suit your tastes.

Music is a really promising app, and there are opportunities to play a serious role as it matures.

Documents

Documents Screenshot

Documents is one of the original GNOME 3 applications. It has come a long way, and has a lot of cool functionality. I’m not sure that people have made the most of this app in the past, but I think that its utility will become much more obvious with a few changes we have planned, particularly when managing document collections.

Debarshi Ray is currently leading the Documents effort. He’s a great guy and an active maintainer. The application is written in JavaScript.

There are 43 available bugs for Documents. They include functional enhancements that will make the application much more useful. Adding the ability to sort documents in different ways is one of these. Another is making the list view more usable.

We also have some nice UI polish planned, such as using a popover for search options and having a smoother full screen mode.

Contacts

Contacts Screenshot

Contacts is one of the older GNOME 3 apps. It is written in Vala, and is maintained by Erick Pérez Castellanos, who is awesome.

This is a nice app that can really shine with a bit of work. Right now there are 60 bugs that are available for contributors. Again, there’s lots of small UI issues: in the spirit of Every Detail Matters, these fixes would make a big difference to the overall user experience. For example:

  • Bug 696384 – porting the contact linking suggestion box to GtkActionBar.
  • Bug 699319 – making the app look better when you don’t have any contacts.
  • Bug 703201 – allowing users to select contacts using the right mouse button.

There are also some fun bugs that will hopefully make Contacts a bit more engaging, such as showing maps and status messages from contacts.

What Next

If you want to get involved in GNOME, these applications, and the lists of bugs I’ve pointed to, are the best place to start. The nice thing about these apps is that small fixes will go a really long way, and they all have active maintainers. It would be fantastic if people could help us to make them shine for 3.14.

If other application maintainers want to get involved in this initiative, just get in touch or follow the procedure I described in my last post.