Responsive Layout of Interface

[rothnic]

Hi, first of all, thanks a bunch for working on this. This is already so much better than the Sunray app and probably saved me from selling this mower. Also, I have python (web dev and data analysis with pandas), javascript (react), flutter, and web/app design experience. So, while I'll be submitting some issues in github, I also expect to pick up some of them to work on as I have time.

So, I'm using this application on a laptop, hooked up to a large monitor much of the time. The layout seems rather restricted and I'm curious if that is something that is limited by the map functionality, or just needs some basic css updates.

Here is what I see at the moment:

I noticed this is using bootstrap and with one quick change here:

From col-lg-12 col-sm-6 col-12 to col-lg-12 col-sm-6 col-12, it at least takes up the full width. I wasn't able to quickly identify small changes to get it to be more "app-like" where the actions stick to the bottom and the main area expands to take up the space between the navbar and actions, but that is essentially what we probably should work towards.

[EinEinfach]

Yes, I know, but my plan is keep the map on the left side. The right place will be used for some plots in the future (Voltage, Speed, driven distance...) For the moment it doesn't look good on large screens. You can change the size of the map in /src/pages/state.py In row 47 change lg and sm to 12

[marvin78]

The appearance is not the problem. You cannot really work with it. It's not very practical. Plots are not essential and can be shown on another page or maybe overlay.

[rothnic]

The appearance is not the problem. You cannot really work with it. It's not very practical. Plots are not essential and can be shown on another page or maybe overlay.

Yeah, to me it is just implementing responsive design. When building an app these days, you typically want to configure each element to flex, no matter the screen size. Whether there are plots on the right or not shouldn't impact that the layout should be responsive. So, without the plots, the app should expand for the available space, then as you add other elements, it should respond and fit all those components based on the size of the screen.

I think it should be a relatively simple fix, but need to find some time to play around with it.

[rothnic]

Ugh, so after working with this some, I've found that this is a bit more complicated than using react + a css library on its own. Dash adds a bunch of deeply nested html elements, then dash bootstrap components implements an older and incomplete version of bootstrap, so it takes some time to work through.

The plotly graph is a bit of a black box to deal with, so it is hard to style it with css. I have it set to autosize with my responsive layout updates, but I could only get it to grow and not shrink. However, I finally just added a javascript callback on window resize to manually clear out the height and then the plot automatically gets the correct height after that. So, here are some screenshots of the new app-like layout with some tweaks to the components and layout of the buttons and state.

This is a first pass to just get the basic structure responsive and I think the rest should come easier. I need to add some padding, but overall the basic layout is responding. Again, the overall idea here isn't to change the layout to only be what you see, but to create a layout that expands to use the available space effectively, based on the components that are actively being shown. Adding a column or anything else should adjust naturally to fit the additional content.

Summary of my changes:

• Fixed the graph so that it doesn't throw errors when there is no path data available
• Set graph to use the autosize mode
• Changed the state cards at the top to wrap them in a CardGroup
• Updated the main state page to
  • fill the entire area (100vh - height of the navbar)
  • use flexbox in a column layout for the main area with the map set to use flex-grow
• Added script to listen to resize and clear out the current height of the map (which then gets reset instantly to correct value)

[rothnic]

Updated to keep the same card group styling without wrapping at the small size:

[rothnic]

I now have an example column placeholder added that I'll wire up so it is easy to hook into toggling it on/off. Next, I'll probably go ahead and push this into a branch in my forked project, then start working on the other pages.

[rothnic]

@EinEinfach I've got a couple questions for you:

1) Mapping Layout: I've been looking at the mapping layout and I'm curious what you'd link about putting the choose perimeter component and upload sunray component into modals behind buttons.

