Summary: | A suggestion for better ergonomics for column, row, and cell actions in Calc | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Laurent Lyaudet <Laurent.Lyaudet> |
Component: | Calc | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | NEW --- | ||
Severity: | enhancement | CC: | cno, heiko.tietze, himajin100000, mhillat, thomas.lendo |
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=80390 | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 108019, 108364 | ||
Attachments: | Height comparison between the proof of concept and LibreOffice |
Description
Laurent Lyaudet
2013-07-01 20:47:11 UTC
Alternativaly, we could use the following design ___ |_| | | \| instead of __ | /| |/\| How do you imagine a segmented button having a height of a header row? There's no space for that. (In reply to comment #2) > How do you imagine a segmented button having a height of a header row? > There's no space for that. Wow! That's a balanced comment ><. I already tought about this problem and in fact the second design is an idea I had while thinking about this problem. I thought it would do no harm to increase the height of column headers. When I look at the size of the X cell, I think it's just near the limit to make it easy (note that it will require less precision than dragging the limit between two columns...). I need to try to see what it gives. I'll try to do a proof of concept this week-end in html to validate the dimensions that are needed. In fact, there could be an option to choose between the two "triforce" designs (with a small increase in headers height) or no triforce. What do you think of the gain of time (energy, muscular stress, etc.) for all the users? Is it negligible? Hi, I did a proof of concept here: http://lyaudet.olympe.in/proofOfConceptTriforce_eng.html You can try it, it is easy to do despite of the size. Of course it would be easier if we decide to increase the height. I join a screen capture to show the height in pixels corresponds to the height in Libre Office. Best regards, Laurent Lyaudet Created attachment 84203 [details]
Height comparison between the proof of concept and LibreOffice
Hi Laurent, I don't know if you already joined the Design team at LibO (look at http://www.libreoffice.org/get-involved/ux-visual-designers/) - perhaps you could get supporters for your idea over there... (In reply to comment #6) > Hi Laurent, I don't know if you already joined the Design team at LibO (look > at http://www.libreoffice.org/get-involved/ux-visual-designers/) - perhaps > you could get supporters for your idea over there... Hi Bernhard, Many thanks for the suggestion. Hi, My old website at lyaudet.olympe.in has been down for a few years. The proof of concept is now available on my new website : http://lyaudet.eu/laurent/proofOfConceptTriforce_eng.html Best regards, Laurent Lyaudet Adding needsUXEval to discuss this. (In reply to Laurent Lyaudet from comment #0) > Suppose you want to unhide all hidden columns and all hidden rows. > You have to click 5 times > I propose the X zone to be replaced by the following visual element, > split the X zone in 3 parts like this... > and make all three zones clickable and right clickable: To un/hide all col/rows you select all and right click either row or column (two clicks +1). While the separation sounds like a fancy addition it has not so much benefit as it just provides the right click on a part of this cell (1+1 clicks). And we have to select all anyway to give proper feedback. So I'm not objecting the idea but doubt its benefit. (In reply to Heiko Tietze from comment #10) > (In reply to Laurent Lyaudet from comment #0) > > Suppose you want to unhide all hidden columns and all hidden rows. > > You have to click 5 times > > > I propose the X zone to be replaced by the following visual element, > > split the X zone in 3 parts like this... > > and make all three zones clickable and right clickable: > > To un/hide all col/rows you select all and right click either row or column > (two clicks +1). While the separation sounds like a fancy addition it has > not so much benefit as it just provides the right click on a part of this > cell (1+1 clicks). And we have to select all anyway to give proper feedback. > So I'm not objecting the idea but doubt its benefit. Hello Heiko, I don't see why your reply censored my explanation. Here is the missing part : >You have to click 5 times >- X zone >- right click column, click unhide >- right click row, click unhide What you propose is 3 clicks for unhiding only rows or only columns. My proposition enables to unhide both rows and columns at the same time in 2 clicks instead of 5. Please, consider that ideas of other people may be interesting too. Best regards, Laurent Lyaudet (In reply to Laurent Lyaudet from comment #11) > My proposition enables to unhide both rows and columns at the same time in 2 > clicks instead of 5. Quite uncommon use case, right? Hm... maybe not if you want to unhide everything. But this could be solved with a context menu on the edge cell itself. Or a dedicated command / menu item. (In reply to Heiko Tietze from comment #12) > Quite uncommon use case, right? Hm... maybe not if you want to unhide > everything. But this could be solved with a context menu on the edge cell > itself. Or a dedicated command / menu item. Hi Heiko, The very initial goal was effectively to unhide everything. I cannot judge whether it is an uncommon use case because I have only my own experience. Nevertheless, I did not stop with the initial problem. I analyzed a more general problem with a rational point of view to avoid doing the same work over and over. My proposition is an optimal UI/UX *with mouse* in terms of the number of clicks: - for row actions (2 clicks instead of 3 at the moment), - for columns actions (2 clicks instead of 3 at the moment), - for cell actions (2 clicks instead of 3 at the moment), - for row and column actions at the same time (2 clicks instead of 5 at the moment) Having a classification of actions into one or two of these sets of actions is easy to do in code. You add a new action, it falls into one or two of these sets and voilĂ . No need for a dedicated command / menu item. If you do not split the edge cell with one of my two designs, but add only a contextual menu with cell actions and simultaneous row and column actions, it will solve 2 of the four cases, including the one with the biggest gain (2 clicks instead of 5). It would not be optimal for the mouse users in all cases but it would still be a nice improvement. Now, I don't understand why there is so much need for administrative or politician debate around a feature that is optimal for mouse users. I can understand that the devs are too busy but otherwise I don't see the point of preferring "worse" over "better". I am paranoid so I thought for years (this feature request is 7 years old) that: - either Microsoft Office has infiltrated people in Libre Office and nice features are always object of a lot of nit-picking to bury them under going-nowhere debate, - or there is a problem with my person, in which case it seems that hate of a single individual like me is stronger than love of LibreOffice's users. - or it is just plain old jealousy and standard abuse of power as is customary in politics, administrative processes, in business company, in states administrations and in civil society organizations unfortunately too. Can you share with us your motivations for arguing that my feature request is not a good one? Best regards, Laurent Lyaudet (In reply to Laurent Lyaudet from comment #13) > (conspiracy theory) <snip> > Can you share with us your motivations for arguing that my feature request > is not a good one? Making the edge cell a complex UI element requires expert knowledge. The UNO command would be an easyhack, doable on beginner level. From the UX POV I have concerns with discoverability- while it might be convenient for you many users don't right-click every element in the UI. Plus, such a feature has issues with accessibility. I agree with the requirement to unhide all. But the one additional click to show all rows or all columns is acceptable, IMO. Your proposed solution is not bad and I'm not against the implementation (would have resolve the request as wontfix in this case) but might be done more simple. |