Bug 452273

> For example, now it is not possible to deselect everything by clicking anywhere in the empty space.
> I think the only option now it to use the keyboard. I can imagine some users that work mostly with 
> the mouse annoyed by this change.
In fact we tried our best to specifically handle this case, and there is some whitespace to the left of the icons that you can click on. It's not as large as the whole white area of the view, but it is still there. This area can be used for dragging files too. However for the drag use case, it is quite small indeed, and I can see how it's now difficult to drag something into the currently-viewed folder, rather than one of its child folders.

I wonder if we should allow drags into the empty area of the folder as we used to, to try to improve that use case It seems like a legitimate usability regression.

(In reply to Nate Graham from comment #1)
> > For example, now it is not possible to deselect everything by clicking anywhere in the empty space.
> > I think the only option now it to use the keyboard. I can imagine some users that work mostly with 
> > the mouse annoyed by this change.
> In fact we tried our best to specifically handle this case, and there is
> some whitespace to the left of the icons that you can click on. It's not as
> large as the whole white area of the view, but it is still there. This area
> can be used for dragging files too. However for the drag use case, it is
> quite small indeed, and I can see how it's now difficult to drag something
> into the currently-viewed folder, rather than one of its child folders.

Oh, that's right! I only realize that now. So I guess we can agree it's not very intuitive. Although now after you told me this I'm annoyed by the "empty" space on the left and I don't know how I didn't see it before hahaha

> I wonder if we should allow drags into the empty area of the folder as we
> used to, to try to improve that use case It seems like a legitimate
> usability regression.

Is the discussion open in gitlab? If so, can you share me the link. Maybe I can put there a few screenshot/videos with the issues I identified after this change.

Thanks,
Iyán

We can discuss it here.

Okay, so after a few days trying the new Dolphin, I'm still not used to this change. It's even hard to navigate in the "one click opens folders" mode. I also find the leading column padding confusing and ineffective. I can think of two possible solutions:

1. Add one option to choose the behavior, so users can go back to previous behavior. Maybe it would make sense to only use this new mode in "tablet mode" and leave it as it is in "normal" mode.

2. Allow to configure the position of the "column padding". For me (and most users), I think it would be more intuitive and easy to use to have that  column between the name column and any additional ones (size, type, modifed, etc.). In this way, you benefit more homogeneous areas to select folders (no matter the name length), but you still have plenty of area to unselect with click, drag and drop, etc.

What do you think?

Created attachment 148030 [details]
alternative padding column

(Annotate tool of Spectacle is just awesome!)

Okay, so here is what I mean with solution 2. Hope it's clear.

Created attachment 148035 [details]
screenshot with expandable folders option enabled

By the way, the padding column is broken when the view is configured so that folders are expandable.

>Oh, that's right! I only realize that now. So I guess we can agree it's not very intuitive.
>Although now after you told me this I'm annoyed by the "empty" space on the left
>and I don't know how I didn't see it before hahaha

In the 22.03.80 Beta version you tested, the padding was way narrower and not resizable. You might have had a better time if you hadn't been affected by a regressions causing this. The regression has been fixed (through a revert) for 22.03.90.

>By the way, the padding column is broken when the view is configured so that folders are expandable.

I believe this is fixed in the Release Candidate 22.03.90 already by the same revert mentioned above.

>1. Add one option to choose the behavior, so users can go back to previous behavior.
>Maybe it would make sense to only use this new mode in "tablet mode" and leave it as it is in "normal" mode.

We have mapped out the required differences in usage of the new behaviour compared to the old and came to the conclusion that the biggest downside of the new behaviour is that users will have to come to terms with the changed click behaviour. This is a disruption that I understand some users will be upset about but there are still ways to do everything with similar efficiency as before. That's why having an option for this which then has to be maintained indefinitely was rejected.

>2. Allow to configure the position of the "column padding".
>For me (and most users), I think it would be more intuitive and easy to use to have
>that  column between the name column and any additional ones (size, type, modifed, etc.).
>In this way, you benefit more homogeneous areas to select folders (no matter the name length),
>but you still have plenty of area to unselect with click, drag and drop, etc.

This seems quite unintuitive to me since one would now have an area that can't be used to click a file/folder in between areas that can be used to click them. Having the area to deselect at the side leads to a clear separation of spaces and responsibilities. I might have misunderstood you if you were meaning to say that the selection area should span the whole name column.

In any case I created a merge request to resolve this bug report that also adds padding to the right end of the view. This has a number of benefits:
- The right margin is more discoverable since the item highlight ends right before the padding column
- Less mouse travel time to reach either of the areas
- More than double the likelihood of users figuring out the advantages of these padding areas for deselecting or dropping
- More visual symmetry

Link to MR: https://invent.kde.org/system/dolphin/-/merge_requests/374

Thanks for the detailed explanation Felix. I will go ahead and comment directly on the MR.

Git commit 3bf471e02a440bd008d69c5939b7c5bf2c03df54 by Felix Ernst.
Committed on 08/04/2022 at 09:44.
Pushed by felixernst into branch 'release/22.04'.

Add symmetric padding on right side of details view

There have been some reports that users were unable to figure out
that the padding on the left of the left-most "name" column can be
used for deselecting or for dropping file items. All of these
reports were by people using a Dolphin version in which that
padding was way too narrow because of a regression (that has since
been fixed). Nonetheless this highlights the potential problem that
some users might be unable to notice/figure out the usefulness of
the left padding.

This commit adds a similar area on the right side of the view when
the column widths are set automatically by Dolphin. The width of
the right padding column mirrors the width of the left padding
column when sized automatically. Both can manually be hidden or
resized similarly to resizing other columns.

There are various usability advantages to having this padding by
default on both sides of the view and not only on the left:
- The right margin is more discoverable since the item highlight
    ends right before the padding column
- Less mouse travel time to reach either of the areas
- More than double the likelihood of users figuring out the
    advantages of these padding areas for deselecting or dropping
- More visual symmetry

I had suggested also having this kind of right padding even before
the initial implementation of the left padding. The contributor
implementing it was in favour of it. It only wasn't implemented
because the contributor said it was impossible without a lot of
work. Turns out adding two characters at the right position seems
to suffice in most ways.

This commit does not contain the string change of renaming "Leading
Column Padding" to "Column Padding" (since it changes two paddings
now) to not infringe on the string freeze.

M  +3    -1    src/kitemviews/kitemlistview.cpp

https://invent.kde.org/system/dolphin/commit/3bf471e02a440bd008d69c5939b7c5bf2c03df54

Feel free to re-open this bug report or create a new more targeted one if you still see issues with the more up to date version.

I confirm that I got used to this change after the last fix. I still think that the padding on the edges looks a bit weird and I look forward for future changes, but overall I think it's a nice improvement, specially for touch screens.

>I confirm that I got used to this change after the last fix.

Thanks for confirming

>I still think that the padding on the edges looks a bit weird and I look forward for future changes

I'll keep that feedback in mind.

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