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.
(In reply to ady from comment #10) > ...attempt to find a solution that won't negatively impact other users. Please elaborate on the negative impact.
(In reply to Heiko Tietze from comment #11) > (In reply to ady from comment #10) > > ...attempt to find a solution that won't negatively impact other users. > Please elaborate on the negative impact. They have been mentioned in prior comments already (including you own); narrow columns for instance. When zooming out, the requirements for precision are greater. Surely the hidden columns matter shall not be affected negatively. Unfortunately, I have more than enough experience regarding changes that negatively affect my UX, but no one wants to allow alternatives or revert a change that was already committed (without considering other users). So, I am mentioning those known factors now, beforehand.
(In reply to ady from comment #12) > They have been mentioned in prior comments already (including you own)... But very generally; I have no convincing use case where the larger hit area becomes a striking argument. We have some misunderstanding about hidden columns, and the fact that it is just minimized aka hidden. To block resize could be actually an improvement. In other words I'm looking for an idea why a user would want to resize a hidden column beyond to make it shown. But I get your resistance and will wait for more opinions. If not, this bug will be a NAB/WF
(In reply to Heiko Tietze from comment #13) > I have no convincing use case where the larger hit area > becomes a striking argument. It is basically the same concern that the OP of this report has: you have to point and drag precisely, and when you make bigger the area on which the mouse pointer changes, then in contrast you have less precision on the other layer (where the header's limits are). When the distance between header limits is big enough, there will be no problem. When the distance is short (e.g. several narrow adjacent columns, or hidden columns), then pointing to the exact zone would become more difficult. So, it is a balance, and what I am reading in this report from several users is that they "don't really have a problem currently (except for the OP), but _maybe_ some minor change could be acceptable". The only way any user could evaluate the change is by actually experiencing it. If you change the current balance, some users could be affected negatively and the probability that they will report back and that something will get done is very small. Other changes to UX have affected me very negatively. Opening new enhancements requests for those has not helped in practice, because, obviously, there are a lot of other things to do, or because reverting is not accepted, or because allowing alternatives for diverse sub-sets of users is "a crime" – even when for some/many users the behavior gets worse, not better. I can only hope the change in this ticket will not be another one. > We have some misunderstanding about hidden > columns, and the fact that it is just minimized aka hidden. To block resize > could be actually an improvement. Utterly disagree. Perhaps you might need to have much more experience/time with spreadsheets as a frequent user. While I personally use other methods, I am well aware that users show/hide headers by changing their width/height by dragging their limits with the mouse; it's a very common practice. For instance, see tdf#90439. > In other words I'm looking for an idea why > a user would want to resize a hidden column beyond to make it shown. Read the prior paragraph.
As I mentioned in the meeting, and that was what more people experienced, is that the touch area is indeed giving me trouble. And sure: broadening should be done with care. So get a patch in the daily builds and collect experiences?
(In reply to Cor Nouws from comment #15) > So get a patch in the daily builds and collect experiences? +1 to that, especially for paying attention to feedback, which is not always the case. With that in mind, I wonder whether perhaps the experiment would be better handled within the future 25.2 cycle, instead of doing it withing the approaching 24.8. Just a thought.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f1d69a84ac82034d7f98877780c549f06d93792d Resolves tdf#160324 - Larger hit area for col/row resize actions It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The patch makes the hit area depended on tools > options > advanced > experimental settings. If enabled, it will be +/-5px and when off the current +/-2.
(In reply to Heiko Tietze from comment #18) > tools > options > advanced > experimental settings FTR: experimental settings > Open Expert Configuration > (preference name) HitArea
(In reply to ady from comment #19) > FTR: experimental settings > Open Expert Configuration... Nope, the hit area is fixed either 2px or 5px to left and right depending on whether the option "Enable experimental features" is checked. If unchecked you get the current behavior, if checked the larger hit area.
(In reply to Heiko Tietze from comment #20) > (In reply to ady from comment #19) > > FTR: experimental settings > Open Expert Configuration... > Nope, the hit area is fixed either 2px or 5px to left and right depending on > whether the option "Enable experimental features" is checked. If unchecked > you get the current behavior, if checked the larger hit area. I thought HitArea was some small/big flag, to select either 2px or 5px. What happens if I want to allow (or set) some other unrelated experimental setting but not this one?