GPlates / gplates-app

GPlates Mobile App
https://www.gplates.org
2 stars 0 forks source link

Settings menu option – page design #8

Closed yiyanw closed 2 years ago

yiyanw commented 2 years ago

After clicking the setting button (label 1), the window is shown. Changes should apply after clicking the save button (picture is only for display demo, not the final version) image

michaelchin commented 2 years ago
Screen Shot 2022-05-09 at 11 13 09 am

The gplates app will not reconstruct data on the fly. So, the time increment really depends on the pre-prepared time-dependent rasters. When users play the animation, I don't think they should be able to choose the time increment.

And I just checked Cesiumjs doc, it seems they still only have three view modes -- 3D globe, 2D orthographic projection and 2.5D columbus view. If we really need other projections, one way is to display it as a static map image, it would not be nice if users try to zoom in. The other way is to use d3js https://github.com/d3/d3-geo-projection/ or other libraries. It requires much more dev efforts. I don't think it is practical for our project.

And, I agree with Nicky that we should have a setting to control the animation speed.

nickywright commented 2 years ago

Hi @yiyanw , this looks like a good mockup to me! For actual aesthetics: will this appear in the middle of the screen, or will it be a window that animates up from the bottom of the screen (seems like settings for most of my apps on my phone do that, including living earth)? Or is the aesthetics all TBD?

For options:

matthew-merkas commented 2 years ago

Thanks for setting these issues up Yiyan! I'm going to work through a bunch of my issues today, were you keen on doing the settings page, or should I? I've got a couple of ideas, like using this mobile-friendly, zero-dependency colour picker react-colorful so users can pick from any colour in addition to sensible preset colours.

matthew-merkas commented 2 years ago

Hi @yiyanw , this looks like a good mockup to me! For actual aesthetics: will this appear in the middle of the screen, or will it be a window that animates up from the bottom of the screen (seems like settings for most of my apps on my phone do that, including living earth)? Or is the aesthetics all TBD?

I think we'll be using ion-modal for the settings component. The beauty of Ionic is that it handles different platforms and screen sizes fairly automatically, so on phones it looks like this: image

and on larger screens it looks like this: image

We'll have to be careful to design the settings page using ion-grid/flexboxes/breakpoints, etc. so it can respond to different settings modal sizes.

  • Personally would change 'Save' to 'Done'. Or could even be 'Close' or 'X'. Depends on aesthetics, but could also move this to the top left/top right

I agree with moving the button to the top right, as that seems to be what the Ionic examples do (see images above). They also use 'Close' and I agree with that (or using an 'X') since that clearly communicates the modal will be closed (and saving is implied I think). Unless we want two buttons, 'Save' and 'Close', but that seems unecessary and sloppy.

  • if we don't use 'time increment' (based on @michaelchin's comment above), maybe replace with 'animation speed'

If 'time increment' refers to the sensitivity of the age slider, then I think that's an appropriate name. But 'animation speed' would also work since the age slider has a play button 🤔

  • Is it possible to have an option for your own background colour? e.g. goes to another window with the RGB sliders or something similar.

Yep! I found a really good react library for this, see my previous comment

  • For configure graticules, perhaps an extra 'graticule properties' (can be renamed) button that goes to another window so people can set options (lat/lon delta, colour)

We could go navigate to another window with a button press, use ion-segment to navigate with tabs at the top of the window, or we could implement an accordion menu (similar to the Material React Accordion) and put the options under it on the main settings screen.

  • Additional option: Show/Hide stars. Assuming we have stars in the background sky, which I really hope we do!

I'd love to have stars and it's a good idea to have a toggle!

  • Additional options that might be useful: 'Help' and 'About' buttons, which takes you to new screens with basic info on the app/how to use (depending on how hard it is to do things) and gives some info about where the data is from and/or link to desktop gplates app.

Sounds good!

nickywright commented 2 years ago

@matthewmerkas, that's great! I didn't know if the mockup was generic since I agree that you'd want it different on phones vs tablets. Just had a little look at all the ionic components and there is lots of nice things there (and sounds like it also makes your lives easier!).

