Description: I redesigned the LibreOffice Writer (Tabbed Compact) interface to make it look more modern and visually lighter. You can view the presentation at the following link: https://drive.google.com/file/d/17-P4rWUqcGZLvw4oiMfkM0XvRMA4GbMU Actual Results: . Expected Results: . Reproducible: Always User Profile Reset: No Additional Info: .
Created attachment 201126 [details] the PDF by the GDoc link
Please attach your ideas directly here, thanks
Sorry, but totally unrealistic. Project has no path to implement and we are limited to use of GTK+ and Glade based UI layout. The NB MUFFIN assemblages do not use native DE widgets, there is no development environment/library similar to the MS Ribbon API. Nor the hodgepodge of widget and extension to build the Google Docs UI. Some discussion of adopting native Qt widgets cross platform, at which point more refined control of the MUFFIN NB cross platform using Qt Designer as replacement for Glade can revisit the layout of the MUFFIN provided LibreOffice UIs. Cosmetic changes, e.g. colors and padding can be tweaked now, but the Notebook Bar MUFFIN assemblages are more limited than legacy menu, toolbar and dialog elements of the UI. -1
Hello Roman, First, let me thank you for taking the initiative of proposing a UI mode design (or redesign). This is an important contribution already, as it moves us away from the "this is what we got and we need to live with it" mindset. I mean, it might be that what we got is pretty good, but that should be challenged. Second, I must ask you for more mockups (or screenshots?) - as right now, I only see one mockup (the "before/after comparison" in the presentation). We really need some more. Specifically, what happens when we click the various tabs; and what happens when the screen is narrower. Finally, I'm not going to opine on what I think about this design, because first I have lots of questions! 1. Why did you choose to redesign the "Tabbed Compact" UI mode, specifically? That is, what's important about it, in your view? The two 'prominent' UI modes at the moment are Menus+Toolbars and Tabbed (a.k.a. Tab Bar). In fact, judging by your design principles (see also later questions), it seems you may be more interested in "Single Toolbar". 2. Why a redesign as opposed to just designing another UI mode with inspiration from an existing one? i.e. do you want to replace "Tabbed Compact", or is that not consequential? Regarding "Design approach and UX prorities"... 3. In Tabbed Compact, there are no menus, only tabs; so, how can "secondary actions go into menus"? This would make more sense if we were in the "Single Toolbar" UI mode. 4. You write that you aim for "simplicity for beginners". What kind of beginners are you thinking of? Younger users? Users who have not had experience with an office productivity suite? Or users who are beginning to use LibreOffice, and may otherwise be experienced? 5. What is your definition of "clean"/cleanliness of a UI? "Simplicity" of a UI? 6. Can you list som e "familiar patterns" which you consider favorably? 7. The UIs of Google Docs and MS Office are significantly different; Google Docs does not use ribbons, for example. MSO and OnlyO both have ribbons, but these ribbons have significant differences. How does this agree with your desire to adopt "familiar patterns"? 8. What do you consider to be the LibreOffice "brand colors"? 9. In your mockup (slide 4, "Before/After Comparison" you place direct-formatting controls on the toolbar, and remove all (?) style-related controls. Can you describe the rationale for this? Do you relate this to the principle of "simplicity for beginners"? 10. What do you envision as the interaction between this UI mode and the sidebar? 11. In the standard UI mode, one can choose whether buttons will exhibit an icon, text, or icon-plus-text; and the default is no-text - while the menus are textual. DO you want your new UI mode to be fully label-free, or do you see this as something the user should be able to toggle? If so, when and how? 12. In your mockup, the controls, or groups of controls, seem to be rather spaced out - more so than most other LO UI modes. Can you elaborate regarding this choice, and whether you see it as something basic, or just a customizable seeting? 13. Do you intend the controls on the toolbar to agree with the Desktop Environment / GUI framework's UI/controls style? So that switching VCLs will mean the toolbar looks different? Or - do you suggest a 'bespoke' toolbar in this UI mode, irrespective of the VCL?
(In reply to V Stuart Foote from comment #3) Stuart, if someone back in 2012 would file a bug saying that we need a tabbed UI mode, you might have raised similar objections. Not to belittle the implementation challenges, but - if people believe that this is a worthwhile design and of superior usability, then even if it is far from realization, it would serve as a future target, motivating potential work on widgets and libraries. After all, we are shipping the tabbed UI despite not having a library similar to the MS Ribbon API (and despite many shortcomings and bugs in what we do have).
(In reply to Eyal Rozenberg from comment #5) > (In reply to V Stuart Foote from comment #3) >> Sorry, but totally unrealistic. Project has no path to implement and we are >> limited to use of GTK+ and Glade based UI layout. >> ... adopting native Qt widgets cross platform, at which point... > > Stuart, if someone back in 2012 would file a bug saying that we need a > tabbed UI mode, you might have raised similar objections. Not to belittle > the implementation challenges, but - if people believe that this is a > worthwhile design and of superior usability, then even if it is far from > realization, it would serve as a future target, motivating potential work on > widgets and libraries. After all, we are shipping the tabbed UI despite not > having a library similar to the MS Ribbon API (and despite many shortcomings > and bugs in what we do have). Just stating facts! Spamming BZ with open RFEs and leaving unrealistic requests floating about does nothing to focus dev and community interest in moving the project forward or completing needed functionality. IMHO this remains a -1, either from design or as a UX issue.
Hi, this is my design for an updated Tabbed Compact. I tried to keep the original architecture while reducing visual noise and emphasizing the most important elements. I referred to the documentation at https://wiki.documentfoundation.org/Design/uk. Since implementation isn’t possible under the current conditions, I don’t think it makes sense to go into further detail.
Created attachment 201155 [details] Layout of Word Tabs in MSO365 Online and Microsoft Teams An outlook of the tab layout in MSO655 Online and Microsoft teams A simplified version of the standard MSO365 Word Ribbon/Tabs
(In reply to andriimuzhytskyi from comment #7) > Hi, this is my design for an updated Tabbed Compact. I tried to keep the > original architecture while reducing visual noise and emphasizing the most > important elements. I referred to the documentation at > https://wiki.documentfoundation.org/Design/uk. > Since implementation isn’t possible under the current conditions, I don’t > think it makes sense to go into further detail. I think it is possible to improve the tabbed compact layout. Attached to this report is a document that shows the structure of the Word tabs for both Microsoft teams and MSO365 online. I would suggest that instead of just modifying the tabbed compact view to increase the spaces between icons and sections that we try and "broadly" replicate what Microsoft have done with their ribbon. Notice how the use of popular functions are added. I think you are doing some sterling work @andriimuzhytskyi and you should progress as much as you are able to. The tabbed compact view could be a simplified view in the future for people that prefer more screen real estate and like to have easy access to the most frequently used functionality.
(In reply to andriimuzhytskyi from comment #7) > Hi, this is my design for an updated Tabbed Compact. I tried to keep the > original architecture while reducing visual noise and emphasizing the most > important elements. I referred to the documentation at > https://wiki.documentfoundation.org/Design/uk. > Since implementation isn’t possible under the current conditions, I don’t > think it makes sense to go into further detail. (In reply to V Stuart Foote from comment #6) > (In reply to Eyal Rozenberg from comment #5) > > (In reply to V Stuart Foote from comment #3) > >> Sorry, but totally unrealistic. Project has no path to implement and we are > >> limited to use of GTK+ and Glade based UI layout. > >> ... adopting native Qt widgets cross platform, at which point... > > > > > Stuart, if someone back in 2012 would file a bug saying that we need a > > tabbed UI mode, you might have raised similar objections. Not to belittle > > the implementation challenges, but - if people believe that this is a > > worthwhile design and of superior usability, then even if it is far from > > realization, it would serve as a future target, motivating potential work on > > widgets and libraries. After all, we are shipping the tabbed UI despite not > > having a library similar to the MS Ribbon API (and despite many shortcomings > > and bugs in what we do have). > > Just stating facts! Spamming BZ with open RFEs and leaving unrealistic > requests floating about does nothing to focus dev and community interest in > moving the project forward or completing needed functionality. > > IMHO this remains a -1, either from design or as a UX issue. Stuart, this person is trying to work on and improve the tabbed compact layout, your opinion on if this proposal is a a -1 for design of UX issue is somewhat immaterial. It is well known your personal disdain for the Microsoft UI, this bias is not helpful for those that prefer to use it. If there is a significant technical impediment that prevents this redesign or an approximation then that is one thing, to dismiss on anything else id subjective. This proposal to me looks about improving the layout to look more "modern" it uses different icons and slight layout changes. The proposals on slide 2 of the PDF document seem like valid improvements to me. If this can be done (or even partly) with the current limitations of the Glade assemblies then I only see this as a benefit to our users. so a big +1 for me.
(In reply to andriimuzhytskyi from comment #7) You have barely-answered just one of my questions. > Since implementation isn’t possible under the current conditions, I don’t > think it makes sense to go into further detail. There is, in fact, so little detail, that it I find it impossible to evaluate your proposal at this time. Suggest this be marked as NEEDINFO until Andrii has the time to provide more information.
(In reply to John Mills from comment #9) > I would suggest that instead of just modifying the tabbed compact view to > increase the spaces between icons and sections that we try and "broadly" > replicate what Microsoft have done with their ribbon. Notice how the use of > popular functions are added. @John, "There you go again...", I have no objection to the UI design ethos supported with WinUI 2/WinUI 3 API. What I have exceptional objection to is the nonsense that LibreOffice is well served by efforts to '"broadly" replicate' facsimile of it using GTK+ Glade assemblages of UNO controls. Until, and only if, we adopt some functional cross-platform UI widget that replicates function I will continue to object to the project putting more design and especially dev effort into GTK+ based UI assemblages--chasing unrealistic parody of MS or Apple delivered native code features. Mimicry is just that. Simply would be far better for project health and maintenance to strip MUFFIN out and return to fully implemented cross-platform menu, toolbar and dialog model augmented by the Sidebar framework.
(In reply to V Stuart Foote from comment #12) TBH, I think John is taking his criticism too far. That said - this is a _design_ proposal, not an _implementation_ proposal. A user can say "I want this-and-that command available", even though the implementation might be hard and different from what we have now - and it might still be a relevant bug if we identify a valid use-case; similarly, a designer can say "we should have our Tabbed Compact UI look like this", without being concerned about how that is to be implemented. This is just our bugzilla, it does not hold next month's deadlines. Your point about the weakness in our ability to implement something like this is well-taken. Finally: > Simply would be far better for project health and maintenance to strip > MUFFIN out and return to fully implemented cross-platform menu, toolbar and > dialog model augmented by the Sidebar framework. It would be easier to maintain, perhaps, but would not be better for project health, since meeting (some) users' basic UI expectations, as much as I dislike them, is important to project health.