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?
(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/
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.
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
s/Toolbar & Dialog/Toolbar, Menu & Dialog/
The force of conservatism vs pragmatism and user adoption/growing the LibreOffice ecosystem.
(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.
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.
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
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.
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?
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
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.
@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.
(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]
(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
(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.
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.
* 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?
(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.
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.
> 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.
> 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.
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.
(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?
(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. ;)
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.
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?
@ 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.
(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.
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, ...
(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.
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.
@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.
(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.
- 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.)
(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
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.
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.
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.
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.
(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.
(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.
(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.
(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...
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.
(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
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.
(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'...
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
It seems to be a sensitive subject with many different opinions. Should we add time for it in the next UX meeting?
(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.
(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?
(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
(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..
>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
(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...
(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?
(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.
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.
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.
(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).
(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.
(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.
(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.
(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.
FWIW: Stumbled on https://www.dedoimedo.com/computers/libreoffice-7-review.html (see bug 136082). Also complaining about to many interfaces
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
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
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.
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
Im against remove tabbed compact and contextual layout and the reason is, it's simple to develop and can maybe in the future transfer from .UI to xml files. Tabbed layout is important, but the most complex UI.
Just noting that I tweeted about the NotebookBar here: https://twitter.com/libreoffice/status/1322497314095833089 Check out the replies - some feedback and requests to make it the default.
This is the first time I've been made aware of this issue page; too bad more QA/power users haven't been in on the discussion. I would like to strongly disagree with the suggestion of making a ribbon interface the default. This change will be _harmful_ to our users. Why? The ribbon is an anti-productive UI choice in Microsoft Office: * It presents less features at once to the user * It forces more clicks to reach many features (and never less). * It discourages using the keyboard to locate features (as it either displaces the menus or confuses us by constituting a secondary menu system). * It forces arbitrary breaking up of natural categories of features, to correspond to the ribbons. * Whatever positive effect it may have in making some buttons bigger - can be achieved by making button shapes visible again, instead of an entirely flush toolbar. Clearly-shaped buttons are more "accessible" to be pressed. No less importantly than this general analysis: Over the years since its introduction, and as a person who supports MS Office users (not professionally, but very often) - I have noticed users have a weaker grasp of Office features, less capacity for adopting the use of additional. features, and more difficulty in locating features/buttons. Thus, ribbons are something we need to wean users off of, to help them become more proficient and more productive. It will certainly _not_ help if they get another broken UI, just because they're used to it. So please, Heiko and others - reconsider and don't make this change. As you have said in your opening comment: > a surprisingly large number of users is not aware of the UI variants Great! That means people easily get used to the menu + toolbars and don't go looking for how to set up a ribbon. Let's keep it that way.
I think we can close this bug report. There will be an information at the Tip of the day dialog where you can go to the dialog picker (or not whatever user prefer) This isn't that much in your face, but will give users feedback what was done within the LibO community.
(Collection of comments resulting from catching up on the discussion; my main point is in comment #73 above.) * I've just read the Reddit thread mentioned earlier. There was about one person who said a ribbon interface is superior / more useful than menubar+toolbar. Others were either against ribbons (some with a passion), or supporting it because that's what people would want/need since they're used to them from MS Office. So it doesn't seem users are themselves clamoring for a ribbon, but rather that some users _assume_ this is necessary/important for MS Office transition. * I don't buy the implicit dichotomy between "enterprise" users who want menus+toolbars and "community" users who want ribbons. My experience is that most or all users (including less-computer-literate ones) fare better with a menu+toolbars interface. And no less importantly - with an interface that is static rather than dynamic. Additionally, people in our "community" are not so enamoured with MS Office as to expect us to copy it. And finally, like Dieter said - MS Office UI is a moving target anyway. * Telesto makes a good point in comment #69: With multiple UI modes, every one needs to see a bunch of work put into it, initially and for ongoing maintenance. This hasn't been completed. As it stands, Some buttons are missing (bug 138440 just filed) , small-vs-large button choices are weird, some placement is confusing (like the formatting marks next to LTR-RTL) etc. ---- @JohnMills: > The... logical UI choice would be the tabbed interface... as this is the UI that the vast majority of users would be most familiar with. Users are familiar with toolbars, with menus and with buttons. Ribbons are less common than all of those. Also, if it were logical to offer users what they are used to, then - it is logical for them to just stay with Microsoft Office. That _is_ what they're most used to, after all. > Microsoft spent a huge amount of time, money and effort when designing this interface It also spent a lot of time, money and effort on UI changes in Windows Vista, and that was a flop. Or - remember clippy? ... MS Office has its better and worse features - we pick and choose, and offer something else. > pragmatism is fulfilling the wishes of what users want. Pragmatism is "a practical approach to problems and affairs" (Merriam-Webster dictionary). That's really not the same as striving to fullfil people's wishes. However, in our case - we're not even talking about people's wishes. Correct me if I'm wrong, but I don't believe we have empirical evidence to suggest that our users want ribbons over toolbars and menubars. Your statement in comment #2 suggests you are _deducing_ this is the case; but you've not justified this deduction AFAICT. > Does changing the default UI benefit LibreOffice in the longer term by bringing new users to the software and hopefully contributors to the project? Well, I would say "no", but - you're making several assumptions here. I would say that encouraging users to drop ribbons benefits LO in the long term; that a uniform (non-ribbon) interface has support benefits; that it benefits our _users_ in the medium and long term; and that ribbons would have a neutral or detrimental effect w.r.t. attracting contributors. ---- @VStuartFoote: Agree with (almost) all your comments :-) ---- @RizalMuttaqin: > [to] some extent we should look at what familiar with majority of users If menus and toolbars were unfamiliar to most users, I would agree. But they are no less familiar than ribbons. Just - not in MS-Office.
@ Eyal Rozenberg Thank you furthering the discussion, you bring a valid perspective and it is important that all sides in the 'debate' are highlighted. The discussion around changing the default User Interface is potentially one of the most disruptive (for good or bad)changes proposed for the user experience in LibreOffice in the 10 years the project has been around. The question for me is, where does LibreOffice(The Document Foundation)see itself in 3 years, 5 years? For commodity software such as LibreOffice there is considerable competition in a market that is relatively stagnant with growth likely being focused towards online offerengs (Office 365, ZOHO office, G Suite)and mobile. https://www.ciodive.com/news/Google-Microsoft-Office-collaboration/571740/ I read the Board discussion mailing list and there isn't even agreement with the online strategy and LOOL might not even continue, but anyway that is a different issue. My hope is that any change would facilitate the growth of the user base for LibreOffice and introduce more people to FLOSS software. >* I don't buy the implicit dichotomy between "enterprise" users who want >menus+toolbars and "community" users who want ribbons. Can you explain this implicit dichotomy some more? I suspect that enterprise users are also personal users when they are not at work. >My experience is that most or all users (including less-computer-literate >ones) fare better with a menu+toolbars interface. And no less importantly - >with an interface that is static rather than dynamic. What is your experience? This sounds anecdotal, granted mine does also, is the static part you refer to the act of not switching to a different tab as opposed to using a menu item? I'll explain my experience, I am massive advocate of FLOSS software. I have worked with Schools, charities and some computer labs at universities. As I am based in the UK my views are likely clouded by this. Almost in all cases those people under the age of 25 given a choice between using an office suite with a 'ribbon' or a menu / toolbar paradigm choose the ribbon as it is familiar to them. I get much better feedback when I default their UI to use the tabbed option. In the UK almost exclusively for desktop office suites(non cloud) Microsoft will be used across primary, secondary and tertiary education. I do not have the numbers to hand but I would expect this to be well in to the 90% range as Microsoft either make the software available for free or provide substantial financial incentives to the institutions to not move away from Microsoft products. The Office 365 strategy feeds in to this. The reason I highlight this is because all of these students will one day be out in the market place, and human nature is such that they will tend to go with what they have used before, and that is the 'ribbon' and that is Microsoft Office. Inertia is a very real thing and Microsoft know this very well. The menu/toolbar may be measurably better by your standards or studies, however the current UI of LibreOffice is more difficult to operate for this class of user. And this will increase year after year. The tide started in 2006 when Microsoft introduced Office 2007 and it will not dissipate anytime soon. >Additionally, people in our "community" are not so >enamoured with MS Office as >to expect us to copy it. And finally, like Dieter >said - MS Office UI is a >moving target anyway. I think this is the critical point of your argument, "our community." The millions of end users of LibreOffice do not generally care for internal mailing lists or bug tracking, they want a tool that works, that is familiar to them.I think that there a large disconnect between 'typical' end users many here that it would appear to me have an irrational dislike for Microsoft and hence their applications that are considered the 'gold standard' out in the real world. If you look at the majority of desktop Office suites such as Kingsoft Office (WPS), FreeOffice, Softmaker and OnlyOffice they have all moved to a 'tabbed' like interface first. My opinion is they have done this for the reasons I have outlined above. The online version of Collabora office has moved to this UI paradigm by default in version 6.4 of their productivity suite. https://www.collaboraoffice.com/press-releases/collabora-online-6-4-0-released/ This is not about slavishly copying Microsoft, this is about fulfilling the expectations of the majority of your users and seeking to grow LibreOffice market share. And I do not think having a mostly stagnant UI that resembles Microsoft Office 2003 by default serves the long term objectives of sustaining LibreOffice and growing the user base in a crowded and fragmented market. I am happy to continue but I do not want to make this post overly long for now. Kind regards, John
I think this bug can be closed as fixed. We have opted for a dialog presented at first launch. So comment 73 doesn't add much value, IMHO. Bug 137931 and bug 137925 remain around to continue the discussion. As they compromise at bug 137931 kind of silly. I assume JohnMills is agreeing with me ;-) However comment 73 obvious makes clear the communication issues. It discussed in so corner of the bug tracker :-) Not the right/ideal place. However no clue how to it differently.
For me the decission is realy simple. There is NO developer (since forever) how do/will support Notebookbar, so how could we change to it by default? The Notebookbar was a very good GSOC project and I did play around a lot with the UI, but in the End it's not usefull to have something as default, which isn't well maintained. However I'm very happy that with 7.1 the Layout dialog is more prominent so user can switch if wanted and maybe in the future we get new contributors for Notebookbar. LibreOffice is no single person project and Notebookbar was hacked around from Szymon (while two GSOC projects) a second GSOC project and me (a non developer). In the end Notebookbar show that it would be better to have first an goal and than reach it. Now we have a playground without a decission. Change the default UI mean also update documentation, wiki's, tutorials, help, ... It doesn't work as it is now, that nobody make a goal.
goals has to be defined by special online-meetings where all the stakeholders (develop, design, documentation, help, translation, trainees, ...) can give there feedback. I already wrote meetings you need more than one. And at the end you need a decision where all stakeholders are willing to work on. Plasma define goals for the next years they are working on, that doesn't mean that there can't be other goals, but they define 3 goals and this 3 goals have the focus. For me notebookbar as it is now is more a waste of (my) time. It's not cause notebookbar is a bad idea or bad implemented, it's cause there are two complete different options Standard toolbar with .xml files and Notebookbar with .ui files. Which mean any change need to be added on different places. For Collabora Online (LOOL) I already open an issue cause of exact that reason. It's to expansive, to have two complete different UI's. https://github.com/CollaboraOnline/online/issues/55.
(In reply to Telesto from comment #77) > I think this bug can be closed as fixed. We have opted for a dialog > presented at first launch. So comment 73 doesn't add much value, IMHO. > > Bug 137931 and bug 137925 remain around to continue the discussion. As they > compromise at bug 137931 kind of silly. I assume JohnMills is agreeing with > me ;-) > > However comment 73 obvious makes clear the communication issues. It > discussed in so corner of the bug tracker :-) Not the right/ideal place. > However no clue how to it differently. Hey Telesto, I think you correct with your analysis and I do agree on the points you raise regarding the notification/dialog on first start. However, I think it is better not closing this Bug as this issue will be raised again in the future as it is a topic many are passionate about and there is a lot of valuable discussion found here. I find myself agreeing with @andreas_k also on the criticality of all stakeholders being involved with these discussions and having some long term strategy direction from the TDF board on the direction they wish to see LibreOffice UI progress in the future.
Very long, didn't read the whole thread. My opinion may then be biased. I'm afraid that all this discussion about the "ideal" UI to be elected as the default one misses the real point. UI is not the target in an application. The target is the usefulness of application purpose and UI is only a tool to serve this usefulness. What is the chore of LO and its distinctive power feature? Styles. Styles are present in Writer, Calc, Impress and Draw at different level of abstraction and power. Style usage should be encouraged by all means because they are the key to full LO power. When you must review and reformat a sophisticated document, the task is overwhelming if direct formatting was the base of the workflow. IMHO, M$ Office-like UIs are wrong because: 1 - they lead to the "intuitive application control" syndrome making users falsely think they master the application 2 - they encourage direct formatting because the alternative style control is not that obvious (and styles are far less developed in the competition) 3 - being immediately accessible, they postpone the need to read the Guides The net result is a tremendous number of angry questions on AskLO from users ranting that LO is not M$ Office. In my point of view, LO doesn't offer yet a full original style-oriented UI. In Writer, the paragraph styles sit in the toolbar with their own menu but character, frame, page and list are not there. You must display the side style pane and selecting one non-paragraph style requires first to click on an icon to change the displayed list. As a long-time advocate of styles, I find this is not the correct way to push users towards styling. The present status (with a menu View>User Interface>…choices… seems to me a good trade-off. It is hidden just the correct level so that a curious user discovers the trick and the lazy user is doomed to learn new ways of doing its job.
(In reply to ajlittoz from comment #81) > Very long, didn't read the whole thread. My opinion may then be biased. > > I'm afraid that all this discussion about the "ideal" UI to be elected as > the default one misses the real point. > > UI is not the target in an application. The target is the usefulness of > application purpose and UI is only a tool to serve this usefulness. > > What is the chore of LO and its distinctive power feature? Styles. > > Styles are present in Writer, Calc, Impress and Draw at different level of > abstraction and power. > > Style usage should be encouraged by all means because they are the key to > full LO power. When you must review and reformat a sophisticated document, > the task is overwhelming if direct formatting was the base of the workflow. > > IMHO, M$ Office-like UIs are wrong because: > > 1 - they lead to the "intuitive application control" syndrome making users > falsely think they master the application > > 2 - they encourage direct formatting because the alternative style control > is not that obvious (and styles are far less developed in the competition) > > 3 - being immediately accessible, they postpone the need to read the Guides > > The net result is a tremendous number of angry questions on AskLO from users > ranting that LO is not M$ Office. > > In my point of view, LO doesn't offer yet a full original style-oriented UI. > In Writer, the paragraph styles sit in the toolbar with their own menu but > character, frame, page and list are not there. You must display the side > style pane and selecting one non-paragraph style requires first to click on > an icon to change the displayed list. > > As a long-time advocate of styles, I find this is not the correct way to > push users towards styling. > > The present status (with a menu View>User Interface>…choices… seems to me a > good trade-off. It is hidden just the correct level so that a curious user > discovers the trick and the lazy user is doomed to learn new ways of doing > its job. We need to be more mature that calling Microsoft, M$ it just demeans the whole conversation and shows an obvious bias.
*** Bug 142057 has been marked as a duplicate of this bug. ***
Since it's been a year since any substantial comment to this request do we have any further feedback for this design decision? Is Collabora Office defaulting to the notebook bar tabbed interface by default an indication of the future direction for LibreOffice and any future LibreOffice online version? Is sticking with the 'classic' default UI aiding or hindering the adoption of LibreOffice currently or is the project UI well defined and in 'maintenance' and just coasting at this time?
(In reply to Heiko Tietze from bug 148967 comment #35) > the team facilitates the work around LibreOffice. The > ESC usually gives favorable consideration to my recommendations, which I > take from user input, done at bug 135501. So I plan to change it (affects > new installation only). Hmm. I read the discussion here, and find that the "user input, done at bug 135501" shows the prevail of negative feedback to the idea of making notebookbar the default (in its current condition, or at all) (V Stuart Foote in comment 3; ajlittoz in comment 81; andreas_k in comment 78; Eyal Rozenberg in comment 73, Telesto in comment 69, Samuel Mehrbrodt in comment 62, ... stopped scrolling up), which is voluntarily ignored because of a few vocal users tend to answer every post, creating massive amount of "feedback" (look at the responses to the mentioned comments). I don't claim that this reflects the whole user base opinion; just that we should not consider the feedback received *here* as justification of a "do change" decision (which seems to be the case based on the quote above). Repeating myself from that bug: Note that such a decision should at least depend on the availability on mnemonics (keyboard access) working with such a UI; e.g., when a menu is used (which is active with toolbar UI), you may use F10 (Alt) to access menu without mouse. Competition had never offered a UI without keyboard access to its commands. Also note that keyboard shortcuts (Customization) is unrelated here: what is required is keyboard-based navigation through the visible UI.
I want to support the really crucial point raised by ajlittoz in comment #81. Regardless of the UI *technology* that would be the default, the discussion here drives us in a completely wrong direction, and actually should *not* happen until that point is clarified and resolved. The *current* UI (menu + toolbars + sidebar) might not be perfect; however, *current* form of other UIs makes it *much* harder to use styles, which are the core of LibreOffice. Most advanced features of the suite are based on styles; so making dealing with styles harder, you make all advanced features even less accessible and usable by anyone. And note, that advanced features are not only used by advanced users: any user may receive a document with arbitrary set of features, including those used by the software to emulate features in a foreign format. And when your UI makes these features even more awkward to use than necessary, the conceptual complexity is multiplied, making it a nightmare to comprehend what is going on. Any UI, be it tabbed or whatever, must be analyzed from the point of view of usability with advanced scenarios, keeping in mind that different parts of the UI must work together to help user understand such features, not fragment them. So where are the results of such analysis? In the current form, it looks like we rely on the opinion of users who don't really use the product, but could as well use WordPad for their needs, to decide if current tabbed UI is ready for the primetime. Basic users should not be "second class citizens", but power users should not be just as well.
Before defaulting to the notebookbar as a default (which I am NOT in favour of), it would be rather wise to clean up things like https://wiki.documentfoundation.org/Development/NotebookBar which state "NOTE: the Notebookbar is an experimental and optional feature, and NOT recommended for production use!".
(In reply to Mike Kaganski from comment #85) Comment 3, OK--but I'd think my concers in comment 33 (regards bug 109425 and bug 107343) or in comment 53 (illusion of any similarity between NB Glade assemblages and the full API of the MS Ribbon Class) were more substantive in any decision of moving to a MUFFIN NB default UI.
Tagged the clear opinions about making the Tabbed UI the default with minus (9, would include myself here but didn't do so as OP) and plus (4). Considering also some plus from Twitter, comment 72). The experts arguments weight a lot, meaning bad accessibility, customizability, and missing maintenance. OTOH, without bringing this to attention we don't get volunteers to fix the issues. So this remains on hold.
If TDF considers the ribbon UI to be a strategic benefit they should: 1.) Have a meta bug that is collecting issues about it. (I assume one doesn't exist since it isn't attached to this issue) 2.) Then keep putting out tenders to fix these issues 3.) Then strongly encourage all the beta testers for the next release to switch to notebook bar and do their testing that way. It should also be a focus of a year of internal QA testing. This isn't an issue that you want to rely on volunteers to handle. It is way too important. The user experience must be excellent as soon as it becomes the default, and issues related to it must be fixed quickly. After notebookbar is deemed ready, it should also wait until an X.0 release to debut as default.
Created attachment 180077 [details] defaultToRibbonUI.oxt: extension that sets the default UI to notebookbar Like all of my extension configurations, this was based on trial and error, not on intimate knowledge of the correct way to do things. It works - that's all I can say. Any feedback is welcome.
(In reply to Justin L from comment #90) > If TDF considers the ribbon UI to be a strategic benefit I would actually be interested in links to minutes of such discussions in the past (in the ESC? Design team?) ; and if one is coming up, a notification here or at whatever meta-bug is opened about this issue.
(In reply to Justin L from comment #91) > Created attachment 180077 [details] > defaultToRibbonUI.oxt: extension that sets the default UI to notebookbar > > Like all of my extension configurations, this was based on trial and error, > not on intimate knowledge of the correct way to do things. It works - that's > all I can say. Any feedback is welcome. Thank you, I think that is a useful tool to be available! > If TDF considers the ribbon UI to be a strategic benefit they should: > 1.) Have a meta bug that is collecting issues about it. (I assume one doesn't >exist since it isn't attached to this issue) > 2.) Then keep putting out tenders to fix these issues > 3.) Then strongly encourage all the beta testers for the next release to switch > to notebook bar and do their testing that way. It should also be a focus of a >year of internal QA testing. > This isn't an issue that you want to rely on volunteers to handle. It is way too > important. The user experience must be excellent as soon as it becomes the default, and issues related to it must be fixed quickly. > After notebook bar is deemed ready, it should also wait until an X.0 release to >debut as default. You make some very interesting points here Justin, although I don't agree with your last one about a X.0 release as that would mean any migration would now be over two years away. There is very little doubt that having a 'ribbon' is a strategic benefit for LibreOffice. I often think that some people here are so blinkered that they have no experience of supporting users that have only ever really used MSO as a desktop office client. This irrational 'hatred' for all things Microsoft is nonsensical. I can understand that there are currently some deficiencies with the Notebook bar implementation, however it appears there is no concern to really improve these as it is much easier to stick with the status quo and pretend everyone wants to stick with the Circa 25-year-old MSO 1997 like interface that LibreOffice currently uses. It's just so blinkered, even Collabora Office has shifted to the 'notebook bar' as default as they understand the benefit for their product and user adoption and the strong draw it has for users coming from something like MSO365. I think with a non commercial project like LibreOffice there isn't the strong emphasis for providing your users what they want, there is no financial benefit to chase, you don't really 'compete' in any real sense. So if a few people really like the old ways then so be it, hey it's free after all isn't it? Well wake up to the reality, MSO is for millions and millions of students worldwide, and I dare say there are more pirated copies of MSO being used than LibreOffice users. It's the ostrich burying the head in sand situation and you guys don't see it. LibreOffice will become less relevant over time. I think you see this already with less coverage in the FLOSS media for new releases. In almost every review you find for Libreoffice you read a variation on the same theme, that it is a very powerful Office Suite, with good features but it looks ancient and people just generally don't really like the UI. This will accelerate over time, it has already and it will continue to, the competition like Only Office are building much better mind share now. Why are WPS/Kingsoft Office, Softmaker/Free Office, Polaris Office, Thinkfree and other desktop office clients defaulting to a 'ribbon'like interface? Is this possible because they understand that this is for the benefit of their users? And for the commercial companies with financial constraints that perhaps they see this as a benefit to sell more of their software? Someone with some insight in TDF needs to seriously look at this issue and commit resources to resolve any perceived missing functionality with the notebook bar interface. The guys in the design team work hard and it appears to me they are always battling to get resources like developer support.
(In reply to John Mills from comment #93) > There is very little doubt that having a 'ribbon' is a strategic benefit for > LibreOffice. John, why are you trying to present your position as the objective truth? Many do not believe that having a ribbon is "strategically beneficial" for LibreOffice. And many, or most, believe that having it as the default UI is simply detrimental. > I often think that some people here are so blinkered that they > have no experience of supporting users that have only ever really used MSO > as a desktop office client. This irrational 'hatred' for all things > Microsoft is nonsensical. These claims have already been rebutted on this very bug page, if not fully refuted. Why do you insist on retreading this? > In almost every review you find for Libreoffice you read a variation on the > same theme, that it is a very powerful Office Suite, with good features but > it looks ancient and people just generally don't really like the UI. That's not true. Here's the first set of user reviews one finds on a search for LibreOffice review (on DDG): https://www.trustradius.com/products/libreoffice/reviews#reviews Most reviewers there don't complain about the UI at all. Some do, but those complaints are typically not "why isn't it like MSO". They include "UI not tablet friendly" and "menus are outdated ... full featured [but] some tools are buried within dialogs that you'd have to find under sub-sub-menus". I'm not saying there are no reviews with the complaint you mention. The first result on that search phrase is a PCMag review, which decries how LO's interface isn't "modern and elegant" like MSO or Google Docs (which get much higher review scores): https://www.pcmag.com/reviews/libreoffice But that's more the exception to the rule. Other reviews mention how you can choose the UI type, and others simply don't bring this matter up at all. Some more of the top search results for LO reviews: https://www.techradar.com/reviews/libreoffice https://www.lifewire.com/libreoffice-review-1356322 > Someone with some insight in TDF needs to seriously look at this issue and > commit resources to resolve any perceived missing functionality with the > notebook bar interface. Disagree.
Being a serious user of LibreOffice, I believe that changing the default UI from Standard to Notebookbar would be detrimental to users’ experience of a very good office software package. The Standard UI is very similar to other office software packages, so a new user to LibreOffice would have no problem in getting to grips with LibreOffice. I find that ALL the UI variants that are available for LibreOffice are not as good as the Standard UI. With writing the user guides for Impress and Draw, I had to check the UI variants for one of the chapters. Not impressed. Standard UI is the best.
(In reply to PeeWee from comment #95) > The Standard UI is very similar to other > office software packages, so a new user to LibreOffice would have no problem > in getting to grips with LibreOffice. Which modern office suites are similar to the Standard LibreOffice UI by default? > I find that ALL the UI variants that are available for LibreOffice are not > as good as the Standard UI. With writing the user guides for Impress and > Draw, I had to check the UI variants for one of the chapters. Not impressed. > If you are involved with creating documentation for LibreOffice I am not surprised that your preference and experience would be for the 'standard' UI, completely understandable. But I don't think that is representative of the type of people that you need to attract as new users to LibreOffice. This exercise is something for the next 5 --> 10 years a longer vision as you wouldn't consider changing the default UI on a regular basis.
Should we spin off a design task "Create sketches for ajlittoz's vision of a UI promoting the use of styles"?
If the default UI is going to be changed, th4en could the spelling be correct. Notebookbar is definitely incorrect. Please change to Notebook Bar to make the UI look more professional. Regards PeeWee
(In reply to Buovjaga from comment #97) Definitely.
Another problem I have found as I do want to test this UI. The Notebook Bar UI is already available as a UI in LibreOffice, BUT it is called Tabbed UI. Can this be corrected so that users can easily identify the correct UI to use? Regards PeeWee
Design task created for making the style story better: bug 149230. From now on I will point all new designers to that task until we hit gold. (In reply to PeeWee from comment #100) > Another problem I have found as I do want to test this UI. > > The Notebook Bar UI is already available as a UI in LibreOffice, BUT it is > called Tabbed UI. > > Can this be corrected so that users can easily identify the correct UI to > use? The Notebook Bar comes in 8 variants. https://help.libreoffice.org/latest/en-US/text/shared/01/notebook_bar.html
(In reply to PeeWee from comment #95) > Being a serious user of LibreOffice, I believe that changing the default UI > from Standard to Notebookbar would be detrimental to users’ experience of a > very good office software package. The Standard UI is very similar to other > office software packages, so a new user to LibreOffice would have no problem > in getting to grips with LibreOffice. I assume you haven't used other office suites in the past 15 years, because since then every LibreOffice alternative uses a tabbed UI similar to the Ribbon UI from MS Office. Furthermore, the users whose experience you want to defend actually do have problems in adapting from a Ribbon UI to the Standard Toolbar. Just go to any comment section of a LibO release to notice that. The Standard UI is a fossil from a different computing era. > I find that ALL the UI variants that are available for LibreOffice are not > as good as the Standard UI. With writing the user guides for Impress and > Draw, I had to check the UI variants for one of the chapters. Not impressed. > > Standard UI is the best. Could you please provide input and feedback on how to improve the Tabbed UI then? I would assume that someone from the documentation team wouldn't want to change from the Standard UI because then you would have increased work to re-write the documentation. Thus I do understand why you would consider it best. Not best for the users of office suites though. And I write this, knowing full well that the Tabbed UI still isn't ready to be the default while it does not support extensions among other blockers. Also, the Notebookbar is the framework to develop different UI variants. The Tabbed UI is the one we are talking about here.
(In reply to Pedro from comment #102) > I assume you haven't used other office suites in the past 15 years, because > since then every LibreOffice alternative uses a tabbed UI similar to the > Ribbon UI from MS Office. Actually, most LO alternatives (as listed on Wikipedia) _don't_ use a tabbed interface: * KOffice - menus & toolbars (abandoned in 2015 but you said past 15 years) * AbiWord - menus & toolbars (although it's just a Writer alternative) * Calligra - toolbar and vertical-tabbed sidebar * NeoOffice - menus & toolbars and the only one on that list with tabs seems to be OnlyOffice. If you count commercial office suites, you do find more ribbons (SoftMaker, OfficeSuite, WPS), but then there's also iWork with its minimalist interface (I believe they're not hiding tabs but feel free to correct me). So, with the commercial ones, you still only get to, say, around half. Not "every" alternative". > Furthermore, the users whose experience you want > to defend actually do have problems in adapting from a Ribbon UI to the > Standard Toolbar. There is some adaptation, granted; but as discussed above - the adaptation is important and beneficial. > Just go to any comment section of a LibO release to notice that. That, of course, would be a biased sample. Users do not post "I just thought you should know I don't have a problem with menus". > The Standard UI is a fossil from a different computing era. Well, it seems that statistically, that's not actually the case; and you've only based this statement on the statistical claim.
(In reply to Eyal Rozenberg from comment #103) > (In reply to Pedro from comment #102) > > * KOffice - menus & toolbars (abandoned in 2015 but you said past 15 years) DEAD > * AbiWord - menus & toolbars (although it's just a Writer alternative) Basically on life support and not an office suite, just a word processor > * Calligra - toolbar and vertical-tabbed sidebar Linux Only > * NeoOffice - menus & toolbars Mac Only > > and the only one on that list with tabs seems to be OnlyOffice. If you count > commercial office suites, you do find more ribbons (SoftMaker, OfficeSuite, > WPS), but then there's also iWork with its minimalist interface (I believe > they're not hiding tabs but feel free to correct me). So, with the > commercial ones, you still only get to, say, around half. Not "every" > alternative". This is factually not correct, iWorks is not commercial in the sense I can not purchase a copy, it is Mac only and comes for free with your system if you need it. How is that half of commercial office suites on your list? Every other defaults to a tabbed interface and there are certainly others you have not added in your list such as the excellent Korean Hancom office. > > Furthermore, the users whose experience you want > > to defend actually do have problems in adapting from a Ribbon UI to the > > Standard Toolbar. > > There is some adaptation, granted; but as discussed above - the adaptation > is important and beneficial. What is the essential part? That you force a user to 'unlearn' everything they know about an office suite interface? Where is the benefit, could you expound upon this assertion? > > Just go to any comment section of a LibO release to notice that. > > The Standard UI is a fossil from a different computing era. > > Well, it seems that statistically, that's not actually the case; and you've > only based this statement on the statistical claim. I would say based upon your previous statement it is your statistical claim in error and not that from Pedro.
(In reply to John Mills from comment #104) iWorks on a Mac no longer exists. The three main components, Pages, Numbers, and Keynote, are now individual software packages. Depending on where you live in the World, these three packages may be included with the macOS or you may have to download them separately from the App Store. The software is minimal with a lot of features and it does take time to learn them. IMO, the Standard UI is a reasonably efficient way of navigating in LibreOffice and does make it different from other office software packages. It also offers several ways of using all the tools that LibreOffice provides. I am used to the Tabbed UI from my MS Office days and if this UI is used as a basis for the Notebook Bar it would be a backward step. There will be users who prefer a Notebook Bar UI, but give those users the option of changing the UI and the Standard as default. To close, Notebook Bar should be used in LibreOffice and not Notebookbar, which is incorrect. There are several incorrect spellings in LibreOffice dialogs and menu items. These errors should be corrected to make LibreOffice look more professional. Regards PeeWee
Hi all! I have been using LibreOffice every day for a couple of years to do all my work and I would like to provide some insights on this issue. At first glance, I would be totally in favor of switching to the Tabbed UI as the default option. On my computer I always switch to the Tabbed interface, because I really think it is more pleasing to my eyes. My preferred setup is LO using kf5 and dark mode with Tabbed UI. With this setup, other people who are not LO users and see me using it with the Tabbed UI tend to compliment how good it looks. Since I often give lectures via online meeting services (Zoom, Google Meet, etc) and I share my screen, I had some people asking "What is this office suite you're using... it looks nice!". Most people don't even recognize it's LibreOffice, because they do not know we already support a ribbon-like interface. I also agree with those who claim that, in order to attract new users we should provide them with something they're more familiar with, which is the ribbon interface. I have met people who migrated from LibreOffice to WPS / OnlyOffice / FreeOffice just because of the way they look and feel, as well as for the superior ribbon interface support (despite LibreOffice providing a much more feature rich application). HOWEVER, being a very frequent user of the Tabbed UI I have to recognize it has some serious limitations that make it unfit to be the default option. I'll list some of them: 1) The set of available commands in each Tab needs to be better thought out, since some commands are missing and some popular commands should be more prominent. This needs more UX research to improve the final layout. If we make the Tabbed UI the default (and it gets documented) we won't be able to keep changing it. 2) The Tabbed UI does not respond well to window resizing because of the way the widgets are grouped. Sometimes, reducing the window by a small amount will hide half of the available commands. 3) Some commands have disproportionally long names that use to much of the available width in the Tab, specially in translated versions of LO. This one is hard to fix, but it's a limitation of the Tabbed UI. 4) The Tabbed UI does not support much customization as the Standard UI does (see Tools - Customize - Notebookbar). Here the question is: do we want to support customization of the Tabbed UI? Maybe not, since it would introduce a whole lot of complexity. 5) The Tabbed UI does not integrate well with extensions. The "Extension" tab is really hard to work with from the standpoint of extension developers and the merge commands do not work as expected. All I ever was able to do is add icons without labels. If the Tabbed UI is to become the standard, we need to improve the way extension developers will integrate their extensions into LO. 6) AFAIK the Tabbed UI does not integrate well with dark mode in Windows, so it would be a bad experience for Windows users. 7) We need to agree on what we'll call this interface. Some people say "Notebookbar", "Notebook bar", "Tabbed UI"... IMO we need to settle with "Tabbed UI" to avoid confusion, because only experienced users will understand that Notebook bar and Tabbed UI is the same thing. 8) All documentation (guides and help) assume the user is using the Standard UI, so we need to give time for the documentation team to provide the necessary changes. 9) We should stick only with the Standard and Tabbed UI only, since the other UIs are not as well maintained. This would help us focus on the two most important options. Other variants could be provided as extensions for users. In summary, I don't think we're near the point to make the Tabbed UI the default option. We need first to define a roadmap and improve it before considering a definitive switch.
(In reply to Rafael Lima from comment #106) Hi Rafael, thanks for taking the time to write such a reasoned response from your perspective, this is entirely the type of feedback that we need, examining the positives and negatives in a very important topic. I think your personal experience is likely not too far from a lot of other people. > Hi all! I have been using LibreOffice every day for a couple of years to do > all my work and I would like to provide some insights on this issue. > > At first glance, I would be totally in favor of switching to the Tabbed UI > as the default option. On my computer I always switch to the Tabbed > interface, because I really think it is more pleasing to my eyes. My > preferred setup is LO using kf5 and dark mode with Tabbed UI. > > With this setup, other people who are not LO users and see me using it with > the Tabbed UI tend to compliment how good it looks. Since I often give > lectures via online meeting services (Zoom, Google Meet, etc) and I share my > screen, I had some people asking "What is this office suite you're using... > it looks nice!". Most people don't even recognize it's LibreOffice, because > they do not know we already support a ribbon-like interface. > > I also agree with those who claim that, in order to attract new users we > should provide them with something they're more familiar with, which is the > ribbon interface. I have met people who migrated from LibreOffice to WPS / > OnlyOffice / FreeOffice just because of the way they look and feel, as well > as for the superior ribbon interface support (despite LibreOffice providing > a much more feature rich application). This is the critical part, the Tabbed UI provides an attractive (certainly on Linux) and familiar interface to users coming from other office suites such as MSO, OnlyOffice, Kingsoft, Softmaker to name a few. This is important, if you were looking 50 to 10 years in to the future where do you think the desktop and online office space is going to be? Will there be consolidation? Will the desktop market shrink compared to online? Will MSO still be number one, will new competitors enter the market? The fact is we don't know for certain, but if trends continue then i think there will be an increased online presence and MSO will still be the most popular desktop client. If they don't radically change their UI then the 'ribbon' will be 20 + years old at that point and the type of UI used by LO 30 years old. Just going by those numbers the current default UI paradigm used by LO will be hopelessly out of date compared to the competition, we can see the movement from traditional menu-based UIs now for a number of years in the office suites mentioned.The very real concern is that this will cause users to migrate away from from LO, free as in 'gratis' is the predominant concern for most users I suspect and all of these other suites offer a product that is generally non cost based to consumers, save for MSO however they offer mobile and web based solutions without cost. I can sit a student down with LibreOffice using the tabbed UI or Softmaker, Only Office and WPS and have them being productive in around 30 minutes once some of the differences are explained compared to using MSO. If you do the same with the current UI then it is a lot longer and the resistance factor is increased. The 'libre' in Libreoffice is critical of course, but is that the primary factor that will increase or sustain the number of users over the next decade? > > HOWEVER, being a very frequent user of the Tabbed UI I have to recognize it > has some serious limitations that make it unfit to be the default option. > I'll list some of them: Thank you for these criticisms, it is very important to hear the issues that users have. And I agree with most of what you say here, but inless there is emphasis and resources made available to correct these then nothing will happen and that stagnation is not healthy for the LO application and community in the longer term. > > 1) The set of available commands in each Tab needs to be better thought out, > since some commands are missing and some popular commands should be more > prominent. This needs more UX research to improve the final layout. If we > make the Tabbed UI the default (and it gets documented) we won't be able to > keep changing it. From what I understand the structure of the tabs can be changed relatively easily. There should be an emphasis for as little change as possible then over the coming years. The standard lets say is MSO, but others like Kingsoft, OnlyOffice and WPS use a similar layout so there is some learnings that can be taken there. I would support in that matter if it was thought to be an exercise to undertake. > > 2) The Tabbed UI does not respond well to window resizing because of the way > the widgets are grouped. Sometimes, reducing the window by a small amount > will hide half of the available commands. Yes, indeed, I was showing Heiko this in the design meeting a few weeks back, the reflow of icons in MSO is very good and logically thought out. Once difference in MSO is that the icons next to the tabs (Save, Open, Undo, Redo, Print) in LO are moved to the header bar in MSO this creates additional room for the tabs themselves when resizing the window. I realise currently LO doesn't support icons in the header bar but this would be an ideal way to get back much needed horizontal space. > > 3) Some commands have disproportionally long names that use to much of the > available width in the Tab, specially in translated versions of LO. This one > is hard to fix, but it's a limitation of the Tabbed UI. Yes, how is this handled in other Office Suites with simmilar UI paradigms, is there some learnings that can be taken away? > > 4) The Tabbed UI does not support much customization as the Standard UI does > (see Tools - Customize - Notebookbar). Here the question is: do we want to > support customization of the Tabbed UI? Maybe not, since it would introduce > a whole lot of complexity. > My broad opinion would be no, for a couple of reasons, mainly the documentation side of things, but also there should be a vision of how this UI should work across different OS versions and potentially the future for the web and possibly mobile. I do think if header bar usage was possible in the future then the ability to add icons there, similar to how MSO allows would be useful. > 5) The Tabbed UI does not integrate well with extensions. The "Extension" > tab is really hard to work with from the standpoint of extension developers > and the merge commands do not work as expected. All I ever was able to do is > add icons without labels. If the Tabbed UI is to become the standard, we > need to improve the way extension developers will integrate their extensions > into LO. Absolutely, I understand that the extention bar came about through a Google summer of code intern working on a project. There has been some debate for example with the Zotero team on the applicability of this extension tab. Currently it is not really fit for purpose and if the decision is that it is a benefit then work is definitely needed there. > > 6) AFAIK the Tabbed UI does not integrate well with dark mode in Windows, so > it would be a bad experience for Windows users. I believe this is pretty much resolved now with the work that is being undertaken with the dark mode in Windows, it would be worth you turning on this experimental feature and provide feedback of your experiences. I have used it for a number of months now and find the experience generally quite positive. > > 7) We need to agree on what we'll call this interface. Some people say > "Notebookbar", "Notebook bar", "Tabbed UI"... IMO we need to settle with > "Tabbed UI" to avoid confusion, because only experienced users will > understand that Notebook bar and Tabbed UI is the same thing. Tabbed UI is the simplest and most descriptive. > > 8) All documentation (guides and help) assume the user is using the Standard > UI, so we need to give time for the documentation team to provide the > necessary changes. Yes, I would expect that if any migration was done it would be over many months at least allowing the documentation team to amend their documents. > > 9) We should stick only with the Standard and Tabbed UI only, since the > other UIs are not as well maintained. This would help us focus on the two > most important options. Other variants could be provided as extensions for > users. Yes, agreed, more than two UIs can cause confusion, personally, I think rather than removing them I would make them an option in the experimental section. I do think there are some benefits to a compact version of the Tabbed UI however and that could be accomplished potentially with an icon that collapses the tab partly as is done currently in MSO. > > In summary, I don't think we're near the point to make the Tabbed UI the > default option. We need first to define a roadmap and improve it before > considering a definitive switch. A road map can only be defined if there is a decision that this is the correct direction of travel for the project, clearly there is need for improvement as you say. However if the resources are not made available then improvements won't happen. There needs to be some strategic vision for where the UI needs to be or else my concern is LibreOffice will simply stagnate and start to hemorrhage users over the coming years.
This part should have read : 'This is important, if you were looking 5 to 10 years in to the future' Not 50 to 10.
(In reply to John Mills from comment #107) So at this point there is a difference between bug title and the actual desire. It's not about the Tabbed UI being the default today or tomorrow, but about some day in the future It's about prioritizing efforts to get a fully functionally tabbed UI (with documentation) with the intention to replace the current toolbar UI as default. The Tabbed UI is a second class citizen at this point. And attracts not much developer attention because it being the non-default. So still stuck at the status quo. So question is about committing to the Tabbed UI as the way to go. And allocating resources to it.
(In reply to Telesto from comment #109) > (In reply to John Mills from comment #107) > So question is about committing to the Tabbed UI as the way to go. And > allocating resources to it. "... allocating resources to it." So, let's ask what dev resources this would commit: 1. Replacing the GLADE based MUFFIN assemblage used for the 'Tabbed UI' with os native code (qt, kf5, gtk4, WDM, Aqua/Cocoa) 2. give up MUFFIN (and all its dynamic UI goodness for users), because we would have to focus dev efforts on the native os code the refactored 'Tabbed UI' and integration for each DE would need 3. Client Side Decoration (the os/DE native code that places program features into an application frame's title bar) 4. assuring correct focus events cross platform for assistive technology for all that new native code And I'm sure a bunch of facets I've missed. Which makes for a simple (and continuing pragmatic) -1 as this contributors perspective. There are other functional areas of UX support for ODF documents that need the attention more than implementing a tabbed UI.
> ... implementing a tabbed UI. Beyond what we have now with the GLADE based MUFFIN 'Tabbed UI', which clearly is not sufficient to being made the default UI.
(In reply to Telesto from comment #109) > (In reply to John Mills from comment #107) > So at this point there is a difference between bug title and the actual > desire. > It's not about the Tabbed UI being the default today or tomorrow, but about > some day in the future I agree with this point of view. Making the Tabbed UI should be a goal for to be achieved within 1 or 2 years. If we start prioritizing it today, maybe within 2 or 3 main releases we'll be able to make it the default. Maybe we could bring this issue to the ESC so that future grants can be proposed to address Tabbed UI-related bugs and enhancements. To that end we already have the Meta bug 107237. I'll check which of the issues I raised in Comment 106 are not yet reported and I'll create bug reports for them and associate with this meta bug. If we are to make the Tabbed UI the default LibreOffice experience in the future, it has to be near perfect. (In reply to V Stuart Foote from comment #110) > 1. Replacing the GLADE based MUFFIN assemblage used for the 'Tabbed UI' with > os native code (qt, kf5, gtk4, WDM, Aqua/Cocoa) I have already made a few minor patches to the Tabbed UI and one thing that gets in the way is that the .ui files for the Tabbed UI are not compatible with Glade 3.38, which is a hurdle when developing for it.
(In reply to Rafael Lima from comment #112) > Maybe we could bring this issue to the ESC so that future grants can be > proposed to address Tabbed UI-related bugs and enhancements. We could hire an in-house developer to focus on UI. See the discussion at https://listarchives.documentfoundation.org/www/board-discuss/2022/maillist.html
(In reply to Buovjaga from comment #113) > (In reply to Rafael Lima from comment #112) > > Maybe we could bring this issue to the ESC so that future grants can be > > proposed to address Tabbed UI-related bugs and enhancements. > > We could hire an in-house developer to focus on UI. See the discussion at > https://listarchives.documentfoundation.org/www/board-discuss/2022/maillist. > html I think this would be long overdue, the guys in the design team could do with some support with all the hard work that they do. You could get a real product vision to follow from a design perspective. And I would wholeheartedly encourage this to be taken to the ESC for consideration. The UI is the gateway to the functionality of the office suite, what should LibreOffice be doing as a project to facilitate this, gain new users and ultimately aim for in the coming years? It might be pride for some to state that no changes are needed in the current UI, but in all honesty what is in the best interests of LibreOffice users now and attracting new users in the future? My opinion is a familiar functioning UI by default (with an option to revert back easily to 'classic UI') robust open file formats and best in class Microsoft Office compatibility is the best way to accomplish this objective.
(In reply to Rafael Lima from comment #112) > I agree with this point of view. Making the Tabbed UI should be a goal for > to be achieved within 1 or 2 years. If we start prioritizing it today, maybe > within 2 or 3 main releases we'll be able to make it the default. If you want to make this argument, you need to address the objections of those of us who are against it. Which you, so far, have not. > Maybe we could bring this issue to the ESC so that future grants can be > proposed to address Tabbed UI-related bugs and enhancements. Again, you're speaking as though this has somehow been agreed. On the contrary - you should refrain from lobbying the ESC for grant money; that would be a misrepresentation of the discussion here. (In reply to John Mills from comment #107) John, I think in this latest reply you've provided the crux of your perspective: > The standard lets say is MSO Excuse the capital letters, but: THE STANDARD IS NOT MSO, nor should it be. "Do like MSO does" may be a reasonable fallback when we have no other alternative. But we also know MSO gets some things wrong, UI-wise; and one of these things is the switch to ribbons, which is more detrimental than beneficial to users. > This is the critical part, the Tabbed UI provides an attractive (certainly > on Linux) and familiar interface to users coming from other office suites The menus + toolbars provide an attractive and familiar interface to such users - as most desktop application software use menus and toolbars, and in fact so do half or more of other office suites. I would concede that tabs "look more attractive" - you get a larger canvas on which to represent your ideas - but they make users fail to notice and find a lot of functionality. And a shiny ribbon is not a good enough reason to make this interface the default. > such as MSO, OnlyOffice, Kingsoft, Softmaker to name a few. You're naming the ones with tabs, and ignoring the others. > if you were looking 50 to 10 years in to the future where do you > think the desktop and online office space is going to be? Will there be > consolidation? Will the desktop market shrink compared to online? Will MSO > still be number one, will new competitors enter the market? The fact is we > don't know for certain, We know that, 30 years ago, desktop applications were using menu bars and toolbars, and 30 years later, they still use menu bars and toolbars, mostly. Ribbons are relatively unpopular. Another direction has been "smartphonish" interface - no menu bar and a hamburger menu. That's nice for a phone, but sucks for the desktop. Chrome, Firefox and Thunderbird have gone in this direction (along with using web-page-like dialog replacements - and it has been a degradation. > but if trends continue then i think there will be an > increased online presence and MSO will still be the most popular desktop > client. if trends continue, then and most applications would still use menu bars and toolbars, while Microsoft will try out some more UI which may or may not be a good idea. > If they don't radically change their UI then the 'ribbon' will be 20 > + years old at that point and the type of UI used by LO 30 years old. Even older. But also note that if trends continue, there will still be few ribbon apps and most free office suites will have menu bars and toolbars, not ribbons. > Just going by those numbers the current default UI paradigm used by LO will > be hopelessly out of date On the contrary. Going by those numbers LO will continue to be in vogue as it is today. Of course, things may turn out differently: It may be the case that in a decade or two, most apps are dumbed-down to smartphone-style interfaces. If that happens, we should still not go down the same path. > [u]nless there is > emphasis and resources made available to correct these then nothing will > happen and that stagnation is not healthy for the LO application and > community in the longer term. I hope you're not insinuating that not adopting your UI design preference implies stagnation... > There needs to be some strategic vision for where the UI needs to be There is such a strategic vision: menu bar and toolbars. True, it's the by-default vision, but to change it, proponents need to make a better argument than "people who use MSO are used to it". Which is what I've also told Rafael, above.
(In reply to Eyal Rozenberg from comment #115) > (In reply to Rafael Lima from comment #112) > > I agree with this point of view. Making the Tabbed UI should be a goal for > > to be achieved within 1 or 2 years. If we start prioritizing it today, maybe > > within 2 or 3 main releases we'll be able to make it the default. > > If you want to make this argument, you need to address the objections of > those of us who are against it. Which you, so far, have not. > > > Maybe we could bring this issue to the ESC so that future grants can be > > proposed to address Tabbed UI-related bugs and enhancements. What precisely is wrong taking this proposal to the ESC? Currently is your suggestion to delay because you have a better proposal for modernisation in the UI? Or rather you believe that the current status quo is adequate? > > Again, you're speaking as though this has somehow been agreed. On the > contrary - you should refrain from lobbying the ESC for grant money; that > would be a misrepresentation of the discussion here. This is an open discussion that has been open for near 2 years now, with both sides making their point. Unless there is any overstepping of statutes for TDF that has been made it is entirely within a member's rights to make a proposal or is this incorrect? > > (In reply to John Mills from comment #107) > John, I think in this latest reply you've provided the crux of your > perspective: > > > The standard lets say is MSO > > Excuse the capital letters, but: THE STANDARD IS NOT MSO, nor should it be. > "Do like MSO does" may be a reasonable fallback when we have no other > alternative. But we also know MSO gets some things wrong, UI-wise; and one > of these things is the switch to ribbons, which is more detrimental than > beneficial to users. For businesses and governments worldwide MSO is by far and way above any other office suite by usage statistics. No other office suite is remotely close to MSO. I would hazard a guess that pirated usage of MSO is significantly greater than LibreOffice unfortunately. Your argument about switching to a ribbon being detrimental is purely subjective. It certainly hasn't hampered their adoption if you compare usage in 2007 compared to 2022. If MSO was not a de facto standard then no suites would seek compatibility of UI paradigms or file formats. Clearly this is not the case. > > > This is the critical part, the Tabbed UI provides an attractive (certainly > > on Linux) and familiar interface to users coming from other office suites > > The menus + toolbars provide an attractive and familiar interface to such > users - as most desktop application software use menus and toolbars, and in > fact so do half or more of other office suites. I would concede that tabs > "look more attractive" - you get a larger canvas on which to represent your > ideas - but they make users fail to notice and find a lot of functionality. > And a shiny ribbon is not a good enough reason to make this interface the > default. Again a subjective opinion, please provide some rational evidence that users 'fail to notice and find a lot of functionality.' > > > such as MSO, OnlyOffice, Kingsoft, Softmaker to name a few. > > You're naming the ones with tabs, and ignoring the others. Which are the others you speak of that default to a 'classic' like interface? Word Perfect, possibly Google docs if you are broadly reaching? > > > if you were looking 50 to 10 years in to the future where do you > > think the desktop and online office space is going to be? Will there be > > consolidation? Will the desktop market shrink compared to online? Will MSO > > still be number one, will new competitors enter the market? The fact is we > > don't know for certain, > > We know that, 30 years ago, desktop applications were using menu bars and > toolbars, and 30 years later, they still use menu bars and toolbars, mostly. > Ribbons are relatively unpopular. Another direction has been "smartphonish" > interface - no menu bar and a hamburger menu. That's nice for a phone, but > sucks for the desktop. Chrome, Firefox and Thunderbird have gone in this > direction (along with using web-page-like dialog replacements - and it has > been a degradation. Well I hope we don't see significant hamburger menu like interfaces by default but they certainly supplement applications now, however I am not talking specifically about non-office applications. I do not see the relevance of the menu structure for photoshop or Auto CAD to the applicability of a Ribbon interface for LibreOffice. > > > but if trends continue then i think there will be an > > increased online presence and MSO will still be the most popular desktop > > client. > > if trends continue, then and most applications would still use menu bars and > toolbars, while Microsoft will try out some more UI which may or may not be > a good idea. I am not concerned what most applications use, only what will serve the adoption of FLOSS Office suites such as LibreOffice. The question is quite simple does offering a UI similar to MSO by default hinder or help the adoption of LibreOffice? Does this help users have a better or worse experience? > > > If they don't radically change their UI then the 'ribbon' will be 20 > > + years old at that point and the type of UI used by LO 30 years old. > > Even older. But also note that if trends continue, there will still be few > ribbon apps and most free office suites will have menu bars and toolbars, > not ribbons. Which free Office suites are they? And do you mean Libre or Gratis? Because if Gratis you are incorrect, if Libre then LibreOffice, Calligra, OpenOffice, however this is by all accounts 'dead now.' > > > Just going by those numbers the current default UI paradigm used by LO will > > be hopelessly out of date > > On the contrary. Going by those numbers LO will continue to be in vogue as > it is today. Of course, things may turn out differently: It may be the case > that in a decade or two, most apps are dumbed-down to smartphone-style > interfaces. If that happens, we should still not go down the same path. In vogue more than now? Is there projections from TDF that keeping the current UI/UX will bolster the adoption of a given time period such as 5 years? Difficult to say I know but your thoughts are basically keep the status quo as it currently exists. > > > > [u]nless there is > > emphasis and resources made available to correct these then nothing will > > happen and that stagnation is not healthy for the LO application and > > community in the longer term. > > I hope you're not insinuating that not adopting your UI design preference > implies stagnation... I am yes, but it is not my UI preference solely, many people have expressed the same preference and see the benefit for the LibreOffice project by bringing more users to the software by using an attractive and familiar interface. UI however is only one area of stagnation, of course there are other areas in LibreOffice that have been neglected for many years due to resources. > > There needs to be some strategic vision for where the UI needs to be > > There is such a strategic vision: menu bar and toolbars. True, it's the > by-default vision, but to change it, proponents need to make a better > argument than "people who use MSO are used to it". Which is what I've also > told Rafael, above. That is your strategic vision and the current status quo as I said before, Rafeal makes a valid point. For those that are seeking to grow the LibreOffice user base through a beautiful and modern Office Suite experience for the end user these arguments are necessary to have, the discourse is civil and the points raised deserve to be discussed at a higher level as your right to object is also.
Although my suggestion (comment 35) was largely ignored, or misunderstood, I'll reiterate it. If you make the UI choice a very visible indicator that can be used to switch to a different UI style, OR to revert to the previous UI the user had been using, I think you can defuse this issue. Unlike commercial software which has to go all in, you have more flexibility. I'll make another suggestion which I expect to be ignored: be (the first?) open source project to run an actual user trial to see what users prefer. [ If you built in a facility for the documentation writers (to snapshot 'screens' from multiple UI styles), you'd also make their job orders of magnitude easier. ]
(In reply to Luke Kendall from comment #117) > Although my suggestion (comment 35) was largely ignored, or misunderstood, > I'll reiterate it. > > If you make the UI choice a very visible indicator that can be used to > switch to a different UI style, OR to revert to the previous UI the user had > been using, I think you can defuse this issue. Unlike commercial software > which has to go all in, you have more flexibility. > > I'll make another suggestion which I expect to be ignored: be (the first?) > open source project to run an actual user trial to see what users prefer. > > [ > If you built in a facility for the documentation writers (to snapshot > 'screens' from multiple UI styles), you'd also make their job orders of > magnitude easier. > ] Hello As one of the LO writers, I can create screenshots of the multiple UIs that are available in LO. All you have to do is go to View > User Interface on the Menu bar and select a UI from the options in the dialog that opens. Restart LO and there is the new UI to take screenshots of. Regtards PeeWee
(In reply to Eyal Rozenberg from comment #103) > (In reply to Pedro from comment #102) > > I assume you haven't used other office suites in the past 15 years, because > > since then every LibreOffice alternative uses a tabbed UI similar to the > > Ribbon UI from MS Office. > > Actually, most LO alternatives (as listed on Wikipedia) _don't_ use a > tabbed interface: > > * KOffice - menus & toolbars (abandoned in 2015 but you said past 15 years) > * AbiWord - menus & toolbars (although it's just a Writer alternative) > * Calligra - toolbar and vertical-tabbed sidebar > * NeoOffice - menus & toolbars > > and the only one on that list with tabs seems to be OnlyOffice. If you count > commercial office suites, you do find more ribbons (SoftMaker, OfficeSuite, > WPS), but then there's also iWork with its minimalist interface (I believe > they're not hiding tabs but feel free to correct me). So, with the > commercial ones, you still only get to, say, around half. Not "every" > alternative". I am counting commercial office suites, with more users or a similar userbase to LibO. KOffice is discontinued. AbiWord is a word processing software. Calligra is a niche office suite, exclusive to Linux and Plasma distros at that (even there most pick LibO over it anyway). NeoOffice is a fork of LibO. It's not an alternative, unless you use Mac and it wouldn't survive if there was anyone actually supporting MacOS in the LibO dev community. I can tell your bias just from this list you enumerated: Linux user and uses exclusively open source software. > > Furthermore, the users whose experience you want > > to defend actually do have problems in adapting from a Ribbon UI to the > > Standard Toolbar. > > There is some adaptation, granted; but as discussed above - the adaptation > is important and beneficial. If you think so then why are you so resistant to adapting to the newer more efficient UI paradigm? > > Just go to any comment section of a LibO release to notice that. > > That, of course, would be a biased sample. Users do not post "I just thought > you should know I don't have a problem with menus". As much of a biased sample as your own selection of "alternatives" top LibO. > > The Standard UI is a fossil from a different computing era. > > Well, it seems that statistically, that's not actually the case; and you've > only based this statement on the statistical claim. Statistically, we know that MSO is the most widely used Office suite in the world. Statistically, the probability that any person you would pick randomly of the street nowadays would be more confortable with the Ribbon UI is much higher than being confortable with a Standard toolbar. I know that most LibO devs prefer Linux, and would prefer if time had stopped in 2006 before the Ribbon UI became the de facto UI standard for an office suite when Microsoft Office launched it in 2007. If you want to satisfy users and attract new users to open source office suites to spread the use of open standards you need to ease the learning curve of using LibO. That means changing the default UI to a Tabbed UI.
(In reply to Luke Kendall from comment #117) > Although my suggestion (comment 35) was largely ignored, or misunderstood, > I'll reiterate it. > > If you make the UI choice a very visible indicator that can be used to > switch to a different UI style, OR to revert to the previous UI the user had > been using, I think you can defuse this issue. Unlike commercial software > which has to go all in, you have more flexibility. > > I'll make another suggestion which I expect to be ignored: be (the first?) > open source project to run an actual user trial to see what users prefer. > > [ > If you built in a facility for the documentation writers (to snapshot > 'screens' from multiple UI styles), you'd also make their job orders of > magnitude easier. > ] It's not a matter of your suggestion being ignored. Open a new bug and clearly outline what you are proposing. Andreas developed the Notebookbar UIs that we use today. At the time we considered making a more visible option, but there was no space available with all the commands you want to make visible, the minimum resolution supported by LiBO means there are important constraints. If you can think of a way to make it fit open a bug with that suggestion and a mock-up please.
(In reply to V Stuart Foote from comment #110) > (In reply to Telesto from comment #109) > > (In reply to John Mills from comment #107) > > > So question is about committing to the Tabbed UI as the way to go. And > > allocating resources to it. > > "... allocating resources to it." > > So, let's ask what dev resources this would commit: > > 1. Replacing the GLADE based MUFFIN assemblage used for the 'Tabbed UI' with > os native code (qt, kf5, gtk4, WDM, Aqua/Cocoa) > > 2. give up MUFFIN (and all its dynamic UI goodness for users), because we > would have to focus dev efforts on the native os code the refactored 'Tabbed > UI' and integration for each DE would need > > 3. Client Side Decoration (the os/DE native code that places program > features into an application frame's title bar) > > 4. assuring correct focus events cross platform for assistive technology for > all that new native code > > And I'm sure a bunch of facets I've missed. > > Which makes for a simple (and continuing pragmatic) -1 as this contributors > perspective. There are other functional areas of UX support for ODF > documents that need the attention more than implementing a tabbed UI. You are just inflating the list of required resources to suit your view of the discussion. Because quite frankly most of those are not required for a user. You are spouting what an ideally developed version of a Tabbed UI should look like from a dev perspective if it was developed from scratch, which would clearly NOT be the case here.
(In reply to Rafael Lima from comment #106) > HOWEVER, being a very frequent user of the Tabbed UI I have to recognize it > has some serious limitations that make it unfit to be the default option. > I'll list some of them: > > 1) The set of available commands in each Tab needs to be better thought out, > since some commands are missing and some popular commands should be more > prominent. This needs more UX research to improve the final layout. If we > make the Tabbed UI the default (and it gets documented) we won't be able to > keep changing it. Microsoft changes the commands available in MSO all the time. If the general layout is the same, people don't mind. If new .UNO commands are introduced and they are deemed too important then the UI/UX developers must find a way to make it visible (ex. see discussion to make the HUD more easily discoverable). Otherwise don't change the layout more than what it is. Plenty of people use it like this nowadays and the complaints have been minor. > 2) The Tabbed UI does not respond well to window resizing because of the way > the widgets are grouped. Sometimes, reducing the window by a small amount > will hide half of the available commands. This is a limitation of Glade but I would call it a blocker. It keeps each group of related commands in the same spatial positions relative to each other meaning that spatial memory of the user can still be used to quickly locate the command he is looking for. > 3) Some commands have disproportionally long names that use to much of the > available width in the Tab, specially in translated versions of LO. This one > is hard to fix, but it's a limitation of the Tabbed UI. This is a translation problem that should not be a blocker as it can be quickly refined. > 4) The Tabbed UI does not support much customization as the Standard UI does > (see Tools - Customize - Notebookbar). Here the question is: do we want to > support customization of the Tabbed UI? Maybe not, since it would introduce > a whole lot of complexity. This would not block the adoption of the Tabbed UI. There's partial costumization already and more could be implemented later. I don't believe there's plenty of bugs demanding this (although there may exist a few) > 5) The Tabbed UI does not integrate well with extensions. The "Extension" > tab is really hard to work with from the standpoint of extension developers > and the merge commands do not work as expected. All I ever was able to do is > add icons without labels. If the Tabbed UI is to become the standard, we > need to improve the way extension developers will integrate their extensions > into LO. This for me is the big show-stopper. Extensions HAVE to be supported > 6) AFAIK the Tabbed UI does not integrate well with dark mode in Windows, so > it would be a bad experience for Windows users. This was fixed by Caolan McNamara and you can check it out in LibO 7.4 dev if you enable experimental features. I already asked in relevant bug discussion to be moved out of experimental so if you want to +1 that please do so. > 7) We need to agree on what we'll call this interface. Some people say > "Notebookbar", "Notebook bar", "Tabbed UI"... IMO we need to settle with > "Tabbed UI" to avoid confusion, because only experienced users will > understand that Notebook bar and Tabbed UI is the same thing. The UI we are referring to is the TABBED UI. Always has been. The Notebookbar is a generic name for UIs developed using Glade and is only used in development terms. > 8) All documentation (guides and help) assume the user is using the Standard > UI, so we need to give time for the documentation team to provide the > necessary changes. Considering the example of members of the documentation team here, I don't think that this is a hard requirement. The Standard toolbar won't go away. Linux distro packagers can still costumize LibO as they want (ex. Mint or Ubuntu) and select Standard Toolbar as the default UI. Would be lovely to see the documentation team expanding the manual with the Tabbed UI though. > 9) We should stick only with the Standard and Tabbed UI only, since the > other UIs are not as well maintained. This would help us focus on the two > most important options. Other variants could be provided as extensions for > users. The other Notebookbar UIs are maintained as much as the Tabbed UI. Andreas Kainz made them and I assisted him with UX research to make the layout as functional as possible for the Tabbed UIs and Groupedbar UIs. But I agree with you. > In summary, I don't think we're near the point to make the Tabbed UI the > default option. We need first to define a roadmap and improve it before > considering a definitive switch. Replying to you, I would say that from your list we have only a couple of HARD blockers: 1 - Extension support. When a user installs an extension it should appear in the extension tab of the relevant module. This should not require extra work of extension developers. 2 - Having a dev that actually wants to work in UI/UX development and would maintain the UI. This for me is the biggest issue and I would say buovjaga would agree with me. Without dev support it cannot be the default. Because a dev could polish the current implementation to a workable state and then start working on dev releases to port the Tabbed UI outside of Glade to support the requirements that Stuart Foote mentioned.
Reading through the heated discussion, I see the recurring motive in the proponents of the change: "we must attract new users". I see why me personally could be motivated by that: I work for a commercial community member (Collabora), and our business indeed would benefit from increased user base of LibreOffice, so that increase by itself could be a goal. But what is others' motivation to demand *just that*? I always had an impression that FLOSS *projects*, unlike commercial vendors, should not be motivated by "get more market share! drag people from other software! consider every alternative a competition!" attitude. I always thought that FLOSS should provide something that the project feels unique distinctive feature(s), so that others could use *if they also share the vision that that is important distinctive feature*. And consider all alternatives as welcome diversity. Is there something in the project (not in some its members, that may and should have own goals) that forces us to seek new users with passion, requiring doing everything just to make the increase happen? Not "make it distinctive and attractive", but "make it attractive by all costs, possibly sacrificing the distinctive pieces"? To clarify: I do not see proponents of the switch saying "we have a *great* and polished UI that we like so much, and that makes our productivity much greater - why is it not default yet?". I see them saying "We have a half-backed UI, with many shortcomings in it that we see, too; and we only require to make it the default because that would resemble something else and *attract users* that otherwise are so uninterested by our distinctive features that they prefer paying money for another UI; and we don't think that such users who require the UI to fit them so much, would immediately see the problems of our similar but not polished thing. Attracting users it the only thing that matters!".
(In reply to Mike Kaganski from comment #123) I think you're being somewhat unfair to the proponents of tabbed UI by default. They seem to be coalescing towards an "invest in the tabbed UI to make it usable as the default", IIUC. That said, I definitely agree with your rejection of the motivation of "we must attract new users at all costs". I also believe that offering UI alternatives at installation time is a sufficient (if not excessive) gesture towards enticing those MSO users who absolutely must have it. (In reply to Luke Kendall from comment #117) > If you make the UI choice a very visible indicator that can be used to > switch to a different UI style, Isn't it enough to make it visible during installation? > I'll make another suggestion which I expect to be ignored: be (the first?) > open source project to run an actual user trial to see what users prefer. The questions of what try, how and for how long will be contentious. Remember that it's pretty easy to cook surveys/polls: https://www.youtube.com/watch?v=6GSKwf4AIlI (In reply to Pedro from comment #119) > I am counting commercial office suites, with more users or a similar > userbase to LibO. I was counting FOSS (and then also commercial) office suites listed on Wikipedia. > KOffice is discontinued. AbiWord is a word processing software. Yes, but the point was made about the past 15 years; and I did mention AbiWord is only an LO Writer equivalent, not a full suite. > I can tell your bias just from this list you enumerated: Linux user and uses > exclusively open source software. I explicitly said that my interpretation of "alternative to LO" is, fundamentally, FOSS. So, yes, I have that bias. > If you think so then why are you so resistant to adapting to the newer more > efficient UI paradigm? You have it wrong... I meant adaptation from ribbons to a menubar and toolbars. And ribbons is an _inferior_ UI paradigm (and certainly not more efficient). > As much of a biased sample as your own selection of "alternatives" top LibO. No, that is not comparable, as I've explained. > > > The Standard UI is a fossil from a different computing era. > > > > Well, it seems that statistically, that's not actually the case; and you've > > only based this statement on the statistical claim. > > > Statistically, we know that MSO is the most widely used Office suite in the > world. So, you're now going to make several points which do not contradict the fact that the standard UI is not "a fossil". Anyway, about this first one: Indeed, MSO is the most widely used office suite; but it's only a single (suite of) applications. Almost no other applications use ribbons, both on Windows and on Linux. And most FOSS office suites don't use ribbons. Also, Windows is the most widely-used operating system on PC's; but we would not entertain an argument that a UNIX-like OS such as GNU/Linux or *BSD is a "fossil from a different computing era". > Statistically, the probability that any person you would pick > randomly of the street nowadays would be more confortable with the Ribbon UI > is much higher than being comfortable with a Standard toolbar. Well, most people in the world don't have PCs/laptops at all; it's more likely such a person would be uncomfortable with any PC app. But regardless - I'm not sure what you mean by "comfortable". If you mean that MSO users are used to the ribbon UI - then yes, but that's not the point. > I know that most LibO devs prefer Linux, and would prefer if time had > stopped in 2006 before the Ribbon UI became the de facto UI standard for an > office suite when Microsoft Office launched it in 2007. Again, common != standard. After all, commercial closed-source is also the "de-facto standard" of how to write office suites by this definition. Also, I work regularly on both Windows and Linux PCs. Ribbons suck IMHO on Windows just like they do on Linux. GNOME-style UI which hides all the functionality sucks on Linux - where it's quite popular unfortunately - and on Mac. Hamburger menubutton rather than a full-fledged menu bar sucks on Linux and on Windows. > If you want to satisfy users I do want to satisfy users, and we should satisfy users with the better UI - the UI which makes it easier for them to be aware and remember how to use more LO functionality, and be more effective document authors: A menu-bar and toolbars rather than Ribbons/Tabbed UI.
(In reply to Pedro from comment #121) > (In reply to V Stuart Foote from comment #110) > You are just inflating the list of required resources to suit your view of > the discussion. > Because quite frankly most of those are not required for a user. You are > spouting what an ideally developed version of a Tabbed UI should look like > from a dev perspective if it was developed from scratch, which would clearly > NOT be the case here. There are lots of different question/aspects to the Tabbed UI bar topic :-). From is a Tabbed UI needed, to being default, to implementation and budget. Obviously the all topics are entangled. For example: seeing the Tabbed UI as extra, means no resources need to allocated (time, budget). And those resources can be used somewhere else. So related to competition with other issues and the prioritization of those. Also the amount of resources required depends on the complexity of the changes to make the Tabbed UI work. Which again depends on what you want to archive (What should the Tabbed UI be like?) Ideally some proposal should be written regarding to requirements which the Tabbed UI so meet (to be competitive), and translated into technical specifications, making for making a CostEstimate for the framework part. So having something concrete to discuses about. Warning: there is a risk the proposal get rejected and a all for nothing feeling for the ones involved.. The current implementation (framework) has limitations (but I'm only have some notion, not exact details). Say positioning of buttons, theming. The design decisions of the current Tabbed UI are - in my perception - governed by limitations. Those limitations start to bite more and more when adding functionality. At least that's my understanding (but Andreas/Caolan/V Stuart are better informed, I guess). There is pretty big risk that the Tabbed UI will outgrow the current framework. Which means a total refactor of framework might be required. Which means lots of stuff needs to be redone. And with the new framework new possibility's arise, so old design decisions based on limitation need all to be reworked again :-( So I tend to prefer to use the "right" framework from the start; at some point every framework will 'fail'. Instead of using some pre-existing framework which already known for it's limitations. And the framework should ideally support complex stuff seen in other Ribbons. Put in other words, the framework should support to possibility to introduce more advanced actions. If those aren't there from the start is pretty obviously. You start with the fundamentals.. But at some point the end-user (or designers) you want to do more.. and are stuck at death end of the framework is to limited. So before optimizing the Tabbed UI, it's necessary to be sure the frame-working underpinning the Tabbed UI (the engine') can do what it expected to do long-term. If something totally new it's looking into a crystal ball, in this it's more comparing with others. I dislike investing in something which isn't future proof. Which means listing the issues designers/developers ran into already. And comparing Ribbons from other products with the Tabbed UI. To grasp what the framework should capable of doing. Next few approaches should be investigated to the options.. How the "proper" framework would look. Every framework has drawbacks by design (if its costs to build , maintainability, functional limitations). Obviously the choice can be to try to improve current Tabbed UI as far as possible, because the other framework revision taking to long/being to expensive. But this really should be a concisions decision :-). It will come back at you at some point Engineers can often build everything you want, within a reasonable time frame. Budget is one of the biggest constrains if you want to outsource the work. -- I personally less into the Tabbed UI and I don't think it's 'better'. Its simply different. But well I admit that lack of Ribbon/Tabbed UI doesn't help the transition from MSO. Especially if you're accustomed to the Tabbed UI. LibreOffice looks kind of outdated if are using MSO 2007 or later. So the Community might be not growing as fast as it could. And commercially (eco-system partners) might be not the best UI to ship with either. On the other hand, if there where major demand it would have been changed long ago :-). At the point people start to need paying for something the back-off.. The Toolbar UI being good enough. But well the Tabbed UI obviously better for touch screen usage (tablets and such). But unsure where the technology is going. Touchscreens still a thing in 5 or 10 years?
(In reply to Mike Kaganski from comment #123) > Reading through the heated discussion, I see the recurring motive in the > proponents of the change: "we must attract new users". > > I see why me personally could be motivated by that: I work for a commercial > community member (Collabora), and our business indeed would benefit from > increased user base of LibreOffice, so that increase by itself could be a > goal. But what is others' motivation to demand *just that*? > > I always had an impression that FLOSS *projects*, unlike commercial vendors, > should not be motivated by "get more market share! drag people from other > software! consider every alternative a competition!" attitude. I always > thought that FLOSS should provide something that the project feels unique > distinctive feature(s), so that others could use *if they also share the > vision that that is important distinctive feature*. And consider all > alternatives as welcome diversity. > > Is there something in the project (not in some its members, that may and > should have own goals) that forces us to seek new users with passion, > requiring doing everything just to make the increase happen? Not "make it > distinctive and attractive", but "make it attractive by all costs, possibly > sacrificing the distinctive pieces"? Why should we seek new users? I can give you some reasons why. First, as an open-source project, attracting new users means that LibO would also potentially attract the eyes of developers that can contribute to the codebase among them. This would bring new blood, and provide more man-power for interesting projects. By using a dated UI paradigm for Office suites, younger people won't even be bothered with looking at LibO. It will look dated to them. Second, I assume the purpose of LibO is to attract users to open source software. To provide solid alternatives to closed source, commercial software. Not only to prevent vendor lock-in, but also to promote real open standards. The more users are attracted to LibO, the more open standards will be used instead of proprietary formats of MS (or fake open standards like OOXML). I would assume that this is common knowledge to any LibO contributor, or any open-source contributor for that matter. > > To clarify: I do not see proponents of the switch saying "we have a *great* > and polished UI that we like so much, and that makes our productivity much > greater - why is it not default yet?". I see them saying "We have a > half-backed UI, with many shortcomings in it that we see, too; and we only > require to make it the default because that would resemble something else > and *attract users* that otherwise are so uninterested by our distinctive > features that they prefer paying money for another UI; and we don't think > that such users who require the UI to fit them so much, would immediately > see the problems of our similar but not polished thing. Attracting users it > the only thing that matters!". As per your comment of the distinctive features of LibO. New users don't want to re-learn how to use an office suite. They won't stick around to find those distinctive features if they feel like they're fighting against the UI, as compared with other office suites. This same kind of discussion happened with GIMP. It eventually adopted a single-window UI similar to Inkscape because it was easier for newcomers. The classic UI could still be selected. I would say that some people here need to come around to the fact that it's been too long since standard toolbars are not the standard anymore for Office suites. And some people should understand the overwhelming majority of LibO users are on Windows. Guess what's the most used UI in an Office suite in Windows? But yes, Windows users are second class users for LibO, I'm aware of that. Only in release 7.4 will it have support for the taskbar jump lists. A feature that exists since at least Windows 7. The LibO build instructions for Windows devs are terrible, no one also bothered to write a guide for WSL build instructions, and without a software that is interesting and attractive for Windows users and developers the state of the situation will only worsen. I am a proponent of the switch WHEN two blockers are solved: 1 - Extension support, 2 - Get a dev dedicated to work on the UI for proper support. I think the UI is already good as it is, and do not accept that you put words in my mouth like these: >"We have a half-backed UI, with many shortcomings in it that we see, too; and we only > require to make it the default because that would resemble something else > and *attract users* that otherwise are so uninterested by our distinctive > features that they prefer paying money for another UI; and we don't think > that such users who require the UI to fit them so much, would immediately > see the problems of our similar but not polished thing. Attracting users it > the only thing that matters!" I don't agree with the "many" shortcomings. I don't want solely to "attract users", I want something that makes me want to use LibO without pulling my hair out, and that's the Tabbed UI. I don't agree that the Tabbed UI is not polished. It is as polished as it could be made with the constraints of Glade and many of the decisions taken when making it had a rationale behind it. I know it because I helped organize that UI and the Groupedbar. And yes, to me attracting users is the only thing that matters. That's the whole point of this. If I release something to public I want the most people to use it. I released a dark theme for Zotero with that in mind, and it was my joy to try to fix the issues that new users detected and pointed out in it. It made it into a much better theme and attracted another dev which used it as the base to make an awesome dark theme extension. Why shouldn't the focus be on attracting new users? Answer me that. Also, if you guys think the Tabbed UI is so bad then it shouldn't even be available outside of experimental. You guys should advocate for its removal. If it's so terrible for you, why keep it? Where was your feedback and help when it was being developed?
(In reply to Pedro from comment #126) > Why should we seek new users? You're using a straw man argument there. Mike did not suggest LO shouldn't seek new users. > New users ... won't stick around to find > those distinctive features if they feel like they're fighting against the > UI, as compared with other office suites. New users do not feel they are fighting against the UI. Also, new users who know different kinds of UI do not need an app to only have one of these kinds in order to stick around. > This same kind of discussion happened with GIMP. It eventually adopted a > single-window UI similar to Inkscape because it was easier for newcomers. > The classic UI could still be selected. Actually, it's closer to the _opposite_ situation: We are arguing for using the same basic UI as Inkscape, and now GIMP, and most other apps in the world, which is easy enough for newcomers. (If MSO was using a GIMP-like interface, it would be the exact opposite). > I would say that some people here need to come around to the fact that it's > been too long since standard toolbars are not the standard anymore for > Office suites. MSO does not define "the standard". > And some people should understand the overwhelming majority > of LibO users are on Windows. Guess what's the most used UI in an Office suite in Windows? It's the UI that MSO uses, since it's the most popular office suite on Windows. But guess what's the most used UI in application on Windows overall? > Only in release 7.4 will it have support for the taskbar jump lists. A > feature that exists since at least Windows 7. The LibO build instructions > for Windows devs are terrible, no one also bothered to write a guide for WSL > build instructions, and without a software that is interesting and > attractive for Windows users and developers the state of the situation will > only worsen. Ok, now _that_ is an important grievance. I was not aware of this (as a QA person, not a developer) and it should be brought up in the relevant forums. > I don't agree with the "many" shortcomings. Well, you'll need to convince enough of us that the Tabbed UI is superior. > I released a dark theme for Zotero with that in mind, and it was my joy to > try to fix the issues that new users detected and pointed out in it. > It made > it into a much better theme and attracted another dev which used it as the > base to make an awesome dark theme extension. Why shouldn't the focus be on > attracting new users? Answer me that. To continue your analogy: If fixing those issues would cause less people to use your theme, what then? > Also, if you guys think the Tabbed UI is so bad then it shouldn't even be > available outside of experimental. You guys should advocate for its removal. 1. That's a false dichotomy. If we followed this logic, then we would think that the tabbed UI proponents are actually out to remove the standard UI altogether. You aren't, hopefully. Some people will insist on a different UI; I can disagree with their choice but live with it. Different strokes for different folks etc. 2. Given the RTL issues, I'm not sure the Tabbed UI should have been made available outside of experimental builds. Nobody consulted us (= RTL QA people) about this. > If it's so terrible for you, why keep it? Where was your feedback and help > when it was being developed? 1. Again, it is not terrible, it's more detrimental than beneficial. True, I did say it "sucks", but that's in relative terms. 2. This was a personal GSoC project of an intern; nobody consulted us about it. Although maybe you mean Mike and people more central than myself, in which case let them answer that...
I don't care about engaging in pointless discussions. I totally approve of (In reply to Eyal Rozenberg from comment #127) > (In reply to Pedro from comment #126) > > Why should we seek new users? > > You're using a straw man argument there. Mike did not suggest LO shouldn't > seek new users. > > > New users ... won't stick around to find > > those distinctive features if they feel like they're fighting against the > > UI, as compared with other office suites. > > New users do not feel they are fighting against the UI. Also, new users who > know different kinds of UI do not need an app to only have one of these > kinds in order to stick around. Okay, show me the evidence that proves otherwise. I am giving my personal experience. I don't use Impress and Calc because I feel like I am fighting against the UI plenty of times (in features not related to the Tabbed UI). > > This same kind of discussion happened with GIMP. It eventually adopted a > > single-window UI similar to Inkscape because it was easier for newcomers. > > The classic UI could still be selected. > > Actually, it's closer to the _opposite_ situation: We are arguing for using > the same basic UI as Inkscape, and now GIMP, and most other apps in the > world, which is easy enough for newcomers. (If MSO was using a GIMP-like > interface, it would be the exact opposite). Most other apps in the world besides the office suites that are used by the overhwelming majority of PC users in the world. LibO is an office suite. I couldn't care less about the UI paradigm of a vector design app, since it is not in the same space as LibO. You talk about strawman argument: you employ so many fallacies in your arguments that I can't even begin to count them. If you want to make it personal please say so. > > I would say that some people here need to come around to the fact that it's > > been too long since standard toolbars are not the standard anymore for > > Office suites. > > MSO does not define "the standard". MSO does effectively define "the standard". MSO is the de facto standard when it is the most used suite in the world. Your hurt feelings don't change this. > > And some people should understand the overwhelming majority > > of LibO users are on Windows. Guess what's the most used UI in an Office suite in Windows? > > It's the UI that MSO uses, since it's the most popular office suite on > Windows. But guess what's the most used UI in application on Windows > overall? I don't care what is the most used UI in applications on Windows overall. I care about the competitors relevant to LibO. You don't because you personally don't like it, just as you don't like hamburguer menus and other things. You avoid making comparisons with the REAL targets of LibO because you dislike this fact. You make up that LibO mainly competes with other FLOSS office suites when its clearly stated goal is: >We seek to eliminate the digital divide and empower all as full citizens, support the preservation of mother tongues, and avoid proprietary software and format lock-in. https://www.libreoffice.org/about-us/who-are-we/ Is LibO objetive to release users from the evil clutches of KOffice or AbiWord? Do we want to save users from the clutches of Adobe Photoshop or Mendeley or video editors with menubars? Stop being intelectually dishonest in your arguments. The purpose of LibO is to target users of proprietary software and to spread open formats. MSO is the antithesis of LibO and the purpose of LibO is to free its users from MSO proprietary formats. You don't do that by not catering to the userbase of Microsoft Office. > > Only in release 7.4 will it have support for the taskbar jump lists. A > > feature that exists since at least Windows 7. The LibO build instructions > > for Windows devs are terrible, no one also bothered to write a guide for WSL > > build instructions, and without a software that is interesting and > > attractive for Windows users and developers the state of the situation will > > only worsen. > > Ok, now _that_ is an important grievance. I was not aware of this (as a QA > person, not a developer) and it should be brought up in the relevant forums. > > > I don't agree with the "many" shortcomings. > > Well, you'll need to convince enough of us that the Tabbed UI is superior. I'm fully aware that you won't take your head out of the sand because it's more important to win an Internet discussion than being productive. Go back and read the mission statement of LibO. If you are in denial and don't want to achieve that goal because your personal preference of UI is more important to you, then you are not the kind of person I have to convince. > > I released a dark theme for Zotero with that in mind, and it was my joy to > > try to fix the issues that new users detected and pointed out in it. > > > It made > > it into a much better theme and attracted another dev which used it as the > > base to make an awesome dark theme extension. Why shouldn't the focus be on > > attracting new users? Answer me that. > > To continue your analogy: If fixing those issues would cause less people to > use your theme, what then? Lol. > > Also, if you guys think the Tabbed UI is so bad then it shouldn't even be > > available outside of experimental. You guys should advocate for its removal. > > 1. That's a false dichotomy. If we followed this logic, then we would think > that the tabbed UI proponents are actually out to remove the standard UI > altogether. You aren't, hopefully. Some people will insist on a different > UI; I can disagree with their choice but live with it. Different strokes for > different folks etc. > 2. Given the RTL issues, I'm not sure the Tabbed UI should have been made > available outside of experimental builds. Nobody consulted us (= RTL QA > people) about this. > > > If it's so terrible for you, why keep it? Where was your feedback and help > > when it was being developed? > > 1. Again, it is not terrible, it's more detrimental than beneficial. True, I > did say it "sucks", but that's in relative terms. > 2. This was a personal GSoC project of an intern; nobody consulted us about > it. Although maybe you mean Mike and people more central than myself, in > which case let them answer that... You can clearly see the bias you have in this. You are entrenched. The Tabbed UI was not a GSoC project. It took a year and a half to make by Andreas Kainz and was built on top of contributions of others. I assisted him. I opened a multitude of bugs when we were developing. You didn't assist in this. It's easy to criticize from the outside having done nothing to make it better. Windows users needed this. I as a Windows user that WANTED this, assisted as much as possible to make it as good as possible. And I am glad you don't have the weight to remove it. And yes, I want it as default on Windows. You can keep the standard toolbar as default for Linux. I want that after the issues I mentioned are addressed. I will stop wasting my time replying to you. You won the discussion by exhausting me. Bravo!
I am primarily a Windows user, and I do not (except for QA and UX feedback) use the TABBED UI. Compared to fully-functional Standard UI--Menu, Toolbar & Dialog supplemented with the Sidebar--the Glade based assemblages of UNO controls remain half-baked and ill-suited to task. The most appealing and "fresh" MUFFIN UI is the Contextual Single. Refactoring needed for the TABBED UI to be functional on Windows (comment 53) would require a lot of dev effort to implement the native code necessary. With similar native code and DE adjustments needed for Linux and macOS implementation of new default Tabbed/Ribon UI. In short a lot of dev effort for what is at best a questionable ask.
It has been interesting reading the comments about updating the user interface, but I believe that there have to be a few corrections first to the present user interfaces that are available. This would make LibreOffice look more professional and more acceptable to users. There are several spelling mistakes in the dialogs and menus. For example: Notebookbar should be Notebook Bar Groupedbar should be Grouped Bar Gluepoints should be Glue Points I have not gone through all the dialogs and menus, but I definite there are more spelling mistakes. In Draw, the status bar at the bottom of the main window uses Slide 1 of 2. This should be either Page 1 of 2 or Drawing 1 of 2. Page is preferred because drawings can have several pages. In Draw, the Properties deck on the Sidebar is labeled Slide. It should labeled Page or Drawing. Again, Page is preferred because drawings can have several pages. Regards PeeWee
(In reply to Eyal Rozenberg from comment #115) > If you want to make this argument, you need to address the objections of > those of us who are against it. Which you, so far, have not. TBH my main goal in joining this discussion is to raise awareness about the problems we have in the Tabbed UI, which is possibly the second most popular UI variant, after the Standard Toolbar. I don't really mind if it doesn't end up becoming the default UI. But I would love to see it receiving more love from devs. As for "addressing the objections", I feel that this discussion is too subjective for one to address the objections of other users who oppose the Tabbed UI. There's nothing I can say that will objectively prove that the Tabbed UI is superior and that is not even my goal here. What I would love to see is the Tabbed UI being improved, so that those using it have a better experience. Only after this happens we will be able to discuss if it should become the default. > Again, you're speaking as though this has somehow been agreed. On the > contrary - you should refrain from lobbying the ESC for grant money; that > would be a misrepresentation of the discussion here. My objective was never "lobbying the ESC for grant money". Regardless of the Tabbed UI becoming the default or not, these issues we currently face in the Tabbed UI need to be fixed and I see no problem in bringing this discussion to the ESC. Mind you that the discussion I would like to bring to the ESC is "the Tabbed UI needs improvements and fixes"... it's not my intention of saying that "the Tabbed UI should become the default", because as you said this decision would not represent the opinions expressed here. (In reply to Luke Kendall from comment #117) > Although my suggestion (comment 35) was largely ignored, or misunderstood, > I'll reiterate it. > > If you make the UI choice a very visible indicator that can be used to > switch to a different UI style, OR to revert to the previous UI the user had > been using, I think you can defuse this issue. Unlike commercial software > which has to go all in, you have more flexibility. I believe Luke's proposal would be the ideal solution, which would be to provide the user a more prominent way to change the UI variant. Maybe the user could choose this during installation. I'm saying this because in the university where I work, most students using LibreOffice do not know there's a Tabbed UI. Those who are not involved with LO development and news simply have not heard of it and the way to change it is not very prominent so that new users will easily learn that it exists.
(In reply to Rafael Lima from comment #131) > TBH my main goal in joining this discussion is to raise awareness about the > problems we have in the Tabbed UI, which is possibly the second most popular > UI variant, after the Standard Toolbar. > > I don't really mind if it doesn't end up becoming the default UI. But I > would love to see it receiving more love from devs. Then - I apologize for my tone. The bug title, after all, is "change the default UI", and that's how I (mis)-interpreted your post. Perhaps it would be a good idea to split off a meta bug tracking fixes and improvements to the Tabbed UI (and perhaps other UI variants (like tabbed compact and sidebar) - away from the fire-and-brimstone of the argument about the default UI. > Those who are not involved with LO development and news simply have not heard of it and the way to change it is not very prominent so that new users will easily learn that it exists. Bug 137931 seems like the solution to that problem...
I appreciate the passionate discussion. It shows how much interest and dedication you _all_ have in the project. To summarize, we more or less agree on the need to finalize the Notebookbar. Stuart's task list in comment 110 could be a start to get developers' wisdom into the discussion. Point is that we have a functionally pretty well-working Standard UI and we should balance the effort for a Ribbon-like interface with the benefit.
> > Those who are not involved with LO development and news simply have not heard of it and the way to change it is not very prominent so that new users will easily learn that it exists. > > Bug 137931 seems like the solution to that problem... Hi Eyal, I think this is a very reasonable request and was raised a while back, the interim solution was to highlight the UI availability as a tip of the day dialog. While better than nothing it does not have the same emphasis as a user choice on first startup. @Heiko : Is this something that could be revisited while future work is undertaken on the Tabbed UI? Also to this point: > To summarize, we more or less agree on the need to finalize the Notebookbar. > Stuart's task list in comment 110 could be a start to get developers' wisdom > into the discussion. Point is that we have a functionally pretty well-working > Standard UI and we should balance the effort for a Ribbon-like interface with > the benefit. Possibly the comments in 110 should be the basis of a 2 step approach for a longer term solution to aim for. However is there anything that could be done in the short term so we do not have to wait months or years for discussion and then developer support/funding? @Pedro makes a valid statement in comment 126. > I am a proponent of the switch WHEN two blockers are solved: > 1 - Extension support, > 2 - Get a dev dedicated to work on the UI for proper support. Is there anything that can be done to support this shorter term approach while the longer term one is planned for? Cheers, John