[QGIS-Developer] Why was selection tool behaviour changed in 3.x?

Cory Albrecht maps at hanfastolfe.com
Sun Apr 14 15:42:33 PDT 2019


> I would like to see a mode where the node that will be moved is
autoselected based on proximity to the mouse pointer.

That would be a UX prone to mistakes unless it had to be explicitly turned
on and very visible when on. :-)

On Mon, Apr 8, 2019 at 11:23 PM Jo <winfixit at gmail.com> wrote:

> I guess the rationale was making it easier on the tendons in the carpal
> tunnel. Click, hold/move, click became click, move, click.
>
> I would like to see a mode where the node that will be moved is
> autoselected based on proximity to the mouse pointer. Then it would become
> move, click, move, click. Obviously this needs to be guided by a
> rubberband, whowing which node will be moved.
>
> In JOSM this "improve way accuracy" also allows Ctrl-Click for adding
> nodes, I mean vertices.
>
> Polyglot
>
> On Tue, Apr 9, 2019 at 2:54 AM Cory Albrecht <maps at hanfastolfe.com> wrote:
>
>>
>> Cory Albrecht <maps at hanfastolfe.com>
>> 8:14 PM (37 minutes ago)
>> to Régis
>> Hello Régis,
>>
>> Sorry for not being clear - I mean when using the selection tool in
>> freehand mode. I am definitely not talking about the identification tool,
>> assuming you're referring to the same thing that I am thinking of?
>> Ctrl+Shift+I, or the icon that is the cursor with a the letter "i" in a
>> sold blue circle. I'm not sure I would call that new as it's been part of
>> QGIS since I started using it in about 2015. Perhaps you're an old salt
>> from the 1.x days? ;-)
>>
>> As a principle of UX design, ideally, the user should do the same action
>> - click and drag - for any type of selection, both to maintain internal
>> consistency in the application and with common ways of doing things in the
>> broader computer universe. This lets people learn new software quickly by
>> having a set of transferable actions that can get them up and running and
>> doing rudimentary things quickly. It also helps reduce unintended errors
>> caused by using common actions that get unexpectedly interpreted different
>> than the user is used to. Things like this contribute to how easy or
>> frustrating an application is to use, both for new and long time users.
>>
>> 1. For the "Select Feature(s)", click and drag to indicate the diagonally
>> opposite corners of a selection rectangle.
>> 2. For the "Select Features by Freehand", click and drag to create an
>> irregular blob of selection area.
>> 3. For the "Select Features by Radius", click and drag to indicate the
>> centre of a selection circle and it's radius.
>>
>> In 2.x the answer to all of those was yes, but in 3.x it's yes, no, no.
>>
>> In vector and raster drawing applications, drawing rectangles, circles
>> and blobs is done by click and drag, as is selecting rectangular, circular
>> or irregular blobby areas. If you release and click elsewhere then drag,
>> you start drawing a new object, or you discard the first selection and
>> start outlining a new one. Word processing and text section, video editors
>> and frame selection, sound editors and lengths of time in a track, they all
>> have the user do these conceptually similar tasks in the same way - click
>> and drag to create a selection , new click discards old selection.
>>
>> Another principle of UX design is that you don't change how a user does
>> something unless there is clear benefit that outweighs the trouble of
>> relearning, especially for action concepts that are common in the broader
>> sphere. When you make changes without benefits you cause friction in your
>> user flows (some call those "point points"), and that means people find
>> that task (and potentially the application as a whole) difficult and
>> frustrating to use.
>>
>> For those three methods of selection there's nothing to be gained by
>> making QGIS 3.x the odd one out in how this is done. There's no benefit
>> added by extra functionality in these selection methods. All it does is
>> create pain points, both by being different from everybody else and by
>> being inconsistent internally.
>>
>> The exception to this is the poly gone selection tool. I've never
>> encountered it outside of QGIS and ArcGIS. Drawing applications have
>> polygon drawing tools in which you sequentially click the polygon's points,
>> just like how you create features on polygon or line layers in QGIS, but
>> there's no polygon selection analogue. As such it makes sense to take the
>> feature creation method of sequential clicks over for use in a polygon
>> selection tool rather than coming up with a whole new user flow like click
>> and drag and tapping the space bar for the points.
>>
>> And so I wonder - what was the rationale behind making this change?
>>
>> On Mon, Apr 8, 2019 at 6:00 AM Régis Haubourg <regis.haubourg at gmail.com>
>> wrote:
>>
>>> Hi Cory,
>>> I must say I didn't notice any difference on the selection tool behavior
>>> on my side.
>>> I don't think there was any explicit attempt to homogenize the selection
>>> behavior with the node tool new ergonomy.
>>>
>>> Just a check, in the maptool dropdown list for selection tool, are your
>>> using the freehand selection tool or the classical clic and drag selection
>>> tool?
>>>
>>> I've seen similar surprising issues with the new "identify" tool that
>>> now can interrogate features in a polygon. Users got confused when they
>>> changed this behavior by mistake. Could that be your case?
>>> Cheers
>>> Régis
>>>
>>> Le lun. 8 avr. 2019 à 01:09, Cory Albrecht <maps at hanfastolfe.com> a
>>> écrit :
>>>
>>>> I was wondering why the selection tool behaviour in 3.x was changed
>>>> from the implementation in 2.18?
>>>>
>>>> In 2.18.x when you wanted to select features in a layer, you clicked
>>>> the primary mouse button, held it, and moves the mouse cursor over the
>>>> items you wanted to select - known as "click and drag". To help, a shape
>>>> was drawn on screen for the user to know what they had already dragged the
>>>> mouse over top of. To add to the selection you used shift plus click and
>>>> drag, to remove, Ctrl plus click and drag. It the way select tools work
>>>> broadly across computer world and is intuitive because of it's ubiquity -
>>>> learn it once, use it everywhere.
>>>>
>>>> In 3.x, however, instead of using that common method, it has changed to
>>>> click and release and move the mouse around. This is a common UI method to
>>>> set focus to an item for subsequent actions but still be able to move the
>>>> mouse around without selecting or affecting any other items. I know things
>>>> would work slightly different in QGIS because of having a distinct
>>>> selection tool that one must activate, but this removes intuitiveness from
>>>> the application and makes it more difficult to use without any
>>>> corresponding gain in functionality.
>>>>
>>>> A similar change has also happened in the vertex editor where in 2.18.x
>>>> single clicking on a vertex used to mean select, and you had to drag (click
>>>> and hold) to move it. Now, if you click and release, it unexpectedly drags
>>>> the vertex around as you move the mouse.
>>>>
>>>> QGIS having it's own, non-standard mouse actions for tasks that are
>>>> common (select, copy, delete, etc…) across all types of data (text in a
>>>> wordprocessor, frames in a movie editor, features in a map editor, etc…) is
>>>> counter-intuitive and confusing, especially if those non-standard actions
>>>> are already commonly used for other common user interface actions.
>>>>
>>>> It's almost like the QGIS development team has decided that Ctrl+V will
>>>> now mean "Cut", Ctrl+X will mean "Copy", and to copy have to use Alt+F1 for
>>>> "Paste". Extending common user interface actions for something in QGIS that
>>>> has no exact parallel but is still conceptually similar to that common
>>>> action, like how Ctrl+Alt+V means paste what was copied into the buffer
>>>> into a brand new layer, that makes sense. But ignoring decades of common UI
>>>> actions that are in the muscle memory of probably all users makes the
>>>> programme frustrating and tedious to use as one has to constantly remind
>>>> themselves that QGIS is different.
>>>>
>>>> _______________________________________________
>>>> QGIS-Developer mailing list
>>>> QGIS-Developer at lists.osgeo.org
>>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20190414/14047d0e/attachment-0001.html>


More information about the QGIS-Developer mailing list