Hi,
I'm working on a new user creation module for the new and improved firstboot. I created a little video to give people an idea of the UI interaction:
http://bagu.org/scratch/createuser.ogv
One open issue that I have is that I'd like to require that a user account be created by greying out the 'next' button until the information requested is complete and correct.
If requiring a user account be created is not the best approach, what is the best way to allow the user skip this step? An initial idea I had was to grey out the 'next' button only when the user starts to enter information. The problem with this approach is that it's not easy for a user to cancel out of the account creation if they start the process but decide halfway through that they don't want a user account anymore. Any thoughts or comments would be appreciated.
I've also been looking into using cheese to allow users to take a snapshot of their face with a webcam when they are creating their account in firstboot. The stock_person button in the video posted above would activate a dialog for this. I sent a message to cheese-list and one of the developers suggested that a dbus interface might work for this task.
I created a mockup of what the interface for choosing a user image could look like:
http://bagu.org/scratch/create-user-file.png http://bagu.org/scratch/create-user-webcam.png
As you can see, there is a video preview from the webcam in the second mockup. I don't know dbus well enough to comment on if it's appropriate for this type of task. Does anybody know if dbus could work for this or have any other ideas? I'm also looking for comments on the UI design of the mockups.
Thanks, Ben
On Wed, Oct 03, 2007 at 03:34:04PM -0400, Ben Konrath wrote:
I'm working on a new user creation module for the new and improved firstboot. I created a little video to give people an idea of the UI interaction: http://bagu.org/scratch/createuser.ogv
Email address? Where's that going to go? What will it be used for? And isn't my e-mail address username@localhost?
There should also be an advanced button so that parameters like userid can be selected.
On Wed, 2007-10-03 at 15:43 -0400, Matthew Miller wrote:
On Wed, Oct 03, 2007 at 03:34:04PM -0400, Ben Konrath wrote:
I'm working on a new user creation module for the new and improved firstboot. I created a little video to give people an idea of the UI interaction: http://bagu.org/scratch/createuser.ogv
Email address? Where's that going to go? What will it be used for? And isn't my e-mail address username@localhost?
The Email address is intended to used to pull in account information from mugshot so using username@localhost wouldn't really work.
There should also be an advanced button so that parameters like userid can be selected.
This user creation module is intended to be used by desktop users, not systems administrators so having a place to select advanced options like userid doesn't really make sense. FWIW, the current user creation module doesn't have those options for local users either.
Cheers, Ben
On 10/3/07, Ben Konrath bkonrath@redhat.com wrote:
On Wed, 2007-10-03 at 15:43 -0400, Matthew Miller wrote:
On Wed, Oct 03, 2007 at 03:34:04PM -0400, Ben Konrath wrote:
I'm working on a new user creation module for the new and improved firstboot. I created a little video to give people an idea of the UI interaction: http://bagu.org/scratch/createuser.ogv
Email address? Where's that going to go? What will it be used for? And isn't my e-mail address username@localhost?
The Email address is intended to used to pull in account information from mugshot so using username@localhost wouldn't really work.
There should also be an advanced button so that parameters like userid can be selected.
This user creation module is intended to be used by desktop users, not systems administrators so having a place to select advanced options like userid doesn't really make sense. FWIW, the current user creation module doesn't have those options for local users either.
Cheers, Ben
if this is only targeted at desktop users.. what's wrong with firstboot?
On Wed, Oct 03, 2007 at 05:35:33PM -0400, Ben Konrath wrote:
Email address? Where's that going to go? What will it be used for? And isn't my e-mail address username@localhost?
The Email address is intended to used to pull in account information from mugshot so using username@localhost wouldn't really work.
My point is: how is the user presented with that form supposed to guess that? Mugshot integration sounds like a cool idea -- but why not present it as that?
There should also be an advanced button so that parameters like userid can be selected.
This user creation module is intended to be used by desktop users, not systems administrators so having a place to select advanced options like userid doesn't really make sense. FWIW, the current user creation module doesn't have those options for local users either.
I'm a desktop user. I want to select my user id. This is a flaw in the current user creation module; if we're changing it, now's the time to fix it.
Good design makes easy things easy and more complicated things possible.
On Wed, 2007-10-03 at 21:26 -0400, Matthew Miller wrote:
I'm a desktop user. I want to select my user id. This is a flaw in the current user creation module; if we're changing it, now's the time to fix it.
Good design makes easy things easy and more complicated things possible.
It also hides irrelevant things.
Why do you need to select a specific user id when creating a new user ? I guess you are not creating a new user at all, but trying to recreate an existing one, to reuse the home directory, etc. Right ?
On Wed, Oct 03, 2007 at 10:49:06PM -0400, Matthias Clasen wrote:
Good design makes easy things easy and more complicated things possible.
It also hides irrelevant things.
Hence the "advanced" button.
Why do you need to select a specific user id when creating a new user ? I guess you are not creating a new user at all, but trying to recreate an existing one, to reuse the home directory, etc. Right ?
Often, yes. But I also like to have all user ids the same at home so usernames on removable media just match up. I don't have complicated enough home network (or enough users!) to justify LDAP or even NIS, and anyway I need disconnected operation. So matching up user ids is nice.
tor 2007-10-04 klockan 08:36 -0400 skrev Matthew Miller:
Often, yes. But I also like to have all user ids the same at home so usernames on removable media just match up. I don't have complicated enough home network (or enough users!) to justify LDAP or even NIS, and anyway I need disconnected operation. So matching up user ids is nice.
Yeah, I do that too.
Though perhaps it's time to start thinking about how to solve this automatically. I personally feel that user ids should be local and that anything that's not local to a host (removable media, network file systems etc.) should use something else which then gets mapped to a local uid when necessary. I'm not sure what that something would be, though. Usernames, username@domain, mugshot accounts, user@uuid or whatever.
For example, a USB drive with an ext3 file system could contain some database that maps uids for that file system to usernames. Then when you plug that into a machine, the uids are automatically remapped according to this database to match what the host actually uses.
Btw, this isn't about improving security, it's just a way to make things work more smoothly.
/abo
On Thu, 2007-10-04 at 17:37 +0200, Alexander Boström wrote:
tor 2007-10-04 klockan 08:36 -0400 skrev Matthew Miller:
Often, yes. But I also like to have all user ids the same at home so usernames on removable media just match up. I don't have complicated enough home network (or enough users!) to justify LDAP or even NIS, and anyway I need disconnected operation. So matching up user ids is nice.
Yeah, I do that too.
Though perhaps it's time to start thinking about how to solve this automatically. I personally feel that user ids should be local and that anything that's not local to a host (removable media, network file systems etc.) should use something else which then gets mapped to a local uid when necessary. I'm not sure what that something would be, though. Usernames, username@domain, mugshot accounts, user@uuid or whatever.
For example, a USB drive with an ext3 file system could contain some database that maps uids for that file system to usernames. Then when you plug that into a machine, the uids are automatically remapped according to this database to match what the host actually uses.
I agree, solving the real problem is the better way to go. But unfortunately that's out of scope for user creation stuff I'm working on.
Matt: How do you get around not being able to specify the uid in the current firstboot user creation module? - Just curious.
Cheers, Ben
On Thu, Oct 04, 2007 at 11:37:10PM -0400, Ben Konrath wrote:
Matt: How do you get around not being able to specify the uid in the current firstboot user creation module? - Just curious.
Skip it. Log in as root on text console, create user with useradd. Which I'm fine with continuing to do, although it'd be *nice* to skip this step.
(If I'm installing BU Linux, I can, because we've made our own replacement firstboot module which looks up the user id from our ph/qi server. But I often install vanilla Fedora or CentOS.)
On Wed, 2007-10-03 at 21:26 -0400, Matthew Miller wrote:
On Wed, Oct 03, 2007 at 05:35:33PM -0400, Ben Konrath wrote:
Email address? Where's that going to go? What will it be used for? And isn't my e-mail address username@localhost?
The Email address is intended to used to pull in account information from mugshot so using username@localhost wouldn't really work.
My point is: how is the user presented with that form supposed to guess that? Mugshot integration sounds like a cool idea -- but why not present it as that?
Good point. But since there are other uses for the email address (think any application that asks for the users email address), it's best to just keep it generic.
There should also be an advanced button so that parameters like userid can be selected.
This user creation module is intended to be used by desktop users, not systems administrators so having a place to select advanced options like userid doesn't really make sense. FWIW, the current user creation module doesn't have those options for local users either.
I'm a desktop user. I want to select my user id. This is a flaw in the current user creation module; if we're changing it, now's the time to fix it.
When I said desktop user I really meant 'non-computer-savy desktop user', sorry about that. I think for this case uid is not required, but by that logic neither is the unix username (and some might argue that passwords are in the same boat). So maybe an advanced would be useful.
Thanks for your input, Ben
On Thu, Oct 04, 2007 at 11:58:57PM -0400, Ben Konrath wrote:
The Email address is intended to used to pull in account information from mugshot so using username@localhost wouldn't really work.
My point is: how is the user presented with that form supposed to guess that? Mugshot integration sounds like a cool idea -- but why not present it as that?
Good point. But since there are other uses for the email address (think any application that asks for the users email address), it's best to just keep it generic.
Ouch. I don't *want* to provide a working e-mail address to any application that generically asks. And I don't think I'm the only one who's sensitive to this.
Anyway, from an old school Unix perspective it just feels weird to ask it the way you are, because e-mail address is exactly equal to username@hostname.
But overall I'm with you on this. It's useful to have an external e-mail address. In fact, I'd like to see an option on this screen to automatically alias the root e-mail address to the given address.
Hi,
On Wed, 2007-10-03 at 15:34 -0400, Ben Konrath wrote:
Hi,
I'm working on a new user creation module for the new and improved firstboot. I created a little video to give people an idea of the UI interaction:
This looks pretty smooth, thanks a lot for working on this. My first reaction is that this is not something that should be limited to firstboot; ideally stuff like that should be able to run from the desktop environment when adding / deleting / managing users, right?
If we want that we probably need to look at existing functionality in the desktop.. that includes system-config-users (Fedora specific) and the GNOME About Me dialog and how this would fit in. I'd probably say that we want to replace both. And in the same breath I would approach the GNOME community to get this done upstream so all distros can rally around it (share development and maintenance efforts). What is your take on that?
Also, if we want this in the desktop environment (and I think we do) it needs to be written in a way that separates the mechanism (would run privileged, e.g. uid 0 however locked down by SELinux or whatever) from the user interface (would run unprivileged user). I'd probably suggest to use PolicyKit [1] (for flexible fine grained lock down) and D-Bus (for activating the mechanism) for that, both of these (especially PK) are kinda written for this kind of thing [2].
Finally, it would be good to have this feature as a "Component" so it's easy to embed into other applications; e.g. if I want to write a OS installer app, then I can easily embed this component. Same, FWIW, goes for the work we're doing on the clock applet and in the future any system configuration bits. I think firstboot has /some/ notion of plug-in architecture but actually haven't reviewed it since I'm not sure it's appropriate in an environment where the UI should run unprivileged. But it just might work.
David
[1] : http://hal.freedesktop.org/docs/PolicyKit/
[2] : See e.g. http://blog.fubar.dk/?p=93 and http://blog.fubar.dk/?p=94 for some background
On 10/3/07, David Zeuthen davidz@redhat.com wrote:
This looks pretty smooth, thanks a lot for working on this. My first reaction is that this is not something that should be limited to firstboot; ideally stuff like that should be able to run from the desktop environment when adding / deleting / managing users, right?
We had a design session on this; the idea was actually that you could create new users from the login dialog (GDM).
On Wed, 2007-10-03 at 18:09 -0400, Colin Walters wrote:
On 10/3/07, David Zeuthen davidz@redhat.com wrote:
This looks pretty smooth, thanks a lot for working on this. My first reaction is that this is not something that should be limited to firstboot; ideally stuff like that should be able to run from the desktop environment when adding / deleting / managing users, right?
We had a design session on this; the idea was actually that you could create new users from the login dialog (GDM).
I agree that's an interesting idea that would replace the need for a firstboot module (and probably firstboot entirely). However, I think it's still needed as a program you can launch in the desktop session along with an icon in System->Administration. If only we had a component system...
David
David Zeuthen escribió:
On Wed, 2007-10-03 at 18:09 -0400, Colin Walters wrote:
On 10/3/07, David Zeuthen davidz@redhat.com wrote:
This looks pretty smooth, thanks a lot for working on this. My first reaction is that this is not something that should be limited to firstboot; ideally stuff like that should be able to run from the desktop environment when adding / deleting / managing users, right?
We had a design session on this; the idea was actually that you could create new users from the login dialog (GDM).
That would actually be a very cool idea, in my opinion.
I agree that's an interesting idea that would replace the need for a firstboot module (and probably firstboot entirely). However, I think it's still needed as a program you can launch in the desktop session along with an icon in System->Administration. If only we had a component system...
David
I thought that's why we had system-config-users for? Or am I missing something here?
On Thu, 2007-10-04 at 10:07 -0400, Gian Paolo Mureddu wrote:
I thought that's why we had system-config-users for? Or am I missing something here?
As I wrote in my original mail there's overlap between this new cool thing, the GNOME About Me dialog and system-config-users. Ideally we should just have a single tool.
David
On 10/4/07, David Zeuthen davidz@redhat.com wrote:
On Thu, 2007-10-04 at 10:07 -0400, Gian Paolo Mureddu wrote:
I thought that's why we had system-config-users for? Or am I missing something here?
As I wrote in my original mail there's overlap between this new cool thing, the GNOME About Me dialog and system-config-users. Ideally we should just have a single tool.
Yes, I think what we talked about in the GDM discussion was to reuse the user dialog inside GNOME. So there would be a dialog for creating / editing a user account that can be called from GDM as well as a dialog for doing the same inside the Desktop. (i.e. the person probably shouldn't have to log out to create / edit new users) To save effort we should attempt to reuse code paths because the dialogs and actions will be almost exactly the same.
~ Bryan
On Thu, 2007-10-04 at 14:05 -0400, Bryan Clark wrote:
Yes, I think what we talked about in the GDM discussion was to reuse the user dialog inside GNOME. So there would be a dialog for creating / editing a user account that can be called from GDM as well as a dialog for doing the same inside the Desktop. ( i.e. the person probably shouldn't have to log out to create / edit new users) To save effort we should attempt to reuse code paths because the dialogs and actions will be almost exactly the same.
Cool. Btw, in passing, another thing I'd really like to see is support for setting up the fingerprint reader via thinkfinger [1].
David
[1] : in F8 (and maybe F7), HAL can tell you whether you have the hardware installed
David Zeuthen escribió:
On Thu, 2007-10-04 at 10:07 -0400, Gian Paolo Mureddu wrote:
I thought that's why we had system-config-users for? Or am I missing something here?
As I wrote in my original mail there's overlap between this new cool thing, the GNOME About Me dialog and system-config-users. Ideally we should just have a single tool.
David
Again, I thought system-config-users was for adding users (admin) and changing properties of users as per administration policies, and the about-me tool was for users to *modify* their profiles, password and other preferences, rather than do the *exact* same thing as system-config-users... I'm a bit confused now...
On Wed, 2007-10-03 at 19:44 -0400, David Zeuthen wrote:
On Wed, 2007-10-03 at 18:09 -0400, Colin Walters wrote:
On 10/3/07, David Zeuthen davidz@redhat.com wrote:
This looks pretty smooth, thanks a lot for working on this. My first reaction is that this is not something that should be limited to firstboot; ideally stuff like that should be able to run from the desktop environment when adding / deleting / managing users, right?
We had a design session on this; the idea was actually that you could create new users from the login dialog (GDM).
I agree that's an interesting idea that would replace the need for a firstboot module (and probably firstboot entirely). However, I think it's still needed as a program you can launch in the desktop session along with an icon in System->Administration. If only we had a component system...
If the account creation was only in gdm, how would a user know that they need to create an account before they login? - would this be an obvious step? IMO presenting the account creation in firstboot is the way to let a user know that they should create a user account. And since the code would be reused from the other account creation code it shouldn't be too hard to create the module.
Ben
On 10/5/07, Ben Konrath bkonrath@redhat.com wrote:
On Wed, 2007-10-03 at 19:44 -0400, David Zeuthen wrote:
On Wed, 2007-10-03 at 18:09 -0400, Colin Walters wrote:
On 10/3/07, David Zeuthen davidz@redhat.com wrote:
This looks pretty smooth, thanks a lot for working on this. My first reaction is that this is not something that should be limited to firstboot; ideally stuff like that should be able to run from the desktop environment when adding / deleting / managing users, right?
We had a design session on this; the idea was actually that you could create new users from the login dialog (GDM).
I agree that's an interesting idea that would replace the need for a firstboot module (and probably firstboot entirely). However, I think it's still needed as a program you can launch in the desktop session along with an icon in System->Administration. If only we had a component system...
If the account creation was only in gdm, how would a user know that they need to create an account before they login? - would this be an obvious step?
If there are no accounts listed in the GDM user list then you'd have to create one. GDM could even prompt for this since it knows if user accounts are present (or rather it has a blacklist of non-user accounts). The thought was that GDM could easily make it obvious that you needed to create a user account when none existed by prompting you. (i.e. if (user_accounts.length == 0) { show_account_creation_dialog(); } ).
The other reason GDM was a good entry point for creating accounts was because in (fast) user switching scenarios you will be shown the GDM screen to login as another user, if another user doesn't exist you might want to create them at that point instead of switching back to your original user and finding the system-* dialog that allows that.
~ Bryan
On Wed, 2007-10-03 at 17:51 -0400, David Zeuthen wrote:
Hi,
On Wed, 2007-10-03 at 15:34 -0400, Ben Konrath wrote:
Hi,
I'm working on a new user creation module for the new and improved firstboot. I created a little video to give people an idea of the UI interaction:
This looks pretty smooth, thanks a lot for working on this. My first reaction is that this is not something that should be limited to firstboot; ideally stuff like that should be able to run from the desktop environment when adding / deleting / managing users, right?
As Colin pointed out, the goal here is to allow users to create accounts at more obvious places - at login, when switching users, at firstboot - and share the code / UI for this. This firstboot module was just an easy place for me to start experimenting. So yeah, having the ability to run an account creation app inside the desktop environment is definitely what we want.
If we want that we probably need to look at existing functionality in the desktop.. that includes system-config-users (Fedora specific) and the GNOME About Me dialog and how this would fit in. I'd probably say that we want to replace both. And in the same breath I would approach the GNOME community to get this done upstream so all distros can rally around it (share development and maintenance efforts). What is your take on that?
I think that seems like a good plan.
Also, if we want this in the desktop environment (and I think we do) it needs to be written in a way that separates the mechanism (would run privileged, e.g. uid 0 however locked down by SELinux or whatever) from the user interface (would run unprivileged user). I'd probably suggest to use PolicyKit [1] (for flexible fine grained lock down) and D-Bus (for activating the mechanism) for that, both of these (especially PK) are kinda written for this kind of thing [2].
Yes, I agree. I just read those pages and they will be a good starting point. Thanks for the info :)
Finally, it would be good to have this feature as a "Component" so it's easy to embed into other applications; e.g. if I want to write a OS installer app, then I can easily embed this component. Same, FWIW, goes for the work we're doing on the clock applet and in the future any system configuration bits. I think firstboot has /some/ notion of plug-in architecture but actually haven't reviewed it since I'm not sure it's appropriate in an environment where the UI should run unprivileged. But it just might work.
Yeah, firstboot does have a plugin architecture so making a component is probably what I want. Can you elaborate on what you mean by component? - What technologies should I be looking at using?
Thanks, Ben
On Fri, 2007-10-05 at 00:39 -0400, Ben Konrath wrote:
Finally, it would be good to have this feature as a "Component" so it's easy to embed into other applications; e.g. if I want to write a OS installer app, then I can easily embed this component. Same, FWIW, goes for the work we're doing on the clock applet and in the future any system configuration bits. I think firstboot has /some/ notion of plug-in architecture but actually haven't reviewed it since I'm not sure it's appropriate in an environment where the UI should run unprivileged. But it just might work.
Yeah, firstboot does have a plugin architecture so making a component is probably what I want. Can you elaborate on what you mean by component? - What technologies should I be looking at using?
Unfortunately not, hence why I used quotes around component above. There's things like Bonobo, KParts, COM, Eclipse extensions, Mono addins etc.. In NetworkManager, for VPN plugins, we use (or used too, don't know how it works post 0.6) a pretty simplistic in-process approach (not even GObject based)
http://svn.gnome.org/viewcvs/NetworkManager/branches/NETWORKMANAGER_0_6_0_RE... http://svn.gnome.org/viewcvs/NetworkManager/branches/NETWORKMANAGER_0_6_0_RE...
whereby the UI for managing VPN connections would load a GModule providing the UI and functionality (there's at least three different open source plug-ins at this point). Nautilus has a similar concept with it's extension system; see the nautilus-devel package and some of the extensions.
The idea was simply that this functionality, along with other things (such as selecting your location/timezone etc.), would be targets for embedding in, say, containers like the OS installer, firstboot, gdm or whatever. Depending on the audience for the OS (or spin), you'd select where each component then goes. For example for home-user oriented desktops you'd want everything to go into the live cd installer, for other targets you want something else.
I'm not really sure it's worth worrying about at this point; I'd just focus on creating a single program for now then it can always be retrofitted it into one or more component system later on (and it sounds like you want a firstboot module as well so perhaps writing the program as a library might be a good idea too).
Anyway, I'll stop the architecture astronaut thing now (need air!) but I thought it was important to mention that retrofitting the code so it can be used in different contexts is desirable.
David
On Wed, 2007-10-03 at 15:34 -0400, Ben Konrath wrote:
Hi,
I'm working on a new user creation module for the new and improved firstboot. I created a little video to give people an idea of the UI interaction:
http://bagu.org/scratch/createuser.ogv
One open issue that I have is that I'd like to require that a user account be created by greying out the 'next' button until the information requested is complete and correct.
If requiring a user account be created is not the best approach, what is the best way to allow the user skip this step? An initial idea I had was to grey out the 'next' button only when the user starts to enter information. The problem with this approach is that it's not easy for a user to cancel out of the account creation if they start the process but decide halfway through that they don't want a user account anymore. Any thoughts or comments would be appreciated.
If we don't want to make the user creation mandatory, then it is probably best to not make the button insensitive at all. Instead, we can pop up a message telling the user why creating an account is a good idea when he tries to just click through.
If he clicks the next button while the entered data is inconsistent or incomplete, we can pop up a warning telling him that the entered data does not allow to create an account.
I've also been looking into using cheese to allow users to take a snapshot of their face with a webcam when they are creating their account in firstboot. The stock_person button in the video posted above would activate a dialog for this. I sent a message to cheese-list and one of the developers suggested that a dbus interface might work for this task.
Not sure how dbus would come into this. I'd suggest to investigate a) just launching cheese with some argument that tells it to take a single snapshot and where to save it or b) just steal the relevant code from cheese and embed the video directly in the user dialog.
Anyway, cool stuff.
Matthias
desktop@lists.fedoraproject.org
-
Alexander Boström -
Arthur Pemberton -
Benjamin Konrath -
Bryan Clark -
Colin Walters -
David Zeuthen -
Gain Paolo Mureddu -
Matthew Miller -
Matthias Clasen