How do you develop and use Atlaskit / AUI?

Atlassian Ecosystem Design
, ,
2

Hi :wave: @dzmitry.hryb

Thank you for posting the question here. Here is the answer from @daz, @tshugart and I.

As of TODAY, both libraries aim to implement Atlassian’s Design Guidelines. And their main differences are:

  1. Atlaskit is built using React, whereas AUI is built using HTML and CSS.
  2. AUI and Atlaskit do not implement 100% of the same components, nor using the same APIs.
  3. Atlaskit is relatively new which started 2 years ago, whereas AUI has 10 years of history.

Atlaskit

Atlaskit started 2 years ago as an effort to implement the new ADG designs for all Atlassian Cloud products which are built on top of React. It started as a repository of leaf UI components and un-opinionated about how components are used.

Over the last 2 years, almost all single-page applications built in the Atlassian Cloud use React and Atlaskit. And as Atlaskit matures and Atlassian products and ecosystem vendors lean in more heavily into Atlaskit and React, Atlaskit need to improve on how our consumer product and ecosystem teams can consistently implement these components and patterns in order to provide consistent and performant user experiences across our Atlassian products and ecosystem. Atlaskit components need to walk the fine line balancing between being opinionated about implementation best practices and providing the right level of extensibility. From here on, Atlaskit Core components will work on:

  1. better logical groupings of components and design primitives as exports in the components.
  2. provide extensibility by
    • consistent API with default props, ability to setup controlled props to override default behaviors as needed.
    • compose-ability of components through ability to set render props and more examples
    • a flexible theming API
  3. more common use cases and patterns

AUI

AUI started 10 years ago as an effort to share common UI solutions across our products. At the time, the best mechanism we had to share UI in Atlassian was Atlassian Plugins, also known as P2…

AUI has had a large number of contributions over time, each with disparate coding philosophies. The results have been mixed. AUI’s pain points have been:

  1. its monolithic nature – take all or none of it;
  2. its low-level API of HTML and CSS, and
  3. its distribution model on P2.

The AUI team will be addressing these pain points in upcoming major releases, moving it in a direction that’s more sympathetic to the needs of front-end development in 2018.

In 2017, every Atlassian product UI has a minimum of 40% utilisation of AUI.

  • Every one of them ships AUI’s CSS reset and basic styles.
  • Most use dropdowns and inline dialogs from AUI.
  • Modal dialogs are used in several places.
  • The remaining components are used occasionally.

Their usage is based on a number of factors.

  • Did the component exist in AUI before a product design team decided to implement a design pattern? If it didn’t exist beforehand, a product team likely built their own.
  • Does the component meet the intended use-cases of a given product? Some components’ behaviours were built before an understanding of the team’s expectations was established, which led to them not being used widely or at all. AUI’s async dropdowns is a good example of this: the feature was built expressly for Jira, but Jira do not use the behaviour as it caches the response forever, whereas Jira need the contents to change each time the dropdown is opened.
  • Did the team know the component existed? Sometimes the teams don’t check whether their problem has been solved already, and start down the path of building their own before they realise.
7 Likes