Re: [Usability] Reviewing users-admin's new UI

[Milan Bouchet-Valat <nalimilan club fr>]

Le mercredi 02 décembre 2009 à 23:01 -0500, Philip Ganchev a écrit :
> Thanks for your work! I am not familiar with the rationale for the
> design. There is already a good "Users Settings" dialog in Ubuntu
> (maybe also other distros);[1] why not use of modify that, instead of
> redesigning it completely? Its child "Account Properties" dialog has
> the advantage that it has tabs (Account, Contact, User Privileges, and
> Advanced), which are a standard UI component.
Hmm, maybe I've not been absolutely clear: I've actually taken
maintainership of the gnome-system-tools recently, so what I was talking
about in my mail is users-admin, the tool you're referring to in your
screenshots. So yes, I've "used and modified" it, to make it more user
friendly - and the new design allows us to fix important bugs too.

> As near as I can see, the new design does not allow a way to set phone
> numbers, specific user privileges (monitor system logs, connect to the
> Internet using a modem, etc.), the home directory, or the login shell.
Yeah, that's why I've kept those tabs from users-admin, and put them into
an Advanced Settings dialog. We don't want all users to be confronted with
this kind of settings, but advanced people should be allowed to tweak
them.

> Also, it would be better to avoid the additional dialog boxes for
> setting the name, account type, email address, language, location, and
> (maybe) the password. I know this is more work to program, but it
> would be clearer and less manual work for the user. The dialog window
> could use combo boxes and text fields like this:
> 
>          Real name: [ Orville Redenbacher       ]
>           Username: [ orville                   ]
>       Account type: [ Standard user (Recommended)  v]
>           Password: To be set at next log-in [Change...]
>     E-mail address: [ orville gmail com       ]
>           Language: [ English (US)  v]
>           Location: [ Westford, MA, USA ]
>  Parental controls: [ Not enabled  v]
> 
> 
> The fields "Real name", "Username" and "Email address" are text
> fields, while "Account type", "Language", ("Location"?) and "Parental
> controls" are combo boxes that are expanded when clicked, like this:
> 
>       Account type: [ Standard user (Recommended)  v]
>                     | Administrator                 |
>                     | Guest                         |
>                     +-------------------------------+
> 
> (By the way, "Parental controls" should have the correct letter case.)
The rationale behind separate dialogs is multiple. First, this allows us
to present the user with more information than currently. For example,
the Account type dialog shows descriptions of every profile, meaning
that people understand what Administrator means (I've bug reports
complaining about that being obscure currently).

Second, this allows the main dialog to show an overview of all principal
settings without being completely overwhelming for the user, which is a
reproach I'd address against the current users-admin UI with tabs. Spot
the setting you want to tweak, see it's current value, click on Modify,
and then consider the options you have. generally you only change one
setting at a time, so better hide complexity away.

Third, implementation-wise, exposing all the settings at once in a
dialog forced us to commit back all the data, which makes it more
complex to handle. When creating users, we had to pre-fill the UID, home
dir, etc, which does not allow us to ask the backends to use system
default settings. The new design ensures we don't change all settings at
once, thus we can more easily detect errors (this was and still is a
kind of mess to debug).

Fourth, PolicyKit really fits better in the new design. We don't have to
show the lock button, which was confusing users and making GNOME feel
stupid ("why should I click there myself?", "why is that dialog greyed
out?"). We can ask for authentication when clicking on Modify, while
still showing the settings to all users, getting rid of greyed widgets
that are hard to read. And if the user cancels authentication, we don't
have tried to commit any changes at all - previously, the changes made
would still be kept by users-admin, and would be applied if you
succeeded committing any other change later. (Note that for now
authentication is performed when closing the dialog, but that will be
fixed soon.)

> Setting the password probably should still be done in an additional
> dialog or tab, because it has so many controls. The design document
> shows two such dialogs, and I think the first one is unnecessary; use
> the second one only.
I don't think there are two dialogs on the document. The different
mock-ups only represent the same dialog when different options are
selected in the combo box. Anyway, for now the password dialog merely
consists in the old password widgets, because, you know, I sleep the
night too. ;-)

I'm not sure what options from the mock-ups I'll implement, since not
all of them are easy to code, and some are more useful than others.


Regards