[Libreoffice-ux-advise] [Bug 87078] Cross-reference dialogue in Sidebar
https://bugs.documentfoundation.org/show_bug.cgi?id=87078 Eyal Rozenberg changed: What|Removed |Added CC||eyalr...@gmx.com --- Comment #5 from Eyal Rozenberg --- > wouldn't it make sense to integrate the function into the navigator? Are you sure you want to maker the Navigator that flexible? Hmm... I wonder. Anyway, the first thing we'd need to do is have a filter textbox at the top of the Navigator's forest view. And then you'd need to arrange it so that the user could easily switch the "refer using" choice. A bit tricky. I suppose we could think of a "crossref mode" for the navigator; but I don't know how I feel about that, either. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 158541] simplify start-center document selection
https://bugs.documentfoundation.org/show_bug.cgi?id=158541 --- Comment #6 from Buovjaga --- (In reply to V Stuart Foote from comment #2) > Making an "on mouse over" document selection from the SC thumbnail views > would then be at odds with UI behavior on Menus and Toolbars and anywhere > else we have preselection highlights. Selected state for buttons usually indicates some feature has been activated and this can be true for multiple ones (Bold, Italic, Underline...). So the interaction with buttons is quite different from the Start Center thumbnails. Buttons are almost ten times smaller than the thumbnails, so the dual highlight effect in Start Center might appear as jarring to some users in comparison. Similarly, menus have a unique behaviour: if you click to open a menu and then hover over other menu items of the same level, the opened state will immediately switch to the hovered one. So compared to buttons, menus behave more like how steve envisions Start Center thumbnails should behave. In bug 158404 comment 20 I asked: (In reply to Buovjaga from comment #20) > Created attachment 191112 [details] > Screen recording of Start Center behaviour with patch making hover equal to > selection > > As we still only have the argument of uniformity, I would be interested in > hearing what is the problem with the behaviour shown in this video. > > Stuart: can you explain what is bad/annoying based on the video? I'm still interested in hearing about the badness. I made a Reddit poll that ran for 5 days and the result was 4 votes for the current behaviour and 7 votes for steve's proposal: https://www.reddit.com/r/libreoffice/comments/187p7l3/which_hover_interaction_in_libreoffice_start/ -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 133836] Autofilter enables deselect items automatically when typing a search
https://bugs.documentfoundation.org/show_bug.cgi?id=133836
--- Comment #30 from ady ---
(In reply to Heiko Tietze from comment #29)
> Turning it into "[ ] Add" ends up in a strange workflow where one
> has to select the checkbox first to get the intended result - otherwise all
> previous input would be lost.
Having "[ ] Add" (or some alternative nomenclature) is at least respectful of
the current behavior and workflow. A tooltip on it would add some clarity and
allow for users to discover it and try/test its effect. Such setting would have
to be remembered until the specific autofilter is canceled and it should be
independent for each column/field of the whole autofilter set. To be clear,
this is just a comment about it; I am not saying I am 100% convinced.
Some brainstorming, not having thought about the following thoroughly-enough...
A possible alternative would be to have an additional checkbox on the left of
each value (OFF by default), located to the left of the current one: setting
the additional check box ON [x] would "fix" the current status of the
already-available check box on that value (leaving it grayed out), whether it
would be ON or OFF. The new additional check box on each value would also
remain independent of the current "All" and independent of the search box. The
new additional check box would be cleared by a new upper ("Fix all" or
equivalent) check box located to the left side of the current "All" filter.
This is similar to the aforementioned "[ ] Add", but per-value. I guess both of
these could be implemented. This provides additional flexibility for the
possible different results of the filter, at the cost of more UI artifacts,
screen area, and also (potentially) additional clicks for the new behavior (but
not for the current behavior).
This all is only a *brainstorming* idea (not having thought about it
thoroughly-enough), not a suggestion. Clearly it would make the AutoFilter UI
heavier and wider. I'm not sure it would be intuitive "as-is" - I'd have to see
the resulting UI. Tooltips are essential. The default status and behavior
should remain as the current one.
Maybe the new additional check boxes (or whichever other alternative) should
also remain hidden (or not included) in the Autofilter feature, only to be
shown by some new additional new "Complex Autofilter" alternative, leaving the
current Autofilter feature without these changes. Both should share the basic
characteristics, in order to avoid branching code (with the maintenance
consequences). Again, brainstorming only.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 158541] simplify start-center document selection
https://bugs.documentfoundation.org/show_bug.cgi?id=158541 --- Comment #5 from V Stuart Foote --- I've said my piece on bug 158404 (while bug 158084 was fully resolved by shifting to 75% transparency) and have now passed this over for UX consideration. I'm a -1 to any merging of mouse over to become a selection action. It is up to others... -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 158541] simplify start-center document selection
https://bugs.documentfoundation.org/show_bug.cgi?id=158541 --- Comment #4 from steve --- Created attachment 191253 --> https://bugs.documentfoundation.org/attachment.cgi?id=191253&action=edit Pages template picker 2023-12-05 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 158541] simplify start-center document selection
https://bugs.documentfoundation.org/show_bug.cgi?id=158541 steve changed: What|Removed |Added CC||mikekagan...@hotmail.com --- Comment #3 from steve --- Here we go (again). I understand Stuart is not fond of this proposal, because the start-center would behave different from how toolbars behave. So far this is the only argument brought up against this proposal. I don't understand how that even is a valid comparison. The start-center is NOT a toolbar. If you think that, you are mistaken. Thus there is no reason it should behave identical to toolbars. Adding a screencast of how pages template picker behaves: it is simplified even further: there is no mouse over whatsoever. And guess what - it makes for great UI + UX. It is very simplistic speaks a clean design language and causes no confusion on the user side. Want to open a document, either navigate there with your arrow keys or mouse, select it and press enter Why is it so hard to make the most basic operations (selecting a template or document from start center) user friendly? It really is beyond me. Sorry, I am not sure I'll engage much further in this debate. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 158541] simplify start-center document selection
https://bugs.documentfoundation.org/show_bug.cgi?id=158541 V Stuart Foote changed: What|Removed |Added Version|Inherited From OOo |4.2.0.4 release CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||vsfo...@libreoffice.org Keywords||needsUXEval --- Comment #2 from V Stuart Foote --- No, when the Start Center is opened focus is onto the Main menu--not into the backing window for either Template or Recent Documents thumbnail views. Likewise on return from closeout of the last open document. "On mouse over" behavior is a distinct UI action from "Selection" cross platform and is correct on the UI of the Start Center. For keyboard navigation, on open or following an , will cycle into the thumbnail view backing window and then cursor movements will make selections--the same behavior on UI Menus and TBs. Making an "on mouse over" document selection from the SC thumbnail views would then be at odds with UI behavior on Menus and Toolbars and anywhere else we have preselection highlights. If alternative representation(s) of the thumbnail views, bug 95739 and dupes, ever happen the current on mouse over would be expected. The UI representation of the Most Recently Used (MRU) menu list with thumbnail views on the SC backing window was a GSOC 2013 project modeled on LibreOffice work for the Template manager UI both implemented with behavior of TB and menus, The SC thumbnail views went in for 4.2.0 release. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 158274] Impress setting list Position and Size is not consistent with what is done in Writer
https://bugs.documentfoundation.org/show_bug.cgi?id=158274 Stéphane Guillou (stragu) changed: What|Removed |Added Summary|Impress setting distance|Impress setting list |between bullets and text is |Position and Size is not |not consistent with what is |consistent with what is |done in Writer |done in Writer See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||2654, ||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=12 ||0905, ||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=65 ||003 Status|UNCONFIRMED |NEW Blocks||103407, 48799 Whiteboard| QA:needsComment| Keywords||needsUXEval Ever confirmed|0 |1 CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||stephane.guillou@libreoffic ||e.org --- Comment #1 from Stéphane Guillou (stragu) --- Thanks Jean-François. Regarding the Format > Bullets and Numbering dialog: The Impress dialog seems to be a mix between the "Position" and "Customize" tabs of Writer's Bullets and Numbering dialog. It's true that it is quite inconsistent between the two components. Regarding the editing of styles: (In reply to Jean-Francois Nifenecker from comment #0) > Note : This can NOT be done using the 'Outline N' styles. [...] > The Impress way is not consistent in that it should be done, IMO, using the > 'Outline N' styles. The was a recent conversation on a related topic in bug 157264, showing that it is probably common to expect these "Presentation styles" to behave just like Writer List style do (in modifying them and applying them). Currently, these Outline styles allow changing Numbering settings in the "Customize" tab for all different levels, regardless of which Outline style is being edited. So it makes sense to expect to also be able to change the "Size" and "Position" settings as well. So I see two issues here: A) Make the Format > Bullets and Numbering dialog consistent across components B) Make Position and Size settings available when editing Outline styles - which I think is supposed to be covered by bug 65003. This is in a way related to proper support of list styles in Impress/Draw, tracked in bug 152654. And general UI improvements of the Bullets and Numbering dialog are tracked in bug 120905. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=48799 [Bug 48799] [META] Impress Bullets and Numbering bugs (formatting and UI) https://bugs.documentfoundation.org/show_bug.cgi?id=103407 [Bug 103407] [META] Unify behaviour and functions across apps -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 156915] Cannot access document themes option using tabbed UI
https://bugs.documentfoundation.org/show_bug.cgi?id=156915 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org, ||mentoring@documentfoundatio ||n.org Keywords|needsUXEval |difficultyBeginner, ||easyHack, skillDesign, ||topicUI --- Comment #9 from Heiko Tietze --- Let's add it to the context menu for now. .uno:ThemeDialog needs to be added in sw/uiconfig/swriter/ui/notebookbar.ui (similar to MenuPage-Watermark) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 100585] Ordering of sheets with different direction changes when switching between them (RTL UI, not with GTK3)
https://bugs.documentfoundation.org/show_bug.cgi?id=100585 Heiko Tietze changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #20 from Heiko Tietze --- (In reply to Heiko Tietze from comment #19) > I would follow Eyal's suggestion in bug 157961 and make the tab position > depending on the UI language (and close this ticket). No objection, let's do it. Making this one a duplicate though to keep track of the relation. *** This bug has been marked as a duplicate of bug 157961 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 156598] Custom list numbering from DOCX import is not available in UI
https://bugs.documentfoundation.org/show_bug.cgi?id=156598 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | --- Comment #7 from Heiko Tietze --- Mockup is available, removing needsUXEval. Happy to revise if the solution needs to be down-scaled. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 156229] Calc- Select Categories in Theme does not apply changes to sheet.
https://bugs.documentfoundation.org/show_bug.cgi?id=156229 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |er...@redhat.com, |.freedesktop.org|heiko.tietze@documentfounda ||tion.org, qui...@gmail.com, ||vmik...@collabora.com --- Comment #9 from Heiko Tietze --- No further input, let's make this a topic for documentation. (The "Card" cell style is inserted after a theme has been picked.) The dialog is a wizard, check wizards/source/template/DialogStyles.xdl for details, with styles defined under extras/source/templates/wizard/styles/. I vote for removal of the whole feature. Tomaz (or Miklos) is working on the (Document) Themes alternative. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 76750] UI: Feature Request to Select the Language of the Cells and Sheet
https://bugs.documentfoundation.org/show_bug.cgi?id=76750 Heiko Tietze changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Heiko Tietze --- No objection to the DUP, let's do it. *** This bug has been marked as a duplicate of bug 127856 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 158414] A shape with 100% transparency (or no fill and no border) can't be easily selected with the mouse in Calc
https://bugs.documentfoundation.org/show_bug.cgi?id=158414 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | --- Comment #14 from Heiko Tietze --- Let's treat this as a bug. I don't get why 100% transparency should be handled differently, and if needed Stephane had a good idea. -- You are receiving this mail because: You are on the CC list for the bug.
