Created attachment 143571 [details]
Example for changed "Contains" section in Modify Style dialogues
The possibility to use hierarchical styles is a powerful tool particularly in order to edit larger and professional documents. In order to promote this feature and encourage users to use it, it is necessary, that the connection between superior and inferior styles is displayed as transparent as possible. Unfortunately to my opinion this is not the case. Especially it is not very transparent which formattings are inherited to a inferior style and which are different compared with a superior style. One enhancement is already proposed in bug 88559. Here I propose an additional enhancement respective this issue.
Access to the formattings of a style you can get via the modify dialogue of the styles.
In order to open the modify dialogue:
(a) Open list of styles with F11.
(b) Choose style type (paragraph, character, …) at the top of the style list.
(c) Right click on a style and choose Modify…
The relevant informations according the inheritance of formattings can be found in the Organizer tab. In this tab there is a section with the heading “Contains”. According the Help the relevant formatting used in the current style should be described here. But what are the relevant formattings? For each user this may be different. It's also not obvious which formattings are supposed to be displayed here. See also bug 94395, bug 96382, bug 108293 and bug 102211. Furthermore the content of the Contains section is quite cryptic and not clearly displayed. In order to be sure which formatting is displayed here, in most times you have to browse the other tabs of the Modify dialogue.
With this report I propose to change the Contains section. All(!) differences and only these should be listed here. The heading should be changed from “Contains” to “Differences to style /superior style/:” Each difference should be listed in a new line and should begin with the tab, where the respective formatting can be changed. Furthermore each formatting should get a button, in order to set the formatting back to the inherited formatting. (similar proposed in bug 89826). With the attachment you can get an impression how the changed Contains section may look like.
Thanks for the suggestion and the elaborated mockup. There is bug 115311 about nested styles that also deals with hierarchies.
Thanks - I would simply say: if someone wants to make this: good idea.
So no need to keep UX in the loop, IMO
Small addition to the mockup:
The button wall could be made less obtrusive with an icon only design using e.g. a trash can symbol or per link. And less text is better so I wouldn't add "Tab" in front of every modification.
(In reply to Cor Nouws from comment #2)
> So no need to keep UX in the loop, IMO
Yes, maybe it's an easy hack. I set the importance to High given the large number of See Also.
I like the idea, to make it possible to clear a property in this place. Currently you can only clear all properties of a tab, but not a single one. And clicking OK on a tab might set properties, that you want to be still "inherit" whereas other properties on the tab you want to set.
I like the idea, that the associated tab is mentioned. I would like, if the property name is mentioned too.
The list of contained settings can become very long. So it needs to be something that it scroll-able. To get such huge list of properties do this: Create a shape with associated style and drag it into the Gallery. Start a new document and insert the shape from Gallery and keep it selected. Create a style from selection.
Created attachment 148150 [details]
For discussion I created another mockup. The main difference is, that the initial mockup is more a list whereas this one is a table. Therewith a user is able to compare the value of each preference between the inherited style and the current style easily, I also added a column for the value of the inherited style.
(In reply to Harald Koester from comment #5)
> Another mockup
We come very close to the desired solution so expect nitpicking. While the table feels not right to me, as it is a control for two-dimensional data taking hierarchical information here- maybe a tree would be better, it does the work well.
Besides the pure mockup you should always outline requirements and a verbal, generalized description.
* Eve wants to see what has been modified on a style to understand... (Why exactly do we need this feature?)
* Eve wants the list to follow the dialog layout to be familiar with the known structure.
* Eve wants to read actual and default value to see what exactly has changed.
And your concept would outline like this:
* Use the second column to list the dialog tab containing a modification.
* Use the third column to list the section (bold label).
* If a section contains an unlabeled option such as of checkboxes add it's label to the third column after a greater sign.
* If a tab contains combined sections ... (I cannot generalize "Position, Type, Fill")
* Show the current value in the fourth column.
* Show the default value in the fifth column.
* Provide a button in the first row to revert the modifications. (We have to describe what happens on click: would say the row is being deleted but it could also become strike-through, the button goes into Cancel, and all changes are not applied until the dialog is closed per Ok with Cancel doing nothing)
* Sort the rows starting with the second tab and add the first as last. (Really? *g*)
So close but no cigar :-)
Changing priority back to 'medium' since the number of duplicates is lower than 5
This has been implemented during GSoC20 by Shivam Kumar Singh , remaining tickets are handled in bug 134554.
(In reply to Heiko Tietze from comment #8)
> This has been implemented during GSoC20 by Shivam Kumar Singh , remaining
> tickets are handled in bug 134554.
Is this really fixed with the Style Inspector in a satisfying way? The bug opener mentioned that this should be an enhancement to make the style concept better visible and usable. Not to criticize the Style Inspector, but the deficiencies of the style dialog window are not gone with this new inspector tool.