Platform Support for Design Patterns

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

This page aims to track areas where our designs and the platform are out of sync, with a view to resolving the issues that are identified. For each problematic design pattern, we need to figure out a plan, where the options include:

  • Adding support for the pattern to the platform
  • Adjusting the designs to make them easier to support
  • Dropping the design pattern

In the future, we want to ensure that, for every design pattern in the HIG, we have:

  • Links to the relevant widget
  • A screenshot of a reference implementation in GNOME
  • A link to the source code for an example or reference implementation

Pattern Development Process

One thing we've discussed is defining a process for rolling out new design patterns. This aims to ensure that we don't widely adopt patterns before they are sufficiently mature. It could look something like:

  1. Initial development: the pattern is designed and implemented, with iteration and testing happening to get the UX up to a good level. Ideally the new widget would only be used in a single place at this point.
  2. Staging: the pattern is adopted by ~3 applications, in order to mature its API and featureset.
  3. Publishing: once staging is complete a further review takes place before the pattern is made generally available. This would take into account all the standard GNOME things, including accessibility, internationalization, UX and code quality.

Problem Patterns

Design patterns that are out of sync with the platform.


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

  • Modify the popover menus to match the mockups (Gitlab issue)

  • Design questions to resolve:
    • Do we want buttons at the top of menus? (User testing is required here.)
    • 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)
  • Improve documentation and examples for creating menus
  • Start an initiative to ensure consistency in design and implementation across GNOME



Next steps:

  • Requires feedback from GTK developers on whether the mockups can be supported
  • Create 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

Platform status

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.

Design status

The design that's in use today may not be easy to implement. There are some updated designs, which aimed to be easier to implement, however these were never fully agreed on. It would be useful to get input on this from the GTK side.

Split header bars

Platform status

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.

Design status


Option lists

Platform status

This pattern is used in our designs but it is hand-crafted every time, leading to quality and consistency issues. The pattern is also documented as part of the HIG. However, these designs are outdated.

Design status

There are some old designs which never landed. These need to be refreshed and revisited. We should try and simplify them.

Other patterns to consider

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

See Also


Design/Whiteboards/DesignPatternReview (last edited 2019-04-12 14:09:32 by AllanDay)