Open dabreegster opened 2 months ago
"3. Importing a route from the coherent network (I'll just manually sketch some inputs matching what you have now)" is now started. Keeping it ultra simple for now, just click on something from the CN, then the user could edit it -- including splitting / moving the route.
Thanks; a good start.
I think the UI should be fundamentally non-modal. This is a workspace so there shouldn't be a continual need to mark something as done. What is on the screen should be regarded as present/'saved'. Modal interfaces for this kind of task are always a bit painful because you continually have to press the same buttons over and over again just to get rid of a panel.
In other words, it should be less like a series of forms that have to be marked with a submit button, and more like a standard GIS window, or indeed like the OSM iD editor, where you draw things on and set attributes, without ever having to press a button to save/change state, but at some later point you can save it.
The current UI concept requires constant pressing of 'Finish' and 'Save'. But these are essentially pointless, and they give rise to lack of clarity in the state: after drawing, a line is present on the screen which appears to be correct and finished, but then 'Finish' has to be pressed for it actually to be present. As a result, the panel on the left then also has to change continually to different modes, and navigation back/forward is required to access these - all of which is very modal and adds congnitive load.
Instead, I think the UI should use a single panel on the left that, when a geometry is selected or being drawn, contains the editing controls, a simple drop-down for the infrastructure type, and the name. Essentially it means that a selected line has information to be 'filled in' but can be left blank at any point so that things like type/name can be completed later.
In other words, tasks like drawing, setting the type, adding names, then do not have to be done in any order: a line can just be clicked on to make it the active item, and one can choose to amend the geometry, add type, fill in the name, etc., or indeed just click somewhere else.
The infrastructure types legend should not be part of a side panel because the side panel is specific to state, but a reference to infrastructure types is not a state-related matter, and should be possible to view at any time. I would make it a panel in one corner of the map.
The infrastructure type selection screen is currently a large radiobutton area. I would change this to a drop-down (with the colours as the background/text colour), which makes reading down the page quicker, or a side-by-side set of images (one of each type) which forms the selection, with a label underneath each.
Mockup:
As you can see, this massively gets rid of lots of UI clutter because almost navigation operations become obsolete. Obviously if no line is selected, most of the left panel doesn't show. It could list the items, but obviously retain the button at the top to add a new item. Line colours match the left panel infrastructure type selection.
This is a quick mockup of the state when no line is selected, including the initial first-run state:
Thanks for the detailed feedback! I agree lots of separate modal states is pretty frustrating here. Keeping geometry and form editing distinct was a decision we've never been sure of in the scheme sketcher context, depending on the complexity of the form. I've started some changes to get closer to the mockups, but there's some bugs with the new consolidated editing/creating state. I'll rework this in my next round of work. For now, you have to press enter or double click to confirm the route geometry when making something new.
I think there still does need to be some kind of "OK" or "Done" or "Confirm" button to return to the main state. Calling it "save" is maybe misleading; everything is auto-saved. But it could be useful to give the user a chance to confirm or cancel all of the changes they've made somewhere. And when creating a new route, if the user fills out the form but never draws any geometry, I'm choosing to disable the "OK" action in this case, because some geometry is necessary.
I'll keep iterating on this, but I more or less agree with Martin's suggestions. Thanks!
I think there still does need to be some kind of "OK" or "Done" or "Confirm" button to return to the main state.
Can you clarify? If the user has no line selected, that is presumably an implicit return the 'main state'. You could have a 'Back' button in the top-left which has the same effect of deselecting the current line.
Can you clarify? If the user has no line selected, that is presumably an implicit return the 'main state'. You could have a 'Back' button in the top-left which has the same effect of deselecting the current line.
I think right now it's pretty easy to accidentally click the map off of the route being edited. So I was thinking a Back button is the way to go. But I also have some ideas for improving the route snapping mechanics using maplibre markers, and maybe with those, it'll be much more rare to click a blank part of the map accidentally while adjusting things.
... But, the route drawing also has an option to keep adding points to the end of the route. In UX studies for other use cases, it's about a 50-50 split if people prefer to set two endpoints and then adjust the middle, or keep appending new points to the end. The use case here is a bit different and hopefully most geometry will just come from the coherent network, but still, there is some ambiguity for clicks on the map to mean "I'm done, deselect this" and "add another point"
No comments from me on this, great you're looking for feedback, let me know if you want a second pair of eyes on this.
Dustin asked:
I got a super rough sketch of the editor started: https://nptscot.github.io/editor/?boundary=LAD_City%20of%20Edinburgh
You can:
1) Draw routes, set their infrastructure type, and edit their details/geometry 2) Look at basic route-level indicators: a detour factor (for directness) and the breakdown of infrastructure type along the way (for coherence and LoS)
I think I'll next hack in a toy example of
3) Importing a route from the coherent network (I'll just manually sketch some inputs matching what you have now) 4) Seeing network-wide metrics, by making up or reusing some zone-based OD data, and starting to see how many routes can be calculated in reasonable time
Feedback on extremely high-level things welcome; details and bugs not helpful right now, because my goal is just scaffolding the end-to-end user flow as roughly and quickly as possible, to show Angus and the others and validate the overall idea.