[Bug 161502] Calc: change Structure label of Function Wizard dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=161502 ady changed: What|Removed |Added Assignee|libreoffice-b...@lists.free |bayram.ci...@collabora.com |desktop.org | -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161502] Calc: change Structure label of Function Wizard dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=161502 Heiko Tietze changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161516] Label "Compare Document…" menu (and toolbars menu items) action more clearly, to indicate comparison direction
https://bugs.documentfoundation.org/show_bug.cgi?id=161516 Stéphane Guillou (stragu) changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||stephane.guillou@libreoffic ||e.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||needsUXEval --- Comment #1 from Stéphane Guillou (stragu) --- I agree this is confusing and is an issue that needs resolving. (In reply to Jeff Fortin Tam from comment #0) > "Compare Document with a Previous Version…" > (if that's indeed what it does) I feel like using terms that relate to recency or relative age is not the right solution. A user might be comparing their version of a document with another person's version, with diverging histories but no clear "before" and "after". The help[1] does use "newer" vs "older": > You should always start with opening the newer document and compare it with > the > older document. Maybe using a term like "reference" or "base" would be better? But really, I feel like this feature should have an intermediate step that lets the user choose which document is the base and which one is compared to the base, because the current UX is very, very poor: 1. open base document 2. compare 3. see that direction is wrong 4. close document 5. open modified document 6. compare, now in the right direction UX/Design team, opinions? Band-aid relabel, or more involved (but possibly a interesting easyHack) intermediate step? [1]: https://help.libreoffice.org/latest/en-US/text/shared/guide/redlining_doccompare.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161502] Calc: change Structure label of Function Wizard dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=161502 --- Comment #5 from Commit Notification --- Bayram Çiçek committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/1b88db8c1c0a92229a1998d4dcc4d5c488163f5a tdf#161502: change Structure label of Function Wizard dialog It will be available in 24.8.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161502] Calc: change Structure label of Function Wizard dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=161502 Commit Notification changed: What|Removed |Added Whiteboard|target:25.2.0 |target:25.2.0 ||target:24.8.0.0.beta2 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161090] Allow specifying how many / which values are grouped in remainder of Pie-of-Pie or Bar-of-Pie chart
https://bugs.documentfoundation.org/show_bug.cgi?id=161090 --- Comment #2 from kurt.nordb...@protonmail.com --- FWIW, it appears to me that the default MSO behaviour (split type "auto") puts the last ceil(n/3.0) entries in the right subchart. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161411] UI Better wording for ASCII-only characters
https://bugs.documentfoundation.org/show_bug.cgi?id=161411
--- Comment #7 from Tuomas Hietala ---
(In reply to Heiko Tietze from comment #5)
> If we end up in a verbose label, I suggest to keep a short label and have
> the explanatory text in a tooltip.
>
> ("aka" might become a migraine for l10n)
Not sure about the migraine, but of course if we put it in a tooltip, we could
as well write "also known as" as we wouldn't be running out of space anyway.
So perhaps something like this:
"Only Unicode 'Basic Latin' characters can be entered"
And the tooltip/explanation:
"Characters in the Unicode 'Basic Latin' block (also known as ASCII) include
the letters A-Z, a-z, numbers 0-9 and the most common punctuation marks."
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug 161411] UI Better wording for ASCII-only characters
https://bugs.documentfoundation.org/show_bug.cgi?id=161411 --- Comment #6 from Tuomas Hietala --- (In reply to V Stuart Foote from comment #4) > Unlike the Unicode 'Basic Latin' block, referring to ASCII is a problem as > non-standard Extended-ASCII and localized 8-bit character mappings remain > prevalent. > > And also utf-8 is broken for password entry as noted in bug 50400--that our > SfxPasswordDialog::AllowAsciiOnly() used in pw dialogs exclusively validates > the 7-bit 128 character ASCII code set. > > That is what needs to be conveyed. > > (In reply to Tuomas Hietala from comment #3) > >... > > * ""Only Basic Latin (a.k.a. ASCII) characters (A-Z, a-z, 0-9 and the most > > common punctuation marks) can be entered" > > Something for everyone? > > Make that "Only Unicode 'Basic Latin' (a.k.a ASCII) characters (A-Z, a-z, > 0-9 and the most common punctuation marks) can be entered" Yes, that would be even more complete. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161441] UI: Hard to tell which side of a shape being used for as reference for rotation
https://bugs.documentfoundation.org/show_bug.cgi?id=161441 --- Comment #15 from Telesto --- (In reply to Eyal Rozenberg from comment #14) > (In reply to Telesto from comment #0) > > UI: Hard to tell which side of a shape being used for as reference for > > rotation > > Are you sure that is exactly the problem? See below You're right, this isn't the core problem. FWIW: when reporting an it's always flipping between reporting a 'solution' with a description of the problem. Or more a description of experience without clear cut answer to the solution (and sometimes even real clue why the experience being off) > > > This rather common experience, IMHO. Lets assume some - like me - re-using a > > shape (by copy paste) initially drawn say vertically but used horizontally. > > The horizontal shape will have 90 degree angle. Really counter intuitive > In itself, this is not counter-intuitive to me, nor does it matter. At the same time: Yes, you right and No, it does matter. Yes, you are right: It doesn't matter as long I can archive my goal. It would have gone unnoticed if I used the WYSWING rotation mode .uno:ClickChangeRotation. However I struggled to realize it exists (Draw/Impress have it; Writer does not) and properly accessing it (see bug 161500). So I did look at sidebar -> rotation. With the experience that a visually similar oriented shape (rectangle) can have a 0 degree rotation or 90 degree (compare green rectangle and red rectangle in attachment 194623). Also if you rotate the green rectangle 90 degree (right). Having 2 shapes with same rotation degree set delivering a different result > problem, I would say, is with the ffect you mentioned earlier: > > > the negative or positive rotation doesn't matter, until you you add > > text to a shape > > So, I would say that the meaningful issue you're pointing out is that, on > one hand, the shapes looks the same, but on the other hand, they have > significantly different behaviors. Yes > What other behavior distinguishes the shapes other than the text block? The rotation seen in the sidebar/dialogs. > Because, for the text block, one could argue that once you "enter" the > block, you see a rectangular frame for the text block itself, that lets you > know what you can expect when typing. Please explain why that is not good > enough. > > Opposite happens to: copy/paste of horizontal shape rotation to vertical. > > So horizontal shape getting angle of 90, which feels natural (to me) > > I didn't understand this sentence. Nor your definition of a "horizontal > shape". Do you mean a 2D shape for which the page-horizontal extent is > larger than the page-vertical extent? > > > A) Use one angle as basepoint (say horizontal). So vertically drawn object > > is has automatically a 90 degree angle. No clue if this being workable > > Don't quite get this either. You seem to have defined a "vertical shape" and > a "horizontal shape", but what does it mean to be "vertically drawn"? I sometimes have hard time expressing myself; sorry. I hope the illustration given based on attachment 194623 helps > > > B) Some visual indicator on the shape itself marking where the top side of > > the shape is; improving the UI feedback > > How would this be useful other than for knowing how the text area behaves? Well it's suboptimal solution, IMHO. The core issue: the experience that a visually similar oriented shape (rectangle) can have a 0 degree angle or 90 degree angle. And follow-up on that the adjusting the angle becomes math. Rotate the green shape (with text) (attachment 194623) 45 degree. Now rotate the red shape (with text), to match the green shape. I have to really think/or use the try and error mode to conclude:315 / 135 degree. Normally I mindlessly adjust to the same value (45 degree). Also notice that the label text is hard to read. So you want to adjust that (already an additional step I didn't intend to do). To conclude: there is no way to adjust the label orientation (as far I can tell). So no need to redo you work by re-draw the rectangle, I suppose. A (simple) rotating action which I normally perceive as something done mindlessly becomes mind numbing, time consuming frustrating activity. The application working against me (in my perception). And no it's hard to draw a rectangle with a 90 degree rotation -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161502] Calc: change Structure label of Function Wizard dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=161502 --- Comment #4 from Commit Notification --- Bayram Çiçek committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9bbb02bcd7cf26b3e69e12481ffd041019d76082 tdf#161502: change Structure label of Function Wizard dialog It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161502] Calc: change Structure label of Function Wizard dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=161502 Commit Notification changed: What|Removed |Added Whiteboard||target:25.2.0 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161515] Ability to cut image object in two pieces along a line
https://bugs.documentfoundation.org/show_bug.cgi?id=161515 Eyal Rozenberg changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval Blocks||105815 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=105815 [Bug 105815] [META] Draw image bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161441] UI: Hard to tell which side of a shape being used for as reference for rotation
https://bugs.documentfoundation.org/show_bug.cgi?id=161441 --- Comment #14 from Eyal Rozenberg --- (In reply to Telesto from comment #0) > UI: Hard to tell which side of a shape being used for as reference for > rotation Are you sure that is exactly the problem? See below > This rather common experience, IMHO. Lets assume some - like me - re-using a > shape (by copy paste) initially drawn say vertically but used horizontally. > The horizontal shape will have 90 degree angle. Really counter intuitive In itself, this is not counter-intuitive to me, nor does it matter. The problem, I would say, is with the ffect you mentioned earlier: > the negative or positive rotation doesn't matter, until you you add > text to a shape So, I would say that the meaningful issue you're pointing out is that, on one hand, the shapes looks the same, but on the other hand, they have significantly different behaviors. What other behavior distinguishes the shapes other than the text block? Because, for the text block, one could argue that once you "enter" the block, you see a rectangular frame for the text block itself, that lets you know what you can expect when typing. Please explain why that is not good enough. > Opposite happens to: copy/paste of horizontal shape rotation to vertical. > So horizontal shape getting angle of 90, which feels natural (to me) I didn't understand this sentence. Nor your definition of a "horizontal shape". Do you mean a 2D shape for which the page-horizontal extent is larger than the page-vertical extent? > A) Use one angle as basepoint (say horizontal). So vertically drawn object > is has automatically a 90 degree angle. No clue if this being workable Don't quite get this either. You seem to have defined a "vertical shape" and a "horizontal shape", but what does it mean to be "vertically drawn"? > B) Some visual indicator on the shape itself marking where the top side of > the shape is; improving the UI feedback How would this be useful other than for knowing how the text area behaves? (In reply to Heiko Tietze from comment #5) > Sounds to me like an artificial use case. Disagree that drawing rectangles of various shapes and rotating them is artificial. I mean, the reproducer is a tiny document so it's always going to feel a bit artificial. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161502] Calc: change Structure label of Function Wizard dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=161502 --- Comment #3 from Bayram Çiçek --- (In reply to Heiko Tietze from comment #2) > Was thinking about a shorter label like "Content" or to just remove the > label (only reason for the label is a11y). Thank for the suggestion. I changed the label to "Content:" and uploaded a new patch. CI is green. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161502] Calc: change Structure label of Function Wizard dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=161502 Heiko Tietze changed: What|Removed |Added CC||heiko.tietze@documentfounda ||tion.org, ||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval --- Comment #2 from Heiko Tietze --- Was thinking about a shorter label like "Content" or to just remove the label (only reason for the label is a11y). -- You are receiving this mail because: You are on the CC list for the bug.
