Allow three or more map panes to be compared

[almccon]

It was bound to happen eventually, but it happened for me pretty quick... I'm in a situation where it would be really handy to have three panes.

The swipe tool wouldn't work in this case, instead it would have to be three linked side-by-side views.

Could we implement this easily? And what are the UI implications? Would we want the option to add/remove that third pane, or to potentially add n panes? Could this work if we had a toggle between the "swipe" mode and "side-by-side" mode? But if you're in three-pane side-by-side view and then you want to switch to swipe mode, would it just drop one? Or prevent you from switching to swipe....? hmm.

[aparlato]

I would guess if we're hitting situations where it would be helpful to compare 3 styles, it isn't a stretch to think we'd want to compare 4 (or more) at some point.

Could this work if we had a toggle between the "swipe" mode and "side-by-side" mode? But if you're in three-pane side-by-side view and then you want to switch to swipe mode, would it just drop one?

I would think, rather than drop a view, we might think of the compare mode (allowing and adding more views) as the primary app state. Then we could have an option to select 2 of those views for compare with a swiper (in a modal).

Here's an extremely rudimentary sketch to illustrate my thought (not to fully mock up exactly how this would work):

No views selected (white text box under map lets you use url to point to style): One view selected (option to edit style json): Two views selected (gives option to compare): (modal with compare tool):

Could we implement this easily?

With this proposal, I don't believe we'd be able to implement easily from the existing code. This would be a bigger more holistic refactor.

@peterqliu what are your thoughts? Is there an easier lift or do you think a request like this warrants thinking through bigger changes?

[peterqliu]

@almccon in thinking through the tech lift, I've got a straw man for you to 👍 / 👎 :

When we're asking for a "three pane", we really just need a quick way to toggle between pairwise comparisons. We might want look at differences between 3+ styles, but can only ever see two at a time: A to B, B to C, A to C.

If this is true then the challenge gets significantly easier (just a matter of setting up the matchup easily, rather than all at once).

[aparlato]

I think one other factor to consider is how much change this tool is likely to go through in the near future. @peterqliu has done a great job getting something good and useful together quickly. Are we at the point that we know more of our requirements and this is coalescing into something that should be more robust?

Depending on that and the turnaround time needed, we might consider taking this opportunity to build this from components we can reconfigure as needed. For example:

