Lock, Unlock, Login
Objectives & Requirements
- 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
- Hide the user's session when they are away or have locked it
- Allow accessing the session either with or without authentication (autologin)
- 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)
- Integrate with disk encryption
- Allow selecting a session type when logging in
- Password entry shouldn't be susceptible to brute force attacks
- Allow the distribution to be identified
Discussion & Background
The latest design was informed by some perceived issues with the existing one. These include:
- There are reoccuring 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
- 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.
- 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 eight 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.
- Reduces notifications on the lock screen to a set of app icons with a notification count for each one.
- Shows the distribution name in the top-left corner, both on the lock screen and when entering a password.
Implications for other modules:
- The "show message content on lock screen" notification setting no longer has a role.
- There is no place for a dedicated lock screen wallpaper.
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).
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.