From Fedora Project Wiki

Pre-Installed App Selection Guidelines

This page provides guidance on the selection of apps for inclusion in Fedora Workstation installs. It is primarily intended for members of the Workstation Working Group, as a resource when reviewing the default app set.

Basic functional requirements for the default app set

The default app set should provide a basic set of functionality that users require from a desktop. This includes:

  • Functionality that is essential to managing and operating the system. This includes the ability to install and remove apps, install system updates and change system settings.
  • Basic system features, including the ability to browse the file system, view disk configuration, and execute terminal commands.
  • Basic user features, such as viewing a PDF, playing an audio or video file, browsing the web.
  • Basic system utilities, for when the user needs help or when something goes wrong. This includes user docs and diagnostic and recovery tools (for example a disk usage analyser and system monitor).

Beyond these basic requirements, the default app set can be selected based on the kind of apps that users tend to expect from a desktop. In general, niche apps should be avoided, and the emphasis placed on generic, commonly recognised app types.

Going beyond basic functionality

As a developer-focused workstation, in cases it may be desirable to include additional developer tools. When doing this it is important not to generate confusion by introducing ambiguous or highly advanced tools. Boxes is a good example of a developer-focused tool which is still relatively accessible and non-confusing.

Design requirements for each app

Apps that are pre-installed should generally be:

  • High quality: the UI should look good, the app should work well, it should have a good quality app icon, should work with accessibility features, be translated, and so on.
  • Consistent: the app's UI should be consistent with the others in the default app set.
  • Integrated: where appropriate, the app should be integrated with the system and with other default apps.
    • Apps should use standard system services and should respect system settings.
    • Apps should be integrated into the desktop: they should appear properly in the desktop, including in gnome-shell and gnome-software.

Application identity

The collection of default apps should largely consist of generic unbranded applications. For example: Music, Videos, Calendar.

Obvious exceptions to this currently exist, including Firefox and LibreOffice. The point here is that the set is easier for users to comprehend if the majority of the apps have simple functional names. It is also good for naming to be consistent across the set, as far as possible, in order to make it easy to browse.

The primary consequence of this guideline is to avoid introducing lots of apps with their own identities, and to avoid introducing apps with ambiguous names or identities.

Apps should additionally follow the icon and packaging guidelines.

Additional goals for the default app set as a whole

When making decisions about the composition of the pre-installed app set, the following considerations should be kept in mind:

  • The default app grid should look good:
    • All rows on the first page should be populated.
    • Avoid uneven grid layouts: pages should have a good number of apps on them, rows shouldn't have more than a couple of apps.
    • Avoid having too many apps (likely not a problem).
  • Be consistent in how classes of apps are treated:
    • Follow logical groupings: for example, if there's a music app, logically there should probably be a videos app too.
    • Avoid having individual apps of a single type - the overall set should appear as a coherent set of subsets.
    • In some cases, it is necessary to consider collections of apps as a single entity. This particularly applies to apps that have functional interdependencies: for example, calendaring, contacts and email often go together.

Legal and practical requirements

  • Obviously should be open source.
  • Should have active development community, with which Fedora has a good relationship.