Git started with Ruter Design System

A presentation at Github Intility Meetup in March 2019 in Oslo, Norway by Ronny Siikaluoma

Slide 1

Slide 1

Git started with RDS Ruter Design System 12.2.2019 Ronny Siikaluoma, Design System Lead, Making Waves Thank you, pleasure to be here My name is Ronny, I’m a consultant in Making Waves and currently holds the role as a Design System Lead in Ruter I represent the Ruter Design System Team that currently consist of a visual designer, a front-end developer and myself. In addition we have Christian Nordström, Design Manager in Ruter, as our product owner. 1

Slide 2

Slide 2

• • • • Ruter = The public transport authority in Oslo and Akershus Located in the heart of Oslo. They are responsible for administration, funding and marketing of public transport in the two counties. This includes busses, trams, metro, and the ferry service. 2

Slide 3

Slide 3

+370 50% Mill • • • Ruter stands for over 50% of PT in Norway In 2017 they celebrated their 10 years anniversary as well over 370 mill travels So we’re talking high volumes • And getting everything to work together, especially from a design and ux perspective can be quite challenging 3

Slide 4

Slide 4

SCREENS WEB & APPS VEHICLES WAYFINDING INDUSTRIAL DESIGN PRINT DESIGN SERVICE DESIGN MARKETING Screens at stops and vehicles RuterBillet, RuterReise, Ruter.no, B2B sites, microsites, Ticket controll app Vehicle interior and exterior design Wayfinding to and at the stations, landmarks, signposts, content and placement Products like cassettes for timetables and information pylons Travelinformation, maps Service design – physical cardboard prototypes for cockpit layout, visitor centre Marketing – posters, foils, social media etc 4

Slide 5

Slide 5

GRAPHICS STANDARDS MANUAL Over the years, Ruter has tried to gather all the information about how to work with design in this huge ecosystem. And as many others they have their fair share of old’n dusty ring binders with manuals, guidelines and specifications hidden away in various bookshelves. Since I’m a bit nostalgic I really love those old floppy disks containing design files. Takes me back to my Amiga days J 5

Slide 6

Slide 6

ONLINE DESIGN MANUAL • • • • • • • • • In 2011 they created an online design manual Simplified sharing everything inside and outside the company But little or no support for developers Still focused on guidelines, less on concrete assets and tools. It’s an old Epi-site, hard to maintain, no real ownership Information became unreliable («last update 2012») Led to inconsistency between platforms in 2018 need for a renewal NEED for a DESIGNSYSTEM 6

Slide 7

Slide 7

DESIGN SYSTEM MATURITY Living Design System A process built into the organization Automatic Reusable components as part of application build process Hard-to-cross «chasm» for most organizations Manual Style Guide Simple copy/paste code snippets Static One-time PDF with brand guidelines Inconsistency The lack of a design system When we started, we tried to identify where we would find Ruter on this «ladder». - They had lots of guidelines, so it wouldn’t be fair to place them at the rock bottom. - Online, so that was slightly better than just PDFs - But they lacked code examples, snippets and tools for developers making digital products. So at the time we felt that Ruter could be placed around here ➡ Our ambition was to move ⬆ Ruter up the ladder and establishing a living design system built into - and serving the organization. 7

Slide 8

Slide 8

Agenda • What we’re building • How tools enable us to build with confidence, quality and efficiency • Why this creates value for Ruter So today we’re going to have a closer look at - What we’re building for Ruter How the right tools enable us to build and operate the DS as a product, and Why a DS creates value for Ruter…and in the end, for you and me - the customers 8

Slide 9

Slide 9

What 9

Slide 10

Slide 10

RuterBrand https://brand.ruter.no

RuterComponents https://components.ruter.as RDS has TWO main entry points/ «storefronts»: RuterBrand and RuterComponents. For brand assets and top level guidelines we use Frontify – this replaces the old designmanual And for developers we have a styleguide where we showcase our shared components Their both public so feel free to snoop around! 10

Slide 11

Slide 11

