[Libreoffice-ux-advise] [Bug 141102] The "outline content visibility" feature deserves a friendlier name.
https://bugs.documentfoundation.org/show_bug.cgi?id=141102 --- Comment #3 from Jim Raykowski --- Created attachment 170645 --> https://bugs.documentfoundation.org/attachment.cgi?id=170645=edit options view tab page outline content visibility change to outline folding How about this? -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 140178] Change "Outline & List" to "Level & List" as tab label in Paragraph and Paragraph Style dialogs
https://bugs.documentfoundation.org/show_bug.cgi?id=140178
sdc.bla...@youmail.dk changed:
What|Removed |Added
See Also||https://bugs.documentfounda
||tion.org/show_bug.cgi?id=14
||1128
--- Comment #13 from sdc.bla...@youmail.dk ---
(In reply to Heiko Tietze from comment #11)
> But in the end I believe users don't read those details.
Agree -- in general.
> The alliteration reads awkward.
Agree. "List & Level" would "sound" better. (-:
But I am content to leave this as WF.
Both “List & Level” and “Outline & List” are meaningful labels in relation to
the tab, so then it becomes a question of which words signal the important
functions of the tab.
I chose “Level” because it is the attribute being modified by "Outline Level".
Also, the word “Outline” gives a false impression that the numbering hierarchy
is created here in the paragraph (style) dialog, or that Outline Level has
something to do with the lists. It doesn't. [ Reason (c) in comment 0 also
demonstrated that confusion - but reasons (a) and (b) are still valid. ]
> Given that outline is kind of a list, how about "List Style"?
I believe you share a misunderstanding here with Dieter in relation to this
particular dialog tab -- which makes it difficult to discuss. (In this
exceptional case, the label may make a difference!)
>Dieter from comment #8> I'm not a native speaker...Chicago Manual of Style
>Dieter from comment #8> If "outline" is related to lists
The issue here is conceptual/technical, not linguistic. It cannot be solved by
looking at dictionary or style manual definitions; it requires understanding
what the controls are actually doing in this context (no matter what they are
called, though in this case, we must use the terminology provided by the UI.).
I have already accepted WF. But for the sake of clarity:
The critical point is that the word "level" is used with two different
independent meanings for "Outline Level" and "List Level" (in the LO interface
and in the underlying ODF).
The expression "Outline Level" comes presumably from the ODF (19.850
text:outline-level), which is carried over to the UI. But that "level" is
distinct from the attribute "level" (19.834 text:level), which is used with
list elements. In the UI, it appears that "Level" is also carried over to the
UI (in the Position and Customize tabs in Bullets and Numbering dialog). The
only place in the UI where I can find "List Level" at present is in the
Condition tab in the PS dialog -- and that is because I changed it recently).
("List level" also appears throughout comments in the source code.)
In the PS dialog tab under discussion here, there is no connection or
dependence between Outline Level and List Style (List Level). It is possible to
set an Outline Level without a List or apply a List without setting an Outline
Level.
The "connection" between "Outline Level" and "List Level" is created by the
Chapter Numbering dialog, which exists to create an apparent dependence between
Outline Level and List Level. (In fact, the dialog lets you assign a List Level
1 numbering to a Heading N which is assigned to an Outline Level). This
"assignment" is preserved/enforced by the UI, because the PS dialog prevents
editing Outline Level for the Heading N paragraph styles. (and if you choose to
use another PS in the Chapter Numbering dialog, then you will not be able to
set the Outline Level in the PS dialog -- by design).
The proposal to use "Level" instead of "Outline" was mostly to steer people
away from thinking that this tab has something to do with lists and outlines --
-- but following the principle "renaming … UI elements has to be an exception”,
then this reason ("steering away") is not a strong enough justification for an
exception right now.
But I hope this ticket highlights an issue that will get further attention. If
the Bullets and Numbering dialog gets developed further, it might be worth
considering using the label "List Level" instead of "Level" in the Position and
Customize tabs.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 113192] [Digital-Signatures][OpenPGP] There's no indication of which key is which
https://bugs.documentfoundation.org/show_bug.cgi?id=113192 Eike Rathke changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #4 from Eike Rathke --- Read the comment above :p (status should had been updated though). -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 135364] Change default pen color and width for presentation
https://bugs.documentfoundation.org/show_bug.cgi?id=135364 --- Comment #9 from Caolán McNamara --- (In reply to Heiko Tietze from comment #8) > Caolan, what do you think? the dtor of ShowWindow isn't getting called, so the pen color preference isn't saved. The dtor isn't getting called due to some complicated a11y ownership problem so its apparently an a11y related issue seen under gtk cause a11y is always-on there -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 141121] Better default font choice for the Writer comments, and/or ability to customize the font family and size for comments
https://bugs.documentfoundation.org/show_bug.cgi?id=141121 --- Comment #5 from Jean-François Fortin Tam --- Well the problem I see with carrying font family+size information "in the comments" rather than "per system/app" is that: 1. it might render pretty differently on other people's systems anyway if they don't have the fonts (especially if someone chose a non-shipped-with-libreoffice font) 2. this metadata would then be stuck forever "polluting" each document, i.e. even if you were to set your preferred default font as a user you wouldn't retroactively see this improvement in all the old documents that you open, or documents generated by users. I for one would like to be able to open any document and see the text comments as a UI element rather than a document element, because they don't have spatial characteristics in Writer (no size and position, unlike in spreadsheets). -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 141077] Writer Web mode should be one-column, instead it shows meaningless page breaks and column jumps
https://bugs.documentfoundation.org/show_bug.cgi?id=141077 --- Comment #4 from Lobotomik --- (In reply to V Stuart Foote from comment #2) > If you want to use the uncluttered Web view layout to write in, great. Just > accept that its VCL handling is calculated against an unisized page (10 > meters tall, at the current app frame width minus controls). > > Reflowing from Web view to Normal view, or reverse, will otherwise honor the > page settings of the document. > > If you don't want columns in Web view reformat the page style for the > document to single column--you can't have it both ways. Single column in > Web view and multicolumn in Normal view. I know that is how it works, but I don't think it is how it should work. I cannot have it both ways *now*, but I think that is a bug, not a feature. The web view is inconsistent. Why are margins, headers, footers and page breaks ignored, but not columns? They make as just as little sense in a web view, if not even less. Flowing columns in web pages are an extremely rare occurrence, and a very dubious design choice. The column management in web view is buggy anyway: I cannot think of any setting where it makes any sense to flow columns counting on a non-configurable 10-meter tall page, which in itself could be considered buggy behavior. I don't think that is how it works, anyway: in documents a lot less than 10m long there will be a column wrap in web view, though both columns are very different in length. And if there are changes in the number of columns (because you have they have to be separately enabled and configured for every section and page style), then it also inserts visible page breaks. And the behavior changes depending on whether your whole document is in "Default Page" page format, or the first page is in "First Page" format, and whether you change columns while within the web view, or in the Normal view (and then depending on whether you change one style, the other, or both). You can get page breaks at impredictable places, with different lengths, and the text sinuously flowing up and down. But I don't think fixing the buggy column management in web view is the right thing to do (or even possible). I think that the bug looks like the untested behavior of code that is being used in a setting that makes no sense. The easiest thing to do, and most logical in terms of fixing the behavior, whould be to stop trying, as it seems to be done with margins, headers and footers. If these issues with the web view were fixed, it could make do as a less cluttered writing interface that removed the biggest distractions, filling the window with the user's work. And it would work better as a way to publish documents in HTML for uploading to some CMS or whatever. In the wishlist arena, a dedicated no-clutter writing interface might satisfy many writers. Much sofistication could be added, or removed; many features would be possible. But that will be a long time coming, if it ever comes. In any case, thanks for your efforts. Really LibreOffice is unbelievable value at the price, and it must be frustrating for developers watching a growing queue of bugs that need fixing with no resources to allocate. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 141094] UI: Ability to set configure image resolution to be shown in inch instead of cm, if other dimensions are in CM
https://bugs.documentfoundation.org/show_bug.cgi?id=141094 --- Comment #4 from Heiko Tietze --- Would be a challenge to calculate with dpcm when dpi is the standard. Fact is that we use different units. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 135364] Change default pen color and width for presentation
https://bugs.documentfoundation.org/show_bug.cgi?id=135364 Heiko Tietze changed: What|Removed |Added CC||caol...@redhat.com --- Comment #8 from Heiko Tietze --- Caolan, what do you think? -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 140770] PRINT PREVIEW: Toolbars without a function should be removed in print preview
https://bugs.documentfoundation.org/show_bug.cgi?id=140770 Heiko Tietze changed: What|Removed |Added CC||momonas...@gmail.com --- Comment #4 from Heiko Tietze --- Maxim, what do you think about hiding all toolbars in print preview mode? -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 141102] The "outline content visibility" feature deserves a friendlier name.
https://bugs.documentfoundation.org/show_bug.cgi?id=141102 Heiko Tietze changed: What|Removed |Added CC||rayk...@gmail.com, ||sdc.bla...@youmail.dk --- Comment #2 from Heiko Tietze --- Would rename "Show outline content visibility button" to "Show inline button" (a bit longer label could be "Show outline folding button") with the tooltip "Toggles the visibility of the outline content visibility button left of chapter headings. Access to the outline folding is always possible via Navigator." Any objection, Jim? -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 140805] FIND TOOLBAR: Incremental/Type-ahead search in Writer should be supported
https://bugs.documentfoundation.org/show_bug.cgi?id=140805 Heiko Tietze changed: What|Removed |Added Summary|FIND TOOLBAR: Incremental |FIND TOOLBAR: |search in Writer should be |Incremental/Type-ahead |supported |search in Writer should be ||supported Keywords|needsUXEval |needsDevAdvice CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #4 from Heiko Tietze --- I'm puzzled by the summary. "Incremental search" refers to the method of showing possible terms while typing. When I enter "Libre" in the Google search bar it returns "libreoffice glade", "libreoffice", "libreoffice template", "libreelec" based on my previous searches and the knowledge Google has about me. The actual request is rather a type-ahead/find-as-you-type function. Meaning the search restarts/refines with every new letter. But in fact some applications use the term incremental for this, eg. https://www.gnu.org/software/emacs/manual/html_node/emacs/Incremental-Search.html Guess it's a challenge for developers to make the performance a good UX. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 141121] Better default font choice for the Writer comments, and/or ability to customize the font family and size for comments
https://bugs.documentfoundation.org/show_bug.cgi?id=141121 --- Comment #4 from Heiko Tietze --- (In reply to Jean-François Fortin Tam from comment #0) > A) ...the font family and size should be set by the application (or global > user preferences) Yes, requested in bug 62150 (or more generally but maybe over-engineered in bug 103064, as comment by Uwe). > B) The default font family & size used for comments are not optimal. Don't see much of an issue with Liberation and would avoid shipping another font. If A) is solved it's not a problem to set B) to your preference. > I would therefore recommend that: > 1- LibreOffice ignores comment metadata about font family and font size, > instead applying those two properties globally for the comments. Guess removing the ability to highlight parts of the comments with font color or weight is a regression for some users. If your co-workers are mean and format every word differently, the only reason I can think of why rich formatting has a negative impact on UX, we could introduce an option to clear or hide all direct formatting in comments. My take: duplicate of bug 62150. But it's a good topic for the design meeting. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 140719] LABELS: Problems with "Single Label" option
https://bugs.documentfoundation.org/show_bug.cgi?id=140719 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |glo...@fbihome.de, |.freedesktop.org|heiko.tietze@documentfounda ||tion.org --- Comment #7 from Heiko Tietze --- Single Label: Prints a single label or business card on a page. So far the current implementation is correct. But with col/row it's not a _single_ label anymore and I would expect to print the given number of labels. Hard to say if the implementation was done intentionally (making this an enhancement) or not (thus it's a bug, plus the caption is wrong). Jmux, any stance here? Maybe it's easyhackable. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 140178] Change "Outline & List" to "Level & List" as tab label in Paragraph and Paragraph Style dialogs
https://bugs.documentfoundation.org/show_bug.cgi?id=140178 --- Comment #12 from Dieter --- (In reply to Heiko Tietze from comment #11) > Don't see advantage in shuffling the words. It would emphazise, that list is the broader word and outline is the list outline and it is something different than outline of the document. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 140178] Change "Outline & List" to "Level & List" as tab label in Paragraph and Paragraph Style dialogs
https://bugs.documentfoundation.org/show_bug.cgi?id=140178 Heiko Tietze changed: What|Removed |Added CC|heiko.tietze@documentfounda | |tion.org| --- Comment #11 from Heiko Tietze --- (In reply to Dieter from comment #8) > From my POV "List & Level" has no advantage compared to "List & Outline". (In reply to Dieter from comment #9) > ...change from "Outline & List" to "List & Outline" Don't see advantage in shuffling the words. (In reply to sdc.blanco from comment #0) > "Outline & Numbering" was changed to "Outline & List" > (a) reduce confusion with "Outline" tab and "Outline" in B > (b) highlights the important aspect ... namely "Level" > (c) tabs in "B" and "List Style" have a "Level" option > (d) leave the "Outline" label ...in B commonly known But in the end I believe users don't read those details. In most cases they glance over the dialog to find a way to "put numbers at the beginning of the text" having a chapter number in mind (Outline is the whole picture to me, an overview of the document structure). And less often to make a paragraph a list (type equally split here). So the keywords are numbering, outline, and list- and if I spot any of those terms I pick the tab. Given that outline is kind of a list, how about "List Style"? (In reply to sdc.blanco from comment #0) > "Outline & List" -> "Level & List" The alliteration reads awkward. Off-topic: No need to CC me to UX topics, I receive and read all messages to the ux-advice mailing list. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
