[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 kurt.nordb...@protonmail.com changed: What|Removed |Added Assignee|libreoffice-b...@lists.free |kurt.nordb...@protonmail.co |desktop.org |m -- 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 Stéphane Guillou (stragu) changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=50 ||934 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161090] New: 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 Bug ID: 161090 Summary: Allow specifying how many / which values are grouped in remainder of Pie-of-Pie or Bar-of-Pie chart Product: LibreOffice Version: 24.8.0.0 alpha0+ Master Hardware: All OS: All Status: UNCONFIRMED Keywords: needsUXEval Severity: normal Priority: medium Component: Chart Assignee: libreoffice-b...@lists.freedesktop.org Reporter: stephane.guil...@libreoffice.org CC: kurt.nordb...@protonmail.com, libreoffice-ux-advise@lists.freedesktop.org Blocks: 90486 Created attachment 194138 --> https://bugs.documentfoundation.org/attachment.cgi?id=194138=edit sample ODS with basic bar-of-pie showing the last 3 values grouped as sub-chart The new bar-of-pie and pie-of-pie chart types groups the last three values of the data range to construct the sub-chart (see bug 50934 comment 21). Note that this also differs from MS 365's default, which groups the last two. The UI does not currently allow changing how many values are grouped, or which ones. This is confusing (the user can't easily understand the logic) and is too limiting in customisability. Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 658a212585c56540a17c4e6829716d4ef4e3 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded Copying UX/Design team for opinion on the best UI for that. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=90486 [Bug 90486] [META] Chart bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160920] Allow choosing the page style from the sheets tab
https://bugs.documentfoundation.org/show_bug.cgi?id=160920 --- Comment #13 from Eyal Rozenberg --- (In reply to Cor Nouws from comment #0) > It's - as far as I know - mostly unclear that double clicking a page style > in the Stylist (eh.. pane Manage Styles :D ) applies that to the active > sheet. So, don't you want to make that the bug? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161075] Rename "Page Style..." to "Page..." on the Format menu
https://bugs.documentfoundation.org/show_bug.cgi?id=161075 --- Comment #8 from Eyal Rozenberg --- (In reply to Cor Nouws from comment #7) > You should have looked to what the menu entries do and noticed a difference > in the dialogs titles... Ah, but I shouldn't have to. It's the Format menu. You format pages (or page sequences), you don't format styles - or at least, you don't expect to. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161078] Allow direct formatting for page sequences instead of editing the style
https://bugs.documentfoundation.org/show_bug.cgi?id=161078 --- Comment #12 from Eyal Rozenberg --- (In reply to Cor Nouws from comment #9) > Apart from your arguments, "making use of styles easy/promoting the use of > styles" is a good principle in our work. Unfortunately - it isn't; and this is a key point. That is, it is a good principle for users to adopt, but our policy is to enable the opposite user behavior, of "I'll just DF and I don't care and styles and consistency." We could decide we want to enforce the use of styles; but - if we're not enforcing this for most entities, it does not make sense to enforce the use of "styles only" just for page sequences. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161078] Allow direct formatting for page sequences instead of editing the style
https://bugs.documentfoundation.org/show_bug.cgi?id=161078 --- Comment #11 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #7) > While I fully agree with Mike's comments Then please read my last comment and I'm sure you'll change your mind. > it might be worth to think about > from another angle (actually as bugs should be reported). Something like: "I > insert a graphic on page 5 and want to make this page landscape. Please add > easy means to do so.". > > Theoretically we could do the same as for lists and create a page style on > the fly, and add a page break with it after the last paragraph of the > previous page, plus one with what was active before on the current page. Let's not get ahead of ourselves. The ability to format a single page / create a single page sequence is relevant with or without the ask in this bug - when considering named styles. Maybe I have a "blue background" style that I've defined; a desire to apply it to a single page is also relevant. But - that's not the scope of this bug. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161078] Allow direct formatting for page sequences instead of editing the style
https://bugs.documentfoundation.org/show_bug.cgi?id=161078 --- Comment #10 from Eyal Rozenberg --- (In reply to Mike Kaganski from comment #4) > ... it is not impossible... but what would be the upside of this[?] The opposite of the problems with which I described the current situation: * Consistency with styles of other entities. * Format | Page (Sequence)... becomes a less confusing action, with no spooky action at a distance on other page sequences which the user never intended to affect. * No need to go to the trouble of defining a new page style just to apply some formatting to the current page sequence. To be concrete: I want to have some of a couple of pages of mine to exhibit a blue background. Why should I need to define a style just for that? And of course, I can't have my Default Page Style go blue, since my pages are basically white. So, it's DF for me, tee hee. Also, while we don't have composable and inheritable page styles, defining multiple page styles for many kinds of sequences requires a lot of maintenance, in the sense that whenever you change something that's common to multiple styles, you're likely to have to change all of them. > and how could the *user management* be realistically implemented ... which > would be easy and different compared to the current situation? I don't propose any changes in how users manage this compared to the current situation: * Format | Page... (or Format | Page Sequence...) will apply DF * Double-clicking the current page style will clear the DF * Clicking another page style will apply it, but try to keep the DF where possible > Including the > important "next page style" mechanism, which needs referring to the set of > properties of the next page, currently implemented by referring to the style > name? Ah, that's a good point. Here are two options for when a Next Page Style is defined: 1. Only the first page in the sequence gets the DF, and then it's just a clean application of the Next Page Style, and the next-next-page style etc. 2. For each transition to the next page, act as though the user had double-clicked that style while having DF in effect. That is, try to apply the DF to the extent possible. (actually (2.) is not perfectly well defined.) I like (2.) better, but I think this is kind of a non-issue, because the use of alternating styles like that only happens intentionally, when the user carefully styles his/her page sequences. Such a user can be assume to not be fazed or confused by our choice of DF application behavior, and realize they may need to clear the DF. There is also the possibility of warning about DF'ing a page sequence with Next Page Style defined, if we believe this should be avoided. It's not clear to > I do not see this whole suggestion as any kind of UX improvement; any "this > is internally inconsistent" It's _externally_ inconsistent. I find it inconsistent. I forget that this is the case, and mess up my documents. And if it happens to me, it happens to many users. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161078] Allow direct formatting for page sequences instead of editing the style
https://bugs.documentfoundation.org/show_bug.cgi?id=161078 --- Comment #9 from Cor Nouws --- (In reply to Mike Kaganski from comment #6) > I disagree that a "consistency" argument is applicable / fair in this > context. Apart from your arguments, "making use of styles easy/promoting the use of styles" is a good principle in our work. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161078] Allow direct formatting for page sequences instead of editing the style
https://bugs.documentfoundation.org/show_bug.cgi?id=161078 Cor Nouws changed: What|Removed |Added CC||c...@nouenoff.nl --- Comment #8 from Cor Nouws --- (In reply to Heiko Tietze from comment #7) > While I fully agree with Mike's comments it might be worth to think about > from another angle (actually as bugs should be reported). Something like: "I > insert a graphic on page 5 and want to make this page landscape. Please add > easy means to do so.". e.g. ask (somewhere) "[] apply to current page only" (and then later on fight the trouble of people not understanding why the text flow in their documents is broken - fatal path..) Maybe the least bad option is to show a warning when applying a page style via selecting (Manage Styles or Status Bar) "mind that see [] do not show this warning again" -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161075] Rename "Page Style..." to "Page..." on the Format menu
https://bugs.documentfoundation.org/show_bug.cgi?id=161075 --- Comment #7 from Cor Nouws --- (In reply to Eyal Rozenberg from comment #0) > * Character... > * Paragraph... > * Bullets and Numbering... > * Page Style... > > One of these does not fit the naming scheme of the rest. Which is it? You should have looked to what the menu entries do and noticed a difference in the dialogs titles... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160650] allow to set comments/descriptions for conditional formattings
https://bugs.documentfoundation.org/show_bug.cgi?id=160650 Stéphane Guillou (stragu) changed: What|Removed |Added Whiteboard| QA:needsComment| CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||stephane.guillou@libreoffic ||e.org Keywords||needsUXEval See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=14 ||5518 --- Comment #1 from Stéphane Guillou (stragu) --- Thanks for the suggestion. Let's see what the UX/Design team thinks. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161037] UNO Sidebar 'Hide' and 'Show' sidebar deck (splitwin) -- a new function (available for assigning a shortcut key to it)
https://bugs.documentfoundation.org/show_bug.cgi?id=161037 --- Comment #4 from V Stuart Foote --- (In reply to Michael Weghorn from comment #3) > (In reply to V Stuart Foote from comment #1) > > This is expected with the current +F5 toggle (.uno:Sidebar) which > > *closes* or *opens a new instance* of the SB framework. Its workflow and UI > > behavior is pretty consistent, as is that of the F11 "Stylist". > > > > Also, UNO are already available and assigned to open each SB Deck (bug > > 84502); +[1-9] with 1-4 common (uno:PropertyDeck, uno:StyleListDeck, > > uno:GalleryDeck, uno:NavigatorDeck) across the modules. > > Could making Alt+[1-9] *toggle* the current state of the corresponding deck > maybe be a potential solution, i.e. switch to that deck if it's currently > not active, and collapse it if it currently is active? Kind of like the toggle that F11 provides for the Stylist deck. But that has issues in the sense that the splitwin "Buttons" apply to either Sidebar splitwin framework exposure state--just Tab bar, or to Tab bar and Deck. Also the +[1-9] just Open corresponding SB when focus is on the document canvas or the SB, and don't work while focused to main menu, any toolbar, or a Notebook Bar assemblage. So would provide a keyboard toggle for the splitwin to collapse (but not close) the SB framework. The existing +F5 shortcut actually closes the framework, and applies SB state as recorded to profile for each module on relaunch. Unfortunately there is no available UNO to match the mouse-only splitwin collapse of the SB framework--and don't think extending the +[1-9] slate of shortcuts gives us the right UX. That same UNO could be reused with the other splitwin UI (e.g. calc, writer). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161082] Print dialog: Put initial focus to "Printer" combobox
https://bugs.documentfoundation.org/show_bug.cgi?id=161082 V Stuart Foote changed: What|Removed |Added CC||vsfo...@libreoffice.org --- Comment #3 from V Stuart Foote --- (In reply to Heiko Tietze from comment #2) > And my reply > > (In reply to Heiko Tietze from comment #12) > > From the efficiency POV, the most relevant function should be in focus. And > > that's the number of copies: ctrl+P into the dialog, arrow up as many copies > > you like, and enter to run the action. > > > > Admittedly it's odd to start tabbing (or screen reading) in the middle of a > > dialog. But the actual printer selection *is* the more significant condition. Knowing it before configuring print range and number of copies is crucial, especially as the range and number of copies have reasonable default. While printer selection takes a value from os/DE default or as recorded to ODF archive for a document. And that means the user will not know what printer is selected on opening the dialog! Very serious situation as the printer could be a disconnected network printer, or a remote network printer, or a "print to file" printer resource. So rather than the copy count (and needed 10 round to reach the printer listbox), starting from the printer selection is the more conservative/appropriate landing. It certainly is from an a11y point! +1, change the dialog landing to the "Printer" listbox selector. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160858] Add "Apply" button to all tabs of Table Properties dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=160858 --- Comment #2 from Heiko Tietze --- The Apply function would be added next to Reset on the bottom bar. Like it is implemented for the Format > Page Style dialog. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 160938] FORMCONTROLS: Add ability to Find and Replace field names
https://bugs.documentfoundation.org/show_bug.cgi?id=160938 --- Comment #4 from Heiko Tietze --- Created attachment 194124 --> https://bugs.documentfoundation.org/attachment.cgi?id=194124=edit Example document If you copy/paste a table with form controls the resulting names are amended with a number like "top_left" becomes "top_left 1". What's wrong with it? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161078] Allow direct formatting for page sequences instead of editing the style
https://bugs.documentfoundation.org/show_bug.cgi?id=161078 --- Comment #7 from Heiko Tietze --- While I fully agree with Mike's comments it might be worth to think about from another angle (actually as bugs should be reported). Something like: "I insert a graphic on page 5 and want to make this page landscape. Please add easy means to do so.". Theoretically we could do the same as for lists and create a page style on the fly, and add a page break with it after the last paragraph of the previous page, plus one with what was active before on the current page. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161082] Print dialog: Put initial focus to "Printer" combobox
https://bugs.documentfoundation.org/show_bug.cgi?id=161082 --- Comment #2 from Heiko Tietze --- And my reply (In reply to Heiko Tietze from comment #12) > From the efficiency POV, the most relevant function should be in focus. And > that's the number of copies: ctrl+P into the dialog, arrow up as many copies > you like, and enter to run the action. > > Admittedly it's odd to start tabbing (or screen reading) in the middle of a > dialog. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161078] Allow direct formatting for page sequences instead of editing the style
https://bugs.documentfoundation.org/show_bug.cgi?id=161078 --- Comment #6 from Mike Kaganski --- And let me also provide a "philosophical" view on this. The proposal argues that since we allow DF for other entities, we should do the same for pages. But this is like this: 1. There is a consensus that styles mechanism is generally superior to direct formatting. 2. But there are *reasons* why we can't avoid direct formatting in some areas - like steep learning curve, or compatibility, or legitimate use cases. 3. This justifies the *unfortunate* need of DF in many entities, giving raise to a huge set of problems, like unmanageable documents being overwhelmingly common, and not only when one writes a letter to a friend, and forgets that - but in most real-life documents offered as templates in official sites of organizations, governments, and so on. This is an inevitable evil, but not something to cheer. 4. And now, the unfortunate need to keep the DF in some entities provokes a suggestion to also support this same problematic "feature" in an entity which was lucky to survive without DF so far. And that lack of DF was not itself problematic for users - other problems (as mentioned in comment 5) could be solved to make the current no-DF a comfortable state. I disagree that a "consistency" argument is applicable / fair in this context. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161082] Print dialog: Put initial focus to "Printer" combobox
https://bugs.documentfoundation.org/show_bug.cgi?id=161082 Michael Weghorn changed: What|Removed |Added Priority|medium |low CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||m.wegh...@posteo.de Severity|normal |enhancement See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=16 ||0824, ||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=34 ||641 Keywords||needsUXEval --- Comment #1 from Michael Weghorn --- (In reply to Michael Weghorn from comment #0) > # Expected behavior: > > Initial focus should be on the "Printers" combobox at the top of the dialog. That's my personal opinion of course, for the reasons given above. I don't really have strong feelings about it, though - up to the UX team to decide. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161037] UNO Sidebar 'Hide' and 'Show' sidebar deck (splitwin) -- a new function (available for assigning a shortcut key to it)
https://bugs.documentfoundation.org/show_bug.cgi?id=161037 --- Comment #3 from Michael Weghorn --- (In reply to V Stuart Foote from comment #1) > This is expected with the current +F5 toggle (.uno:Sidebar) which > *closes* or *opens a new instance* of the SB framework. Its workflow and UI > behavior is pretty consistent, as is that of the F11 "Stylist". > > Also, UNO are already available and assigned to open each SB Deck (bug > 84502); +[1-9] with 1-4 common (uno:PropertyDeck, uno:StyleListDeck, > uno:GalleryDeck, uno:NavigatorDeck) across the modules. Could making Alt+[1-9] *toggle* the current state of the corresponding deck maybe be a potential solution, i.e. switch to that deck if it's currently not active, and collapse it if it currently is active? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161078] Allow direct formatting for page sequences instead of editing the style
https://bugs.documentfoundation.org/show_bug.cgi?id=161078 --- Comment #5 from Mike Kaganski --- Additionally, the page styles are *actually* not the problem that users struggle with. The largest user problem with page management in Writer is the concept that page sequences are *properties of text* (currently paragraphs and tables). This is not obvious; this creates confusion. There is missing UI for both easy *identification* of existing page sequences, and easy *application* of the wanted page properties (styles) to a user-defined range. My strong opinion is, that simply solving these UI problems without any DF in pages would solve most of the user confusion around page styles. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161078] Allow direct formatting for page sequences instead of editing the style
https://bugs.documentfoundation.org/show_bug.cgi?id=161078 --- Comment #4 from Mike Kaganski --- (In reply to Eyal Rozenberg from comment #3) > But what is your opinion, Mike, on DF of page _sequences_? IIUC, the suggestion is to create a way to allow a *paragraph* (the entity that defines the page sequence) to use a *set of direct page properties* as an alternative to a specific page style. Am I right? Note that it is *orthogonally* desirable to introduce a new mechanism of page sequence bounds - e.g., a page break object *inside* paragraphs (similar to line breaks), which could also define page properties (page style as it is currently, or a set of direct page properties, as I understand your request). Now technically, it is not impossible. Internally, direct formatting is still implemented as a special kind of *style* (autostyles); but what would be the upside of this, and how could the *user management* be realistically implemented for any kind of page-break-with-direct-page-properties, which would be easy and different compared to the current situation? Including the important "next page style" mechanism, which needs referring to the set of properties of the next page, currently implemented by referring to the style name? I can see a dialog for "page break properties" (accessible from any page break, like paragraph, table, or the imagined intra-paragraph dedicated breaks), which would be ~identical to the current page style dialog. But it is completely unclear how that would be an improvement, given that such a set of properties would lack a big part of functionality allowed by styles, when it goes to the next page style machinery (which is important for things like e.g. odd-even/left-right/whatever sequences, or first chapter page - the rest of chapter page sequences, which is also very important part of page management). I do not see this whole suggestion as any kind of UX improvement; any "this is internally inconsistent" is IMO not a problem per se, and if some *real* UX problem can be solved by changing UI without introducing a direct formatting for pages, I strongly oppose this bug 161078 suggestion. I do not see a specific use scenario that gets better with this suggestion. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 161078] Allow direct formatting for page sequences instead of editing the style
https://bugs.documentfoundation.org/show_bug.cgi?id=161078 --- Comment #3 from Eyal Rozenberg --- (In reply to Mike Kaganski from comment #2) > No. It is legitimate as long as there is no "page as a primary object" in > Writer (which is the case), unlike characters, paragraphs, and other primary > objects, that need *some* place, and by that, initiate *automatic* creation > of pages, which uses properties of respective paragraphs (primary objects). Yes, certainly. Note I kept saying "page (sequence)" to emphasize that it's not one page; and that I'm not suggesting making a single page a primary object. So does the bug title. But what is your opinion, Mike, on DF of page _sequences_? -- You are receiving this mail because: You are on the CC list for the bug.
