The Australian Government coat of Arms

Communities of practice

Communities of practice

Badges / Chips / DSS stages


#1

Moved from: https://github.com/govau/design-system-components/issues/96

uikit 1

Design guide


#2

Would this suggested component (and thread) be better renamed to ‘badge’ or ‘badges’ rather than ‘dss-stages’?


#3

Well it was suggested to be a component that was specifically for the DSS stages alpha beta etc. We need to just see who needs this


#4

I agree with gordon, I could see badges being used for displaying tags, particularly within search results.


#5

I think there is a conversation to be had about whether or not we deem tags enough to carry the use-case of what we refer to as badges or if it deems a new module. The original intent of this DSS stages module here was that it was missing from the new uikit and existed in the old one.

I am personally of the opinion that a new module that answers both dss stages and badges is probably the best outcome.


#6

I’d argue that ‘tags’ are more likely to occur in clustered groups, with a subtler presentation than the less-frequently occurring ‘badges’. Too many badges on a single screen/page would produce an effect similar to summary notification overload.

A ‘badge’ is attempting to call attention to itself in a manner distinct from the always-clickable ‘tags’ (but without the same emphasis as a CTA or button, perhaps).


#7

I think there needs to be a clear delineation between tags and status badges.

Any one item could have many tags and their presentation is normally in a cluster. In a read-write context they likely have a remove link. All tags look the same, except for the word(s) on the tag. Normally their styling would be unobtrusive. That’s the tags component.

This request, on the other hand, is for a status badge. There would normally only ever be a single status badge with any one item. In many contexts that status badge would change colour to indicate status. An icon would also show the status.

Options I’d like to see available:

  1. Colour (possibly from a palette, though with more options than green, amber, red)
  2. Text
  3. Icon
  4. Size (small pills used in a column type report versus larger pills used alone)
  5. Type
    • icon-only (text for screen readers and in tool tip)
    • text-only
    • icon-and-text

I’ve added examples of both tags and a status badge to the third card here: https://codepen.io/anon/pen/XqpGZG


#8

Consistent accessible pattern for signalling that a product or service is in beta, what that means, and indicating points for feedback and voting during beta mode as a consistent part of that beta testing harness.


#9

@NathanaelC could you use a badge next to a product name or feature to indicate its beta status?

This is something we currently do at the DTA however I think the badge on its own doesn’t really communicate what beta means . Like you, I’m open to suggestions on how we better communicate a consistent way of handling the development phases via our UIs.

I’d see feedback interactions to be handled separately, particularly when beta testing, and site-based experience feedback can vary greatly from product to product (or between service touchpoints :wink: )

I think we had a badge in UI Kit 1 but it’s not yet made it into UI Kit 2. A badge, though visually similar but unlike a tag (which are good for filtering and exploring related content), would effectively communicate a temporary status and be non-interactive.


#10

Yeah fair call, it’s more a collection of patterns rather than a template. A useful analogy might be like a firing range or recording studio signage and lighting - a collection of consistent clues that communicate the whole mode of an environment or context (and expected behaviour and hazards).

The whole purpose of a product or service in Beta is different from that in Live; the team is still very much in learn and iterate mode, users will likely frequently hit dead ends with searching for information or attempting to perform tasks they assume are supported, and we’re actively encouraging people to provide feedback and help shape the Beta before going live, far more so than when it does go into the BAU + monitor stage.


New Template category ideas
#11

Can consideration be given to discontinuing the trend of using the words BETA and ALPHA on banners. I don’t think the non-tech person would understand it, and it goes against the whole idea of plain English and making it simple. The comments on this blog post from GDS put the point well https://designnotes.blog.gov.uk/2016/12/07/weve-updated-the-alpha-and-beta-phase-banners/#comments


#12

That is a really important question Ross - and I’m surprised it neither occurred to me or that we’ve come this far without the merit of this practice being challenged.


#13

I think what we’re trying to improve here is how to better communicate the service design status of a given service to its users. Rather than dispute whether or not we should use terminology from the Digital Service Standard.

The examples in that GDS blog provide a short, plain language call to action next to each status badge. Those calls to action presumably serve to attract users whom are looking to give feedback on things that worked/didn’t work so well for them but even so, those statuses lack definition.

Do the terms ‘Alpha’ ‘Beta’ (heck, even ‘Open beta’ and ‘Closed beta’) on their own help manage users’ expectations of what to experience from a service? Nope. Is there ever a need to inform users that their experience may be limited in functionality and/or they’re currently trialling a service that may not soon be around in its current form? Absolutely. This is where it’s appropriate to use these status terms AND do a great job of communicating changes that will likely affect users’ course of action (and their perceptions of the service).

Such information could help them decide how and what they want to get out of a needed service. Even if or when. Deciding not to be transparent about the status of a service means it’s a big ask for users to trust in what we’re doing, even if it’s not fully there yet.

Another factor is that government services often overlap or intersect, meaning a user may interact with more than one service when trying to complete their task. Pointing out where services are in development (and how far along) early, simply and with as much room as possible for supporting user action (including desired action), is something both users and service teams benefit from.

If Australian Government services must meet the Digital Service Standard, it follows that the status of the service reflects its current stage of service design and delivery. The status name (being short for convenience) may have little to no impact on non-government users. However government stakeholders (including related service providers) can benefit from the mutual understanding of the status, provided there is an agreed, clear definition of each stage as well as what it means for users of the service.

All in all, the need to flag how far along a product or service is (from being fully functional, published and/or tested) is relevant to all potential and existing users. Some functionality - like whether or not some forms have been digitised, or access to online customer support systems - may be in trial or not yet ready but in the works.

How we define the status should at least be rooted in the Digital Service Standard but there needs to be a simple and consistent way for government teams to communicate the status so that it’s not just a badge :smiley:

Side note: not relevant to this forum but to the content I’ve linked, the Digital Guides team welcomes your feedback on your use of the service design and delivery process content.


#14

So … in summary, are you proposing that this template idea not be progressed and that the intent be pursued through other avenues?


#15

I think it’s a worthwhile idea.

Maybe as an extension of other templates? For example a documentation template with an additional beta (or ‘in-draft’) banner component, and a ‘provide-feedback’ component, or something like that?

That said; maybe if those components existed, they could just have guidance on placement, which would cover any template :thinking:


#16

It’s well worth pursuing as a design component but needs the right content to go with it. As a said, a badge might be part of it but won’t be the only way to get the point across. Please share the ideas that you have so far in this thread @NathanaelC


#17

I think this pattern has fallen out of favour and I’ve no idea if it would contribute to the goals of this template proposal but something in the accordion mast where you have info about the gov.au domain and encryption would one of the elements and be where the “beta” status is shown rather than in the H1 where clicking on it just goes to /.


#18

I would also suggest a mandatory embedded UserVoice or GetSatisfaction – or whatever the kids are using these days – widget as part of the template or guidance for people to more readily provide feedback in-situ than going off to a contact form, if such a widget wasn’t in scope as a fixture of the live service.


#19

Can you give us some examples where the Australian Government ribbon has ‘fallen out of favour’?
I’m keen to understand your thinking around grouping broader ‘gov.au’ content with an individual gov.au site’s production status.

Given the examples you’ve pulled, I’m assuming you’re referring to Digital Guides’ feedback survey? The site is in beta: it’s not fully live and the offsite questions are only a short term solution.


#20

During some desktop research today I stumbled across the atoBeta website: https://beta.ato.gov.au/about. If anyone here’s behind this creation, :wave: hi! I’m an instant fan of your front-end work and content design :heart:.

atoBeta’s About page and their blog, Tell us what you want, what you really really want does a great job of explaining what their Beta involves and how their community can contribute/try out new product and service slices they’re testing.