Navigation aids ("buttons" or "tabs" or etc) should appear below document (/ presentation/ spreadsheets/ etc) and above status bar. Examples: 1) PageMaker pages PageMaker has a page navigation mini-strip, where you can click on a page and the current view (normal/ web/ html source, etc) for that page is displayed. This strip also has LEFT and RIGHT arrows at either end of this strip, so that if there are too many pages, you can scroll the strip. 2) View switcher Microsoft Office products have view switcher widgets, to switch the document view to specific views (e.g. normal/ web/ html source, etc) Soon to come to LibreOffice (hint hint) is an entity viewing and or editing view(s) - see bug #101774, and DocBook/ XML editing views - see bug #101772 and bug #86846 When there are more than two views to choose from, the view switcher widget looks really sexy and reminds you how powerful and flexible your software is :) Ultimately this is just another location to put UI functionality, which some nostalgic old souls prefer (those who had the pleasure to use PageMaker for example), although with a keen eye to "not too high/ similar height to status bar". Finally, I personally think that all widgets should be able to display in discrete narrow or thin environment, such as something like the status bar. The widget api should make it easy for the widget developer to provide each of the following automatically, based on where the widget has been placed: - a menu item, a shortcut and an accelerator - a large toolbar button - a small thin toolbar button - a suitable sidebar and tearoff tool panel widget
This idea will not work in LibreOffice Writer. First of all we have a classic user interface that is familiar to the users, and they want to keep it. Using tabs below the content in order to switch the view is also not really up-to-date (actually very outdated and rejected because the controls are out of the visual focus). Writer provides view modes per main menu. What I miss a good reason to put much effort in this task. I mean do you have any problem switching the view using our method? Talking about "navigational aids" the LibreOffice way is to present them in the Navigator. Admittedly there is room for improvements (https://design.blog.documentfoundation.org/2016/07/31/how-the-navigator-may-support-object-handling-in-libreoffice-draw/) but it doesn't mean to change the interaction concept. So I close this ticket as WONTFIX. By the way, you may be interested in our new toolbar (aka notebookbar) that will add a lot of freedom. Learn more at https://wiki.documentfoundation.org/Development/NotebookBar
Not to "pile on" but concur with the WONTFIX. In Impress we've now removed the long present top positioned default "Tab Bar" GUI mode chooser which is what this is suggesting be adopted for all modules. And in Impress we've replaced the Tab'd mode chooser with a split-button--the "Display Mode"--button now handling both edit modes and master modes. If needed for changing modes (e.g. the Writer Web's Normal-Web-HTML source) additional "Display Mode" split buttons per module seem reasonable. Stuart
> do you have any problem switching the view using our [existing] method? In MSWord I got used to the convenience of editing a page in Normal/Print View, and switching quickly to another view and back again, by simply clicking the view button below the page. (MSWord has more views available than LO.) This would just be another or a custom toolbar, that could be placed at bottom rather than at top - the main difference I see from a regular toolbar, is that it would be thinner than a normal toolbar, that's all. Perhaps this is just a theme thing? Is it possible to have two different sized toolbars in the one running LO instance? We already have toolbars at top and side bar at side. I would not push/advocate for changing the default/easy/less-busy workspace layout for new users, but I would like a bit more customizability.
Re "additional "Display Mode" split buttons per module seem reasonable" - should this be suggested by changing the bug summary, or filing new bug(s)?
LO Calc, at least in 5.3.0alpha, already has this "navigation bar and tabs for sheets" type of toolbar/statusbar, below the normal view for sheets. I think when bug #101774 (named content) with its potential view(s), better html editing view, bug #86846 and presumably other possible views become available, this Calc like "navigation bar" may well be quite desirable. Please add feedback on these comments.
(In reply to Zenaan Harkness from comment #3) > Is it possible to have two different sized toolbars in the one running LO > instance? We already have toolbars at top and side bar at side. Developers can do everything (I'm not a dev). The question is effort and usability. And here we do not agree. Normal toolbars as used in LibO are part of the system advanced programming interface (API) and themed by the desktop environment. Hard to recode all functionality from the shell with perfect system integration. Keep also in mind that we support all major OS that have many different ways of look and feel. (In reply to Zenaan Harkness from comment #4) > Re "additional "Display Mode" split buttons per module seem reasonable" - > should this be suggested by changing the bug summary, or filing new bug(s)? Yes, we can do that. -> bug 101788 (In reply to Zenaan Harkness from comment #5) > LO Calc, at least in 5.3.0alpha, already has this "navigation bar and tabs > for sheets" type of toolbar/statusbar, below the normal view for sheets. Calc is very special in that not only one document is open at time but many spreadsheets. You will find a similar solution to what you expect in Draw where the layers are realized per tabs. Actually it is an abuse, and the proposal in the blog post I added in comment 1 deals with this fact.
> Calc is very special in that not only one document is > open at time but many spreadsheets. This is a very good point. Why are we forgetting users (like me) who are trying to cope with a 1200 page book? If I had some calc-like tabs at the bottom, each tab could be quick way to jump to a particular page - it's like "new window" but embedded behind the tabs - very clean and elegant way to provide one form of "dynamic bookmars" (dynamic, since each tab is another view - and each view can be "watching" any part of the document. For me this would be a wonderful feature :D > You will find a similar solution to what you expect > in Draw where the layers are realized per tabs. I have not used Draw. Ultimately, I say we should not cram "one size fits all UI" into "the only available UI" - but this is of course limitation of developer time at the moment - for example see bug #33232 (workspaces). When workspaces are available, why we would say NO/WONTFIX to navigation aid widgets like this bug proposes? Surely this would fit perfectly into the advanced UI customizability implied by workspaces in bug #33232 ? > Actually it is an abuse, That is a matter of opinion. Of course, genuine improvements notwithstanding, and new approach may well be better in that example, than "tabs == layers" - but why limit tabs to have to "== layers" ? see bug #33232 > and the proposal > in the blog post I added in comment 1 deals with this fact. That sounds like genuine improvement. I consider also calc-like navigation aids to be an "advanced user" or "power user" UI feature, and now that we have found bug #33232 I hope my argument is a little more compelling now.
> Developers can do everything (I'm not a dev). The question > is effort and usability. And here we do not agree. Can we get concensus that the navigation aids in this feature suggestion (as simply another navigation aid option) DO make sense in customized "workspaces" (perhaps for "advanced users", and therefore that this bug ought be say "low priority + new feature + depends on workspaces"??
(In reply to Zenaan Harkness from comment #8) > > Developers can do everything (I'm not a dev). The question > > is effort and usability. And here we do not agree. > > Can we get concensus that the navigation aids in this feature suggestion (as > simply another navigation aid option) DO make sense in customized > "workspaces" (perhaps for "advanced users", and therefore that this bug > ought be say "low priority + new feature + depends on workspaces"?? Not from my side. You may reopen the ticket and see if someone agrees with you. LibreOffice is F/LOSS meaning my opinion from the UX POV is just two cent worth (unless I argue well enough and convince people).
(In reply to Zenaan Harkness from comment #8) > Can we get concensus that the navigation aids in this feature suggestion (as > simply another navigation aid option) DO make sense in customized > "workspaces" (perhaps for "advanced users", and therefore that this bug > ought be say "low priority + new feature + depends on workspaces"?? Apparently no consensus, maybe consent .. However, when we arrive at the stage that we can implement customized workspaces, there will be abundant room and time for discussion. I might even join myself ;) So keep an eye on it!