> 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 <winfi...@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 <m...@hanfastolfe.com> wrote: > >> >> Cory Albrecht <m...@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.haubo...@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 <m...@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@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@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@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer