Bug 135501 - Change the default UI (see comment 67)
Summary: Change the default UI (see comment 67)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
7.1.0.0.alpha0+ Master
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on: 117463
Blocks: UI
  Show dependency treegraph
 
Reported: 2020-08-06 14:35 UTC by Heiko Tietze
Modified: 2020-09-26 12:12 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments
A dialog picker rough mock-up (110.66 KB, image/png)
2020-08-10 10:19 UTC, Pedro
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Heiko Tietze 2020-08-06 14:35:35 UTC
With the release of 7.0 we got some attention and comments. And a surprisingly large number of users is not aware of the UI variants and would like to use one of the Notebookbar variants. Question is:
* Do we want to switch the default from Standard to Tabbed (or any other option)

Changing the default feels like a regression for many users. So this change should not be done before we have an option to choose the UI, see bug 117463 (I disagree with the dialog on first start but welcome advertising and access via Tip-Of-The-Day.)

Another issue is that we have quite many UI variants and it might confuse users. Question here
* Do we want to remove some UI variants, and if so which?
Comment 1 Heiko Tietze 2020-08-06 14:39:11 UTC
(In reply to Heiko Tietze from comment #0)
> With the release of 7.0 we got some attention and comments. 

For example here https://www.reddit.com/r/linux/comments/i43zrt/libreoffice_70_released_with_new_features_and/
Comment 2 John Mills 2020-08-06 14:44:42 UTC
The most logical UI choice would be the tabbed interface on Microsoft Windows as this is the UI that the vast majority of users would be most familiar with. I say that as someone who has installed LibreOffice on numerous colleague, friends and student's PCs.

The standard 'Tabbed' UI (not compact)is the closest to the Microsoft Ribbon and would aid in the adoption of LibreOffice.

This is a very pragmatic option and aids in the adoption of FLOSS software for those users that are 'put off' by the current UI that resembles Microsoft office 2003.
Comment 3 V Stuart Foote 2020-08-06 15:00:44 UTC
Sorry, but the MUFFIN are 'alternative' lightweight Glade based assembled user interfaces. The fully instrumented UI remains Toolbar & Dialog based.

That should remain the 'default' UI, with some guidance for folks interested in one of the MUFFIN assemblages, e.g. work on bug 117463

Otherwise a robust -1 and => WF
Comment 4 V Stuart Foote 2020-08-06 15:03:47 UTC
s/Toolbar & Dialog/Toolbar, Menu & Dialog/
Comment 5 John Mills 2020-08-06 15:11:58 UTC
The force of conservatism vs pragmatism and user adoption/growing the LibreOffice ecosystem.
Comment 6 V Stuart Foote 2020-08-06 15:28:50 UTC
(In reply to John Mills from comment #5)
> The force of conservatism vs pragmatism and user adoption/growing the
> LibreOffice ecosystem.

No this is pragmatic--the MUFFIN Tabbed NB only looks like the MS Ribbon UI it does not implement that API.

While changing the default for only the Windows builds would require a whole parallel documentation including large sections detailing the differences between our button UNO actions and the MS API for the Ribbon namespace.

Again that is pragmatism recognizing the reality of the development and documentation resources available to the project.

Frankly the most functional MUFFIN UI is the Contextual Single hybrid--but the default Toolbar, Menu & Dialog supplemented by the Sidebar remains the most appropriate to ship cross-platform.

Again that is being pragmatic. Working with one of the MUFFIN alternatives is already trivial from the View menu for anyone interested--no reason to choose one of them as a default when existing default is the most functional.  Again pragmatism.
Comment 7 Pedro 2020-08-06 15:47:15 UTC
IMO, the main problem that became quite clear in several comments in that Reddit thread and other online discussions is that many people didn't even know about the alternative UIs.

Thus, something must be done for users to be made aware of them. 
There are two ways to address this:

1 - Change the default UI.

2 - Provide a dialog picker at first start after an installation and give the user freedom of choice to select one of the multiple available UIs.

3 - Keep it as is.

Option 1 presents some advantages: 

a) not necessary to make a new dialog to select the UI.
b) Tailor the selected UI to OS where LibO is installed.

Option 1 also presents some disadvantages:
a) Novice users, or users with such an ingrained routine that they don't venture to look at different menus still won't know where to change the UI in case they don't like it,
b) A choice is imposed by the devs to the users. There might be Windows users that prefer the standard toolbar and won't like to have their UI changed from one version to the other.
c) The devs need to choose the default UI to ship to users. This opens a can of worms of discussion, where personal preferences of devs might not match the preference of end users (ex. more devs work on Linux environment and prefer standard toolbar thus they pick that for Windows users that prefer Tabbed UI)

Option 2 to me has more advantages:

a) Highlight the flexibility in UIs from LibO, one of the strong points of LibO together with file compatibility,
b) Highlight ALL the UIs done by the Design community of LibO. The standard toolbar is legacy, the Notebookbar UIs were actually developed by work of LibO contributors.
c)Provide freedom of choice to the user. The user will be made aware of the different UIs. Novice users may be able to pick a UI more familiar to them (ex. Tabbed UI), conservative users may pick their preferred UI (Standard), adventurous users may try out the unique UIs (Groupedbar). 
d) No need to update documentation tailored for the standard toolbar (or at least documentation can be gradually updated for other UIs). Simply include a disclaimer that LibO documentation is tailored only to the standard toolbar.

Option 2 disadvantages:
a) Creating yet another dialog at first start.

As for the alternative UIs being "lightweight Glade assembled UIs" I do not see that as a disadvantage. They provide the same functionality, and if more users are made aware of these UIs, more bug reports will be filled to further improve them, and Glade, which is a win-win situation.

Therefore, my vote goes (in order of preference) is the following:
Vote: Option 2 - provide a dialog at first start for users to select UI.
IF NOT: Option 1 - Changed the default UI in Windows and MacOS installs to the Tabbed UI.

DEFINITELY AGAINST: current situation. Change is needed.
Comment 8 John Mills 2020-08-06 15:52:17 UTC
I sincerely do not want this to be impolite, but pragmatism is fulfilling the wishes of what users want. I understand the attachment to the current user interface as you have a considerable amount of investment in this.

However in my anecdotal experience and reading many threads this is something that is hampering adoption of LibreOffice. 

If it can not be changed on one operating system only then why not consider all? Of course I realise that documentation and development is limited and this would cause disruption. 

There is a feeling that LibreOffice is dated and the UI is an area that is consistently brought up as highlighted by Heiko in this Bug. 

The 'Contextual Single hybrid' may well be the most functional. But if you switch to this you will upset the people who want the current interface to remain default and never please those users that want an Office suite that looks and works similarly to Microsoft Office. 

Yes, it is not identical as you wrote previously but it is close enough that a new user of LibreOffice is not instantly disengaged due to an interface paradigm that came from Xerox park and interface very simmilar to Microsoft Office 2003. I do not deny that the current interface is possibly more 'feature complete' and 'efficient' or any other number of additional descriptions.

However it is not what the majority of people are looking for today in an office suite, and being so opposed to any change does not help with user adoption for LibreOffice.

If anything I believe that LibreOffice market will decline as users switch to applications such as  WPS office, free Office and Softmaker who ship by default with interfaces similar to Microsoft's ribbon that are simpler and more efficient for people, particularly those under 25 to use.

With best regards,

John
Comment 9 Pedro 2020-08-06 15:56:12 UTC
Just want to add: perfection is the enemy of good. Sometimes it's necessary to change things to create scale and accelerate evolution.
Adopting another UI may well be a jolt that brings more development and user focus to LibO.
Comment 10 Pedro 2020-08-06 15:58:07 UTC
Also, I think that not adopting something that is mature enough to be offered to users because it's more "work for the devs" is not a satisfactory reason.
If we're here to avoid bringing something new because it's hard work what's the point?
Comment 11 Dieter 2020-08-06 16:08:59 UTC
The discussion should take into account, that UI of MS Word is not static:

