Our mission, democratizing map making, is a lofty one that requires building for the next generation of point-and-click map makers. Sam and I knew most maps are shared on the web, but a lot of the time they are – to borrow a phrase from design tools – flattened. We wanted to make sure our maps consisted of composable pieces that you can not just see, but tinker with and “right-click” into. Not only that, we also wanted to make sure you could indeed create these maps on the web, without having to download or install anything. And if we did everything right, we knew sharing would be as simple as just copying and pasting a URL into an email or a tweet. The web, we knew, had all these primitives built in.
Over its existence, the web has evolved from a document sharing platform with a rigid request-response cycle to supporting full-fledged desktop class tools, ushering in new user expectations and experiences. For example, we now rightfully want things to save without having to CMD-S (phew!), we want our changes to be instantly reflected in our colleague's browsers, and we want to easily share our work via links–not double digit MB pdf files. This "multiplayer" environment is highly complex to build, but when done right, changes the way users work and what users are capable of producing, and is fundamental to building any application that meets users expectations for the decades to come.
Achieving our simple mission required a complex solution. How could we build a brand new type of interaction, a spatial UI, while also making it “multiplayer”? Set aside the technical challenges, how would it even work for the users? For example, what did it look like when you had multiple people on a map, and one of them zoomed out to continent level and another person looking at street level data? What does it mean to make an annotation, say, on the city level view that has to be visible to others who might be looking at another part of the world at the time?
We knew we didn’t have the answers but we knew how we would get them (or try to): by iterating as fast and as many times as possible. Our respect for the challenge of the unknown has driven the technological decisions and investments we’ve made to date. We knew there was no other way to build a collaborative, complex product without making it easy to build and test the product itself.
You’ll in fact find this idea permeate through all our blog posts already. Julius Tarng, for example, thrives on prototyping and works tirelessly to make experimenting with new ideas as seamless and fun as possible. And when we ran into one of our first speed bumps with complicated state changes being lost across page refreshes, Jason Axelson picked up the mantle and implemented Hot Reloading across our Phoenix application. This was uncharted territory for everyone involved, and we are also happy to have contributed our learnings to the community.