Bug 102070 - Menubar button to change the toolbar layout/mode
Summary: Menubar button to change the toolbar layout/mode
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.3.0.0.alpha0+
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevEval, topicUI
: 106630 (view as bug list)
Depends on:
Blocks: Notebookbar Toolbars
  Show dependency treegraph
 
Reported: 2016-09-12 09:47 UTC by Pedro
Modified: 2018-05-06 21:31 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
UI change button of KSO near the Update button in LO (67.02 KB, image/jpeg)
2016-09-12 09:47 UTC, Pedro
Details
Highlighted toolbar Layout button near to Update button (70.38 KB, image/jpeg)
2016-09-12 14:37 UTC, Pedro
Details
UI Change button in KSO (117.42 KB, image/png)
2016-09-12 14:39 UTC, Pedro
Details
menubar close button always active, and transient update button on a Windows build (23.71 KB, image/png)
2016-09-12 21:10 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pedro 2016-09-12 09:47:46 UTC
Created attachment 127269 [details]
UI change button of KSO near the Update button in LO

Hello,

In the following of the discussion of Bug 101249 (https://bugs.documentfoundation.org/show_bug.cgi?id=101249) I am opening this bug to know if it's possible to create a button that increases the visibility of the option to change the Toolbar Layout that will be introduced in 5.3 in the View --> Toolbar Layout menu.

https://vid.me/bpS3 --> video of ht behaviour

Is this feasible, considering that a few OSes integrate the Menu bar in the top bar (Ex. MacOS, Ubuntu)?

Best regards,
Pedro
Comment 1 steve -_- 2016-09-12 10:00:59 UTC
2 cents incoming:

I think this is a view option. Having the switcher button would just clutter the toolbar.

LO comes with the option that serves most users needs (the 2 row toolbar). If you want to switch, you can do that via the view menubar option (which is the correct place for this imo).

As an alternative the option could be in the LO preferneces > View, but honestly I prefer the menubar > view.

The switching process is a one time process that has no need for repeated action. Thus I vote against adding this as option to the toolbar.

I am not sure I understand what the screenshot should be pointing out. It would be helpful to mark the section of the screenshot which is relevant to this specific bug.
Comment 2 V Stuart Foote 2016-09-12 11:31:56 UTC
(In reply to steve -_- from comment #1)
> I think this is a view option. Having the switcher button would just clutter
> the toolbar.

I don't see it as necessary, but believe Pedro is proposing adding a button to a different "prominent" GUI element, not to an existing Toolbar.

> As an alternative the option could be in the LO preferences > View, but
> honestly I prefer the menubar > view.
>

Yes, would agree that in addition to the View -> Toolbars Layout menu, it should be added as a drop list to the Tools -> Options -> View: User Interface section.
 
> The switching process is a one time process that has no need for repeated
> action. Thus I vote against adding this as option to the toolbar.

Would agree, no need for a button widget on Toolbar (either standard tool bar, or a "special" toolbar just for a toolbar View split button).  However, suspect you underestimate the frequency folks would be changing their toolbar mode. Especially if we can not get the toolbars to assert per module stateful by user profile.
Comment 3 Pedro 2016-09-12 14:36:59 UTC
(In reply to steve -_- from comment #1)
> 2 cents incoming:


> I think this is a view option. Having the switcher button would just clutter
> the toolbar.

I  am not saying including it in the toolbar, but next to the Update button that shows up when an update is available in LO as I've written in the text and exemplified in the figure.
 
> LO comes with the option that serves most users needs (the 2 row toolbar).
> If you want to switch, you can do that via the view menubar option (which is
> the correct place for this imo).

My point is that having that option buried in menus will keep it out of sight of the common users who may not even notice that.

As for the double toolbar serving most user needs, that's besides the point. If that was the case LO wouldn't be constantly criticized in every release because of its dated UI. In case you haven't noticed in the past 13 years the overwhelming majority of Office suite users have been using different UI paradigms than a double toolbar.

And the UI team has been hard at work in creating and imrpoving three different UIs for LO.

> As an alternative the option could be in the LO preferneces > View, but
> honestly I prefer the menubar > view.
> 
> The switching process is a one time process that has no need for repeated
> action. Thus I vote against adding this as option to the toolbar.

Why is it a one time process? for you maybe, but what if an user prefers to use Sidebar in Writer, double toolbar in Calc and Single toolbar in Impress and wants to change the UI per module?

> I am not sure I understand what the screenshot should be pointing out. It
> would be helpful to mark the section of the screenshot which is relevant to
> this specific bug.

Will do.

What I am asking is the feasibility of creating a button next to the Update button (which sits on the Menu bar) and separate of the toolbar buttons.
This would achieve the following:
- Make the option to change between toolbar modes easier to reach (less clicks and more visible),
- Would not site on any of the toolbars.
- Would not be buried in a Menu, so normal users would notice it more.
- It would make the work of the LO UI/Design team more visible to the user and easier to be toggled on, instead of defaulting to a legacy UI and hiding the work done by so many people in the past year and a half under a Menu option (whichmost casual users avoid as much as possible).
Comment 4 Pedro 2016-09-12 14:37:53 UTC
Created attachment 127277 [details]
Highlighted toolbar Layout button near to Update button
Comment 5 Pedro 2016-09-12 14:39:53 UTC
Created attachment 127278 [details]
UI Change button in KSO
Comment 6 Yousuf Philips (jay) (retired) 2016-09-12 20:34:35 UTC
(In reply to steve -_- from comment #1)
> As an alternative the option could be in the LO preferneces > View, but
> honestly I prefer the menubar > view.

Not a good alternative place as only advanced users open the options dialog and there are different toolbar modes per module (e.g. there is no sidebar mode in impress and there is no single toolbar mode in draw)

(In reply to Pedro from comment #3)
> Why is it a one time process? for you maybe, but what if an user prefers to
> use Sidebar in Writer, double toolbar in Calc and Single toolbar in Impress
> and wants to change the UI per module?

Yes per module users may want to change it once or more until they are content with the mode and then they normally never change it again. With KSO, i only switch to the classic mode when i want to see their menu or toolbar structure, other than that, i stick with their ribbon UI.

Setting the necessary keywords to have a dev look into how difficult it would be to implement this, though i believe that it should be simple as we are already doing the same for the update button, though it maybe difficult to have a menu popup from clicking the button, which in that case we could always create a dialog for the switching if necessary.

I believe the update icon code is here.
http://opengrok.libreoffice.org/xref/core/extensions/source/update/ui/updatecheckui.cxx
Comment 7 V Stuart Foote 2016-09-12 21:10:37 UTC
Created attachment 127287 [details]
menubar close button always active, and transient update button on a Windows build

The menubar Close button and LibreOffice Update button widgets are hard coded in src, they are not .UI configured.

And placement onto the menubar is really not a very good part of the UI to try using for GUI configuration preferences.

=-ref-=
http://opengrok.libreoffice.org/xref/core/extensions/source/update/check/updatecheck.hxx#141

http://opengrok.libreoffice.org/xref/core/vcl/source/window/menubarwindow.cxx
http://opengrok.libreoffice.org/xref/core/vcl/inc/salmenu.hxx

of course GTK has its on twist on things.
Comment 8 Pedro 2016-09-14 10:39:36 UTC
"And placement onto the menubar is really not a very good part of the UI to try using for GUI configuration preferences."

It's a method of having a one way stop for UI configuration instead of having it spread around multiple dialog boxes and accessed in multiple Menu items.

For example, if I want to change the icon set, icon size, and toolbar layout I have to go to:
 Tools --> Options --> View to change icons,
View --> Toolbar Layout

These options should be readily accessible in the same module to allow for more intuitive and faster configuration so that I can quickly adjust the UI to my needs and preferences instead of having to dig around in completely unrelated modules.

IMO having this immediately visible to the user is crucial because it will become one of the strong and unique points of LO. The user can make it its own.
If you don't agree with having the button there, then I would suggest creating a completely separate Menu entry then.

But hey, if you don't want the excelent work done by yourselves in the past year and a half - to provide the users with UI choices - easily discoverable then that's on you.
If I had spent so much time doing this, and being fully confident in my work I would try to make as easily discoverable as possible instead of hiding it away in submenus to stick to a legacy UI that wasn't developed by the LO contributors.
Comment 9 Samuel Mehrbrodt (CIB) 2016-09-14 10:48:57 UTC
Havent read everything in here, but atm we shouldn't add any easy discoverable means to activate the Notebookbar. It is only a proof-of-concept currently and far from finished.

Please leave it hidden for now, as we did with the Sidebar in earlier days.
Comment 10 Yousuf Philips (jay) (retired) 2016-09-14 16:08:04 UTC
(In reply to Pedro from comment #8)
> These options should be readily accessible in the same module to allow for
> more intuitive and faster configuration so that I can quickly adjust the UI
> to my needs and preferences instead of having to dig around in completely
> unrelated modules.

True, see bug 80544.

> IMO having this immediately visible to the user is crucial because it will
> become one of the strong and unique points of LO. The user can make it its
> own.

It definitely is useful, but not crucial, as the user had the option to reorganize the toolbars previously, though had to do it manually.

> If you don't agree with having the button there, then I would suggest
> creating a completely separate Menu entry then.

Unfortunately that isnt a good idea, as changing the layout of toolbars isnt important enough to justify that.

> But hey, if you don't want the excelent work done by yourselves in the past
> year and a half - to provide the users with UI choices - easily discoverable
> then that's on you.

Yes we do want users to easily be able to switch the toolbar layout, which is why we didnt stuff this option in the Options dialog, but added it to the recently organized menu bar. Having a button on the menubar will possibly make this feature more easily discoverable, but there isnt any guaranteed method that will show this option to the user. What is the 'year and a half' you are referring to?

> If I had spent so much time doing this, and being fully confident in my work
> I would try to make as easily discoverable as possible instead of hiding it
> away in submenus to stick to a legacy UI that wasn't developed by the LO
> contributors.

Not getting what you mean by 'so much time', but if you are talking about the notebookbar, then it has been worked on for maybe 6 months. Toolbars are used in most applications, so i wouldnt call it a legacy UI and we have improved the toolbars during LO's lifetime.

(In reply to Samuel Mehrbrodt (CIB) from comment #9)
> Havent read everything in here, but atm we shouldn't add any easy
> discoverable means to activate the Notebookbar. It is only a
> proof-of-concept currently and far from finished.

The button isnt about easy discoverability of the notebookbar, but easy discoverability of switching the toolbar layouts/modes.
Comment 11 V Stuart Foote 2016-09-14 17:00:17 UTC
(In reply to Yousuf Philips (jay) from comment #10)
> (In reply to Samuel Mehrbrodt (CIB) from comment #9)
> > Havent read everything in here, but atm we shouldn't add any easy
> > discoverable means to activate the Notebookbar. It is only a
> > proof-of-concept currently and far from finished.
> 
> The button isnt about easy discoverability of the notebookbar, but easy
> discoverability of switching the toolbar layouts/modes.

No, I think what Samuel is concerned about *is* that we are already providing too much visibility to the NotebookBar before it has been fully implemented.  Like the Sidebar in its debut--the NotebookBar should probably remain an experimental feature rather than already being enabled by default and already visible from the View -> Toolbar Layout entries.

This obsession with making it "easily accessible" is premature.
Comment 12 Samuel Mehrbrodt (CIB) 2016-09-14 18:17:36 UTC
(In reply to V Stuart Foote from comment #11)
> (In reply to Yousuf Philips (jay) from comment #10)
> > (In reply to Samuel Mehrbrodt (CIB) from comment #9)
> > > Havent read everything in here, but atm we shouldn't add any easy
> > > discoverable means to activate the Notebookbar. It is only a
> > > proof-of-concept currently and far from finished.
> > 
> > The button isnt about easy discoverability of the notebookbar, but easy
> > discoverability of switching the toolbar layouts/modes.
> 
> No, I think what Samuel is concerned about *is* that we are already
> providing too much visibility to the NotebookBar before it has been fully
> implemented.  Like the Sidebar in its debut--the NotebookBar should probably
> remain an experimental feature rather than already being enabled by default
> and already visible from the View -> Toolbar Layout entries.
> 
> This obsession with making it "easily accessible" is premature.

Exactly, thanks Stuart!
Comment 13 Yousuf Philips (jay) (retired) 2016-09-14 19:39:40 UTC
(In reply to V Stuart Foote from comment #11)
> No, I think what Samuel is concerned about *is* that we are already
> providing too much visibility to the NotebookBar before it has been fully
> implemented.  Like the Sidebar in its debut--the NotebookBar should probably
> remain an experimental feature rather than already being enabled by default
> and already visible from the View -> Toolbar Layout entries.

Well the sidebar was an experimental feature in 4.1 before its debut in 4.2, so maybe the notebookbar should only be visible when the experimental checkbox is checked in the options dialog.

> This obsession with making it "easily accessible" is premature.

Well that doesnt change the fact of having the other toolbar modes easily accessible.

There is going to be alot of hype/discussion/retaliation around the notebookbar when 5.3 is released and people are going to try it and reporters are going to write about it and i'm assuming it will also be featured in the 'what's new' videos. So we better braise for impact.
Comment 14 Samuel Mehrbrodt (CIB) 2016-09-14 19:46:32 UTC
(In reply to Yousuf Philips (jay) from comment #13)
> Well the sidebar was an experimental feature in 4.1 before its debut in 4.2,
> so maybe the notebookbar should only be visible when the experimental
> checkbox is checked in the options dialog.

If you enabled the experimental options, only the menu entry to activate the sidebar became visible. Nothing more.


> Well that doesnt change the fact of having the other toolbar modes easily
> accessible.
> 
> There is going to be alot of hype/discussion/retaliation around the
> notebookbar when 5.3 is released and people are going to try it and
> reporters are going to write about it and i'm assuming it will also be
> featured in the 'what's new' videos. So we better braise for impact.

Not if we do not mention them in the release notes.
And I think we shouldn't before we have the same for all apps (we have ~nothing for Base,Math,Basic IDE atm).
And its really not ready to replace the current toolbars. we have no way to customize things or allow extensions to integrate.
Comment 15 Samuel Mehrbrodt (CIB) 2016-09-14 19:48:36 UTC
Also it might be worth bumping the major version to 6.0 if we release the Notebookbar/other toolbar modes, so I really think we should wait 1 or two releases before making it public.
For the enthusiasts it already is there to try out.
Comment 16 Yousuf Philips (jay) (retired) 2016-09-14 20:09:37 UTC
(In reply to Samuel Mehrbrodt (CIB) from comment #14)
> If you enabled the experimental options, only the menu entry to activate the
> sidebar became visible. Nothing more.

Didnt quite follow, but i'm saying that we could link the experimental options checkbox with the visibility of notebookbar entry in the toolbar layout submenu (.uno:ToolbarMode) and we would likely have to remove the notebookbar submenu (.uno:Notebookbar) from the view menu unless it can be hidden.

> Not if we do not mention them in the release notes.

Already mentioned in the release notes as it was GSoC work.

> And I think we shouldn't before we have the same for all apps (we have
> ~nothing for Base,Math,Basic IDE atm).

I doubt notebookbar is needed in math, as the toolbar is pretty much empty already, or for basic ide as devs dont care for a notebookbar interface. No idea about base as i havent used it or worked on its toolbars or menus. :D

> And its really not ready to replace the current toolbars. we have no way to
> customize things or allow extensions to integrate.

Thats why i'm suggesting it only be visible when experimental options is enabled, as it is unfinished.

(In reply to Samuel Mehrbrodt (CIB) from comment #15)
> Also it might be worth bumping the major version to 6.0 if we release the
> Notebookbar/other toolbar modes, so I really think we should wait 1 or two
> releases before making it public.

Yes bumping to 6.0 for the release of notebookbar sounds like a good idea, and i believe 6.0 is already scheduled to happen after 5.3.
Comment 17 Pedro 2016-09-15 10:08:09 UTC
I do agree that the Notebookbar should not be accessible untill it is considered to be usable enough at least in the three main modules (Writer, Impress and Calc) and maybe in Draw as well.

But that doesn't invalidate the discussion for making these default toolbar layouts already available to become discoverable.
But I guess that having them under the View Menu is already a lot better than having them buried in:

Tools --> Options --> View

I just wanted to see it even less buried. But if it's not feasible then I won't push for more.
Maybe move the selection of icon set and icon size to the View Menu as well then.
For visually impaired users it would probably be easier to change icon size if it was under the View menu which is much more accessible than under 3 submenus.
And the icon set would be another interesting option.

The issue then is that the View menu would have too many subcategories.
Comment 18 Heiko Tietze 2017-03-18 23:40:46 UTC
*** Bug 106630 has been marked as a duplicate of this bug. ***
Comment 19 V Stuart Foote 2018-04-30 16:17:24 UTC
Calling this resolved fixed with work on bug 115131 to elevate the Notebookbar modes (still experimental) onto the main menu as elements on the new View -> User Interface list.

Present on the main menu, and from Notebookbar menus, so no need for a GUI split-button object.

Desired visibility of the MUFFIN Notebookbar modes has been achieved.

=-ref-=
https://gerrit.libreoffice.org/49575
https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=5c573a2f7473bae7bb965ca36557cd1b0bf7b9c9