gnome – Page 2 – Form and Function

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

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

Enabling Participation

With 3.12 out the door, it’s time to think about what we want to be doing for 3.14. I have a long list of design projects that I want to work on for the next release, but I also want to spend some time on how the GNOME project is working and how we can improve it.

One of my reoccurring interests is how we, as a project, can ensure that each module is in a healthy state. We want modules to have active developer teams around them, and we want it to be easy for people to get involved – not just because it is good for our software, but also because openness is an important part of our mission.

This interest in helping people to contribute isn’t just reserved for new, inexperienced contributors. There are experienced coders out there who are interested in GNOME but haven’t found a way in. Even members of the GNOME project itself don’t always know how to contribute to different apps and modules.

Making it easy for people to contribute takes work. Simply putting the code online is not enough: we need to provide potential contributors with the information they need, and we need to give them feedback and support as they work. We need to enable them to participate by creating the conditions in which it is easy to contribute.

There are a number of reasons why people sometimes find it difficult to participate, and we aren’t going to solve them all overnight. Thinking about this topic, though, one of the main reasons why people struggle to contribute is that it is difficult, if not impossible, to know which tasks to work on. In my opinion, the way that we manage bugs in GNOME is a major factor here [1].

In GNOME we often don’t do a good job of indicating which bugs we want to be fixed, and we don’t spell out what needs doing to fix them. This leaves potential participants with no way to contribute. A long list of unconfirmed bugs, often with no guidance on what needs to be done to resolve them, is a brick wall. It can be the end of the story for potential contributors.

This is the issue I want to address. Interestingly, though, improvements in this area can also help with other aspects of project management: if we are clear about which bugs we want fixing, it prompts forward planning, and it stimulates discussions about which issues should be prioritised over others. It also creates opportunities for conversations about the direction of modules, which can help to include contributors in taking on leadership roles.

To make it easier for people to participate in GNOME, our bugs need to be organised so that they give clear guidance about where contributions are needed. This requires that we have a different process for how bugs are processed and categorised. I’ve spent some time talking about this with various maintainers, as well as members of the Bug Squad, and I have come up with a set of procedures that could work.

This procedure won’t be for everyone, and I am not proposing that GNOME adopts it on a project-wide basis. What I am suggesting is that a small number of applications try it out for the 3.14 cycle as an experiment (I’m focusing on applications because I think they are the best place for new contributors to get involved). If it has a positive impact, then we can think about involving more applications in the following cycle. If it doesn’t, then that’s fine: we’ll have learnt something.

How it could work

The main goal for the bug management procedure I’ve come up with is to remove uncertainty from bug reports. This is something that we are bad at: thousands of ambiguous bugs sit in Bugzilla, which contributors have little chance of knowing what to do with. The procedure uses this schema for bug reports that are on the path to being fixed:

UNCONFIRMED: new bugs that haven’t been validated. These reports are uncertain – they might not correspond to real issues.
NEW: reports that have been validated, and therefore correspond to actual issues.
NEW with “needs_design” whiteboard: valid bugs that are waiting for a design to be produced in order to fix them.
NEW with “available” whiteboard: NEW bugs that are ready to be fixed. These bugs should have an identified solution which has been stated, and they shouldn’t be blocked by other bugs.

In this schema, “available” bugs are the reports that you point potential contributors to. They are items of outstanding work that can be tackled today. You can link to the list of these bugs from your wiki page, blog posts, or IRC topic. Having an available status is also helpful to maintainers: it helps them see which tasks are pending.

This bug schema also makes UNCONFIRMED a meaningful category. These are the bugs that triagers and maintainers need to process in order to give them a definite status. A large or growing number of UNCONFIRMED bugs in your product is a sign that you need to do a sweep through to clean them up.

In this approach to bug management, you need to regularly review bugs that don’t fall into the “available” category, in order to try and resolve them, either by identifying a solution (and therefore making them available) or by closing them as WONTFIX or NOTABUG or so on. It’s a fairly aggressive approach, in which you have to routinely say what is desirable and what isn’t, but in doing so you open the doors to new contributors who know what the project wants and how they can help.

What’s going to happen next

