Story of creation of InMobi icon font. Why we made it, how we made it and how it is helping us more than we thought it would.
The problem
We were majorly using icons in two ways — few products used sprites and the rest used assets. The sprites come with their share of issues, the critical one being their inability to work well with higher density screens, resulting in an increase in image file sizes. The colours also complicate the matter, as there are different colours for hover, active and normal states of an icon, apart from the different colours of the same icon for different places and use cases.
Next, is the issue of size. You need to have different sizes for navigation, buttons, etc. And how can we forget the nightmare christened scalability? The mind-numbing amount of back-and-forth work required to scale an icon, is enough to put off any designer. Finally, maintaining all of these in a library is painful.
There are two sides of this problem
Designer’s side
- Must create multiple versions of the same icon.
- Bigger files, difficulty maintaining
- Optimise the file after each update, maintain the grid,
- Sprite continues to grow and get bigger, and bigger, and bigger.
Developer’s side
- Error prone when using sprite, because they use absolute background image positions
- Performance. Files get bigger and heavier as the product grows
- Run to the designer for every single little icon, because they need it in a different size/colour
With Assets, however, it’s a different story altogether. When you use assets (individual SVG files) size is not an issue, they work well on different screen densities as well. But each icon is a separate HTTP call, which affects the performance of the product. And sprites, one single HTTP call (great!).
It is basically a trade-off between HTTP calls and lighter, scale-friendly multiple files. But why does it have to be a trade-off?
We are relatively a newer team of 10+ designers working on multiple products across the organisation. It sometimes becomes difficult to maintain consistency. When we investigated icons of all the products, we found out that they were three different types of download icons used in three different products. In few places the drop-down arrows were of different sizes. We needed a central repository where all the icons would be stored and can be easily accessed by all the designers.
How might we… solve all the issues faced by everyone in the simplest way possible?
Enter Icon Font
We started fiddling with the idea of making an icon font. The benefits are many. Using icon font, you could use any font-size, apply any colour to it. With a single font file, we could bring consistency across products. Fonts are low on maintenance. Fonts (vector) are much lighter than sprites (bitmap) and it would be a single call to the server — hence better performance.
It’s easy to make any changes to the existing icons, if everyone is using the same font file and we update the font with improved icons (for readability etc) then in one shot the new icons start to reflect across all the products.
Icon fonts are not something new and it’s fairly simple to create one using any of the free online tools available. Just add your SVG icons in the tool, and download the font file.
But creating a future proof icon font is not that simple. It should be able to handle all the current & upcoming products and their icon requirements.
By the way, how do fonts work?
Simply put, each character in a font file has a specific place (called codepoint in Unicode) to sit. So that when someone presses a certain key (“Q”), the expected is shown on the screen (computer prints “Q”).
What about icons?
Unicode has a Private Use Area (PUA), which is a range of code points that, by definition, will not be assigned characters by the Unicode Consortium. PUAs are for private use, this is the range that is used by companies for their icons, etc (in total 6400 codepoints available).
Requirements in place!
We got the team together and their requirements for any icon they need now or in the future. We filled in the gaps by introducing new icons and polishing existing ones.
Categorized icons based on use cases
Apart from the icons we already had, we also reserved space in each category for the icons in the pipeline and kept some buffer as well. We had a fair idea about the number of code points we had to reserve and ensured the font will be well organised, when we introduce new icons in the near future.
In our prior experiences
Working with other icon fonts, there’s always a cheat sheet or a directory where all the icons are displayed with their names (if lucky) and classes that needs to be implemented by the developers. We are supposed to find the perfect icon, download the SVG or copy paste the icon (font character, which required the font to be installed) into our designs. And the developers copy paste the class name into their code.
We had created icon fonts in the past with the same approach. There were a couple of problems with this:
- If the class definition is not done carefully then the icons would not be mapped to the correct Unicode codepoint which would result into displaying wrong/no icon.
- Sometimes a certain icon was moved to a different Unicode code point
- The code is not very readable
- Moving in and out from the workflow for designers
To help with this we thought of using ligatures. Which is a typographic feature that allows rendering of an icon glyph simply by using its textual name. The replacement is done automatically by the web browser. This feature is supported in most modern browsers on both desktop and mobile devices.
Ligatures provide more readable code than the equivalent Unicode codepoint. The .im-icn class has definitions like the font-family and font-size. Which icon is displayed is entirely based upon the text.
When you enter “star” a ★ is displayed. Which is irrespective of which Unicode codepoint the glyph sits at. “Star” will always give ★.
Using all the icons we generated the font. It is very easy and the font (with all the icons) is one fourth of the size of a single sprite sheet of a product.
We also worked on a Sketch plugin, so that the designers don’t have to exit their workflow and can easily insert icons. The plugin adds a text layer with value (like “home”) and has InMobi Icon font applied. So, it displays the home icon. There are a bunch of cool things that the plugin does. But that is for later.
When this gets exported to Zeplin for design hand-off, developers can easily pick the content and the same icon is displayed. No more background positioning for them. If you look at how minimal effort and code has become, you would be surprised like we were.
Going forward
- We didn’t want to go crazy with every release, we would be maintaining change logs.
- Put a system in place for requesting new icons to cater to all the needs.
- The font would be in a central place on our servers and all the products would be using it.
Learnings
- No project is small.
- It could be already done by a thousand people, a thousand times, and it could still be your first time and that makes it special.
- Working together never disappoints, it’s always great!
At InMobi, we walk the extra mile. We did this exercise to make sure that the performance of the products is great and everyone building & using them feel great!
