Bug 144814 - Options dialog has some settings specific to current document & stored within it
Summary: Options dialog has some settings specific to current document & stored within it
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Options-Dialog File-Properties
  Show dependency treegraph
 
Reported: 2021-09-29 19:57 UTC by John
Modified: 2024-01-05 13:33 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John 2021-09-29 19:57:58 UTC
Description:
There is a very serious UI problem with LO settings. The problem is that some of these settings are stored in the document/template, and some of them are stored in the application itself.

**It is assumed you have a new LO user profile and LO uses US measurement units (specifically, inches) by default. We will test the Writer application.**

Open "Tools > Options > LibreOffice Writer > General" and notice the following two settings: "Measurement unit" and "Tab stops".

a) The value of "Tab stops", if you change it to a custom value and then save the document, will be stored in the document.
b) ... While the value of "Measurement unit" is always stored in the application.
c) Ah! And if you change the value of "Tab stops" to a custom value **without** saving the document, this custom value will be stored in the application and not in the document.

And please notice that there are no hints to the user that these settings are stored so differently.

And here is how confusing it can be in the real life:

1. Create an unsaved document.
2. Tools > Options > LibreOffice Writer > General:

   1. Measurement unit = Change it from "Inch" to "Centimeter"
   2. Tab stops = Change it from "1.25 cm" to "1.00 cm"

   HERE IS WHAT IS CURRENTLY GOING ON:
   * "Meas. unit" is stored in the application (as always)
   * "Tab stops" are stored in the application as well (this because we
      aren't going to the document at this moment of time, see the next step.)

3. Close the document without saving it.
4. Create another document. Notice the settings are the ones you have set up: "Centimeter" and "1.00 cm". This is fine.
5. Save the document.

   HERE IS WHAT IS CURRENTLY GOING ON:
   * "Meas. unit" is stored in the application (as always)
   * "Tab stops" are stored in the document (since you have saved the document)

6. Change the values to "Millimeter" and "6 mm"

   HERE IS WHAT IS CURRENTLY GOING ON:
   * "Meas. unit" is stored in the application (as always)
   * "Tab stops" are stored in the application as well (this because we
      aren't going to the document at this moment of time, see the next step.)

7. Close the document without saving it.
8. Open the saved file. Its values will be "Millimeter" and "10 mm"

This is really confusing even for many experienced users who already aware of how this works. This is because the are many different settings and users **cannot** remember which of them are stored where. And so they cannot predict how some settings will change if you change the template. Or if you open the document on another computer.

And this is much worse for many people who aren't so experienced.

It seems to me that settings that are stored in the document and not in the application

Solution-1: Should be "marked" as such. For example, instead of "Tab stops" it should be "Tab stops [D]" (where D stands for "document").

or

Solution-2: They should be moved to a separate section.


Steps to Reproduce:
see above

Actual Results:
see above

Expected Results:
see above


Reproducible: Always


User Profile Reset: No



Additional Info:
see above
Comment 1 John 2021-09-29 19:59:56 UTC
> The problem is that some of these settings are stored in the
> document/template, and some of them are stored in the
> application itself.

The problem is that there is no hint to the user which of these settings are stored where.
Comment 2 John 2021-09-29 22:02:56 UTC
> this because we aren't going to the document at this moment of time

a typo.

There should be

> this because we aren't going to save the document at this moment of time
Comment 3 Heiko Tietze 2021-09-30 07:24:48 UTC
You request a solution but should report a problem with a use case.

The tab stops clearly needs to be stored in the document - you want the defined 1cm on every workstation and all applications. Whether this distance is 1cm or 0.39" is a matter of the UI, internally we likely use Twip. 

In general, all default values are set-up via tools > options while document related properties are defined in other dialogs (which pick up what is defined as default).

Admittedly we discuss from time to time where attributes belong to (for example the document language). But it's a per case solution.

=> WF (happy if you or others reopen)
Comment 4 John 2021-09-30 08:01:15 UTC
The problem is that it makes harder for a user to understand what is going on.

Sooner or later the user will face with a situation where some of his settings are "reset" and some are not, and he doesn't know why.

Or a technical writer may write instruction about how LO should be configured in his organization, but he would prefer to avoid giving directions regarding settings that are already set up in the corporate template.
Comment 5 Telesto 2021-09-30 12:57:04 UTC
(In reply to John from comment #4)
> The problem is that it makes harder for a user to understand what is going
> on.

In the process of deciphering the problem. My vision:

The case
1. Open Writer
2. Tools > Options > LibreOffice Writer > General:
3. Measurement unit = Change it from "Inch" to "Centimeter" or if the default is Inch visa versa)
4. Tab stops = Change it from "1.25 cm" to "4.00 cm"
5. Press OK
6. Close the document
7. Open new document
8. Press Tab -> 4 cm jump and type something say AAA
8a. Save the document as ABC
9. Open a new document
10. Tools > Options > LibreOffice Writer > General:
Measurement unit = Change it from "Inch" to "Centimeter" or if the default is Inch visa versa)
11. Tab stops = Change it from "1.25 cm" to "0.50 cm"
12. Press OK
13. Press Tab.. Jumps in 0,50 cm (OK)
14. Close the document.. (No save
15. Reopen the document ABC
16. Press Tab.. jumps still 4 cm 
17. setting Tools > Options > LibreOffice Writer > General: Tab stop will be 4cm
19. Close the document
20. Open new document 
21. Press Tab -> Tab stops are 0,50 cm
22. Open ABC again
23. Setting Tools > Options > LibreOffice Writer > General. Change tab top to 2 cm
24. Press OK
25. The content in the document moves 2 cm to the right

The situation at step 17 and 21 rather contradicting. Tools > Options > LibreOffice Writer > General is an application setting.. But it shows the 'in document' setting, if the opened document has different tab stops embedded in the file (it's now not a 'application setting' but 'in document setting')

That fact that the setting from "Tools > Options > LibreOffice Writer > General" being embedded in to document when used makes sense. (Else you get 23-25 effect) on different systems. You can't force the LibreOffice configuration defaults on a document (would change the layout) 

However there is no way of managing tab stops, if you're working on a document with embedded tab stops generated by Tools > Options > LibreOffice Writer > General setting. When moving the document system A with certain configuration, the system B using different defaults (regarding to Tab stops).

The current behaviour surely confusing; counter intuitive and if you ask me wrong. There must be way to 'show' the in document tab stops..

Format -> Paragraph -> Tabs doesn't hold them Tab Stops created by "Tools > Options > LibreOffice Writer > General"(seems correct). There is simply lack of an dedicated dialog. And no 'in document' tab stops should be managed by "Tools > Options > LibreOffice Writer > General". That's the wrong location.
What the proper location to access those tabs stops would be is a different question...
Comment 6 John 2021-09-30 18:17:54 UTC
As an addition to Telesto's comment:

This issue is not about tab stops only. Tab stops are just one case, but if I remember correctly,  "Tools > Options" have more of them.

This issue affects settings in other places as well. For example, most "View > Zoom" is stored in the application, but the view itself ("View > Normal" or "View > Web") is stored in the document.

The whole idea of what I talking about is to make these things transparent for the user.
Comment 7 m_a_riosv 2021-09-30 21:02:20 UTC
I think it is already reported, but I can't find, about to have some indication on every option to know if they are for file and not general.
Something I think it's very helpful in general, without add new issues.
Comment 8 Heiko Tietze 2021-10-01 06:34:47 UTC
The more opinions the better. My take is a clear -1 / WF.

Although implementing might not harm UX when done unobtrusively, eg. with a different font color for the labels, it's far from obvious to users what this information means. And developers have a hard time to implement it.

Point is: all relevant information is stored in the document. If you find something which is not, report as an issue.
Comment 9 Telesto 2021-10-01 07:52:43 UTC
(In reply to Heiko Tietze from comment #8)
> The more opinions the better. My take is a clear -1 / WF.

Could please clarify what you're rating with -1 precisely . You're right about down voting comment 3. However, I don't think that that's being the topic. Talking past each other isn't really helpful. 
 
> Although implementing might not harm UX when done unobtrusively, eg. with a
> different font color for the labels, it's far from obvious to users what
> this information means. And developers have a hard time to implement it.

Me having surely totally different understanding of the topic. So yet again not following..

> Point is: all relevant information is stored in the document. If you find
> something which is not, report as an issue.

True; but is this the topic?

----

The case - as far I'm reading the request of the OP (Or I'm yet again talking about something totally different or different perspective)

I'm limiting myself to 'Tabs-stops' for now (admitting the scoping being larger)

They OP poster deploys systems with document templates. Sometimes the user wants a different tab stop setting compared to the embedded one. So you can point to:  Tools > Options > LibreOffice Writer > General.

However if you change the setting there, it doesn't only affect the only the opened document, but all new documents created in LibreOffice where no explicit tab stop being defined

I do think that should be possible to list all the in document defined settings. Which seems to be practical for authors of templates too. You else might be incident include something you didn't think off. As those are being introduced by LibreOffice General settings..

Tools > Options > LibreOffice Writer > General is a global setting, for all new documents. It is not the tool for CHANGING/EDITTING the pre-existing Tab stop setting for a single document.

Showing all embedded settings could be done in File -> Properties; which could look like the Style Inspector approach. 

Where talking about things like
* Default Printer
* Tab Stops
* Multipage - Single Page view
* Zoom-level???
* Last position in Document (I recall this being stored, or I'm I making this up?)
* Other additional options which are also stored in document (which needs checking the ODT specifications, I guess).

Is there any documentation (full list) of type of setting can be embedded in ODT?  

It also aligns - in my perception - with my request for showing the File Format Version somewhere in the Document Properties window.
Comment 10 John 2021-10-02 14:43:14 UTC Comment hidden (obsolete)
Comment 11 John 2021-10-02 16:48:37 UTC
The previous comment is not precisely accurate. Here is a fixed version:

Some settings are stored in the application; some in the document; and some in both the application and the document if you save the document afterwards, and only in the application otherwise. The problem is that LibreOffice does not differentiate these kinds of settings for the user, and so you do not know if the current value of the setting that you are about to change is "inherited" from the application or is stored in the document, and you do not know where it will be stored after you change it.
Comment 12 Telesto 2021-10-04 09:37:34 UTC
@Mike
Would be nice to have your perspective on the matter too.
Comment 13 Heiko Tietze 2021-10-04 09:55:29 UTC
(In reply to Telesto from comment #9)
> Could please clarify what you're rating with -1 precisely

I doubt that giving feedback on where options are stored
a) is of practical use,
b) can be done unobtrusively,
c) would be possible with a reasonable amount of work.

Regarding a) I said, _all_ options that are relevant to reproduce the layout pixel-perfect cross-platform and cross-application are stored in the document. The tab stop is such a value while the unit is not. We may have bugs here.

In respect to b) it might be a different color for the label or a small icon/symbol next to it. In any case it first of all clutters the UI and secondly makes ordinary users who don't care about the options wonder what this indicator is meant for.