"We’ve been on a multi-year design journey to create more focused, immersive experiences, from the single-line ribbon, to Dark Mode, to Fluent. The next wave of Microsoft 365 UX changes will go even further by fading brand colors from app headers and exploring adaptive commanding. A flexible ribbon that progressively discloses contextually relevant commands at the right time just where you need them." [1]

So the strategy "Let's copy MS Word" will never work.


[1] https://medium.com/microsoft-design/m365future-815cf30a8be
Comment 12 andreas_k 2020-08-06 16:13:46 UTC
From a muffin dev point of view I can say that if LibO change to a notebookbar layout by default, than the LibO message has to be also, that LibO is a community project and not for enterprises.

From a community point of view I would say go for tabbed layout for windows users by default to find devs how will work on Bugfixes for the notebookbar component. I was very conservative when users switch to different UIs cause there is no developer how work on Bugfixes. But after years of waiting that someone will work on Bugfixes, Nobody come to support my work so I also get boring to work on notebookbar.

From an enterprise point of view, LibO should remove all different UIs and make them available as extension.

As LibO is a community project with smart people to do think things, I would say +1000 to have an UI selector after the installation. LibO have to care on the project and not on the enterprise end user.
Comment 13 Telesto 2020-08-06 16:16:40 UTC
@Heiko
> I disagree with the dialog on first start

Please explain why? I find a dialog the ideal compromise (only at first launch; if no setting is present). As it accommodates the toolbar and tabbed bar user, without us having to make a binary choice. There is not good/bad. It are simple different options. Tip of the day is not to obvious, and really easy to click away without reading

I personally like the toolbars, but the default these days is tabbed.
Comment 14 Telesto 2020-08-06 18:00:19 UTC
(In reply to andreas_k from comment #12)
> From an enterprise point of view, LibO should remove all different UIs and
> make them available as extension.

What's the reasoning behind this? I only see different audiences. Not taking in editions. University's who use LibreOffice should use an Enterprise Edition. Which maybe opt for the tabbed menu, as the enduser (students) like them etc.
I don't think the dichotomy between community <-> enterprise being fruitful. 
Company's might have to drop toolbars because every employee being used to tabbed stuff.  

About the extension part; LibreOffice has outdone itself on the variants of the user interface, IMHO. This shows the flexibility. However, it's confusing to choose (from user perspective) and hard to maintain quality of those. There are specific tabbed related issues.

So if there are toolbar & a tabbed bar default and the rest as extension (if technical possible), also fine

>From a community point of view I would say go for tabbed layout for windows users by default

Hard to tell why people are choosing LibreOffice, maybe because of the toolbar :-). I'm surely not to interested in they tabbed stuff. However I do read a lot of complains about LibreOffice looking old & outdated. 
Mostly because of lacking tabbed toolbar, but maybe (also) partly because of theming. Somehow I find they tabbed mode one big gray area. Not nice to look at. For example the tabs are still gray even with theming. And sidebar having different shade of gray. It's aesthetically not 'polished' somehow; can't put my finger on it exactly. It must be possible to make it little more attractive for they eye, without being distracting. [And I have this problem of course only with tabbed interface, not with they regular toolbar]
Comment 15 Roman Kuznetsov 2020-08-06 18:04:16 UTC
(In reply to Heiko Tietze from comment #0)
Question is:
> * Do we want to switch the default from Standard to Tabbed (or any other
> option)

NO!

> Another issue is that we have quite many UI variants and it might confuse
> users. Question here
> * Do we want to remove some UI variants, and if so which?

May be
Comment 16 Rizal Muttaqin 2020-08-06 18:16:02 UTC
(In reply to Dieter from comment #11)
> 
> So the strategy "Let's copy MS Word" will never work.


I tend to disagree. We are all know who is the top dog of the office suite race. LibO is not a clone of MS Office, but in some extent we should look at what familiar with majority of user. Regarding this case, to provide this two idealisms (being not a carbon copy to keep our identity/ability or being conservative or whatsoever reason and also in the same time give familiarity), a startup dialog for choosing UI IS A MUST. Otherwise, we would loose one of our idealism. 

So as we discussed in Telegram, Heiko already working on the UI chooser dialog then we now have choices: 

1. Show user how to access the dialog via Tips of the Day (provide short explqnation and a link to the dialog) 

2. Show another infobar which provide a link to a dedicated website about how to choose UI or may be show the page directly after user launch LibO at first start as Mike Saunder suggested 

3. Show the dialog in the startup (or i.e. in fresh new user profile) as Pedro, Andreas, John and me suggested 

4. Show an extra UI chooser dialog in the installer as we target Windows user only as Italo suggested 

The first choice has a clear question: do user really read ToTD message or even they disable it at first appearance? I have no clue about what majority user do, but me the latest (since I can show it later again via Help > Tips of The Day). May be we need a poll for this case. 

For second choice we should consider user with no Internet connection at all, or may be we can set the page locally? But providing another infobar would make LibO too bloated as we have already add a button for release note link. 

For third choice Pedro already said his comment the pro and cons but at least the neeeded for creating another dialog already in progress. 

For fourth choice we should consider may be in the future this traditional installation method will less relevant as the trend now clearly show many tech giant including MSFT actively suggest the developers two join in software store game.
Comment 17 BogdanB 2020-08-06 18:45:54 UTC
I don't care about Microsoft here, but we already have some interfaces and they are very hard to find by an average Joe. Ubuntu Mate helped my in choosing another look with their Welcome page. The same thing would be usefull for LibreOffice users. First time when this in installed you have the option to choose the user interface you wish. It's a one more screen, but a very important one. Everyone we listen in social media complains about LibreOffice poor design. But we know is not true. But they don't know what we know. 

So, this screen would be the market to meet the request and the offer.
Comment 18 Telesto 2020-08-06 20:44:49 UTC
* Do we want to remove some UI variants, and if so which?
-> They regular Tabbed is the only one I personally would use. So I could do without the rest. If I have to pick 3 for removal from they UI, I would opt for the following:

Groupbar compact
Tabbed compact
Contextual grouped

I also don't see much point in a special sidebar configuration. This can be arranged manually, I think?
Comment 19 Rizal Muttaqin 2020-08-06 22:53:33 UTC
(In reply to Telesto from comment #18)
> * Do we want to remove some UI variants, and if so which?
> -> They regular Tabbed is the only one I personally would use. So I could do
> without the rest. If I have to pick 3 for removal from they UI, I would opt
> for the following:
> 
> Groupbar compact
> Tabbed compact
> Contextual grouped
> 
> I also don't see much point in a special sidebar configuration. This can be
> arranged manually, I think?

There is no need to remove any UI option. We should take into account that some Notebookbar interface are still in experimental mode, so with that case if we enable it, the UI list in the UI chooser dialog should be extended also. Pretty same if we install another NB variant via extension. So, the dialog ideally should be flexible enough in the future.
Comment 20 BogdanB 2020-08-07 05:33:52 UTC
There was a lot of work for each UI variants. They sould be NOT removed.
If still experimental we don't show them in first UI picker, only when Experimental is checked in Options.
Comment 21 John Mills 2020-08-07 08:00:45 UTC
> There was a lot of work for each UI variants. They sould be NOT removed.
> If still experimental we don't show them in first UI picker, only when  Experimental is checked in Options.

That's an interesting question, as you say a lot of effort has gone in to this work and it is a shame if that was lost. Would it make sense that experimental UIs become extensions until deemed to be stable? I think it doesn't make sense to show something that is not considered production ready. Also if you have a selection with anymore choices than 3 or 4 it will just become confusing for the end user.

If I 'understand' the feelings above it would appear to me that there is more agreement for the Tabbed choice from the notebook interface as that would prove to be the most beneficial for users familiar with the Microsoft Office users interface.

My personal opinion would be to switch to this as the default (certainly on Windows)and make it super easy for people to switch back to the standard interface if the end user is not happy with their choice.
Comment 22 andreas_k 2020-08-07 08:08:36 UTC
> That's an interesting question, as you say a lot of effort has gone in to
> this work and it is a shame if that was lost. Would it make sense that
> experimental UIs become extensions until deemed to be stable? I think it
> doesn't make sense to show something that is not considered production
> ready. Also if you have a selection with anymore choices than 3 or 4 it will
> just become confusing for the end user.

That's the reason because they are in experimental. Cause all UI's out of experimental are consistent in all apps. In the past it wasn't possible to offer notebookbar files as extension. Maybe it's now possible. I have to check. But in general I don't care and there will be no other outcome of this discussion.
Comment 23 andreas_k 2020-08-07 08:55:21 UTC
Instead of the discussion about standard toolbar, tabbed toolbar, ... I would go with contextual single layout as default an an dialog on startup.

The reason everybody say LibO is not modern is, cause it's very conservativ. Compare to MSO LibO never change there layout and MSO will change twice.
Comment 24 Heiko Tietze 2020-08-07 09:05:57 UTC
(In reply to Telesto from comment #13)
> @Heiko
> > I disagree with the dialog on first start
> Please explain why?
That's off-topic here, let's discuss on bug 117463.


Caolan, Thorsten: What do you think about default and selection of MUFFIN?
Comment 25 Thorsten Behrens (CIB) 2020-08-07 10:11:03 UTC
(In reply to Heiko Tietze from comment #24)
> 
> Caolan, Thorsten: What do you think about default and selection of MUFFIN?

As said during ESC - generally in favour. Also siding with Caolan, that then we'd want to limit the number of choices to perhaps 2 or 3 max (classic UI, and one or two notebookbar flavours).

How to make this least disruptive for existing users, and at the same time keep help, documentation etc ~up to date is predominantly a UX decision (perhaps with project-wide input).

But broadly, the reason why the project implemented the notebookbar, is to eventually have it as the 1st tier UI. ;)
Comment 26 John Mills 2020-08-07 10:25:38 UTC
I agree with Thorsten here, I see this as an issue of benefit vs loss.

Does changing the default UI benefit LibreOffice in the longer term by bringing new users to the software and hopefully contributors to the project?

Yes / No

If No stop here

If Yes then proceed, but please choose something that would have the maximum benefit to the widest possible audience. 

I draw attention to one of the latest comments in the forum Thread that Heiko linked to earlier:


######################################################

xxPoLyGLoTxx
1 point ·
19 hours ago

A few things:

(1) The speed of LO is significantly better now. It's way snappier than before.

(2) There is still some compatibility stuff when saving as docx. When saving as docx and converting that to PDF, I had a terrible issue last night where the spacing of my footnotes was way off. If I saved as ODT, that issue went away.

(3) The tabbed layout should be the default. Or like someone else said, have a brief setup wizard on the first run to let people choose. I had no idea it even existed and its WAY more intuitive and similar to MS Office layout.
Comment 27 Telesto 2020-08-07 10:40:29 UTC
Off-topic @Jokhn Mills 

(In reply to John Mills from comment #26)
> (2) There is still some compatibility stuff when saving as docx. When saving
> as docx and converting that to PDF, I had a terrible issue last night where
> the spacing of my footnotes was way off. If I saved as ODT, that issue went
> away.
-> There is a bugreport for this?
Comment 28 John Mills 2020-08-07 10:52:53 UTC
@ Telesto : I realise point (1) and (2) are not related to this discussion, I simply copied the whole of the forum posting so an not to be accused of bias. I think it inappropriate to only copy small sections of a comment. 

Clearly point (3) is the relevant point for this discussion.
Comment 29 Pedro 2020-08-07 11:00:35 UTC
(In reply to Thorsten Behrens (CIB) from comment #25)
> (In reply to Heiko Tietze from comment #24)
> > 
> > Caolan, Thorsten: What do you think about default and selection of MUFFIN?
> 
> As said during ESC - generally in favour. Also siding with Caolan, that then
> we'd want to limit the number of choices to perhaps 2 or 3 max (classic UI,
> and one or two notebookbar flavours).
> 
> How to make this least disruptive for existing users, and at the same time
> keep help, documentation etc ~up to date is predominantly a UX decision
> (perhaps with project-wide input).
> 
> But broadly, the reason why the project implemented the notebookbar, is to
> eventually have it as the 1st tier UI. ;)

Since there seems to have been some discussion about this in the ESC meeting about this I would like to remark that 2 or 3 max UIs do not showcase the flexibility of LibO, which is one of the stronger points I would suggest that at least 4 UIs are presented.

I would propose to remove from the old toolbar layouts the Single toolbar layout.
From the Notebookbar layouts I would remove the contextual layouts, and if necessary the Compact layouts.
However, I think the Compact layouts are awesome, so I would keep them and increase UI choice to 6 layouts.
Comment 30 andreas_k 2020-08-07 11:22:45 UTC
This is the bug report for Change the default UI! Bug report for the Dialog is BUG 117463.

-1 for Change the default UI on any operation system. 
+1 for an start dialog (BUG 117463).

Reason is, that we have different icons, different vcl backends, different UI's, ... on different Systems, ... Way to much work for support, documentation, ...

An dialog where the user can choose is fine for me cause than you can inform the user that other UI's are not supportet by documentation, ...
Comment 31 Telesto 2020-08-07 11:38:07 UTC
(In reply to andreas_k from comment #30)
> This is the bug report for Change the default UI! Bug report for the Dialog
> is BUG 117463.
> 
> -1 for Change the default UI on any operation system. 
>1 for Change the default UI on any operation system. 
> 
> Reason is, that we have different icons, different vcl backends, different
> UI's, ... on different Systems, ... Way to much work for support,
> documentation, ...
> 
> An dialog where the user can choose is fine for me cause than you can inform
> the user that other UI's are not supportet by documentation, ...

Fully agree with Andreas

Arguments for a dialog instead of changing the default as such
* There is no good or false here; it's a preference. And switching things doesn't solve the issue. People will ask here has the toolbar gone? Similar to the people who can't find the tabbed interface.
* Different vcl backends, different, UI's, ... on different Systems
* Documentation
* Temporary argument aesthetics; tabbed for must be tweaked a bit to look nice. Common comments: LibreOffice has a 90's look or people don't have feeling for design.

About number of interfaces. Choice is a bit overwhelming; and without preview even harder to grasp. Or there must be dialog which gives a preview of all the options. Which can be accessed manually and is launched automatically at the start if no profile is present.
Comment 32 Timur 2020-08-07 13:53:39 UTC
I'm for options, to let user choose, inform in 1st Tip of the Day. Plus in installer. 
MSO is not a good example to me, rather WPS which has (if I recall well) also tip to choose. 
Not to remove any UI, please stop with that here.
Comment 33 V Stuart Foote 2020-08-07 14:26:27 UTC
@Samuel, I know Thorsten is leaning in favor--but what do you believe as to fitness of any of the NB to become default UI. And, if default were to be moved onto NB then how much remains to be done with the framework?

@Maxim, hey so did Sumit's GSOC 2019 work bring the NB customization far enough for use as a default UI?

And, are we there yet for instrumenting the NB for a11y? Seems not, bug 109425 and bug 107343 are blocking a11y of the NB implementations.
Comment 34 andreas_k 2020-08-07 14:38:27 UTC
(In reply to V Stuart Foote from comment #33)
> @Samuel, I know Thorsten is leaning in favor--but what do you believe as to
> fitness of any of the NB to become default UI. And, if default were to be
> moved onto NB then how much remains to be done with the framework?

In general there was only Szymon and GSOC Student Sumit how worked on the notebookbar codebase. Which is a big issue cause there is no wide code knowledge (I think). 
 
> @Maxim, hey so did Sumit's GSOC 2019 work bring the NB customization far
> enough for use as a default UI?

NB customization is ok but there is bug 132797 which blog my work to finish customization.

> And, are we there yet for instrumenting the NB for a11y? Seems not, bug
> 109425 and bug 107343 are blocking a11y of the NB implementations.

a11y and keyboard navigation and partly extension support are open issues.

Notebookbar implementations are not available for
- Chart 
- Master document
- other sw modules excl. writer
- formular
- base

Another issue someone has to care about new features (uno commands) which has to be added to the different NB layouts.
Comment 35 Luke Kendall 2020-08-07 15:05:25 UTC
- I'd like to propose a new UI element that makes the UI choice visible the user.
E.g. a short coloured bar with the name of the UI style, which they can click on to see the list of available UI styles and choose between them.

- A one-off choice during installation or startup isn't as good as that because the user may not be aware of what choice they're making at that point, and may not know how to alter that choice after that.

- I wasn't aware there were different UI styles to select between.
If the UI suddenly changed to a different style, without my choice, I would be annoyed.
Being able to easily switch between UI styles would remove that annoyance.

- Being able to easily see that there were different styles and switch between them to try them out would encourage me to experiment.

- Accidentally clicking on something that changed the whole UI when I wasn't expecting it would make me panic and try to work out how to undo whatever it was I'd accidentally done.

- I'd like to observe that making features discoverable is a good thing.

- I suggest that for people updating from an already-installed version to a new one, keeping the UI setting to the same as they had is best - especially if they can be told that other options are available for them to try out.

- For people who are installing LO for the first time, I think you're on safer ground to install a UI of a new style that you wish to promote (because you think it's better).

- As for treating MS Office UI as the gold standard, I have a lot of experience in UX and UI design and creation, and when they introduced the Ribbon there was a lot of deserved push back. Even after using it for years, I couldn't see any real improvement it brought. However, with years of use it does become more familiar.

- Having learned from this bug report that alternative UIs exist, it seems a strong UI/UX feature and you could consider making that fact more discoverable through the UI and easier for users to try out and experiment with, which brings me back to my very first point.

(That's my two cents.)
Comment 36 V Stuart Foote 2020-08-07 15:19:56 UTC
(In reply to Luke Kendall from comment #35)
> - I'd like to propose a new UI element that makes the UI choice visible the
> user.

Thanks for posting, but already in place in the UI from <F10> Main menu's View -> User Interface, and additional 'Experimental' MUFFIN are exposed when the Tools -> Options -> Advanced 'Enable experimental features' checkbox is enabled.  

This issue is about what becomes the default. Specifics of additional UI for setting/selecting alternate UIs, and when, are in see also bug 117463
Comment 37 Caolán McNamara 2020-08-07 15:25:37 UTC
I'd hate to see a dialog presented to the user on first start to pick their user-interface, that just seems horrible, like that terrible "pick your default browser as a feeble workaround for an anti-competitive ruling" windows has/had.

I think there are too many "user interface" options. Leaving aside the experimental options, we have in the user interface menu in the muffin section "tabbed, tabbed compact, groupedbar compact, "contextual single" and I have no real feeling for what the difference is between them all. It feels indecisive, as if it's uncertain which one is the right design. IMO, pick one, drop the others and then its a clearer decision as what the option between current and proposed ui would entail.
Comment 38 Luke Kendall 2020-08-07 15:34:45 UTC
Being buried inside the UI and only reachable/discoverable via

"from <F10> Main menu's View -> User Interface, and additional 'Experimental' MUFFIN are exposed when the Tools -> Options -> Advanced 'Enable experimental features' checkbox is enabled."

is kind of the opposite of what I was proposing. 

I proposed making the UI style a visible indicator and widget on the UI so it is always visible: so the user can easily see what it is currently set to, and choose between alternatives.

If it's hidden away then you have all sorts of negative user experiences and consequences of changing it, or changing the default.

I also believe there's a big difference in choosing a new default for fresh LO installations (new users) and changing the UI style for an existing LO user.

E.g. the Unity UI of Ubuntu may not have turned into the big argument it did if there had been an easy way for users to try it out at their choice: to switch back and forth at any time.

I also hold the strongly opposing view to comment 37. The idea that one UI is the best choice for everyone, or that one person can choose between UI alternatives, ignores the fact that there is usually a wide range of contexts that users operate in and backgrounds they come from, as well as hand-eye-coordination, workflows, and so on.  So I strongly feel that choice offers flexibility and configurability, and does not need to be a mark of indecision (although it CAN be, that's true).

I'll say no more.
Comment 39 andreas_k 2020-08-07 15:46:28 UTC
I have some questions

1. Why Szymon Work on notebookbar implementation? What was the goal?

2. What is the best workflow for an office suite? Menubar + toolbars, tabbed bars, sidebar?

3. Why LibO development toolbars, sidebars, tabbed bars, ... But didn't change layout since 2 decades?

4. Why people say LibO is outdated?

5. MSO change from menubar + toolbars to menubar + ribbons to ribbons to simply died ribbons and the previews show something context related toolbars + search

LibreOffice is a community project where different members do different stuff. Out users are also individuals for me the diversity in the project is one big difference compare to unified MSO.
Comment 40 andreas_k 2020-08-07 15:53:30 UTC
https://www.collaboraoffice.com/press-releases/collabora-office-6-4-released/

Colabora office show in there 6.4 announcement 6 schreenshots. One use the standard toolbars layout. Even marketing like diversity.
Comment 41 Maxim Monastirsky 2020-08-07 16:01:09 UTC
(In reply to V Stuart Foote from comment #33)
> @Maxim, hey so did Sumit's GSOC 2019 work bring the NB customization far
> enough for use as a default UI?
Currently customization is very basic: Just show/hide individual items; still no way to add other commands. And there are serious problems caused by the fact that the customization is stored in the user profile using the glade ui format, see comments in Bug 132797 and Bug 135495. But I don't think that a working customization should be a blocker for some UI to become the default.

What I really missing from this discussion are *facts*. A major change like this shouldn't be done without a serious study. We should collect feedback from users who really tried to use the other UI variants on a daily basis, and take a decision based on that. So arguments like "ribbon is the default on windows, therefore we should use it too" don't count. When we set something as default, we should be confident that at least it will allow users to get their job done.
Comment 42 Dieter 2020-08-07 16:06:03 UTC
(In reply to Maxim Monastirsky from comment #41)
> What I really missing from this discussion are *facts*. A major change like
> this shouldn't be done without a serious study. We should collect feedback
> from users who really tried to use the other UI variants on a daily basis,
> and take a decision based on that.

+1 - I totally agree.
Comment 43 andreas_k 2020-08-07 16:18:41 UTC
(In reply to Dieter from comment #42)
> (In reply to Maxim Monastirsky from comment #41)
> > What I really missing from this discussion are *facts*. A major change like
> > this shouldn't be done without a serious study. We should collect feedback
> > from users who really tried to use the other UI variants on a daily basis,
> > and take a decision based on that.
> 
> +1 - I totally agree.

Great Idea. As LibO has no telemetry data, let's release a LibreOffice version with tabbed UI and see which one will be downloaded.
Comment 44 V Stuart Foote 2020-08-07 17:04:12 UTC
(In reply to andreas_k from comment #43)
 
> Great Idea. As LibO has no telemetry data, let's release a LibreOffice
> version with tabbed UI and see which one will be downloaded.

;-) 

But actually we can collect (Tender'd 2015) disabled by default:

Tools -> Options -> General 'Collect usage data and send it to The Document Foundation'; and I'm not asking folks to turn it on.

But that is a different issue.  A split configuration release would be a logistical/infra nightmare. Just no...
Comment 45 andreas_k 2020-08-07 17:25:41 UTC
It was more a joke to offer two downloads but an discover LibreOffice hint for the different layout after the download page would be nice.
Comment 46 Telesto 2020-08-07 18:56:35 UTC
(In reply to Caolán McNamara from comment #37)
> I'd hate to see a dialog presented to the user on first start to pick their
> user-interface, that just seems horrible, like that terrible "pick your
> default browser as a feeble workaround for an anti-competitive ruling"
> windows has/had.

You’ve a point here. It's bit nagging. And not to decisive either. If you follow the masses, maybe they tabbed one by default. It might be people are used to re-configuring as the tabbed interface is forced on them quite often anyhow (go with the flow)

However their is still they issue of all the environments where LibreOffice is running. Will this be a change across the board? Or Windows/MacOS only? Splitting it up can be itself seen as indecisive. It also will cause multiple screenshots flying around with different default interfaces.

> I think there are too many "user interface" options. Leaving aside the
> experimental options, we have in the user interface menu in the muffin
> section "tabbed, tabbed compact, groupedbar compact, "contextual single" and
> I have no real feeling for what the difference is between them all. It feels
> indecisive, as if it's uncertain which one is the right design. IMO, pick
> one, drop the others and then its a clearer decision as what the option
> between current and proposed ui would entail.

I agree. And most users tend to stick with the default (I assume). It are all variants of the same thing, IMHO. From QA perspective I  prefer not to many options; probably the same is valid for  documentation for example a11 
 
Ideally the alternatives should be delivered as extension. Or if not possible buried in the theming dialog or even Expert configuration. This would allow backward comp-ability and there would be a test if people are actually missing those (if there are complains about where did they.. interface go)

(In reply to Maxim Monastirsky from comment #41)
> What I really missing from this discussion are *facts*. A major change like
> this shouldn't be done without a serious study. We should collect feedback
> from users who really tried to use the other UI variants on a daily basis,
> and take a decision based on that. So arguments like "ribbon is the default
> on windows, therefore we should use it too" don't count. When we set
> something as default, we should be confident that at least it will allow
> users to get their job done.

Such a study is time consuming and expensive. And results will be hard to asses. I assume Microsoft did spend some money on research on the acceptance of the ribbon or the start menu of "Windows 8'. They transition did have some bumps and there were some tweaks.. but the didn't go back to before.

There are people who love the Ribbon others hate it. I assume the competitors did make the decision to use the ‘ribbon’ on purpose.  All of them made the ‘Ribbon’ default, with an option of a toolbar. Not that follow the herd necessary is the wise thing to do. OTOH, they toolbar aren’t gone either. It’s a few clicks away. 

The existing user base you can reach (in theory). I still love some kind of info bar which makes users aware of poll using the same system as the automatic update check. So they can participate once in a while. [But that’s only a thought of mine]. However such poll only reaches the existing user base. Still not the potential user base. Maybe the potentials ignore LibreOffice because it lacks a ‘ribbon’ interface (or because the experience isn't the ‘same’ thing).  

I personally find the current ‘tabbed’ edition aesthetically not that nice to look. And it doesn’t get better with theme. 
They issues already known should be fix upfront. Instead of pushing something which isn’t finished. Especially something so noticeable :-). Not that ever will be finished, can still be tweaked, need feedback (users) for that. 

Maybe enable it by default in Master and until 7.1 RC1 and decide at RC2/3 what to do based feedback/comments etc. 

----
(In reply to V Stuart Foote from comment #44
But actually we can collect (Tender'd 2015) disabled by default:

Tools -> Options -> General 'Collect usage data and send it to The Document Foundation'; and I'm not asking folks to turn it on.

I'm not really against telemetry (as such) if it helps improve LibreOffice. However
1) Telemetry shouldn’t start registering without explicit consent. As separated question. Not checked by default etc or buried along with other questions
2) I want a full disclosure which kind of data is collected (openness)
3) I want to be able to see what’s will be send in advance (openness)
4) I want a to be informed every time telemetry data will be exchanged (control). Being aware it happens
5) I want to see some kind of statistics derived for that data (results). 
6) Some idea how it is can be used to improve things. And actually being used. Else it’s pointless exercise
Comment 47 John Mills 2020-08-07 20:25:17 UTC
Hi Telesto,

You make some very interesting points, I just wanted to pick up on one of them regarding the 'Ribbon' interface. 

> I assume Microsoft did spend some money on research on the acceptance of the ribbon or the start menu of "Windows 8'. They transition did have some bumps and there were some tweaks.. but the didn't go back to before.

Microsoft spent a huge amount of time, money and effort when designing this interface. I think you will see this if you watch a little of the design philosophy that went in to this and the effort undertaken. It certainly wasn't just thrown together. 

https://channel9.msdn.com/Events/MIX/MIX08/UX09

I know it is fashionable in some segments of the FLOSS community to hate on Microsoft, I understand, embrace, extend and extinguish but what people can't do is call their Office suite garbage. It isn't. There is a reason why it is used by over 90% of Office users worldwide. It is good, very good.

I encourage you to spend a little time, and anyone else reading this, just to watch a little and understand some of the thought and design process that went in to Microsoft Office 2007. 

I understand the objections to telemetry but look in that video just how useful it can be when making decisions.
Comment 48 V Stuart Foote 2020-08-07 21:10:24 UTC
(In reply to John Mills from comment #47)

> > I assume Microsoft did spend some money on research on the acceptance of the ribbon or the start menu of "Windows 8'. They transition did have some bumps and there were some tweaks.. but the didn't go back to before.
> 
> Microsoft spent a huge amount of time, money and effort when designing this
> interface. I think you will see this if you watch a little of the design
> philosophy that went in to this and the effort undertaken. It certainly
> wasn't just thrown together. 
> 

And all of that is absolutely irrelevant as LibreOffice makes *no* use of the Ribbon framework API, which yes is a very rich library. In fact if anything from a UX perspective it is a very strong argument to *not* use the NB Tabbed UI as naive users expecting fully implemented API will be confused/disappointed with the functionality our Glade UI assemblages of UNO controls provide.

I'd anticipate a flood of user requests for 'why doesn't it work like in MSO'...
Comment 49 John Mills 2020-08-07 21:42:48 UTC
Thank you Stuart for a reasoned response,

It is relevant, because the Tabbed interface is functionally similar. If it is not why was it created? It is an approximation that uses a similar design metaphor.

If you look at some of the sources that are linked to this bug request you will see that people are asking for this type of interface, or at least a choice in how they interact with LibreOffice from a UI perspective.

You mention API compatibility and I am certainly not expert enough to disagree. However, there is a UI that ships in LibreOffice that many people do not know about and once informed choose to use because it is similar to the interface that greater than 90% of Office users interact with worldwide and has existed for 14 years now, once informed of the existence many believe that they are more productive than the current shipping interface and it suits their personal needs better. 

I think no one expects LibreOffice and Microsoft Office to be functionally and aesthetically identical. Having an interface that works similarly like Microsoft Office (tabbed) is not a sin, WPS, FreeOffice, OnlyOffice and Softmaker to only name four suites that have adopted similar user interfaces.

With best regards
Comment 50 Sascha Z 2020-08-08 10:27:00 UTC
It seems to be a sensitive subject with many different opinions. 
Should we add time for it in the next UX meeting?
Comment 51 Maxim Monastirsky 2020-08-09 13:28:52 UTC
(In reply to Heiko Tietze from comment #0)
> * Do we want to remove some UI variants, and if so which?
At least the non-NB single toolbar mode can be removed, see comments in Bug 125040. Also in Bug 124835 there was a discussion about how the sidebar mode is supposed to work, and I think that might be a candidate for removal too. As for the other NB variants, we don't have to remove anything right now, as we can just move some under experimental.

One more thing that I would like to point out is that "tabbed compact" isn't really a different design, rather just a variation of "tabbed" made as a single line of buttons, to save some vertical space. So even if we decide to go with "tabbed", it still might make sense to keep also "tabbed compact". And especially as our notebookbar can't be collapsed, unlike MS Office's ribbon.

(In reply to Telesto from comment #46)
> (In reply to Maxim Monastirsky from comment #41)
> > What I really missing from this discussion are *facts*. A major change like
> > this shouldn't be done without a serious study. We should collect feedback
> > from users who really tried to use the other UI variants on a daily basis,
> > and take a decision based on that. So arguments like "ribbon is the default
> > on windows, therefore we should use it too" don't count. When we set
> > something as default, we should be confident that at least it will allow
> > users to get their job done.
> 
> Such a study is time consuming and expensive. And results will be hard to
> asses. I assume Microsoft did spend some money on research on the acceptance
> of the ribbon or the start menu of "Windows 8'. They transition did have
> some bumps and there were some tweaks.. but the didn't go back to before.
I didn't actually mean a study about the acceptance of a ribbon as a concept. This is well known that some people don't like ribbons. What I meant was to gather feedback from users who are willing to use such interface, and actually tried to use *our implementation* on a daily basis. My goal is to try to find out if there are any major flaws/bugs, that might be serious enough to become blockers for the default UI switch. And telemetry won't help here, because it can only tell how many people clicked on the tabbed UI menu item, but not what issued did they have with that interface, and whether they continued to use the interface despite those issues, or just gave up and switched back to the classic one.
Comment 52 Telesto 2020-08-09 14:36:54 UTC
(In reply to Maxim Monastirsky from comment #51)
> I didn't actually mean a study about the acceptance of a ribbon as a
> concept. This is well known that some people don't like ribbons. What I
> meant was to gather feedback from users who are willing to use such
> interface, and actually tried to use *our implementation* on a daily basis.
> My goal is to try to find out if there are any major flaws/bugs, that might
> be serious enough to become blockers for the default UI switch. And
> telemetry won't help here, because it can only tell how many people clicked
> on the tabbed UI menu item, but not what issued did they have with that
> interface, and whether they continued to use the interface despite those
> issues, or just gave up and switched back to the classic one.

You surely don't get feedback, until this it's default :-). It's hard to come into contact with people who do use it regularly, IMHO. 

I'm happy to test it tabbed mode. I personally see some issues in the aesthetic area which should be solved before a switch should be made (more or less theming related).. but should possible within 5 months; 

IMHO I still thing we simple set 7.1 to Tabbed to gather some feedback, and decide around RC1/2. I have seen much more problematic stuff pushed to release builds without being properly tested. In this case you easily switch to toolbar edition. So even if there is some dysfunctions, there is always a fall back

--- 
(In reply to V Stuart Foote from comment #6)
> No this is pragmatic--the MUFFIN Tabbed NB only looks like the MS Ribbon UI
> it does not implement that API.

I'm not all know in feature richness of the Ribbon interface. So what are you exactly pointing too? Live Preview? Or also other things?
Comment 53 V Stuart Foote 2020-08-09 18:56:50 UTC
(In reply to Telesto from comment #52)

> (In reply to V Stuart Foote from comment #6)
> > No this is pragmatic--the MUFFIN Tabbed NB only looks like the MS Ribbon UI
> > it does not implement that API.
> 
> I'm not all know in feature richness of the Ribbon interface. So what are
> you exactly pointing too? Live Preview? Or also other things?

Have a look, the MS Ribbon Class [1] is fully implemented API for GUI development in source (or for user scripted GUI customization). Every facet of the MS Ribbon UI is directly programmable for UWP or DWM use, and then integrates well with other MS Windows controls.

The MUFFIN Notebook Bar framework is limited by the controls, attributes and actions available implemented as UNO applets. UNO controls can not be manipulated like Ribbon Class object and any functional similarity is skin deep. They are not implemented as 'native' Windows (UWP/DWM) and so won't function like them--though naive users will expect them to.  Why expose the Windows users to that disappointment--and cause a lot of grief to the project otherwise when those users say they "expect" it.

Rather than wasting project resources on changing default and dealing with long running support requests, IMHO much more appealing to fix other facets of the GUI (e.g. Dark Mode support). And then implement new useful document modes for the Libreoffice GUI handling of ODF, e.g. Tabbed (bug 33173) or Multi-document (bug 37134) 

=-ref-=
[1] https://docs.microsoft.com/en-us/dotnet/api/system.windows.controls.ribbon.ribbon?view=netframework-4.8
Comment 54 Telesto 2020-08-09 19:42:10 UTC
(In reply to V Stuart Foote from comment #53)
> (In reply to Telesto from comment #52)
> 
> > (In reply to V Stuart Foote from comment #6)
> > > No this is pragmatic--the MUFFIN Tabbed NB only looks like the MS Ribbon UI
> > > it does not implement that API.
> > 
> > I'm not all know in feature richness of the Ribbon interface. So what are
> > you exactly pointing too? Live Preview? Or also other things?
> 
> Have a look, the MS Ribbon Class [1] is fully implemented API for GUI
> development in source (or for user scripted GUI customization). Every facet
> of the MS Ribbon UI is directly programmable for UWP or DWM use, and then
> integrates well with other MS Windows controls.

If with they tabbed bar certain unrealistic expectations are raised automatically, it might be a problem. OTOH, if people dislike simply they the UI it would solve a problem. And this is delivered by the beloved competitors too (excluding MS Office). Do the competitors have real Ribbon, Or are those also superficial imitations (Didnt' check) And I really don't know what people look for.. a similar layout or similar functioning. There must be quite a group who doesn't use the 'advanced' programmable stuff. They only want something what they have seen before

And there is quite some time spend on all those interfaces already :-). So my impression is that not so many resources are needed to finalize it; being a tabbed toolbar (not Ribbon). Without the intention of becoming a Ribbon in the short or mid term. 

I do know that some people are complaining about 'LibreOffice' looking like they '90's. And this might cause the impression of LibreOffice being dated. Not sure how large the whole group is assessing it this way.

However there surely a need to prevent the wrong expectations arising (expectation management). This can partly be solved by some additional lines in the Release notes explaining... 

But sure, there are many sides to this. If opted for tabbed, it really should be over the full line.. So including Linux (on any environment). If Linux distro's want to tweak it, fine.. but the TDF release should be the same for all environments.. (Screenshot on the internet and documentation etc)..

Pre-requisite are surely a11y support, nice aesthetics and proper documentation, IMHO. And it should be more or less bug free of course.

Fortunately it's not up to me ;-). It's surely not simple yes/no answer. There a pro/cons.   My wish list (or should I say reported bug list/regression list) is pretty long. I would love (some of) those being fixed.. Even before new features are added. 

Anyhow I see no objection for a (temporal) experiment on Master and/or Beta 1 and 2 and maybe one or 2 RC's. Simple to see what happens..
Comment 55 John Mills 2020-08-09 20:39:46 UTC
>The MUFFIN Notebook Bar framework is limited by the controls, attributes and actions available implemented as UNO applets. 
>UNO controls can not be manipulated like Ribbon Class object and any functional similarity is skin deep. They are not implemented as 'native' Windows >(UWP/DWM)and so won't function like them--though naive users will expect them to.  Why expose the Windows users to that disappointment--and cause a lot of grief to the project otherwise when those users say they "expect" it.

Hi Stuart,

I'm not sure if you would have any knowledge on this but it is an interesting question to ponder.            

Do you know if WPS Office is directly programmable for UWP and DWM use on Windows? And does it also integrates well with other Windows controls? If it doesn't then does that hamper the use of the application by 'naive' Windows users who know no better?

If it does use these interfaces then do the users of WPS office on MacOS have a poorer user experience than their Windows counterparts? Do the users on Linux also? 

Do they contact the publisher to report their poorer experience? Are they unable to accomplish their office tasks because of this?

I can ask the same question for:

SoftmakerOffice

Polaris Office

FreeOffice

OnlyOffice (Desktop client)


And a number of Chinese office suites I have forgotten the name of, I'm sure there are others also.

Do users of Microsoft Office on Mac also have these issues because they lack of these essential functions? Do users of Microsoft Office 365 web client have this poor user experience are they frustrated and unable to accomplish their tasks?


>Rather than wasting project resources on changing default and dealing with long running support requests, IMHO much more appealing to fix other facets of the GUI (e.g. Dark Mode support). 
>And then implement new useful document modes for the Libreoffice GUI handling of ODF, e.g. Tabbed (bug 33173) or Multi-document (bug 37134) 

Does the possibility of switching to another user interface such as Tabbed preclude these improvements taking place? Can we only have one of the other? 

Is it not possible to use a dark mode with notebook bar interfaces? Does the architecture of the Notebook bar solutions preclude this? Maybe it's only a Linux thing but I'm sure that it is possibility to have a dark interface with LibreOffice under Ubuntu. 

If LibreOffice intended to include document tabs would it not be possible also in one of the notebook bar interfaces? This can only be accomplished in the current shipping interface?

Kind regards
Comment 56 V Stuart Foote 2020-08-09 23:10:37 UTC
(In reply to John Mills from comment #55)
Well as most of those questions are obviously rhetorical--I won't bother.

Suffice to say that as demonstrated by this UX-advise BZ issue--user expectations often may diverge from practical considerations of what is in the best interest of LibreOffice as an ODF-centric cross-platform Office program.

Changing the default "standard" UI to the current MUFFIN NB implementation of a Tabbed UI would have little practical advantage (appearance or function), with potential for substantial regression in UX over our Toolbar/Menu/Dialog UI.

Ill-advised on all counts...
Comment 57 Sascha Z 2020-08-10 00:35:16 UTC
(In reply to V Stuart Foote from comment #56)

> Suffice to say that as demonstrated by this UX-advise BZ issue--user
> expectations often may diverge from practical considerations of what is in
> the best interest of LibreOffice as an ODF-centric cross-platform Office
> program.

No, I disagree for the fact that LibreOffice should always work in the best interest of its user expectations. Not vice versa! With only one difference in the amount of users. Meaning a single user might be wrong, a group of users might still be asking for changes disregarded by the majority, while the majority of users is the one and only angle to focus on.

Only problem - we can't gather enough informations what the majority of users is using. Or would like to use if they know it does exists. So what do you suggest: a Tip of the day or a user choice during first start-up?
Comment 58 Pedro 2020-08-10 09:44:38 UTC
(In reply to Caolán McNamara from comment #37)
> I'd hate to see a dialog presented to the user on first start to pick their
> user-interface, that just seems horrible, like that terrible "pick your
> default browser as a feeble workaround for an anti-competitive ruling"
> windows has/had.

That's a matter of personal preference. IMO, that's a very simple way of highlighting the choices for the end user. I think it's very positive, and in that Windows case it even helped less known options to become more well-known by end users. Such as it happened on Android when a browser and search engine picker were shown to users. This helped less known, and more user-privacy focused engines to become known and gain users. Which are all positive points. Opera, Brave, Firefox gained a lot from that. Qwant, Duckduckgo as well.

> I think there are too many "user interface" options. Leaving aside the
> experimental options, we have in the user interface menu in the muffin
> section "tabbed, tabbed compact, groupedbar compact, "contextual single" and
> I have no real feeling for what the difference is between them all. It feels
> indecisive, as if it's uncertain which one is the right design. IMO, pick
> one, drop the others and then its a clearer decision as what the option
> between current and proposed ui would entail.

Those issues are something that must be worked on when making a dialog: what are the purposes of the UIs, and present that purpose in a clear manner.
We can overcome that feeling of undecisiveness with a well-crafted dialog and clear descriptions/tooltips on hover.
Each UI that was designed had a clear purpose in mind:

- The Tabbed UI is for users looking for something like the Ribbon UI, but with refinements that address the weak points of it, namely the fact that it is more compact to steal less vertical space.

- The Groupedbar is the Toolbar UI 2.0: an innovative UI that combines commands and menus in related groups with the most used commands visible and the drop-down menus showing the other commands on that group instead of a standard toolbar where there's no connection between the toolbar items and the menus.

A discussion to be had that I think is important: what to do with compact UIs. Those are responsible for the multiplication of UI options. If we want to decrease the number of options in a consistent manner I would consider "hiding" these ones. They're the Single Toolbar, the Tabbed Compact, the Groupedbar Compact.
I would suggest to have a checkbox in a dialog "use compact UI". Then the user could select the UI of its preference, click the checkbox and the compact UI would be selected.
This would narrow down the number of visible options to 4:
1 - Toolbar, (mention in tooltip this is the UI with documentation)
2 - Sidebar,
3 - Tabbed,
4 - Groupedbar.
Comment 59 Pedro 2020-08-10 10:19:12 UTC
Created attachment 164096 [details]
A dialog picker rough mock-up

An example of what a dialog with UI selection could look like, with 4 UI options and a check-box to select the corresponding "compact" versions.
Comment 60 Pedro 2020-08-10 10:35:53 UTC
That mock-up is just a visual way of showing what I believe are the essential elements that such a dialog should have:
1 - 4 UIs to select from, 
2 - a checkbox for users to select the compact UIs (single toolbar, Tabbed Compact, Groupedbar Compact),
3 - Tooltips that show on hover with a short description of each UI.
Comment 61 Dieter 2020-08-10 10:55:52 UTC
(In reply to Pedro from comment #60)
> 2 - a checkbox for users to select the compact UIs (single toolbar, Tabbed
> Compact, Groupedbar Compact),

It wasn't clear to me, that checkbox refers to all UIs. I thought, it is only for single toolbar. Dialog should make it more clear. In general I like your dialog (perhaps I would skip sidebar option).
Comment 62 Samuel Mehrbrodt (CIB) 2020-08-11 06:53:16 UTC
(In reply to V Stuart Foote from comment #33)
> @Samuel, I know Thorsten is leaning in favor--but what do you believe as to
> fitness of any of the NB to become default UI. And, if default were to be
> moved onto NB then how much remains to be done with the framework?

I do think that one variant of those can become the default UI (probably the tabbed one).
But before that can happen we need to have
* proper customization support (not what we have now which *copies* the whole UI file to the user profile (which causes issues like bug 135495)).
* proper extension support (Extensions must be able to register new buttons in existing Notebookbars and also register new tabs with their own layout)
(* support for Notebookbar in all LO apps)

And I still do believe (as I did from the start) that the Glade format is not suitable for Notebookbar. We need some stable format which extension authors can also use. Which will allow proper customization and proper extension support.

Jay did some proposal for such a format at some point: https://docs.google.com/document/d/1vabkHLibXBXY8SSDJ6aa17VOoVYoCNZdPBttrv9aOFU/edit#heading=h.5p67h0et36mp

And yes, we need to limit ourselves to one variant of Notebookbar.
It is already a burden for extension authors to adapt their extensions to a new UI.
We can't expect them to support 4 or 5 different Toolbar/Notebookbar systems. This will give us problems like "why does this extension work in Notebookbar variant X, but not in variant Y"?

So my proposal is to focus on one variant and make it a proper and worthy alternative to the current toolbar system.
Comment 63 Rizal Muttaqin 2020-08-11 07:56:57 UTC
(In reply to Samuel Mehrbrodt (CIB) from comment #62)
> (In reply to V Stuart Foote from comment #33)
> > @Samuel, I know Thorsten is leaning in favor--but what do you believe as to
> > fitness of any of the NB to become default UI. And, if default were to be
> > moved onto NB then how much remains to be done with the framework?
> 
> I do think that one variant of those can become the default UI (probably the
> tabbed one).
> But before that can happen we need to have
> * proper customization support (not what we have now which *copies* the
> whole UI file to the user profile (which causes issues like bug 135495)).
> * proper extension support (Extensions must be able to register new buttons
> in existing Notebookbars and also register new tabs with their own layout)
> (* support for Notebookbar in all LO apps)
> 


For me it's strange if we demand this two after we set the interface (in this case Tabbed UI) out of experimental. To my mind taking out something from experimental mode do have mean that the feature is considerably stable and get ready for user and third party developer to work on.
Comment 64 Samuel Mehrbrodt (CIB) 2020-08-11 09:10:06 UTC
(In reply to Rizal Muttaqin from comment #63)
> (In reply to Samuel Mehrbrodt (CIB) from comment #62)
> > (In reply to V Stuart Foote from comment #33)
> > > @Samuel, I know Thorsten is leaning in favor--but what do you believe as to
> > > fitness of any of the NB to become default UI. And, if default were to be
> > > moved onto NB then how much remains to be done with the framework?
> > 
> > I do think that one variant of those can become the default UI (probably the
> > tabbed one).
> > But before that can happen we need to have
> > * proper customization support (not what we have now which *copies* the
> > whole UI file to the user profile (which causes issues like bug 135495)).
> > * proper extension support (Extensions must be able to register new buttons
> > in existing Notebookbars and also register new tabs with their own layout)
> > (* support for Notebookbar in all LO apps)
> > 
> 
> 
> For me it's strange if we demand this two after we set the interface (in
> this case Tabbed UI) out of experimental. To my mind taking out something
> from experimental mode do have mean that the feature is considerably stable
> and get ready for user and third party developer to work on.

Agree. But obviously opinions on that differ. And in no way I'm "demanding" this. I'm just stating my opinion because I was asked to.
Comment 65 Pedro 2020-08-11 10:37:48 UTC
(In reply to Samuel Mehrbrodt (CIB) from comment #62)
> (In reply to V Stuart Foote from comment #33)
> > @Samuel, I know Thorsten is leaning in favor--but what do you believe as to
> > fitness of any of the NB to become default UI. And, if default were to be
> > moved onto NB then how much remains to be done with the framework?
> 
> I do think that one variant of those can become the default UI (probably the
> tabbed one).
> But before that can happen we need to have
> * proper customization support (not what we have now which *copies* the
> whole UI file to the user profile (which causes issues like bug 135495)).
> * proper extension support (Extensions must be able to register new buttons
> in existing Notebookbars and also register new tabs with their own layout)
> (* support for Notebookbar in all LO apps)
> 
> And I still do believe (as I did from the start) that the Glade format is
> not suitable for Notebookbar. We need some stable format which extension
> authors can also use. Which will allow proper customization and proper
> extension support.
> 
> Jay did some proposal for such a format at some point:
> https://docs.google.com/document/d/
> 1vabkHLibXBXY8SSDJ6aa17VOoVYoCNZdPBttrv9aOFU/edit#heading=h.5p67h0et36mp
> 
> And yes, we need to limit ourselves to one variant of Notebookbar.
> It is already a burden for extension authors to adapt their extensions to a
> new UI.
> We can't expect them to support 4 or 5 different Toolbar/Notebookbar
> systems. This will give us problems like "why does this extension work in
> Notebookbar variant X, but not in variant Y"?


Just some information: the extension authors don't have to worry about supporting 4 or 5 different toolbar/notebookbar systems. As it is currently working they just need to add Notebookbar support and the layout is defined by the Notebookbars. It is working quite well, and if you wish I can provide screenshots demonstrating extensions with Notebookbar support in the different Notebookbar UIs.

> So my proposal is to focus on one variant and make it a proper and worthy
> alternative to the current toolbar system.

As for the focusing solely on one variant: that discussion has already sailed. There's no need to focus solely on one, we already focused and developed multiple variants because they are stable, mature and well developed. That's not the problem.
But I do agree that we should not change the default UI from the toolbar without fixing the other issues with the Notebookbar. Hence, I believe that a UI dialog should be offered for the user to select the UI at first start with the indication that the toolbar is the only UI with documentation.
Comment 66 Telesto 2020-08-25 07:19:15 UTC
FWIW: Stumbled on https://www.dedoimedo.com/computers/libreoffice-7-review.html (see bug 136082). Also complaining about to many interfaces
Comment 67 Heiko Tietze 2020-09-24 09:49:27 UTC
Many thanks for the thorough discussion considering the various aspects of the topic. Here is my executive summary (top) based on what I extracted from the thread (below).

* NBs are not fully functional and perform below ribbons
* Chicken/Egg: to get feedback we have to switch
* Tabbed might be the most familiar, Contextual Single the most complete
* UI picker is welcome (though it just makes the selection a bit easier)
* NB variants showcase our self-concept to be as flexible as possible
* Removing single toolbar and tabbed compact is broadly accepted


Default: 
* Tabbed UI
  + most familiar UI for Windows user (John c2,8)
  + "as community project for individuals" (Andreas, c12)
  + general agreememt, me too (John c21)
* Standard TB
  + pragmatic solution since MUFFIN is incomplete (Stuart c3,6,53,56)
    + no need to be perfect (Pedro)
    + users' expectation is ribbon (John)
    + don't copy MSO is continously developing (Dieter c11)
      + familiar UI is not copying (Rizal c16)
    + users expect fully implemented ribbons (Stuart c48)
  + keep standard (Roman c15, Andreas c30)
  + keep until we have evidence that users benefit (Maxim c41, Dieter c42)
    + switch to get feedback (Telesto c52, Pedro ?)
* UI Picker
  + provide a UI picker on first start (Pedro c7, Andreas c30, Telesto c31, Luke c35)
    + not forced at first start to have a clean start for long-term/expert users (Heiko re: c13, Caolan c37, Telesto c46)
    + basically yes with pro and cons about the details (Rizal, c16)
  + show off what you have (Bogdan)  
* Contextual single
  + most functional (Stuart c6)
  + conservative choice, not copying MSO (Andreas c23)

Selection:
* drop all UI variants (Andreas, c12) 
  + provide variants as extensions
  + "if we develop for professional use"
* remove some (Roman c15, Thorsten c25, Caolan c37)
* clean-up and keep Groupbar-, Tabbed-, Contextual grouped (Telesto c18)
* keep all
  + picker makes it easy (Rizal c19, Timur c32, Luke c35)
  + implementation was some effort (Bogdan c20)
* remove single toolbar (Pedro c29, Maxim c51)
* remove sidebar, tabbed compact (Maxim c51)
* remove contextual layouts (Pedro c29)
  + having alternatives is a showcase for our flexibility
Comment 68 John Mills 2020-09-24 15:59:02 UTC
Hi Heiko,

I think that is a very fair and balanced overview from my perspective, I agree with this summary that you have created.

Kind regards,

John
Comment 69 Telesto 2020-09-25 12:25:22 UTC
I agree with the summary. Only want to add that if Tabbed variant gets more prominent (or default, or picker), it should be made sure they quality matches toolbar settings more or less (so including accessibility and such). Which a see as pre-requirement. Dislike pushing something which doesn't meet (user) expectations. It's a rather prominent dialog. 

Yes, there will always be some remaining lose ends (unknown/unexpected bugs). However should pass the basic testing protocol.
Comment 70 John Mills 2020-09-26 12:12:42 UTC
Hello all,

I don't know if this has any bearing on the desktop client for LibreOffice but it appears that Collabora will be moving their online edition to use the tabbed interface by default starting at version 6.4.

https://9to5linux.com/collabora-online-development-edition-6-4-office-suite-gets-a-fresh-look-many-improvements

https://www.collaboraoffice.com/press-releases/code-6-4-0-release/


I'm not sure if the desktop client will also move in this direction? However I wouldn't be surprised for consistency between the two products. Perhaps someone who is a recipient to this Bug report could comment on this?

Kind regards