Created attachment 185289 [details] Styles Preview in Writer A Styles Preview widget was implemented in Writer's Tabbed UI to mimic the widget available in MS Word. This was a good idea, but the way it was implemented in Writer has a few limitations that I believe should be improved. First, in Writer we only show 3 styles at a time which is too few considering the high number of styles that a document usually contains. If the user relies on this widget to explore/discover the existing styles in a document, they won't have a good experience. See first screenshot to see the current widget and notice that it could be wider and occupy more space horizontally (the empty space is highlighted in the screenshot). In MS Word we can see 12 styles at a time and the Styles Preview extends to use all the horizontal space available in the ribbon (see second attached image). The second issue is that we should provide a better way to show all available styles. In MS Word there is a down-arrow icon in the Styles Preview that shows a grid with all available styles. This is great for discoverability and I believe we should have this grid in Writer as well (see third image). So in summary, what I propose is: 1) Implement the grid view of all styles 2) Allow the widget to automatically use the available horizontal space in its tab
Created attachment 185290 [details] Styles Preview in MS Word
Created attachment 185291 [details] Grid view of all styles (MS Word)
Not a fan. The Sidebar's Styles deck *already* provides treeview list of all styles -- with preview (default) or not. Expanding the 3 column w/scroll Styles widget on the Tabbed NB is not necessary. And the SB treeview already provides details a pop-out dialog might. The MUFFIN NB framework is not the MS Ribbon, it does not function like Ribbon (or really even look much like it). Waste of time to try to do so. The 3 column 'Styles Preview' suffices and increasing column count comes at expense of other Home tab entries when UI is dragged narrower. -1
(In reply to V Stuart Foote from comment #3) > Not a fan. The Sidebar's Styles deck *already* provides treeview list of all > styles -- with preview (default) or not. > The MUFFIN NB framework is not the MS Ribbon, it does not function like > Ribbon (or really even look much like it). Waste of time to try to do so. > The 3 column 'Styles Preview' suffices and increasing column count comes at > expense of other Home tab entries when UI is dragged narrower. I respect your opinion, but if we follow this line of thinking, than the Styles Preview (from the Tabbed UI) should not have been implemented in the first place. The fact that we also have this functionality in the sidebar is not a reason to not improve the Styles Preview in the Tabbed UI. My argument is that the current implementation is very limited and I honestly don't know what use case it serves for. The current Styles Preview is not good for discovering and applying styles, so this is why I resort to the sidebar to apply styles. The Styles sidebar is really good and I believe we should also have a good implementation of the Styles Preview for Tabbed UI users. Since we already have this widget in the Tabbed UI, we should seek to improve it and offer a complete experience. Otherwise I can hardly see myself using it.
(In reply to Rafael Lima from comment #4) > I respect your opinion, but if we follow this line of thinking, than the > Styles Preview (from the Tabbed UI) should not have been implemented in the > first place. I've said as much ;-) > The fact that we also have this functionality in the sidebar is > not a reason to not improve the Styles Preview in the Tabbed UI. > Maybe. Or, we could just dump the NB Tabbed UI... it is not and never can be fully functional--so we just disappoint MS Office users. > My argument is that the current implementation is very limited and I > honestly don't know what use case it serves for. The current Styles Preview > is not good for discovering and applying styles, so this is why I resort to > the sidebar to apply styles. > > The Styles sidebar is really good and I believe we should also have a good > implementation of the Styles Preview for Tabbed UI users. Guess we could simply provide a "more..." and just open the Stylist (i.e. <F11> pop open the SB deck). > Since we already have this widget in the Tabbed UI, we should seek to improve > it and offer a complete experience. Why? The 3 column grid and scrollbar exposes the previews. Otherwise <F11> launches the full treeview listing in the SB Styles deck.
OTOH, I agree with Rafael- the Tabbed UI should be familiar for users migrating from Windows/MSO and is supposed to work without sidebar. But besides the visualization defects it has also functional limitations in that you cannot create new styles. Stuart's "More..." is a possible solution - and ditching the whole Tabbed UI too.
(In reply to Heiko Tietze from comment #6) > ditching the whole Tabbed UI too FTR I don't think that "ditching Tabbed UI" should be an option. This would be too extreme and goes against what many users want. The current implementation of the Tabbed UI is good (not excellent), and we should seek to overcome its limitations, as discussed in bug 135501. As per this request, it's not only about minimizing the transition from MSO, but also about giving this widget more functionality. We don't need to "copy" exactly the Styles Preview from MS, but being able to show more styles and make them more discoverable would be great for users. Looking at the existing code, I believe this enhancement is technically possible, but would take a good amount of development time.
(In reply to V Stuart Foote from comment #5) > (In reply to Rafael Lima from comment #4) > > I respect your opinion, but if we follow this line of thinking, than the > > Styles Preview (from the Tabbed UI) should not have been implemented in the > > first place. > > I've said as much ;-) > > > The fact that we also have this functionality in the sidebar is > > not a reason to not improve the Styles Preview in the Tabbed UI. > > > > Maybe. Or, we could just dump the NB Tabbed UI... it is not and never can be > fully functional--so we just disappoint MS Office users. > > > My argument is that the current implementation is very limited and I > > honestly don't know what use case it serves for. The current Styles Preview > > is not good for discovering and applying styles, so this is why I resort to > > the sidebar to apply styles. > > > > > The Styles sidebar is really good and I believe we should also have a good > > implementation of the Styles Preview for Tabbed UI users. > > Guess we could simply provide a "more..." and just open the Stylist (i.e. > <F11> pop open the SB deck). > > > Since we already have this widget in the Tabbed UI, we should seek to improve > it and offer a complete experience. > > Why? The 3 column grid and scrollbar exposes the previews. Otherwise <F11> > launches the full treeview listing in the SB Styles deck. Here you are again advocating for removing a feature that an enormous number of people use, and that other contributors spent hundreds of hours working on with the tools available just because it wounds your aesthetics. The Tabbed UI should NEVER be removed. Learn to adapt to the times. It's been 15 years that such an UI paradigm has been implemented in Office suits. You have hundreds of millions of people that never even worked with a menu-based Office suite, and LibO NEEDS to cater to these people and adjust to the times. If you want to remove the current implementation, then by all means DEVELOP a new Tabbed UI or move on. You complain that it should be shelved because it has limitations. Here's a bug advocating to address one of those limitations and you are against fixing it. This flies in the face of all your previous arguments and just shows that most of them are bad faith arguments against the Tabbed UI. If you don't like it, DON'T USE IT. Nobody is forcing you to. Why do you want to force your preference on others??? As for this bug: +1 for Rafael Lima's request. Infinity -1 to removing the Tabbed UI.
(In reply to Rafael Lima from comment #1) > Created attachment 185290 [details] > Styles Preview in MS Word Yes, a great idea, I think this will be a big improvement for those that use the tabbed UI. Due to the tabbed UI not using the sidebar this is a good approach and it appears there is space for this.
(In reply to Rafael Lima from comment #7) @Rafael, Fair enough, and I realize this MUFFIN NB construct is released and so deserves additional dev effort. My "ditch it" was sarcasm. And by the way thank you Rafael for all your contributions over the years! Stuart "Doers decide..."
Please stop hiding comments from myself and Pedro, these are relevant to this bug report.
We discussed this in the design meeting. Improvements to the styles preview widget in the notebookbar is needed. The idea to have a More... option, could also be some kind of expander at the right bottom, might simplify the implementation but does not meet the user expectations. The proposed maximize function sounds like a low hanging fruit. The expand thing could be more challenging. Maybe split these topics into separate tickets.
As a user I find the current UX difficult to use. Changing multiple styles from "default" or "text body" to "Heading 3" or "Heading 4" is very challenging - each time I click on the line which I want to denote as a heading the style preview selects "default" style which scrolls it back to the top so and I need to scroll down again; this is really distressing for some reason. I would really appreciate a change to make the styles preview box expand to full width available. If you are discussing a larger redesign, I also miss ability to customise styles as these appear to be hard-coded; for example, I would like to add "Heading 5". For now I am applying a manual workaround by modifying `svx/ui/stylespreview.ui` file (for me on Linux it is in `/usr/lib/libreoffice/share/config/soffice.cfg/svx/ui/stylespreview.ui`) as follows: 1. In `<object class="GtkScrolledWindow">`, increasing the requested width, for me it is 1200: `<property name="width_request">1200</property>` 2. Replacing hard-coded `3` columns with `-1` to fit as many columns as possible in `<object class="GtkIconView" id="stylesview">`: `<property name="columns">-1</property>` I experimented with setting expand/fill/hexpand (to replace hard-coded `width_request`) and I think that none of these work because the size is set in code by `StylesPreviewWindow_Impl::SetOptimalSize` method implemented as `SetSizePixel(get_preferred_size());`).
Created attachment 186779 [details] Annoying scrolling behaviour when fully expanded Even with the workaround as described I still see some distracting scrolling behaviour: when I click on different styles the scroll window scrolls up or down (see attachment). I can manually disable scrolling for myself, but maybe the auto-scroll could be improved to minimise distractions. And/or maybe the "Default paragraph style" could be truncated with ellipsis after first line like ""Default..."?
Apologies, part of the scrolling behaviour issue appears to be already tracked in https://bugs.documentfoundation.org/show_bug.cgi?id=141335.
Some relevant other reports: * other ideas related to efficient use of space in the Tabbed UI: - bug 157580: visibility of elements based on space available, not just order - bug 154953: allow "sliding" the tab contents horizontally * general Styles widget improvements in bug 139429, in which I shared relevant screenshots comparing alternative office suites' behaviour with their Styles widget: - default look in attachment 194234 [details] - "expanded" look in attachment 194235 [details] Description of the attachments: - Top: MS 365. Shows a maximum of 3 styles, which can reduce depending on window size. Down arrow shows more styles in a dropdown list. - Middle: OnlyOffice 8.0.1.31. Number of styles adapts to window size, from 1 to more than 10. Down arrow expands to a multi-row grid that accommodates all styles. - Bottom: WPS 11.1.0.11719. Minimum of 3 styles, but can drag divider to show more. Like OnlyOffice, down arrow expands to a multi-row grid that accommodates all styles.
I agree with Rafael about the fact the current style preview is poorly designed. In addition to the fact that it is too limited horizontally and that you cannot expand it vertically, I don't understand why the name of the style appears twice (once with a standard font and one which is a real preview). I think the name of the style should appear only once with the right style preview. This would be cleaner and reduce the surface screen dedicated to a style.
In addition, when you use a 200% scaling on Linux/gtk3, the style preview is blurry.