You must provide a glanceable representation of a person for use in various contact-listing contexts.
Visual representations of any sort can technically be displayed by any platform. Providing the images can be a notable challenge if you have to make the images, or make arbitrary images fit in the space.
Text is accurate, and precise, for listing or otherwise describing people. However, text labels can be slow to read, and this is often undesirable in mobile context -- whenever possible make the interfaces glanceable and scanable.
Much like the Indicator pattern, an Avatar is an iconic image used to represent or support the label for an individual, such as a contact in the address book.
This pattern is addressed separately from the Icon or Indicator because the Avatar image represents a real person, not a concept or action, and because in many cases the image itself cannot be directly controlled by the designer, or the user of the device.
The two basic types of Avatar are different from other variations in the book in that they vary by individual use. Each one can, and very often will, appear in the same interface.
The first, and most obvious, is any custom representation. This may be a photo, or a personalized icon or other graphic. It may be loaded by the user of the device (as when a photo is taken of a contact for use on that device alone) or may have been created by the owner of the avatar (as when the profile image from a social network is automatically loaded).
When no custom image is available, as will occur very often with first-time use, a generic icon, or set of icons, is often used instead, as a placeholder. Whenever possible, avoid truly generic icons.
As described in the Thumbnail List pattern, irrelevant images may be simply left out. The specifics of your interface will determine it this is a workable solution. During design, consider the likelihood of most or all items being populated with image content, and make decisions about use of the Avatar pattern accordingly.
Avatar images may be selectable or not. Be sure to follow the general paradigm of the context in which they are used. If used in a line item, such as an address book, you may make them selectable as an extension of the name, as a part of the whole line, as individual items with different behaviors from the other labels, or not at all.
Always consider how clear the interaction which will follow selection of an Avatar can be communicated. If it is not perfectly clear, then add additional information, such as an overlay icon as described in the Icon pattern. Otherwise, consider simply making the Avatar image display only.
When you display an Avatar without a label -- such as in threaded messaging or an SMS conversation -- the Avatar should always be selectable, and generally either display the user information, or offer options for interaction with the individual as a Pop-Up or Annotation.
Since the image itself often cannot be created, the designer must be careful when selecting borders, background, sizes and aspect ratios.
Avatar images are almost always square, to account for both landscape and portrait orientation source photos, without adding masking bars to part of the image, or causing inconsistencies in the display and alignment of page items.
Generally, to fit to a square, the long sides are cropped off, and the short side is fitted to the image dimensions. Occasionally, it may be useful to crop the outer 10 or 20% of the whole image, to assure a recognizable face is in the image area. Base all such decisions on the final rendered size and aspect ratio; aside from source imagery varying widely, even very poor images will generally be much larger than the Avatar image.
Though some Avatar selection systems allow manual image cropping, this -- as well as photographing within the mobile device to generate images -- is not within the scope of discussion here, but should be designed to generate the best possible images, and adhere to the design principles of the application or process. Feel free to explore alternative methods; facial recognition software, for example, is now reliable enough that can be used to automatically crop Avatar images.
When practical, use Avatars alongside text labels. When selectable, use the existing paradigms, discussed under the Link pattern, to denote that an image is selectable.
When no supporting label text is associated with an Avatar image, consider use of the Tooltip, when practical and supported by the device's interaction model. If an Annotation or other interaction may conflict with the Tooltip, make sure label information such as the user's name is in the interactive selection mechanism as well.
Avoid using too many generic icons, or only have one style of graphic which serves as a placeholder for every empty slot.
Always keep in mind the value of the Avatar, and do not fill with arbitrary content to populate a flawed or boring design.
Next: Wait Indicator
Discuss & Add
Please do not change content above this line, as it's a perfect match with the printed book. Everything else you want to add goes down here.
If you want to add examples (and we occasionally do also) add them here.
Make a new section
Just like this. If, for example, you want to argue about the differences between, say, Tidwell's Vertical Stack, and our general concept of the List, then add a section to discuss. If we're successful, we'll get to make a new edition and will take all these discussions into account.