The idea came from my friend Nick Hould, who worked in a web agency as an analytics analyst before joining The Starter League. Like many agencies, they were reinventing the wheel. The agency was hand coding analytics dashboards for their clients, starting from scratch every time. So, were working on a tool that we’re currently calling Dashboardly (TBD) to stop the wheel from being reinvented.
We completed the first version this weekends 24-hour Builders Hackathon. Not bad for a group of people that have only been developers for six weeks?
Designing for Data Clarity
Last week Jason Fried talked about about clarity, and design communication. After mulling over his thoughts we decided that it would be best to compete on clarity. We are not going to be able to analyze more numbers than our competitors, but we can make data more presentable.
Clarity is about getting the important numbers across to our users. That is why Dashboardly maximizes white-space and follows flat design.
Problems We Faced
We had a dire issue two hours before we had to present. Dashboardly was making 50 separate requests to Google Analytics every time the dashboard page was loaded. With people constantly making requests, we quickly hit our limits. Nick added dummy data to the application, so we could save our requests for the presentation. We are in the process of refactoring our API calls.
The Javascript charts we planned on using broke in production. Charts are an important part of Dashboardly, and going forward getting them right will be a priority.
Understanding OAuth, which handles user authentication, is a major hurdle for rookie Rails developers. We had issues saving the user login data to a database, as a result we had to hard code the information into the application. This will be fixed in the next version.
Next Steps
Were considering several things for the next version. Custom dates and dashboard headers will are next on my to-do list.
What do you think?
