1. Insert - Fields - More Fields (Ctrl-F2) 2. Document tab 3. Under Type, choose {Chapter, Page, Template} Actual result: choices shown in Format Proposed result: choices shown in Select Reasons: 1. All other Types are shown in Select, where Format modifies how the Selection is presented. 2. Makes it easier to explain on Help page. Have filed as enhancement, but could be considered bug from UI POV.
Regarding to https://help.libreoffice.org/7.0/en-GB/text/swriter/01/04090001.html?System=WIN&DbPAR=WRITER&HID=modules/swriter/ui/flddocumentpage/FieldDocumentPage#bm_@@nowidget@@ Format is limited to selection of number formats. So I agree, that current situation is a bug => NEW https://help.libreoffice.org/7.0/en-GB/text/swriter/01/04090001.html?System=WIN&DbPAR=WRITER&HID=modules/swriter/ui/flddocumentpage/FieldDocumentPage#bm_@@nowidget@@
Maybe an Easy Hack? adding needsUXeval and cc: Ayhan Would be useful for UI consistency and simplifying help page.
Issue is clear. Guess it has been done because of the input control below the right column. Adding/moving this to the middle column would make the UI jump; and keeping it there divides the configuration. We could list the 1..10 levels under Format instead of the spinner, not really nice though.
(In reply to Heiko Tietze from comment #3) > Adding/moving this to the middle column would make the UI jump; It already jumps. Try between "Chapter" and "Template". Change would make "less" jumping. Try "Statistics" and "Template" currently gives bigger jump than if moved. Try "Date" vs. "Chapter"
(In reply to sdc.blanco from comment #4) > It already jumps. Try between "Chapter" and "Template". Don't see it jumping. The "details" input below the format list shows up or is hidden, sometimes it's a spinner sometimes a checkbox. But it never moves to the middle column.
(In reply to Heiko Tietze from comment #5) > Don't see it jumping. The "details" input below the format list shows up or > is hidden, sometimes it's a spinner sometimes a checkbox. But it never moves > to the middle column. Clarification of misunderstanding: For Types: Chapter, Filename, Template, moving what is currently shown in "Format" to "Select" does not entail moving the control under the Format box (i.e., "Fixed content", "levels", etc.) (That was not meant to be part of the OP). In short, no "jump" with that part (if that was what you meant).
We discussed the topic in the design meeting and decided to show the list in the middle column. Might be an easyhack yet somewhat tricky. UI is sw/uiconfig/swriter/ui/flddocumentpage.ui code at sw/source/ui/fldui/flddok.cxx
Hmm. This is not a bug actually, and should not be fixed. The "Type" and "Select" lists together define *which* data to display. "Format" tells *how* to display it. E.g., for "Author" type, we see the choice of *two different* pieces of information available in Options|LibreOffice|General: Name and Initials. They are not different representations of some single information: they may happen to be present both, or none, or only one present. So choosing this in "Select" list defines which information to display. Or for Date: depending on the choice (fixed or not), the field will display one date value or the other. But in case of chapter, the data being displayed is the same (the paragraph with non-0 outline level). There's no choice where to take the information from; only how to present it (you may choose to display the text, or the number, or both; just the same way as you may choose to display year, or year plus month, or year, month, day, and time for datetimes). Please review.
(In reply to Mike Kaganski from comment #8) > Please review. Author > Name != Chapter > Name is at least surprising for ordinary users. Sascha, rather keep the current implementation?
Well, not all that is inside the Format-list is actually a format-variation. So we have to chose one-by-one. My suggestion so far: Document > Chapter > Chapter name > Chapter number > number and name > number without separator File name > File name > File name with extension > File name without extension > File Path > Path with file name > Path without file name Templates > Category > File name > File Name with extention > File name without extention > Path > Path with File name > Path without File Name > Style Variables > Set variable > Text > Character > Number > Integer > Floating Point > Additional Formats User Field > Text > Character > Formula > Integer > Floating Point > Additional formates > Standard > Integer > Floating Point > Additional formates In this order we rather create some placeholder entries in the current empty Selection-lists, namely Total editing time, DDE field, Insert Formula, Show page variable, User Field
BTW -- just an observation for those who care -- isn't "Chapter" a terminological dinosaur (i.e., a relic from a bygone era)? "Paragraph with non-zero Outline Level" describes more accurately the actual behavior of the inserted "type". Perhaps something like "Heading" is closer to what a user might comprehend (or expect with such a label).
(In reply to Sascha Z from comment #10) > Well, not all that is inside the Format-list is actually a format-variation. > So we have to chose one-by-one. My suggestion so far: Speaking now only about Document tab. 1. Usually "format" is showing only (familiar) controls for time, date, and number, with an additional format option (for time and date). (This makes sense) 2. Moving all the different file and chapter (heading) variations into Select also makes sense. It is a psychological problem of UI, not a logical problem of trying to find a consistent category system (especially when speaking about fields, right Mike?). 3. Mike argues that "Name" and "Initials" are "two pieces of information". But we can also say that "filename" and "path" are two pieces of information. 4. Honestly -- when is the last time you have thought about the "format" of a file name? Functionally filename, filename with path, filename w/o extension can be treated as different kinds of information (Same point with headings). (why force a user or programmer into trying to decide this philosophical problem about when it is a format and when it is a select? -- the options are limited to four, or six in the case of template -- and not likely to increase -- much easier to just move them to Select.) Just to underline the arbitrariness of trying to follow a "logical" system here: Consider Mike's example with "Author" type and "name" and "initials" being two pieces of information. One could also argue that "name" and "initials" are just two formats, because, "There's no choice where to take the information from; only how to present it" It is just an accident that LO implementation allows a user to give arbitrary initials, independently of First/Last name. If the software automatically determined the initials from the First and Last Name in User Data, then on Mike's logic, Name and Initials should be moved to Format. Logically correct. Functionally dubious.
(In reply to sdc.blanco from comment #12) It's up to design team to restructure it here. I only pointed out that currently LibreOffice consistently follows *its* design - wherever something is entered in one box, like filepath, it's one piece of information. If it's entered in different boxes in the application, it's different pieces. You are breaking the consistency, and instead trying to make "psychological" decisions - thus necessarily becoming subjective: neither consistent, nor covering everyone's PoV. But no objection from *my* side - I can always look into the code to know, and into the git log to blame ;-P
(In reply to Mike Kaganski from comment #13) > You are breaking the consistency, and instead trying to make "psychological" > decisions - thus necessarily becoming subjective: neither consistent, nor > covering everyone's PoV. But being consistent does not cover everyone's POV either. (-: > It's up to design team to restructure it here. Thanks for clarification. To design team: please consider consequences of the UI design for writing clear documentation (which is what motivated the OP).
(In reply to sdc.blanco from comment #14) > > thus necessarily becoming subjective: neither consistent, nor > > covering everyone's PoV. > But being consistent does not cover everyone's POV either. (-: Currently it has one of two - not covering everyone's PoV, *but* *is* consistent; proposal looses that property ;-P
(In reply to Mike Kaganski from comment #15) > Currently it has one of two - not covering everyone's PoV, *but* *is* > consistent; proposal looses that property ;-P My point is: I repeatedly random (from my PoV) decisions by design team, that are not based on actual quantitative analysis of benefits vs drawbacks; that don't take overall architectural picture into account; e.g. here, I don't see an analysis like "This will change this from consistent into inconsistent; yet, we estimate that about 60% users who currently use this feature have problems, and the suggestion is expected to lower that number to 35%".
(In reply to Mike Kaganski from comment #16) > My point is: I repeatedly random (from my PoV) decisions by design team... Harsh words, and you didn't address the design team (CC now). I take it, though.
(In reply to Mike Kaganski from comment #16) > that don't take overall architectural picture into account; e.g. here, I > don't see an analysis like "This will change this from consistent into > inconsistent; yet, we estimate that about 60% users who currently use this > feature have problems, and the suggestion is expected to lower that number > to 35%". [avoiding politely the question of whether the possible change in consistency is "logical" or "subjective" (-: and completely oblivious of the overall architectural picture - but without disputing the general validity and importance of doing so ] How about an analysis like this (seriously meant): This change will guarantee with 100% that it will be possible to write a simpler, more comprehensible help page: https://help.libreoffice.org/7.1/en-US/text/swriter/01/04090001.html where (on this help page) all Types and Select items can be placed in a single table (so their relationship can be clearly indicated), rather than the current hybrid with a separate "Select" section, and where the instruction to the user is -- as the page currently says -- to insert a field, choose an item in the select list and press insert. (At present, the current help page is wrong, when some items to insert are in the Format frame. This change will also avoid having to find a way to explain these alternatives.) With all that in place, then it is easy to indicate that "Format" applies only Types "Date", "Page" "Statistics" and "Time", where format can be used to choose how dates, times, and numbers are displayed. Based on these potential improvements in the help page, we estimate that 3% of the users might read it, with 85% of them being able to successfully achieve (and/or) expand their possibility to use Document Field Types, with satisfaction. (ok, maybe this paragraph is only half-serious) Furthermore, it is predicted that with a consistent relation between Type and Select, and useful explanations of Field Types and Select in the Document Fields help, then users will gain advantage in understanding the DocInformation tab and the Variables tab, where all fields are inserted from the "Select" frame, and where Format is used (in DocInformation) like in Document to control dates and times (no numbers there) and roughly the same in Variables (now with numbers, and with greater numerical display variations (plus text) because of "Additional formats"). I suspect there already exist usability studies that show the advantage of a consistency across the tabs of the UI -- even if there are not studies of this particular Insert Fields dialog (with its different tabs). ---Please -- no reply to this analysis is needed -- but I wanted to lay out the main issue that motivated the OP and comment 14 ----
Apparently a delicate subject. And since no further comments have been made, I'll resolve as NAB. Request is not based on actual user mistakes but comes from a documentation problem. Current implementation is consistent and has proven to work. Any change might cause other trouble and new inconsistencies.