Ideas for lengthy dropdown

[kelsey-taylor]

Describe the issue

If there are a lot of style options in the dropdown (i.e. >20), selecting a stylesheet to view can be a bit overwhelming and hard to read. I've been thinking about how we might improve this UI going forward for projects that have many versions of different stylesheets.

This may sound like an unusually high number of styles, but you would be surprised how quickly a project with several versions and/or variations of a style can add up 📈

Propose a solution

I've been thinking about how we might use multiple dropdowns to only show relevant styles at one time. Chatted with @aparlato about this a bit earlier and here's where this is headed now:

break out current sections into multiple dropdowns - first you select the type, then the style name, then the branch or version as needed

Curious to get thoughts from folks on this or other ideas to make this easier to use! 💭

[aparlato]

Thanks for opening this @kelsey-taylor !

This initial mock feels like a good direction here to resolve this issue.

The primary thing to resolve I think is how we would handle the preset dropdown with the separate dropdown for versions.

This would require that we adhere to a strict convention for our presets in the local.js config file so that we can appropriately parse versions from the rest of the style name.

Unfortunately, the current spec doesn't provide us a good way to handle this as id can be anything unique, url doesn't necessarily follow a consistent pattern, and version isn't a specified key (and could follow different patterns for different clients if it were):

{
    id: 'mapbox-streets',
    name: 'Mapbox Streets',
    type: 'mapbox-gl',
    url: 'mapbox://styles/mapbox/streets-v11',
  }

One idea would be to include a new config key similar to branchPatterns called presetPatterns that could follow a similar format with tokens:

{
     name: 'Cool style',
     pattern: 'https://website.com/dist/{version}/dir-a/path/to/my-style.json',
     versions: ['v2.1.4', 'v2.1.5'],
     type: 'mapbox-gl'
 }

Although, something to consider with an approach like this is that, in at least in one implementation in a client repo, we pull all the preset styles automatically from S3 as part of a Github Action. The above pattern solution would require that that implementation be scrapped in favor of manual updates.

[kelsey-taylor]

thanks @aparlato! i'm not opposed to the presetPatterns idea but def hear what you're saying about the existing s3 implementation. obviously it's preferable to avoid as much manual work as possible...i'm wondering if there are other possible options we aren't thinking of? i'm sure @ebrelsford will have some ideas when he gets back

[ebrelsford]

I like this direction!

My only feedback on the mocks is that in my head I would specify the style first, then pick version/branch/local.

Agreed that it would require some refactoring of the config files and this might be hard to get right for all cases. I could be convinced that in addition to what you're proposing, @aparlato, that we allow for more explicit entries (set URLs rather than patterns).

[aparlato]

obviously it's preferable to avoid as much manual work as possible

Totally. I think @ebrelsford makes a good point about explicit URLs and that could help solve this problem wrt that automated script. If we use explicit URLs, we could alter that script more easily to set this up for us I believe with some specific code to handle the conventions in that repo.

I could be convinced that in addition to what you're proposing, @aparlato, that we allow for more explicit entries (set URLs rather than patterns).

@ebrelsford how do you feel about using the same format for explicit urls and just making the pattern only the token in those cases? This would allow some flexibility. We could rename the versions key to something more general like values or something?

{
     name: 'Cool style',
     pattern: '{value}',
     values: ['https://website.com/dist/v1/my-style.json', 'https://website.com/dist/v2/my-style.json'],
     type: 'mapbox-gl'
 }