DESIGN SYSTEM ANATOMY Design System Process Components Docs Dev Standards Style Guide UI Presentation Layer Tone & Voice Assets Content Strategy Design Principles Visual Design Language UI Kit Brand If we look at what a design system can be from a birds eye perspective: - We can place the brand portal here And the component library styleguide around here 11

Slide 12

Slide 12

RuterComponents https://components.ruter.as Today we’ll be focusing on the component library 12

Slide 13

Slide 13

CODE React Since Ruter already had made a strategic decision to focus on React for future project, it was pretty obvious for us to build our design system components using the React library For styling, we use Sass. We did consider other methods like CSS Modules and Styled Components, but landed on a more traditional Sass -> CSS approach since we wanted to avoid a too tight coupling between components and styling. This way, even non react project still can import and use our Sass-tools or link to our minified css. 13

Slide 14

Slide 14

CODE React Sass Since Ruter already had made a strategic decision to focus on React for future project, it was pretty obvious for us to build our design system components using the React library ➡ For styling, we use Sass. We did consider other methods like CSS Modules and Styled Components, but landed on a more traditional Sass -> CSS approach since we wanted to avoid a too tight coupling between components and styling. This way, even non react project still can import and use our Sass-tools or link to our minified css. 14

Slide 15

Slide 15

CODE + UTILITIES React Lerna Sass Webpack Babel Other tools worth mentioning… - Lerna: A tool for managing JavaScript projects with multiple packages (Monorepos) It handles all dependencies just like npm, but also simplifes npm linking between local packages We use Lerna to bootstrap all node projects, build them as well as publish distributable packages to jFrog.

We use Webpack for most of our bundling (but some packages uses Gulp 4 as well)

Babel transpiles JSX to ES Modules and Common JS 15

Slide 16

Slide 16

The styleguide application is built on React Styleguidist. It’s kinda similar to React Storybook, but we chose Styleguidist for its clear focus on documentation 16

Slide 17

Slide 17

I found an article on Medium.com comparing the two - The author her placed Storybook as more of the workshop And Styleguidist as the place you present the finished product (window at the store) We’ve found Styleguidist to be quite good at both. 17

Slide 18

Slide 18

Also, Styleguidist is quite customizable. For example, here we see a barebone/ out-of-the box version of styleguidist. It looks perfectly okay, but seems a bit anemic if you as me J So we have worked quite a bit to make it feel more like a Ruter product… 18

Slide 19

Slide 19

This is how it looks: - We have a branded header and a sidebar with categorized groups of pages There is a custom front-page with an introduction and… highlights of the most important stuff There’s also guidelines for installation, usage, configuration as well as how to use… important aspects like layout, our spacing-system, responsive design etc. 19

Slide 20

Slide 20

In React Styleguidist, each component has it’s own «playground». ➡ - Here can you see a live render of how it looks and behaves. By using the integrated code-editor you can play around and test component features. Everything is hot reloaded and updates on the fly. When you’re happy, just copy the code an use it in your project. 20

Slide 21

Slide 21

Another nifty feature in Styleguidist is that it auto-generates tables for propTypes and methods in React. This is pretty sweet ‘cause the documentation will always stay in sync with the actual running code. Maintaining docs manually is quite painful 21

Slide 22

Slide 22

Since Styleguidist is a React app, it’s quite easy to reuse our own components within the application itself. - Here we use selectbox, table and card. By the way, this is a tool created by my collegeague Martin Dahl (in the audience) It’s a Color Contrast Calculator that helps ➡ you to find good color comnbinations. You can choose a color from the design systsemtint-stack, or a custom color, and check it against another. Copy the Hex, scss or Json variable. 22

Slide 23

Slide 23

The icon library also uses some internal component: - Button, selectbox, searchfield, checkboxes and cards Find available icons in the iconset Test sizes Can toggle the svg viewbox, get the react code or see an inverted version on dark background. 23

Slide 24

Slide 24

We also have a tool for testing typography: - Here we use our typographic scale, combining given font-sizes and line-heights Test with custom text or generate «ripsum» Test different font weights Copy variables or include statements for sass mixin 24

Slide 25

Slide 25

So how does the right tools enable us to build and operate the DS with ease, confidence and efficiency? 25

