Created attachment 173440 [details]
Screenshot Word

Sure, this would be a solution. And it has the advantage to be a bit more a11y-friendly. But better keep all aspects of a redesign together in one ticket.

(In reply to Heiko Tietze from comment #2)
> Sure, this would be a solution. And it has the advantage to be a bit more
> a11y-friendly. But better keep all aspects of a redesign together in one
> ticket.

No objection to a single ticket. The problem is more my hesitation to write it down in a way people don't get overwhelmed or confused. 

The logic of the dialog is already that confusing (for me), that the attempt to write it down (in a single report) becomes 'as confusing' as the incidents experienced .

And me lacking the right vocabulary to be very precise about what the problem is, how and when it occurs (and cases where it does function) doesn't help.

Pick one generic and make all other a duplicate of this one. Let me and the design people handle the rest.

*** Bug 143248 has been marked as a duplicate of this bug. ***

*** Bug 143250 has been marked as a duplicate of this bug. ***

*** Bug 143251 has been marked as a duplicate of this bug. ***

*** Bug 107675 has been marked as a duplicate of this bug. ***

*** Bug 106044 has been marked as a duplicate of this bug. ***

*** Bug 143252 has been marked as a duplicate of this bug. ***

*** Bug 139838 has been marked as a duplicate of this bug. ***

*** Bug 139837 has been marked as a duplicate of this bug. ***

(In reply to Telesto from comment #1)
> Created attachment 173440 [details]
> Screenshot Word
If that severs all scenario's currently covered by LibreOffice: looks good :)

The UI needs to allow for example:
Set left border to red, 4pt, dotted
and right border to green, 4pt, dotted
and top border to no border,
and bottom border to black, 3pt, double.

I do not see, how that will be possible with buttons.

This is kind of recycled global redesign/ improve bug table borders bug. 

So comment 1 is only a minor aspect (original report here).. Comment 14 one of the 'bigger' issues I personally perceive being present.

Heiko preferred single report. The bug report as such isn't quite useful to distill the issues (and the buttons of comment 1 don't fix everything). 

I leave it up to Heiko go give a summary of the possible issues with the workflow. And which ones can be addressed and which (comment 4) can't because of different workflows..

I think number of border formatting cases should be defined. (Workflows). 

Regarding modification of table borders, row borders, borders of selection of cells, single cell. And differ between changing existing borders, or starting from scratch. Modifying existing things is also quite a hassle.

Created attachment 173608 [details]
Mockup

Requirements are simple:

   + Benjamin wants to show a grid on the table.
   + Eve wants to configure the border style using potentially different 
     attributes per side.
   + Adrian wants to install LibreOffice for visually disabled people too.

Not yet implemented:

   + Eve wants to store a configuration and apply in other documents.

The mockup takes the known design principle with a list of presets at left, the attributes in the middle, and a preview right-hand.
The line style Position is a multi-selection toggle button, one selects all the border lines that should be modified. In contrast to the current configure and apply (on click at the preview) this workflow would apply the modifications immediately. Meaning if some positions are selected (toggle button active) and the vertical left line is added now, it will become blue. To keep the left line's color (and use it also at right) one has to uncheck both horizontal first. If none is selected the attributes are taken from the selection.

In the first iteration, the alternative approach was to apply line attributes only individually via dropdown. This idea was rejected as regression to the current solution with multiple selection.

Previously it was possible to click repeatedly on the preview and disable a border line. This is replaced in the mockup with a checkbox. The preview is not clickable.

For the padding a dropdown allows to set the distance for all sides (currently done via "synchronously") or individually for each side. Thus, the dropdown has 5 items.

The mockup is done with Penpot, publicly available at https://design.penpot.app/#/workspace/35358890-e54f-11eb-b623-4c4b7a420f0b/4f34a020-e552-11eb-b623-4c4b7a420f0b?page-id=4f34a021-e552-11eb-b623-4c4b7a420f0b

The current dialog has the presets "Set Outer Border only" (which removes the inner lines if any) and "Set Outer Border Without Changing inner Border". The mockup has only the preset "Frame".

The mockup has no way to change the inner lines only.

Currently you can set all four padding values at the same time and you can see the current values of all four paddings at the same time. The use of a drop down as in the mockup would be a regression.

The term in the shadow style is "Distance" not "Width".

(In reply to Heiko Tietze from comment #16)
The design is interesting; refreshing: positive surprised. 

However... My core concern is the workflow. The task oriented view  (you may add persona to it. So Benjamin has mental idea of a certain formatting, how can he do that).

Simply putting some cases forward:

Case A: 
Say you have a 1x2x table. You intend to make the left 'left and right' border red. And Top bottom border dashed. And increase the border width of the middle.

How many steps are required to do this? And is there an order in which you have to handle it?

Case B: 
You have pre-existing (border)formatted table. Say the formatted table you created above. You want to change the line style of the left/right border (without changing the color). Is it possible to do? How many clicks are needed?

Case C: 
You want to get quick overview of the border settings of the existing borders.. How do I do that? Difference in border thickness between 0,05pt 0,15pt are sometimes hard to differentiate on screen (not even starting about visually disabled people)

Case D
Take again the table of case A, now I want the change the line width of those borders at once.. without touching the other formatting (color/dash) of the outer border. And excluding the inner border. Is it possible to do so?

For the record: My ancient MS word struggles on these tasks too :-).

My initial impression (or misreading) is that the mockup has less capability's compared to the current, click at the preview thingy. The current concept is not that bad, my core issue with it is the implementation. There are annoying quirks and particularity's. Like the preview being to small, evilly sensitive. lacking outside buttons (to avoid inside clicking). 

And also lacking certain functionality.
*It's lacking an option to select multiple borders (manually and/or by present). So you can change formatting of multiple borders at once. So you can change the border width of all borders while retaining the dashed look of some borders it the selection.
* Being able to select a single border and see the current formatting in the edit fields.

It's quite possible I odd table design capability's :-). I'm running into issues with MS Word too. And modern versions discourages manual formatting (fiddling with formatting).. likely for a reason.

