FaceBrowserLogin

Differences between revisions 25 and 26
Revision 25 as of 2006-11-27 11:04:14
Size: 4948
Editor: ANancy-151-1-16-34
Comment: drop usecase not revelant to the spec
Revision 26 as of 2006-12-20 15:06:32
Size: 4998
Editor: 74
Comment:
Deletions are marked like this. Additions are marked like this.
Line 10: Line 10:
On a computer capable of running the OpenGL-based compositing/window-managers (e.g. compiz) the visual feel of the system should be consistent. There should be no conceived "visual gap" (effects-wise) between the login-window and the normal desktop-session. As with all things bling, a systems that looks good (right from the start... at login) is more fun to use. It also helps to increase the "me too"-factor of any possible bystanders early on. The face-browser only really makes sense for systems used mainly be people who are too lazy to type (or at least try to avoid to type as much as possible), are generally very bling-fond or cannot remember their login-name (hopefully they are able to recall their accounts password). On a computer capable of running the OpenGL-based compositing/window-managers (e.g. compiz) the visual feel of the system should be consistent. There should be no conceived "visual gap" (effects-wise) between the login-window and the normal desktop-session. As with all things bling, a systems that looks good (right from the start... at login) is more fun to use. It also helps to increase the "me too"-factor of any possible bystanders early on. The face-browser only really makes sense for systems used mainly be people who are too lazy to type (or at least try to avoid to type as much as possible), are generally very bling-fond, and don't give a rat's ass about local security, or cannot remember their login-name (hopefully they are able to recall their accounts password).

NOTE: This page is part of the Ubuntu Specification process. Please check the status and details in Launchpad before editing. If the spec is Approved then you should contact the Assignee, or another knowledgeable person, before making changes.

Summary

In order to extend the embellishment of the visual experience for a user early on, make use of GL-accelerated transitions in the face-browser of gdm. Aside from just providing bling-ified looks, the handling of the face-browser in gdm should scale nicely on installations with many users.

Rationale

On a computer capable of running the OpenGL-based compositing/window-managers (e.g. compiz) the visual feel of the system should be consistent. There should be no conceived "visual gap" (effects-wise) between the login-window and the normal desktop-session. As with all things bling, a systems that looks good (right from the start... at login) is more fun to use. It also helps to increase the "me too"-factor of any possible bystanders early on. The face-browser only really makes sense for systems used mainly be people who are too lazy to type (or at least try to avoid to type as much as possible), are generally very bling-fond, and don't give a rat's ass about local security, or cannot remember their login-name (hopefully they are able to recall their accounts password).

Use cases

  • A family with mum, dad, daughter and son (all non-technical people who like to just look, point and click instead of read text) share a single computer. Each of them has a photo setup for their user-account. They are lazy and want to avoid typing text as much as possible. The face-browser allows them to just point at their photo on the login-screen and the password-entry widget changes accordingly requesting them to enter the password for the user the mouse is currently pointing at.
  • A company has many employees and offers them to login at any workstation in the offices. An enabled face-browser would allow quick identification of the employee wanting to login. Seeing the photos of their fellow co-workers is a way to make the working environment get a more personal and human touch (bit of soap-box I admit).

Scope

This affects gdm obviously. Will likely introduce a new dependency of gtkglext to gdm.

Design

  1. Get AIGLX/GL-based rendering working in the gdm's face-browser window.
  2. Add a GL-widget (via gtkglext) for displaying each users face/photo as texture on a GL-primitive (e.g. quad).
  3. User selection should either happen by hovering or clicking on a users photo.
  4. Should the number of photos (threshold e.g. 9) not fit on the screen, moving the mouse to the left/right of the stack of photos should gradually scroll the stack to the left/right revealing additional user photos.
  5. Use "load on demand" of photos/textures in cases when you have a really huge amount of users (> 100).

  6. The face-browser has to scale well with 100 user-photos or more.
  7. The face-browser has to fallback to the old existing code for non-AIGLX systems gracefully.
  8. The face-browser will need to be connected to the input-box for the user-name. Thus the list of pictures gets filtered, while the user enters his/her name. Optionally for more bling the face-browser just can scroll very fast to the first matching photo.
  9. A normal "Login"-button will need to be provided so users, not knowing that just hitting the return-key will continue the login-process, have a visual clue on how to proceed once they fully entered their name.
  10. To preserve the most consistent look and feel with SlickBoot and usplash the art-resources from those packages have to be used in the same way. This will make the transition from the usplash-screen to the face-browser/gdm-screen as smooth as possible. (The next more refined mockup will take this into account)

These are mockups of how it should look in general:

[http://macslow.thepimp.net/shots/face-browser-mockup-1.png http://macslow.thepimp.net/shots/small_face-browser-mockup-1.png] [http://macslow.thepimp.net/shots/face-browser-mockup-2.png http://macslow.thepimp.net/shots/small_face-browser-mockup-2.png]

Implementation

tba

Data preservation and migration

There are no issues affecting data preservation and migration.

Unresolved issues

  • Is a face-browser really a security-issue for public installations (e.g. at companies)?
  • Accessibility issues have not been covered yet. See the [:Accessibility/Specs/AccessGDM:AccessGDM spec]

Comments

  • In large organisations and public terminals you also have to cater to disabled users. A user needs to be able to activate assistive technology features with a standard keyboard or mouse gesture. See the [:Accessibility/Specs/AccessGDM:AccessGDM spec] for details and use cases. -- HenrikOmma

FaceBrowserLogin (last edited 2008-08-06 16:38:08 by localhost)