Fwd: [libreoffice-design] Feedback on Border Feature in LibreOffice Writer/Calc

Forwarding this message, going to reply later.

-------- Forwarded Message --------
Subject: Re: [libreoffice-design] Feedback on Border Feature in LibreOffice 
Writer/Calc
Date: Sat, 2 Aug 2025 17:02:58 +0100
From: Noh Jose <noh.spam.jose@gmail.com>
To: Heiko Tietze <heiko.tietze@documentfoundation.org>

On 31/07/2025 16:04, Heiko Tietze wrote:
> Hi Zain,
>
> The "border feature" is complex (line type, width, color for all 
> positions, shadow options, padding) but you rarely need all the 
> options. The original idea might have been therefore to provide some 
> (hard-coded) presents (including no border), and allow to modify 
> everything in the same dialog. The UI is not really hard to 
> understand, just a bit clumsy.
>
> This topic is frequently discussed of course. We track issues on 
> Bugzilla, and I still like my proposal on this ticket:
>
> Improve configuration of table borders
> https://bugs.documentfoundation.org/show_bug.cgi?id=143249
>
> here is something older
>
> Reorganizing “Border” tab on “Format Cells” window in Calc
> https://bugs.documentfoundation.org/show_bug.cgi?id=100548
>
> And there are many more ideas (not that discussing these topics on the 
> mailing list is bad).
>
> Cheers,
> Heiko
>
>
> On 14.07.25 3:32 PM, Zain Tahir wrote:
> > *Dear LibreOffice Design Team,*
> >
> > I’m Zain Tahir, a LibreOffice user and developer currently working on 
> > Ubuntu. I’d like to give some constructive feedback regarding the 
> > *Borders* feature in LibreOffice Writer and Calc.
> >
> > Right now, the border interface feels outdated and unintuitive:
> >
> >   *
> >
> >     The *presets and previews don’t accurately reflect the applied 
> > output.*
> >
> >   *
> >
> >     The *UI is cluttered*, and the settings don’t offer real-time 
> > feedback.
> >
> >   *
> >
> >     *Basic border operations (like applying different styles to
> >     different sides)* require more steps than they should.
> >
> >   *
> >
> >     In general, the *workflow feels disconnected from modern UI 
> > standards.*
> >
> > I genuinely appreciate the work the team puts in — and I’m only 
> > sharing this because I see potential for massive improvement. A 
> > streamlined, modernized border editor (with live preview and more 
> > intuitive layout) would greatly boost productivity and usability.
> >
> > Thanks for your time and your continued efforts in making LibreOffice 
> > better.
> >
> > Best regards,
> > *Zain Tahir*
> > zaintahirbajwa@gmail.com
Heiko,

I'm posting the following on this thread because it's not clear to me where a 
better place would be. If you have a suggestion, please let me know and I'll 
happily repost accordingly.

I've recently been reading and commenting on the thread about table borders and 
following several of the many, many links to related and other issues where 
there are lots of comments about how styles and direct formatting should or 
shouldn't interact and speculation or assertions about what should or shouldn't 
override what.

Is there a place where design and UI behaviour axioms are discussed and 
specified as a basis for design consistency and use across the whole of Libre 
Office?

In terms of formatting, there cannot be a definitive hierarchy of which, between 
a style, and direct format, overrides the other!There are legitimate cases where 
a user has applied a style and then wants to tweak it, vs a user has hand 
crafted attributes directly but only afterwards applies a style. In both cases, 
the style will be a superset of the directly set attributes and which one wins 
cannot be programmatically determined, nor just asserted as 'the rule'!

It seems to me that some UI flexibility is needed here, where there is an easy 
default that the user can override, should they require more control. The usage 
patterns could look like:

*Definition of a style: * A style is a named set of related attributes that have 
default values but where each of the attributes can be changed to a preferred 
valid value. The set can be saved with a style name and can only be applied to 
compatible objects, as a set. The applied style inherits from the base style, so 
within the scope of the document (or section??) changes to the base style will 
be reflected accordingly. The valid set can be saved, with different names as 
different styles; all equally but exclusively applicable to a compatible object.

*One could argue that a style includes the /universal set/ of attributes, that 
can be validly set on an object and that applying the style includes custom AND 
default values.

*Definition of direct formatting:* Direct formatting is /any valid attribute/ 
from the /universal set /for an object that has had its value set by the user.

*If a style contains the universal set of attributes, any direct formatting will 
always clash with a valid style for that object!

*Usage patterns:*

1. I have an object /with an applied style/. I /directly change one of
   the attributes/ that, /by definition*/ is already specified by that
   style on that object.
    1. I could expect the direct setting to override the matching value
       in the style
    2. I could expect the direct setting to be ignored because a style
       (all settings) has been already applied
    3. I could expect the direct setting to be ignored because it
       clashes with an explicitly set (ie non default) value
    4. I could expect a request for clarification (which of 1.1, 1.2 or
       1.3 do you want)
    5. I have made an error and want to revert to the style settings -
       do 2!
2. I have an object where I have /directly changed one or more of the
   attributes/ and I /apply a style /to that object, where the style
   /by definition*/ will include the same or different values for the
   directly applied attribute(s).
    1. I could expect the style to override ALL the direct set values
    2. I could expect the style to override ALL EXCEPT the direct set
       attributes
    3. I could expect the style attributes to be listed, showing where
       clashes occur, so I can choose which should be left and which
       should be overridden
    4. I could expect a simple entry point where I can just choose
       between 2.1, 2.2 & 2.3, (with a default selection that I can set
       in the UI preferences)

Many lossless RAW photo editing applications include an action analogous to 2.3 
- they often do it on the copy action. One can copy modifications from one photo 
to another but not all may be needed. A dialogue appears with checkboxes for all 
applied actions pre-checked. User changes the selection to the ones they want to 
paste and then pastes those on the target RAW file(s).

I would also say that for ease of use, there should be a close, but not 
exclusive relationship between a style and the attribute value settings 
dialogue, so the attributes CAN be applied as direct settings OR as a 
style (probably should be the same dialogue but two different contexts).

Styles should NOT BE MODAL, because many attribute changes represent subjective 
judgements and punctuating that experimentation with an 'Apply' button and 
another request to open the same dialogue repeatedly makes for a disruptive 
staccato experience. (the 'Cancel' button or 'Undo' will be essential). Making 
the dialogue dockable near the style picker could also help, and reduce UI clutter.

Any enterprise will also need different style-sets (across any object types) to 
be associated for specific purposes: say a conference or a go-to-market branding 
strategy and allowing thoughtful bundling and naming of styles would allow them 
to ensure these sets are distinct, shareable, unpolluted - they should, if 
needed to be, source controlled in GitHub or suchlike.

All cases (like table line formatting and 'table styles') should be revisited, 
so they are consistent with a styles vision/design-specification across the 
whole suite. Designs should represent best UI practice and not merely derive 
inspiration from other brands of office suite. We are not, and should not aspire 
to be Microsoft, as with holistic vision, research and insight, we can be better!


Regards


Greg Lubel




--
To unsubscribe e-mail to: design+unsubscribe@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/design/
Privacy Policy: https://www.documentfoundation.org/privacy