Bug Hunting Session
Bug 114318 - The buttons layout could be context sensitive
Summary: The buttons layout could be context sensitive
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL: https://forum.manjaro.org/t/a-better-...
Whiteboard:
Keywords:
Depends on:
Blocks: Notebookbar Toolbars
  Show dependency treegraph
 
Reported: 2017-12-07 20:46 UTC by Alberto Salvia Novella
Modified: 2017-12-13 20:25 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
LibreOffice interface.tar.gz (3.48 MB, application/gzip)
2017-12-07 20:46 UTC, Alberto Salvia Novella
Details
Text context (120.38 KB, image/png)
2017-12-08 09:19 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alberto Salvia Novella 2017-12-07 20:46:52 UTC
Created attachment 138285 [details]
LibreOffice interface.tar.gz

The default buttons layout exposes most of the available functionality in LibreOffice, without discrimination.

I would be nice that it showed what was needed in the very moment, or constantly, and hid everything else.

This way the interface would be clean and explicit in what is valuable, without sacrificing functionality.

The attachement is a prototype of what I mean.
Comment 1 Heiko Tietze 2017-12-08 09:17:28 UTC
Quite interesting. Likely you are aware of our Notebookbar approach [1,2] where your idea would be a perfectly addition. 

Personally I think the total dependency on the context with no static element in the UI is not so good for learnability. And when the switch takes longer than 50ms you have to wait for the new UI (guess it takes about a second). But you will for sure find users who want a clean interface, maybe for reading primarily. And there is my second point: I strongly recommend to define the use case, scenario, and have a clearly stated concept (suggestion is to have it for what we ship in [3]).

So putting all together: great stuff but please as Notebookbar [4,5]. Join the NB-Telegram group if you want to discuss details.

Would suggest to resolve this ticket as INVALID.

[1] https://blog.documentfoundation.org/blog/2016/12/21/the-document-foundation-announces-the-muffin-a-new-tasty-user-interface-concept-for-libreoffice/
[2] https://design.blog.documentfoundation.org/2016/12/21/evolving-past-the-restrictions-of-toolbars/
[3] https://wiki.documentfoundation.org/Design/ToolBar#Notebookbar
[4] https://design.blog.documentfoundation.org/2017/01/16/diy-ui-how-to-create-your-own-notebookbar/
[5] https://kdeonlinux.wordpress.com/
Comment 2 Heiko Tietze 2017-12-08 09:19:50 UTC
Created attachment 138296 [details]
Text context

The initial tar.gz attachment contains the full .config/libreoffice/ user space. Basically, the design is a single toolbar layout reduced to the most relevant items and switching with context.
Comment 3 Alberto Salvia Novella 2017-12-08 13:04:27 UTC
Personally I feel that the notebook bar is over-engineering, and still needs to provide context.

The idea wasn't to only to organise things in a cleaner and more intuitive way. But to show what is needed, only when it's needed, in the exact place that is needed. So what's useful is explicit.

And for that just choosing the right button set serves well the purpose. As long as the user can fit the layout for their particular needs, it doesn't require that of a deep refinement.
Comment 4 V Stuart Foote 2017-12-08 14:55:13 UTC
(In reply to Alberto Salvia Novella from comment #3)
> Personally I feel that the notebook bar is over-engineering, and still needs
> to provide context.
> 
> The idea wasn't to only to organise things in a cleaner and more intuitive
> way. But to show what is needed, only when it's needed, in the exact place
> that is needed. So what's useful is explicit.
> 
>...

Hmm, the Notebook bars as an implementation of MUFFIN do not require context sensitivity--it can be provided but it not a basic tenant.

Such a highly dynamic GUI would be of questionable utility to users (Benjamin or Eve) but would be a horrible support burden if it could even be instrumented.

=> WF
Comment 5 Heiko Tietze 2017-12-09 07:42:36 UTC
(In reply to Alberto Salvia Novella from comment #3)
> Personally I feel that the notebook bar is over-engineering, and still needs
> to provide context.
>
> The idea wasn't to only to organise things in a cleaner and more intuitive
> way. But to show what is needed, only when it's needed, in the exact place
> that is needed. So what's useful is explicit.
> 
> And for that just choosing the right button set serves well the purpose. As
> long as the user can fit the layout for their particular needs, it doesn't
> require that of a deep refinement.

No question, the Notebookbar is in an early state. But your approach turns all known concepts upside down, and most users want to keep the known standard toolbars. Your proposal would be an alternative not the default- and that's ideally done as NB.
Comment 6 Yousuf Philips (jay) (retired) 2017-12-09 12:32:19 UTC
The contextual single notebookbar implementation intends to implement this same concept.
Comment 7 andreas_k 2017-12-09 13:59:14 UTC
Groupedbar (compact) is something like suggested.
Comment 8 andreas_k 2017-12-09 13:59:28 UTC Comment hidden (obsolete)
Comment 9 Heiko Tietze 2017-12-13 20:25:06 UTC
Thanks a lot for your submission. We discussed the proposal in the design meeting. and decided to not take it into the classic toolbar; there is also a very close Notebookbar pendant. But we suggest to make an extension out of it that serves the clearly existing but likely not too big group of users.