Not a fan. As the MUFFIN Notebook bar evolved *sufficient* labeling and and object tooltips were applied. Anything more would just clutter the UI.

IMHO not needed => WF

"Contextual groups" focuses on a different target group, see also https://wiki.documentfoundation.org/Design/Guidelines/ToolBar. But I don't see a downside from adding the labels except vertical size and in case of l10n horizontal scaling for short sections. Limited benefit OTOH as the individual commands are not labelled. In other words: Who needs the section with copy/paste etc. to be labelled Clipboard?

Hello all,

Thank you for your consideration of this request, firstly I realise that there are some negative issues around this, particularly additional vertical height that will be used.

If I may I would like to understand a little more of the rational for the comments posted?

'Not a fan. As the MUFFIN Notebook bar evolved *sufficient* labeling and and object tooltips were applied. Anything more would just clutter the UI.'

In this context what does 'sufficient' labeling mean? Which 'tooltips' are referred to?

An interesting observation, does having a textual description for a group of functionally related tools cause additional clutter? My personal opinion is no, it aids in discoverability as an end user may not know what the correct icon to select and aids usability because if I am trying to complete a task such as change a style or insert a graph etc I would be more productive in time by going to the appropriately named division/section in the toolbar. 

@ Heiko : 'But I don't see a downside from adding the labels except vertical size and in case of l10n horizontal scaling for short sections.'

Thank you, that is the only negative that I see with this request also. 

'Who needs the section with copy/paste etc. to be labelled Clipboard?'

This is an interesting point that you raise, in this example it could well be too much. However what are the essential functions of a clipboard? I would suggest that they are 'cut, copy and paste.' I am aware that you and certainly many others realsie that these are clipboard functions. The point I am trying to justify is you are highlighting to the user that these tools are related to that goal explicitly.

I think for consistency every division/section in the toolbar you would have to have a description, more 'complicated' sections like text formatting / alignment in Calc are not at all clear if you have little experience of using a spreadsheet. The point being that you are providing the end user with a textual clue.

If I turn to Impress for a moment and select the Tools tab can I ask what is the contextual grouping rational for the last four sections? I'm not inferring that these are not related only to highlight that there are 4 blocks of 6 small unlabelled icons, if you do not understand the functionality behind these icons how would you efficiently use them in your workflow? How do you easily draw to the attention of the user these are related to perform tasks?

 
Now please bear with me here, I do understand that the Tabbed interface as part of the Muffin menu is not a one to one implementation of the so called Microsoft Ribbon interface. It is however functionally similar and the contextual descriptions have been there since the first implementation in 2007, it was realised through usability testing this was a benefit for users and integral to their design paradigm.

In the below UI document produced by Microsoft these and justifications are explained better than I could ever hope to as a no UX expert  

https://docs.microsoft.com/en-us/windows/win32/uxguide/cmd-ribbons

There is also some interesting information to the design decisions and usability focus from Microsoft's Mix2008 conference that might be interesting for those that have not watched before. 

https://www.youtube.com/watch?v=Tl9kD693ie4

I understand that this could be considered potentially as plagiarism or a possible disregard of previously discussed and implemented principles. If this is the case then I would suggest that under the tools or view tab (I do not know the name of the last section in the tabbed interface under the 'hamburger menu' the last part that changes dependent on the selected tab)you have the option to turn this contextual information off if people don't want it. Or even you could have this textual information switched off by default with the user then needing to proactively go and switch this functionality on. You could label it 'contextual grouping description' or something similar. 

I hope that you now understand some of the reasons why I feel that this additional contextual information would be a usability and productivity improvement to the tabbed interface and that you can take this request further for your consideration.

With best regards and thanks,

John Mills

Every control resident on a MUFFIN Notebook Bar (NB) will respond with its localized 'tooltip'; and at some point the 'Extended tips' and "F1 -- What's this" mechanism will also be restored ( bug 118148 and bug 120538 ).

The "Groupedbar Compact", and experimental [1] "Groupedbar" or "Contextual Groups" NB modes provide textual labeling of the groupings, and a group function "caption" in the Contextual Groups mode.

Otherwise, there is no reason to clutter the clean "Tabbed" mode NB UI with caption labeling that would impact the NB mode's layout and impose l10n translation effort with limited benefit.

Remains of limited merit and IHMO => WF 

=-=-=
[1] enable from Tools -> Options -> Advanced: 'Enable experimental features' checkbox. Select from View -> User Interface, or the MUFFIN mode's "hamburger".

Hello Stuart,

Thank you for that reasoned explanation,I however think we are talking about two two distinct ideas on discoverability. You refer to 'tooltips' and 'extended tooltips' and indeed if I hover my mouse over the icon I currently see the name of the icon and I think you mean in the future that I would see a more detailed explanation of the functionality when I hover the mouse pointer over the icon.

This is not the point that I was trying to make before. If I want a particular function in any of the constituent applications and do not know the icon in the currently implemented 'tooltip' workflow/search I could potentially have to hover my mouse over every icon in all of the 'tabs' until I find the correct description/tooltip. This to me is cumbersome and inefficient. Don't get me wrong that is a very useful feature to have and I will be happy to see the extended descriptions, it will however not make me find the functionality I require to perform the given task any quicker.

However, what I am explaining is for the icon groupings to have contextually grouped descriptions underneath. If I want design, for example, I need no knowledge of the icon pictorially, I simply navigate to the associated 'design' section efficiently and quickly. I would then use the 'tooltips' on a small number of icons to find the functionality required.

I think both of these methods for discoverability should work in tandem for the benefit of the user. Tooltips only is not efficient. If there is a technical reason such as the translation issue you mention then I can appreciate the rational for your decision. However I do not understand the description 'clean "Tabbed" mode NB UI.'

Is the tabbed compact mode NB UI 'cleaner' as it is smaller vertically? I think this is somewhat subjective based upon the end users needs and wants. 

As I commented earlier these descriptions underneath the grouped information sections could be made optional, my opinion is they are useful and add value to the interface by improving the speed and accuracy of discoverability by removing unnecessary requirements to memorize many icons. I hope that explanation makes sense?

I think this also supports the UX-discovery principles on the design wiki.

https://wiki.documentfoundation.org/Design/Principles  

ux-discovery
Users should be able to discover functionality and information by visually exploring the interface, they should not be forced to recall information from memory. [Source: Nielsen]  

Kind regards

The MUFFIN NB modes are Glade UI based assemblages of control objects--there is just a lightweight framework in place to support these UNO controls, exploiting their existing attributes.

Beyond what is provided in the Groupedbar NB mode already, what you request would require additional dev effort to extend the framework, and also design & documentation work to populate the "contextual" details of the NB groups.

You are of course welcome to implement to extend the framework.

But such visual annotation simply does not belong on the Tabbed NB UI which was implemented as a streamlined MUFFIN alternative UI to our full function Toolbars, object Context menus and the SideBar deck UI.

Hello Stuart,

Thank you for your response, I believe I understand your position clearer now.  

I would just like to clarify a point that you wrote:

'Beyond what is provided in the Groupedbar NB mode already, what you request would require additional dev effort to extend the framework, and also design & documentation work to populate the "contextual" details of the NB groups.'

I don't believe (please correct me if I am mistaken)that I am asking for anything beyond what currently exists in the contextual groups interface, at least technically. The proposal is simply that the height of the tabbed interface is increased by an appropriate amount for a label to be under the individual sections of the 'tab' thereby indicating that the icons in that section are contextually related to aid discoverability. The divisions would work similarly to those in the Contextual groups interface or the Groupbar(although there are clear differences of approach here)interface. In both of these UI interfaces the icons are grouped contextually to aid with task completion.

Regarding your previous comments about Glade, I certainly am not qualified to agree or disagree. Hence why in my previous post I indicated that the label in the tabbed interface should be added if technically feasible to do so. Having spoken to some of the design team members in the IRC channel I think that the proposal would have some support. 

I would envision the contextual details being similar to those found in Microsoft office as the broad breakdown of the tabbed interface is not too dissimilar if you compare them.


'You are of course welcome to implement to extend the framework.'

As a non programmer how does one go about supporting this effort? I have seen this request relatively frequently in Reddit postings for LO, when Mike Saunders was asked this question it was stated that there is no real mechanism for individuals as the majority of LibreOffice development work is conducted by 'ecosystem' partners.

With best regards