• A higher order component for the basic layout (easily changed)
• A lower order component we reuse to display a map (known functionality that won't change)
• A modal to display a swipe compare (known functionality that won't change)
• A utility to fetch a map from a url (known functionality that won't change)

When we're asking for a "three pane", we really just need a quick way to toggle between pairwise comparisons. We might want look at differences between 3+ styles, but can only ever see two at a time: A to B, B to C, A to C.

If time to something useful is still our primary metric though, I think @peterqliu 's solution is clever. That said, do we already know there's a use case for seeing all variants at the same time or is that speculation?

[almccon]

Regarding the use cases for 3+ panes, I did a very cursory search through screenshots on my FB laptop (the one project where I've had a 3+ pane viewer available) to see how frequently I used three panes. In this case it's useful to remember that you get two panes by default when you load, so it does take a tiny bit of motivation to go and add a third. I also found some cases where the QA teams had their workflow set up to automatically start with 3+ panes.

As a very rough guess, I'd say that 95% of my screenshots were two panes, but 5% of the time I had 3 or more.

Use cases for 3+ panes:

• Porting a style to a new data source, such as taking a stylesheet that uses HERE data tiles and making it work with MMI data tiles, or taking an OSM-based style and making it work with TomTom tiles. This is what I'd like to do currently: Left pane has the existing client stylesheet, middle pane would have my local/branch working stylesheet (where I've taken the existing stylesheet but have it loading the new tileset, so not all the features are displaying yet), and an unrelated stylesheet driven by the new tileset, so I can see what features ought to be rendering.
• When moving style logic (min/max zoom, tag filtering etc) from the tile schema to the stylesheet or vice versa. When tile versions and style versions might be released out of sync from each other, I needed to have the left pane with the old style version and the old tiles, the middle pane with the new stylesheet and old tiles (or vice versa) and the right pane with the new tiles and new style. The goal here would be to catch any unexpected behavior that might happen if users had mismatched versions... although this is rare and can usually be prevented by other means.
• Using the extra panes for additional "ground truthing" by including a satellite view. Often I'd have the style I'm working on in the left pane, maybe OSM tiles in the middle pane, and a satellite layer in the right pane. In this case, the extra panes are more for convenience and less of a requirement to really do the task. I noticed that the QA teams for FB often had their panes set up like this when filing bugs.
• Using 3+ panes to see a bunch of variants at the same time. I could imagine that for some small features we might be adding to all variants, it would be handy to have all of them loaded on screen at the same time. This would also be handy for QA.

This is a pretty narrow set of use cases and they're all really just a "nice to have" situation. I'm kind of talking myself out of the request that 3+ panes is really that useful. But maybe this list is helpful for others' thinking?

[peterqliu]

This is helpful. After thinking a bit about the polypane use case, I think we should keep the current swipe tool for two styles, and a separate tool for >2 styles. Rationale:

• UX: the current swiping tool works really well for two styles, and I think an expansion to support more styles would make that 95% use case a bit less easy. The multi-step, "pick two and compare" would work, but feels like we're force-fitting it to a UI it's not designed for.
• backward compatibility: links using left and right url's only make sense when there are two styles, and of course don't work with more.

New compare tool for >2 panes

I think the solution to comparing many styles, is actually showing just one pane at a time, and making it easy to switch between them.

• Compare tool will have a hash of all the map styles to compare, in a comma-delimited list (up to 9)
• For each style, tool will instantiate a full-paged map, stacking atop all the others. All maps will synchronize their movements
• To view a map, user presses the number corresponding to its position in the list (1-9). Users can flicker back and forth between styles, indefinitely, to see minute differences in position, color, opacity, angle, etc. Even though they can see only one style at a time, I think the optometrist-style, "is lens A or B sharper?" swapping is actually more effective, for doing small-scale comparisons

Downsides

• showing one style at a time means it's hard to take static screenshots to illustrate a difference (would have to take two screenshots)
• one map object per style could mean spawning a ton of maps, causing overages

[aparlato]

@peterqliu I understand your assessment, but as a counterpoint: I feel like more tools might actually be more maintenance and, in use, lead to fatigue for cartographers when the use cases are so similar (compare 2 vs compare 3+).

Based on conversations, it sounds to me like this tool is something we want to start moving to become customer agnostic (and longstanding), and if so is worth considering building out for expanded use cases rather than start a new tool.

Based on that, my take would be to either create a solution here or hold off until we have a larger use case.

I think the solution to comparing many styles, is actually showing just one pane at a time, and making it easy to switch between them.

With this solution, is this drastically different than just switching the style in one of the panes as-is? It seems like this is already possible, even if not optimized, and I'm reading the request as 3+ maps side by side. @almccon what do you think?

[peterqliu]

Based on conversations, it sounds to me like this tool is something we want to start moving to become customer agnostic

I share this dream, but after working on project-specific tooling and fulfilling their cartographic feature requests, the dream feels remote. Without getting specific here, a majority of those features are unique to some file system setup, or a niche map inspection workflow, or a live-reload system based on some file structure, or some other project-specific need.

While we do want to pull out generalizable patterns into this tool, potentially open-sourced for other people on other projects, it is unlikely to be satisfactory for many of Stamen's, without heavy customization (i.e. turning this into something completely different). cc/ @ebrelsford might have thoughts on this too

I feel like more tools might actually be more maintenance

from the above train of thought, I suspect this tool will stay generic and pretty rudimentary, which suggests minimal changes in the future. But even when it IS necessary, I think the separation actually reduces maintenance load: a tool that toggles between two things is likely to have more complexity, than two self-contained pages that each does something simple.

To use an extreme case, we can make a monster tool that combines all the mapbox gl examples into one, but I bet that would be harder to debug and maintain than keeping them as loose HTMLs.

[aparlato]

I see, thanks for laying out this context @peterqliu, this is helpful for me to understand the scope and constraints!

But even when it IS necessary, I think the separation actually reduces maintenance load: a tool that toggles between two things is likely to have more complexity, than two self-contained pages that each does something simple.

I think I misread "make another tool" to include starting a new repo initially, so it sounds like you're imagining 2 HTML files that both live here. In my mind, even switching between the two independent HTML files via an <a> link effectively makes it a single tool, but now I think I'm on the same page here (even if we choose not to link them). Based on what you've written above, this sounds like it makes sense!

[peterqliu]

Built what I had described in https://github.com/stamen/mapbox-gl-compare/issues/5#issuecomment-1025413523 over on the [multi] branch here (put it on a block if you'd like to play with it).

Per chat with @almccon, he is still refining the problem that this tool is meant to solve, so we can back burner this until more clarity materializes.

[ebrelsford]

I'm happy to hold off on talking about this until Alan chimes in with some more clarity about the use case. Where possible, I would like to make a tool that uses components and is relatively generic, then fork that tool for specific client uses. I agree that we shouldn't try to force every feature into this tool, but on the face of it I think having more than two panes is a reasonable ask.

[ebrelsford]

Now that #9 is merged I'm interested in us working on this. My proposal:

• [ ] Add an add pane button here:
• [ ] Add a close button here:
• [ ] If there are more than two panes, disable swipe mode as it is no longer useful. Instead, we could allow phone mode (up to ~4 panes?) and otherwise force the user into a side-by-side (fixed? need a better name for it...) mode where each map is centered and zoomed to the same area.
• [ ] Allow the user to just view one pane if they want to--why not?
• [ ] As panes are added, arrange them in a grid on the screen

[RossThorn]

In line with these changes, even when looking at just two styles, I also would find it useful to have both map styles have identical side-by-side views rather than swipe. So what would be the default for >2 views, but also just for two views as well!

Sometimes a change is just to see if something is present in one or the other and always having to slide just adds a little more mouse mileage to the use than needed with a mirrored view.