Written by: Lindsay Jacks
For the past three months, I’ve been working with Cadasta and Stamen on the atlas creation pages of the Field Papers map annotation tool. The end result is now live on the Field Papers website. We took the four step “wizard” process for creating an atlas, combined it all into a single-page, and placed priority on the map by making it full-screen. We wanted to simplify the process as much as possible, and make sure that the resulting composition page was intuitive and easy to use.
We reexamined the original Field Papers four step atlas creation process.
The old Field Papers user interface (UI) consisted of four steps: search, select, describe, and layout. The division of the ideas made it hard to navigate through the atlas creation process. The map viewport used to interact with the grid was also a pain point: it was too small to be effective. Several issues were filed that all stemmed from the users feeling confined by how small the box was. In addition to this, the grid interaction model added a level of complexity that could be improved. Many of these issues could have been fixed independently, but overhauling the UI would set Field Papers up for the longer success. Since I was interning through Outreachy, I had three months of dedicated time to spend on Field Papers, so going through the pains of overhauling it made a lot of sense. We knew we wanted to combine all of the steps into one page, that the viewport needed to have priority, and that we needed to keep things simple.
I started by researching what others in the mapping community are doing.
Starting out, I was tasked with scoping out the “competition” to see how others in the mapping community were handling full-screen map applications. When 90% of your screen is taken up by the same thing, I assumed there wasn’t going to be much variety. I was happily proven wrong by the number of creative solutions to organizing and hiding menu information. For the most part, the interactions they needed to facilitate were more complicated than mine, so I had to resist the urge to get fancy. A lot of slick solutions would only needlessly complicating things, especially when simplicity was my ultimate the goal.
After putting together several wireframes, I narrowed it down to three menu designs.
At this point I had several ideas for how to organize all of Field Paper’s information, but I wanted to make sure I wasn’t getting too attached to any one idea. I sat down to do a 10 minute sketch session, spending no more than 30 seconds on each idea. Quickly moving through layouts and menu options forced me to get creative. A lot of the ideas were just a sloppy collection of squares, but they gave me ideas that then fed the eight wireframes that I developed into fully-fleshed out ideas. With these eight wireframes, I was able to not only look at ideas that I liked, but also ideas that I didn’t like. That way I could fully grasp why I didn’t like them. At the end of this process, I threw out all of the sketches and five of the wireframes to settle on three ideas: one simple, one slick, and one somewhere in-between. Once I showed them to everyone at Cadasta and Stamen we went with the one that was simple (you should be seeing a theme at the point).
I created a stand alone prototype to experiment with different interaction models.
Now I had a single idea to work from which I was able to transform into a prototype. Rather than try and parse through Field Papers’ entire codebase, I created a stand alone experiment that consisted only of Leaflet.js, CSS, HTML, and just the JavaScript necessary for the visual aspects of the grid. Separating these ideas from the backend allowed me the freedom to play with the interaction model without worry about how it was all going to fit together in the end.
The original Field Paper’s grid interaction model required the user to interact with the grid and map separately, rather than simultaneously.
The grid interaction was an aspect of this redesign that was difficult to illustrate in the wireframes. This prototype gave me a chance to really hone in on the issues with it, rather than trying to think about the conceptually. In the previous iteration of Field Papers, the grid was “stuck” to the map. This meant that to position the grid, you had to move the map, move the grid, then repeat until the grid was in the right location. Adding rows and columns made the grid expand beyond the size of the viewport, taking the grid adjustment buttons with it so that the user was left chasing them across the screen. We wanted to simplify this interaction as much as possible.
I experimented with the grid reacting to the map vs. the map reacting to the grid, but with the ultimate goal of simplicity.
We decided it made the most sense for the grid to behave like you were looking through a camera lense. As you pan across the map, the grid goes with you while remaining in the center of the screen. It didn’t make sense to have this giant map only to have a tiny grid, so we wanted to figure out the best way for the grid to stay as large as possible at all times. The one thing we weren’t sure of is whether the grid should react to the map, or the map should react to the grid. For example, if the user adds rows and columns to increase the size of the grid, should the grid adjusts its size to fit in the viewport, or should the map zoom out so that the grid squares are allowed to stay the same size (pictured above)? I ended up with three versions of this prototype with different solutions to this problem for people to play around with.
Once we had a working prototype, we were able to how it worked in the full Field Papers ecosystem.
Once I had a prototype that worked independently, it was time to fit it back into the Field Papers system. Since Field Papers is built on Rails, I pulled out the main body of the HTML and rewrote the menu form into Ruby so the backend was being fed the same information it was receiving previously. The CSS required a solid rewrite so that it could absorb the Skeleton styling used by the rest of the website (and so it didn’t look like someone slapped it together in 30 minutes…). With a little bit of work to make sure my event listeners weren’t getting foiled by Rails’ TurboLinks, and to make sure that the new JavaScript was playing nicely with the old, we had a fully functional compose page.
We decided to try different menu styles, including an accordion style menu, to more effectively divide up the content.
With the initial surgery complete, we were able to take another look at the menu design in the harsh light of reality. The design from the initial wireframe ended up being rather lengthy once all of the information was included. On any screen size other than huge, you had to scroll to be able to see all of it. I tweaked it to make everything smaller, but it still seemed rather cluttered. After discussing it, we decided to try a few other layout options, including an accordion style menu, to more effectively divide up the content.
We conducted a community survey to get feedback on the changes that we were making.
At this point it made sense to put all of these options to a vote. We took the three grid interaction experiments I created, as well as the two menu options (full-length and accordion) and put them up on a demo site for people to play with. This gave us a chance to make sure that the decisions we were making weren’t based on assumptions, and we wanted to give people a chance to see the changes we were making. We got a limited number of responses, but the majority of the responses were positive and insightful.
The final design.
Based on the responses to the survey, and the final thoughts of Stamen and Cadasta, I was able to put the finishing touches on the redesign. Because simplicity was the goal, we went with the full-length menu. In order to prevent it from seeming cluttered, and in response to some of the feedback we got, we moved the row and column buttons off of the menu and onto the map. We also removed the large search bar in favor of a smaller one powered by mapzen (which I think is quite slick). With the final grid interaction, the grid is completely independent of the map, and resizes itself to fit within the viewport. It also has the added option of being able to “pin” the grid to the map, so that you can interact with it in a way that feels familiar to the old Field Papers UI. The end result was something simple that gives the user more room to breathe, which was ultimately what we were hoping for. You can see the final result for yourself, which is now live on fieldpapers.org.
Photography Provided by OpenStreetMap Indonesia
