Initial System Setup

After acquiring or installing a new system there are a few essential things to set up before use. It would be nice if GNOME had a simple, easy, and safe way to prepare a new system.


  • Guide the user through essential set up tasks. Configure:
    • Display language and formats
    • Keyboard layout
    • Connect to the network
    • Online accounts
    • User name, password, and enterprise login
    • Time zone
  • Be quick and straight forward.
  • Be welcoming, fun, positive.

Relevant Art


Dynamic name change

The design currently relies on running in a bare user session and changing the user's name and home directory. This has traditionally been problematic. We should investigate exactly why this has been the case and hopefully work to eliminate those issues.

One of the biggest problems with doing any kind of dynamic changes are environment variables. Currently we store the user's name in a few of them:

SSH Login


GDM Login


Tentative Design

Language Selection

  • If geolocation is available, it would be good to set the language based on where you are. In this case, the automatically determined location would be preselected at the top of the list.
  • Distributors and OEMs should be able to change the default language.
  • Since this is the first thing some people will see on a new computer, it would be nice to inject a bit of excitement or interest. One way to do this would be to have "Welcome!" in different languages slide across the window.


  • Available regions are determined from the language. A short list of popular regions is displayed in the list; pressing the "more" button shows the full list of regions for the selected language.
  • If possible, we should use geolocation to select the preselected region.
  • The region setting is used to determine the language variant, formats and input sources.

Input Sources

  • This panel allows one input source to be set. In cases where an input engine is chosen, the associated keyboard layout should be automatically set as a second input source.

  • The panel displays a choice of common input sources for the configured display language and region. For the purposes of initial setup, we assume that the user wants to input the display language. "Alternative" input sources (eg. Dvorak, Colemak) are not displayed as options.


  • This panel is only shown if:
    1. There is no internet connection.
    2. There's a wi-fi interface.
  • The "Skip" button changes to a blue "Next" button once a connection is established.

Time Zone

  • Ideally someone would never see the progress spinner, since we would have already determined the location before the panel is seen.
  • These designs pretend that the time, date or time zone has not been set, even if a default configuration is provided. The clock in the top bar is not displayed until a time zone has been selected through either geolocation or the user searching for a city.

This is displayed if geolocation isn't available, or if it is and we are unable to determine the location:

Online Accounts

  • The "Skip" button changes to a blue "Next" button once a connection is established.
  • We could add a "View More" button on the bottom row of the account type list, but I was wary about making this too complex.
  • This position of this panel in the sequence has been moved forward to allow us to try and pull the user's name and avatar.


  • This step is a bit experimental. Name, password and avatar have been split from setting a password. This is to try and clarify the two aspects of what used to exist in the login step: personal information and access/privacy.
  • If details in this step have been pulled from an online account, the string is changed to reflect that it is more about confirmation.
  • We might want to add additional details to this panel, such as allowing the user to select a default email address if there is more than one online account present.

Enterprise Login


  • Other privacy controls could be added to this panel, like automatic lock.


  • We really need a more exciting graphic for this.

Layout Guidance

Each of the steps should have the same visual layout, which should roughly correspond to the following guidance:

There are two partial exceptions to this:

  • In language selection, the icon is replaced by the "Welcome!" heading, and the list extends up to the top of the title area.
  • Time zone selection has a fairly unique layout, in order to accommodate the map.

Previous Design Iterations

Initial wireframes

Note: "Starting using GNOME 3" closes setup and logs the user in for the first time. It also launches Getting Started.

Selecting 'Show all' expands the list to include all languages (keeps the initial set on top) and replaces the checkbox with a query bar that accepts input immediately, so typing a string immediately filters the list above.

Workstation displays don't show the application maximized.


Why not the installer?

The goal of the installer is to efficiently and safely deliver the product. It is a vehicle not a destination. We should make that trip as brief and as painless as possible. There are many reasons why it is desirable or advantageous to set up the system for the user at the time of first use and not during the install or delivery stage:

  • Reduce the stress of transition by restricting interaction in the foreign installation mode
  • Get on with it - once the decision has been made to install a new OS don't spend any more time than necessary in intermediate modes
  • Support OEM or third-party installations
  • Defer decision making
    • The main thing a user should be making a decision about is where to put the bits. Any other decision is premature.
  • Questions asked during the install often presume knowledge of the resulting system - which is often incorrect
  • Decision making should be linked to a way to change decisions if possible
  • Simplify the mental model of the installation task
  • Avoid performing risky, complex tasks (and code) during critical writes to disk
  • Allow the user to perform fire and forget or unattended installs (click install, walk away, come back, use)
  • Reduce amount of code in the installer since it is rarely or never updated
  • Streamline the first time use experience
  • Avoid having to leave a system installed with either a default password or unlocked account (if the user account is created by another person during the installation)
  • Avoid the need to manually login to the system the first time (when you've just created the user account before arriving at the login screen)
  • Use exactly the same tools and visual experience as the resulting OS
  • Introduce the user to the newly available experience
  • Support performing installation from within different or incompatible OS versions
  • Avoid mismatch of goals between fast install and interactive setup
    • If writing to disk is fast then it is too fast for asking questions
    • If writing to disk is very slow then it is too long to expect the user to sit around and answer questions


* We should have a way of setting the machine name there as well, probably with some translated default (eg. "Foo Bar's laptop" if the person is called "Foo Bar" and the DMI info says that we have a laptop) (BastienNocera)

* We need to figure out what environment this tool gets run in. There's some tricky implementation aspects:

  • If we run it in the session, then session apis are available (e.g. NetworkManager applet stuff), and it is trivial to save e.g. the web account settings. But we cannot change the username while a process with that uid is running, so this doesn't really work

  • If we run outside the session, we need to be careful what session apis we use, and we need to figure out how to store location and web account configuration into the user account 'from the outside'. Creating an account will be easy here, but we have to somehow get the user session started when the tool is done.
  • If we go the 'copy from one account to the other, we have to be careful about references to the username stored in ~/.config. On my system, I counted 665 files below .config affected by this. Thankfully, most of them are session state, which we don't want to copy anyways. All the references I saw were in the form of absolute paths to files in my home directory.

* The current theory is that we run the tool in a special-purpose account, akin to a guest login, and then copy all configuration bits over to the newly-created users home directory when the setup is done. This will need some cooperation from gdm to smoothly switch out of the guest session and into the user session without jarring flickering (ie keep the X server, like we do when going from the login session to the user session).

* Things that need to be running in the session for the setup tool to work:

  • gnome-settings-daemon (to get themes, etc)
  • nm-applet (to get all the wireless dialogs)
  • the web accounts step may need some session service running
  • we need to allow accessibility technologies
    • And a way to access them. Windows8 screenshots shows a accessibility button on each step. Something like this is not included on GNOME drafts
    • Probably also a screen reader keybinding for that special-purpose account. Most installers and the gdm login screen uses Ctrl+S for that.
  • we should try to avoid any polkit dialogs by setting suitable permissions for this special-purpose account, so a polkit agent should not be needed

* What to you do with the special purpose account? Would you delete it afterwards or is that a skeleton for new accounts? (SriramRamkrishna)

* FIXME: What to do for the networking step in case of a workstation with multiple NICs

* What is the point of having next and back buttons placed on the top? In my opionion, it just creates inconsistency as next and back buttons are normally placed on the bottom in GNOME.

* A more exiting graphic for "Complete"


See Also

Design/OS/InitialSetup (last edited 2014-09-05 11:13:52 by AllanDay)