Bug 103035 - UI: Changing text formatting in Header/Footer dialog can be confusing
Summary: UI: Changing text formatting in Header/Footer dialog can be confusing
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: difficultyInteresting, easyHack, skillCpp, topicUI
Depends on:
Blocks: Page-Dialog Dialog-UX
  Show dependency treegraph
 
Reported: 2016-10-06 12:07 UTC by Michael Meeks
Modified: 2018-12-04 21:37 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
dialog mockup (31.55 KB, image/png)
2016-10-07 07:17 UTC, Yousuf Philips (jay) (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Meeks 2016-10-06 12:07:34 UTC
Description:
Format->Page->Header->Edit

I press the "Custom header" button marked 'T' - for text attributes; I select a larger font size, and say an orange text colour, and super-script.

Interestingly, these are not saved by the dialog as I close it; so re-opening the flow and re-visiting the data shows that this is not persisted by the dialog.

Actual Results:  
 

Expected Results:
 


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Comment 1 Michael Meeks 2016-10-06 12:12:23 UTC
Hmm - so in fact this is an idiot bug report =)

You need to have some text selected for the format to apply to it; so the behavior of 'T' is a little non-intuitive.

It would be nice - if no text is selected, to pre-select the text in whichever pane the cursor contains - I know that was my intention at least =)

Thoughts from UX ? if they like that, I'll turn it into an easy-hack with some code-pointers; thanks !
Comment 2 Cor Nouws 2016-10-06 13:09:57 UTC
(In reply to Michael Meeks from comment #1)
> Hmm - so in fact this is an idiot bug report =)

Well, let me be friendly and disagree on that; users - however dump it may seem - are always right (TM)
/me hope people will not quote me for this :p

> Thoughts from UX ? if they like that, I'll turn it into an easy-hack with
> some code-pointers; thanks !

OK > change summary a bit.

thanks in advance for code pointers!
Comment 3 Cor Nouws 2016-10-06 13:11:09 UTC
(this needs to be added for ux-advize)
Comment 4 Yousuf Philips (jay) (retired) 2016-10-07 07:00:50 UTC
Well it does do something without selection, it changes the font style at that point, so you can type with the newly selected font features. It acts the same ways as it would in writer with direct formatting, as you can have multiple direct formatting applied to the text in the pane. It would be no different than having bold, italics, underline, etc buttons in the dialog that a user could press to apply the feature.

So maybe having a simple toolbar of direct formatting attributes (font name, font size, bold, italics, underline, font color) is the simplest way of making it easy for them to customize the font style and then changing the 'T' button into a 'More...' buttton.

We should also change the 'Header' label to 'Presets' and change 'Custom Header' label to 'Insert Field'.
Comment 5 Yousuf Philips (jay) (retired) 2016-10-07 07:17:49 UTC
Created attachment 127850 [details]
dialog mockup
Comment 6 Michael Meeks 2016-10-07 08:30:09 UTC
Sounds reasonable; but now this is quite a large change =) certainly for an easy-hack. As far as I can see, it is a trivial minority use-case to first change the font and colour, and then type - whereas - changing it, seeing there is no change; and closing and re-opening, and seeing that that change is not persisted (even for the same cursor position ;-) is well - I'm no idiot and fell immediately into that trap. Type then format should be the norm, I hope - and if not - when there is no content in the box, it can behave as before =) I would strongly suggest that we go with the tweak to pre-select the text if nothing is selected when that button is pressed.

Then again - I like your new mockup =) re-arranging it trivially in glade anyway to change the order would be great; and a legend of "Insert Field" rather than Field might be better for the 2nd row of buttons (?) [ we should drop the 'T' there - it is now the 'More' button right ? ;-].
Comment 7 Yousuf Philips (jay) (retired) 2016-10-07 15:54:41 UTC
(In reply to Michael Meeks from comment #6)
> Sounds reasonable; but now this is quite a large change =) certainly for an
> easy-hack.

Yes large changes are needed to most dialogs, so might as well fix them all in one go to improve UX. Would assume moving around widgets in glade should be easy to do, but having the formatting toolbar would be the hard part.

> As far as I can see, it is a trivial minority use-case to first
> change the font and colour, and then type - whereas - changing it, seeing
> there is no change; and closing and re-opening, and seeing that that change
> is not persisted (even for the same cursor position ;-) is well - I'm no
> idiot and fell immediately into that trap.

Yes i only changed the font and color at the beginning as your steps in the description didnt say to type something first and then click the 'T' button. :D But yes having text attributes hidden in a dialog would likely confuse many to assume it might be a style type dialog which affects all the text in the pane. Cant predict what my behaviour would have been if i didnt already know how it functions and whether i would have easily discovered how it does or would have had your same frustrations.

> Type then format should be the
> norm, I hope - and if not - when there is no content in the box, it can
> behave as before =) I would strongly suggest that we go with the tweak to
> pre-select the text if nothing is selected when that button is pressed.

Yes type then format would definitely be the most used behaviour, but dont tell that to style users :D. Well with no content in the box, it would still be selecting no characters and styling it :D.

> Then again - I like your new mockup =) re-arranging it trivially in glade
> anyway to change the order would be great; and a legend of "Insert Field"
> rather than Field might be better for the 2nd row of buttons (?)

Glad you like it :D. Initially i had it as 'Insert Field' and changed it just to 'Field' to save space, especially as we have to think about l10n, and also because we can add 'insert' to the button tooltips without worry.

> [ we should
> drop the 'T' there - it is now the 'More' button right ? ;-].

About the 'T' icon, i was using it for insert title, as the icon for insert title in worthless - its the icon for up one folder level. ;D
Comment 8 Heiko Tietze 2018-11-22 10:49:54 UTC
Nice mockup in c5 could be the basis for an easyhack.