MapBrief™

A cornerstone of the Lean Startup movement is the idea of a Minimally Viable Product (MVP) whereby a company, instead of spending months (and months) building the perfect product, quickly builds something that has just enough features to be useful, but makes no claims to completeness or finished polish. Instead, getting real feedback early from users interacting with an actual product, one can apply iterative improvements based on user behaviors rather than a bunch of people in a conference room white-boarding theoretical features that would be theoretically cool.

Minimally Viable Products are a bulwark against counterproductive perfectionism and the tendency to keep adding marginally useful features.  As we’ve seen in the Why Map Portals Don’t Work series, web map interfaces tend to be bloated with all manner of content and functionality that distract and hinder the user from carrying out their primary intention of information retrieval.

Below, then, I’ve created a Minimally Viable Property Lookup Service using a half million property records from the great City of Philadelphia. The goal is to create something that a) doesn’t require “Help”  b) enables the user to find information fast c) gives users links to more information and d) requires a minimal investment in tech infrastructure.

Cutting-edge info aesthetics? Um, no.

Without further ado…

Award-winning? No.

Soon-to-be profiled in a glossy industry magazine? Probably not.

Could you find an address quickly?  Probably.

Ingredients

Here’s a rundown of the minimalist ingredients powering the app.

• SQLite:  the 500K parcels are stored in a SQLite database.  SQLite has a number of important qualities including 1) ubiquitous, especially on cheap web hosting environments such as GoDaddy and InmotionHosting;  2) portable–it’s a single file so you can create and test locally and easily upload to the web; 3) it’s reasonably fast.
• Address Lookup:  this is the most important part of the app. You can’t have the users guessing about address formats, street types, etc.–let them just start typing and give them very specific feedback as to what options actually reside in your database.  They’ll figure it out.  Our address lookup is rather forgiving insofar as it takes fragments of house numbers and street names–again powered by a basic PHP script searching the address field in SQLite and piping the results into a javascript autocomplete widget. Even though our app is on generic shared web hosting, we’re getting sub-half-second response times: fast feedback is essential for engaging someone used to the Google auto-complete experience.  The indispensable Tobin Bradley has a screencast here on setting up a similar search.
• “More on this Block…”:  Simple list of hyperlinks that gives the user the quickly check out the tax assessments of your neighbors. Because we’re naturally nosy.
• Attribute Table: You’ll spend the most time agonizing over the background color of your zebra banding.
• Disclaimer:  We’re GIS people–we always include a disclaimer.
• Google Static Map: perfectly in the spirit of a Minimally Viable Product, our map is courtesy of Google’s Static Maps API, just plug in our parcel’s centroid into a request URL and, voila, a map.  Google gives you 25,000 free maps per day (thanks!).

From a techie’s point of view, the above is rather mundane.  But the shocking truth that I’ll expand on in the next post is that the above satisfies the majority of your users. They happily go off to some other corner of the web, content that the information retrieval experience wasn’t too bad.  But for those who need more, we can give them the following without much exertion on our part–

• Bing Maps KML overlay + print capability:  since most commodity hosting has the bare-bones SQLite 2 installed, we can’t provide much in the way of SpatiaLite magic.  But we can store the KML geometry as text in a SQLite 2 text field (not optimal, but still viable).  And through the magic of URL rewrites, we can make each record in our database “look like” it has its own unique KML file to the outside world.  We simply append an address’ unique KML url to Bing Maps and, presto, we have free interactive mapping that even shows our custom logo (no API key necessary). And did you see we mentioned printing?  FACT:  more tears have been shed by geo-developers creating web-map printing capability than actual web maps printed.  We just offload that headache to the fine folks at Bing and call it done.
• KML Download:  as long as we have a unique KML “file” for each feature, let the user download it.  And be sure to mention “Google Earth”:  more people know what Google Earth is than know what a KML file is.

Maintainable Over Time?

Any tech manager knows the value of an application isn’t necessarily in its splashy roll-out but in its maintainability over time.  In our set-up, we can use free command-line tools from the aforementioned SpatiaLite project to automatically load a shapefile into SQLite plus execute SQL commands to clean the data up, create a text field with KML geometry, etc.  We have one client who does their updates using DOS commands in a batch file–how awesomely mid-1990s is that?  But it works, and it’s free: everybody’s happy.

Cost Certainty

A significant impediment to adoption of usage-based cloud solutions is that their costs, while low, are variable.  And nothing exasperates managers and accounting departments than unknown month-to-month costs.  I’ve had clients point-blank tell me they can’t move forward with any solution that involved them wrangling with their Accounting Department once a month.  With commodity hosting, you can one-time purchase storage and bandwidth for 1-3 years at one time.  Again, it’s this kind of conundrum that reminds one that the biggest obstacles to progress aren’t necessarily technological but rather the policies and procedures created in a simpler time.

Website Politics

For government entities that don’t run their own website in-house but rather a 3rd party provider with an inflexible content-management-system (CMS), the options are limited for rolling out spatial content.  A minimalist approach that can be easily be embedded via an <IFRAME> (again, a 1990s web thing) is not optimal but given limited options and resources, it works.

The World We Live In

It’s never been easier to distribute large quantities of data–including spatial data–inexpensively to the public.  But a mistake we see too often made is the assumption that anything relating to geographic information automatically requires something called “GIS”.  Users want to find the one needle in the haystack that is relevant to them–fast.  But they certainly don’t want the haystack dumped on their head, which is what too many traditional map portal experiences feel like.

In the next post we’ll be rounding up a fresh set of web map analytics that reinforce the power of simple, fast specificity.

—Brian Timoney