Topcoder UI Kit
part 2 of 3 of Topcoder design series
Good User Interface (UI) collection helps to develop constistent apps faster. At Topcoder, we build a minimal UI Kit for our latest development stack. It uses React and Redux, Webpack, and runs on Node. You can find the latest version on GitHub. We’re working on some great challenges, so stay tuned.
Thing about development while you design
There are unique challenges in our process you have to understand well to be successful. Topcoder is a remote company and uses crowdsourcing to build software.
The Topcoder product development team is currently 5 people and we span around the globe. We are avid users of the Topcoder crowdsourcing platform to develop all our apps. To achieve that we break features into small chunks of work that we post on the platform as competitions. A lot of different members compete to deliver a winning solution. Although some competitors may stick with us for a while, most don’t. There are a lot of different people who work on the source code.
Another difference is that there’s no sense of typical team communication . Challenges don’t allow the designer and developer to talk to each other when they try to solve a problem. One can think of a more traditional waterfall process — once a stage is completed, you pass it over to the next step. The challenge here is how to deliver good quality products. We go through small iteration cycles, following a more rigid delivery cycle.
High quality design specification is the key to successful application development. It should follow the standards, and explains all states and components.
In current development life cycle Agile is the norm. So we have to adapt our thinking to use a series of challenges as a development sprint. We need finite, modular and isolated solutions that can fit into the grand scheme of things. Think of each feature development as done by separate team, and you will be on the right track. It is like Spotify’s culture — people move from feature to feature. Challenges ensure we work with very smart people who are passionate about the particular problem.
The role of our team is to create the standards, and provide all information for all challenges. Building set of simple rules that are easy to understand, and a process that prevents errors, is key to what we do. The design language and UI Kit are products of that process. We want to empower the community to succeed and create amazing designs.
Core elements
The core elements are the building blocks of the UI Kit. They follow the design language principles, and have only a handful of options.
Global constants
The global constants define the properties of the UI Kit. They are: base unit, corner radius, type families & scale, and colors. At current we haven’t set constants for any interaction properties.
All elements have size. We defined a simple 4-tier system — based on t-shirt sizes — for all core elements: SM, MD, LG, XL. Each core element includes all 4 sizes. Some components might have more than 1 size alternative, but it is not required. I will cover the differences between elements, components, and containers a bit further in the article.
All elements have states ( variations that allow the user to identify the system affordances and status). Each core element should provide designs with all states. We identified the following:
- normal,
- hover,
- clicked,
- tapped,
- focused,
- disabled,
- loading,
- visited,
- pressed/checked (on/off).
Elements, components, and containers should provide designs for their variants. Variants define semantic cases for contextual use. They allow to identify primary vs. secondary buttons, or required field vs. optional one. We have the following variants: default, primary, secondary, required, warning. More states can be defined based on the semantic meaning of a component.
How to mix and match elements with properties
The most important thing for building a well composed interface is to know how to use the UI Kit. Instead of experimenting with different properties, try to stick to some general guidelines:
1. Use elements within one size family, if possible. There could be examples of a block level form where you might want to have a bigger block button at the bottom. For the most case sticking to medium (the default size) would provide a great look for your interface.
2. Understand the semantic properties of your components. Think about the states and use cases the user will encounter. What information they will need? What is the typical behavior? What does your design represent at any given point?
3. Be consistent with your patterns. Once you establish a pattern, it should be available on the UI Kit and reused when applicable.
Buttons
Buttons are the primary interaction elements of an app. We have default, primary, secondary, and warning buttons.
Forms
All applications need forms. We have simplified and extended form controls. Depending on context you can use one or the other. Login form can use simple form elements, for the pattern is pretty well known. The profile settings page should use full form elements. The data usually is formatted in an application-specific way.
Labels
Labels are the text identifiers for interactive elements. Usually combined with form elements, yet you can use them with other elements, or alone.
Text
Topcoder relies on text to communicate a lot of concepts, so typography is paramount. Challenge details, listings, customer communication, forums, blog posts, etc., all contain text. It is important that our typography works for both short and long bodies of text.
It is important to draw a distinction line between labels and text. Text is content; labels are explanations or metadata. Navigation and buttons use labels, while a page would use text. Think of a label as something that you can replace with an icon. Text is content that cannot be transformed. I cannot replace the text of this article with pictograms, and convey the same message. Hope you understand how confused I am right now.
Icons
Yeah. Those. Sometimes you have to replace text labels with icons. Icons are vital for providing graphic encoded information. We use the amazing set from Nucleoapp.com. There are a lot of great sources online as how to use icons. Google material icons is a great starting point.
For the need of our community profiles we developed our own icon system. It renders the member skills on Topcoder. I captured the process in a work Google document so you can take a look.
WARNING! Avoid icons that are cryptic, unclear, or deviate from the well established patterns.
Components
You cannot be a successful designer if you do not understand the media you’re designing for. In the case of web app UI, you have to know more about how modern applications are being developed.
Developers think a bit different about applications than we (designers) do. They like to find repeatable patterns and break down your designs into small pieces of code. They do that so they don’t repeat writing the same code over and over again. Here is an actual guide of how a design is broken into components, by Facebook.
Think of components as symbols in Sketch. If you use Sketch, it is the best way you can achieve component-based design today.
A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties — EECS Berkeley / via Google
See what I mean? Developers don’t speak the same language as we do. This is key to understand how to communicate your design ideas with them. It is important that you provide a detailed design specification, and explain how your design will function. This way the developers that make your design into actual code will not have to guess.
In React (our UI javascript library) everything is a component. Components are inside components, that are inside components. It is mind-boggling at first, but there is a system to the madness. There are 3 main types of components: dumb components, smart components, and containers. And they all live inside each other.
Dumb components
These are the smallest components of all. Like the end doll in the set, they can’t have anything inside them. Usually those are components that do not handle data and are very small. An avatar, button, icon, list item — these are all dumb components. They render what data is passed to them via the wrapping smart component.
Smart components
The smart components usually manage the data and use dumb components to render it. A calendar is a great example of a smart component. Most of the time you’ll have to design smart components reusing the dumb components. Let’s take a calendar for example. You will reuse some elements: the month navigation, month title, day display, day grid. In this case the dumb components would be the navigation, label, and day display. Each will have different states ( weekday, weekend, off-month, etc.). The smart component will render the layout and manage the data.
Containers
Think of containers as the page you’re designing. Most of the time the page displays a lot of smart components. Think about what are the states of the page you’re designing, and how that affects the content inside.
Practical approach for designers
When you do design for Topcoder, you have to keep in mind our design language principles. Always see if the thing you need exists. If so — reuse it.
Never redefine the global constants. You should not invent new colors or typeface sizes, buttons, or form elements. You should try to combine the simple design primitives into new components.
Sometimes you will need new elements — you can design dumb components. If we need a new leaderboard design with badges, and there are none designed, you’ll be creating them.
We use Sketch for all our interface design work, so that’s the format we need the UI Kit to be in. If you are on a Mac and haven’t tried it yet — you should. It is amazing tool for app design and getting a lot of traction in the industry.
This is the end of the second article, and I hope you liked it. I tried to stay as focused as possible, so if you have any further questions or inquiries, or just want to say hi, find me at vic@topcoder.com
Head over to Part 3 or back to the Series main page
