[libreoffice-design] Minutes from the UX/design meeting 2023-Jul-31

[paul hofseth]

sirs,

I occasionally look at your dialogues and at times misguidedly complain 
about program stability rather than lack of "bells and whistles" .

I do realize that your task is dealing with the user interface and not 
with the data mechanics, but do hope that you have communication lines 
that concern program usefulness-.

This time I am sorely tempted to comment on the disability of reading 
monopolistic texts in docX format even if it lies outside your remit.

When working with our new book i have discovered a msjor annoyance when 
my co-authors use microsoft or apple. Black text on black background is 
not enlightening in any sense of the word.

p.

Den 01-08-2024 16:33, skrev Csongor Halmai:
> Hi Heiko,
> 
> you wrote this:
> 
>    + necessary if the app DPI differs from the screen DPI (Csongor)
> 
> but I didn't say this.
> 
> I meant in my comment that this feature would be useful when you want 
> to see more information than the resolution of your screen (and your 
> eyes) allows. You could magnify the region of interest (ROI) while you 
> still can see the big picture as well.
> 
> I created a mimicking screenshot in GIMP how I think it should look: 
> https://i.ibb.co/WW0WsxC/magnifier-sample.png
> 
> Disclaimer: for the screenshot, I used the Spherize filter of GIMP, 
> which is geometrically not identical to a magnifier lens but shows well 
> enough what I would like to see.
> 
> In order to not hide anything from the underlying screen, it is 
> essential that the center of the circle shows things larger than their 
> original size but at the same time, around the edge, things look 
> smaller. This way, the magnifier doesn't cover anything, just shows 
> some distortion around the edges.
> 
> A realistic lens effect can be seen here: 
> https://youtu.be/XtCW-axRJV8?t=271
> 
> I think this would be such a useful feature that it should be supported 
> at operating system level.
> 
> Csongor
> 
> 
> 
> 
> On 1/08/2024 04:56, Heiko Tietze wrote:
>> Present: Sahil, Eyal, Heiko
>> Comments: Mike, Justin, Stephane, Stuart, Cor
>> 
>> Tickets/Topics
>> 
>> (Suggested bump-up (Eyal):
>>   * Cell selecting fat border looks ugly especially if you selected 
>> some
>>     cell range, it also can block content in other cells
>> https://bugs.documentfoundation.org/show_bug.cgi?id=161709
>>     + Rafael: Made commits to improve the cosmetic situation, consider
>>       the bug fixed.
>>     + Rafael: This was done to resolve 143733, which requested the
>>       rectangle not cover the active cell
>>     + Heiko: Suggest accepting the current situation for now
>>     + Eyal: Serious degradation of UX - text in surrounding cells
>>       partially hidden, can make one value appear as another due
>>       to hiding.
>>     + Eyal: Suggest back-out of changes to before 143733, for now, and
>>       reconsideration. Must fix this for 24.8 release.
>>     + Eyal, Mihai, Rafael, Roman, flm2: Excel active cell rectangle 
>> looks
>>       nice
>> => please discuss at Bugzilla or the mailinglists (Heiko)
>> )
>> 
>>   * No option to automatically indent multiline list entries to align
>>     with numbering followed by space
>>     + https://bugs.documentfoundation.org/show_bug.cgi?id=156071
>>     + line up *subsequent lines* of each list entry, see c12
>>     + no good example for the necessity (Mike, Cor, Heiko)
>>     + mandatory to have this as cross-platform feature (Justin, Cor)
>>     + A tab is, in the general sense, an inherently flawed solution,
>>       because once your number exceeds the tab width - you'll overflow
>>       and the alignment will be messed up (Eyal)
>>     + Request is reasonable (Eyal):
>>       + Follows a different aesthetic principle: Fixed amount of space
>>         between number and paragraph content v-start rather than 
>> uniform
>>         content v-start across all paragraphs
>>       + Should be implemented via a paragraph feature to move all 
>> lines
>>         further in to respect the maximum constraints on each 
>> individual
>>         line (e.g. numbering, wrapping around frames etc.), ensuring
>>         that the paragraph's v-start is uniform across all lines, 
>> without
>>         having to set it explicitly using indentation and/or tabs.
>>       + Should be usable even without numbering being active (an 
>> aspect
>>         of a paragraph's style)
>>     + requires probably also to start a list from any number (Heiko)
>>     + MSO does exactly the same as we do (Heiko)
>>     => comment
>> 
>>   * Tab stop of list contents increases then decreases in default
>>     Roman numeral list, looking messy
>>     + https://bugs.documentfoundation.org/show_bug.cgi?id=162133
>>     + Microsoft Office forces right alignment for Roman numerals, 
>> often
>>       with horrible results (Justin)
>>     + right-alignment is not the right solution => WF (Stephane, Cor)
>>   => solution follows bug 156071
>> 
>>  * PIVOTTABLE: Formating Pivot Tables
>>    + https://bugs.documentfoundation.org/show_bug.cgi?id=51732
>>    + double-click brings up the Data Field dialog currently, add
>>      a context menu (Stephane. Cor)
>>    + perhaps more obvious via push button? (Sahil)
>>    => provide a context menu for the functions
>> 
>>  * Magnifier Tool for a quick overview and spot zoom into a document
>>    in Multiple-page view
>>    + https://bugs.documentfoundation.org/show_bug.cgi?id=162101
>>    + magnifier is always just a click away, eg. Win + +/- on KDE
>>    + bug it does not render again with a higher resolution (Heiko)
>>    + "magnifier" would be an excellent feature *in general* (Stuart, 
>> Cor)
>>    + necessary if the app DPI differs from the screen DPI (Csongor)
>>    + duplicates / relates to bug 101646 "UI option "Scaling" was 
>> removed"
>>      with a lot duplicates itself
>>    + weird relation to multi-page view; suggest to do with low
>>      priority (Eyal)
>>    => comment
>>