UserAccounts

Differences between revisions 8 and 9
Revision 8 as of 2012-09-12 11:34:14
Size: 5603
Editor: mpt
Comment: italics
Revision 9 as of 2012-09-12 11:44:48
Size: 5647
Editor: mpt
Comment: TBD
Deletions are marked like this. Additions are marked like this.
Line 11: Line 11:
''TBD''
Line 14: Line 16:
''TBD''
Line 16: Line 20:

''TBD''
Line 61: Line 67:
''TBD''

This is an incomplete design for how user accounts should be presented in Ubuntu.

Settings

System Settings should contain a “User Accounts” panel.

Account and group list

TBD

Configuring the guest account

TBD

“Name & Picture”

TBD

“Security”

security.png

If your own account is selected, the heading for the first column in the “Security” tab should be “To identify me, I can use any of:”, and for the second column “To authenticate me, require all of:”. Otherwise, the headings should be “This account can identify with any of:” and “Authenticating requires all of:” respectively.

The various options for identification and authentication may be implemented in any order. When they are implemented, they should appear only when hardware is present that can use them.

Options may be insensitive, in checked or unchecked state, as defined by an administrator. In addition, whenever an identification option is checked, the equivalent authentication option should be unchecked and insensitive, and vice versa, because you can’t use the same option for both.

If an option is currently unregistered (for example, if you have not registered your fingerprints), checking either checkbox for that option should act as if you also clicked the relevant “Register” button.

Fingerprints

For comparison: Fingerprint GUI, Fingerprint authentication in Fedora, Microsoft Fingerprint Reader, Lenovo ThinkVantage, Authentec TrueSuite

Choosing “Register Fingerprints…” should open a “Register Fingerprints” dialog.

fingerprint-register-1.png

In the “First, select a finger to register.” section, the pair of hands should be focusable as a single control, with Left and Right keys navigating between fingers, and Space selecting the focused finger. In addition, the keys 1 through 0 should be access keys for the individual fingers. Any currently-registered fingers should be highlighted in green.

The “Remove Selected Fingerprint” button should be sensitive whenever a finger is selected that has a currently-registered fingerprint.

When the dialog opens, the “Then, swipe it on the reader until registered.” section should be insensitive.

fingerprint-register-2.png

Once you select a finger, the section should become sensitive. If the reader reports a percentage complete, the gauge should reflect that percentage. Otherwise, if the reader reports an exact numbers of swipes required for registration, the gauge should move to the appropriate fraction with each swipe. Otherwise, it should move asymptotically — to 1/2 with the first swipe, 2/3 with the second, 3/4 with the third, etc — until registration is complete. Whenever the gauge moves, it should move bouncily.

fingerprint-register-3.png

When registration is complete, the success sound should play, then:

  1. the “Then, swipe it on the reader until registered.” section should become insensitive again
  2. the hands control should be refocused
  3. the “Repeat with as many fingers as you like.” text should appear. (This should not enlarge the dialog — it should have been large enough the whole time.)

For fingerprint authentication in PolicyKit, see AccountPrivileges.

Smart card authentication

TBD

“Access”

user-accounts-access.png

In the “Access” tab, the “Account type:” menu should contain items for “Standard” and “Administrator”. Whenever the selected account’s access privileges do not match either of those two types, the menu should also contain a “Custom” item that is selected.

The “This account:” list should contain checkbox items for all the configurable privileges.

Whenever “Has mandatory Launcher items” is checked, the “Choose…” button at its trailing end should be sensitive. Choosing it should open a dialog containing a desktop, including a non-auto-hide Launcher containing only the current mandatory items.

mandatory-launcher-items.png

“Launching” an application inside this dialog should not actually launch it, but should add it to the Launcher as a mandatory item. Each configurable Launcher item should have a Delete button overlaid in its top right corner as a badge, with accessible label “Remove From Mandatory Items”. Choosing “Revert” should return the Launcher to the state when the dialog was opened, without closing the dialog. “Change” should be sensitive only when the current state is different from when the dialog was opened.

Back in the “This account:” list, whenever “Has mandatory Launcher items” is unchecked, the indented “Can add other Launcher items” item should be both insensitive and checked.

“Open at Login”

See https://live.gnome.org/Design/SystemSettings/Proposals/LoginItems

See also

UserAccounts (last edited 2016-07-26 15:08:32 by mpt)