[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #40 from Heiko Tietze --- The topic was on the agenda of the design meeting. Tagged the opinions of individuals here with plus/minus and we have a tie. Having means to directly add the search term would be a great benefit (although I remember Tomaz commenting somewhere else that this modification requires some effort). But it comes on cost of space and we either accept the field to be hidden on small screens or remove many commands to make space. Placing the search field into the header bar as done by MSO is not possible. So we better create a dedicated search tab at the sidebar where a) commands are listed in respect to the position at the main menu (as of today), b) the commands are shown associated with the term whether in the label or the tooltip, and c) the search returns occurences in the document where the word is being used (the quick search function). This will effectively take the quick find into the sidebar. In request in this ticket, asking for a search field in the Standard toolbar, the recommendation is to close WF. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #39 from Mike Kaganski --- (In reply to Eyal Rozenberg from comment #38) AFAICT the OP opened a bug report *about that*, asking to have a *text field* tor the HUD instead of the button *that is only possible now* (mentioned in the bug report title since comment 11); and then you recommend the OP to file a bug report about that? If you imply that *originally* the bug was worded in a different way, that's what bug tracker is: people with different ideas and different understanding file what they want, and then the discussion transforms it into a reasonable shape, which is now exactly "about it". -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #38 from Eyal Rozenberg --- (In reply to Roman Kuznetsov from comment #11) > Because the UNO for it adds the button to the toolbar, but I would prefer > the text field Ok, well - why not open a bug about that? i.e. having a separate UNO command, or some kind of variant/option to the same UNO command, add the text field? That would be less controvertial... -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 Heiko Tietze changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=14 ||2931 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #37 from Mike Kaganski --- (In reply to Heiko Tietze from comment #35) Note that such a decision should at least depend on the availability on mnemonics (keyboard access) working with such a UI; e.g., when a menu is used (which is active with toolbar UI), you may use F10 (Alt) to access menu without mouse. Competition had never offered a UI without keyboard access to its commands. Also note that keyboard shortcuts (Customization) is unrelated here: what is required is keyboard-based navigation through the visible UI. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #36 from John Mills --- (In reply to Heiko Tietze from comment #35) > (In reply to V Stuart Foote from comment #32) > > @Heiko, please confirm the TDF position. Stuart > > TDF has no position, the team facilitates the work around LibreOffice. The > ESC usually gives favorable consideration to my recommendations, which I > take from user input, done at bug 135501. So I plan to change it (affects > new installation only). It's a hard decision Heiko, but in the long run, it will be the best one for the future of LibreOffice. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #35 from Heiko Tietze --- (In reply to V Stuart Foote from comment #32) > @Heiko, please confirm the TDF position. Stuart TDF has no position, the team facilitates the work around LibreOffice. The ESC usually gives favorable consideration to my recommendations, which I take from user input, done at bug 135501. So I plan to change it (affects new installation only). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #34 from John Mills --- (In reply to John Mills from comment #33) > (In reply to V Stuart Foote from comment #32) > > There are NO TDF plans to make the MUFFIN 'Tabbed' Notebook Bar the default. > > > > The LibreOffice Menu - Toolbar - Dialog w/ Sidebar will remain the primary > > (and supported) interface cross platform. Any divergence from that would > > require development effort and native code cross platform that is not > > feasible, nor justifiable. > > > > And this has *nothing* to do with this topic. "Discussion" here is off-topic > > and pointless to what is a valid enhancement request. > > > > @Heiko, please confirm the TDF position. Stuart > > > Not to be dismissive of your opinion but the muffin notebook bar tabbed > interface is the best option for new users coming to LibreOffice. The > 'classic' legacy interface is becoming an increasing detriment to the > adoption of LibreOffice. I do agree this is off-topic for this discussion, however, if there is a difference between functionality between the classic and notebook bar version then the default UI is an important consideration. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #33 from John Mills --- (In reply to V Stuart Foote from comment #32) > There are NO TDF plans to make the MUFFIN 'Tabbed' Notebook Bar the default. > > The LibreOffice Menu - Toolbar - Dialog w/ Sidebar will remain the primary > (and supported) interface cross platform. Any divergence from that would > require development effort and native code cross platform that is not > feasible, nor justifiable. > > And this has *nothing* to do with this topic. "Discussion" here is off-topic > and pointless to what is a valid enhancement request. > > @Heiko, please confirm the TDF position. Stuart Not to be dismissive of your opinion but the muffin notebook bar tabbed interface is the best option for new users coming to LibreOffice. The 'classic' legacy interface is becoming an increasing detriment to the adoption of LibreOffice. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #30 from John Mills --- Created attachment 180063 --> https://bugs.documentfoundation.org/attachment.cgi?id=180063=edit Possible location for the HUD? If there is not enough horizontal space at the top of the panel in classic mode could it be moved to the bottom of the LibreOffice Window as in the attached screenshot? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #29 from V Stuart Foote --- (In reply to Mike Kaganski from comment #27) > What if really use Find toolbar for that? With a "special" mode "search for > commands" instead of "search for text"? > Positioning the command search at the bottom (like Firefox's 'Find in page') was suggested for bug 91874. So sure, the Find toolbar might be pressed into service for feeding the dialog. But then for simplicity we'd suppressed the 'Navigate by' listbox on the Find toolbar, searching text values by default, yet keeping the Find code common for use in the Sidebar Navigator deck. Seems a slippery slope requiring a lot of rework. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #27 from Mike Kaganski --- (In reply to Pedro from comment #13) > Depicitng the Find toolbar as a potential HUD toolbar. What if really use Find toolbar for that? With a "special" mode "search for commands" instead of "search for text"? (Maybe it's a nonsense, I just saw the attachment 180056 wording ant figured that could be a possibility) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #25 from John Mills --- (In reply to Heiko Tietze from comment #23) > Just replied to your "...1600 x 900 has been a common resolution". Adding a > large dropdown either exceed the predefined maximum width - and would be cut > off for many users - or require to remove a lot interactions. Let's say all > insert functions. > > Since we want to make the Notebookbar/Tabs the default my take regarding the > classic UI is therefore WF. Regarding this statement: 'Since we want to make the Notebookbar/Tabs the default my take regarding the classic UI is therefore WF.' Is this now actually the direction that TDF intend to take? I think it makes a lot of sense but clearly there is disagreement. Is there a timeline for how long this migration will take? Cheers, John -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #24 from John Mills --- (In reply to Heiko Tietze from comment #23) > Just replied to your "...1600 x 900 has been a common resolution". Adding a > large dropdown either exceed the predefined maximum width - and would be cut > off for many users - or require to remove a lot interactions. Let's say all > insert functions. > > Since we want to make the Notebookbar/Tabs the default my take regarding the > classic UI is therefore WF. Hi again Heiko, What I wouldn't like to see is that this is rejected for the 'classic' toolbar with a promise this is implemented in the notebook bar interface and then that doesn't happen. I would like to see it in both and there is a benefit for users of LibreOffice if it is. If the display is below a certain pixel size can it simply not be displayed? Is the interface responsive enough that this could be done? It seems that the current 800-pixel limit is a detriment for serious changes to the classic UI. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #23 from Heiko Tietze --- Just replied to your "...1600 x 900 has been a common resolution". Adding a large dropdown either exceed the predefined maximum width - and would be cut off for many users - or require to remove a lot interactions. Let's say all insert functions. Since we want to make the Notebookbar/Tabs the default my take regarding the classic UI is therefore WF. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #22 from John Mills --- I should say 2560 x 1440 and not 1440 x 900. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #21 from John Mills --- (In reply to Heiko Tietze from comment #20) > https://gs.statcounter.com/screen-resolution-stats/desktop/worldwide > > 1920x1080:21.69% > 1366x768: 18.42% > 1536x864: 10.42% > 1280x720: 6.04% > 1440x900: 5.85% > 1600x900: 3.5% Hi Heiko, These only add up to 66% what are the missing 34%? It is very strange there is no 1440 or 4k (2160) displays listed. By having the HUD to the right like Pedro showed in his mockup how would that impact 800px display? Looking at that list only 24.5% are less than 800 pixels wide on the desktop. OS versions are cut off, at what point do you say modern applications should be allowed to be 800 or more pixels as a minimum for the UI to be displayed correctly? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #20 from Heiko Tietze --- https://gs.statcounter.com/screen-resolution-stats/desktop/worldwide 1920x1080: 21.69% 1366x768: 18.42% 1536x864: 10.42% 1280x720: 6.04% 1440x900: 5.85% 1600x900: 3.5% -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #19 from Roman Kuznetsov <79045_79...@mail.ru> --- (In reply to Heiko Tietze from comment #18) > https://www.w3counter.com/globalstats.php > > Top 10 Screen Resolutions > 1 800x360 6.52% > 2 1920x1080 4.99% > 3 1366x7684.97% > 4 915x412 4.74% > 5 896x414 4.73% > 6 640x360 4.42% > 7 780x360 3.96% > 8 812x375 3.26% > 9 844x390 3.20% > 10873x393 3.16% And it all are mobile devices, except 2 and 3 item in the list -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #18 from Heiko Tietze --- https://www.w3counter.com/globalstats.php Top 10 Screen Resolutions 1 800x360 6.52% 2 1920x1080 4.99% 3 1366x7684.97% 4 915x412 4.74% 5 896x414 4.73% 6 640x360 4.42% 7 780x360 3.96% 8 812x375 3.26% 9 844x390 3.20% 10 873x393 3.16% -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #17 from John Mills --- (In reply to Heiko Tietze from comment #14) > (In reply to Pedro from comment #13) > > I attached a picture of the Standard Toolbar with a potential HUD toolbar... > > You got a large display... HIG says: aim for 1280px (WXGA is common on > notebooks). I think the HIG needs to be examined again then if we can't change panels because of a requirement to adhere to 1280px, 1600 x 900 has been a common resolution for at least 5 years now, 1366 x 768 resolution even longer than that. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #16 from John Mills --- (In reply to Cor Nouws from comment #15) > (In reply to John Mills from comment #12) > > > A text field to search would be the ideal outcome, but if only a button to > > open the search is possible then go with that. Better to have something > > rather than nothing. > > My traditional PoV would be: there is the Help menu, that offers what people > need (and more). > My more modern personality would say: if it makes users life easier, and it > fits in the UI!, let's do it.. I think your modern personality is 100% correct on this one ;-) This is a feature that has the future potential to be really helpful and expand the usability of LibreOffice. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #15 from Cor Nouws --- (In reply to John Mills from comment #12) > A text field to search would be the ideal outcome, but if only a button to > open the search is possible then go with that. Better to have something > rather than nothing. My traditional PoV would be: there is the Help menu, that offers what people need (and more). My more modern personality would say: if it makes users life easier, and it fits in the UI!, let's do it.. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #14 from Heiko Tietze --- (In reply to Pedro from comment #13) > I attached a picture of the Standard Toolbar with a potential HUD toolbar... You got a large display... HIG says: aim for 1280px (WXGA is common on notebooks). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #13 from Pedro --- Created attachment 180056 --> https://bugs.documentfoundation.org/attachment.cgi?id=180056=edit Depicitng the Find toolbar as a potential HUD toolbar. In my opinion having by default the HUD only accessible by a keyboard shortcut effectively hides it away from the people that would benefit from it the most: novice users that don't know the location of all commands. Novice users use primarily the mouse and the UI instead of keyboard shortcuts. Yet the HUD is only accessible by a keyboard shortcut. Thus there is no way a novice user that does not even read the Release Notes of each new version know about this great feature. I know some people are allergic to implement reasonable well-thought UI paradigms if they were first implemented by Microsoft or Apple. But I believe I provided a decent reasoning about why this would be important. As for providing a HUD (or text field) in the Standard Toolbar or a button. I also agree with Roman that the text field is a better idea. And I don't understand what would be the blocker for this. As V Stuart Foote mentioned: this can be done by creating a HUD toolbar that could be enabled by default in the Standard Toolbar. I attached a picture of the Standard Toolbar with a potential HUD toolbar, based on the Find Toolbar in the position. Considering that the HUD toolbar is just a search box, it would occupy even less space as my mockup shows. But a similar box would have to be included in the Tabbed UIs. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 --- Comment #12 from John Mills --- (In reply to Roman Kuznetsov from comment #11) > (In reply to Eyal Rozenberg from comment #9) > > > I think I'm against. Reporter - why not just add a HUD on your own? Why do > > you believe it needs to be there by default? > > Because the UNO for it adds the button to the toolbar, but I would prefer > the text field A text field to search would be the ideal outcome, but if only a button to open the search is possible then go with that. Better to have something rather than nothing. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 148967] Include a HUD inside the Standard toolbar as text field (today you can add it only as button)
https://bugs.documentfoundation.org/show_bug.cgi?id=148967 Roman Kuznetsov <79045_79...@mail.ru> changed: What|Removed |Added Summary|Include a HUD inside the|Include a HUD inside the |Standard toolbar|Standard toolbar as text ||field (today you can add it ||only as button) --- Comment #11 from Roman Kuznetsov <79045_79...@mail.ru> --- (In reply to Eyal Rozenberg from comment #9) > I think I'm against. Reporter - why not just add a HUD on your own? Why do > you believe it needs to be there by default? Because the UNO for it adds the button to the toolbar, but I would prefer the text field -- You are receiving this mail because: You are on the CC list for the bug.
