Quicker Start: The Feature Formerly Known as "One Neighborhood per Project" #246
Conversation
But I'd like to re-use this component and its easier to reason about without the "global" store variable.
I had set out to work on "one neighbourhood per project", with the idea being that, after creating a project, users should immediately be dumped into the "create neighbourhood" screen. The problem is, we have two ways to create neighbourhoods: by picking auto gen boundaries and drawing them by hand. This change combines the 2 UI modes. Originally it was in pursuit of the "one neighbourhood per project", but this change streamlines the UI for everyone I think. Now the user doesn't have to pick in advance (which could be confusing if you don't already know the difference). Plus, now you can see prioritization metrics for your "hand drawn" neighbourhoods, which was missing before.
dabreegster
force-pushed
the
mkirk/quicker-start
branch
from
d4d2178 to
4462ddc
Compare
There was a problem hiding this comment.
This is awesome! I love how this fulfills the spirit of the original request to make one project = one neighbourhood, but still lets more advanced users set up multiple boundaries if they want. I anticipate still a little user confusion about picking both a project and neighbourhood name, but we could maybe just prefill the first neighbourhood name with "LTN" or the project name.
It's very cool to see the metrics update as you draw a manual boundary!
In large areas with a slower "generating boundaries" loading step, I could see a user being frustrated if they intended to draw manually, but I think the current tradeoff is worth it, and we could always get more complex later by doing this in the background and letting them start the manual drawing immediately.
There are 3 potential issues I found, but none need to block merging. I'll work on some of them next or file issues.
-
I like the clarity of the popup with controls on waypoints, but if you move the cursor quickly and overlap the popup element, the waypoint dragging gets messed up. Also, the extra node markers cover up the popup:
If there aren't some z-ordering tricks we can get working, then we could also try offsetting the popup from the cursor or some other ideas. -
I managed to get partly stuck by clicking pregenerated boundaries and merging them, then switching to manual drawing, then switching back to areas, then back to manual. Manual mode didn't have a "Finish / start over" button. I'll repro more carefully next and/or just fix if it's quick.
-
I managed to trip the debug assert in
make_polygon_validabout multipolygon results. I'll get a good repro in Dundee and file an issue. I think because we now call this method much more frequently while dragging around, it was easier to hit. I think in the short-term, changing this to return a Result instead of panic and handling it cleanly on the frontend should help.
| } | ||
|
|
||
| onMount(async () => { | ||
| // Make sure the loading indicator has rendered before we generate boundaries. |
There was a problem hiding this comment.
This seems to resolve #144. When I was trying this out, the loading screen seemed to be flaky when it would show up and sometimes even when it would disappear. But every time trying this PR so far, it's working fine.
There was a problem hiding this comment.
Yeah, I'm pretty mystified why the simpler didn't work, but 🤷
await tick();
let boundary = $backend.generateBoundaries()
| <p>Click the map to add three points. Then adjust the points or add more.</p> | ||
| <div style="display: flex; gap: 16px;"> | ||
| <label> | ||
| <!-- REVIEW: Currently, after three points, route-snapper will try to draw an area, |
There was a problem hiding this comment.
Hmm... this seems intuitive. When you click an existing waypoint to toggle it, would it change this setting for the next case?
There was a problem hiding this comment.
That's the idea. I'm not entirely sure it's the right solution.
The issue I have with the current approach is basically that showing/hiding controls is a bit jolting ("Hey where'd it go? I want to switch.")
How it is now, it stays visible but becomes disabled. I think I understand why, but still think it's a bit inexplicable to the user. Also though, maybe it's not that big of a problem in practice.
|
Thanks for the feedback on the route-snapper popover. I agree it's clumsy.
Typically, this indicates the backend was not able to create a valid geometry from the input. The easiest way to do this is to create a "bowtie" which causes the boundary generation to create a multipolygon neighbourhood (which we dont allow): 
But that should only change as a result of changing the waypoints. I don't know how toggling between "draw" and "choose" could trigger that. If you figure that out, LMK! |
To your point, I'll at least see if I can add something more explicit like "The geometry you've drawn is invalid" or something and maybe keep the "Finish (disabled)" / "Start Over" buttons visible. |
Great idea! filed #249 |
This is based on #244, so merge that first.
The main commit is Combine choose/draw neighbourhood UI
I had set out to work on "one neighbourhood per project", with the idea being that, after creating a project, users should immediately be dumped into the "create neighbourhood" screen.
The initial complication was that we have two ways to create neighbourhoods: by picking auto generated boundaries and drawing them by hand. Which got me thinking... would it be better to combine them?
This change combines the 2 UI modes. Originally it was in pursuit of the "one neighbourhood per project", but this change streamlines the UI for everyone I think.
Now the user doesn't have to pick in advance whether they want to pick predefined-blocks or draw something from scratch. (which could be confusing if you don't already know the difference).
As a bonus, now you can see prioritization metrics for your "hand drawn" neighbourhoods, which was missing before.
Screenshots
new create project flow drops you directly to prioritization after project creation.
faster-start.mov.mp4
After project creation you're dumped directly to the prioritization/create boundary screen:
You can now switch to "draw" right from that neighborhood create screen. These "choose area"/"draw area" buttons could probably use some further design work:
Once you've drawn a polygon, you'll see the aggregated boundary stats table, and can proceed to "Create" just like with autogenerated boundary selection:
"start over" button - previously there was a red X to clear the selections, which no one seemed to understand. So I wanted to try something different:
popover detail - I replaced the help button with some more contextual instructions. TBH they kind of get in the way sometimes, but I think it's better over all:
Back on the "pick neighborhood" screen - you can still add more neighbourhoods if you want to (note there's one "Add" button rather than two Pick/Draw buttons.
FIXES #153 (or at least obviates it I think. WDYT?)
As an aside, I think this UI begs for the ability to "tweak" your boundaries, even if you have done the "choose area". But I think that would necessitate prioritizing #201.