we need a better UI

[vincentsarago]

[vincentsarago]

right now the default UI fetch the dataset metadata (info + stats) when openning a new dataset. This helps when we are dealing with non-byte data (rescaling the value from min/max found in the stats)

titiler/src/titiler/application/titiler/application/templates/cog_index.html

Line 754 in 9a8d579

fetch(`${metadata_endpoint}?url=${scope.url}&max_size=256`)

I think we should make metadata fetching optional (and thus making the histogram optional too)

FYI: I've implemented some of this in developmentseed/rio-viz#38

Edit: ☝️ was done in 473c37d

[dchirst]

Hey @vincentsarago. This issue is pretty old, but I'd be interested in taking it on. Do you have any other ideas on how you'd like to improve the UI, or has most of the work for this been done already?

Also, I'm not sure I fully understand how the UI here interfaces with rio-viz - should it be all one codebase (in titiler.local like this issue says), or should development be done in rio-viz instead?

[vincentsarago]

titiler and rio-viz are two different project but they share a lot (well now rio-viz depends on titiler.core 😅)

titiler.extensions's viewers are really close to the one in rio-viz and I usually experiment first in rio-viz before changing the UI in titiler. About my last comment, I already made the change in titiler's viewer (we now only fetch the info for the dataset and then the user can fetch the statistics)

That's said, the viewers are pretty old and written in pure javascript/css. I'm sure we can do better!!! I'm not a frontend designer/developper so I prefer let other do this task 😂

Note: Designing a frontend for titiler client is going to be quite complex so if we really want to do this I should also check internally if some of our designers want to help (👋 @LanesGood @ricardoduplos) but I feel you have a great knowledge of titiler already so I'm eager to ear what you have in mind 😃

[dchirst]

Perhaps this would be better suited in Discussions, rather than Issues?

I'll draft up a few possibilities that might work - there are lots of options ranging from small UI tweaks to large overhauls.

[dchirst]

So I had a think over the weekend, and here are some relatively unstructured ideas for features/approaches, roughly in order of complexity:

New Features

1. Automatic Rescale button - currently the min/max values are set to the maximum possible value for the image. We could add a button that automatically rescales the images (especially for one band).
2. Colormap Legends - feature request from here, it could be a really useful quality of life improvement for single band datasets.
3. 3D Visualizations of Terrain - I saw this in rio-viz, so I guess could be quite easy to port over?
4. Color Formula GUI - Currently color formulae can be difficult to use and understand. If we could add sliders to show the value effects in realtime, it could become more of a used feature? (however, this seems like a separate project to Titiler, and maybe shouldn't be packaged in Titiller itself

Cosmetic Changes

1. Graphical Upgrade - Currently, the frontend map uses Mapbox's Assembly. If we wanted to spend a bit of time, we could make the map feel more "modern", or could fit in more with either Material UI style (like the documentation), Titiler's style, or something else (mapping.team)? This could be relatively simple to implement, especially if there is a designer to help out my terrible taste.
2. Port to a web framework - we could add a web framework (React, Svelte, Vue) and compartmentalise the different components. This could be good for code readability in the end, but it feels kinda pointless to do on its own (i.e. not in conjunction with other tasks)

Wider Changes

1. Implementation of STAC Browser. There have been conversations on their forums about implementing Titiler inside their service, though it could also happen the other way. According to this answer they have 2 concerns - 1. The cost and complexity (fair enough), 2. Not knowing which mapping library they will use to power the maps. Given that we can reduce the difficulty to serve the maps (via just exposing the COG as a generic tiling endpoint), this could be made easier in our case.
2. GUI versions of each endpoint. This task could explode until there is a GUI equivalent for every Titiler endpoint. This could be useful, though also potentially quite a big task! It's also difficult to know how lightweight this UI should be - if we add too many capabilities this could end up turning into a behemoth

I'd love to hear your thoughts. Do you want there to be a fully graphical twin for Titiler that can do everything Titiler does? Something even more fully fledged, with data exploration (via STAC Browser)? Or just a small graphical upgrade to make the endpoint look pretty? Loads of options 😅

[dchirst]

@vincentsarago Just following up on this! This is probably a slow burn, so whenever you have time to have a think about what you'd like to see