I like the proposal of the Notebook toolbars in general I'm a big fan of the contextual grouped toolbar. So I make a mockup for Writer.
1. My idea is that the contextual groups are grouped according to the menu bar. Why?
Because you use a menu bar when you have a lot of features and you didn't have enough space in the toolbar(s). Good example Kate file editor didn't have a toolbar only a menu bar because ordinary you want to write a text file and when you need an action it's a feature you didn't have on the toolbar.
Because the LibreOffice users know where the actions are located in the menu bar. Add a new structure with grouped toolbars and hidden actions somewhere (like MS do) would solve at least problems for new users but not for existing ones.
Because when the group is called like the menu I can click on the group name and the menu bar entry pop up it's really easy to explain new and existing users.
2. Always same layout for each group
I know I like grids but one of the thing I didn't like in MS Word and the existing Writer examples are that you mix between two and three rows. So my proposal is ONE big icon at the beginning of each subgroup and than always 3 rows if there are no 3 actions available than it will also anchor according the grid.
3. Small toolbar mode
I also have an example of a small toolbar mode according to the same idea. You can see the small toolbar at the bottom of the picture. It will start with the name of the menu bar and than some important actions. Here also the group name is the menu toolbar drop down menu where you get all actions.
Problem of this the small toolbar layout is that you can't add the action name behind the action icon cause names are for the groups.
I'll prepare the .ui file for the contextual grouped toolbar and hope I get feedback if it's a good idea AND how I can add the drop down menu instead ONLY the group name.
Created attachment 131263 [details]
Contextual Group Toolbar Mockup
I'm starting editing the notebookbar_groups.ui file for writer look good so far.
Interesting GUI, fits well with the emerging MUFFIN concept.
And while good as a MUFFIN alternative, I kind of doubt this would be accepted by users as a replacement for the default toolbar.
Its gridded structure is just not as space efficient as multiple (and detachable) single button height toolbars, especially as we've now resolved bug 42029 to replace toolbar overflow chevron's menu list with a button pane.
thanks for the feedback.
About space efficient:
I will look at it in general I have to say yes it's not that space efficient the good thing is that I would make one "big" contextual grouped toolbar and one "tiny" one.
The good thing was that when I can use the menu bar as group number AND drop down menu I can save height (which is more importend than wide).
I will also think about the overflow chevron's menu concept and how I can use it for now I'm thinking more about a mix between grouped toolbar and sidebar. grouped toolbar for most used features and sidebar to show the available features. Why? because sidebar and the grouped toolbar has the same "concept" show features in groups/sections.
about the overflow chevron's menu concept I have the problem that it fit's maybe to toolbars where it's ok to hide features but at grouped toolbars the idea is complete different for me it's more give the use context and support and not ALL needed features.
e.g. File group: show open, save, pdf and preview
there is no print action there is an preview action, why? because before you print something you should have a look how the document really look. the preview update links and you will see error messages before you print the error message.
So it's kind of give the user the preview feature and when the preview is open you get all the print features like page layout, ...
Do I understand you correct that somehow, perhaps on click at the sections, the menu opens, being a full replacement the main menu? Interesting idea, and easy to implement. The problem is that we have View, for instance, on the third position but you consider it (rightly) as less important and place it somewhere in the east. Not a big issue when the main menu is off. But I wonder how you want to place all the buttons/icons on the toolbar. The space is limited. And what happens when the context switches, e.g. on click at an image?
Your "always same layout for each group"-rule sounds reasonable, on the one hand. But a big item attract a lot attention (e.g. Fits law) and need a respective functionality. What I really like is the split of styles into paragraph and character styles. Although you didn't made the big button a context menu that could work really well. Many users may not be aware of the different styles.
Big thumbs up from my side for the labels. That makes hardly to read icons easy to access.
(In reply to Heiko Tietze from comment #6)
> Do I understand you correct that somehow, perhaps on click at the sections,
> the menu opens, being a full replacement the main menu? Interesting idea,
> and easy to implement. The problem is that we have View, for instance, on
> the third position but you consider it (rightly) as less important and place
> it somewhere in the east. Not a big issue when the main menu is off.
Yes you understood the concept correct instead of an "stupid" Label for the groups I make the labels clickable and the full menu bar for e.g. view open. And yes the sorting of the groups didn't follow the menu bar structure 100%. I'm not sure if this is really that important and show also the origin menu bar doesn't make sense at this concept. Awesome that this could be implement easy.
> But I
> wonder how you want to place all the buttons/icons on the toolbar. The space
> is limited. And what happens when the context switches, e.g. on click at an
That's the reason I start configure the ui file to have a running prototype instead of an mockup.
> Your "always same layout for each group"-rule sounds reasonable, on the one
> hand. But a big item attract a lot attention (e.g. Fits law) and need a
> respective functionality.
Hope you can help me to find the right big item. I'm also thinking on link to the sidebar from the big item so by default only the grouped toolbar and when you click on styles you get the styles and formatting sidebar.
> What I really like is the split of styles into
> paragraph and character styles. Although you didn't made the big button a
> context menu that could work really well. Many users may not be aware of the
> different styles.
Instead of the context menu I link with the big styles button to the sidebar which is from my point of view better than 3 styles in the context menu. In addition there is the drop down menu with the different styles.
> Big thumbs up from my side for the labels. That makes hardly to read icons
> easy to access.
this is one of the big feature of the contextual toolbar. So I'd like to use this feature (see paste special)
I'll hope for as much feedback as possible to find a great solution. Thanks for reporting.
(In reply to andreas_k from comment #7)
> I'm also thinking on link
> to the sidebar from the big item so by default only the grouped toolbar and
> when you click on styles you get the styles and formatting sidebar.
Nah, two clicks with full context change. That would be awkward.
Created attachment 131423 [details]
LO grouped toolbar for writer with selected image extension
The windows size is 1920 px. I can't get it with 1280 px. As you can see the different groups have always similar layouts one big 32px action and than 24px icons in two rows. the two rows are center align.
The drop down action icons (with an arrow) are now 16px height. This is a bug they should have also the same size than the others.
Created attachment 131433 [details]
LO grouped toolbar for writer with selected table extension
now also the table view is finished. Screenshot is with 1920px.
Created attachment 131434 [details]
Writer Grouped Layout for 1920px size
First Default Group
Second Table Group
Third Image Group
now it has the functionality of the default notebook_group.ui but I'd like to add an group for Print, Draw, References, Review and View.
Created attachment 132062 [details]
Context toolbar for 1280px to 2560px
for 1280px the "needed" stuff will be shown and if you have a larger screen you will get other usefull stuff too.
Commenting on patch Ic7956e11ebe2edd8e1046c4695f92b3398036c2f:
* Underlined menus support the discrimination of those buttons from the ordinary NB content
* Mnemonics are unlike the menubar not accessible from any place but after F6
* Alignment of menu buttons and accompanying functions needs improvement (e.g. Format - Page Settings, References - Update All)
* Margins at the very left edge and at top would improve the layout
* Tools (right-most column) adds a lot of vertical space, white space for 90% of the NB
* "Show draw functions" could be replaced by "Insert basic shape"
Tested under Windows with Version: 18.104.22.168.alpha0+ Build ID: e175f9f4393eb3badd763fa5b1cdc5b3aabab0e4
andreas kainz committed a patch related to this issue.
It has been pushed to "master":
tdf#106035 update the contextual groupedbar full layout update
It will be available in 5.4.0.
The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
Created attachment 132827 [details]
Variants of the Groupedbar
From top to bottom: table, image, shape, chart, text
(In reply to Heiko Tietze from comment #13)
> Commenting on patch Ic7956e11ebe2edd8e1046c4695f92b3398036c2f:
> * Underlined menus support the discrimination of those buttons from the
> ordinary NB content
look good to me and work yes.
> * Mnemonics are unlike the menubar not accessible from any place but after F6
> * Alignment of menu buttons and accompanying functions needs improvement
> (e.g. Format - Page Settings, References - Update All)
> * Margins at the very left edge and at top would improve the layout
> * Tools (right-most column) adds a lot of vertical space, white space for
> 90% of the NB
> * "Show draw functions" could be replaced by "Insert basic shape"
I prefer TDF#107085