Unless we want two buttons, 'Save' and 'Close', but that seems unecessary and sloppy.

I think one button would be the way to go, it's neater.

If 'time increment' refers to the sensitivity of the age slider, then I think that's an appropriate name. But 'animation speed' would also work since the age slider has a play button 🤔

These refer to different things.

For time increment: Some of our models go from 250 Ma to 0 Ma, and so most people would probably want to see the frames in 1 Myr increments (the smallest time increment we make the files in). But for other models, e.g. 1000 Ma to 0 Ma, you might only want to see every 10 Myr or 100 Myr - otherwise you could be sitting there for ages!

@michaelchin, could every X Myr be downloaded from the server on the fly to then be played in the app? Would mean that potentially a lot less files are downloaded in some cases (especially for the billion year model).

For animation speed:
How fast it plays back, i.e, the frames per second option in the screenshot below. Perhaps as a slider where when you scroll it shows you the value in fps (similar to the second slider), and with a slow/fast image at either end of the scale (tortoise and hare? standing person vs running person?)

Another one I just thought of here: option for 'time range', so that an animation will start from Y Ma and play to Z Ma (e.g. 50 Ma to 20 Ma, instead of full 250-0). GPlates has a 'configure animation' dialogue, so basically would want most (all?) of the options there. 'Reverse animation' would be good too imo.

Screen Shot 2022-05-09 at 2 51 28 pm

If it starts getting too messy, could also add subheadings to the settings menu to group similar things, e.g. 'Display' for projection/colours/graticules/stars, 'Animation' for all the above animation settings, and 'Other' for the help/about.

using this mobile-friendly, zero-dependency colour picker react-colorful so users can pick from any colour in addition to sensible preset colours.

Yes this is exactly the kind of thing I had in mind!

jcannon-gplates commented 2 years ago

The gplates app will not reconstruct data on the fly. So, the time increment really depends on the pre-prepared time-dependent rasters.

I'm assuming this also applies to vector data (ie, not just raster data). As in the points in the vector data are reconstructed on the server and then those post-reconstructed locations sent across the network. I assume the GPlates app is basically going to be streaming pre-processed data from the server (whether that's vector or raster or any data really).

And I just checked Cesiumjs doc, it seems they still only have three view modes -- 3D globe, 2D orthographic projection and 2.5D columbus view. If we really need other projections, one way is to display it as a static map image, it would not be nice if users try to zoom in. The other way is to use d3js https://github.com/d3/d3-geo-projection/ or other libraries. It requires much more dev efforts. I don't think it is practical for our project.

I agree that you wouldn't want a static map image, and that map projections can be added in the future sometime. I'll just mention a couple of thoughts on map projections (for the future):

  1. GPlates only has a handful of map projections (four), and hasn't increased that number for a long time, so one option is to have pre-map-projected versions of your vector datasets. These could be stored on the server. However the dataset storage gets multiplied by five (one for 3D globe and four for map projections; although maybe that's four if 3D globe and Rectangular projections both use lat-lon coordinates).
  2. ...alternatively can map-project the data just before sending it. For example, the app requests a Mollweide projection of coastlines at 100Ma, so server accesses its internal present day coastlines, reconstructs them to 100Ma, map projects to Mollweide and sends the map-project points across the network. Saves on server dataset storage at the cost of a slight delay due to map projection (in addition to the reconstruction).
  3. There's the issue of dateline wrapping (where polylines/polygons intersect the dateline and have to be wrapped onto the lat-lon projection). I don't know if/how the d3js library deals with that. But in any case if the map projections were done on the server you could use the dateline wrapping in pyGPlates and send the post-dateline-wrapped points across the network (perhaps also tessellated where needed - pyGPlates has an option for that - to follow curved map boundary, eg, Mollweide; although tessellation on the server is a disadvantage in terms of network bandwidth, so something local like d3js has an advantage there).
  4. If there's too many points sent across the network you could run a simplifying pass over the un-reconstructed vector datasets as a pre-process before storing on the server. Some datasets are probably unnecessarily dense for a phone display. Unless you zoom in greatly, in which case could ultimately have different levels-of-detail (LODs) of each vector dataset. In other words, use simplified LOD when zoomed out (but send all the data on the globe, because it's all visible) and use original high detail dataset when zoomed in (but only send the data that's visible) - so in either case the amount of streamed data is limited (in a similar manner to using LOD raster tiles for raster data). The amount of vector data stored on the server is probably about 30% more (the simplified datasets are smaller than the original high resolution dataset). Of course this LOD would complicate things. So it's more of a future-looking thing if the GPlates app is going to be based around streaming pre-processed data from the server while minimizing delays due to network bandwidth.
jcannon-gplates commented 2 years ago

Everything in my previous post is in regard to 2D map projections of vector data. Map projections of raster data is a whole other story. So yeah, I think wait for a future iteration to tackle the 2D map projections - outside of what Michael mentioned (the 2D orthographic, and 2.5D columbus which is basically same as 2D orthographic but with a perspective camera view, which means both projections can run off un-projected lat-lon data).

michaelchin commented 2 years ago

could every X Myr be downloaded from the server on the fly to then be played in the app? Would mean that potentially a lot less files are downloaded in some cases (especially for the billion year model).

Yes, we can do that. But sometimes the time points might not be arithmetic sequence. See the screenshot below. We need to consider that as well. Maybe find the nearest nth time point?

Screen Shot 2022-05-09 at 3 27 01 pm

For animation speed: How fast it plays back, i.e, the frames per second option in the screenshot below. Perhaps as a slider where when you scroll it shows you the value in fps (similar to the second slider), and with a slow/fast image at either end of the scale (tortoise and hare? standing person vs running person?)

Yes, we can do that if the schedule allows us.

Another one I just thought of here: option for 'time range', so that an animation will start from Y Ma and play to Z Ma (e.g. 50 Ma to 20 Ma, instead of full 250-0).

Agree.

GPlates has a 'configure animation' dialogue, so basically would want most (all?) of the options there. 'Reverse animation' would be good too imo.

Agree.

michaelchin commented 2 years ago

If the background means the starry night, I am not sure if you can do that with Cesium. See the link below. You have to provide images for the SkyBox. I am not sure if you can change it to arbitrary colours. https://community.cesium.com/t/change-the-black-background-image-to-custom-one/15164

matthew-merkas commented 2 years ago

Maybe we could compose an image on the fly with the selected background colour and a transparent stars image?

michaelchin commented 2 years ago

Maybe we could compose an image on the fly with the selected background colour and a transparent stars image?

Yes, we can try the Image object option. https://cesium.com/learn/cesiumjs/ref-doc/SkyBox.html

michaelchin commented 2 years ago

Maybe we could compose an image on the fly with the selected background colour and a transparent stars image?

Not sure, maybe something like this?

var image = new Image();
//paint canvas with colour
image.src = canvas.toDataURL();

And then pass the Image object to SkyBox and refresh...

yiyanw commented 2 years ago

Thanks all,

I try to summarize the infomation you mentioned, please help me to check if I forget something.

  1. use ion-modal to build window
  2. change 'save' to 'Close' and move to top right
  3. change 'time increment' to 'animation speed'
  4. use react-colorful to set background color
  5. new button 'configure graticules' (probably can open a new issue for this window?)
  6. stars! (awesome, I will try)
  7. 'Help' and 'About' buttons - (probably can open a new issue for this window?)
  8. GPlates only has a handful of map projections (four), and hasn't increased that number for a long time, so one option is to have pre-map-projected versions of your vector datasets. These could be stored on the server. However the dataset storage gets multiplied by five (one for 3D globe and four for map projections; although maybe that's four if 3D globe and Rectangular projections both use lat-lon coordinates).

It seems some server-side stuff, do we need to open a issue for this?

  1. ...alternatively can map-project the data just before sending it. For example, the app requests a Mollweide projection of coastlines at 100Ma, so server accesses its internal present day coastlines, reconstructs them to 100Ma, map projects to Mollweide and sends the map-project points across the network. Saves on server dataset storage at the cost of a slight delay due to map projection (in addition to the reconstruction).

What is Mollweide projection? Is that a algorithm we need to do in front-end? If back-end handle this, what data structure it is?

  1. There's the issue of dateline wrapping (where polylines/polygons intersect the dateline and have to be wrapped onto the lat-lon projection). I don't know if/how the d3js library deals with that. But in any case if the map projections were done on the server you could use the dateline wrapping in pyGPlates and send the post-dateline-wrapped points across the network (perhaps also tessellated where needed - pyGPlates has an option for that - to follow curved map boundary, eg, Mollweide; although tessellation on the server is a disadvantage in terms of network bandwidth, so something local like d3js has an advantage there).

I search the dateline wrapping, but I dont know is that correct. image it seem a server-side problem, do we need to open a new issue for it? 11.

If there's too many points sent across the network you could run a simplifying pass over the un-reconstructed vector datasets as a pre-process before storing on the server. Some datasets are probably unnecessarily dense for a phone display. Unless you zoom in greatly, in which case could ultimately have different levels-of-detail (LODs) of each vector dataset. In other words, use simplified LOD when zoomed out (but send all the data on the globe, because it's all visible) and use original high detail dataset when zoomed in (but only send the data that's visible) - so in either case the amount of streamed data is limited (in a similar manner to using LOD raster tiles for raster data). The amount of vector data stored on the server is probably about 30% more (the simplified datasets are smaller than the original high resolution dataset). Of course this LOD would complicate things. So it's more of a future-looking thing if the GPlates app is going to be based around streaming pre-processed data from the server while minimizing delays due to network bandwidth.

Delay can be a big issue, we probably can talk about this after the first implementation.

  1. new setting 'time-range'
  2. Add all configuration Animation that Gplates has -- add in setting menu or new window?

btw, what is Ma?

Thanks for setting these issues up Yiyan! I'm going to work through a bunch of my issues today, were you keen on doing the settings page, or should I?

@matthewmerkas no worreis, I can take this issue for now. If too much works here, I will open some sub issues.

jcannon-gplates commented 2 years ago

It seems some server-side stuff, do we need to open a issue for this?

I think Michael is thinking of leaving the map projections for later, so I don't know if he wants an issue opened now or later. I suspect later because both vector data (eg, polylines/polygons) and rasters will need to be projected and rasters is not trivial. So might be a decision that needs to wait until the first iteration of the app is complete.

What is Mollweide projection? Is that a algorithm we need to do in front-end? If back-end handle this, what data structure it is?

It's one example of a 2D map projection (that's currently in GPlates on desktop) that we'd ultimately want supported in the GPlates app. I think there's still debate over whether to do it in the front end (eg, d3js) or back end.

I search the dateline wrapping, but I dont know is that correct. ... it seem a server-side problem, do we need to open a new issue for it?

That image is correct. In GPlates we export Shapefiles with dateline wrapping by default, otherwise when loading those Shapefiles into something like ArcGIS you'll see these horizontal lines (like in your image). It probably is a server-side thing because the server will reconstruct geometries using pyGPlates and then these could get dateline wrapped (also with pyGPlates - there's a description here) before sending across the network. (I'm not exactly sure how Michael currently does this.) And then the app can display those dateline wrapped geometries on the globe (or the 2D orthographic, 2.5D columbus, that Michael mentioned).

btw, what is Ma?

It's a million years. So 100 Ma means 100 million years ago. You might also occasionally see My or Myr which is more a time interval (eg, 1 Myr time increments).

michaelchin commented 2 years ago

This issue is getting too big. I will go through the comments and split this big issue into new small issues.

@yiyanw let's keep this issue open for now until the new issues have been created.

michaelchin commented 2 years ago

I have created new Issues for all the matters being brought up in this Issue. If I missed any points, please open new issues. Close this old giant issue for good.