Map interaction design work

[clash99]

Updated:

• Last version of the wireframes here.

  Wireframes for area around map interactions - locations, relationships, parties, resources.

[wonderchook]

@clash99 I'm pushing this off a sprint since I think you already have a lot on your plate for sprint 9

[wonderchook]

@clash99 we should have a brainstorming call related to this. One idea is also what other tools we would offer the users such as calculating the area of a location.

[clash99]

@wonderchook Sounds good - admittedly I need to do a little research beforehand on the tools part. Does early next week work?

[wonderchook]

perfect

[clash99]

Link to map interaction flows: https://drive.google.com/a/cadasta.org/file/d/0BzpiEtMtHC3rSnZMWUVjckNHMHM/view?usp=sharing

Ready for review but I'm still making a few changes (mainly text). I would still like to add an updated project index and project overview page.

[wonderchook]

Few comments:

1. What do you think of icons instead of drop downs for selecting the entities that are viewed? I'm wondering if that might be more obvious for users.
2. I like the interactions between the maps and the panel. I think it would be good to also think through the cartography for those interactions. What do things look like highlights on the map as far as theme and color.

[clash99]

Updated flows dated 01/04/2017: https://drive.google.com/a/cadasta.org/file/d/0BzpiEtMtHC3rSnZMWUVjckNHMHM/view?usp=sharing

@wonderchook -

1) I played with icons but I think an additional map/location marker might be confusing in that area. Is there another icon you think could represent "locations"?

2) We should provide a few palette options and then based on the number of location types, it will be a variation of the opacity somewhere within the selected color range. This also makes me think about the upcoming feature to add an additional highlight based upon a questionnaire response. I think we will need to add these selections in the project settings.

3) I reworked the entity dropdown and views to only include Locations and Parties. I think this simplification makes a lot of sense.

Take a look and let me know if you have other feedback. I still need to review with David and I know Oliver mentioned he had some feedback in the works too.

[oliverroick]

Here are few comments and questions from my end:

• What's the purpose of having both list and map views other than expanding the right-hand panel? It seems to convey the same information. It adds more functionality and complexity to the interface but and doesn't add much value.

Location lists

• I prefer the alternate proposal as it's much cleaner with the sliding panel option. The separation of the location list into location type is not necessary because we have the filter dropdown to filter for specific location types. Implementing a grouped list that is quite complicated because you would have to sort all locations and then group them, which is not possible to do it a template, so we'd have to add more code to the view itself.
• The dropdown to switch between location and party lists could be confusing to users. It changes the context without making that visually explicit. When I look at the map with a list of locations on the side, there is a clear connection between the map and the list. When the user switches to the parties list, this connection is lost. Wouldn't it be better just to have to filter for relationship types and party names with the location list. That way users could combine searches like "Show me all locations where Chief Sonieky has a Leasehold." The list of parties can be accessed from the link in the left-hand menu.
• For listing the relationship types and party names with a location, I can see more performance issues coming up. All this information needs to be queried from the database and joined to the model entity, which will be very slow. We can keep track of the number of relationships assigned to a location and display that in the list of locations. This might not be that big of an issue if we have mostly 1:1:1-relationships between Location-Relationship-Party; if we have a significant amount of many-to-many relationships this will get tricky. So it might be worth looking at the data we already have and the data we expect to come in soon to work out how to design this area.
• I find the second "Add" button a bit confusing. It's in proximity to the "Add location" button on top, so I don't see the need for it.
• Hovering locations: How will this work when you hover of a location on the map, and the location is not visible on the list, and vice versa when you hover of a location in the list, and it's not visible on the map. What happens when you hover over a location in the list, and the location is inside a cluster on the map?
• Filtering: Will filtering the list also affect what is displayed on the map?

Location Detail

• Relationships tab: I would not show all the resources in this view. The purpose of this view should be to answer the question "What parties have a relationship with this location?" When we show the resources for each location, the list gets very long, and users have to scroll a lot to get this overview.

Party Detail

• Is the list of locations for a party linked to the map? I.e.; does the map only show locations for that particular party?

