What should we prepare before starting up a UI lib
Developing an app without having a UI lib is probably very hard and a waste of time. People are pretty easy to be blocked by issues of creating components themselves, especially when most of them are lack of related skills. That’s the reason why lots of startup/teams which don’t have their own UI lib and don’t have enough time/skills to build a new one for themselves, choose to use open source libs to finish the work. Even though some of the libs are not well maintained, they are still better than nothing. I guess lots of readers of this article met this kind of sense before, maybe more than one times.
If the application goes well on the market, more and more development jobs will be planed as well to spread the application, to get more customers and money as well. Upgrade UI is one of the major parts of the development that we will care about at the most because we are talking about the UI, aren’t we? The more the app lives, the more customization you team will make on the UI. And then you will get to know that it’s very hard to make customization of the existing UI. Following are the reasons, at least one of them maybe catch you up.
- The UI lib doesn’t provide an official interface to customize the visual effects, or only a few of them, e.g. colors.
2. No way to change the interaction mode. e.g. how a slider moves.
Smart engineers always get the idea to change the UI on the fly. Like what we guys did several years ago, create additional style sheets to override the default theme. Sometimes it’s tricky because you have to add more !important after the style value to make the override works. And finally you will get a series of CSS files which are filled will contents contains !important, and also selectors like id, class, etc. It’s hard to maintain, and in addition, it’s obvious that you will not be able to upgrade the UI lib along with official that means you will not get the benefits of open source.
And, it’s barely impossible to change the interaction mode.
So, you can only choose one of the items below for the long term.
- Don’t change anything on the fly, use the UI and believe the UI, and ask designers of your team to use the UI as the design language.
Believe in one design system is better for saving time while solving UI issues. People don’t argue for basic UI stuffs like what the button should look like and how should it interacts with the user. They are focusing on resolve problems the users meet.
2. Try to create your own UI (and plus design guide/language if necessary)
Your team(usually your manager) decides all the things of the UI. Each of the changes merged to the code base and no more workaround existing. And you will never need to worried about some tricky problems while using open source UI lib(Ant Design Christmas Easter Egg).
Design guide
If there is a designer(s) in your team, it’s easy to work with him or her to prepare a visual guide for the product. As I know, designers are happy to make it since it always reduces communication efforts. Think about an engineer asks a designer, ‘hey, what is the width of the regular button? I cannot find it from the docs’.
If no designer, it’s still easy to get started since there are so many articles, open guide over there. Like flag UI, Material Design, etc.
Get approved for the design guide
Whatever, it’s absolutely important to get more consensus from your managers. Try to tell them what problems you guys meet currently and why it’s better to fix it(from the point of view of the people you are talking to). How you will fix it and how many resources you need. And the most important part, what the benefit is if you guys finished. That reduces the possibilities that one of the key managers kills the project since they dislike the idea in the design. If you are not worked for a big company, you probably only need to go get attention from engineers.
Style of API
It’s never been a mistake to imitate the existing libs. If all the team engineers are familiar with an open source UI lib, you would better pattern or even copy the APIs from it at the beginning. Because It’s a great benefit that the team is able to switch to the new UI lib without any changes on code but only the dependencies. You don’t need to worried about the large numbers of complaints from your colleagues because the UI lib forces them to update the code or the product will down. Actually, in most of the cases, they will disagree with the integration of the UI lib, or delay.
Begin from nothing?
No, except you know a lot about how to building a UI lib from nothing. Usually, I recommend starting from an existing project. In addition, you’d better very familiar with the details in this project, the code structure, the build scripts, the test, and so on. Or you have to ensure you are able to learn very quickly. Please be noticed, the earlier you release the first version for the team, the more resources(engineers, time, money, etc) you will get. It’s OK to have only part of the basic components in the first release, you will get more feedbacks and they are good for improving your work.
Summary
For long term business purpose, build own UI (lib/guide) is probably one of the most important plans in tech. And, you have to prepare three things for it.
1. Design guide
2. APIs
3. Basic project
Thanks for reading.
