We have a single stat component available in gitlab-ui that isn't available in Pajamas or the Sketch design library.
Solution
Add the single stat component to the chart section of Pajamas and to the Sketch design library.
The single stat gitlab-ui component should also be updated to include color examples. On the page it does mention that:
The single stat component is a card used to show a single value. The color of the background & text is determined by the variant prop, which can be one of "success", "warning", "error", "info", or "neutral" (default).
We should communicate how this relates to the color guidelines in Pajamas and provide visual examples:
Blue indicates a current or active state. It communicates: management, progress, connectivity, or organization.
Relates to "info"
Green indicates success. It communicates: save, create, add, available, done, approved, or resolved.
"Success"
Orange indicates ‘attention-required.’ It communicates: warning, pending, missing, or impeded progress.
"Warning"
Red indicates a problem. It communicates: critical states, destructive actions, errors, fails, removals, or declines.
"Error"
(+ Neutral = grey)
Example(s)
The security dashboard is not using the proper component, as it was built before this component was added to Gitlab-UI, but should be updated to match the component specs as detailed from the output of this issue.
This pattern is currently being built for the WAF Statistics Reporting issue as well:
Make sure these are completed before closing the issue, with a link to the
relevant commit or issue, if applicable. Get familiar with the Sketch UI Kit
documentation
which has information on updating files, structure, fonts, and symbols.
Author: Create a Sketch file in your progress folder with the
changes required for this issue. Try to use existing symbols, layer styles,
and text styles.
Author: Ask another Product Designer to review your personal Sketch
file, linking them to your latest commit so they know where to find it. If
they have the capacity, they should assign themselves to this issue. If not,
try pinging another person.
Reviewer: Review and approve author's changes in their personal
Sketch file, according to the workflow.
Author: Add your changes to the GitLab Sketch UI Kit (pattern
library and/or instance sheet), following this step-by-step process.
Author: Ask the reviewer to review your changes to the Sketch UI
Kit files.
Reviewer: Review and approve author's changes to the Sketch UI Kit
files, according to the workflow.
I played about with a few variations in this rough Productivity Analytics mockup from a while back. Nothing implemented though.
You also may need to take into account...
How the metric has been trending
Ratios
I think using the colour for the entire box is a bit too much. May be worth exploring different ways to add the colour. I say this because at later dates, we could click on tiles for further functionality (as shown above).
This will also be linked to our unified dashboard initiative.
Wow this is awesome @npost. I agree that the fill colors are too dominant. Maybe text color within the area is enough to communicate the data, IF color-specific data is required. I love that your mockup has twice the data in the stat area but is 100% easier to parse and abstract information from. I definitely think this is a direction worth exploring @beckalippert.
We may need to consider the scope of the changes we want to make here. Is this 1) to do a direct port of the existing designs into a sketch component or 2) explore a new variation where color is removed/reduced as well as consider rules around content within the stat area?
I wonder if this is similar to a card and whether we can align all these efforts to create one card component that is flexible enough for different types of content.
And if not, why/how does this component differ from a card?
As I view it, if the tiles are interactive and used to filter the content below. they would fall into a button component category. If they are static components would make sense to take them into consideration when exploring the card design for Pajamas.
When it comes to single stats, this could also be an opportunity to make them feel more infographic/dashboard like. If we have some minor graphical elements to provide the color, we wouldn’t have to color the text and worry about accessibility in that regard.
Neat idea, one thought I had was that the circular ones feel almost like progress or amount indicators. For example, the red circle is filled in which could be read as all vulnerabilities are severe. This is obviously in contradiction with the grey circle which is slightly filled in and says 6. Not sure if thats confusing, something we could test.
@tauriedavis great points. For the sketch I didn’t run these through their paces, but just wanted to explore how something paired with text would work. Do you think icons or spot illustrations would be better?
Thanks everyone for the contributions! Here's another exploration:
@andyvolpe and I were talking a bit ago about how to combine 2 different data types in the same area and keep it balanced. In this example, the first 3 colors are in the chart but the stat on the very right is an overall metric and not reflected in the chart.
Andy you shared an idea that had them in a 2x2 grid - can you post that here too?
@beckalippert just wanted to riff on your last concept a bit. Made the bars more literal to what’s in the chart with the top border and kept text dark for accessibility. I would avoid using the × where it looks button-like and could infer removing, deleting, or closing. I also included the value before the label because I think it would be announced better by a screen reader. I don’t think the icons are necessary in the bars, and it’d probably be easier to implement a broader range of stats without them.
One thing I noticed about our charts is that they’re using title-case instead of sentence-case, so I just capped the first character.
I agree with your comment below that the single stat could be a separate component. In that regard the single stat could be a component that gets included in some cards when there’s other data/content coinciding.
so I do think there's a need for each separate component
One thing that seemed worth flagging on this issue - in Monitor, we are likely going to have to ensure that we have appropriate components to essentially re-build a Grafana dashboard in GitLab. Here's what the Grafana single stat chart looks like:
Wanted to flag this as one thing we may need to do, in future, is to show a graph within the single stat component. Some of the explorations here seem like they might support that sort of addition but, in others, it might be trickier.
We could always build a separate variant for this particular use case but, wanted to at least highlight this likely use case for the single stat component in case it impacts which route is selected here. Creating a component that allows for some flexibility and customization, whether through introducing graphical elements or even trend lines (trending up or down) might be useful.
I think the idea is that it's meant to give a quick overview of the trend. There are definitely different ways we could do this visually though! Here's the GitLab Grafana dashboards, btw, in case you want to take a look. You can login with your GitLab email address :)
This cropped up a couple times in my data viz section discussions. The use case is when you want to hint at the "relative" trend but don't necessarily need the "absolute" values. I would refer to them as metric box sparklines or something of the sort. Probably a different component from this one. Alternatively, we could think of it as a simplified line chart for smaller dashboard widget.
I was playing about with a rough concept last week around this component...
I like that exploration, @npost! It feels like a good example of a more robust sparkline/trend single stat option. Maybe we could have a "simple" version of the single stat, with just the single highlighted data point, and something more like this, with the data point and trend line?
@tauriedavis - You raise a good point. These might be the same as cards. In that case I can turn this issue into building cards out further as they're not yet documented in Pajamas. If we decide to merge the single stat and the card component, then we'll want to consider removing the single stat component in Storybook and building out the Storybook card component there. At the moment I can't think of enough differences to justify having both components, but I"ll think on it more.
Ha! Ok I was just looking through my to-dos and noticed that @timnoah is working on cards in this issue. So if we decide that single stat and cards are the same I'll close this issue.
Although, given the work in this Card Explorations issue, I can see the need for separate components. Take an example from a design in that issue:
Single stat wouldn't have buttons, labels, or links (unless maybe behind a tooltip), and would have to correspond to colors on a chart/ graph, so I do think there's a need for each separate component.
@npost Thanks for sharing. Personally, these stats stress me out! Seems like it could encourage burnout very easily, and I have more questions than answers (what determines capacity? What does 7 hours of cycle time mean? Is my manager seeing this info and is this something I'm being measured on? Should I be incentivized to focus on quantity over quality in my issues?) The To Do page is where I want to focus on unblocking my team by responding to their comments and questions, so this doesn't feel like the right place for it. Have you considered somewhere under Profile? What problem is this solving? Could you share what information you're working from to determine that a) there is a need for this and b) that this is the best location?
With regard to this single stat component, I'm unsure if we need it anymore because there's much inconsistency in the examples we've posted in this issue. I think the example we have on the security dashboard could easily be argued to be the card component, as are several of the examples above, and I'm not sure if your examples here justify a new component creation. We might want to consider adding it as a subsection under Data Visualization, or even a Data Visualization section under Card. WDYT?
Thank you! Interesting points @beckalippert! I've had a lot of feedback on this from my post in Slack and will explore some new variations.
Context
This exploration is from this epic. The analytics team is working with a few different stage groups to figure out where best we can embed some analytics to inform workflows. To-Dos is the first area of low-hanging fruit we've identified.
Content
You're right. We could definitely improve clarity and education around these types of metrics. Capacity and cycle time are unfamiliar to most. I loved your point around burnout... that's very insightful. cc @jshackelford
Component - solution criteria
I feel like all the variations here are a great example of diverging ideas and ensuring we capture the edge cases. You've done a great job of gathering this feedback. From what I can see in all these threads, this component's key solution criteria are:
Communicating key metric
Communicating status (if needed): average, trend, deviation, good/bad
Metric guidance: showing more info/education on metric if unfamiliar
Modularity: Displaying metric on its own and with others side-by-side
Accessibility: Using icons + colour to communicate status (as mentioned here by @jeldergl)
Unboxing: Minimising boxes and lines in the UI
Scope: Differentiating between simple stat, complicated stat & card components (as mentioned here by @ameliabauerly)
Guidelines for interactivity (popovers, clicking, relationship with charts & tables etc)
Next steps
IMO, I feel like we are in a good state to start converging on a general solution and creating a flexible simple stat component. In order to do that, a few questions spring to mind that we need to clarify more explicitly:
What are the primary use cases of this component? (e.g. typical JBTD or context in the UI)
What is the MVC vs future vision of this component? Where can we find the most value whilst investing the least effort?
A few teams are quite interested in getting the first iteration of this component into their areas of the product. Maybe we could collaborate and find the MVC together?
@beckalippert Thanks for your feedback. To the point about burn-out, this is exactly what we are trying to help people with. Today many report that they have a huge queue of To-Dos and can't get to them all. They pile up, users time box how much time they can put into them, and then occasionally declare bankruptcy by clearing them all. The goal here is provide people with information about how much they can reasonably expect to do given their historical average and to focus on the UI around knocking out that few of the most high priority items while removing the noise of unimportant items that is an unhelpful burden which obscures responding to the stuff that matters. The rest of the UI gives very concrete goals about what to knock out so that one can get through it quickly without the stress of feeling like there is too much to manage or of trying to decipher which are most critical to respond to. I understand that without seeing the rest of the UI, that's not obvious.
@npost Thanks for the context. I do think that your use case is different from what we have in mind for the single stat component, and would fall under something more related to data visualization. Here are the two use cases we currently have for what we (in Secure and Defend) refer to as the single stat component -- as you can see these are both surfacing highlighted information from a corresponding table or graph below. Both are in containers of equal size (or will be spec'ed to be equal size) and spaced a certain number of pixels apart, with guidance on colors. I think what you're working on would be a related component but not the same thing.
@beckalippert - IMO, the use cases are similar... we are both showing a particular high-level metric near the top of the page or next to a chart. These give the user some indication of how well something is performing before they focus on a chart (or other granular content). There will be some slight variation we can build into the component to illustrate status in your case (critical, high, etc) and the trending direction in my case (trending up from last time period).
I believe all our needs can be met with one component rather than fragmenting secure & defend from Data Viz and the rest of PJs. I'll design a few more options later this week to show how I think we can do this.
Also - your threat level monitoring use case could potentially be achieved with the updated chart legend that @nadia_sotnikova is working on!
Here's a wireframe reiterating what I mean - removing any styles and focusing purely on content & layout)...
This type of component would satisfy all of our use cases. It has optional add-ons to clarify the context & meaning of the metric. These live in the same place within the component to help with consistency.
This component could go above a chart, it could go at the top of a page, it doesn't matter. What's important is that it provides consistency (with enough flexibility) in the way we display metrics.
I'll be working on a few more ideas for proper styles in the context of the report object.
I like this breakdown of content. If we could find a visual that would comfortably fit both use cases, I think something like this could work. I think the challenge will just be in how to make the "simpler" version of the single stat still look compelling, visually, when it's effectively missing half the content?
Also - your threat level monitoring use case could potentially be achieved with the updated chart legend that @nadia_sotnikova is working on!
From glancing over the thread I couldn't find that use case, so not sure if it's useful. However, since I was tagged, here's the new tabular chart legend we worked on. It's a new chart legend variant that works well for data series with several value types.
@npost I appreciate you looking into this holistically and I do see much overlap. I'm also trying to balance that with the differences in the components, e.g.:
A lot more potential information in your example (if all optional items are added)
The data your use case highlights doesn't directly correlate to the information below in the same way that the other use cases do and consider the interaction: if either of the charts is adjusted below with applied filters, the data in the examples I provided will update immediately, thus communicating that 1:1 relationship. It's unclear how to get the numbers in your example to change but I think it would take a lot of activity to do so.
Primary task on page: Users come to the security dashboard and the threat monitoring page specifically to check on stats, whereas on the issues page, so highlighting high-level info is key to help consume the overall trend before drilling in. The primary task on the issues page, however, is searching for issues, and not all users may find this information relevant, important, or helpful, and yet it's a component they have to look at everyday, for every user type, potentially as part of their daily workflow.
The data you provided falls outside these containers that would have to be defined in terms of design specs
Potentially different ways of handling responsiveness (what would the metrics on the Issues page look like on mobile?)
I'm wondering if we can find some middle ground here by defining different types of single stats with subsections on the page. The overview area could discuss the ways in which they overlap; best practices for communicating values and color meanings, and then we can go into the idiosyncrasies of each of our use cases as needed. I put together examples (and potential examples) of single stats currently in the portal in this Mural. Perhaps we can start by creating guidelines based on these? Then we can determine if some are unique enough to be differentiated as something else altogether, or a variations of a single stat.
I'm wondering if we can find some middle ground here by defining different types of single stats with sub-sections on the page. The overview area could discuss the ways in which they overlap; best practices for communicating values and color meanings, and then we can go into the idiosyncrasies of each of our use cases as needed
Good idea! I like it... One component can have multiple use cases - but each use case may require a slight variant. It's like Base vs Variants vs Examples differentiation that @jeldergl laid out in Figma components...
We don't need to use all the "complications" within the component, but they are there for some of the edge cases.
Great work on collating the stuff in Mural. Let's catch up synchronously next week to pin this down! Anyone else is more than welcome to join too...
@npost Things keep popping up in Secure/ SAST that I need to prioritize, and this keeps getting pushed out. Do you have resources to take this over? Happy to be in a supporting role if you can lead.