[clash99]

@oliverroick -

1) The list view vs map view provides the user the option to view the data related to a map or not basically. My thinking is since all our data is based on a location, it should all be able to be viewed relative to a map. But you are correct that the location list view and party list view are basically just indexes.

2) Sound good. I think the latest version with more filtering options addresses this concern.

3) I'm still thinking about what changes I can make on this one. Notice I did eliminate the party tab on the left. What is lacking now is the ability to see party information relative to a map. This allows a user to do that but you could also do it through filtering on the locations view. Perhaps we eliminate the party option from the top dropdown and have the user rely on filtering? I have to question why we have a parties tab on the left but not a locations tab - or maybe we have both. I like to take away (if possible) vs add so again, still thinking here.

4) Agree - we should see what is the average number of relationships a location has. When I spoke to David last it was most typically 1:1. I have tons of questions like this come up as I design so I would love to have access to this information. The relationships view/grouping has been eliminated and should be able to be covered with the filtering.

5) Since we don't allow adding a relationship outside of the context of a location, we need to keep that one. Same with adding resources to location, relationships and resources. Other that those I can look at removing those.

6) If a hovered location is not on the visible list, nothing on the list would be highlighted. I don't think we can do anything with the clusters either. This is most beneficial when the user has zoomed in on a specific area and is trying to find a specific location which may be layered below another one.

7) Yes, the map array of locations and the list array should always be in sync in my opinion. I tried to reinforce the total number of locations available with the badge by the Location title and then the "showing # of #" is the subset (if not all records). Do you think we need more explicit "this location has a total of ## locations" messaging? Also I was thinking as a user zoomed or moved the map, the list could be limited to just that area with the "Limit list to viewable map" checkbox. I think this makes the map a whole lot more usable, especially in the cases of large projects with many locations.

8) If not here, then where else would you look for resources connected to a relationship? I think it makes sense here but perhaps we could hide them and provide a link to them? Or perhaps drill up/down on the relationship itself.

9) Yes, a user should be able to filter for a party and see all locations on the map for that party. One idea to maintain the context of their location to the others is to just keep an outline of the other locations and the selected party colored but I'm assuming this would hit performance. In the doc I just show the filtered locations.

Let me know if you have any ideas about my responses above. I still need to review with a few more people and then I'll make another round of revisions. Thanks!

[seav]

Just some comments on some of the points raised here:

Oliver: What's the purpose of having both list and map views other than expanding the right-hand panel?

This redundant view is one possible solution to #496.

Chandra: I have to question why we have a parties tab on the left but not a locations tab

Isn't the map tab the locations tab?

Chandra: Since we don't allow adding a relationship outside of the context of a location [...]

Currently. In the future we will be including spatial relationships, and more importantly, party relationships. I would suggest considering this in mind when we make changes related to relationships in the UI.

[seav]

Given the map vs. list views, I wonder if we are emphasizing the map too much especially with the alternate proposal of a sliding right panel for the map view. How about if we approach things in reverse: we emphasize lists and tables for displaying project data and then slide in a map or show a map inset to provide geographical context as needed?

[clash99]

Thanks @seav - Interesting idea about de-emphasizing the map although I'm guessing that will not be the way most of our users will want to view the data. The platform currently has a disconnect between the raw data (especially parties) and the map. This approach of showing both simultaneously and contextually is going to allow users a better way to both get an overview as well as hone in on a target. Good points you raised though so I'm collecting all the feedback and going to have a discussion with @dpalomino when he returns. I'm sure he will have more to add as well. Stay tuned!

[oliverroick]

@clash99 —

Thanks for your clarifications. I don't have answers to many of the questions I raised. Just wanted to put them out there.

In general, I would always link the map and the list in the right-hand panel. When you zoom in on the map, you see only locations listed that are also on the map or parties who also have a relationship to any location visible on the map. Do I understand this correctly? If yes, this is much more clear to me. Otherwise, if you separate this it will get very confusing I think.