Slide 26

Slide 26

How So how does the right tools enable us to build and operate the DS with ease, confidence and efficiency? 26

Slide 27

Slide 27

CICD Github Enterprise TeamCity Jfrog Artifactory We have our CICD pipe here at Intility consisting of these badboys J 27

Slide 28

Slide 28

CICD Code

Build Test Release Deploy Github Enterprise is used for Version control TeamCity is our build environment and Jfrog Artifactory is where we store our distributable packages. When our users run npm install, they point to jFrog as the registry to be able to get the scoped packages. Jfrog also works as a proxy for the global npmjs.com so everything public on npm can be installed through jfrog. Lastly we have hosted versions of both master and develop (password protected) 28

Slide 29

Slide 29

GITHUB TEAMS We use teams in Github - This is a simple way to organize access to different projects Basically we have one organization: Ruter Directly below this, we have: Ruter Developers – Read access to all repositories And the DS has it’s own Ruter Design System Team – write access to our two repositories. 29

Slide 30

Slide 30

If we look at Github Insights we see that we had a spike in commits From november -> beginning of 2019 This is because we got an extra developer Marte on the team She has now taken over for Martin since he is on paternity leave We’ve also now moved into a more operating phase. We have created a lot of components that now are pretty stable. My own contribution has also reduced since I’ve taken on a different role. 30

Slide 31

Slide 31

BRANCHING MODEL v.0.6.4 master Let’s now look at how we use branches i our project - We’ve adopted a branching model called GITFLOW It’s well suited for collaboration an scaling the dev team GITFLOW can be initiated whenever – also in an existing project ➡ For example if our production code is in version 0.6.4… we still can start GITFLOW here. 31

Slide 32

Slide 32

GITFLOW v.0.6.4 master develop

First we’ll set develop to be our default branch We never work directly towards master. It’s just an image of what’s currently in production. ➡ Develop becomes a staging area for what’s coming and not released yet. We can commit directly to develop, but ➡ 32

Slide 33

Slide 33

GITFLOW v.0.6.4 master develop feature

Instead we create a feature branch for every feature, Nice to separate things ➡ …

Gitflow also supports handling emergency fixes. 33

Slide 34

Slide 34

GITFLOW v.0.6.4 v.0.6.5 master hotfix develop feature stash

So someone reports a bug in production!!! ➡ Need to pause the feature ➡ Stash it Create a hotfix branch – fix error and patch Also merge hotfix into develop 34

Slide 35

Slide 35

GITFLOW v.0.6.4 v.0.6.5 master hotfix develop feature stash

The continue applying stash and continue play 35

Slide 36

Slide 36

GITFLOW v.0.6.4 v.0.6.5 master hotfix develop feature feature

Another dev creates another branch This now includes the latest hotfix 36

Slide 37

Slide 37

GITFLOW v.0.6.4 v.0.6.5 master hotfix develop feature feature We all work in parallell 37

Slide 38

Slide 38

GITFLOW v.0.6.4 v.0.6.5 master hotfix develop PR feature feature When she’s done, she creates a Pull Request 38

Slide 39

Slide 39

39

Slide 40

Slide 40

40

Slide 41

Slide 41

41

Slide 42

Slide 42

42

Slide 43

Slide 43

43

Slide 44

Slide 44

44

Slide 45

Slide 45

45

Slide 46

Slide 46

GITFLOW v.0.6.4 v.0.6.5 master hotfix develop PR feature feature

Everything is good Feature is merged to develop 46

Slide 47

Slide 47

GITFLOW v.0.6.4 v.0.6.5 v.0.7.0 master hotfix release develop feature feature

We then decide to make a release Since this is a new feature, the release should be minor – no breaking changes We tag the release as v0.7.0 and.. Merge the release into develop as well All while I’m still working on my breaking feature 47

Slide 48

Slide 48

GITFLOW v.0.6.4 v.0.6.5 v.0.7.0 master hotfix release develop feature PR feature

When I’m done, I pull develop into my feature branch… ..Since the difference is quite massive Fix all issues and conflicts locally Create a PR 48

