Platform Support for Design Patterns

All the design patterns in use in GNOME should be easy for application developers to use. They should also be consistent for users. Unfortunately, this isn't always the case: a number of patterns have to be hand-crafted by developers, which makes implementing our design patterns difficult and laborious. It also results in an inconsistent user experience.

The goal is to make sure that every design pattern is fully supported. They should all be easy for developers to use, and consistent for users, as well as delivering a high-quality user experience.

The Process

One part of this that is yet to be decided is how we define which patterns are supported, and where they should be kept. So far the answer to this has been "if something is part of GTK", but this approach isn't always appropriate. GTK also supports design patterns which we don't generally recommend or encourage.

What we can say we want is:

• Every supported pattern included in the HIG, with:
  • Links to the relevant widget or API
  • A screenshot of a reference implementation in GNOME
  • A link to the source code for an example or reference implementation
• A process within which each pattern is used in a small number of applications, then reviewed for code and design quality before being accepted

Pattern Overview

Detailed Notes

Menus

Background:

• Inconsistency in how menus look and behave - some are popover menus and some are not
• It's unclear how developers should implement menus, since there's various ways they should do them

• The design team has new mockups for menus; these would largely involve porting existing context menus to be popover menus

Next steps:

• Some menus have been adapted to the new designs, but there's more work to be done in both GTK3 and GTK4

• Design questions to resolve:
  • Do we want buttons at the top of menus? (User testing is required here.) There might be a few small cases where we want to include this (zoom controls is one). It sounds like these buttons will be supported whether the design advice is to use them or not.
  • Do we want buttons alongside menu items, like in the cut/copy/paste case? It's a handy trick but probably not easy to implement and not something to use generally.
  • Is it worth the extra complexity of being able to configure whether a popover has a point or not? (Initial answers seem to be yes, but it's worth keeping this question in mind.)
  • Sliding sub-menus versus traditional ones: the prevalent design view seems to be that sliding sub-menus are preferable, but there are some challenges that we should be mindful of:
    • Potential inconsistency with menu bars
    • They're relatively constrained and only allow navigating down one level (this is generally advantageous but could be an issue for some)

Lists

Background:

• These are used extensively in our designs and applications (HIG page is here).

• The primitive elements are supported by GTK. However, this doesn't give app developers something close to resembling the design patterns. This results in issues around consistency and difficulty of implementation.

• libhandy has some helpers for lists.

• The design team has updated mockups for list patterns design effort to refine and standardise the list patterns

Next steps:

• Requires feedback from GTK developers on whether the mockups can be supported
• We might want pre-baked composite widgets for the list patterns, so developers can easily create them. These should have standard layouts and styling that can be updated. Other features that we should consider adding:
  • Clicking the list background activating its control
  • Rounded list corners
  • Standard min and max width and responsive behavior for resizing

In-app notifications

Background:

• This pattern is used widely in our apps and designs, but it never landed in GTK and currently resides as part of libgd.
• There are various issues around the quality of our in-app notifications implementation. Sometimes they stack up in odd ways, and the layout is often not what it should be.
• The design that's in use today may not be easy to implement.

Next steps:

• The design team needs to review and iterate on the latest designs

Split header bars

Background:

• These are a standard design pattern, and they are used in a number of GNOME apps, but apparently they are hard to implement in GTK, for technical reasons, and probably aren't part of the header bar widget.

Next steps:

• Sit down with the GTK developers to see what can be done

Dropdown lists

Background

• This pattern is used in our designs but it is hand-crafted every time. It's highly inconsistent in both design guidance and implementation.

• The pattern is documented as part of the HIG. However, these designs are outdated.

Next steps:

• New designs can be found here. They need review by the design team.

Selection mode

Background

• This is covered by the HIG, and there's some support in libgd. We also have a design page.

• One of the challenges with selection mode is that it's a complicated pattern to implement, and isn't covered by a single widget. This makes consistency an issue, as well as updating the pattern.

• There has been some recent design discussion about changing the pattern, and/or changing when it should be used.

Next steps:

• Recent design discussions need to be brought to a conclusion.

Other patterns to consider

• Floating, overlaid controls
• Full-screen windows
• Search

See Also

Comments