Created attachment 113770 [details] mockup The sidebar contains many percentage fields in the properties tab in various sections (e.g. transparency field in the line section). Unfortunately these fields are overly large in width for no good reason except to keep the field aligned with other fields. It would be more beneficial to replace these fields with a slider control or alternatively have the slider next to a smaller field. I've attached a mockup but as we dont have any other sliders in the UI except in the statusbar, i used that as an example. It would be good to implement this same slider concept in the dialog boxes as well.
I think this is a nice proposal. Then you would theoretical have no more that much unused space and you would have an additional UI feature and such a system is also used for the zoom function in WRITER in the bottom right-hand corner of the main window and for the rotation feature in the Sidebar we have also a slider system. But from the layout it should then maybe also look like (at least similar to [with the circle]) the already existing zoom slider? The only thing I am thinking about is, whether there is then enough space for such a slider, meaning that the slider will not be too small and would be practial? In this case one has also to think about different (maybe longer) translations of "Transparency" in other languages. This is maybe a critical point for such a proposal. Otherwise, you would need to put the slider into a next line (like currently for the Line Style feature, though Jay has also another good proposal for this Line Style feature -> see 89543), but in this case the space issue would no longer really be touched with such a proposal, but you would nevertheless get this new UI feature and would no longer have this long not necessary input line. For me it would be interesting to get to know what others would think about such a nice and interesting enhancement proposal.
Sliders are a good means for arbitrary changes within a defined range. To support accessibility and in order to achieve precise input a spin box is sometimes appended that not only shows the actual value but allows to modify it. We should take care about a consistent implementation. Normally, min and max should be labeled (not necessary if the range is clear from content but consistency be respected). It's not recommendable to use non-linear scales (but often done for zoom; with more labels/tickmarks then). And for an appealing design it makes sense to have not too many sliders in one dialog/view. Jay's and Andy's examples make perfect sense. HIGs: Gtk2: https://developer.gnome.org/hig-book/2.32/controls-sliders.html Gtk3: (linked to the Gtk2 guideline) KDE Slider: https://techbase.kde.org/Projects/Usability/HIG/Slider KDE Slider + Spin box: https://techbase.kde.org/Projects/Usability/HIG/Slider_and_Spin_Box
Created attachment 113785 [details] improved slider (In reply to A (Andy) from comment #1) > But from the layout it should then maybe also look like (at least similar to > [with the circle]) the already existing zoom slider? I pulled the slider from the zoom slider for the mockup but was able to grab the correct slider control for my theme from glade, so i've attached an updated mockup. > The only thing I am thinking about is, whether there is then enough space > for such a slider, meaning that the slider will not be too small and would > be practial? In this case one has also to think about different (maybe > longer) translations of "Transparency" in other languages. This is maybe a > critical point for such a proposal. The slider isnt small in the new mockup. Well about longer lengths of the word 'transparency' in different languages, it would adjust according to the width of the string, just like it does now with the percentage field. > Otherwise, you would need to put the slider into a next line (like currently > for the Line Style feature, though Jay has also another good proposal for > this Line Style feature -> see 89543), but in this case the space issue > would no longer really be touched with such a proposal, but you would > nevertheless get this new UI feature and would no longer have this long not > necessary input line. A number of times, the transparency label is on a different line than the percentage field (e.g. Graphic section when you click on an image), so there isnt a problem there. :D
Places this should be implemented. Area section > Transparency Graphic section > Brightness, Contrast, Transparency, Red, Blue, Green
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue