The Australian Government coat of Arms

Communities of practice

Communities of practice

Summer community meetup 2019


#1

Hi all!

We have booked in the 31st of January, from 2pm-4pm for our summer community meetup at the DTA office (50 Marcus Clarke St).

There is a page on Eventbrite with more information. Please make sure to RSVP :slight_smile:

Raj


#2

Hi, I did jump over to the eventbrite page, but I just wanted to understand, is this a general event or for those working on a specific project? Cheers, L


#3

Hi @LoriMancell this is an event for people who are using the Design System ( https://designsystem.gov.au ) or wanting to learn more about it.


#4

Hey all,

Thanks to everyone for your attendance and contributions.

I just want to summarise the GitHub tickets that were discussed towards the end
of the meetup. For those who couldn’t make it, if there is anything you would like to add please share below :slight_smile:

Use bootstrap 4 grid breakpoints

Problem

Currently the Design System is using bootstrap 3 grid break points. Right now, the grid break points are inconsistent with the media query breakpoints. The other problem being that the .col-xs- class has a range between 0 to 768px and doesn’t allow flexibility for any device ranges between these values.

Solution

Moving forward, the Design System will shift to use bootstrap 4 grid breakpoints instead.

See below for differences

Grid System Extra small devices (.col-xs) Small devices (.col-sm) Medium devices (.col-md) Large devices (.col-lg) Extra large devices (.col-xl)
Bootstrap 3 <768px ≥768px ≥992px ≥1200px n/a
Bootstrap 4 <576px ≥576px ≥768px ≥992px ≥1200px

It will be a major change, and websites already built using the current grid may need to update
their use of the grid.

Side note: We also had someone ask for the option of not supporting IE8 pixel fallback.
There is actually a global SASS variable called $AU-pixel-fallback which can
be set to false to achieve this.

To use au-body or not?

Problem

Right now it’s difficult to tell when to use au-body. Some components need to be wrapped in an .au-body container, and some don’t.

Solution

We will look to decouple the au-body from some of the design system components. Components that don’t have content area should not need au-body. For example, the link list component shouldn’t require to be wrapped in an .au-body. We will need to investigate where it fits and where it doesn’t.

Naming inconsistencies

Problem

It’s frustrating not knowing when to use plural or singular for components on the Design System.
For example we have the following:

npm i @gov.au/control-input
npm i @gov.au/text-inputs

So I don’t know whether I should do:

npm i @gov.au/buttons or npm i @gov.au/button

Solution

We need to investigate deprecating existing components that use plural and singularise them.
And we also need to consistent naming convention for all future components :sweat_smile:

Remove external link icons

Problem

Research done by a Gov.Uk team indicated that the external link icon doesn’t add value. There was also feedback from usability testing that some users were afraid to click the link because they weren’t sure what the external icon meant.

Solution

Remove the external link icon because it doesn’t add value.

Remove keyword list component

Problem

This component is not used often and is for a very specific use case. The same look can be achieved by some simple custom styling.

Solution

Majority in favour of deprecating this. The component will be deprecated.

What’s happening with Angular?

We received an amazing pull request for an Angular implementation within the current Design System Component repository, but it’s something our team cannot support at this stage. It would also slow things down significantly for existing users of the Design System.

As discussed, an Angular implementation of the Design System could exist in a stand alone repository. So we will be leaving the PR open for anybody who may be interested in building on this :slight_smile:

If there is anything I’ve missed or you would like to add more, please share below!

Cheers!


Flexbox for layout/components
#5

Alex mentioned at the meetup that you were looking into more automated approaches to documentation in the Design System. I suppose something like comments within the components pushing directly to a webpage/help centre, ro something like that. Can you comment on this at all - packages or approaches you are exploring to achieve this? It makes a lot of sense to make sharing and documenting an integrated part of a workflow when building something like a component library (or an API) and am interested in what you have investigated.


#6

A very early version of the Design System used “Living Style Guide” tools to generate documentation from SASS/CSS. https://github.com/davidhund/styleguide-generators
I understand Storybook is a popular tool which also works for React components as well as HTML/CSS https://storybook.js.org/

For APIs, Swagger is the de facto inline documentation tool for REST APIs https://en.wikipedia.org/wiki/Swagger_(software) Support for many many languages and just like a living style guide generates visual examples, Swagger displays example API queries that you can get started using APIs eg. https://data.gov.au/api/v0/apidocs/index.html


#7

Hi @robt

We are currently looking at generating our documentation for each design system component through the package source code itself. This sort of approach has been sparingly used throughout other design systems, namely Polaris with their React components.

Design system workflows are a :fire: topic right now, there isn’t really a ‘best practice’ or tool set that exists to do this in a sophisticated manner. Our current approach is the build the tooling required to achieve what we think is a sensible approach, learning what we can about common documentation patterns across other systems and then share-back our learnings and tools with the community.

We intend to role this out in phases, for example the first phase we’re looking at now, is to generate the README.md file automatically for each component. Second phases would be along the lines of automating our document workflow and examples. At that point where we might discuss options on how to share the docs and examples across our different repositories.

These are the two issues that are most relevant right now:

All of this aside, we encourage everyone to please bring suggestions and ideas forward on this topic, if you’ve seen better patterns for this kind of stuff, let us know! :smiley: