For this project with Cloudant I was tasked with designing an experience to query a user's database using geospatial data, much like Yelp does when you search using the viewable map area.
Problem: Users had no way of querying and displaying their database using a map.
Goal: Design an interface that would allow users to easily query their database using different shapes.
Role: I was the sole Designer on this project working with a Front-End Developer and working under the leadership of a Project Manager.
Below are the steps needed to running a geospatial query on your database. In general, there are two main steps for submitting a query: first you have to create the geo index, and then you move into the map and query using shapes. After this, you are presented with the results.
While the flow seems straightforward, there were multiple ideas for how this could be incorporated into the existing user experience. Also, while some novice users want to query their map by drawing shapes on it, others prefer writing the query using code, so I had to ensure both functions were easily available. As such, I developed three distinct versions. I went over each one with both my team lead as well as our developers to ensure feasibility, and then tested each with users to see which was most natural to them.
Version 1 - New UI:
This version uses a new tabbing paradigm in the main content creation window to allow the user to switch seamlessly between the query code and editing the geospatial index. This version lowers the barrier to entry by putting users straight into the map even if they haven't yet set up the geo index. It allows users to see both the JSON query code and the map view side-by-side, providing a fluid transition between the two contexts. Furthermore, the "Edit Geo Index" tab provided easy access to the query settings. Finally, the View Filter in the top bar allows users to easily switch between map view, JSON view, and table view.
Version 2 - Search UI:
This version borrows from our already used Search UI, already known to our users. For this version, the middle column–the secondary menu–stays consistent with the rest of the product, and allows users an easy way to move to something else within their database. When users select Geospatial, they are first required to create an index. Once they have, they are presented with the map interface with a text box overlay–should they choose to code the query. This version has tabs in the main content area, allowing users access to the view filter as well as the settings page. This is helpful in that all of the settings for the Geospatial query are nested in the same place.
Version 3 - Map Reduce UI:
This version follows our Map Reduce UI. It's a hybrid of the first two versions. The "Edit Geo Index" page is in the middle column similar to Version 1, but everything else is in the main content area on the right. Similar to Version 2, to query the database using code, there is the text box overlay on the map. Also similar, the filter view tabs are along the top of the main content area, but instead of being nested in a dropdown they are displayed as separate tabs.
The Final (Shipped) Version
User feedback indicated Version 2 was the best due to its familiarity and ease of manipulation.
For the final version, here are a couple design decisions that were made:
- The middle panel stays consistent across the product, and the bulk of the feature-set is in the main content area. Users preferred this in order to easily switch to other geo indexes or any other areas of the database.
- Editing the Geospatial Index is accessed by clicking a gear icon next to that specific one, since users always hovered around that area when asked to edit their Index.
- Tabs in the main interface were removed and elements redistributed throughout.
- The View Filter is placed in the header bar but moved left since it was unbalanced when centered with the rest of the actions on the right. Also "Table" was removed as an option–something users didn't like–and "Docs" was renamed to "JSON" (not to be confused with querying using JSON).
- The ability to query by code was removed, since this feature tested poorly. Users said that if they wanted to use code to run a query, they would rather do it in other areas of the product that don't require them to open up geospatial and are more full-featured.
What I learned:
- There definitely isn't one correct way to design this flow.
- The intricacies of querying using geo spatial indexes is complex.
- Watching a user move around through a prototype will help inform placement of elements.
Things I would change:
- The visual design can be fine tuned (buttons on map made a little larger).
- Incorporate geo spatial indexing more thoroughly throughout the product.