A presentation at Github Intility Meetup in March 2019 in Oslo, Norway by Ronny Siikaluoma
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
• • • • 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
+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
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
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
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
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
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
What 9
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
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
RuterComponents https://components.ruter.as Today we’ll be focusing on the component library 12
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
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
Babel transpiles JSX to ES Modules and Common JS 15
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
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
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
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
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
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
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
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
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
So how does the right tools enable us to build and operate the DS with ease, confidence and efficiency? 25
How So how does the right tools enable us to build and operate the DS with ease, confidence and efficiency? 26
CICD Github Enterprise TeamCity Jfrog Artifactory We have our CICD pipe here at Intility consisting of these badboys J 27
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
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
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
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
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
Gitflow also supports handling emergency fixes. 33
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
The continue applying stash and continue play 35
Another dev creates another branch This now includes the latest hotfix 36
GITFLOW v.0.6.4 v.0.6.5 master hotfix develop feature feature We all work in parallell 37
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
39
40
41
42
43
44
45
Everything is good Feature is merged to develop 46
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
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
Since it is breaking, we tag the release with MAJOR version As always merge it back into develop. 49
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
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
52
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/*
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
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
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
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
We use Abstract as a version control system for our Sketch files. 58
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
Why Why does the DS create value for Ruter 60
Why does the DS create value for Ruter 61
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
SPEED & PRODUCTIVITY Prototype, develop, test and fail faster …repeat Focus on what’s important Helps onboarding new teams and teammembers 63
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
QUALITY • • • • • Accessibility Responsiveness Performance Experience Testing 65
