Bug 94551 (Single-Fill-Tab) - All-in-one Area tab for modifying object fill
Summary: All-in-one Area tab for modifying object fill
Status: NEW
Alias: Single-Fill-Tab
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.1.0.0.alpha0+ Master
Hardware: Other All
: medium enhancement
Assignee: Rishabh
QA Contact:
URL:
Whiteboard: target:5.3.0
Keywords:
Depends on: 91281 94725 95165 100742 Area-Fill-Tab 104172 100682 100685 100728 100731 100743 100744
Blocks: Object-Fill Dialog
  Show dependency treegraph
 
Reported: 2015-09-27 15:05 UTC by Yousuf Philips (jay)
Modified: 2016-11-28 22:54 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
initial mockups (223.76 KB, application/vnd.oasis.opendocument.text)
2015-10-04 12:25 UTC, Yousuf Philips (jay)
Details
Preliminary solid fill tab (50.88 KB, image/png)
2016-06-22 20:23 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) 2015-09-27 15:05:00 UTC
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.
Comment 1 Yousuf Philips (jay) 2015-09-28 08:11:06 UTC
Seems i forgot to set this as ux-advise. :D
Comment 2 Jean-Francois Nifenecker 2015-09-30 17:13:44 UTC
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?
Comment 3 Yousuf Philips (jay) 2015-10-01 00:55:17 UTC
(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
Comment 4 Yousuf Philips (jay) 2015-10-04 12:25:42 UTC
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.
Comment 5 Luke 2016-02-12 03:58:26 UTC
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.
Comment 6 Heiko Tietze 2016-02-12 08:50:34 UTC
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/
Comment 7 Yousuf Philips (jay) 2016-02-12 13:02:51 UTC
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 ).
Comment 8 Luke 2016-02-13 08:35:06 UTC
Another feature that we should plan for is "Rotate fill effect with shape". See Bug 34551.
Comment 9 Heiko Tietze 2016-06-22 20:23:55 UTC
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?
Comment 10 Yousuf Philips (jay) 2016-06-23 13:14:57 UTC
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.
Comment 11 Luke 2016-06-23 18:35:15 UTC
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.
Comment 12 Commit Notification 2016-09-03 20:07:27 UTC
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.
Comment 13 Yousuf Philips (jay) 2016-10-16 15:26:41 UTC
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.