 Yeah, well, it was all stopped like five minutes ago, so I'm going to start quickly. So it works, well, alternation cycle conditions. And first, let me introduce myself, my name is Pirate. You can follow me on Twitter, at Foxman, on YouTube. You can also follow us. My name's Alan, we are one of your... The biggest... you've come up from in Europe. It's just not here. It's all there. Two thousand people working in tech. One of them is working in office. And we are selling one at 250k. And the rest is possible. I'm trying to work with this government. We have to set up that we have six autonomous teams working in different domains. If you work in retail, you will be surprised how big and complex the whole life cycle of the product you want to sell is. Especially, depending on what you're selling. You have to make up all the campaigns that depend on ID. You have a huge life cycle. And for the whole life cycle, we have a lot of tools. And currently, we are trying to develop a couple of new applications. To solve a couple of issues we had in the past. Also, we want to update. I guess you are hearing the only way. Good. So, to think that each team is working in one domain. Which is there to depend on working on applications. Therefore, we have six teams with different developers working on different applications. First thing, while we need the cycle, our department is ready to have the same open field. So, if you have new applications, you want the user experience has to be consistent and cohesive because it's an application. If you don't want having one user, it can be an internal experiment. But we have both. If they have to learn to get a training on new applications, it should be intuitive. It should be easy to learn. And once you've learned it, you should learn again from each application. That's one thing why we need the website guide for our job application. The second thing is, engineering perspective. We as a front-end developer, we don't want to repeat ourselves. Meaning that in the web works, these days we have everything in components. We can put all our slides with CSS or SCSS. And once we have the slide guide with all the basic design language items, then we don't need to repeat a couple of common things. You don't slide your buttons again and again. You just do it once and everyone else can just pick up a slide. In our case, we can pick up some patterns. We have some complex components which developers can just use instead of developing multiple times. So we can work on other topics and focus on other things instead of... So that's the second thing. Hi again. And the third thing for everyone of us which we already learned is that we can move fast. As we are developing a lot of applications, we have a lot of assumptions. So we start small, having small MVPs or even prototypes just to check if the design we have really fits in what the user expects. And with a style guide, we can move quite fast. Like before that we had maybe weeks working on things. Now we have like maybe days developing a first prototype with an existing style. So users already know how to work with it instead of learning a new thing or having just simple Google Forms or mock-up. Here we can really have a clear UI. Users can work with, mocked with data so we can really get good feedback on the assumptions we have from the product. So these were the three things why we need the style guide and then we had a lot more requirements. So in our setup, it was also like how can we all contribute to the style guide? Meaning that we don't have only front-end developers contributing to this. We also had the interests of UX designers who are developing the whole design language who was also interested... They were also interested in contributing to the documentation on that site. So we needed a setup where it's easy for the UX designers and easy for front-end developers and on top maybe even for anyone else, our assumption was like whoever wants to contribute, the initial gap should be like small. The learning curve should be small instead of like a huge setup. Therefore, I clustered our requirements a bit into easy to maintain. We already had one style guide approach in the past where we had the issue that it was a static site generator. It was a bit hard to configure and whenever we wanted to update the documentation we had to do it manually because of the way the static site generator in that case worked. And also the tool we used which was an open source tool it was called fabricator. It is now deprecated. One and a half years ago it was deprecated. So it was even harder working on it. So we really didn't need to have something which is easy to maintain even with maybe almost no maintenance cost for us rather than having one application we developed anyway. So this means also we wanted something which is integrating quite well in our existing developer workflow with GitHub because internally we use GitHub Enterprise and if we open source we also do it on GitHub.com so everyone as a developer knows GitHub quite well and the whole ecosystem around. So we wanted a solution which fits good into this day-to-day workflow. The second thing is easy to contribute as I said. So again UX designers and also developers should be able to contribute without having a huge complex setup maybe even not much of a setup anyway. Then easy to customize. Here's the thing with static site generators or sometimes even with more complex content management systems for documentation especially for us. If you're developing front-end application you work with HTML, CSS and JavaScript. That's your basic technologies you use but often with any management system you end up having template engines new languages on top maybe even frameworks or libraries on top of it which you have to learn to create your own style, your own template. It's not really complex for a developer to catch up but we quite often had the issue in the past that at one point you have maybe a feature you want to implement in your own staggered application which the engine doesn't support so you have hacky solutions, you have to go deep into the source code maybe to understand or maybe even extend the rendering engine instead of just using what we use anyway HTML and CSS. So here we also wanted to have a solution which could fit maybe into our current approach and just developing maybe even a single-page application and having APIs which provides us something documentation content for example and the last one was it's already a solution but we also had as a requirement it is we wanted to use Markdown so in our setup all UX designers and all front-end developers we all agreed on the fact that Markdown is a nice thing to use for documenting stuff especially it's easy to catch up the syntax and it's easy to use and there are a lot of libraries for rendering parsing Markdown and now comes the solution solution number one, the basic workflow is if you're working with Github Github Enterprise, it's basically a common pull request workflow we have on Github so we have a developer UX designer they create a pull request for code or for their documentation which is the Markdown file in one of these repositories it's either in the SCSS repository or the components here was one decision we made to enable also developers to do their documentation as fast as possible because often most developers complain of switching to another repository to another interface and here we said if you develop the feature in the repository there's another subfolder for the documentation so you can also update the documentation immediately instead of switching the context maybe, get distracted and then maybe two days later you have to document the feature you worked on and you already lost half of your decisions and once it's merged the whole process of getting to the Stygite application is automated with our CI solution which is in this case it's CircleCI and we test everything we build the whole Stygite application which is a single-page application because we also wanted that kind of approach so we have full autonomy in the technologies we use in the decisions we make in the conventions we create on our own instead of relying on others because they kind of limit us in the past so whenever there is a pull request merged we immediately deploy the new Stygite application for us it was important that the state of the library the repositories should be mirrored immediately in the Stygite application instead of having different forks and different states the only review process we have here is really the pull request whenever you have a pull request developers, designers, they sit together and check if the documentation is updated if it makes sense, if it's working if the markdown is correctly written, if there is maybe like instead of a bigger hat than you use a smaller hat than these kind of small things and we all check them together and the other thing is I go a bit more into the detail for each repository as I said we have UX designers who contribute to every repository and we also had for us it was really good that we also had now one UX designer contributing also to SCSS code so they also had the interest to contribute to the code so they had this nice UI toolings like sketch and they can generate their Zask code out of it and it will also make sense for us because they have this design they generate their SCSS and then it was more having code consistency across developers and the UX designers that the whole code looks like one developer has written it so there is a nice open source tool which is called Styland which is basically linking your SCSS or something I can recommend it, it's easy to set up this is just a setup file the good thing is there are even existing guidelines you can just use and extend or even just with a tool liner you can just use the existing guideline and then they will link the whole project for you and the other thing is that for each pull request we also linked again so we linked the SAS code and then we also built one time building up because linking is one thing but if it's really successfully building it's the other path and again documentation is also done here just as marked on fights and the other interesting thing is if we work on the front end space or you maybe work or read something about this people are developing a lot in components in our case we develop in React oh something which means that it's quite nice to just develop small components and it's also even better to document that because there are existing standards open source standards also in the javascript world one is JS docs which is kind of the same like Java docs kind of there might be some differences but it's like inspired from it oh you can't see it really if you could see it here's a description in your comment of the component like what the component is really doing let's say you have a header component with a lock in maybe you want to provide links to different navigation items here's a short description here's basically if a React component the React component is just a black box for the user and you can just throw in some data into it and you expect as an output an item an element DOM items so in here for example for one of our components we have we documented all the properties they call it properties one component expects or wants from you or supports so here's another example because this one is big again description property the nice thing again about markdowners you could even provide in the code some examples how you would use the component in your own code with the example flag tag and with this nice open source library called documentation.js you can generate from your JS docs the markdown which means the developer in this normal day-to-day work he's just developing the component providing us this documentation and this creates the markdown for us so the developer doesn't have to do anything this is also part of the CI process so we develop also we create also these API documentations for our components from the comments and thanks to the whole CI integration and continuous deployment strategy we have whenever you just create a new feature and you push it everything else is automatically generated for you so it's as I said easy to maintain for the developer because basically you just don't really care once it's set up it's working it's currently working you just develop your components your features for the style guide and you don't care really how everything else is built up and this is a screenshot how it looks like it's our own design so we kind of also dog feeding the style guide with our SCSS library and everything so we can even test if everything is working and then here there's this is the basic documentation we still have to do manually and let's say we have this API documentation for the component and this is also generated automatically and everything is bundled into this javascript application so that even it's a nice side effect because we bundled everything already even the markdown is javascript object already this is even offline you could even if you don't have any internet connection still use this application because everything is already there it's a static site so we don't even do any API codes anymore it's just getting the basic javascript files the styling and then we are done conclusion documentation as important as code when we started this we had some tough discussion we already had before the talk it's about some developers they think just my code is a single source of truth so if you don't understand my code then you will also not understand maybe the documentation so I don't do it anyway it's needless time I don't have to do it why should I do it just learn to read my code but we had some tough discussions and we decided that the documentation is like a first class citizen it's as important for the pull request as your code if there is no documentation the pull request got rejected in our case if you use github you can provide pull request templates and there you can provide checklists and one of the checklist items is also do you have any updated feature or something please update the documentation otherwise it gets rejected so if there is no documentation we don't merge it that's at the beginning it was hard for all the developers but currently everyone is fine everyone is accepting this approach and now we also see the benefits because now everything is documented if you have new join us they can go to the library quite fast it's easy to onboard new people instead of having this knowledge silos where you have to maybe ask each person individually who developed which component and another thing is keep entry level low which was for us basically if you want to contribute you just need to know markdown yes you also need to know a bit github like for example our UX designers they never used github before so we had a small training session with them but thanks to github in that case they have this nice desktop application so it was even easy for them to understand the basic thing like okay I need to create a branch I need to do my stuff and then I create the pull request and that's it for them and currently it's also working pretty well because most of the general documentation about why we choose this behavior and why this things almost done so use documentation.js I can really recommend it if you have a javascript project it's really helpful because if you have your markdown generated you can have two things one in your application or the second thing is if you have a github repository it's already rendered so people can immediately see your documentation which is also a nice side effect for us and the last thing is this approach kind of I think these days it's called something like gemstack which is javascript, apis and markdown so you basically use github you use javascript as much as possible and maybe you have additional apis for additional things one popular page is smashing magazines if you know this developer page they are fully into the gemstack approach and there are also like big companies kind of like Netlify who are allowing this thanks everyone if you are interested I have a demo project sorry you can, that's fine you can see it anyway we have a very tight schedule so questions outside the door thank you for navigating all the trouble