Terra-core: Avatar Component (Revised)

[ChaseSinclair]

Technical Design: terra-avatar

Summary:

A discussion with UX has lead to a necessary redesign of the Avatar component. This revised tech design includes the following changes:

• only two avatar types (User/Facility)
• icon can no longer be provided as a prop (only the User and Facility icons are used)
• specifying that if an image or text is provided, it will display in place of the fallback icon.

See the outdated tech design.

Expected behavior:

Should be able to give the component an image or text which will display inside a circular wrapper. If neither of these are provided, then the default User or Facility icons display. Which icon is displayed is determined by the prop 'type'.

Responsiveness:

The content within the avatar does not change, only the size. The size of the avatar is dictated by the component where it lives.

I18N / Bi-directionality:

These changes should make no changes to the existing ltr/rtl functionality.

Interaction States

Avatars will not have interaction states. The hover state shown on the callouts will be controlled by the parent component not the Avatar.

Accessibility

We'll provide an aria-label to indicate that the component is an avatar.

React Props:

| Props | Type | Default | Required? | Description |
| ----------- | ----- | --------- | ---- | --------------------------------------------------------- |
| alt | string | undefined | No | The text content that specifies the alternative text for the image. |
| variant | string | user | No | The type of avatar. Either 'user' or 'facility'. |
| image | string | undefined | No | The image to display. |
| initials | string | undefined | No | The initials to display. Limited to 2 or 3 characters. |

Themeable Styles:

• Background
  
  
  
  • color
  
  
  • opacity
  
  
• Border
  
  
  
  • width
  
  
  • style
  
  
  • color
  
  
• Box shadow
• Font size
• Font color
• Size
• Icon color
• Line height

[dylanklohr]

I would suggest for the prop type's details, explicitly calling out the two strings that you pan to accept.

• 'user'
• 'facility'

That way, anyone looking at this tech-design in the future knows what you wanted the values to be.

[dylanklohr]

Do you have thoughts yet about how you'll end up doing the icon coloring, for theming?

[dylanklohr]

+1

[bjankord]

Do you have thoughts yet about how you'll end up doing the icon coloring, for theming?

I assume this will use the scss inline-svg function to add the svg icon to the stylesheet. Inside this svg is where we would set the icon color. For dialog, we set the icon color as a fill on the path of the SVG that is inlined.

[bjankord]

+1 on revised tech design. We'll want to get @neilpfeiffer to take a look and a +1 from one of the other terra maintainers, @mjhenkes, @ryanthemanuel, or @JakeLaCombe

[mjhenkes]

Could you explain more about the implications of the user or facility type?
Should the image prop be passed in as children?

[ChaseSinclair]

Could you explain more about the implications of the user or facility type?

An Avatar must be one of these types. This type determines the fallback icon that is used if neither an image nor initials is provided. A User could be a patient or provider or some other form of user while a facility could represent a group or organization.

Should the image prop be passed in as children?

I think providing the image as a string prop is appropriate. I modeled this off the existing Profile Image. If the image prop is provided, we immediately know to display the image and thus can avoid all icon/initials based logic.

[dm123455]

+1

[mjhenkes]

+1 on tech design.

I think providing the image as a string prop is appropriate. I modeled this off the existing Profile Image. If the image prop is provided, we immediately know to display the image and thus can avoid all icon/initials based logic.

You may still need to fall back to the icon/initials logic if the src fails to load. We have this setup for both profile image and image.

[JakeLaCombe]

+1.

For that fallback logic, perhaps we should just use the User or Facility icons for it? That's the only thing that dictates whether the image should be a string or prop.

Otherwise, everything else looks good.

[neilpfeiffer]

👍 on the revised tech design.

Nit, but curious if anyone else would rather see type be variant instead, to better match status-view and button?

FWIW, Appreciate how this is cleaner approach than 3 variants, and ditto to what @mjhenkes mentioned on testing for images failing to load falling back gracefully to icons/initials.

[dylanklohr]

@neilpfeiffer , using type as opposed to variant was done at my request. I didn't want to use the name variant as, at least to me, it implies a greater implication to the overall purpose of the component than type does.

