Description: The column resize handle touch target is only 1-2px wide, leaving little margin for targeting when resizing the column. While recovering from a mild wrist injury, resizing a column became a frustrating and needlessly long exercise for me. By comparison, Google Sheets and Excel use wider touch-targets (around 4-8px) and the difference in ease of use is night and day. Steps to Reproduce: 1. Open a new document 2. Hover the right edge of column header A 3. Hold when the cursor changes to EW-RESIZE 4. Move the pointer slightly Actual Results: Accurately targeting the column resize handle requires very precise fine motor control. When targeting the handle, it is extremely easy to under- or over-shoot the target, requiring deliberate pixel-by-pixel pointer movements to reacquire the target. A slight movement of the pointer (of the kind that could be expected from drift of normal usage) results in immediate loss of the target. Expected Results: Targeting the column resize handle should not be a cognitively demanding task for someone of average or mildly impaired fine motor control. Moving onto and off the column resize handle should transition the cursor to EW-RESIZE and NORMAL roughly in step with the user's intent. No pixel-perfect fiddling should be required to target the handle. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded A small demo has been created to demonstrate the effect of the touch target width on usability here: https://codepen.io/meat-circuit/pen/ZEZBjrJ. The resize handle width can be adjusted dynamically to get a feel for resizing. Setting it to 1px reproduces the experience in LibreOffice, while a setting of 6px is close to the feel of Google Sheets.
Without invalidating the request, let me add: * Changing Calc's zoom factor might help, at least partially. * Adapt the screen to use a bigger factor in your OS. This should not affect the specific request, but might make it easier to interact with small artifacts on screen. * The OS has a magnifier tool too. * The OS has UX methods to control the mouse pointer using the keyboard's arrows and other keys. Again, this does not invalidate the request. I'm changing this report from normal to enhancement request. CC'ing Michael.
FWIW, one concern is the case when the column/row header is rather narrow. Widening the relevant area around the header limit for size-related actions might potentially bother some other types of actions on or near the header. Such cases would need testing, in case this requests changes anything about those situations.
"Between running and stopping, there is a middle way, which is walking." So 3-4px seems to be more appropriate. Now, sometimes it is not very friendly.
(In reply to jon.maccaull@gmail.com from comment #0) > Description: > The column resize handle touch target is only 1-2px wide, leaving little > margin for targeting when resizing the column. While recovering from a mild > wrist injury, resizing a column became a frustrating and needlessly long > exercise for me. By comparison, Google Sheets and Excel use wider > touch-targets (around 4-8px) and the difference in ease of use is night and > day. In my test with trying to move the mouse just a pixel at a time, the handle seems to be more than just 1-2px (rather around 4 pixels maybe?), but making it slightly wider sounds reasonable to me. CC'ing UX advise for further evaluation.
Can we make the responsive area dependent to the zoom factor? Sure, we can if tweaking the area is possible at all.
*** Bug 160747 has been marked as a duplicate of this bug. ***
(In reply to jon.maccaull@gmail.com from comment #0) > The column resize handle touch target is only 1-2px wide, It's at least 4 px wide, if not 5, for me. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ffccbf4762a9ae810bcdd21c41fccdd436e7bfc9 CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: he-IL (en_IL); UI: en-US Could this be a Windows-specific problem?
We discussed the topic in the design meeting. The issue is clear, the hit area is very small in many situations. However, more space to click might have unwanted impact for hidden rows/columns and in case of small width/height. We should give it a try and see how a larger hit area feels.
Created attachment 193949 [details] Screencast with tentative patch applied The hit area is currently >= -2 to <= +2 and I change it to 5. This compromise makes the area much easier to click while being acceptable wide for small columns or rows. An issue remains with hidden columns (or rows) that are sized to zero. Potential solution here might be to block resizing completely. https://gerrit.libreoffice.org/c/core/+/167041
ATM, we don't even know the reasons for the reporter to experience one behavior while other users experience a different behavior. I would guess that a more accurate (but probably harder to find) solution would require such conditions to be known. Without knowing the reasons, whichever solution to the problem has a chance to negatively impact everyone else. Meanwhile, there are possible workarounds suggested. (In reply to Heiko Tietze from comment #9) Potential solution here might be to block resizing > completely. That part is absolutely utterly not a potential solution. Some users are explicitly saying that the reported problem does not happen to them, and there are also suggestions in prior comments to workaround the reported problem. No matter what happens with the reported problem or what related-modifications are made in order to solve a reported problem (suffered by only a sub-set of users), canceling the normal usage of every other user on another feature is not a potential solution in any sense, at all. Please ask actual spreadsheet _users_ before applying changes decided by non-users. Regarding the reported behavior itself, please attempt to find a solution that won't negatively impact other users. We have seen changes that match only a sub-set of users but have a very negative impact on others; but then no one wants to allow alternatives in order for users to adapt the UX to their needs/context.