• So, we'd basically use a consistent layout between the state page and mapping page, where we have a couple primary buttons at the bottom. I think this might make for a more usable layout on mobile where the map component isn't so constrained.
• Then, I think we could on large screen sizes show those in the column area I mocked up in the previous update. 2) State Module Changes: I noticed that you removed some details from the state component that is on the state page. However, a the info modal component seems like a lot of the same, but more complete information. I was thinking we could make the state component contain all the details, but would be collapsible. So, in the default state, it would look similar to what we have now for the state component, but by clicking on it, it would expand to show all the details. This would enable us to see all the details in addition to the map at the same time, or collapse it for the basic information and to maximize the area for the map

Here is the current state of the styling I've done:

[rothnic]

Here is a rough mockup of what I'm describing for the Mapping page. The layout would be the same as the state page, except primary buttons would open modals to interact with the corresponding functionality. I'll show screenshots of the layout, then what you see when clicking the button on the left vs button on the right:

[rothnic]

I also have this setup where, if we wanted, we could still show the select components in the right column when there is enough space. I found some bootstrap classes to automatically hide/show the buttons/components at breakpoints, so we can show the buttons to open the modals as small screen widths, then show them in the right column for larger screen widths.

[rothnic]

Quick update.... I have been focusing on trying to remove my javascript-based approaches to helping the map respond correctly. I was able to find the right combination of styles applied to the highly-nested page structure to get this working with pure CSS.

The benefit is that I'm seeing smooth resizing whether you are on a desktop device changing window size, or on mobile and you click the "hamburger" menu where it expands the top nav to show the additional options. It keeps the key buttons on the screen at all times and maximizes the space available to the map.

I think this approach I've taken for the mapping and state pages can easily be applied to any other screen where we have the map and some controls as well. So, I'm thinking about packaging up what I have as a pull request in the next day or so, once I have a chance to take a pass through and clean things up a bit.

I think once this basic framework is adopted, there are some more things we can easily add on (like the expanding state component I mentioned above).

[disaster123]

Great ideas!! I like them.

[rothnic]

@EinEinfach see the draft pull request above. Looks like there are some conflicts that I'll need to resolve, so let me know when would be a good time to do that. I put a fresh set of screenshots showing the various layouts in the pull request for reference.

[EinEinfach]

@EinEinfach I've got a couple questions for you:

1. **Mapping Layout**: I've been looking at the mapping layout and I'm curious what you'd link about putting the choose perimeter component and upload sunray component into modals behind buttons.

   * So, we'd basically use a consistent layout between the state page and mapping page, where we have a couple primary buttons at the bottom. I think this might make for a more usable layout on mobile where the map component isn't so constrained.
   * Then, I think we could on large screen sizes show those in the column area I mocked up in the previous update.

2. **State Module Changes**: I noticed that you removed some details from the state component that is on the state page. However, a the info modal component seems like a lot of the same, but more complete information. I was thinking we could make the state component contain all the details, but would be collapsible. So, in the default state, it would look similar to what we have now for the state component, but by clicking on it, it would expand to show all the details. This would enable us to see all the details in addition to the map at the same time, or collapse it for the basic information and to maximize the area for the map

Here is the current state of the styling I've done:

Yes, that is the idea behind the information modal. It will be fill up with more information, not sure what exactly is needed. Feel free to make suggestions.

The styles look awesome!

[EinEinfach]

Here is a rough mockup of what I'm describing for the Mapping page. The layout would be the same as the state page, except primary buttons would open modals to interact with the corresponding functionality. I'll show screenshots of the layout, then what you see when clicking the button on the left vs button on the right:

I like it!

[EinEinfach]

Looks like there are some conflicts that I'll need to resolve, so let me know when would be a good time to do that. I put a fresh set of screenshots showing the various layouts in the pull request for reference.

Yes, I have done a lot of changes on the mapping page. I added new feature with moveable points. I'll check your pull request, and try to resolve the conflicts

[rothnic]

@EinEinfach Check my new PR #45. I got rid of the old one since it was so far out of date (not sure how that happened). This isn't going to be absolutely perfect, but should provide a good starting point.

Potential future work is better handling having so many buttons in the mapping layout, then abstracting out the layout that is pretty much manually duplicated across the 3 pages. Otherwise, I think this is a good checkpoint to move forward from.