Who's On First

After gaining a better understanding of the website and the project itself, I developed four goals to help guide the redesign.

• provide an overview of the project which explains the entirety of the thought put into the project, while not being so overwhelming as to scare potential users away
• provide the tools to immediately utilize WOF
• provide the tools for deeper exploration into WOF
• get individuals excited about the project

I also began to think about the users of the website. Are they all similar? Are they coming to the project for different reasons? What kind of backgrounds and experiences do they bring with them?

I concluded that the majority of these users will come from three different groups.

• Users actively working on a project that could benefit from WOF. They are not stumbling upon the project, they have come to the website with a specific purpose. They have either used WOF before or have background knowledge about WOF. They have some technical knowledge.
• Users not actively working on a project that could benefit from using WOF. These users are interested in WOF, but don't have an immediate need for it. They are interested in learning about the project, but are not looking for in-depth knowledge. They may or may not have technical knowledge.
• Users who stumble upon WOF. They come to the project without preconceptions. They may never have a use for WOF, but may spend some time on the page if they find it interesting.

How can we most effectively allow for understanding of WOF? What are the most effective ways of visualizing WOF? Can understanding of WOF be acquired through some sort of interaction? How can users directly interact with the data? How can we replicate a user's interaction with WOF outside the website? How can we visualize that this project is a continuous work in progress? How can content create a dialog that captures the attention of a user, while showing the power of the project?

With these questions and others in mind, I searched for answers moving from lower fidelity to higher fidelity prototypes.

Throughout the first half of the summer, I had been using the Mapzen style guide so that anything I was designing or building would align with the Mapzen visual style and other Mapzen product pages. Halfway through the summer, the decision was made to completely redesign the website.

One area, I focused on was building out a clear hierarchy. To do this, I wireframed possible options.

After a number of iterations and receiving feedback from my team, I created a home page with cards ordered by importance and differentiated by size and color.

Within subpages, users are able to see where in the overall hierarchy they are located by looking at the top and left navigation.

With this new architecture, users can clearly and efficiently move through the site. From the home screen, every page is at most 2 clicks away (except for mobile, where every page is at most 3 clicks away from the home screen). From any subpage screen, every page is at most 3 clicks away.

One of the first things I focused on was how users directly interact with WOF data. Do we create some sort of interactive component where individuals can immediately interact and get a sense of the data made available by WOF? If so, what powers that component? One feature that WOF provides is an API.

While some of the API queries require background knowledge, a number of them could be understood by a first-time user, like the getByLatLon query.

Knowing that I could use the API, I explored different ways the API methods could be visualized.

Could we create a card with tabs that would display specific fields based on the tab selected?

Results would appear below the tabs and fields.

Or we could create a map that would allow for interaction? A user could select a specific point or draw a box on the map and results based on that point or rectangle would appear.

I had some concerns with this approach. Would the interaction interfere with the main navigation of the page? Should the first element seen rely on user interaction? I ultimately came to the conclusion that this first element should not rely on a user's interaction.

Since I didn't want the first element to rely on user interaction, I created further iterations.

I knew that I wanted the element to immediately capture the user's attention and show some of the capabilities of WOF. With that in mind, I created the mockup below where users are able to see WOF places depicted by red circles.

I showed it to my team and they suggested including the API command powering the visualization.

When initially building this out, I'd planned to detect a user's location and run a WOF API query based on that location. However, this can lead to potential problems with GeoIP lookups (not correctly locating an individual).

I made the decision to simplify this, this element is now built to randomly select one of five locations and run a WOF API query based on that location.

After building out the initial component, I still wanted to create an element that would allow for a deeper and more direct interaction with WOF. Consulting with my team about the most important API queries, we settled on: getByLatLon (returns WOF records intersecting a latitude and longitude), getNearby (returns WOF records near a point), and getIntersects (returns WOF records intersecting a bounding box).

Using my earlier mockups as inspiration, I thought about ways a user could run these queries through an interface. This inspired another set of mockups.

This brought up a new question. Could you combine the getByLatLong function with the getNearby function? The getByLatLong function is essentially equivalent to the getNearby function, without the radius argument.

This convinced me to combine the getByLatLong and getNearby queries into one type of interaction, while the getIntersects query would be represented by a different interaction. They would be represented by the icons in the top left of the mockup below.

The point (dot) icon repersents the getByLatLong and getNearby interaction. When active, users are able to select a point on the map and/or specify a radius, latitude, and longitude in a window on the bottom left.

The box icon represents the getIntersects interaction. When active, users are able to draw a box on the map or specify minimum and maximum latitudes and longitudes in a window on the bottom left.

The results of those queries are seen in the right hand column, followed by the API query run to acquire those results.

I found it would be difficult for users to utilize the point and box functionality to find specific places and their descendants, so I added a search. Users could search for a place and then view the descendants of those places, but the walkthrough would have to be broken up.

I also created a walkthrough to help users understand the functionality of the component.

An additional way to create a dialog that could capture the attention of a user, while showing the depth of the project, would be through stats. WOF provides an ample amount of stats that could be relevant to a wide variety of users. At the same time, stats must be limited. You do not want to be consistently processing statistics in the background.

With the stats, I also wanted to avoid the parts of WOF that require background knowledge. Users shouldn't have to discern what things mean, and the stats should be relatively simple.

I took some time to understand how to organize and visualize the stats. Should they go from higher level place types (countries, regions, etc...) to lower level place types (venues, etc...)? Should the stats be context specific? How much more computation would that require? Is that computation worth the time and load?

The website also needed to provide users with tools to immediately get started with WOF. This includes the different options a user could take to use WOF. For example, if a user knows the specific path and ID for a particular place, the website should provide that user with an example URL they could use to retrieve data. Or if the user wants to use the WOF API, that user should see a number of example queries and links to additional documentation. A link to the Github repo where all WOF data lives would also work, users could then download their own version of the data if they so desire. You can find a mockup below to see just how this could work.

I ended up creating two new "get started" pages, one for retrieving venues and another for retrieving neighborhoods. Both tutorials utilize the WOF API.

When I arrived, part of WOF lived solely on GitHub. One example of this was source information. In order to make the WOF website more usable, I made dedicated pages for some of the information available on GitHub.

These additional pages included the Explore tool and Get Started page.

The website was also made responsive, with a focus on the navigation menus.

I built the website so that it was easily scalable and manageable when I left Mapzen at the end of the summer.

I did this by building what I call a Makefile CMS. A Makefile CMS includes a Makefile that utilizes terminal commands to create pages in seconds.

The CMS then pulls content from GitHub, basic HTML pages, already established components (navbars, headers, footers, etc...) and manipulates that content to build finished pages.

Updates can be easily made in the Makefile, both in terms of the content and the components that make up the website. Once the Makefile is updated, users have the ability to run commands in the Terminal and see the updates immediately.

I also built a styleguide for the team to reference. The styleguide includes all built and established components.

Before my internship, I hoped that I could design and build something that would live on when I left Mapzen at the end of the summer. I believe that I was able to do that by building a platform that can grow with WOF. That gives its user the tools to effectively make use of WOF and its creators the tools to effectively communicate WOF to the world.