I think much of the confusion about the bigger picture (the map and it's relation to the side panel, and the list views, and how we design the filters) is because we don't have a good idea about the problems we want to solve. We all have an idea in our heads how it's supposed to work. But do we have a narrative for what our users want to achieve? Like a list of questions, users want to answer when they look at the map? I think if we have these questions, it will be much easier to figure out how we need to design that area and what use cases we need to give more priority. At the moment we're on the way to building a very complex user interface because we're trying to do a bit of everything.

If not here, then where else would you look for resources connected to a relationship? I think it makes sense here but perhaps we could hide them and provide a link to them? Or maybe drill up/down on the relationship itself.

I would only display resources in the detail view of a relationship but not within a list of relationships.

@seav —

I think we are having different conceptions of what "list view" means. I mean the table view that covers the whole page, not the list in the panel next to the map. The list in the right-hand panel solves #496; that's right. But not the list view that I was talking about.

[wonderchook]

@clash99 in addition to reviewing with @dpalomino I think we should think about getting some user feedback prior to building. Or at least more outside the dev team. @oliverroick's point about not being sure about what problem we are trying to solve is valid. I'm not all that sure about how people might want to use the data myself. I can picture use cases for both list and map view, but think we could get a bit more clarity by soliciting some further feedback.

[clash99]

I think we should consider breaking this into smaller parts for development (and design). This list of locations offers a solution to #496, which could be implemented separate from some of the other map interaction recommendations.

If we had more user interaction questions, we should consider doing some third party testing since its an easy way to get insight to user behavior. I'm not sure what the more controversial issues are so perhaps a meeting would be the best way to discuss.

[clash99]

I'm trying to document what user problems are being addressed on specific wireframes from my perspective before our meeting.

Map View with Location Index

User problems:

• Can't select locations when layered below others (#496)
• Can't view locations in any other view but map, which is hard to search

Additional benefits:

• Allows user to see number of location within project
• Allows user to view list of locations - including search, filtering, sorting
• Allows user to limit list of locations to viewable map area for targeted zooming
• List hover with map hover helps with context

---

Map View with Location Detail - Relationships Tab

User problems:

• Can't view relationship details within context of other location details, currently have to leave tab page

---

Map View with Party Index

User problems:

• Can't see locations belonging to a party in the context of a map

Additional benefits:

• Allows user to see number of locations belonging to each party
• Allows user to view relationship to location

---

Map View with Party Detail

User problems:

• Can't view party details within context of map and relative to other location details
• Currently when on party details page, there is no way to return to relationship details other than using browser back button which isn't optimal

---

List View with Locations

User problems:

• Can't access location information except one-by-one on map

---

List View with Party Detail

User problems:

• Can't see locations belonging to a party

Additional benefits:

• Allows user to view relationship to locations and other location details

[nastynoel]

@clash99 - my two cents.

1. I like the sliding panel option

2. How well will hover functionality work with mobile devices, if it all? Could it impact or frustrate users trying to pan/zoom on those devices?

3. I would not de-emphasize the map aspect. Based on past experience before Cadasta, users do like to see their linked to the map, i.e. just viewing lists was less compelling for them. We used to sell software on the back of simply having that clear linkage, i.e. having the map and associated entity/attribute data on the screen.

4. yes - I believe users would like to see when parties do not have locations associated with them

5. is "extent" or "project extent" an alternative to "overview"?......it depends on what and how much info is being shown in that window. Having an overview tab in the list views might confuse users if we also stick with Overview on the LH side of the screen

6. I do like the list views

7. I'm with Kate on getting some external feedback on this. Marena as Namati indicated she'd be happy to provide feedback if we'd like.

[nastynoel]

@fhpichel - do you have any inputs here?

[SteadyCadence]

If the goal of these pages is to sort and filter data collected, then I think it makes sense to downplay the map size. Location boundaries are necessary to view but they are one element of data. The relationships and statuses of a parcel are likely more useful for sorting/filtering than the actual coordinates of the parcel.

Alternatively, if the goal is to allow partners to print and use the dashboard to narrow in on the precise boundaries then it would be worth keeping the size of the map... but I think something like that would be more useful as another feature (PDF/print functionality).