The Area tab is found in many dialogs (e.g. paragraph style, object area), but the user interface and user experience of using it needs improvement. The major UX problem with the Area tab is that it limits users to select from a defined list of presets, which limits their ability to customize the area fill. To get around this preset limitation, some dialogs will have a Colors, Gradients, Hatching and Bitmap tabs, so users can switch to those tabs to add a preset to the list and then return to the Area tab to apply it. The major UI problem with the Area tab is that the preset lists are shown in a list-view rather than being in icon-view, which results in a large waste of space within the dialog. Icon-view would save users from scrolling through a long list of presets and also see more of the presets at a single glance. Having an all-in-one contained tab will also reduce bugs that occur when jumping from tab to tab to customize the fill.
Seems i forgot to set this as ux-advise. :D
The Area tab seems empty when the selection is "None". Each other option leads to a sometimes quite crowded panel. How would you organize the Area tab when using an icon set instead of a scrollbar?
(In reply to Jean-Francois Nifenecker from comment #2) > The Area tab seems empty when the selection is "None". Each other option > leads to a sometimes quite crowded panel. How would you organize the Area > tab when using an icon set instead of a scrollbar? Well i would utilize the icon view found in Format > Object > Area > Colors or Format > Character > Highlighting. All are welcome to join the design session on friday at 11am utc, as me and Heiko will be working on mockups for the redesign of this tab. I've started gathering details for its implementation here - https://docs.google.com/document/d/1gf7wqYszXnbrbzbyNlLKbJelMb20ssuimxfszcHP_wM/edit?usp=sharing
Created attachment 119263 [details] initial mockups Last friday, Heiko, Bubli, Samuel, Tomaz and I were discussing the redesign of the Area tab. We were able to create some initial mockups and all are welcome to comment on them here or in the google doc.
Currently the fill bitmap UI follows Heisenberg's Uncertainty Principle. You can set the exact scale of your bitmap, but not the position. Or if you set the position, but you cannot change the scale. If we allow the user to set both both scale and position of bitmaps in filled shapes, we make the bitmap feature much more flexible and useful. Currently the only way to achieve a specific desired result, is to scale the bitmap in outside application and then use the position controls. This is far from ideal. I don't know how much of a backend vs UI this feature is, but it is definitely what we should eventually be shooting for. See Bug 95165.
Aren't you afraid of some quantum instability in case of full control? The idea behind the proposal was how wallpapers are aligned. Right now you get a couple of mutually exclusive options. Adding more features complicates the interaction. You can place images with exact position and size, why is it necessary for the fill style of areas? BTW: The proposal was published here https://design.blog.documentfoundation.org/2015/12/22/area-fill-options-made-consistent/
Yes it important to have the ability to be able to set both the scale and position of bitmaps in a shape, as the current options in the mockup dont provide that. The wallpaper proposal does fit handle alot of scenarios, but i would assume a common scenario with setting an image as the fill of a shape would involve using the shape's shape as a border and positioning the image at a specific location within the image (e.g. around the head of one of the students in a class photo). I had seen this done in iWorks interactively without a user having to open a dialog ( https://www.youtube.com/watch?v=EjjAA96aSXY ).
Another feature that we should plan for is "Rotate fill effect with shape". See Bug 34551.
Created attachment 125847 [details] Preliminary solid fill tab Rishabh managed to provide means to select the palette at the solid color tab and shows the containing colors nicely. The question is what happens with the interactions (add, modify, delete). Option 1: We let users do whatever they want. Meaning the palette standard.soc may end up empty. Option 2: We allow to change not all (e.g. standard.soc) but a selection of palettes. Option 3: Changes go into a (newly to introduce) user.soc (or whatever this extra palette is called) Option 4: We disable the buttons in this tab Option 5: We allow everything (like #1) but restore the factory settings per "reset". Option 5 is the most user-friendly way. It would work only when the content of the soc files are stored as an additional ressource. But maintainability would seriously diminished. Opinions?
I choose option 3 and we can represent it similar to the 'Recent' section in the color drop down widget and title it 'Custom Colors' or something like that.
Having your choice between using your application's standard colors and your document's custom colors is how most office and image manipulation programs work. So Option 3: seems to be the most general, most interoperabile choice that fits with this model. Standard and MSO theme palettes should be read only. And there should be one custom color table that the user can edit. If we wanted to improved ease of use, we could have a recent list of used color.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ca504cd4ca381e5d24a82e588dac51c344c6f946 tdf#94551 Preset list: 3 entries per row and always show scrollbar It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c33f0e0c8579be4744902ca92fe5d8f7ae2d60e4 tdf#103223 Arrange buttons, add spacing and separator to Area tab It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
Set to RESOLVED FIXED as this was implemented in 2016. Open issues are listed in Area-Fill-Tab meta bug 103223.