InfoPogo: Scratching the surface
- January, 28, 2009
- 7 Comments
A few weeks ago I was contracted by the guys at Infopogo.com to give their prototype some design love. If you haven’t seen it yet, InfoPogo is a research tool that searches census, demographic, housing, crime, and a whole bunch of other public data (don’t let me trivialize it, it’s much more than that) by US regions.
Looking for the median family income for Beverly Hills? It was $102,611 in 1999. Pretty neat huh?
The InfoPogo guys have big plans for the application, including making improvements on the other planes of User Experience, however, any improvements on the surface would go along way.
The InfoPogo team has spent countless hours in making their components and controls as re-usable as possible, so it was important not to create a bunch of work for them for the sake of design. In order to make it easy for them to implement, much of my HTML/CSS started from the markup that they already had on the site.
The crumbs are built using the
last-child CSS selector so that the last
li is automatically formatted appropriately.
From the developer’s point of view, it’s a simple unordered list. (Oh, and I know what you are thinking – Internet Explorer doesn’t like
last-child. Have you seen ie7.js?)
Doug Bowman’s sliding doors method for making tabbed navigation seems like a hundred years old in Internet years, but it is still one of the most flexible and bulletproof methods for creating tabbed navigation from an unordered list.
The flexibility is important because as InfoPogo matures, the names of these tabs might change and there may be more tabs to come. This is one example that requires a bit of extra markup for the developers, but in the end they are still just rendering an unordered list.
The summary components don’t currently exist on the site, but will soon. Each summary unit is marked up as a definition list and is automatically styled (again, using
last-child) and floated into place. The summary’s parent container doesn’t care how many individual summary “units” are inside, it will handle them appropriately.
The default summary unit will handle fairly large numbers, but can be extended if the needs arises to accommodate very large numbers.
Most of the data is presented in a tabular fashion so it was important to design some flexible
table markup. This meant accounting for the baseline table styles, such as
th‘s, but also extending the basic styles for additional presentation and functionality. For example, adding the class
alt-row to the
table tag added alternating rows.
A lightweight script looks for tables with this class and adds the needed markup client-side with no additional work from the development team.
Pulling it Together
Here is an example (although, not a real page) of all of the newly skinned components working together:
It will be really exciting to watch InfoPogo come together and mature over the next few months, so keep your eye out.
Aaron Martin said:
You’re one of those guys that I hate and call a douche, bBut only because when I see stuff you do I always think “damn, I wish i had done that.”
This is a solid working of what could be considered boring data. It looks as if you’re showcasing it in a way that’s easy to find, view, and process internally. I’m a big fan, Travzi.
Aaron Martin said:
P.S. – I love you.
Jared Christensen said:
Drool. That is all.
Travis Isaacs said:
Thanks for the love guys.
David Sutoyo said:
Sweet, the summaries are reminiscent of Google Analytics. I like. Looking forward to its launch.
Chris J. Davis said:
Very nice Travzi. You amaze as always. This could be an interesting resource for another sekret project we are working on…
splendid. u throw many lessons for free in visual and information design.thank u