follow-up of the controversial Bug 93318 some users like to have all the 4 buttons visible (first, previous, next, last) while others would like to have just the "previous" and "next" buttons and get rid of the "first" and "last" buttons. the only way to please both categories of user is to allow customization of that UI part allowing the user to decide which buttons to show and which to hide. such customization has never been possible since the OOo era.
The key take away from Bug 93318 was that the "First" and "Last" buttons are only useful when you have approx 20+ sheets visible. The rest of the time the buttons are useless. Because such large worksheets are unusual, Tomaž replaced the buttons with a CTRL+click. As Yousuf pointed out, the problem with this is we didn't have a tooltip, so the discoverable was ZERO, and rightly some users complained. Instead of adding a tooltip, we brought back the 2 useless buttons. I see 3 solutions to Bug 93318's poor compromise to a valid concern. 1) Try Yousuf's suggestion of adding a tooltip 2) Only show the "First" and "Last" buttons when not all of the sheets are visible. 3) Make "First" and "Last" buttons an opt-in for power users that deal with massive spreadsheets
(In reply to Luke from comment #1) > .... > I see 3 solutions to Bug 93318's poor compromise to a valid concern. > > 1) Try Yousuf's suggestion of adding a tooltip the tooltip is not the best choice in my opinion... first not many users wait in patience to see a tooltip appear, so they would still think that the function was removed. second, a user that going to use the "first" and last "button" wants to do it immediately with a single click... the Ctrl+Click thing is annoying and needs two hands instead of one. > 2) Only show the "First" and "Last" buttons when not all of the sheets are > visible. > 3) Make "First" and "Last" buttons an opt-in for power users that deal with > massive spreadsheets I think both "2" and "3" to be good solutions, a developer probably can tell which one is easier to implement. let's see what Tomaz thinks about. I'm not expecting he's going to fix it, but maybe he can just give a technical opinion on the feasibility of such a thing.
Adding a tooltip is not an option for LO 5.0 (can't add new strings that need to be translated) so reverting was the only option. For 5.1 we can change that.. I have a solution that does "First" "Last" "Next" "Previous" button hiding when they are not needed it just needs some more polish before it goes into master.. Tomaž
I would assume there is a third category of users who dont care to see them at all, as you can easily navigate backwards and forward with mouse scroll thanks to Tomaz's work. :D
(In reply to Tomaz Vajngerl from comment #3) > ... > I have a solution that does "First" "Last" "Next" "Previous" button hiding > when they are not needed it just needs some more polish before it goes into > master.. that would be a very nice improvement. there're users that think that those button do not work at all and don't know that they only have effect when you have to scroll a long list of sheet tabs look at this report: Bug 89265 - The four worksheet navigation buttons don't work (In reply to Yousuf (Jay) Philips from comment #4) > I would assume there is a third category of users who dont care to see them > at all, as you can easily navigate backwards and forward with mouse scroll > thanks to Tomaz's work. :D sure, when a selective show/hide button option will exist, those users could hide them all
(In reply to tommy27 from comment #5) > there're users that think that those button do not work at all and don't > know that they only have effect when you have to scroll a long list of sheet > tabs That's why I turned on "disabling" of buttons too.. I don't know why but it looked like this was turned off intentionally.
First of all, thanks to Thomaz for restoring the first and last tab scroll buttons I asked for in bug 93318. I found the subsequent user comments in that bug commentary revealing in the variety of reactions to something so basically simple. Given that there would seem to be no approach which would please everyone, it's kind of a wonder that people such as Thomaz would want to volunteer their personal time to do anything! But, fortunately, they do, and the rest of us without such skills get to benefit. One of the apparent desires by other users is for controls that have no function in a particular context to not be visible. For a mouse right-click context menu, that is exactly what I would expect, i.e., to only see a list of things I can do in that specific context. However, I fail to see any harm in having a control visible which, at that moment in time, doesn't have any function it can be expected to do. It's presence is not doing any harm, the space it takes up can't be used for anything else, and putting in the code to make it visible/invisible as the context demands adds to the bloat of the overall program and makes the program less responsive. I support the concept of allowing users to customize which controls are visible, as this enhancement bug seeks to do. But, that's a one-time step for the user and the program, not something the program has to constantly evaluate. Thinking more about the specific topic of the tab scroll buttons, I offer the idea that the scroll one tab left and right buttons might be more useful if they scrolled one sheet width's worth of tabs, rather just one tab. One of the commenters in bug 93318 expressed the view that a large number of tabs in a workbook was more of a rarity. Perhaps it is for him, but for me it is very common, and I suspect I am not the only such user. Perhaps scrolling a sheet width's worth of tabs is programmatically difficult to achieve, but if not, doing so is more likely to bring the desried tab into view with one click than advancing only one tab.
> However, I fail to see any > harm in having a control visible which, at that moment in time, doesn't have > any function it can be expected to do. This is why open source software has such a bad reputation for poor usability. People with no design experience sway the design process. When commercial software companies do usability studies, they always come to the same conclusion, that the fewer buttons, the easier it is for people to use. This is why we have greatly simplified our context menus. > It's presence is not doing any harm, > the space it takes up can't be used for anything else, What part of "I sometimes mis-click trying to click those microscopic buttons. Two big buttons are much better" (than four little ones) in Bug 93318 don't you understand? > rest of us without such skills get to benefit... putting in the > code to make it visible/invisible as the context demands adds to the bloat > of the overall program and makes the program less responsive. So you have no programming experience and yet still expound your theories on software engineering to argue against implementing this enhancement. If enabling 2 hidden buttons causes a noticeable performance hit on modern hardware, there is something seriously wrong with your widget toolkit.