(In reply to John Mills from comment #7)
>... 
> I don't believe (please correct me if I am mistaken)that I am asking for
> anything beyond what currently exists in the contextual groups interface, at
> least technically. The proposal is simply that the height of the tabbed
> interface is increased by an appropriate amount for a label to be under the
> individual sections of the 'tab' thereby indicating that the icons in that
> section are contextually related to aid discoverability.  ...

Each Tab is labeled, an analog to our main Menu which can be suppressed, and that labeling is sufficient to the MUFFIN NB 'Tabbed' interface. Nothing more is needed, and this is a clean NB implementation suitable to task.

>... 
> I would envision the contextual details being similar to those found in
> Microsoft office as the broad breakdown of the tabbed interface is not too
> dissimilar if you compare them.
> 

Sure, but we are not obliged to implement the UI designs of other office suites. And as the NB MUFFIN framework was designed within constraints of our UNO controls, devs and folks hacking on the features work with the tools at hand--labeling for labeling's sake--is not provided in the framework. And most labeling is pulled as attribute from the UNO control. Some contextual sense is possible--and I am rather fond of work done on the MUFFIN NB 'Contextual single'. While the 'Contextual groups' NB mode provides a passing semblance to the MS Ribbon object model [1] it is not constructed with feature set MS  implemented their Ribbon with--notably lacking from our NB UNO framework is a work-alike to the MS RibbonLable interface. Labeling beyond attributes of the individual UNO controls is manually added by our NB designer/implementer. 

Because it must be manually coded if it is not necessary, or detracts from design/appearance, it is not included on our MUFFIN NB designs. 

=-ref-=
[1] https://docs.microsoft.com/en-us/visualstudio/vsto/ribbon-object-model-overview?view=vs-2019

(In reply to V Stuart Foote from comment #8)
> NB UNO framework is a work-alike to the MS RibbonLable interface. Labeling

s/RibbonLable/RibbonLabel/

Hi again,

I'll be brief, 

'Each Tab is labeled, an analog to our main Menu which can be suppressed, and that labeling is sufficient to the MUFFIN NB 'Tabbed' interface. Nothing more is needed, and this is a clean NB implementation suitable to task.'

Yes, (indeed I understand what the tabs have a name, if they didn't I would be considerably concerned about giving the software to any users) under the 'Home' tab I believe there are 46 icons separated into 6 broad sections, of these icons only 5 have names/text next to them, Paste, Clone, Clear, Table and Zoom. The others do not.

From my point of view unless you know what the icons represent it is a case of mouse over until you find the task you want to accomplish, that is if you know the name of the functionality. Clearly in some cases it is self evident, but certainly not for all, and having the contextual description below aids as it is evident similar icons are related. 

We will have to agree to disagree that it is 'clean NB implementation' and 'Nothing more is needed' if you consider providing additional contextual descriptions would make the interface less productive for LibreOffice users.


Oh and thank you for the technical description, I did not understand all of the intricacies but it sounded well reasoned and I broadly followed. I just want to be clear that I appreciate for the thought and work that goes in to this product by all the many volunteers.

kind regards,

John

No further opinions. Use case of the tabbed NB is to make users coming from Windows feel home not not improve learnability as it's the fact for the "Contextual Group" variant. So I agree with Stuart's WF (not blocking if someone wants to implement this but there is no need for enhancement).

Created attachment 162868 [details]
Section description MSO 2007 --> 2019 & LibreOffice Writer 6.4

Hello Heiko, hello Stuart,

Thank you for the consideration of this enhancement request, I understand that you have set the status to 'RESOLVED WONTFIX.' I understand your logic behind this, so this will be the last comment I make to this enhancement request as it appears the decision is now final.

@ Heike : You wrote above:

> Use case of the tabbed NB is to make users coming from Windows feel home not not improve learnability as it's the fact for the "Contextual Group" variant.

Thank you for this, I think it is clear from this statement that the primary intention of the Tabbed notebook bar interface is to be familiar to users coming from Microsoft Office, to make the transition to LibreOffice a little easier for them. 

Please take a moment to look at the screenshot that I have attached to this ticket. As you can see Microsoft office has had descriptions underneath their respective section of the 'Ribbon' interface. This has been consistent for 14 years since Microsoft office 2007 was introduced at the end of 2006.

These are not there for no reason, the designers understood that this helped their users. The primary reason I raised this request is not about discoverability, although that clearly is very important in the context of a complex piece of software such as LibreOffice.

The primary reason I raised the request is precisely for the reason that you stated. That is to make the transition for ex Microsoft Office users to LibreOffice considerably easier. The tabbed NB although superficially similar is not functionally equivalent because it does not aid the user in the manner that Microsoft Office does, i.e. support the usability of the interface.

In the future if you want to encourage users to migrate away from Microsoft Office to LibreOffice with the NB tabbed interface then it is advisable to understand why these descriptions are important to the working of the interface and have remained so for 14 years.

I want to finally say that I care deeply about the goals of the DF and the LibreOffice application and hence moving people from priority applications that do not respect their liberty. If it was not so then I would not spend my time writing these requests here. So once again thank you and the whole of the LO community on the hard work of providing software that fulfills an essential need.

With best regards,

John Mills

(In reply to John Mills from comment #13)
> The primary reason I raised this request is not about discoverability...

No objection if Andreas or someone else will implement this. But WF as this label is not urgently needed.

When I start with tabbed notebookbar I added the labels and than I removed them cause of the following reasons:

- Tabbed NB is NO 1:1 copy of MSO Ribbons
- LibreOffice has not so many settings than MSO
- Tabbed NB need way less vertical space than MSO Ribbons
- Compare to Ribbons, Tabbed NB can't shrink in height so vertical space is even more importend.

Goals of Tabbed NB:

- Home Tab most wanted commands and well known commands without label
- All other tabbs icon + label which mean compare to Standard Toolbar where you have only icon (label as tooltip) way better accessibility (at least for commands which wasn't used frequently)
- Regular layout for groups in tabbed NB
  - first item large icon + label on bottom
  - other items in two rows smale icon + label
  - NO group description string
- icon size follow system setting option

No group description string

- Group layout is always similar (easy to understand)
- Groups are 1 + 2 (+ 2) commands large (not larger)
- As commands has labels addition string will only add more strings
- I can't theme NB background in gerrit so description strings can only get opacity
- A lot of work for translators (NB is not the default layout)


I hope I could describe why I decided not add group strings. And I think it was the correct decision.

(In reply to andreas_k from comment #15)

> ... 
> I hope I could describe why I decided not add group strings. And I think it
> was the correct decision.

You did, +1

Sorry John, but in this point I agree with Andreas. We weighed this a lot and decided not to do it for the reasons highlighted by Andreas.