I fully agree with Andreas. It's necessary to define work methodology as much as targets. IMO, we should come up with targets for UI/UX that go beyond simply offering new UIs.
I would define four topics where to work on: *1 - The Back-end, the tools that are used to make UI work. *In this case I believe that devs need to provide their feedback more. Right now we have notebookbar UIs which use Glade, and the legacy toolbars. IMO, for the future only one tool should be used. Thus, a migration of all UIs to the Notebookbar framework should be organized. This does not mean ending the user facing toolbar UIs, but simply creating toolbar UIs using Glade. This would simplify the work for adding support to multiple UIs in the future and decrease complexity. Plus, the Notebookbar is quite flexible for extensions developers, since by simply adding the Notebookbar support, extensions look good in any Notebookbar UI, if we make sure that the UIs are working correctly. a - Transition all UIs to Notebookbar, b - Add support for necessary features to Notebookbar, c - Add Notebookbar support to remaining modules (ex. Chart module), d - Polish Extension support in Notebookbar. *2 - Simplify and decrease the number of UIs on offer per platform. *IMO, currently we have too many UIs and some are redundant. I believe that choice should be offered to users but excess of choice can be overwhelming. For example, we have three distinct toolbar layouts - probably offering one is enough since differences between single toolbar, sidebar and double toolbar are minimal. As for the notebookbar UIs, the compact UIs probably make sense to use in mobile or online platforms. Also some of the notebookbar UIs are in need of work and iteration to remain as a choice. If no one actively iterates on the Contextual UIs they need to be removed since they're incomplete as they are right now. *3 - Improve UI/UX in specific OSes, polish visual niggles, adopt universal office suite shortcuts, uniformize the branding of the modules. *These are the "lower priority" details that always get pushed down because there's always something else to do and there's no dev that wants to waste their time implementing this. However, these are issues that can make LibO feel like a great software or something hastily put together. Examples: a - Correct the Notebookbar UI clipping issues in MacOS, b - Support Dark modes in MacOS and Windows, c - Support MacOS menus in top-bar (not sure how it's called), e - Consistency to module looks (ex. Calc color is green so cells selected should have a green highlight, not blue. Outline for selected text boxes in Impress being brown instead of light blue), f - improve theming support (ex. persona support per module - to adopt module color by default, better persona support in some Notebookbar UIs). d - Scroll bar smooth scrolling, e - Improve integration of Chart module and Calc module. It's very jarring to have to double-click on a chart to be able to edit it and something that does not occur with any other object in LibO. It's necessary to open the Chart module in Calc though. This is something that should change but I do believe it might be a lot of work. *4 - Uniformize tool usage between modules.* Not sure if this falls under UI but it definitely falls under User Experience: the lack of consistency in what some things do in different modules. Of the top of my mind: table support in Writer and Calc. I'm sure more people can think of others. Some of this would require a lot of coordination with devs willing to work with the design team. Or for the design team to develop their coding skills a bit more, which considering that it's mostly composed of unpaid volunteers, it's abiit hard to ask for more. On Sun, 16 Aug 2020 at 13:01, kainz.a <kain...@gmail.com> wrote: > Hi All, > > Thanks for coming up with this topic, Heiko. The idea came to my mind after > the discussion about a dialogue about the different UI / notebookbar > implementations, where we discuss reducing the notebookbar implementations, > ... I work very long on the different notebookbars and had always in mind > to find a good solution for users AND developers. Which means that if there > was a bug I made compromises cause there was no developer available, ... In > the end nobody knows what to do with all this work. So I think it would be > way more useful to make some targets and work on them instead of doing > whatever you want and in the end nobody wants it. > > My general ideas for goals for a 2 year plan are: > - find general UI solutions (HIG's) where ALL community members will work > on. > - define targets (meta bugs) where developers and designers will work on. > - reduce different UI layouts to simplify the UI. > > Some more specific goals: > - define the UI for desktop, mobile, tablet and web (LOOL) so that we have > a unify "brand/layout" > - have one theming engine for the different platforms which fit mobile, > desktop, online, color scheme, ... > > I'm happy to work on any goal doesn't matter if it's from community, CIB, > Colabora, ... > > cheers > Andreas_K > > > Am Fr., 14. Aug. 2020 um 16:54 Uhr schrieb Csongor Halmai < > cson...@halmai.hu > >: > > > Hi All, > > > > I don't know too much (khm. I don't know anything:)) about the internal > > structure of the LO code base. But the question is what I would like > > to see in 2 years so, if you don't mind, I let me go crazy and come up > > with wild ideas, regardless of how easy they are to implement. > > > > > > > > I think it is a waste of the developer resources to redesign the user > > interface every fifth year, when the fashion changes. What did work > > very well in the past, is the add-on system of Firefox. I would like to > > see something similar in LibreOffice. > > > > (I am talking about the first version of the FF addons, when there was a > > lot of freedom, not the newer model, when a lot of nice old addons > > don't work anymore.) > > > > > > It would be great if there was a separate code base in LO which > > manipulates the document itself and a sharply separated other one which > is > > responsible for the UI. They should communicate on an interface which > > makes it possible to write UI add-ons for LibreOffice in > > easier-to-learn programming languages, for example Python and/or > > JavaScript, not just C/C++/ > > > > In that case, the community would win a lot of competing UIs from > > enthusiastic developers and some of them would be really good. People, > who > > are experts of UIs but don't necessarily want to learn the deep secrets > of > > the LO code base, would be able to make their on add-ons, like > > thousands of Firefox add-ons made the browser really popular. > > > > After this structural change, people who know LO deeper, can focus on new > > functions, performance improvements, better compatibility and > > other useful things while people, who want to make spectacular UI, can > > focus on just the UI, without knowing too much about the internal > > parts of LO. > > > > There would always be one or two official UI packages which offers an > > acceptable balance between functionality, beauty and used resouces but > > people could choose 3rd party UI add-ons freely, from a LibeOffice add-on > > store. > > > > > > > > > > Disclaimer: I am writing this idea without having any clue what the > > current structure of the code base is and how complicated this change > > would be. Take this just as it is. As an idea which can be ignored if it > > is totally useless. :) > > > > Cheers, > > > > Csongor > > > > > > > > > > On 14/08/2020 06:45, Heiko Tietze wrote: > > > Hi all, > > > > > > other communities such as KDE [1] plan the work for next releases. This > > idea > > > also comes up repeatedly for LibreOffice; and while steering in a > narrow > > sense > > > is not possible, it make sense to have a common vision for the next two > > years. > > > > > > That's why Andreas Kainz suggested an IRC meeting. We should do this > > similar to > > > the question what topics to foster for next year's GSoC [2]. An example > > for such > > > a 2-year plan clould be to rework all property dialogs and to get rid > of > > tabs in > > > favor of a sidebar with text/icons (see tdf#113418; controversially > > discussed in > > > the design meeting today). > > > > > > Please think about where you see LibreOffice in 2 years and what you > > want the > > > design/UX group to achieve. I suggest to share the ideas first here. > > > > > > The meeting should be on Sep/02 at 6pm UTC / 20:00 CEST (Berlin) > > (replacing the > > > usual weekly meeting). We talk on IRC #libreoffice-design (bridged to > > Telegram). > > > > > > Looking forward your thoughts, > > > Heiko > > > > > > [1] https://community.kde.org/Schedules > > > [2] https://listarchives.libreoffice.org/global/design/msg09343.html > > > > > > > -- > > To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org > > Problems? > > https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ > > Posting guidelines + more: > https://wiki.documentfoundation.org/Netiquette > > List archive: https://listarchives.libreoffice.org/global/design/ > > Privacy Policy: https://www.documentfoundation.org/privacy > > > > -- > To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org > Problems? > https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ > Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette > List archive: https://listarchives.libreoffice.org/global/design/ > Privacy Policy: https://www.documentfoundation.org/privacy > -- To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/design/ Privacy Policy: https://www.documentfoundation.org/privacy
