|
Description
Harald Koester
2018-07-16 12:13:05 UTC
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]
Another mockup
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 [1], remaining tickets are handled in bug 134554. [1] https://shivam-51.github.io/ (In reply to Heiko Tietze from comment #8) > This has been implemented during GSoC20 by Shivam Kumar Singh [1], 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. |