And last but not least, c) is important. There might be cases where a setting is stored only in some cases in the document. Many of what is configured in tools > options can be tweaked per document at other dialogs. An example is your locale which defines whether documents are letter or A4 but ultimately it's the page style what defines the layout.

Admittedly, if all my concerns are neglectable it would give some confidence in what you configure and how it works.
Comment 14 Mike Kaganski 2021-10-04 09:59:32 UTC
(In reply to m.a.riosv from comment #7)
> I think it is already reported, but I can't find

Same with me.
This is *definitely* a must. Having document-specific properties in Options is plain wrong. People should not be expected to look for such options there, and you will not find a "this is intuitive" reason for such placement; no "UI simplification" is an excuse for that. In case when there are defaults (suitable for Options dialog), they should be limited to the "defaults" in Options, and should never suggest to also/alternatively modify current document's properties. There should be document-specific location for its properties - likely in File->Properties (but it's debatable, of course); the two locations could have inter-links, like buttons "Default..." in File->Properties dialog, pointing to related Options tab.
Comment 15 John 2021-10-04 12:03:15 UTC
To Mike and Heiko:

I agree that changing how settings are currently organizing would be a large amount of work. Probably too large.

But what is much simpler is to add [D] after each setting that is stored per document.

Example 1:

  Tools > Options > LibreOffice Writer > General:

  * Measurement unit: ...
  * Tab stops [D]: ...

Example 2:

  View:

  * Normal View [D]
  * Web View [D]

D stands for "document", of course. Another option is to use asterisk* instead of [D].

Of course, [D] (or asterisks) will clutter up the user interface a bit. But in my personal opinion this the case where a little cluttering is justified. The main thing about user interfaces is that they should be understandable.
Comment 16 Eyal Rozenberg 2022-11-06 22:29:39 UTC
I staunchly support "solution 2". I claim that _no_ setting in an application's options dialog should be a document- or file-specific setting. The dialog should _only_ have application-level settings, inspecific to a single file, which are saved in the app's configuration files and apply to all relevant documents. I claim that this is what users expect; it is what's common in other applications; it is a reasonable, almost necessary, separation.

I therefore disagree that the problem can be resolved by an indication or hint of what gets stored where. Instead of hinting or indicating we should just avoid this ambiguity from the get-go. Document-specific settings belong in document properties, or other document-specific dialogs.

I myself had not even realized until the other day that this was even the case! And I consider myself to be a somewhat experienced user...

That all being said... :

* I recognize some settings are app-level defaults, which are saved in documents since the documents make a copy of those settings. For example, default Western language to use, or tab stop size etc.
* There may be some settings for is ambiguous whether they should exist at document-level or app-level, and the way the dialog is structured has allowed the maintenance of this ambiguity without having to decide this way or the other, and without duplicating the default and per-document setting.

