February 24, 2015
Since joining Ushahidi in the beginning of last month, I have been working on the design and front-end code of the new version of their namesake product, the Ushahidi Platform. Version 2 of the platform was released in 2009 and has been used around the world to help people collect, organize, and visualize data. When V3 is finished, it will have six years worth of improvements, including increased functionality and a shiny responsive design.
The greatest strength of the Ushahidi platform is also what creates the most challenges for the design — its flexibility. The platform could be used to track violence in Syria, or to collect dynamic data from water wells in Afghanistan, or just to make a map of where to get a great burger. Data will be displayed as maps, graphs, lists, image collections, etc. It could be in Chinese, English, Arabic, or even multiple languages at once. And the data can be submitted and sorted in a number of ways; for example via SMS or on a slow connection in the middle of a crisis. Needless to say, there is a lot to consider.
Prior to joining Ushahidi, I did primarily client work. We would often make pattern libraries after designs had been approved and coded. We would identify patterns, pull them out of the front-end templates, and organize them into a singular reference point. But with client approval taken out of the equation, we can now use the pattern library as a reference for in-progress design work.
For the V3 design, I’m still using Photoshop to mock-up some views, at some screen sizes. It’s important for me to see that visual hierarchy is maintained when patterns are combined in layouts. But they get coded and added to the pattern library soon after they are designed. The benefits are many:
Most people are familiar with the principle of DRY (“Don’t Repeat Yourself”) programming, and the same thing should apply for design. This can get difficult when you have multiple PSDs and forget to reference every previously created document to check for reusable patterns. In the past I have avoided repetition by creating a working styles PSD, but now the pattern library has taken its place. For example, with all the button variations in one place, it’s easy to see where they can be consolidated and reused.
We’re not quite ready yet, but in the near-future, I’ll be able to say “adios amigo!” to Photoshop and create a mockup of a new page directly in the browser, made up of existing patterns dropped into an existing layout. And if a page needs a new pattern, I can design that alone, code it, and then put it in. No more painful hours wasted to update one color across multiple PSDs.
Instead of doing Quality Assurance on a full page, we can QA individual patterns. With so many considerations—accessibility, performance, extensible code, languages with different characters & reading directions, multiple devices—it’s a lot easier to test small patterns instead of full pages. We can guarantee that every pattern is bulletproof, and then create pages freely from there.
The Sass/CSS lives in its own repository that will then be referenced by the app itself. With the completed pattern library code kept completely separate, future users will be able to fork it and create their own pattern libraries. Maybe someday we’ll even have a collection of themes that can be applied to the app!
After years of doing only confidential client work, the prospect of working on an open source project is super exciting to me. So, if you’re interested, you can follow along with our progress here: Demo & Repository
June 14, 2017
March 17, 2017
September 28, 2015
February 24, 2015
December 17, 2014
November 20, 2014
October 9, 2014
July 10, 2014
May 15, 2014
May 11, 2014
March 23, 2014
January 16, 2014
September 26, 2013
July 2, 2013
May 16, 2013
December 16, 2012
August 2, 2012