-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clear previous selection on select features once a new selection drawing is initiated #113
Comments
Why would the selected/highlighted features clear before clicking Go? What if the user changes their mind and cancels? Do we want to destroy the select/highlight then?. |
I'm sorta with @klassenjs here, I know you can create this incongruous situation but these are all understandable steps that the user would've done. |
Personally I'd rather not hit go at all but have it go automatically upon
completion of the selection geometry.
Clearing the selection not at the start of a new selection geometry but at
the completion is what makes sense to me, although it is unclear when a
multipoint is complete and duck mentioned that at the start of a new
selection geometry might work better in the existing phases.
…On Wednesday, June 7, 2017, theduckylittle ***@***.***> wrote:
I'm sorta with @klassenjs <https://github.com/klassenjs> here, I know you
can create this incongruous situation but these are all understandable
steps that the user would've done.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#113 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFBPmsGFiG6tvg7dCoHpM7Zm5NZDm2Alks5sBowRgaJpZM4Nx9Oj>
.
|
Yes, I would say the old selection is gone as soon as they decide to make a
new selection, if they want the old they can redo it. You don't get to
keep both your old selection forever and make a new selection.
…On Wednesday, June 7, 2017, Jim Klassen ***@***.***> wrote:
Why would the selected/highlighted features clear before clicking Go? What
if the user changes their mind and cancels? Do we want to destroy the
select/highlight then?.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#113 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFBPmuJzSZWNEzbYK24hgkVT10jsmP4_ks5sBouEgaJpZM4Nx9Oj>
.
|
How do you know when it is the end of the selection geometry? In general a user might want to revise their input, but particularly with multipoint. |
One of the usability complexes here is that we now allow for more "post processing." We have the ability to slice-and-dice the results in ways that are not preserved. As those slices-and-dices are done against the results and not against the query itself. I get not wanting to hit "Go" at all but there are some issues there:
I think "Go" is still a necessary evil but I think if the user begins drawing on the map we could, ostensibly, clear the last query results. |
For line and polygon, double click signals the end of the selection
geometry. For box (if implemented and enabled), letting go of the mouse
button is the end.
How can input be revised now? My impression is only through redoing it,
which would still be the same option available to them.
Multipoint is of course tricky, it could continually repeat after each
individual point which would make multipoint the only non-clearing option.
Otherwise, require go for multipoint or require a double click on the last
point of multipoint.
…On Wednesday, June 7, 2017, Jim Klassen ***@***.***> wrote:
How do you know when it is the end of the selection geometry? In general a
user might want to revise their input, but particularly with multipoint.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#113 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFBPmmUVfUt3xg01Iirx1c5mlSyXgDMfks5sBpHygaJpZM4Nx9Oj>
.
|
Adjusting radius buffers happens live on the screen for the input
geometry. One approach could be to extend to the selection too.
…On Wednesday, June 7, 2017, theduckylittle ***@***.***> wrote:
One of the usability complexes here is that we now allow for more "post
processing." We have the ability to slice-and-dice the results in ways that
are not preserved. As those slices-and-dices are done against the results
and not against the *query* itself.
I get not wanting to hit "Go" at all but there are some issues there:
1. The multi-point selection mentioned above.
2. Adjusting buffer radius.
I think "Go" is still a necessary evil but I think if the user begins
drawing on the map we could, ostensibly, clear the last query results.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#113 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFBPmnWmDl11VB321t-I7--wKZ2THL01ks5sBpIhgaJpZM4Nx9Oj>
.
|
My general thought process is to draw what I want and then set the buffer I want. Without a Go the buffer would have to happen first. Also, in the past I have traced over a previous select while drawing my new one (to slightly adjust a previous result I wasn't quite happy with). |
You could still set the buffer second (that is what I do too); the select (with the buffer) would happen again. I do that too, it is also why I prefer to keep everything until the geometry is completed not just started. But started sounded like it fit better for implementation. |
i'm wondering if #273 offers a reasonable compromise for everyone? |
#273 seems to give fine grained control to users who want it. There doesn't seem to be any way to change defaults so that only users who want it need to learn it. But this seems to offer all options to users willing to user those options. So yes, this should work. I'll look at it more once it is in the demo. |
From #107,
Right now the way select features works, once a selection is made, it remains selected until the Go button is hit again. This can lead to some screen views that look inconsistent.
This is an enhancement request to clear the previous selection once a new drawing is initiated.
From, #107 (comment), I'm not sure that we have the same understanding @theduckylittle. By "clear the previous selection", I mean the selection input geometry (unless it was a drawing and markup), any buffer geometry, and the selected and highlighted features.
The text was updated successfully, but these errors were encountered: