New 'Scoreboard' Card Variant for dashboards and object detail pages

[SOjaHPE]

GLCP for Glasgow is requesting support for a new card variant, for displaying data points. They need guidance and a figma card component that allows designers to quickly create them is a consistent manner. Standardizing the layout of this new card type will establish norms for font sizes for labels, data points, units, state/status, trending info, icon locations. Naming wise these are data vis. data points, scorecard, or scoreboard cards.

It might be a better approach to think about creating a data vis pattern and guidance for the display of data points, since data points can be rendered in cards, data tables, list views, adjacent to charts, etc. Standardizing the what, why, and how will create consistency.

Problem Statement from GLCP

Challenge: We do not have an available Figma template for this layout, which results in redundant work for designers who have to start from scratch if they need to build the dashboard card.

We have upcoming services migration to GLCP, and in order to prepare the GLCP for business units, we require some building boxes and guidance to be ready for them.

What sets the dashboard card apart from a regular card is that users have the option to customize it. They can adjust the card size, select specific cards, and rearrange the layout to their liking.

Examples

See figma link below for use cases

[SOjaHPE]

Link to the GLCP Glasgow figma file use cases

[jeffstolz]

Met with Sylvia Shen today - my takeaways from the call:

Problem statement: Users need an easy way to regularly view important metrics and evaluate their changes over time within GLCP. (This problem statement is specific to GLCP, will collect from compute & storage and then consolidate).

The GLCP team has identified that the best place to present this information is within top-level cards on various dashboards, which seems like a logical approach. However, the current card documentation doesn’t provide options for presenting this type of information and will need to be updated.

The use cases Sylvia and I identified are:



• Wellness Dashboard (GLCP) - this is owned by Diane Labenz, I’ll reach out to get more details.
• Sustainability Dashboard (GLCP) - owned by Sylvia. Will present the total carbon emissions, energy consumption, and energy cost to the end user, with associated filterable time vs value graphs.
• Compute Dashboard? (Compute) - owned by Greg, I’ll reach out to get more details.
• Storage Dashboard? (Storage) - Sylvia will get back to me with the best contact.

Once I gather info on all of them, I will collate our findings into common themes that can translate into standardized components/placements within the template. Variations will be identified/documented to ensure all use cases are still properly meeting their user outcomes while remaining as consistent as possible.

While we want to address scalability in the future, I recommend we first release an MVP component that addresses all current state use cases. The GLCP team needs it now and this component will inevitably evolve through usage: I’d rather let the design teams within their contexts drive that evolution rather than spend time predetermining all potential future use cases that don’t yet exist.

[SylviaShenCC]

Dashboard Customization DSCC I was in touch with Astha Sirohi previously, but it appears that the project is now under the ownership of a designer named Kevin McNavich.

Wellness Dashboard GLCP Designer : Diane Labenz

Compute Ops Management It appears that I don't have access to CoM, but Greg was the designer to compute and he is also the design lead for the Sustainability Dashboard. I recall him being involved in the conversation about the GLCP data visualization strategy recently, so he would be a valuable resource. Additionally, he used to be part of the grommet team.

[jeffstolz]

Met with Greg to discuss the CoM dashboard and sustainability dashboard, which evolved into a conversation around the overall approach to our card component. Some takeaways:

• We currently define a card as “a container providing at-a-glance information and easy access to more details”. I think a more accurate definition is from NNG “a card is a UI design pattern that groups related information in a flexible-size container.”
• Following the NNG definition, a card really isn’t a component - it is a container that most often contains related components and UI elements within it. I think what we should be defining within the card component (or template?) is that specific container construction (border, elevation, radius, etc) and have flexibility on what goes inside. Thematically, we’ll want to steer and define card best practices and provide loose examples, but I don’t think we’re empowering our designers by defining limited/specific structure and variants. As long as they are following the DS guidance of the components used within a card, they can mix and match these components to best solve the user problem - that is the power and flexibility of an atomic design systems
• I recommend, while we continue to meet with teams to discuss and learn about their use cases, we use these as examples and inspiration for card usages (when appropriately used), but not try to corral them all into more limited approaches for the sake of visual consistency in place of best solving the user problem.

[halocline]

• We currently define a card as “a container providing at-a-glance information and easy access to more details”. I think a more accurate definition is from NNG “a card is a UI design pattern that groups related information in a flexible-size container.”

I think the above statement could be misleading read out of full context. NNG goes on to say the following:

• "Definition: A card is container for a few short, related pieces of information. It roughly resembles a playing card in size and shape, and is intended as a linked (i.e. "easy access to more details"), short representation (i.e. "at a glance") of a conceptual unit (i.e. "related information about a single subject")."
• Cards have 4 key properties:
  1. Cards are used for grouping information. -- A card chunks several different (but related) pieces of information into one digestible unit — be it an article on a news website, a product on an ecommerce site, or a post on a social app. A single card will typically include a few different types of media, such as an image, a title, a synopsis, sharing icons, or a call-to-action button — all associated with the same concept.
  2. Cards present a summary and link to additional details.. -- A card is usually short and offers a linked entry point to further details, rather than the full details themselves. It is intended as a high–information-scent outline used to entice users to click through to further details contained on a separate page.
  3. Cards resemble physical cards --- Cards use a border around the grouped content, and the background color within the card that differs from background color of the underlying canvas. These visual-design elements create a strong sense that the different bits of information contained within the border are grouped together....
  4. Cards allow for flexible layouts.

I believe the guidance currently presented on the site aligns with this definition and is consistent with others:

"Card - A container providing at-a-glance information and easy access to more details."

"Principles - Cards are containers that display content and actions on a single topic. They should be easy to scan for relevant and actionable information.

• Contained - A card is identifiable as a single, contained unit.
• Independent - A card can stand alone, without relying on surrounding elements for context.
• Individual - A card cannot merge with another card, or divide into multiple cards.
• Summarized - A card by nature has limited real estate, so it should present summarized information.

Cards should be used when:

• Presenting high-level, summarized pieces of information.
• Presenting an item, or collection of items, which can best be consumed visually.
• In all cases the presentation allows users to quickly scan the content and navigate to underlying detail if desired."

[halocline]

• Following the NNG definition, a card really isn’t a component - it is a container that most often contains related components and UI elements within it. I think what we should be defining within the card component (or template?) is that specific container construction (border, elevation, radius, etc) and have flexibility on what goes inside. Thematically, we’ll want to steer and define card best practices and provide loose examples, but I don’t think we’re empowering our designers by defining limited/specific structure and variants. As long as they are following the DS guidance of the components used within a card, they can mix and match these components to best solve the user problem - that is the power and flexibility of an atomic design systems

We agree that the card itself is a "is that specific container construction (border, elevation, radius, focus, etc) and have flexibility on what goes inside." This is very similar to "Notification." At there core, both Card and Notification are simply containers with certain properties.

Similar to how notifications have different "flavors" of inline, toast, global, each with their own set of purpose, intended applications, behaviors, and guidelines. (e.g. toast notifications should be used for x, but not for y. They should behave in this manner. etc.).

Cards too have different "flavors" with distinct purpose, solving for specific user needs. The flavors we have arrived at thus far are:

• Call to action - Purpose: Entice the user down a desired path.
• Navigational (open to naming suggestions) - Purpose: Provide a menu of options, providing a user a means of way-finding.
• Status-based navigation - Purpose: Quickly assist the user to navigate to resources, tasks, or processes requiring their attention and/or action.
• Resource (open to naming) - Purpose: Allow a user to scan a set of resource options (e.g. products on an e-commerce site, catalog of services, collection of devices, etc.) and choose one based on their needs.
• Analytical - Purpose: Present measures and metrics in short, digestible content pieces and allow a user to navigate to underlying detail is needed.

Within all of these the content and interior layouts should be quite flexible, but follow the intended purpose and user need being solved for. If additional user needs are surfaced, we can explore new "flavors."

---

The scope of this issue should really be divided into to sub-issues:

• Fill in the guidance for "status-based navigation cards" and provide templates and example contexts for when they might be used.
• Fill in the guidance for "analytic cards" and provide templates and example contexts for when they might be used.

We should focus on one. Let's find a time to meet to make sure we are aligned here.

[halocline]

Lastly,

• I don’t think we’re empowering our designers by defining limited/specific structure and variants. As long as they are following the DS guidance of the components used within a card, they can mix and match these comp

I agree. We should not be restricting or limiting content to specific variants. Designers should have freedom to present content appropriate for the use cases for which they are solving. That said, we should have "flavors" and taxonomy defined so that we are purposeful with how we apply cards. We should also have templates which designers can grab for convenience and/or inspiration.

There are also things that cards should not be used for such as: toggle buttons

cards placed within other cards

cards serving as content sections.

[halocline]

Lastly, lastly - The specific ask of this ticket from GLCP is:

"Challenge: We do not have an available Figma template for this layout, which results in redundant work for designers who have to start from scratch if they need to build the dashboard card." ---> translation "give us some templates"

[jeffstolz]

@halocline and anyone else - Looking for initial feedback on my initial analytics card explorations - super rough, low-fi template proposal in the red box. I collected all of the cases of analytics templates I could find to the left, and I'm hoping this would be able to satisfy most of those cases. This is a single card template that has a lot of levers the designer can turn on and off - all properties optional - I'll talk to Sylvia to see if she thinks this would be flexible or burdensome.

https://www.figma.com/file/9k4e2q0RwQTY4fKrj0CX8s/Status-%2F-Analytics-Card-Templates?type=design&node-id=0%3A1&t=0TEIzYglpDGPyzVz-1

[jeffstolz]

@halocline @SOjaHPE looking for some progressive feedback on this - https://www.figma.com/file/9k4e2q0RwQTY4fKrj0CX8s/Status-%2F-Analytics-Card-Templates?type=design&node-id=0%3A1&t=oNHtVuLr3xxpvHsk-1. The Figma file is just structured how I'm working through the problem: pages broken down by use cases throughout our experience, high level anatomy & guidance documentation, the actual card templates, and then seeing those card templates applied to those use cases to see how we can cover as many as possible. I've got a definition for the general card structure and have defined, at a high level, the types of data visualizations I'd like to include in each template variation. Primarily looking for feedback on the anatomy/documentation and if you think this is complete enough to move forward on. Next steps will be the component work for the templates. Also meeting with Sylvia tomorrow to go over the latest.

[jeffstolz]

Created the template component using the "slot" component method. Was able to expand on the "applied to use cases" list without breaking the component, seems quite flexible, https://www.figma.com/file/9k4e2q0RwQTY4fKrj0CX8s/Status-%2F-Analytics-Card-Templates?type=design&node-id=68%3A32833&t=bwC4wlUXmu9fMHZQ-1. Will clean up the documentation & data visualization components and then put up for review.

[taysea]

6/14: This would be a candidate for small group discussion to get on same page before deciding next steps/remaining scope of work. @KennyAtHPE mentioned there is still work in progress (vs being in a close to done state).