Take button for instance, the variant in button, among other things, implies to me that we have in fact a variation on what a button is intrinsical. All of the same intrinsic functionality is in place conceptually, and the component physically functions the same way regardless of what variant it might be. That being said, a button's variant in practice changes the appearance of a button, not the way it works.

type on the other hand, implies (at least in my head) a looser relationship between whatever value may be provided by this prop and the overall functionality of the component. IMHO, an Avatar should be an Avatar, and not a Facility Avatar or a User Avatar. The logical flow in which this actually becomes relevant is when we're determining under the hood, how an Avatar really renders its content, and what that content really is.

Describing this in precedence, the questions asked by an Avatar should be

1. _Do I have an image provided?_ –> If so, display it and skip to end
2. _Do I have initials provided?_ –> If so, display them and skip to end
3. _Okay, so I know at this point I don't have an image or initials that I'm supposed to display..._
   –> What should my fallback display contents be? Only at this point, should the type value that's passed in be considered, not before.

I'd be interested in hearing other's thoughts and naming options for the prop other than type, but variant to me implies a relationship that with its current implementation, I don't think should be assumed.

[dylanklohr]

+1

[neilpfeiffer]

The reason we've avoided using type is a logical one - we've reserved it for components that utilize the html attribute of "type" where a corresponding actual type may need to be provided (input, button, et.al.). Hence variant has become our word to do the visual characteristic switching, not so much functional variations (functional variances are usually associated to the isXYZ prop nomenclature). Not a hard and fast rule, but putting it up for discussion to affirm or revisit.

On the fallback - the routine that needs to be accounted mentioned above is not whether image values are provided, it is if values that are provided yield an 403/404/503/504 (error/broken url) or anything other than a 200.

Do I have an image provided? –> If so, display it and skip to end

adding something like "-> if image fails to load (onError), display initials (if provided) or icon."

[dylanklohr]

@neilpfeiffer, I definitely see the issue with type here, and I'm totally open to changing it.

My questions then become:

1. Is there enough of a "majority" use-case to justify creating either aisUser or isFacility as a flag to say "hey, this is not the majority use-case, use the other fallback icon"?
2. Is there an alternative name for what is currently the type prop that you can think of, that obeys the anti-variant naming motivation above?
3. If there isn't a majority enough use-case, is there an instance in which you can recall defining both isUser and isFacility as optional props, and then just having some JS logic that requires you to provide at least one of them (throwing an error if you don't) and also handles the case of providing both props and how that determines our fallback icon?

[neilpfeiffer]

The full design has additional types/variants that are not being coded for initial implementation: patient and provider, which may have unique icons in the future, dictating the current proposal and would be passive approach to grow into.

[mjhenkes]

I thought about making a comment about variant over type, but we aren't consistent. Alert uses type. Badge uses intent. Button and Status view use variant. I think I lean towards variant?

[dylanklohr]

@mjhenkes My concern isn't so much a naming issue, it's more of a meaning behind the name issue. I'm thinking that variant, specifically, implies too strong a relationship about what setting it to a particular value given the other instances in which I've seen it used, as really the only functional difference at this point seems to be what fallback icon is displayed in the case that the user doesn't supply initials or an image. Ultimately I'm fine with whatever

[dm123455]

@neilpfeiffer what happens when we do not have user or facility type specified as the default is undefined? what do we fall back to?

[dylanklohr]

@dm123455 , im not sure that's an actual option... we should be setting type or variant or whatever we have as a required prop

[dm123455]

I think there needs to be a default, I would rather make the type a non required field and have a default(user/facility).

[dm123455]

@ChaseSinclair I spoke with @neilpfeiffer and we do need to have the user variant as a default.

[bjankord]

Talked offline @dylan-sftwr @neilpfeiffer @mjhenkes and landed on consensus on using variant instead of type.

[neilpfeiffer]

+1 on current TD

[dm123455]

+1

[dylanklohr]

+1

[PaulSolDev]

JIRA created

[bjankord]

This is released in [email protected]