Description: UI: Preferred user interface: the arrangement of options Steps to Reproduce: 1. View -> Select your preferred user interface Not sure which criterion being used; but the list is not the most practical. I personally would start with they 'most used'. So Standard toolbar + Tabbed. Followed by a splitter and put they other alternatives below. They tabbed one is currently pretty hidden in the middle. That wasn't the point when starting the discussion. I would even argue to set Tabbed default and Standard Toolbar second; Actual Results: Arrangement at random Expected Results: Some order to nudge people & make it easy Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha1+ (x64) Build ID: ec1f4d3253963ac16d638734ac70dde033e82154 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
+1, the original menu order came from merging the existing toolbar/menu/SB with the experimental MUFFIN NB flavors. Elevating the Tabbed NB prominently is fine, add a separator, and then the remainder. No sense to sorting otherwise. Standard Tabbed ------ Single Toolbar Sidebar Tabbed Compact Groupedbar Compact Contextual Single
Or how about this as @Telesto suggested? :) Tabbed Standard ------ Single Toolbar Sidebar Tabbed Compact Groupedbar Compact Contextual Single
My + 1 was for Telesto's "I personally would start with they 'most used'. So Standard toolbar + Tabbed. Followed by a splitter and put they other alternatives below." There has never been an agreement to make any MUFFIN mode the default, and it can not be made default as it remains broken--minimally functional, minimally customizable, completely without accessibility (A11Y) support. Scope here is to raise the Tabbed NB to prominence, fine. But not as a default user UI.
(In reply to V Stuart Foote from comment #3) > My + 1 was for Telesto's "I personally would start with they 'most used'. So > Standard toolbar + Tabbed. Followed by a splitter and put they other > alternatives below." > > There has never been an agreement to make any MUFFIN mode the default, and > it can not be made default as it remains broken--minimally functional, > minimally customizable, completely without accessibility (A11Y) support. > > Scope here is to raise the Tabbed NB to prominence, fine. But not as a > default user UI. Based comments on message board it would be Tabbed. However A11Y support and tabbed not being a exact copy of ribbon, I tend slightly to keeping Standard as a precaution With decent popup (please not Tip of they Day) and choice between standard/tabbed should be pretty obvious. And with Toolbar being standard, we have kind of excuse for they Tabbed bar not being in totally superb shape (we didn't make it default for a reason). OTOH, Collabora Office did already.. so this would speed up bugfixing :-). So taking they neutral position, here
As long bug 135501 remains open the default is Standard not Tabbed. For the rest I have no preference. Separator line goes into cui/uiconfig/ui/toolbarmodedialog.ui where labels should be reordered too. And it require modification to cui/inc/toolbarmode.hrc. Take care of the experimental variants that have special treatment.
+1 for this request There's chance people are not having familiarity with "Tabbed" naming and with this arrangement more developers hopefully come to enhance this still "second class citizen" user interface.
Ayhan Yalçınsoy committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fd9b1fbcae5d90d7e542dae999cffda9a0f928f0 tdf#137925: UI: Preferred user interface rearranged It will be available in 7.2.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.
I apologize for only now commenting on this bug. Ayhan, Rizal and others - I strongly oppose placing "Tabbed" above of "Standard Toolbar". I have argued extensively on why the tabbed interface is problematic and should not be promoted: https://bugs.documentfoundation.org/show_bug.cgi?id=135501#c73 https://bugs.documentfoundation.org/show_bug.cgi?id=135501#c75 including, among other arguments why this statement: > Based comments on message board it would be Tabbed. is an incorrect conclusion; and is not a good basis for making that decision. Additionally, andreas_k says that : > There is NO developer (since forever) how do/will support Notebookbar, so how could we change to it by default? and this is true also for the placement within View | User Interface . Considering how even commenters here have not decisively favored placing Tabbed as the top, default - please swap the order of the two options - making "Standard Toolbar" the default.
I like the addition of the separator, but also would prefer that position 0 keep the rdButton1 assigned to 'Standard', and that rdButton4 assigned to 'Tabbed' UI be placed at position 1. Otherwise the sequence is fine. Though I think folks would enjoy using the 'Contextual Single' UI--it is a hidden gem, and deserves a spot above the separator. Probably should clean up the button assignments to put them in position sequence. =-ref-= https://gerrit.libreoffice.org/c/core/+/112553 Standard -- rdButton1 Single -- rdButton2 Sidebar -- rdButton3 Tabbed -- rdButton4 Tabbed Compact -- rdButton5 Groupedbar Compact -- rdButton6 Groupedbar -- rdButton7 Contextual Single -- rdButton8 Contextual Grouped -- rdButton9 Position Old New (fd9b1fb) 0 rdButton1 rdButton4 1 rdButton1 2 GtkSeparator 3 rdButton4 rdButton2 4 rdButton5 rdButton3 5 rdButton7 rdButton5 6 rdButton6 rdButton7 7 rdButton8 rdButton6 8 rdButton9 rdButton8 9 rdButton2 rdButton9 10 rdButton3
Hi all, If the changed has been completed and then given the once over by Heiko Tietze only a few hours ago why is there a call to change the order so quickly? What is fundamentally different now? I think the order as amended is perfectly fine. Kind regards
(In reply to John Mills from comment #10) > If the changed has been completed and then given the once over by Heiko > Tietze only a few hours ago why is there a call to change the order so > quickly? What is fundamentally different now? I think the order as amended > is perfectly fine. > Bcz it was not what was agreed to--that 'Tabbed' UI would get top billing. 'Tabbed' NB, and any of the MUFFIN assemblages, remain deficient UI compared to fully implemented "menu & toolbar" paradigm of the 'Standard' UI, unworthy of promoting for the multiple reasons. That coupled with technical issues of the patch (button assignment out of sequence with position)--the patch can either be reverted, or modified, when that is done it would be appropriate to reverse the 'Standard' & 'Tabbed' UI order restoring 'Standard' to its proper position.
Agreed by who? What is wrong with the tabbed option taking 'top billing' as you say? Isn't LibreOffice a doers project and someone has stepped forward to make the required changes.
(In reply to V Stuart Foote from comment #9) > I like the addition of the separator, but also would prefer that position 0 > keep the rdButton1 assigned to 'Standard', and that rdButton4 assigned to > 'Tabbed' UI be placed at position 1. > > Otherwise the sequence is fine. Though I think folks would enjoy using the > 'Contextual Single' UI--it is a hidden gem, and deserves a spot above the > separator. > > Probably should clean up the button assignments to put them in position > sequence. > > =-ref-= > > https://gerrit.libreoffice.org/c/core/+/112553 > > Standard -- rdButton1 > Single -- rdButton2 > Sidebar -- rdButton3 > Tabbed -- rdButton4 > Tabbed Compact -- rdButton5 > Groupedbar Compact -- rdButton6 > Groupedbar -- rdButton7 > Contextual Single -- rdButton8 > Contextual Grouped -- rdButton9 > > Position Old New (fd9b1fb) > 0 rdButton1 rdButton4 > 1 rdButton1 > 2 GtkSeparator > 3 rdButton4 rdButton2 > 4 rdButton5 rdButton3 > 5 rdButton7 rdButton5 > 6 rdButton6 rdButton7 > 7 rdButton8 rdButton6 > 8 rdButton9 rdButton8 > 9 rdButton2 rdButton9 > 10 rdButton3 I agree with you. I will fix them soon.
In a question independent of the order isn't 7 choices just too much for an average user to really differentiate with any confidence? I would much prefer to see only two choices, those being Standard and Tabbed with the rest being made available through enabling experimental functions or something to that effect. Not to detract from the hard work undertaken by those who worked upon the other 5 options. Isn't a separator indicating that the top two items are the preferred UI option with the others not having the same weighting?
(In reply to John Mills from comment #14) > In a question independent of the order isn't 7 choices just too much for an > average user to really differentiate with any confidence? I'd say it's too much, but not for this reason. That is, the user can just try more options and settle on the one they like. The thing is, some, or all, of the options other than Standard Toolbar are quite ready, including just "Tabbed" (e.g. bug 138440). Are we, or rather are you, willing to commit to have verified that all interface modes are free of such gaps by the time 7.2.0 is released? > Not to detract from the hard work undertaken by those who worked upon the > other 5 options. Isn't a separator indicating that the top two items are the > preferred UI option with the others not having the same weighting? Yes, it clearly indicates that.
(In reply to John Mills from comment #14) Not at all. Selection of the UI by main menu View --> User Interface... to launch of the UI picker "Select Your Preferred User Interface" is a *low frequency* user selection. The dialog is instrumented to allow the selection to apply to all modules, of to individual LO modules. Addition of a separator now will "steers" them to the fully functional 'Standard' UI or the half-baked 'Tabbed' UI, warts and all. The adventuresome can work with the second class UIs placed under the separator as guided by the localized descriptions and mode previews incorporated into the dialog. Srry, but showing just two UI modes makes no sense--and dilutes what benefits the MUFFIN effort offers the project.
>Addition of a separator now will "steers" them to the fully functional 'Standard' UI or the half-baked 'Tabbed' UI, warts and all. Let me ask why you refer to the 'Tabbed' UI in such a condescending way when it is used by many LibreOffice users? This bias indicates that whatever work was done to improve this would not meet your exacting standards. Yes it's not perfect but clearly wanted by a sizable percentage of the user base. And this will surely increase as time passed as it has already. >Srry, but showing just two UI modes makes no sense--and dilutes what benefits the MUFFIN effort offers the project. I respectfully disagree, clearly you want to show the flexibility that LibreOffice offers, however this becomes a paradox if people have too much choice as they do not know what to choose. Similar to the numerous Linux distribution available. By also having 7 choices you implicitly imply that these will be supported for the long term. Hence why I questioned the viability long term. Returning to the topic of choose I would like to refer you to a very honest review of LibreOffice 7.1 from Dedoimedo who raised these very same concerns. https://www.dedoimedo.com/computers/libreoffice-7-1-review.html It is important to read widely where possible what actual users who make the effort to post reviews actually think. Regards
(In reply to John Mills from comment #17) > the 'Tabbed' UI ... is used by many LibreOffice users Do we have statistics regarding the fraction of LO users who use the tabbed UI?
We don't need to be rehashing the TL;DR discussions of bug 135501 here, Ayhan's patch closes this issue out.
>Do we have statistics regarding the fraction of LO users who use the tabbed UI? As said above this probably isn't the correct place for the discussion. I believe there is some sort of analysis available in LibreOffice however switched off by default. Short answer, I don't know and I think no one really does. This would be very useful information, perhaps someone like Mike Saunders from the marketing team could help there. I think it is important that strategy and decisions (to an extent) are based on empirical evidence. However you won't get people using something new if it is not promoted.
(In reply to V Stuart Foote from comment #9) > ... is a hidden gem, and deserves a spot ... Would do this by renaming the options. "Tabbed" is not attractive to me neither the other terms. Standard -> Classic Tabbed -> Windows Single -> Small Screen Contextual Single -> Compact Contextual Grouped -> Novice (this is the actual gem!) We can also use creative names, eg. cities because of Redmond, flowers, some Indonesian terms... whatever.
>Standard -> Classic >Tabbed -> Windows >Single -> Small Screen >Contextual Single -> Compact >Contextual Grouped -> Novice (this is the actual gem!) >We can also use creative names, eg. cities because of Redmond, flowers, some >Indonesian terms... whatever. Yes, that is an excellent idea. I would keep it vaguely relevant, certainly Redmond in respect of Tabbed as that is where Microsoft is based. I wouldn't go and call 'Single' daffodil as an example. :) The current names same extremely geeky.
> The current names same extremely geeky. Sound extremely geeky I should say.
It seems that we are continuing the argument about which UI mode to prefer and promote, while pretending not to: 1. Is the bug fixed or not? 2. What should the UI mode names be? 1. This bug is not quite fixed. Why? It's about the arrangement of options in the UI dialog. The "expected results" in the opening comment is the order in which we want to "nudge people", i.e. our order of preference for users' setting. It seems it is settled, for now, that the order should be Standard Toolbar first, then Tabbed. That's not currently the case, so the expected state of affairs is not yet realized. However, since Ayhan says he will make this change - I'll not start a "toggle war" by reopening. Ayhan, please make your commit ASAP as you said you would (_NOT_ with the new chage Heiko and John now suggest, see below). 2. We have a standard toolbar UI mode. Heiko and John Mills, who support making the ribbon/tabbed interface the default, suggest renaming Standard -> Classic Tabbed -> Windows that means that we're declaring our standard UI mode to no longer be the standard (with arguably some hit of it being outdated). Standard, or Standard Toolbars, is a fine name, and is more informative than "Classic" (certainly for new users, who do not know what UI LO used to have). As for ribbons/tabbed - the renaming would make obscure its meaning: "Windows? Do they mean as in the Operating System? Or will I have more LO windows instead of fewer?" I also think the renaming of the other modes should not be named with a description of the scenario/context of their use, but rather with what their visual nature. IMHO, the latter only seems meaningful if you already know what that UI mode looks and behaves like.
Ayhan Yalçınsoy committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3989fdb4fc7333236869c9bec9612fc86aba77c7 tdf#137925: UI:Preferred user interface rearranged It will be available in 7.2.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.
verified as fixed in: Version: 7.2.0.2 / LibreOffice Community Build ID: 614be4f5c67816389257027dc5e56c801a547089 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded