The How and Why: Building The New Crowdmap.com

We’ve been discussing the new Crowdmap.com recently, and our own Brandon Rosage has shared some great videos of the new UX we’re feverishly working on. We thought it would be a good time to discuss how we’re building the new Crowdmap.com, and why we’ve taken the approach we have. Let’s start at the (sort of) beginning...

Our Team

We have great design chops on this team, and a wealth of engineering experience, but the two skill sets aren’t contained in one Captain Planet-esque super being. As with most application development teams, we have to coordinate the work of our designers and engineers to produce the final product. From experience, we knew that integrating the different layers of an application would consume a hefty amount of our development time, especially when we don’t work in the same time zone. In an effort to make our lives easier, we’ve spent a lot of time, especially at the beginning of our work on the new Crowdmap.com, discussing what our development philosophy should be and how we can make things easier on all of us. This is how we arrived at our current, though ever evolving, development philosophy.

Our Development Philosophy

We have three goals that drive our development philosophy, somewhat influenced by the makeup of our team: 1) improve the handoff and coordination between UX design and engineering, 2) have a small, manageable codebase to simplify maintenance and growth, 3) most importantly, create great user experiences. We want to be fast, agile and effective as a product team, and let the Crowdmap API do almost all of the heavy lifting.

Our Approach

To that end, we start building new features by discussing user stories with the entire team, and generate UX mockups before integrating anything into the application. We prioritize reliance on code & UX patterns to boost team wide development velocity. We’re strong believers in DRY, even if we’re not perfect practitioners. We build reusable components and libraries wherever we can. We decouple logic and presentation as much as possible. This allows UX designers to implement novel interactions without having to ever touch server side code. It has also led to us abstracting out most of the underlying logic into simple patterns that can be implemented over and over again with little customization. When it's needed, server side support for a new feature can be rolled out with little effort or delay. For many of the same reasons, we made the decision to go with a widely adopted, actively supported front-end framework. We wanted to be able to “stand on the shoulders of giants,” so to speak. That framework ended up being Ember. We settled on Ember largely because, of all the frameworks we evaluated, it felt most likely to allow design and engineering to meet in the middle. We’re taking advantage of Ember’s use of Handlebar templates, ember-data and it’s RESTAdapter to build a full featured web app that lives comfortably on top of our RESTful API. It’s taken a lot of work from both sides to get to this point, but we’re very close to having a designer produce a template, and it to  an engineer to wire it up, and have everything just work. It may not sound like much, but it’s a pretty significant accomplishment for our team. Of course, all of this is made relatively easy because almost all of the logic is encapsulated in the Crowdmap API. It handles object relationships, authentication, access and more, allowing us to focus solely on the last mile, i.e. providing the best user experience we can. The Crowdmap API is the engine that powers Crowdmap.com and the way this engine is built we can rapidly and efficiently add new features that serve the user -- and others have caught on. We have begun to offer other enterprises access to this engine, to quickly build out their own custom Crowdmap. More details on that coming soon...