Now in the font size field in miscellaneous (styles) dialogs, the use can insert a pt (fixed) value or a percentage (relative) value. But it's not always obvious if it's possible to use percentage instead of pt. Some styles have percentage and some styles have pt values as default. To enhance the visibility what's possible I suggest to add a toggle feature in the near of the font size field where the user can choose percentage or pt. This toggle should be smart so that it automatically switches to "percentage" if the user enters a percentage value and vice versa with pt.
Just add a label saying "size of % relative base style"?
(In reply to Mike Kaganski from comment #1) > Just add a label saying "size of % relative base style"? Yes, that's a good idea but it's an addition to my suggestion. I want improve the general visibility of pt/% possibility in the size field and to make it easier to create styles with font size relative to it's parent style.
The topic is on the UX-agenda since a while and switching units on-the-fly would be a great enhancement. However, this topic is addressed in bug 72662, bug 44267, and bug 105176. So please consider to make it a duplicate.
*** This bug has been marked as a duplicate of bug 72662 ***
The description of Bug 72662 is about not using the standard, universally accepted units for font size and line spacing. One proposed solution makes it easier for the users to work around this UI failure. However it not clear at even that poor solution would directly fix this issue without further work. A much better solution would be to directly address this specific UI issue, rather than try to come up with a generic fix that makes the user micromanage units that shouldn’t have to be micromanaged. attachment 149725 [details] shows how WordPerfect gives the user a choice in an instances very similar to this where they can choice multiples vs line spacing in its natural unit, points. Writer does something similar with a drop down. It's much better to address cases like this individually, rather than expect the user to constantly manage every type of unit. We have natural units for a reason.
Personally I'd simplify all this to label strings and tooltips. Having the proposed (and mistyped in comment 1) "size or % relative to base style" would already make user aware of the option to use this (which was the initial rationale); and additional tooltip telling that it's possible to also use other units (like in, pt, mm, etc) would drive it further. Only after implementing simple helpers, more complex solutions should be invented.
(In reply to Luke from comment #5) > The description of Bug 72662 is about not using the standard... Now we discuss potential solutions on two places. > attachment 149725 [details] shows how WordPerfect gives the user a choice... Two units would be a good step ahead, for sure. But I suspect there are many scenarios where you need the micromanagement. For example, talking about Draw as worst-case you need A4 with points and lines to create a poster but meter/inches to scribble a floor plan. Sometimes you scale things and that requires percent. So while I totally agree on a sensible global configuration with two options or per-module configuration, we'd support working with different units very easy when switching per-control would be possible (and since this feature is a "hidden gem" it has no negative bearing on usability).
(In reply to Heiko Tietze from comment #7) > Draw as worst-case you need A4 with points and lines to create a poster but > meter/inches to scribble a floor plan. Sometimes you scale things and that > requires percent. If you want to make changing Units easier on Draw, I could see the advantage. I've used *drawing* apps that have this functionality and I see the advantage. However that change should not be applied across all the other applications in every dialog box with units. For all the other apps, we should just fix the UI on a case-by-case bases with a simple, clean solution, like Mike suggested. > suspect there are many scenarios where you need the micromanagement. We should not make the UI more complex on gut feelings. When I use MS Office at work, I do NOT miss having to switch between inch and point. I do get annoyed that I have to switch back and forth when I'm using LO because we incorrectly shown font sizes and line widths in non-standard units like inches. And no one likes overly complex UI always showing features that 99.9% of users will never need. In this case, we could use label strings and tooltips. And in Bug 72662, we could just use the same unit of measure that Word, WordPerfect,WPS Office... all use.
(In reply to Luke from comment #8) > However that change should not be applied across all the other applications... That leads to inconsistency. If you are able to configure something at one place (spinner in Draw) you don't understand why it's different on a similar-looking place (spinner in Writer). > We should not make the UI more complex on gut feelings. At least we agreed on one scenario, we likely find more. And I strongly believe hidden gems are killer features. You never get bothered with overly complex options unless pressing the right mouse button on a spinner. The point is you want a per-control configuration- and me too. I would ditch the Tools > Options configuration in favor of sane defaults and the opportunity to change per-control by the user. Don't see a drawback here.
(In reply to Heiko Tietze from comment #9) > That leads to inconsistency. A trade-off I'd prefer over the alternative. > Don't see a drawback here. Messy, cluttered UIs are slower to use and result in misclicks. I can use GIMP to make flowcharts. But I use Draw instead, because its simpler UI is faster to work with. I do not think Draw needs messy dialogs like GIMP. If we do go down this road, it shouldn't drag down the UX of every other component with it for the sake of "consistency".
(In reply to Luke from comment #10) > Messy, cluttered UIs ... I do not think Draw needs messy dialogs like GIMP That's far away from the proposal. The UI changes are zero, actually -x because some T>O settings are obsolete.
(In reply to Heiko Tietze from comment #11) > (In reply to Luke from comment #10) The UI changes are zero Then you run into a discoverability issue. If the UI looks identical, how will people know to look for it? > actually -x because some T>O settings are obsolete. If we used sane defaults for typeface units, this would be a rarely used feature. Neatly tucked away in T>O is exactly where it belongs.