This tool crawls over the repository files and determines if they are relevant to be analyzed, based on the configurations we provide. After that, we use react-scanner to perform the static analysis of the code. Using the simple-git interface, we clone all repositories sequentially. Having the list of repositories that have design system components as dependencies, we now need to clone them in order to be able to perform the static analysis of the code. All this initial processing and filtering is supported by GitHub APIs’ capabilities.įigure 1 - Simplified map of the data retrieval process. If any of them contains a dependency on one of our packages, we mark that repository for analysis. We start by retrieving a list of all the repositories from the Talkdesk codebase and we perform a quick analysis to understand if it would be a relevant repository, by checking if the most used programming language was JavaScript.Īfter retrieving just the JavaScript repositories, we check for the package.json files of that repo (there can be many, f.e. Using Octokit - the official GitHub API SDK - to accurately manage rate limits. #Metabase histogram codeBut how do we fetch that code in the first place?Īfter some research, we found out that Twilio’s design system team had already answered some of our questions, so we were inspired to follow in their footsteps. We decided to do a static analysis of all the code that is using our components. So we decided to go to the only place where, surely, we would have the references to all of our deliverables: the source code. This approach would also make it impossible to retrieve information from previous versions of the components that would remain without this capability. However, we soon realized that some elements (like Modals or Tooltips) are only rendered in the browser for specific use cases, and we could easily miss and never count them as being used. We initially considered equipping our components with some data attributes that would later be captured and analyzed by some analytics tool. The first question that we needed to answer was: how are we going to collect all the data? So we decided to mitigate this and gather proper usage data about our design system. We did not know which components were the most and least used, and which teams were using them. We had no data about the usage of our design system components. However, we were lacking a big thing: we had no way to see the big picture and understand if we were addressing the asks from the “loudest person in the room”, rather than the problems that impacted most users. The great advantage of having our users as our colleagues is that they are always just one message away from providing all the feedback we need, so we were able to get that at any time. #Metabase histogram softwareThis includes not only software engineers but also product designers and technical writers, with the total number exceeding 900 users.Īs part of the design system engineering team, we would often need to prioritize and decide what should and could be done to make our users’ experience better. Talkdesk’s design system - Cobalt - is used by all the R&D teams at Talkdesk. Metrics that Matter - Measuring the Impact of the Cobalt Design System (Part II)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |