This specification covers design and implementation details of the Login Experience in Ubuntu Lucid. Proposed solutions will affect the structure, look&feel and functional aspects of the GDM greeter (login screen).

Release Note


The new gdm will provide an easy-to-use, personalised login interface which, while improve the user experience, will make the login process easier to learn and less prone to user errors.

It'll also provide important accessibility features.

User stories

* John has just bought a new Ubuntu laptop, but does not want to log in automatically, for security reasons.

* Jan and Ania have a shared desktop computer, also used by their 3 children, aged 8, 10 and 14. Every child has his own non-admin account, while Jan and Ania want log in as admins.

* Ali is studying at the university, where she can access her account on the network computer. She prefers to set her session language to Spanish, as it's her first language.

* David is using his private laptop for work and logs in to his local account and remote accounts via XDMCP.

* Maria is blind, and she occasionally uses her boyfriend's laptop. She needs to launch the screen reader when she logs in.



The new login experience should seamlessly conjoin with the newly designed boot experience and provide a smooth transition between the system startup screen and the user session.

Login screen with user picker and more than one user account

If the login screen has been configured to display the user list, and there is more than one user account, the user names should be displayed in order of login frequency, with the currently logged in users at the top.

The login screen should also consist of:

  • Accessibility icon, providing access to the accessibility options dialog
  • Login options menu, providing access to:
    • Automatic login settings dialog
    • Language selection dialog (disabled until the user is selected)
    • Keyboard layout selection dialog (disabled until the user is selected)
    • Session selection dialog (disabled until the user is selected)
    • Remote login options dialog
  • Power icon, providing access to the power menu with the following options:
    • Shut down
    • Restart
    • Hibernate
    • Suspend

The list should display maximum of 6 users at a time, if there is more than 6 user accounts the list should scroll down.

The user name displayed at the top of the list should not be selected by default. Pressing Enter should result in selecting the user from the top of the list, unless any other menu item or button has been manually highlighted.

User should be able to filter the list by typing in the first letters.


When the user makes his selection, the window should morph vertically to display just the selected username and a focused password field.




Login screen with authentication error

If the user enters incorrect password, the following message should appear:

"The password you have entered was incorrect. Please try again."


Login screen with user picker and one user account

If there is only one user account, the user list should not be displayed, the password screen should appear right away instead. The password screen would not include the "cancel" button any more, as there is no preceding step. All other elements should remain unchanged.




Login screen with username/password manual entry

If the login screen has been configured to not display the user list, the screen should consist of the username input field (focused) and the password field below. All other elements should remain the same.




Power options menu

The power options menu should consist of the following options:

  • Suspend
  • Hibernate
  • Restart
  • Shut down




Accessibility options dialog

Should use the current gdm implementation.

Automatic login settings dialog

Current design here: https://wiki.ubuntu.com/Spec/GDMConfigureTool

Language selection dialog

Should use the current gdm implementation.

Session selection dialog

Should use the current gdm implementation.

Remote login dialog

Should use the current gdm implementation.


This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.



  • data migration, if any
  • redirects from old URLs to new ones, if any
  • how users will be pointed to the new way of doing things, if necessary.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

Community artists proposals

I think that some proposal worth to be taken into account (even some of them include boot process as well, there is a part for login).

proposal #1


DesktopTeam/Specs/Lucid/LoginExperience (last edited 2009-11-19 16:28:38 by mat.t.)