Creating a UI Framework: A Story of Blood, Sweat and Tears… of Joy!
When my company offered me the opportunity to be on a team that would create a new amazing UI framework, I was ecstatic.
I love coding. Building something functional from scratch has been a lifelong dream of mine. Since I’m not an arts-and-crafts kind of guy, coding is a great way to achieve that dream. When I started my professional life as a developer, I envisioned myself building something that could help other developers like me in their daily work.
So, yeah, I loved pretty much every aspect of this ambitious project. And, creating a UI framework ended up being one of the most joyous efforts of my career. However, before the joy, my team had a painful start. It would take many tears, a whole lot of sweat and some bloodshed before it was all said and done.
Developers Thinking UX and UI
At some point most developers today are asked to create “something with a beautiful look and feel and great usability.”
Cringe.
How very specific. Do you see the problem?
Actually, the rise of the “Age of the App,” means constantly looking for better ways of making it possible for users to interact with applications.
Usually, we try our best to create something on our own. Sometimes, we get lucky and have UI and UX experts available to help us handle the problem and find amazingly creative solutions. Then we simply have to implement those solutions and consequently dazzle our users. Easy.
(By the way, this is one of the many reasons why it’s so important for developers and designers to work together.)
But the major problem starts right here: building those great UIs.
Most developers have no design background. And, the great languages we have available (CSS, HTML, JavaScript, etc…) do not easy frameworks make. So, we started searching for solutions.
Massive UI Framework Research
Achieving the 20% of features that will be used by 80% of developers is no easy feat. We ran a lot of usability tests with the first versions of certain components and gathered as much feedback as possible. Very few patterns have the same features and configuration options that they started with. New use cases came up often, and we wanted to give as much functionality as we could, always with one premise: easy to use, but fully extensible.
So we selected around 70 of the most installed apps in the world to research the typical patterns, typical interactions, and how the UI structure changes between applications.
We also researched UI frameworks to find one we could use as a base. There are many great ones out there, and these frameworks offer a good number of patterns. But, when we looked more closely, either patterns that we felt were necessary were missing or they had patterns we didn’t think were needed.
Also, our developers are used to working in a low-code platform where they code visually by just dragging and dropping elements to the screen. With the frameworks we were researching, we always had to go back to HTML and CSS.
So we decided to create a UI framework from scratch that offered all the patterns we needed and that would be a better fit with what our users were used to.
The Team Goes At It Alone Only to Sweat Some More
We started coding the framework, and with that, a new set of struggles appeared:
- How will our patterns adjust on different devices? Should we consider using painful media queries or is there a better way of providing that level of customization to our users?
- How can we make generic enough patterns that address every project need (I see you, calendar)?
- How do we make sure all patterns work on older browsers (burn in hell IE8)?
Dealing With Different Devices and Browsers
The majority of the problems related to CSS came from old browsers like Internet Explorer 8 and 9. Having a consistent UI framework for all browsers is very, very hard to achieve. We decided to create a mechanism that allowed us to have a smart solution for specific browsers. All applications built with our framework have a container with the class “Page,” which identifies our layout. We also added a class for the browser and device, like this:
- “Page desktop ie8” tells us that we are on a desktop using IE 8.
- “Page phone chrome” tells us that we are on a mobile phone using a Chrome-based browser.
And since we were targeting devices with a CSS class, developers no longer needed to get into breakpoints and media queries, which was great. We were able to reduce the number of CSS lines and allow developers to easily create responsive apps without media queries.
Designing Consistently for Multiple Patterns
This drew some blood. We did serious research on the current UI design trends so we would know how the themes must look. More than that, we wanted to have great and customizable user interfaces with very little CSS. Basically, a tool that would empower any developer — regardless of their CSS knowledge — to build amazing-looking UIs.
The big challenge was that instead of designing single pages, creating a theme for this UI framework involved creating a modular system of components that worked well together. We played around with primary and secondary colors to understand how flexible each theme was.
Another thing we soon realized was that it is very hard to create a style guide for an unknown number of patterns. Why unknown? Because we would be creating more as time went by. Worse, we needed several style guides because we had 4 different themes with more than 80 patterns each. For this, we created a tool that would allow us to create visual tests and make sure everything was up and running.
The UI Framework Is Released
Fast-forward to eight long months later. After dealing with all the struggles and pains, our first beta version was ready for testing: over 80 easy-to-use patterns distributed between approximately 10 categories.
Only one thing was missing: a cool final name for this framework. After a lot of conversations, the team decided that, since our framework was so simple to use, we would call it the (smooth as) “Silk UI Framework.”
During the entire development process for the framework, we had some Alpha users testing and providing feedback that we kept iterating. But we still needed to test our work with a broader audience, so we started a Beta program. The result was a huge amount of really valid feedback. By the time we released the framework to the world, things were pretty solid.
To keep the user adoption growing, we kept up a really strong presence in our forums. We tried our best to answer every single question and gather the amazing feedback from our users to improve our framework.
From Web to Mobile to… the C-Suite!
Our framework has been publicly available for the last 1 1/2 years. Our user base is continuously growing. In September we took another big plunge and released a new version, one that’s specially dedicated to mobile applications.
If I had to choose, one of the best moments of the entire project was when we received feedback from a customer. And not just any customer. This was the CIO and the CFO. Without any previous development knowledge, they implemented a really amazing looking application in record time, and all while only coding that application between 6 and 8 AM.
Now, that’s what we’re talking about!
The journey was long and hard, and I’m proud of the work that our team achieves with this framework every day, helping customers one application at a time.
The ideas shared in this post resulted partially from the research project RADicalize, which was supported by the EU and PT2020.
