[Libreoffice-ux-advise] [Bug 143962] EDITING range reference should update when edge cell is moved in same column (drag and drop or cut and paste)
https://bugs.documentfoundation.org/show_bug.cgi?id=143962 Stéphane Guillou (stragu) changed: What|Removed |Added Keywords||needsUXEval -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 143962] EDITING range reference should update when edge cell is moved in same column (drag and drop or cut and paste)
https://bugs.documentfoundation.org/show_bug.cgi?id=143962 Stéphane Guillou (stragu) changed: What|Removed |Added Version|unspecified |Inherited From OOo Severity|normal |enhancement Summary|EDITING Address error when |EDITING range reference |move (drag and drop) a |should update when edge |range |cell is moved in same ||column (drag and drop or ||cut and paste) Blocks||108253 CC||er...@redhat.com, ||libreoffice-ux-advise@lists ||.freedesktop.org, ||stephane.guillou@libreoffic ||e.org See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=75 ||904 --- Comment #5 from Stéphane Guillou (stragu) --- Reproduced in OOo 3.3 and a recent master build. I can confirm that in Excel 365, following the same steps, the range is extended in the C10 formula. However, the range is not updated if the cell is dragged to a different column, or if it is dragged below the original range. So this seems to only happen in specific, straight-forward cases. Other apps: - OnlyOffice does not extend the range, same as LibreOffice - Gnumeric and Google Sheets extend the range, same as Excel I consider this as request for enhancement rather than a bug. Eike and UX team, what are your thoughts on this? Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 002ae41bb6088002ba3ed0188ac822fb823a23f9 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=108253 [Bug 108253] [META] Calc cell formula bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155218] Printing: selecting different page orientation does not relayout printed content
https://bugs.documentfoundation.org/show_bug.cgi?id=155218 --- Comment #7 from Mike Kaganski --- Also: (In reply to Stéphane Guillou (stragu) from comment #5) > Calc is a component where users can be surprised to learn that page style > exists and has to be tweaked to print as expected. This is *SO MUCH* distant from the reality! The page settings in Calc are VERY important, and applying them to ranges of sheets is very useful thing. Only the most basic usage can avoid that. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155218] Printing: selecting different page orientation does not relayout printed content
https://bugs.documentfoundation.org/show_bug.cgi?id=155218 --- Comment #6 from Mike Kaganski --- (In reply to Stéphane Guillou (stragu) from comment #5) > How about an option in the print dialog, something like "Ignore Page Style's > paper format", which could be on by default? I do not see how stacking "ignore this", "ignore that" could be a good option whatsoever. IMO, the original expectation that the layout should change is wrong -> WF. Or add a button leading to page style dialog, with some note that "chosen page layout doesn't match the layout of the page style - do you want to fix that?" or the like. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155218] Printing: selecting different page orientation does not relayout printed content
https://bugs.documentfoundation.org/show_bug.cgi?id=155218 Stéphane Guillou (stragu) changed: What|Removed |Added Keywords||needsUXEval Severity|normal |enhancement CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||stephane.guillou@libreoffic ||e.org --- Comment #5 from Stéphane Guillou (stragu) --- Calc is a component where users can be surprised to learn that page style exists and has to be tweaked to print as expected. Writer, Draw and Impress clearly have page and slide settings that are directly visible on canvas, whereas Calc has no visual hint of it. So I can see how many might expect to see the print ranges' content automatically adapt to whatever paper size is chosen in the Print dialog, seeing a sheet as just a number of cells that can expand at will in both directions, virtually without limits. Backward compatibility + PDF export means we can't just do away with the Page Style dialog's settings that can also be found in the Print dialog, nor add a "[from printer settings]" option for Paper Format like there is for Paper Tray. How about an option in the print dialog, something like "Ignore Page Style's paper format", which could be on by default? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155054] UI: Remediate frustration of unclear style names in style-name picklist contexts
https://bugs.documentfoundation.org/show_bug.cgi?id=155054
--- Comment #5 from R. Bingham ---
Thank you for your feedback.
First, to correct a mis-impression. My UI issue is NOT "I struggle to pick the
right PS for my task." As a long-time LO user, I typically have a good idea of
the style functionality I want ("the right PS for my task"). My UI issue is...
+ identifying the character-string style name that maps to that desired
functionality.
Alas, I have not memorized a mapping of all 125 (yes, I counted) built-in
paragraph style character-string names to a mental model of functionality.
Why not? My deep involvement with modifying or defining new styles is episodic,
driven by need. And even then, that deep involvement is usually only one or two
sub-areas across all style types (paragraph, character, frame, page, list,
table). Many months, perhaps more than a year, may have passed since my last
deep-dive to a particular area of styles. My daily use of style names is
relatively shallow. That deep-dive information fades from memory.
Then a need for a new deep-dive episode of styles maintenance creation and
maintenance arrives and I am once again reminded of desirable enhancements to
the LO UI. This is when style functionality hints
+ encoded in the character-string style name, or
+ implicit hints from surrounding style-pick visual context, such as the
hierarchy display in Navigator, or,
+ while using the Paragraph Style tabbed-pane widget combo-box picklists such
when selecting a "Next style:" or "Inherit from:" to modify or define New and
the picklist presents pattern-encoded string names immediately adjacent in the
flat-list sort
are of high value in avoiding interruption of picklist work.
So then, what are my sources of assistance in 'identifying the character-string
style name that maps to that desired functionality' for when I have a
Paragraph Style tabbed-pane widget up, the Organizer tab selected?
The "Stylist (this complex sidebar UI)" component in Navigator has that helpful
hierarchical view. Alas, it cannot assist because that styles-maintenance
tabbed-pane widget is MODAL. Oops, workflow interrupted. I have to dismiss the
widget to use Navigator then return to it.
To avoid that modal widget dismissal and loss of mental context, with the modal
tabbed-pane widget still in view, let us go to the very fine LO user-facing
documentation brought up in my Web browser via key F1 (assuring the appropriate
LO Module section of Help). Surely it will have one of
+a graphic of a fully exploded paragraph styles tree of the built-in styles
as a hint, or
+perhaps a page showing the flat-list of built-in paragraph styles as it
appears in widget picklists, with helpful notes on greater context for each
flat-list entry item?
My challenge to RTFM-inclined "requires to read the documentation" LO
developers is this: cite UF documentation pages having either of those.
A further challenge to RTFM-inclined LO developers is this: using my The Good,
The Bad, The Ugly, The Gross examples of style names as a search term in LO
Writer Help, or any built-in style name for that matter, cite UF documentation
pages having a sentence or two that explains the intended use of the individual
style, or if not an individual style, of a style family, such as the cited
example of the special-built-in-functional-juice style family ' "Content "
for the Table of Contents'. BTW, it is Contents plural, not Content singular.
One might think that the overview page "Styles in Writer",
LibreOffice/help/en-US/text/swriter/01/0513.html?DbPAR=WRITER#bm_id4005249
hosting the topic and table "Style Category" would be a good page to find
further links to use-intention details on each style-name family, possibly the
individual built-ins. NOPE.
Lastly on the topic of help, some unsolicited professional advice from a
customer-facing IT-sales systems engineer: naked, unsupported RTFM always
leaves a classic blow-off impression with customers and sales prospects. Not
good for future sales. I suggest instead cite specific documentation pages,
topic or URLs. That way, still RTFM but at least you give the impression of
helpfulness, of providing resources for the customer. Yes, this requires some
research effort on your part using the same user-facing tools the customer can
access. But the upside of that effort is, if in that effort you discover you
cannot develop those citations, then maybe, maybe, the customer has a point
after all...
"The second part of expanding a dropdown into a tree makes no sense to me."
Agree, but that was only one of several possibilities I listed and in any case
I wanted to spark some thought on why the existing flat picklist design has its
own UI usability problems when the list gets long and the entry items are
opaque, or, err, unclear, or better, cryptic. My whole 'encoding sufficient
information in a style name if that is all you have' concept.
The Workaround:
While the UI of a
[Libreoffice-ux-advise] [Bug 151330] Add option for Optimal row height to ignore hidden columns
https://bugs.documentfoundation.org/show_bug.cgi?id=151330 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | Priority|low |medium CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #3 from Heiko Tietze --- No objection, let's do it. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155147] Better handling of large presentations
https://bugs.documentfoundation.org/show_bug.cgi?id=155147 Heiko Tietze changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155021] Tabbed UI: Tools > Group Box misplaced
https://bugs.documentfoundation.org/show_bug.cgi?id=155021 Heiko Tietze changed: What|Removed |Added Summary|Tabbed UI: Tools tab layout |Tabbed UI: Tools > Group |can be improved |Box misplaced CC||libreoffice-ux-advise@lists ||.freedesktop.org --- Comment #2 from Heiko Tietze --- The "Group Box" command (.uno:GroupBox / Insert > Form Controls) starts a wizard that inserts a some form controls. It toggles on/off likewise the command "Form Control Wizard" above (for some reason not shown in your screenshot and IIRC only after a form wizard run). I don't think this function deserves a prominent place on the primary UI. But if, it is more or less correct placed. To switch into a toggle on state is weird, however. We do this for amodal dialogs but in this case I see no reason. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 154705] Enhancement: Add Snap to Intersection
https://bugs.documentfoundation.org/show_bug.cgi?id=154705 Roman Kuznetsov <79045_79...@mail.ru> changed: What|Removed |Added Blocks||112621 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=112621 [Bug 112621] [META] Snap guide and setting issues -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155131] Differentiate between lines in LO Base table editor and viewer with alternating shades.
https://bugs.documentfoundation.org/show_bug.cgi?id=155131 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Hardware|x86-64 (AMD64) |All --- Comment #8 from Heiko Tietze --- Obviously a highly welcome option, let's do it. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 155205] Why is a menu called "Data", when it has processing functions?
https://bugs.documentfoundation.org/show_bug.cgi?id=155205 Adolfo Jayme Barrientos changed: What|Removed |Added Resolution|--- |NOTABUG CC|libreoffice-ux-advise@lists | |.freedesktop.org| Status|UNCONFIRMED |RESOLVED Keywords|needsUXEval | --- Comment #2 from Adolfo Jayme Barrientos --- Sure, the items are for *data processing*, but from these two words, the one that is 1) shorter and easier to localize, and 2) carries more semantic symbolism, is “data”. Renaming this menu to “Process” makes it ambiguous for localizers and documentation writers about what is it that is being processed, and creates additional churn to those volunteers who are constantly updating their material to match updates done to the software. I see no advantage in renaming this particular menu. -- You are receiving this mail because: You are on the CC list for the bug.
