Hey, Developers 👋 long time no speak! Hope you all are doing well, and building some brilliant stuff 💪
On the previous post, we've talked about GraphQL and Prisma. For those who enjoyed it, the third and final part are already being written 👍 (no spoilers)
For today, I've thought it would be fun if we discussed something more front of the frontend focused. How does it sound, guys?
This is a brand new series of posts, developers 😎 with purpose of discussing the pieces commonly used to build a UI component library. We'll discuss some cool and popular topics such as style guides, frontend workshops, UI automated testing, continuos integration, and much more!
Allow me to talk you through what I have planned, guys 👌 I'm gonna describe a certain scenario, which can be quite common to designers and frontend (or fullstack) developers' routine. This scenario contains a few already known challenges to solve. We'll work on them step-by-step through each post. The best part is, we're doing this together 🧑💻
My main goal here is to present some common challenges when building a component library, and then propose some approaches and tools that can help us to succeed. Therefore, unfortunately, I won't dive deep into all the technical features of the tools presented throughout this journey. No worries, we will still have lots of fun!
To start with, I'm gonna present and talk you through the scenario that I'm proposing. Then, we'll talk about the existing challenges, and how we can address all of them. Today is mostly theory only, but next week we already start with the hands-on fun stuff!
Time to get our hands dirty, guys! Have you got your can of Red Bull (or coffee, or whatever) ready? Shall we get started then?
At a fictitious paper company, called Dunder Mifflin, the product manager's been raising some meeting discussions about the lack of consistency across the company's products. These products consist of web applications for sales purposes.
In those meetings, developers as well as designers have been invited. We know each role has distinct responsibilities, skills, and (last but not least) priorities. However, when the topic is about product quality, we should expect effort from both parts. I suspect it isn't reserved only to Dunder Mifflin, is it? 👽
Let's hear about the challenges they have been facing, guys!
Both teams, development and design, must deal with quite a few challenges:
Not quite an easy task, right? Lots of must's! Oh I forgot to mention, everything described above must be time-efficient 😉
Don't know about you, but I reckon, the following keywords can be extracted from the previous challenge section? Would you agree?
Fantastic, what we must address have been identified. Brick by brick, one step at time! We're gonna make sure Dunder Mifflin succeeds with their UI component library project!
In theory, everything is going good so far. But now I ask you - which way should we go? what tools can we use? Allow me to propose my plan, my friends 👊
A style guide is crucial when ensuring consistency across products and applications. It exposes the visual and design standards within the organization. The guide covers from basic information such as branding colours, text sizes and fonts, to advanced concepts such as UI components and prototyping of web pages.
Usually, and recommended, this work is done by the design team specifically. Obviously, depending on the company size or purpose of the project, developers might ended up working in this area.
A fantastic tool that we're going to use for building our style guide is Figma. It's a vector graphics editor and prototyping tool. I'm not a professional designer or any expert Figma user, but I'm confident I know enough at least to illustrate our next post (hopefully you'll agree with me 🤞).
The frontend workshop is indeed an interesting concept. Basically, what it means is an environment outside of your application development, where you can build your components. Does sound interesting, doesn't it? Have a look at this great article written by Brad Frost.
There are a few frontend workshop tools in the wild, our choice is gonna be Storybook. It's an open source tool for developing UI components and pages in isolation. It provides UI development, testing, and documentation.
The possibilities for creating an effective communication among teams are endless. Each company has it's own approach (or none sometimes). At the end of the day, more than any tool, it relies on good initiatives to make things progress. But, a little help is always welcome, right?
To help the development team be aware of the changes made by the designer team, if we are using designing tools such as Figma and communication tools such as Slack, there is a quite handy Slack app you can use for sending notifications. Also, Figma allows us to add comments to, and mention other users on the prototypes.
On the other way around, designers can be notified of development changes through a union of some great tools. Let me talk more about it in the section below 🙃
If not the most, it's one of the most important steps of our new UI component library workflow. Remember that designers must ensure consistency across everything, right? How to achieve this if not by reviewing every single component change, before the library gets a new version released?
That's when a fantastic platform called Chromatic comes to support us! It automates gathering UI feedback, visual testing, and documentation. A single place for design reviews, discussions, and an online UI library.
Before I forget, about effective communications, this tool can automatically send notifications to the design team every time a new change is pending for review.
I can't say enough about how important it is to have automated tests on our UI components to ensure new releases can be done with confidence. The possibilities are plenty, guys. We're going to implement some together throughout this series of posts, such as UI unit tests, end-to-end tests, snapshot tests, and so on.
To create a seamless and efficient process, we must implement some sort of automation. To do so, we're going to have our web application stored on GitHub, so we can make usage of git branches and GitHub Actions to set up a continuous integration (CI) workflow.
The plan is to have three different branches on our repository: master, preview, and develop. You can think of in this way:
The GitHub Actions will help us to perform certain tasks when the new versions are being applied throughout the branches.
Okie dokie, it all sounds awesome so far. Time to get down to business! Ready to start the work, Ladies and Gentleman?
Here is the agenda for the next part of this series:
Does it look like plenty of fun, or what? I'm excited, hope you are as well 😃
I've decided to split the subject into a couple of posts to ensure it's enjoyable to everyone to follow.
I wish we have a few of learning, relaxing, and fun moments together throughout the journey ✌️
See you in the next one, guys. Stay safe you all!
The Welcome, Developer has a brand new LinkedIn page! If you enjoy our content, we would be very happy to have you as a follower! In there, we will update you about new posts, new projects, and all the cool stuff!