[Libreoffice-ux-advise] [Bug 146623] Enhance Function Wizard Structure Tab for Better Formula Debugging
https://bugs.documentfoundation.org/show_bug.cgi?id=146623 --- Comment #6 from Damian Hofmann --- @(In reply to Heiko Tietze from comment #4) > Sounds all good, but has been (mostly) included in bug 92416. Do you agree > to make your ticket a duplicate; and you comment on the other ticket, Damian? I closed it. However not quite sure about that. The other ticket is for the SIDEBAR functions pane only. There seems to be a long march ahead, before the SIDEBAR function pane can even compare to the functionality that is already there in the Function Wizard. That ticket hasn't seen any activity for almost 5 years. I'm not exactly optimistic that this is going anywhere. Maybe delivering these features in the Function Wizard is more realistic? It already has a structure view which "just" needs to be enhanced. If you think so too, please reopen the ticket. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 146623] Enhance Function Wizard Structure Tab for Better Formula Debugging
https://bugs.documentfoundation.org/show_bug.cgi?id=146623 Damian Hofmann changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEEDINFO|RESOLVED --- Comment #5 from Damian Hofmann --- *** This bug has been marked as a duplicate of bug 92416 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153549] Rename Tools > "Chapter Numbering" to "Heading Numbering"
https://bugs.documentfoundation.org/show_bug.cgi?id=153549
sdc.bla...@youmail.dk changed:
What|Removed |Added
Assignee|libreoffice-b...@lists.free |sdc.bla...@youmail.dk
|desktop.org |
--- Comment #6 from sdc.bla...@youmail.dk ---
(In reply to Heiko Tietze from comment #4)
> The patch should not only change the UNO command label ...
Patch in comment 5 changed UNO and a few UI labels.
> but also the various UIs,
will do this in subsequent patches. Some interact with current changes in
insert index and insert caption dialogs, so will make separate patches.
> a tip of the day
in process...
> and some strings.
in help? Will also update those.
> The code contains a lot of comments talking about "chapter numbering".
Will not make any changes to the source code comments, which is outside the
scope of this ticket.
The aim is to update all references to "Chapter Numbering" in the UI (including
tooltip/extended tips) and help.
In this connectionone question
Could not figure out how to get Style Inspector to show "Para Chapter Numbering
Level" so cannot evaluate whether a change is needed in that label.
Any insights?
inspectorproperties.hrc line 199,
…R_NUMBERING_LEVEL NC_("RID_ATTRIBUTE_NAMES_MAP", "Para Chapter Numbering
Level")
--
You are receiving this mail because:
You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153549] Rename Tools > "Chapter Numbering" to "Heading Numbering"
https://bugs.documentfoundation.org/show_bug.cgi?id=153549 --- Comment #5 from Commit Notification --- Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0d3361aa989bbdb334cc13690a5fe1698bbf0db5 tdf#153549 rename "Chapter Numbering" to "Heading Numbering" It will be available in 7.6.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.
[Libreoffice-ux-advise] [Bug 153549] Rename Tools > "Chapter Numbering" to "Heading Numbering"
https://bugs.documentfoundation.org/show_bug.cgi?id=153549 Commit Notification changed: What|Removed |Added Whiteboard||target:7.6.0 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153673] "Chapter" label needs improvement in cross-references dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=153673 --- Comment #1 from sdc.bla...@youmail.dk --- correction: bug 149653 in OP should have been bug 149635 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153673] "Chapter" label needs improvement in cross-references dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=153673 sdc.bla...@youmail.dk changed: What|Removed |Added Blocks||141858 CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=141858 [Bug 141858] [META] Cross-references dialog issues -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 58070] Switching paragraph styles removes explicit text direction choice
https://bugs.documentfoundation.org/show_bug.cgi?id=58070 Eyal Rozenberg changed: What|Removed |Added Summary|RTL [HE] EDITING Switching |Switching paragraph styles |paragraph style changes |removes explicit text |character orientation |direction choice -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 58070] RTL [HE] EDITING Switching paragraph style changes character orientation
https://bugs.documentfoundation.org/show_bug.cgi?id=58070 Eyal Rozenberg changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Status|NEW |NEEDINFO Keywords||needsUXEval --- Comment #12 from Eyal Rozenberg --- With build: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ad387d5b984c906505d25685065f710ed55d CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: he-IL (en_IL); UI: en-US I am able to reproduce even on a plain new document. But let me offer more robust reproduction instructions: 1. Create a new Writer document. 2. Set the Default Page Style to LTR. 3. Set the Default Paragraph Style to LTR. 4. Set the Heading 1 paragraph style to LTR. 5. Enter some text (e.g. "hello"). 6. Change paragraph direction to RTL 7. Set the paragraph style to Heading 1 The paragraph direction switches to LTR. However - I am now wondering whether the DF of text direction should really be maintained. When we switch paragraph style, the pre-vspace and post-vspace are reset to the style's defaults, as is the background color and the border. Perhaps the text direction should be reset as well? Reporter, please opine on this if you're still around - and asking other users as well. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153560] Rename "chapter" to "heading" in Insert Field (Document tab)
https://bugs.documentfoundation.org/show_bug.cgi?id=153560 sdc.bla...@youmail.dk changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval --- Comment #1 from sdc.bla...@youmail.dk --- Now that "Chapter Numbering" is transitioning to "Heading Numbering" (bug 153549), it is relevant to call this ticket to UXEval attention. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153600] Style organizer's "Next style"'s function not clear to user
https://bugs.documentfoundation.org/show_bug.cgi?id=153600 Eyal Rozenberg changed: What|Removed |Added Resolution|NOTABUG |--- Status|RESOLVED|UNCONFIRMED --- Comment #6 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #3) > We discussed the topic in the design meeting. In an inappropriate manner, without giving reasonable prior notice of the discussion despite my having explicitly asked for this not to happen. > Labeling it "Next paragraph style", for example, adds no information. Ah, I see what you mean! The user can't tell whether "next" is the next style or the next-paragraph. Yes, indeed. Well, the label could be, say, "Style for next paragraph", or "Style for succeeding paragraph". A bit longer, but perhaps with just a line extension of the area for a label, it could be a two-liner, e.g. Style for /\ Next paragraph \/ Note that maintaining non-ambiguity would require a bit of delicacy in translation. Based on this and my two earlier comments - changing back to UNCONFIRMED. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153600] Style organizer's "Next style"'s function not clear to user
https://bugs.documentfoundation.org/show_bug.cgi?id=153600 --- Comment #5 from Eyal Rozenberg --- (In reply to jonathon from comment #2) > This is a documentation/User Guide issue, *not* a UI issue. No, this is a UI issue. I didn't claim there's anything wrong with the documentation. If you mean to say that, in order to understand this part of the UI, the user should read the documentation - that is an inacceptable claim, as I've argued above. The UI must be self-explanatory. Exception to this should be extremely rare, well-justified, and typically involve telling the user explicitly they need to go read some document. This is really not one of those cases. So, please don't quote the documentation to me. If I thought the documentation was lacking or misphrased I would have opened a bug against the documentation component (although TBH it's not obvious whether a bug against Writer documentation should use the Writer component or the Documentation component). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153600] Style organizer's "Next style"'s function not clear to user
https://bugs.documentfoundation.org/show_bug.cgi?id=153600 --- Comment #4 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #1) > Same argument could be taken for the "Inherit from" attribute and anything > else that is advanced. No, it could not, because "Inherit from [SomeParent]" is an imperative-form sentence describing a feature of the style being edited, while "Next Style [SomeStyle]" is a merely a noun-phrase, whose completion into an imperative sentence, or perhaps an adjective-phrase, regarding the style being edited requires a complex transformation. > I don't think these are beginner options. So another > "solution" might be to trust in the (online) help. > > ... documentation quote ... > > Pretty clear to me. => NAB 1. Help/documentation, in general, should never be considered a solution for a usability problem. It is always a fallback if the actual solution is faulty or imperfect; never something to send the user to consult by default. 2. Indeed, these are not beginner option. So, let me rephrase: These options are not clear to the user who is beginning to explore this part of the dialog. That is not the absolute-beginner user, it's the user who wants to get into more complex management of styles. That is the key user for the UI to target. > And we also have the opportunity to clarify a label per tooltip / extended > tooltip. If we do this it should be done for all items on the tab. Why? Do you believe some of the other labels are unclear? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153637] Rename "Use level from source chapter" to "Use outline level from document headings" in Type tab of Insert Table of Contents, Index, or Bibliography dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=153637 --- Comment #5 from sdc.bla...@youmail.dk --- (In reply to Heiko Tietze from comment #4) > Renaming "level" into "outline level" makes sense. OK > but "source chapter" makes no sense OK > neither "document headings" because...? > if this option somehow takes outlines on captions into account. "outlines on captions". Captions do not have outlines. Rather there is a "heading" (i.e., paragraph with outline level) that is prior to the caption. And to be clear --- this index is NOT displaying captions. The index displays the "Name" that is assigned (in Properties) to Table, Frame, Image, OLE Object, where the outline level of the immediately prior heading to the Table, Frame, etc. is used to provide the index level for that name. (Use case for this capability is unclear to me, but OP is only focused on an accurate label.) > But even if just badly implemented the heading is wrong for index. ??? Do you mean that the implementation should not use "heading" (outline level) to assign index level? Or that the implemented behavior should not be described with heading? > How about just "Use outline level" Because it does not indicate w or "Use outline level from source"? "source" is ambiguous -- plus given that each table, frame, etc. gets an index level depending on the immediately prior heading, then "use outline level" does not indicate which outline level is being used -- which is what lead me to: "Use outline levels from document headings" A more explicit and precise (but likely to be rejected) version: "Index by outline level of immediately prior heading" (there is plenty of room in the UI for this long label) -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153302] Function Suggestion: hotkey contains 'serial' key combinations
https://bugs.documentfoundation.org/show_bug.cgi?id=153302 Heiko Tietze changed: What|Removed |Added Blocks||41560 See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=11 ||5052 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=41560 [Bug 41560] [META] Keyboard shortcuts tab of Customization dialog -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153302] Function Suggestion: hotkey contains 'serial' key combinations
https://bugs.documentfoundation.org/show_bug.cgi?id=153302 --- Comment #1 from Heiko Tietze --- Shortcuts are indeed badly implemented and lack, for example, of locale, non-ASCII keys (bug 115052, UI redesign at bug 115527). The implementation defines an accelerator including modifier keys like "KEY_MOD1 | KEY_F" (see cui/source/customize/acccfg.cxx) and allows to bind this as F_MOD1 to any UNO command in officecfg/registry/data/org/openoffice/Office/Accelerators.xcu. There is no room for sequences. And your own styles don't have a UNO command assigned. Besides the need to improve the internal key handling from ground I don't see sequences as a good solution. It works for mnemonics where you press alt+F+O to open a document. But these mnemonics are clearly visible via underlined keys (depending on OS/DE). Sequences make things overly complex. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153309] Prevent direct formatting on writer by a password.
https://bugs.documentfoundation.org/show_bug.cgi?id=153309 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1 --- Comment #1 from Heiko Tietze --- You can modify the UI per document; quite flexible but tedious and not really what you want. Rather than blocking features (doubt we can do it properly) I'd warn or just inform about direct formatting. The idea was to have a style highlighter, for just DF see bug 106556. Would you agree to make your ticket a duplicate, Vito? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153653] Styles tab help page needs revision, and Assign command in Styles dialog should have a tooltip with the command name
https://bugs.documentfoundation.org/show_bug.cgi?id=153653 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #3 from Heiko Tietze --- Default reverts any association between the selected Level and the paragraph style. The default is "Content X" (although it's not added to the level like "Level 1 [Contents 1]"). We use Reset on the whole dialog. "Factory Setting" is correct but I see no advantage over "Default", which is short and easy to read. The tooltip "Reverts the associated paragraph style to the default setting" is fine. (In reply to sdc.blanco from comment #1) > 2. Alternatively, if the functionality is not changed, then... Typically for these dual-list pattern are buttons between the lists. We have the "move right" aka make association button and could turn "Default" into an icon-only trash bin button next to it. Doubt it contributes to clarification; and below the PS list we have an Edit button anyway. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153308] Coloring styles used on Documents
https://bugs.documentfoundation.org/show_bug.cgi?id=153308 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1 --- Comment #3 from Heiko Tietze --- Also wonder about the use case. But do you know the experimental "Document Style" aka "Design" feature? If not, activate the experimental features at Tools > Options > Advanced and find the tab "Design" in the sidebar. Is this what you are looking for? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153637] Rename "Use level from source chapter" to "Use outline level from document headings" in Type tab of Insert Table of Contents, Index, or Bibliography dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=153637 --- Comment #4 from Heiko Tietze --- Renaming "level" into "outline level" makes sense, but "source chapter" makes no sense neither "document headings" if this option somehow takes outlines on captions into account. But even if just badly implemented the heading is wrong for index. How about just "Use outline level" or "Use outline level from source"? -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153549] Rename Tools > "Chapter Numbering" to "Heading Numbering"
https://bugs.documentfoundation.org/show_bug.cgi?id=153549 Heiko Tietze changed: What|Removed |Added CC||vsfo...@libreoffice.org --- Comment #4 from Heiko Tietze --- The command has been change from Outline Numbering to Chapter Numbering for bug 107573 with some concerns, see bug 107573 comment 3. The patch should not only change the UNO command label but also the various UIs, a tip of the day, and some strings. The code contains a lot of comments talking about "chapter numbering". -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149497] Add option to allow sorting content in protected sheets
https://bugs.documentfoundation.org/show_bug.cgi?id=149497 Heiko Tietze changed: What|Removed |Added Blocks||107450 Summary|CALC Enhancement. Permit|Add option to allow sorting |"No User Input" as a data |content in protected sheets |validation which would then | |permit filter sorting | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Status|UNCONFIRMED |NEW See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=57 ||091 Keywords|needsUXEval | Ever confirmed|0 |1 --- Comment #7 from Heiko Tietze --- We discussed this topic in the design meeting. To rephrase the request, it should be possible to sort data in protected sheets (filtering works out of the box). Sorting may affect the data integrity, for example if a reference changes after sorting. We should also keep in mind that you can limit sort to ranges. So this option would be a bit dangerous, yet there might be scenarios where it is acceptable and needed. Instead of tweaking data validation with "No User Input" we suggest to add an option at the sheet protection dialog allowing to sort the content. Only drawback is that you permit it per sheet and not per range. This is kind of a duplicate to bug 57091 (and apparently working like this in MSO). (In reply to Maxim Egorushkin from comment #2) > My use case is analyzing a CSV file by applying different sorts and filters > to its rows and columns. Never experienced any protercion issue with CSV. Sheet protection is enabled manually via Tools > Protect Sheet (the suggested option would be added to this dialog) and you control per cell if a protection is _not_ applied. See also the discussion on bug 143349. > Not completely worthless, though, because such a design and functionality > can still be used as bad examples in textbooks to contrast with the > fundamental engineering principle of least astonishment. :-) Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=107450 [Bug 107450] [META] Cell and sheet protection bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153596] Rename "Outline" to "Headings" in the Type tab of Table of Contents, Index, or Bibliography
https://bugs.documentfoundation.org/show_bug.cgi?id=153596 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #3 from Heiko Tietze --- We briefly talked about this effort in the design meeting and appreciate your work. Consistency is very welcome. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153499] Index Entry dialog needs UI/HIG review
https://bugs.documentfoundation.org/show_bug.cgi?id=153499 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #15 from Heiko Tietze --- We briefly talked about this effort in the design meeting and appreciate your work. Consistency is very welcome. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149933] Introduce "Go To Special" feature as shortcut for typical searches
https://bugs.documentfoundation.org/show_bug.cgi?id=149933 Heiko Tietze changed: What|Removed |Added Blocks||113136 CC|libreoffice-ux-advise@lists |er...@redhat.com, |.freedesktop.org|heiko.tietze@documentfounda ||tion.org Summary|Editing:- Feature Request |Introduce "Go To Special" |"go to - special" feature |feature as shortcut for |needed |typical searches Keywords|needsUXEval | Status|NEEDINFO|NEW --- Comment #5 from Heiko Tietze --- We discussed the topic in the design meeting. The Go-To-Special dialog is a nice shortcut to many typical search operations such as Blanks, Formulas, References etc. I would name it differently, maybe "Quick Search", and place the button to start this dialog at the quick find toolbar. Could be an interesting GSoC project. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=113136 [Bug 113136] [META] Find & Replace Dialog -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153600] Style organizer's "Next style"'s function not clear to user
https://bugs.documentfoundation.org/show_bug.cgi?id=153600 Heiko Tietze changed: What|Removed |Added Resolution|--- |NOTABUG CC||heiko.tietze@documentfounda ||tion.org Status|UNCONFIRMED |RESOLVED Keywords|needsUXEval | --- Comment #3 from Heiko Tietze --- We discussed the topic in the design meeting. Labeling it "Next paragraph style", for example, adds no information. It is reasonably clear what the dialog/label is talking about. Short labels also have the advantage to make the UI feel less cluttered. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 153534] Most bundled page styles are nonsensical and/or redundant
https://bugs.documentfoundation.org/show_bug.cgi?id=153534 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | --- Comment #9 from Heiko Tietze --- The ticket started with "get rid of some and perhaps most of the page styles". We discussed this in the design meeting and come to the conclusion that every single page style has a use case. See also Jonathon's comment 7. => NAB Whether Left/Right is correct or should be Even/Odd is another question. It probably boils down whether RTL starts the first page on even numbers. (In reply to Eyal Rozenberg from comment #8) > No, the mechanism of having separate features when a page is odd or even in > the order of pages, or being to the right or left of the spine, is something > which must be covered within a _single_ page style. You invent new wheels; and even if your approach works we still want to support round-trips with other applications/document types. -- You are receiving this mail because: You are on the CC list for the bug.
