A recent, yet-to-be-announced client project had me designing a mobile app interface that dealt a lot with showing locations and events that are happening at certain locations (how is that for vague? sorry).
While I utilized the brand’s colors to represent certain sections of the app I wanted the app to have tons of colors in order to portray a sense of fun throughout the app. But how could I incorporate pinks and yellows and bright greens without the overall brand disappearing?
After toying with a few design ideas I had an idea to create a unique color for every address in the world. This would result in two benefits; first, each location was then branded as a color, and second, every user would see that location as the same color. If I were a user of the app here in the US and I flew to Spain and looked at a location for an event there, I would see the same exact colors representing that address as the person that lived in Spain and created that event.
Since I wasn’t to be the developer of the mobile application I wanted to avoid the possible pushback this idea might receive from that team. I didn’t want to add burden to the other people on the project by showing a design mockup and a set of requirements and then walking away. I wanted it to have zero overhead for the developers.
One of the solutions I discarded was generating a random color each time an event location was added to the service and then store the color for that address in a database. While this solution is relatively simple to implement it was no good. It adds more work for the developers and they have to maintain the datastore indefinitely. Several other ideas with the same caveats came to mind and I quickly tossed them into the bin.
Once I eliminated all of the ways I didn’t want to solve this problem – the solution came pretty quickly.
Since every address is already unique, I just needed to find a way to represent an address that could be turned into a color. In other words, I wanted the address itself to represent a unique color. And I wanted to do it in realtime as the application’s UI loaded.
This solution allows for just over 16.5 million colors. Far more than this app will likely require during its lifespan.
Here is a demo of the process and if you view the source you can see the code at work. It is fairly simple to follow.
Oh, there was an issue that I ran into with this solution that was fun to solve. If the background color that was generated was too dark the text became hard to read. So digging around I found a way to determine the luminosity of the background color and thus change the text to something a bit lighter in those instances. That too is shown in the demo.
I was then able to repurpose this demo code and give production-ready code to the developer that is going to ship in the app. When that ships I’ll write more about it.