Slide 49

Slide 49

GITFLOW v.0.6.4 v.0.6.5 v.0.7.0 v.1.0.0 master hotfix release develop feature feature

Since it is breaking, we tag the release with MAJOR version As always merge it back into develop. 49

Slide 50

Slide 50

Commit Message Format <type>(<opt scope>): <subject> <BLANK LINE> <opt body> <BLANK LINE> <opt footer> feat(button): Remove prop for customIcon Since we now have a standardized set of icons, we recommend using one of these instead Closes https://jira.ruter.no/browse/RDS-473 BREAKING CHANGE: With the prop removed, buttons will no longer render the custom icons. 50

Slide 51

Slide 51

Commit Message Format feat : fix : perf : docs : chore : style : space) refactor: test : A new feature A bug fix A code change that improves performance Documentation changes only Changes to the build process, additional tools or libs Changes not affecting the meaning of code (e.g. whiteA code change that neither fixes a bug or adds a feature Adding missing tests 51

Slide 52

Slide 52

52

Slide 53

Slide 53

TEAMCITY BUILD CONFIGS Develop Master +:* +:* -:<default> +:refs/tags/() Enable to use tags in the branch specification Features-Bugfixes Releases-Hotfixes +: +:* +:refs/heads/feature/* +:refs/heads/release/* +:refs/heads/bugfix/* +:refs/heads/hotfix/* +:refs/heads/fix/*

  • VCS Trigger - Branch specification - Use tags as branches 53

Slide 54

Slide 54

I KNOW KUNG FU

For people unfamiliar with GIT, It can seem a bit scary. But as a dev who’s been using CVS, SVN and Team Foundation Server in the past ➡ Git makes you feel powerful! Sure, If you ask a designer on the team to just use GIT… 54

Slide 55

Slide 55

And this is the default interface, some will start hyperventilating. You may have strong opinions on using git via CMD or GUI Many devs consider mastering the CMD a feat of experience and skill. I don’t disagree, but… 55

Slide 56

Slide 56

Some of the most extreme «CMD junkies» go as far as GUI-shaming people that prefer using a visul interface. That’s not cool In our team we welcome both. We’re very design oriented, and it feels natural to use a GUI for most Git operations. For everything node related we tend to use the CMD Some use the Githup Desktop app, but 56

Slide 57

Slide 57

GITKRAKEN UI (DARK) Personally I use a tool called Git Kraken. - Electron app – cross platform - It’s a very visual interface. - Nice layout - Supports GitFlow - Great interface for diffing/merging - The commit-graph has nice colors. - It even has a dark theme. 57

Slide 58

Slide 58

TOOLS Abstract Sketch Libraries Sketch App

One of the reasons we’ve succeded into getting our designer to contribute to our GIT-repo Is that we work in similar ways when it comes to designing our Sketch UI Kit. This is the design equivalent to our React components

We use Abstract as a version control system for our Sketch files. 58

Slide 59

Slide 59

Abstract uses similar concepts and naming conventions Here we things like a Master Branches can be made for individual features Abstract uses commits and commit history And you can easily see whats updated, Even diffing the design When a feature is complete, it is the merged into master. 59

Slide 60

Slide 60

Why Why does the DS create value for Ruter 60

Slide 61

Slide 61

Why does the DS create value for Ruter 61

Slide 62

Slide 62

COHESIEVE EXPERIENCE We aim to make things easier for the customer across all plattforms. • • • Creates brand awareness Builds trust, predictability and loyalty to the brand Drives conversions, due to familiarity, reuse components and patterns (e.g: deviation) 62

Slide 63

Slide 63

SPEED & PRODUCTIVITY Prototype, develop, test and fail faster …repeat Focus on what’s important Helps onboarding new teams and teammembers 63

Slide 64

Slide 64

SHARED VOCABULARY We consider design to be a language. To be able to communicate in that language, we need a shared vocabulary. • • • • Reduces friction Language builds culture Enables shared processes Cross-company collaboration 64

Slide 65

Slide 65

QUALITY • • • • • Accessibility Responsiveness Performance Experience Testing 65