[QGIS-Developer] Why was selection tool behaviour changed in 3.x?
Saber Razmjooei
saber.razmjooei at lutraconsulting.co.uk
Sun Apr 14 01:21:53 PDT 2019
Hi
> 2) select by polygon: behaves the same
For select by polygon, there is an additional option: right-clicking allows
you to select features intersecting with existing polygon shapes (so that
you do not need to capture the same geometry):
https://twitter.com/lutraconsulting/status/1040328624002527232
Regards
Saber
On Thu, 11 Apr 2019 at 08:30, Bernhard Ströbl <bernhard.stroebl at jena.de>
wrote:
> Hi,
>
> @Marco I can second Cory that the selection tools' behaviour is
> different between 2.18 (tested on Win) and 3.* (tested on Win and Ubuntu)
> 1) select by rectangle: behaves the same (click + drag)
> 2) select by polygon: behaves the same
> 3) select by freehand: behaves differently: 2.18 click + drag 3.* click
> + click
> 4) select by circle: behaves differently: 2.18 click + drag 3.* click +
> click
> I have no strong feeling for either behaviour (hardly use options 2 to
> 4) but I would think that the behaviour should be consistent within QGIS
> (either all click + drag or all click + click). Click + drag is well
> established (e.g. Inkscape, Bentley Microstation) at least for the
> rectangular selection, so maybe it would be better to use this approach.
> Furthermore this is how the rectangular selection works in the layout, too.
>
> @Cory concerning the vertex-editing tool there has been a lot of
> discussion and there were good reasons to change its behaviour. A lot
> has been improved recently: most prominent IMHO: feature can be locked
> for exclusive editing with a right click (similar to selecting a feature
> for editing in 2.*) but can be edited directly without locking e.g. by
> simply picking and moving vertices. May I therefore ask you to try again
> with current master (or a nightly build)? And may I further ask you to
> forget how it was in QGIS 2 and simply try how it works in 3?
> AFAIK there is no "standard" in mouse behaviour for vertex editing. CAD
> uses click + click (I can at least say for Microstation), Inkscape uses
> click + drag, so if one or the other seems familiar might depend on
> one's background.
>
> just my 2ct
>
> Bernhard
>
> Am 10.04.2019 um 17:38 schrieb Marco Bernasocchi:
> > Hi
> >
> > On 09.04.19 02:53, Cory Albrecht wrote:
> >>
> >>
> >> Cory Albrecht <maps at hanfastolfe.com <mailto: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.
> > I just tested and the answer are, as Régis mentioned, the same as in
> > 2.18 ( tested using 3.4.4). the behavior you describe is only true when
> > you activate "select by polygon".
> >>
> >> 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.
> > That is exactly why QGIS does it the same why as other tools.
> >>
> >> 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?
> >
> > a very quick google search returned the whole rationale to changing the
> > behavior of the Node tool [0] but none for the behavior you describe,
> > which I could not reproduce. Could you show us a screencast?
> >
> > [0] https://github.com/qgis/QGIS-Enhancement-Proposals/issues/69
> >
> > oh, and cheers
> >
> > Marco
> >
> >>
> >> On Mon, Apr 8, 2019 at 6:00 AM Régis Haubourg
> >> <regis.haubourg at gmail.com <mailto: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
> >> <mailto: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
> >> <mailto: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
> > --
> > Marco Bernasocchi
> > QGIS.org Co-chair
> > marco at opengis.ch <mailto:marco at opengis.ch>
> > +41 (0)79 467 24 70 <tel:+41794672470>
> >
> > OPENGIS.ch Logo <https://www.opengis.ch>
> >
> >
> > __________ Information from ESET Mail Security, version of virus
> > signature database 19173 (20190410) __________
> >
> > The message was checked by ESET Mail Security.
> > http://www.eset.com
> >
> > '�z�Zr �r ^�)�j[p��Z��'~��zJ&�W�� ��{^� �iק
> >
>
>
> --
> Bernhard Ströbl
> Anwendungsbetreuer GIS
>
> Kommunale Immobilien Jena
> Am Anger 26
> 07743 Jena
>
> Tel.: 03641 49- 5190
> E-Mail: bernhard.stroebl at jena.de
> Internet: www.kij.de
>
>
> Kommunale Immobilien Jena
> Eigenbetrieb der Stadt Jena
> Werkleiter: Karl-Hermann Kliewe
>
>
> __________ Information from ESET Mail Security, version of virus signature
> database 19176 (20190411) __________
>
> The message was checked by ESET Mail Security.
> http://www.eset.com
>
>
> _______________________________________________
> 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
--
Saber Razmjooei
www.lutraconsulting.co.uk
+44 (0)7568 129733
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20190414/7fa915c5/attachment-0001.html>
More information about the QGIS-Developer
mailing list