My plan for 3.14 is to trial this bug management approach with a small number of applications. I’m already working with Debarshi on the Documents bugs, which he has blogged about, and I’m also looking at Contacts with Erick. Once one or two more applications are involved, I’ll post an update on how to get involved.

We want to see if this approach helps to attract new contributors and to manage projects more effectively. We also want to see if the bug classification schema needs to be improved in any way. Towards the end of the cycle, I’ll be talking to people to see how they think it went: was it useful? Do any changes need to be made? Would you recommend this approach for other modules?

If you’re an application maintainer and are interested in this initiative, I’d love to hear from you. Also, I really, really want to hear what people think about the classification schema and the process around it.

[1] I realise that, in focusing on bug reports, I am restricting this to code contributions. In doing so, i don’t mean to suggest that patches are the only way to contribute to GNOME. This is merely a way of enabling participation in one – obviously important, but by no means exclusive – area.

LGM 2014

I have just returned home from this year’s Libre Graphics Meeting, which was held in Leipzig, Germany. As always, it was a great event, which is somewhat unique in bringing together art and design practitioners with programmers and engineers.

LGM is a good opportunity to meet with friends in other projects, especially graphics applications. I was really happy to be able to spend time with members of the GIMP and Inkscape projects, and hope that this will lead to closer ties and working relationships in the future.

GNOME and Libre Graphics have a lot in common. GNOME design uses free tools developed by the Libre Graphics community, and we practice open design in the way that many of those at LGM also do. I think that GNOME also helps to bring people into the Libre Graphics community, and it was nice to see a good contingent of people from GNOME at LGM this year. This is something that Jakub and I talked about in our presentation on the last conference day.

The Libre Graphics community is creative and passionate, and I always feel refreshed after LGM. Big thanks to the organisers for putting on another great conference.

Looking Forward to 3.12

I usually do a review of what is coming in the run up to a release. However, there have been so many blog posts about 3.12 already that I don’t feel I need to go over individual features. If you haven’t read Planet GNOME in a while, now is a good time to check it out: there’s lots of great content on there right now.

It is worth looking at what the individual features in 3.12 add up to though. A release is more than the sum of its parts, and this is especially true of 3.12.

One important thing you will see in 3.12 is that, more and more, GNOME’s core applications are coming together. Videos will look and behave like a GNOME 3 app: it will let you browse your content, and it offers a modern, streamlined viewing experience. gedit has also had the GNOME 3 treatment. It has retained all its existing functionality, but in a more compact interface [1]. Many of the other apps have also matured of course, Software and Web in particular.

The other big news for 3.12 is that a number of significant gaps have been filled in. For a long time people have wanted to be able to manually organise their apps: now they can with the new apps folder feature. We’ve also added functionality to make installing sofware updates easier and more convenient, as well as the addition of wired networking controls to the system status area.

There are also major developments in the developer space, with the new notifications API, new GTK+ widgets, new capabilities for launching processes, and improved documentation. I think that 3.12 is probably our strongest for developers in a long time.

Finally, and for me perhaps most significantly, 3.12 looks set to be the best quality release so far. Signs of ongoing improvements are everywhere. There are performance gains for startup and (hopefully) memory usage, the theme and animations in the shell has been refined in quite a few subtle ways, high-resolution display support has been extended, and a great many bugs have been fixed. As each release comes and goes, GNOME 3 gets better and better, and 3.12 is no exception.

There’s plenty more that I could mention about this release, of course, and the release notes will provide full details, but what is important is the progress that GNOME is making. 3.12 feels like another significant upgrade, and is another release where it feels like things are coming together more and more.

[1] The other day I did a quick comparison, and found that the chrome in the new version is around 60 pixels shorter than before. That’s an impressive space saving, and makes the app much more focused on what you are editing.

Popovers & You

GTK+ has been getting some really nice new features in recent times. Over the past few releases the list new of widgets has come to include things like ListBoxes and FlowBoxes, stacks and stack switchers, revealers and header bars. Now, in the upcoming 3.12 release, there will be another new widget: popovers. This is something that those of us who work on GNOME design have wanted for a while, and it’s exciting to finally have them.

Of course, once you have a new interface widget, you need to know what to do with it, so I thought I’d write a bit about how to design with popovers. If you’re an application developer or designer and you’re not sure what popovers are for or how to use them, then this post is for you.

What is a popover, anyway?

popovers

Popovers are containers that appear over a parent window. They have some significant characteristics:

They are generic containers, meaning that they can contain a variety of widget types (just like a dialog).
They have arrow points which are always directed at a specific interface element. Often, this is a button, icon or thumbnail, and the popover appears when this is pressed. (This isn’t always the case though, as one of the later examples indicates.)
They cannot be moved and have a fixed position.

Popovers are used to show additional controls or information. As such, they are an example of a widget that allows you to practice “progressive disclosure” in your application. This essentially means hiding non-essential or infrequently used interface elements slightly out of the way. Progress disclosure helps to keep your UI focused by giving more attention to the most important elements. As my favourite part of the HIG states:

“Every extra piece of information or interface control competes with the truly relevant bits of information and distracts the user from important information. Hence, don’t clutter your interface, and don’t overload the user with buttons, menu options, icons, or irrelevant information. Instead, use progressive disclosure and other techniques to limit what the user sees at any given moment.”

The next time you are adding extra controls or information to a UI, you might want to think: “maybe I should put this in a popover”.

When to use popovers

Popovers are one of a number of ways to achieve progressive disclosure, and there are a number of other widgets that can be used in a similar way. In particular, they are similar to dialog windows, so you might find yourself being uncertain about whether to use a dialog or a popover. There are a few things to consider here.

What is the size and complexity of the content you want to display? A popover should generally be small and simple, so if you have a lot of information or controls to disclose, a dialog window is often better: they are nicer than popovers at larger sizes, and you can use tabs to break them up into sections.
Is there a specific element that can act as the source of the popover? If the answer is no, you should use a dialog, since they don’t have to point to something.
Do any of the established conventions for dialogs apply in this case? There are certain interaction patterns where dialogs are the established convention, such as presenting confirmation checks or application preferences. It is best not to abandon the conventions that people are familiar with for dialogs, as this will help your users understand what is happening.

If you can answer these questions and a popover still seems like a good idea, you may well want to use one. In fact, popovers have a number of advantages over dialogs when used correctly. They aren’t as disruptive, since dialogs require a bigger focus shift and give the users more new UI to interpret. In contrast, popovers don’t change the frame in which the user is working, and are generally a more subtle visual presence. This involves less severe context switches and a smoother user experience.

Examples

We’ve been utilising popovers in our application designs for some time, so I thought that it might be instructive to end this post with some examples from our mockups. Hopefully this will give you a better idea about some of the possibilities they present.

A filter menu

This is taken from our mockups for a new character map application. Here a popover is used to allow a filter to be selected for the view (in this case, selecting a font). In the past we would have had to have used a combobox or a dialog for this. A popover is better than either option: it is easier to scroll and search than a combobox, and less disruptive than a dialog.

Note that the popover header shown in this mockup currently isn’t possible, although you could implement something quite similar without it.

Gear menus

Gear menus are a common pattern in GNOME applications. Previously we have used a menu that is activated by a button for this. Popovers are a much nicer way to present a button menu though. Not only can popovers be used as a simple replacement for button menus, but you can also supplement the menu with other controls. In this example, taken from our latest Nautilus mockups, the menu has been prefaced with a pair of buttons and a slider. This makes the menu more compact and interesting, and the slider is a more appropriate control for setting the zoom level than menu items.

A word of caution when using popovers in this way: be careful not to make the popover too complex by loading them with lots of different types of widget. As a rule of thumb, use no more than three different widget types.

Editing Selections

One really nice way to use popovers is for editing controls. Here, the popover can appear in relation to the selection. The great thing about this is that it avoids showing controls until they are needed, so you don’t have toolbars full of insensitive buttons. It also emphasises the context specific nature of the controls that are being presented.

You can already see how this can work in the Notes app, which has had its own popovers implementation for a while. Here’s one of our early mockups for that:

And here is a similar pattern for Sudoku controls:

Have Fun!

Popovers are an extremely flexible widget, which means that they lend themselves to creative design. They are a really nice way to inject interest and originality into applications, I’m really looking forward to seeing how people end up using them. If anyone has any questions about how to design with popovers, I’d be happy to offer advice.