== Problem == 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. {{attachment:Avatar-AllList.png|Avatars add quick scannability to lists; instead of making the user read each item, they may recognize regularly-used images for faster access.|align="right"}} == Solution == 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. == Variations == 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). {{attachment:Avatar-SMS.png|Avatars are a good way to label an individual in a very small space. Selecting these should reveal details of the contact, or options relating to the contact.|align="right"}} 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. == Interaction Details == '''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. {{attachment:Avatar-LessList.png|When custom Avatar images are not available, either don’t use an image at all (as on the left) or use a generic placeholder that is appropriate. On the right, one of several different stand-in images is used for each unassigned Avatar.|align="right"}} 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]]'''. == Presentation Details == 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. {{attachment:Avatar-Anti1.png|Avoid using the same stand-in image for each Avatar (or so few variations they repeat excessively). The image should add meaning to each individual use, not just fill a gap in the design.|align="right"}} == Antipatterns == 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. == Examples == 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.