Different workflow should be fit into a design which is workable for all

Thinking about this a bit more.. one of my complains the current triple state of the border tool (where they sequence of clicking being inconsistent in my perception) A example: The first clicked (present) border will be 'selected' if I change some of the formatting.. and click a different border the change gets applied)

So, I'm inclined to get rid of triple state. However really objecting to be able to click into border picker tool as such.

As I don't desire create a mock-up from scratch if there is some design already having the element.. So i'm using attachment 173608 [details] as reference (but not following MS way either)

The idea:
* Borders can only be toggled on/off by de borders presented around the border picker (see screenshot). See last bullet point why this maybe isn't needed at all
* You can click in the border picker itself (as currently), but only for selecting borders (not for toggling the on off.. Those are the buttons on the outside.
* You might be able to drag drop borders to other border area (technical possible?). So say have pre-existing dashed border at the left, and want the same thing at the right. You drag the left border to the right, and this the same border gets applied there too (with may CTRL+Drag for not copying but moving the border there). 
* Border tool is capable to select multiple borders with CTRL+CLICK so you can select multiple borders at once (and manipulate). With keeping the unique aspects
* If you select a single border, you will see the current settings of that border (and able to modify)
* If multiple borders are selected with different formatting.. at button is present to reset clear 'DF' of the borders. Which means or disabled border/or default border setting (undecided)
* Assuming a selecting inside the 'border picker'. It's possible to de-select all borders.. So you can modify the 'border settings' and press toggle on a border (to apply the style only for the new border). If there is present border a toggle off/on effect replaces the current formatting (different workflow, same effect)
* There are pre-set present for selecting border area's
* An alternative way to activate borders (by not clicking on the toggle around), is to select disabled borders, and simply start formatting (changing line style for none to enabled; similar as by textbox or other drawing objects). [So it might not even be needed to have on/off toggle buttons around the preview]

(In reply to Regina Henschel from comment #18)
> The mockup has no way to change the inner lines only.

You have to pick the right item from Line Style > Position (the inner line options are missing as we don't have icons for it yet).

(In reply to Regina Henschel from comment #17)
> The mockup has only the preset "Frame".

These presets are not a selection but a full configuration with all attributes for all borders.

(In reply to Telesto from comment #19)
> My initial impression (or misreading) is that the mockup has less
> capability's compared to the current, click at the preview thingy.

Yes and no. Thing is that we mix selection and application. Right now you define the line style first and apply this to the positions. That can be one or many. And I guess this third state was introduced as kind of undo.

Even with my proposal that turns the workflow around into select first and apply per setting the attributes, we run into trouble with multi-selection. Consider one line is blue and the other red. What I wrote to explain the behavior is hard to understand for users. And now we have to balance the demand for applying an option to a variable set of positions vs. simplicity/clarity of interactions.

(In reply to Heiko Tietze from comment #21)
> 1. Thing is that we mix selection and application. 

Yes, horribly


> 2. Right now you define the line style first and apply this to the positions.
Well this is my view not totally true (mostly it is though). 

The case you're describing is a table with starting with border NONE, I think

Insert 1x1 table (Default table style). Go to border tab. Picker a border color.. This is instantly applied to all borders.. There is no distinction to defining position and application. Which is surely very efficient if you want to that, but you have to be really careful if you don't want that to happen

---
There is also the case where you can select first, and apply next. 
Insert 1x1 table (Default table style). Single click one of the existing borders (you're know in selected state). You can now edit the properties of the single border. So first 'select' next apply. However this only works for a single border.. If click on the next border (assuming a default table style), you don't start with 'selected state', but in reapply border with this setting mode. If you have a table with border none

---

Something totally different topic. Say you have a workflow defining borders, next formatting. Step A defining borders, you want to have by clicking inside the border picker tool (say left and right border), step 2 apply a formatting to all of them at once.

The left/right isn't possible if you do this way. You have to define the border formatting first an next click/left right.

However the same workflow does exist in other cases. If click on a template alignment style this exactly what's happening. (A) Defining borders first (B) applying border formatting. Which kind of top down workflow. (where in other instances it's more working from bottom (defining borders) to top (selecting where to be applied)


--
Something else I want to mention. No clue if this is handled in the current mock-up Simply to mention. 1x1 table (default table style). I want the right border red and the right green and the other borders disabled.

I can start with: (A) defining red border first. The confusing part here.. All borders become red (which you don't intend to do, really distracting). You can press the Present, set no borders (which fixes that). Or you pressed Present, set no borders first (with the result you can't see the formatting being applied, become borders are disabled) 

Next step you click the left border.. Fine. So you go the next step, right border green. So you start pick the green color the the color picker. And you notice.. green being applied to the left border (which want to be red). Argh.. wrong workflow. So you revert back to red. You click the left border (which becomes red, but you didn't want it be red at all, which is distracting, because have green in mind, and seeing red (literally an sometimes also figuratively). And you change it to green. 

Next you re-consider.. you want left border being blue. You change border color to blue (argh.. no I not the right). So revert back to green. You click the red border again.. Which becomes green (whereas where mentally mapping, select the 'red border' But well red border has become green. Next you pick blue (ah.. that's what I intended).

---
Another question.. Are there also interactive mockups. Is hard to distill the workflow from a dialog still. I'm not having much problems with the current visual design. I'm having operational issues. So issue with interacting with the element in the dialog, to get the result I desire without much frustration.

Current setup is build around applying the same to multiple borders. Because those borders are active, or set by line arrangement button. And you can easily change a single border formatting.

Making inner cross blue and other borders red is more of an exercise. You can partly rely on table line arrangement button (to select all outer borders for example). To prevent to click every border one by one. Next you have to click a inner border (you can't activate both borders first, no you have to do first select the horizontal (or vertical) border, next set color from red to blue and next click the vertical border (or horizontal). Cases where I mostly activate both borders, realize that blue only applied to a single border, and having to click on the inner border again. Where I obviously click little to much in the corner, and applying the inner blue again to the outer red border. And there is no CTRL+Z so you have to again select the (say left) other border and set it back to red.

But well if you used some specific color red (without much alertness, because needed 'some' red and that one looked fine), and you have to reapplied, you might pick the WRONG red (next want to see what picked on the other border).. But well that's not possible, so you start reformatting again. You can't use line arrangement button to select all outer borders again, because the inner borders will be disabled by that action. (argh)

Sometimes I desire the UX persona Telesto being added to the list UX persona's :-).

Out of curiosity.. are there also tools to handle the interactional aspect of mockup. The static - layout mockup - is kind of lacking the way people will interact with the dialog. Or the way UX seeing the interaction process going. 

The design mock-up obviously giving hints, but well this also matter of experience.. Which is the reason for me 'mocking' (posting bugs)on the current design. Not having tremendous trouble with with the position of the element of options available. Not saying it could be done differently. 

However my major concern is get certain things done in efficient manner. Without really counter intuitive ways of getting things done. Or having the follow pretty narrow sequence.. and if you make a mistake, you have to start at A again (undo a single step)

(In reply to Telesto from comment #23)
> Out of curiosity.. are there also tools to handle the interactional aspect
> of mockup.

There are tools that allow to expand a dropdown on click, eg. Axure. But this can also be done with two static pages via Penpot. Haven't done it for this dialog and it's never fully functional, for example responding to the color picker, setting the preview correctly, providing the presets functionality etc. requires code.

The question is rather if people can be convinced of changing the workflow and loosing the ability to apply attributes to many positions at once. Doubt this.

(In reply to Heiko Tietze from comment #24)
> The question is rather if people can be convinced of changing the workflow
> and loosing the ability to apply attributes to many positions at once. Doubt
> this

Loosing the ability to apply apply attributes to many positions at once is a no go for sure. Not 'doubtful' at all ;-)

The point is that don't see why how this should be a problem. at least in my 'model'. Which I attempted to described in comment 20/22. Except you possibly one click extra being needed. To press the select all borders template. Prior to application of border style. This could even be removed, however there might be some negative side-effects).

The interactive dialog isn't necessary per se. It can also be written description. Simply to clarify, and making sure the dialog isn't bound to much by a certain workflow. 

-
Enabling/disabling borders must be untangled from selection. And you might need border selection templates (selecting existing borders) and border enabling templates (next to manual selection/enabling/disabling)

With issue - overlap cases where 'border selecting template' includes borders which are disabled. Where my logic would go, what isn't there can't be selected. 

But well you can also say, the template is selected, and border modified, it should be applied to previously un-enabled border.

[And at this point the desire for undo comes to mind] Reset does reset all changes.. Mostly you want to go one step back.  However this bit of an problem with the overall design of dialogs. This type is undo rather specific (or maybe it isn't)?

When we discussed the mockup from comment 15 on the call, in the beginning, we indeed discussed some workflow change. But in the end, our discussion came to this mockup, which intended to *not* change workflows, but instead to make the actions more obvious and accessible.

Current (and proposed with the mockup) workflow focuses on one central idea: at any point in time, all *selected* borders have the same set of properties applied. This is not only difficult to change, but also is undesirable to change. This also implies one important property: *both* orders of operations: "select then configure" and "configure then select" result in the same set of properties applied to the selection.

The border settings definition is necessarily complex, because we try to fake "simple property  setter" for something that indeed is complex: multiple separate objects (up to 8 individual borders, with several elementary properties - color, width, style - for each). An alternative would be having too many individual simple controls - and that would be even worse.

The proposal has the following advantages:
1. Introduce individual buttons to *select* individual borders (previously, that was only possible by clicking on parts of the preview). This allows to have *accessibility*, as well as UX improvement by hinting people who don't guess where and how to click on the preview.
2. Moving presets to an own panel, potentially allowing to define own presets.

The problems with the mockup:
1. The "visible" should be kind of radio button (or a drop-down), with these options: none/visible/unchanged (to match current options). Visible means the controls below enabled; other two modes mean controls below disabled.

(In reply to Telesto from comment #25)
> Loosing the ability to apply apply attributes to many positions at once is a
> no go for sure. Not 'doubtful' at all ;-)

This will always end up in confusion. Example: left border is blue, right is red, and you select both - the color picker cannot show the current state (correct UI solution is to have some indetermined state like known from checkboxes, which is not perfectly clear to many users). 
The same for Mike's example with the 3rd state for Visible. If only one border is taken into the current attributes you know for sure what attributes it has. IMHO, we complicate the workflow with the (IMO) rare use case of multi-selection.

(In reply to Heiko Tietze from comment #27)
> IMHO, we complicate the workflow with the (IMO) rare use > case of multi-selection.

Two different statements in sentence :-). Multi-selection is complicated, totally true. 

Rare case of multi-selection. Not sure if there is no desire or simply not possible. Is surely sometimes desire to define the border width of all orders (with different formatting applied). Especially if you have some pre-formatted table (done by someone else or years ago) which does different border width for one reason or the other).

It should be possible to put everything which isn't the same in tri-state mode. (So border red, blue select means tri-state). This rather inherent to the type of selection (which is visible in the preview). So not finding this really unexpected result (but maybe biased me, tri-state is surely less common as feature)

Again, this topic inherently complex. Surely not all wisdom here (or experience with all the design principles) 

---- 

Another topic which comes to mind: resetting all borders back to default.
The current line arrangement present also mixes two properties
1. Choosing line arrangement
2. Resetting existing border styles

There are cases where you want to reset all borders to default (Default template style). However you have to press Line arrangement for that. But this can by accident also enable /disable borders too. Or visa versa. you select select outer border line arrangement which disabled the inner (formatted border) too.

(In reply to Telesto from comment #28)
> It should be possible to put everything which isn't the same in tri-state
> mode.

This makes it complicated even further. Having a selection with different applied properties gives no advantage, only another state that user needs to be aware of. Also it destroys a "define then apply by selection" workflow, because every selection act would simply create such a heterogenous selection set; and only "select then define" workflow would be possible, with resetting individual controls from "undefined" to some value; and when user decides to add one more border to the set, every setting needs re-definition again.

> Another topic which comes to mind: resetting all borders back to default.

The *potential* (only needed when we implement true table borders) "reset to default" is easily implemented by the fourth radio button/drop-down: "reset to default" in addition to "none/visible/unchanged" mentioned in comment 26.

*** Bug 100518 has been marked as a duplicate of this bug. ***

*** Bug 101459 has been marked as a duplicate of this bug. ***

*** Bug 139138 has been marked as a duplicate of this bug. ***

*** Bug 139139 has been marked as a duplicate of this bug. ***

Same topic with some duplicates and several comments in bug 87787.

Created attachment 180749 [details]
Mockup #2

Coming back to this topic.

I think we agree on the general layout. Regina mentioned that we have 12 border lines in total (depending on single/multi selection) and Telesto is unhappy with the workflow. In fact there are two scenarios: a) (most common) apply the same attributes for some borders such as the surrounding edges, and b) set individual attributes (for example red on top, blue on bottom).

This second mockup shows two alternatives. First we could present toggle buttons for all 12 options plus some combined defaults. This makes the UI quite busy. So I wonder if we allow to set attributes for a few common combinations (similar to what we have today as Presets) and have all individual settings accessible per dropdown.

To deal with the potentially large dialog I suggest to place Padding and Shadow (forgot to change the label Width to Distance) into expanders and use a scrollbox for the attributes.

The topic was on the agenda of the design meeting but didn't receive further input. So let's do it.

(In reply to Heiko Tietze from comment #35)
> [...] toggle buttons for all 12 options plus some combined defaults.

For me, it is better.

And, maybe, add a Reset button like in other dialogs.

(In reply to Heiko Tietze from comment #36)
> The topic was on the agenda of the design meeting but didn't receive further
> input. 

(In reply to Heiko Tietze from comment #36)
> The topic was on the agenda of the design meeting but didn't receive further
> input. 

I was not CCed to this bug, and unfortunately I often can't attend the design meetings. I only noticed it because of the agenda. Despite my being a latecomer - it seems implementation hasn't started, so I'll add some belated input.
 
Side/meta-issues
===================

1. Table borders and styles: The currently-implemented dialog does not seem to reflect the table's style, nor offer any functionality associated with the style; it is a "direct formatting only" dialog. I'm not sure that's a good thing.

2. RTL. At the moment, you can set "left" and "right" borders. If you then switch the table directions, these are switched. Is it clear enough to the user that this is what will happen? Also, noticed a bug when you switch the table direction, then go back to the borders tab - the borders aren't switched. Will file that separately.

Opinions regarding aspects of the current dialog & replies to other comments
============================================================================

3. Tri-state is good; we need it and we want it. If anything should be improved about it, it's making its semantics clearer to the user. Seeing a thick gray border is somewhat confusing. At the very least, a tooltip should indicate what the "keep" state means; perhaps also some kind of textual indication involving the line style controls.

4. It important that we be able to select an existing border and have its features displayed in the various controls (width, color etc.) This is bug 143248 and Telesto pointed this out in comment #20.

5. Continuing (4.), it should be easy to select multiple border elements without applying a new style to them (and without having to click-click-clackety-clack a zillion times), as Telesto has indicated in comment #25. But at the same time one should be able to do "format-painter-style" copying of border segment style from one segment/position to another. Telesto suggests (in comment #20) this be done using drag-and-drop; I'm not sure I would like that.

6. We cannot currently change the style of a border segment without simultaneously enabling it universally. That is, if I have internal horizontal borders every two lines, I can't say "I want these border to be purple, wherever they exist". I should be able to do that I think.

7. Continuing (5.) ans regarding Heiko's question in comment #24, I would not accept losing the ability of setting the style of multiple border-positions in the dialog at once. Regarding Heiko's comment #27: This is no more confusing then how the preview needs to reflect multiple cells with conflicting-style borders; or how the toolbar buttons need to reflect conflicting styles within a selection of text, etc. Multi-selection is _not_ a rare case, it is a very common case - just think of the presents.

Opinion regarding the latest mockup
====================================

8. I doubt that a full pane of presets is useful, but I don't have a strong argument against it.

9. Will additional presets be part of the document? The document template? The user configuration?

10. I'm not sure I like 10 small position buttons. The 4 side ones are obvious enough, the other ones less obvious and more confusing, especially the use of gray. I would like to be able to make the selection the way I make it now - but just as a selection, without applying any style. Have you considered _two_ preview-like widgets? One being an actual preview with styled borders, and the other being used for selecting positions only?

11. The second mockup alternative, in which one only works on a single position at a time. Is unacceptable AFAIC. And it doesn't even have a format-painter-like capabilty

12. Under the Presets pane, shouldn't the controls be "Apply" and "Add New"?

(In reply to Eyal Rozenberg from comment #38)
> 1. Table borders and styles: The currently-implemented dialog does not seem
> to reflect the table's style, nor offer any functionality associated with
> the style; it is a "direct formatting only" dialog. I'm not sure that's a
> good thing.

Note that there is *no* table styles in Writer at this moment. See also bug 117489 comment 12.

@Telesto: Here are some more potential "DUP" candidates for this ticket.

bug 58349 (with 12 DUPs)
bug 69305 
bug 87787 (with 5 DUPs)
bug 93975 
bug 103582 
bug 113606 (with 1 DUP)

Excuse me if my comment is duplicated and over simplified (it is so much text for only one seat).
I think that the border dialog must work like direct formating text.
1. You select which borders, pressing one or more of the preset buttons; the preview must reflect it someway.
2. You click one property at a time; the preview shows the change.
3. Repeat steps 1 and 2 as needed.
4. Reset, Apply, OK, Cancel buttons at the bottom.

*** Bug 135460 has been marked as a duplicate of this bug. ***

With 10 duplicates and six potential duplicates in comment 40 (including further duplicates), we should raise priority of that enhancement to high.

*** Bug 148164 has been marked as a duplicate of this bug. ***

*** Bug 159098 has been marked as a duplicate of this bug. ***