... and those need special care.

--------

(In reply to John from comment #15)
> I agree that changing how settings are currently organizing would be a large
> amount of work. Probably too large.

It's a lot of work, but not "too large" IMHO. Why? Because:

1. After all, it's just moving settings between dialogs. I mean, it's not about re-implementing the mechanisms affected by those settings or touching them at all. Dialog redesign is significant work, but it's not like there could be all sorts of arcane bugs, or perf issues, or refactoring hairy code etc.
2. It doesn't all have to happen at once. If targets for different settings are located, or created, they could have settings moved there gradually. We're in a messy situation already, so a partial move doesn't make things that much more messy
3. It doesn't all have to happen at once II: Since the options dialog is a rather stable entity, a move could be worked on gradually in some branch for a while before being rebased on the latest development version.

> But what is much simpler is to add [D] after each setting that is stored per
> document.

I'm not sure it's simpler. I mean, it may be simpler to implement, but it would be quite a user-unfriendly eyesore IMO.

So again - "solution 2": Let's separate app settings from document settings.

Finally - I've rephrased the title to reflect the fact that the solution has not yet been chosen definitely, and to mention "Options dialog" explicitly. I also suggest that we change the severity from "enhancement" to "major".
Comment 17 Stéphane Guillou (stragu) 2022-11-21 14:44:24 UTC
(In reply to Telesto from comment #9)
> Is there any documentation (full list) of type of setting can be embedded in
> ODT?  

I agree that a list per-document settings would be very useful here, and that the best solution would be to have per-document settings set outside of the Options dialog.

If we are going that way, we can create more focused bug reports on the per-document settings that need to be "extracted" from the Options dialog, and make them block this bug report. Some elements might feel more like a priority.

Adding a visual indicator for each setting feels like a band-aid, and will add unnecessary clutter when we could instead make it unobtrusively clearer by keeping as many per-document settings as possible _out_ of the Options dialog.
Comment 18 Mike Kaganski 2022-11-25 11:40:22 UTC
(In reply to Stéphane Guillou (stragu) from comment #17)
> I agree that a list per-document settings would be very useful here...
> 
> If we are going that way, we can create more focused bug reports on the
> per-document settings that need to be "extracted" from the Options dialog

Please go ahead and start creating such bug reports, without blocking on a "list per-document settings", which would require some extensive analysis for no real benefit. If one sees a single such option, and points to it, like e.g. here in the comment 0, it's enough reason to file it, and act on it, which would gradually get the end goal.
Comment 19 Stéphane Guillou (stragu) 2022-11-30 12:18:46 UTC
Marking as NEW as something clearly needs to be done according to comments.

Some of these issues are bound to be inherited from OOo.
Comment 20 Seán Ó Séaghdha 2022-12-17 06:28:55 UTC
Just adding my support for removing any document-specific settings from Tools|Options.  It’s just too confusing and adding indicators or colours would be a poor fix.