Alice Wants To…

Jakub: Obviously, the primary user of a user-switching tool will be the home user, but it does have some use within a small office (and perhaps in the star-trek future it has some use in a large office).

The basic use case is someone who wants to switch to their login to do something without disturbing the existing session (which may very well be left unlocked, unattended, and without saving the open work — in spite of everything we tells the users, the editor in chief left himself logged on to two different lab machines one day, and he just got his login a week ago).

But, assuming a perfect world where users didn’t turn disable screensavers and leave themselves logged in, select dictionary passwords and/or write them on sticky notes taped to lab monitors, here’s a case that has occurred before:

  • Jeff works in a campus paper’s newsroom as a photo editor. There are around 80 employees, of whom 30 will be in the office at any given time. There are enough computers in the lab to go around, but only some of machines have special tools on them (like a digital camera media data-recovery tool which requires raw disk access, which the admins have restricted so only one machine can be hosed if the photo guys get their accounts stolen). Jeff (obviously) already knows his own name and face, as well as his username and password, but doesn’t really care about computers beyond them working. Further, he is working under a deadline and thus really needs to use the computer which has the recovery tools ASAP, but the machine is in use already.

This scenario illustrates (I think) that more complex environments must be taken into account even for something as trivial as FUSA, and was what I had in mind. But really, I think “make FUSA not suck with lots of users” is a laudible goal anyways. The ideas for handling that many users boil down to (essentially):

  1. Make FUSA into a “recently used” list, with the last 5-10 users who have logged in.
  2. Only show currently logged-in users.
  3. Show all user accounts.

#1 can only really use utmp to see who the last few users were, and I can see it getting irritating — sometimes your user shows up in the list, sometimes it doesn’t. I’d guess that people will scan the user list to find their user, and after not seeing their user a few times, will get into the habit of just going straight to the “login screen” item to save time, effectively killing the usefulness of showing the users at all. #2 is better, as the list will be smaller, but otherwise shares the same problem as #1. #3 shares one of the problems of #1 (the user must scan the list), but at least the user is gauranteed their account will be in the list — with photos and properly filled-in GECOS names, the scanning shouldn’t be that difficult providing the user is in basically the same place in the menu all the time.

So, I don’t really think #1 fits the use-case (and available user accounts is much closer to available applications than recently-used documents, IMO), and the decision of #2 vs. #3 is close enough to call (e.g. you may not want to show all the available usernames) that it should be a hidden option.

Update:Sorry, Jakub, for misspelling your name (yeah, I’m an idiot).


4 thoughts on “Alice Wants To…

  1. Make FUSA into a “recently used” list, with the last 5-10 users who have logged in.

    the new desktop bookmark spec, which should replace the recent file spec currently used by gnome, is completely agnostic on recently used objects; you could just add a custom URI like “user:///joeuser” and a custom mime-type, like “application/x-fusa”.

  2. (First off: is it intentional that tabbing between fields jumps me two fields ahead at a time?)

    I’ve been following this discussion with much interest, since I’d love to see fast user switching in Linux. Is this an active area of work within GNOME? Or is it as a more theoretical level right now?

  3. 4. Only show the users that have logged on to that particular computer before (and optionally prune that list by removing the users that haven’t used it in a set amount of time such as 6 months or 1 year).

    I mention this only because while I was in college I would use the same small set of computers regularly… only once in a while when the lab was quite full would I grab a computer that I had not used before.

  4. When I previously suggested something along the lines of “Recently used” I was thinking more along the lines of tracking other accounts _previously used_ from this account, rather than users who recently used this computer.

    This wouldn’t work well for the scenario you describe but it would work well for the scenario of an adminstrator that user that would use the same few other acounts on a regular basis, or a friend letting a friend briefly check their mail from his account.

    No offense but custom URI schemes are the spawn of satan and needlessly break back compatibility. I hope it is a mistake that Gnome developers have made enough times already to not need to make again.

Comments are closed.