Repro.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.4.0.0.alpha0+
Build ID: a564821eb9e991774195120e6965b2a8b1419dc5
CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on December 9th 2016

All these fields have been there since LO 3.3 and they never had tooltips.

@Heiko, @Stuart: Any thoughts of whether they are needed or not, as for me i dont think they are needed, as it looks self explanatory to me with all the labels we already have?

(In reply to Yousuf Philips (jay) from comment #2)
> All these fields have been there since LO 3.3 and they never had tooltips.
> 
> @Heiko, @Stuart: Any thoughts of whether they are needed or not, as for me i
> dont think they are needed, as it looks self explanatory to me with all the
> labels we already have?

Really ? I guess nobody uses these functionalities because nobody understand how each parameter acts to modify the result.
A label is not an explanation, it is only a name that is useless without a descriptive tooltip.

Size: how do you know the original size when you have only percents ?
Percents: percents of what ? The original size or the size of the object?
Original size: I guess it is the size of the pattern. What is the unit? cm or pixel?

Without explanation, the user can only randomly play with parameters until she obtains almost what she want.

Best regards. JBF

@Jay, *

To be honest the reworked Area dialog, or the Frame dialog in general and their Help--i.e. tooltips & extended tooltips--have really diverged from description(s) we provide in the local and on-line help--and in the published guides.

For these areas of the UI that have changed so much, providing a corrected tooltips for each widget really should be the norm--it is the least we should do for the users.

And of course the extended tool-tips from help are a component of our a11y AT support. When we lack a specific tool-tip/extended tool-tip for each widget the a11y assistance becomes annoyingly repetitive using a generic.

(In reply to Yousuf Philips (jay) from comment #2)
> @Heiko, @Stuart: Any thoughts of whether they are needed or not...

Guideline wise: Provide a tooltip for every control. And I agree with JBF and VSF that it's very relevant for this dialog. Question is rather if we can introduce new text in this phase of the release since it needs to get translated. @Sophie?

(In reply to Heiko Tietze from comment #5)
> (In reply to Yousuf Philips (jay) from comment #2)
> > @Heiko, @Stuart: Any thoughts of whether they are needed or not...
> 
> Guideline wise: Provide a tooltip for every control. And I agree with JBF
> and VSF that it's very relevant for this dialog. Question is rather if we
> can introduce new text in this phase of the release since it needs to get
> translated. @Sophie?

Hi Heiko, you have until week 51 to provide them, which is next week, see 
https://wiki.documentfoundation.org/ReleasePlan/5.3#5.3.0_release
Jean-Baptiste, thanks for reporting this one, +1 with Stuart comment - Sophie

(In reply to Jean-Baptiste Faure from comment #3)
> Really ? I guess nobody uses these functionalities because nobody understand
> how each parameter acts to modify the result.

Your description talked about the entire area tab and taking the entire area tab as a whole, most parameters are clearly explained by their labels. For example the palette label on the color tab, the from label on the gradient tab, the style label on the bitmap tab, the foreground color label on the pattern tab, and the line type label on the hatching tab.

Your arguments seems to solely focused on the bitmap tab, so lets address its issues. Yes the bitmap tab was quite confusing with all its parameters, which is why we redesigned it for simplicity.

> A label is not an explanation, it is only a name that is useless without a
> descriptive tooltip.

A label is a short description which isnt useless without a tooltip or are you saying the every single dialog in LibreOffice without description tooltips need to be changed?

> Size: how do you know the original size when you have only percents ?

In what unit are you looking for the original size? What is the importance of the original size in non-percentage values when you are filling an area with a bitmap?

> Percents: percents of what ? The original size or the size of the object?

Percent of the bitmap size, we are on the bitmap tab.

> Original size: I guess it is the size of the pattern. What is the unit? cm
> or pixel?

Not sure where 'Original size' is.

> Without explanation, the user can only randomly play with parameters until
> she obtains almost what she want.

With or without explanation, users not familiar with a dialog's controls will randomly play with the parameters as part of the learning process, i do that quite often myself, which is why we created the style presets drop down to fulfill most users needs to fill a bitmap in an area.

(In reply to V Stuart Foote from comment #4)
> For these areas of the UI that have changed so much, providing a corrected
> tooltips for each widget really should be the norm--it is the least we
> should do for the users.

Dont think its a good idea to add .ui tooltips to assist the lack of good UI/UX intended to help old users get familiar with the new UI. This should be fixed at the help level with extended tooltips where we currently have inaccurate tooltips.

> And of course the extended tool-tips from help are a component of our a11y
> AT support. When we lack a specific tool-tip/extended tool-tip for each
> widget the a11y assistance becomes annoyingly repetitive using a generic.

As the help will take its time to catch up to these changes, we should make sure that a11y users without help installed aren't negatively affected by the bitmap tab. @Alex, @Texou: Can you do that for us?

Off the top of my head, i can imagine that the 'W', 'H', 'X', and 'Y' labels will have problems with a11y, so we should be changed them back to 'Width', 'Height', 'X Offset', 'Y Offset'.

Without clear explanation how a complex dialog is intended to work, the user will never know if a surprising or not understood behavior of the dialog is a bug or an erroneous use of it. That is a bad user experience and more work for the QA team.

For the bitmap tab for example: Percents in a editable text-field which change magically when something else is modified by the user is a bad user experience when it is not clearly stated that these parameters are dependent and by which rule they are dependent.

Best regards. JBF

(In reply to Jean-Baptiste Faure from comment #8)
> Without clear explanation how a complex dialog is intended to work, the user
> will never know if a surprising or not understood behavior of the dialog is
> a bug or an erroneous use of it. That is a bad user experience and more work
> for the QA team.
> 
> For the bitmap tab for example: Percents in a editable text-field which
> change magically when something else is modified by the user is a bad user
> experience when it is not clearly stated that these parameters are dependent
> and by which rule they are dependent.
> 
> Best regards. JBF

We talked about the question whether or not to have _simple_ tooltips in general [1,2,3]. Extended tooltips are available when the offline help is installed per configuration or via Shift+F1. Despite some technical challenges this works well and provides a good explanation for the whole dialog. 

The challenge with simple tooltips is in what level of detail we would implement those tips. Every control, and explain the percent, or major and not fully self-explanatory controls only [4]. Furthermore it would be necessary to have multi-line tips.

While the decision is not made finally we likely keep the current approach and provide tooltips optionally for controls that need explanation.

For this particular ticket it means either WONTFIX or to have a one-liner tooltip for the dropdowns that might be not too helpful, though.

[1] http://nabble.documentfoundation.org/Minutes-of-the-Design-Hangout-2016-Dec-22-tt4203377.html
[2] http://nabble.documentfoundation.org/minutes-of-ESC-call-tt4203402.html
[3] http://nabble.documentfoundation.org/libreoffice-l10n-Feedback-on-tooltips-tt4202816.html
[4] https://docs.google.com/document/d/18u_DcmjyIPS1HzxhLEMu_1teFL-1uGGs_Xjfpg1l4d4/edit

(In reply to Jean-Baptiste Faure from comment #8)
> Without clear explanation how a complex dialog is intended to work, the user
> will never know if a surprising or not understood behavior of the dialog is
> a bug or an erroneous use of it. That is a bad user experience and more work
> for the QA team.

The old design definitely was complex, which even i struggled with when i first used it, which is why it was redesigned to be alot more user friendly. If users disagree with these changes, we are to hear them out and make changes accordingly, but i doubt QA will get any more work about this than they would have from the old design.

> For the bitmap tab for example: Percents in a editable text-field which
> change magically when something else is modified by the user is a bad user
> experience when it is not clearly stated that these parameters are dependent
> and by which rule they are dependent.

Users already understand that if they modify a field and it changes another field, then these fields are related, like when they change the line spacing preset field in the paragraph dialog or when they change the column width in the table format dialog. Most users will select one of the available bitmap size presets, which are similar presets they would have seen when they changed their desktop wallpaper, and possibly change its alignment/position and thats it, and you cant get any more simpler than that for this feature. Users who want more control are given the ability to do so, and even they should find it simple to use. And lets not forget that we have a preview to give the user clear feedback on how any of their changes will change the outcome.