I suggest to modify LibO in order to be able to dock the toolbars below or above the navigator as we can do with the stylist. If we had this feature, the user would be able to customize its UI a la IBM-Symphony with all toolbars on the left or on the right of the window. JBF
I guess this is no longer valid since we have the Sidebar from Symphony itself.
(In reply to comment #1) > I guess this is no longer valid since we have the Sidebar from Symphony > itself. Yes, but no, because the sidebar is not able, ATM, to contain any toolbar that the user may want. The main idea of this proposed enhancement is "toolbar container", not Symphony's sidebar. Best regards. JBF
+1
Adding UX-Advise to CC. Please, have a look at this issue as an enhancement of the sidebar. Best regards. JBF
I add my voice to Jean-Baptiste's. The current Sidebar is an annoyance. A better UI (use cases?) would certainly make it usable and allow the user to customize it.
+1 for JBF proposal
*** Bug 79622 has been marked as a duplicate of this bug. ***
As this has morphed into an enhancement of the sidebar GUI, moving earliest version forward to 4.1 release, and adding to the Sidebar META issue bug 65138
*** Bug 88306 has been marked as a duplicate of this bug. ***
I believe that if the sidebar was completed to its full extent, there wouldnt be a need to customize it. Its the same case for other sidebar oriented office suites (iWorks, Calligra). If a user doesnt want to see a particular section of it, he simply clicks on the the section heading and its hidden temporarily.
(In reply to Jay Philips from comment #10) > I believe that if the sidebar was completed to its full extent, there > wouldnt be a need to customize it... No even when fully realized with defaults, the capability for users to modify the GUI as preferred is a fundamental feature contributing to enhanced UX, and is something that we already provide. For example on toolbars we provide "Visible buttons" and the "Customize tool bar dialog". Also, any toolbar can be rotated from horizontal to vertical and docked as such. That flexibility in layout of the GUI (actions and arrangement) is what is not fully realized for the Sidebar. Providing efficient means to modify the fixed "screen space" of the Deck with customized content panels (either existing panels, or adding panels) would be as useful as current ability to manipulate toolbars. In fact, UNO API based macros could already extend the OpenOffice task pane, and now can address any panels of the the Sidebar Deck. We just have not made that obvious or efficient in the Sidebar GUI as it has been for toolbars. It is also not well documented. And, as suggested in this issue--ability for a user to efficiently add their own custom content panel(s) made up of button actions from various toolbars, or even of entire toolbars, is a reasonable for customizable GUI. Other needed customization features--e.g. bug 65351, bug 67230, bug 67770, bug 85905 etc. suggest there is a long way to go before potential of the Sidebar is reached. But for this all to be reliable, and for acceptable UX, we will also need to improve user profile backup and recovery. Currently customizations to Toolbars, and of any Sidebar layouts, are fragile and can not be reapplied when a user profile becomes corrupted and has to be reset. That mechanism for protection of profile (GUI layout and custom styles) is not yet implemented--issues of bug 52387, bug 64439--but would become even more important to the UX when both Toolbars and Sidebar panels are being more commonly customized.
(In reply to V Stuart Foote from comment #11) > No even when fully realized with defaults, the capability for users to > modify the GUI as preferred is a fundamental feature contributing to > enhanced UX, and is something that we already provide. I guess we will disagree on this point as i see the sidebar the same way i see a dialog box. It is built in a particular way that users cant modify. We can give them the option to no longer see a section, like we presently allow to no longer see a tab, but not with the rearrangement of elements within a section. > For example on toolbars we provide "Visible buttons" and the "Customize tool > bar dialog". Also, any toolbar can be rotated from horizontal to vertical > and docked as such. That flexibility in layout of the GUI (actions and > arrangement) is what is not fully realized for the Sidebar. With toolbars, you have a simple structure of a row of buttons/controls, so in that scenario, providing the ability to customize it has benefits. But those benefits dont always work, e.g. make the formatting toolbar vertical in writer and you wont be able to use the non-button elements like the style drop down, font name drop down or font size drop down. > And, as suggested in this issue--ability for a user to efficiently add their > own custom content panel(s) made up of button actions from various toolbars, > or even of entire toolbars, is a reasonable for customizable GUI. I guess this sounds reasonable, though i wonder about what kind of customization dialog would be appearing for them to implement this and whether they would be permitted to place those buttons wherever on the panel as they please. I dont really see the benefit of putting this in a panel when they could easily have it in a toolbar. I see panels as going beyond what a toolbar can handle, as you can add all the elements found in the dialogs into it.
*** Bug 91714 has been marked as a duplicate of this bug. ***
> I guess we will disagree on this point as i see the sidebar the same way i > see a dialog box. It is built in a particular way that users cant modify. > We can give them the option to no longer see a section, like we presently > allow to no longer see a tab, but not with the rearrangement of elements > within a section. I think this comes down to design philosophy, to a degree. As soon as I saw the sidebar, I thought "LO is allowing me to set it up like Pages. Sweet!" It meant I could *remove* all the toolbars, save for just a few functions, and then use bring up or dismiss the sidebar as I please. My goal is a minimum amount of visual clutter while still retaining the ability to bring up those functions I want (i.e., get as far away from MS Word as humanly possible). The sidebar seems to be the only option to do that, so being able to customize it would be ideal. > With toolbars, you have a simple structure of a row of buttons/controls, > so in that scenario, providing the ability to customize it has benefits. > But those benefits dont always work, e.g. make the formatting toolbar > vertical in writer and you wont be able to use the non-button elements > like the style drop down, font name drop down or font size drop down. And with the sidebar, you have several horizontal rows, so individual buttons could be loaded until there's no more room, and there's no problem with drop-down menus. From a visual standpoint, this isn't hard. (I have no idea what kind of programming goes into doing, so I won't presume.) > I guess this sounds reasonable, though i wonder about what kind of > customization dialog would be appearing for them to implement this > and whether they would be permitted to place those buttons wherever > on the panel as they please. Personally, I'd like a fluid space such that if you drop a button into it, that button is centred. If you drop a second button, they pop to an equal distance to each other. There would be a maximum number of buttons/drop-downs you could put on a row, and there would be a default set at load-up. Not unlike a toolbar. > I dont really see the benefit of putting > this in a panel when they could easily have it in a toolbar. You can dismiss the sidebar with a key combo *without* visually disturbing the document you're looking at, unlike toolbars which push the window when they appear. That's the benefit, at least to my mind. Ultimately, I want something that slides *out* of the window rather than pushing my document *in*, but a floating toolbar kinda sorta does that job, so that's what I'm working with. > I see panels > as going beyond what a toolbar can handle, as you can add all the elements > found in the dialogs into it. And a lot of us see the sidebar as the potential to not have to use the toolbars at all. That's the difference in philosophy, as far as I can tell. If you make the sidebar customizable, then we can both have what we want, I think.
(In reply to orion from comment #14) > I think this comes down to design philosophy, to a degree. As soon as I saw > the sidebar, I thought "LO is allowing me to set it up like Pages. Sweet!" > It meant I could *remove* all the toolbars, save for just a few functions, > and then use bring up or dismiss the sidebar as I please. My goal is a > minimum amount of visual clutter while still retaining the ability to bring > up those functions I want (i.e., get as far away from MS Word as humanly > possible). The sidebar seems to be the only option to do that, so being able > to customize it would be ideal. Yes i consider LO's sidebar the same as the sidebar in Calligra, iWork Pages, and IBM Symphony and want users who prefer to use it to have a similar UI layout of one toolbar at the top for file and input functions and the sidebar for properties. Calligra, Pages, and Symphony dont permit a user to modify the sidebar and according to the GSoC student developer who is working on the sidebar, he stated that it wouldnt be possible to allow a user to reorganize content on an existing tab. > And with the sidebar, you have several horizontal rows, so individual > buttons could be loaded until there's no more room, and there's no problem > with drop-down menus. From a visual standpoint, this isn't hard. (I have no > idea what kind of programming goes into doing, so I won't presume.) The sidebar has button, labels, textboxes, drop down lists, and many other controls and these controls are not placed in a grid like fashion where it would be easy to move them around. They are placed in their places using the glade UI editor and being able to expose such an ability for users to do the same would likely be impossible and quite complicated for regular users to use if it was possible. > Personally, I'd like a fluid space such that if you drop a button into it, > that button is centred. If you drop a second button, they pop to an equal > distance to each other. There would be a maximum number of > buttons/drop-downs you could put on a row, and there would be a default set > at load-up. Not unlike a toolbar. Yes if that functionality could be achieved, that would be great, but i dont believe that would ever be possible. > You can dismiss the sidebar with a key combo *without* visually disturbing > the document you're looking at, unlike toolbars which push the window when > they appear. That's the benefit, at least to my mind. Ultimately, I want > something that slides *out* of the window rather than pushing my document > *in*, but a floating toolbar kinda sorta does that job, so that's what I'm > working with. You can move a toolbar into a docked position where it wont disrupt the document window. > And a lot of us see the sidebar as the potential to not have to use the > toolbars at all. That's the difference in philosophy, as far as I can tell. > If you make the sidebar customizable, then we can both have what we want, I > think. If it can be achieved, i'm all for it, but believe it wont ever be possible without a major overhaul of how controls are placed in the sidebar. It would be great to here from some of the devs in the design team on how possible this is, so CCing Rishabh, Kendy and Bubli.
(In reply to Yousuf (Jay) Philips from comment #15) > but believe it wont ever be possible > without a major overhaul of how controls are placed in the sidebar. Well, if: 1) Some panel contains only toolbar buttons (i.e. no comboboxes, checkboxes etc. - except for those that have such thing in the toolbar). 2) All buttons are placed continuously in one container. 3) Nothing is hard-coded inside that panel's code (like the SidebarToolBox class we have now) In other words, you have a single toolbar inside a sidebar panel. In this case (in theory) it should be possible to let the user customize this panel, just like any toolbar. So while it would be impossible to customize predefined panels, one could add custom ones, and put there whatever commands he wants.
I agree with Jay (comment 12) that the sidebar is not designed for user customization. If you want shortcuts to your favorite command, you have the toolbars. Why not use them? I would close this issue as wontfix.
(In reply to Samuel Mehrbrodt from comment #17) > I agree with Jay (comment 12) that the sidebar is not designed for user > customization. Please see Laurent's work on bug 91806 for just how "customizable" (and receptive to Macro/Extension development) the Sidebar structure actually is. > I would close this issue as wontfix. Not a rational, nor justifiable, position.
(In reply to Samuel Mehrbrodt from comment #17) > I agree with Jay (comment 12) that the sidebar is not designed for user > customization. > If you want shortcuts to your favorite command, you have the toolbars. Why > not use them? Because the main utility of the sidebar is to allow to not use toolbars and then save room on the screen for the working area. Best regards. JBF
Created attachment 117630 [details] what a custom toolbar looks like
> You can move a toolbar into a docked position where it wont > disrupt the document window. Yes, I can do that *once*, and then I have to leave it there, taking up space in my field of view. What I *can't* do is bring it up and dismiss it at will without it pushing my screen up, down, left, or right. > Yes if that functionality could be achieved, that would be great, > but i dont believe that would ever be possible. It's almost possible now (see my attachment). All we need is a verticle separator instead of a horizontal one, and the ability to dock it with more than one column of buttons. > I agree with Jay (comment 12) that the sidebar is not designed for user > customization. And many of us are asking for it to be redesigned or to add a separate function that would allow us to do something not conceived of (or not pursued) by its designers. That's the point of a suggestion/request.
I support the comments by orion@orionkidder.org, Jean-Baptiste Faure and V Stuart Foote (Comments 18-21). The comments recognise a design issue which is about efficient and flexible use of screen real estate. I also appreciate that these concerns may be outside of the original design intentions for the sidebar (Samuel Mehrbrodt, Comment 17 and Yousuf (Jay) Philips, Comment 12). The original conception and development of the sidebar is clearly valuable and a credit to those involved - thank you! Achieving the full realisation of that value is what I think is driving the current discussion - discussion about how to take the sidebar further so that significant design issues are resolved. This is likely to make the sidebar a truly great feature. So, can we now move on, acknowledging that original design intentions were/are great and can evolve to resolve the now-clearly-evident design issues?
The question is also whether the sidebar is some kind of 'rich toolbar' or if it provides different functionality. We tried to address this question recently in the HIG but didn't come to a conclusion since not enough opinions were heard. The conventional toolbar provides shortcuts to frequently used functions. It is basically designed for Benjamin but used as well by Eve (but she prefers keyboard shortcuts). When you talk about the sidebar as kind of rich toolbar that means it is just another access to frequently used functions. And if we do so wouldn't users get confused by the same access of, for example, bold which is available at two places? Benjamin could wonder if it does the same, or if perhaps one is for direct formatting and the other for changing the style. An intuitive comprehension is needed where functionality is located. That's why the alternative access to the sidebar is in terms of frequently access to properties. The idea is to not just replicate what we have in the dialogs but to offer graphical shortcuts to the most relevant settings. For instance, rotation of an object can be done fine-grained with the need for input of values. But in most cases the user want to rotate to a certain degree. And to deal with this need we should introduce simple graphical controls, e.g. sliders. Another difference between toolbars and sidebar is the dependency from context. Sidebar content changes with the context, in some cases manually like (formatting) properties and styles & formatting in Writer. Other implementations have a 'local auto context' such as the new chart properties. (Of course there is harmonization needed.) Do we have a concept for this triple customization (context, selection, setting)? Back to topic: The first question was about having the ability of docking another toolbar next to the sidebar, which changed to the question if sidebars should be customizable. Presupposed we have a good layout manager nothing speaks against the option. But the feature to change the sidebar must not refrain us from designing an appropriate default. I'm not sure that we have it.
Created attachment 117655 [details] toolbar docked in sidebar area (In reply to V Stuart Foote from comment #18) > Please see Laurent's work on bug 91806 for just how "customizable" (and > receptive to Macro/Extension development) the Sidebar structure actually is. Looking at the bug description Laurent gave, the API will allow a programmable means of manipulating various aspects of the sidebar, like hiding the navigator tab button, moving the styles and formatting tab button above properties tab button, changing the title bar label of the properties tab deck, hide the character content panel in the properties tab deck, etc. but as Maxim stated in comment 16, "it would be impossible to customize predefined panels". (In reply to Jean-Baptiste Faure from comment #19) > Because the main utility of the sidebar is to allow to not use toolbars and > then save room on the screen for the working area. The sidebar's main utility isnt to eliminate all toolbars, but the properties tab deck is to be an alternative to contextual toolbars, as contextual toolbars were popping up and disappearing constantly in different locations and were altering a document's view area. (In reply to orion from comment #21) > Yes, I can do that *once*, and then I have to leave it there, taking up > space in my field of view. What I *can't* do is bring it up and dismiss it > at will without it pushing my screen up, down, left, or right. Yes it may take up space, for example to the right of the standard toolbar, but it doesnt take up space that your document was taking, so it isnt taking up your field of view. But if you wanted to bring up and dismiss toolbars, you have full screenmode (ctrl+shift+j). > It's almost possible now (see my attachment). All we need is a verticle > separator instead of a horizontal one, and the ability to dock it with more > than one column of buttons. Yes, as Maxim stated, it would be possible to create a new tab deck which could contain user customizable buttons that were possible to insert into toolbars, but this wouldnt permit the addition of buttons and controls found exclusively in the sidebar (e.g. 'above paragraph spacing' textbox in the paragraph panel of properties tab deck). > And many of us are asking for it to be redesigned or to add a separate > function that would allow us to do something not conceived of (or not > pursued) by its designers. That's the point of a suggestion/request. It would be impossible to add this functionality into the properties tab deck, as that deck is contextually sensitive, but adding as an independent new tab would be reasonable. If the intent of this enhancement is still according to JBF's description of being "able to dock the toolbars below or above the navigator", then i would suggest that toolbars be able to be docked above or below the sidebar's main interface, similar to how it is possible to dock a toolbar to various sides of the UI (see attached mockup). GIMP and other apps provide a similar facility of docking multiple stacked controls on their right side panel. ( https://bartoszstyperek.files.wordpress.com/2012/05/gimp28.jpg )
I don't know this has gotten so complicated... I would like to be able to drag sidebar buttons/menus in and out of the sidebar. That is all.
*** Bug 93203 has been marked as a duplicate of this bug. ***
I tried using sidebar, since it would allow me 2 more rows vertically. Quickly gave up on that sport since it didn't have all most used toolbar buttons and was making me slower. There is no point in asking devs to add buttons one by one in sidebar, on user request. Sidebar should be customizable so everyone can adjust it. Or at least, we should be able to add our own toolbars as one of sidebar "submenus".
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.
you can add uno commands to the sidebar and I don't see an additional advantage of stream there some toolbar xml files. modify .ui files with glade is fine no additional possibility needed.
(In reply to andreas_k from comment #29) > you can add uno commands to the sidebar and I don't see an additional > advantage of stream there some toolbar xml files. > > modify .ui files with glade is fine no additional possibility needed. How end-users can do that ? It seems to me that you answered at developer level, not for the end-user. The idea in my original proposition was to make the end-user able to dock any toolbar in the sidebar. Please explain how you can actually do that. Best regards. JBF
I agree with JBL in comment 30 and reopen this bug report as NEW. This is not about developer possibilities but for end users to customize the UI.
(In reply to Thomas Lendo from comment #31) > I agree with JBL in comment 30 and reopen this bug report as NEW. This is > not about developer possibilities but for end users to customize the UI. I agree there is utility to allowing a user their own customized SB Deck/Content panel, per module, to hold whichever UNO toolbar controls--button actions or dialog launchers--they choose to drag into it. Not populated by default and hidden (probably from the SB configuration menu). But when enabled, per module, it would need an entry shown on the SB Tab bar--and be recorded to LO user profile for persistence between sessions. Also these user Decks should honor os/DE default "minimum"/"maximum" SB widths--to keep normal SB UI stable. Guess this also needs a GUI to manipulate--meaning a new tab for SB (just these user Decks) on the Tools -> Customize dialog. I agree with the sound arguments that the "designed" Sidebar Decks/Content Pannels must not otherwise be affected. @Maxim, Samuel -- easy-hackable?
The request is about docking a toolbar at the same docking area where the sidebar is. Docking within the sidebar or customizing it like a toolbar requires effort like Notebookbars and is not MUFFIN-like. I would resolve the request as WF.
(In reply to Heiko Tietze from comment #33) > The request is about docking a toolbar at the same docking area where the > sidebar is. Docking within the sidebar or customizing it like a toolbar > requires effort like Notebookbars and is not MUFFIN-like. I would resolve > the request as WF. No the scope of this is broader than to simply dock the toolbars of the OP, which predated implementation of the SB, and became clearly an enhancement to place controls from toolbars into SB content panels. I've marked OP obsolete to remove the noise. Acknowledged that we can not move entire toolbars into the SB framework. But any specific UNO button/dialog control--as found on any toolbar or menu--could be placed onto a user's personal SB deck. We could support that user customization as reasonable alternative to using the SB API to build full SB Deck macros/extensions.