FUSA in CVS now lays out its menu in a table format if it can’t fit all the users onscreen vertically, which is useful for situations where there’s a lab setup with a fair number of users who must hot-swap their chairs (like the newsroom where I work, for example). However, this horribly violates the 7-8-items-max rule (photos would help in this specific situation, of course) and happens to segue into an interesting point about next-gen UIs. Specifically, what happens when your collection of “first level objects” reaches epic (hundreds of “friends”) proportions? Do you just just say “fuck it” and run things through a query/command interface (e.g. a login window without a face browser)? Do you map it into some hierarchical directory system (like LDAP, FHS, or GNOME’s menus)?
Don’t get me wrong, I’m all in favor of things like Project Soylent because they cut massive amounts of bullshit out of using a computer for interpersonal stuff. I just think it’s also important to realize that most people have far, far larger groups of friends than the average geek, and the interface should accomodate that.
James Cape 
What about displaying the last five users who logged in and a “More…”… or maybe just the plain login screen for the others?
Would a possible solution perhaps be to auto group the nummber of elements with a alpha-numerical divider, with a smart option to detect similair series of names.
for instance in your screenshot the look could be like this.
– asdfas
– James M. Cape
– Tyler Durden
– user1 – user10 -> user1
user2
user3
etc..
– user11 – user20 -> user20
user21
user22
user23
– etc..
and if there just where lots of names, and not a userXX
– Albert – Cleo -> Albert
Bert
…
Cleo
– Dennis – Zack -> Dennis
Leo
…
Zack
Nice. I’ve always hated the standard way menus overflow.
Although it does help forced developers to be smarter and not put so much in the menus some will inevitably put too many items in the menus and laying out the menu as a table is way more effiecient.
Dont suppose this is a change you could push back into GTK so that people could optionally use this style of menu overflow all the time?
All or nothing?
Presumably most users will only have a few user accounts, like $current user, $root and maybe one or two others so if there was some way you could show only the accounts the current user wants/has access too you wouldn’t need to show the full list (perhaps store the accounts that have been recently used from this account and not bother listing the others).
Any chance you could update your form so that users know their email addresses will not be printed on the web page when they submit a comment? (I’m only really adding this comment so that you have my address in the unlikely event you want to contact me.)
I’m thinking of a use case we would have if this was used in one of our Nursing stations. Nurses would like to quickly logout/in so a fast user switch would be quite helpful. The user list would be driven from an LDAP that contains 5000+ users. For this case, only listing users with active sessions and a new login would defiantly be the way to go.
For the use case you describe I would definately recommend a displaying a full application window showing some kind of a easily searchable directory of available user profiles. Menus aren’t really supposed to be used for anything that wont fit on one column the height of a small screen.
It certainly helps that you have some idea of your archetypal target user but clearer uses cases will make your job easier.
Jimmac had something simliar to say about making out proper use cases but he said it more clearly than I did
http://jimmac.musichall.cz/weblog.php/Design/fastuserswitching
Lets be honest here, many people like to “think” they have more friends than what they actually have, a long IM list screams “i’m so popular !”. Most people may think they have more friends, but they have more “contacts” than the average geek.
Ideas.
Much like “recent documents”, you could have “recent users” listed at the top. People being creatures of habit tend to like to use the same machine. This could be stored in a users profile, although a system wide “recent users” would be more effective.
If recent users was tied to a single users profile, the “recent users” idea would be ineffective when tied to a users profile.
Building on the comment by Matthew, above…. some kind of input box with autocomplete might be more useful for massive user lists, with a autocomplete text input box. Below this could be a graphical list like FUSA currently does with matching users.
With a few users on this machine, I wont really need this functionality, so I am just armchairing. I’m sure that you will make up your own mind on what works and what doesn’t.
FUSA is the good.