Lock, Unlock, Login

Design for the lock screen and login experience. This supersedes the previous lock screen and login pages.

Goals

High-level goals:

• Privacy is paramount - communicate it
• Be an effective brand touch point and defining microinteraction
• The lock screen should be useful - show useful information, allow appropriate interactions
• Make access to the user's session as frictionless as possible
• Differentiate between the user's personal session and the system context
• Provide a clear spatial model, so users can orientate themselves

Detailed requirements:

• Hide the user's session when they are away or have locked it
• While the screen is locked, show:
  • The date and time
  • Media controls
  • System status
• Indicate when smart card or fingerprint authentication is available
• Allow logging in as a different user
• Scale between different usage scenarios:
  • One user
  • Small number of users (1-6)
  • Networked environments, such as shared office workstations and labs
  • Kiosks, such as libraries
• Show login messages from sysadmins (these can be long, and are required for regulatory purposes)
• Allow the distribution to be identified
• Password entry shouldn't be susceptible to brute force attacks
• Various features that need to be supported:
  • Autologin
  • Disk encryption
  • Session type selection
  • Big long messages from sysadmins
  • Show time/date of last login

Constraints

• Some systems can have 100s or 1000s of local users (the accounts get copied to the machine).
• PAM is quite flexible in the types of authentication that it can enable, and it's modular. (For instance, there's a PAM module that requires the user to play rock, paper, scissors). It's unclear how this relates to the design - we might just have to ignore particular configurations - but it's worth bearing in mind.
• Currently, doing autocompletion on user names or search for user accounts would be very slow. It would require architectural work to make it possible.
• If user accounts are stored remotely, it isn't always possible to know how many there are.

Relevant Art

See lock screen and login screen.

Discussion & Background

The latest design was informed by some perceived issues with the existing one. These include:

• There are re-occuring issues around the discoverability of the interaction for raising the shield

• Notifications don't get seen on the lock screen if you wake the computer by typing bug 776116.

• It isn't an effective touch point - it's not delightful
• The user list doesn't scale to large numbers of users. Nor does it look good for one user
• Notifications:
  • In their default form, these don't provide a lot of information for a lot of visual noise
  • New notifications are "replayed" after the session has been unlocked, which reduces their usefulness on the lock screen
  • Screen wake ups can be inappropriate, for example in office environments
• It's high-friction - it's a disruptive visual transition from the wallpaper to the grey login screen
• It can be disorientating - there are a lot of paths, and it's not always clear how they connect.

Some more notes on this are available from the 2017 UX Design hackfest.

Tentative Design

Key features:

• Shows the login screen for the last used user by default, without the need to select a user.
• Uses a spatial model, supported by animated transitions, to integrate the different parts.
• User selection doesn't show more than 12 users. If there are more than this, it allows a user name to be entered in addition to picking one from the grid.
• Allows graphical user selection to be disabled, in which case the user can be selected by entering a username.

Static mockups:

• Navigation map

• User selection

• User selection grid layout

• Username-based login

• Lock screen

Motion mockups:

• Lock/unlock

• Boot to login

Implications for other modules:

• There is no place for a dedicated lock screen wallpaper.

Outstanding tasks/questions

• Visual guidance for how admin messages should be displayed.

• Should it be possible to activate a notification, in order to go to the source after login? (If so, how?)

• Guidelines for notification placement, motion, overflow.

• The design incorporates a guest session, but there's been no surrounding design work for this. (Removed for now.)

• Handling of urgent notifications, either from system components ("system is on fire"), (special-cased) desktop components ("calendar notifications"), or third-party applications ("call inbound")

  • gnome-shell already special-cases urgent notifications by showing their contents

  • gnome-shell has an internal only urgency level for chat notifications, maybe we could reuse that for third-party apps receiving calls?

• What to show on non-primary monitors?
• If the display isn't locked and the screen is woken up, should we automatically remove the shield and go straight to the session?
  • This would go with the idea of accessing the session with as little friction as possible.
  • However, it could potentially lead to stray input reaching the session.
  • It also means that users wouldn't see notifications on the lock screen (although they would be replayed in the session).

• How to handle autologin, if it's even desirable.

• Can we always get the user's name, avatar and background for login? What do we do if we can't? What about things like logging in as root?

See Also

• Lock screen design page

• Login screen design page

• 2017 UX Design Hackfest

Comments

• There's an privacy consideration to eliminating the user lock screen wallpaper - currently the user's "Background" wallpaper is "private", i.e. not shown until they've authenticated/unlocked.
  
  If for instance the user's thing is to have some saucy background (surprisingly common, if you've ever done a stint in computer repair!) this change could unexpectedly reveal it to the world (i.e. if they're currently using something else for the lock background).
  
  This could be avoided in an implementation of the concepts by retaining the current separate DConf keys and just setting them both when using any new background selection UI, or selecting the user's current "Lock Screen" background for everything when migrating to a single background.
  
  Alternatively, the background selection UI and DConf keys could be left as is, and the "lock screen" wallpaper used for all the relevant places in the mockups.
  
  To be honest, it's not necessarily clear that "There is no place for a dedicated lock screen wallpaper" is true in order to achieve the above design though - it seems orthogonal.