Contextual Action Area
OpenPublic

Mock History

Current Revision1

Mock Description

Mocks that show how the status bar can be combined with a contextual action area.

clel added a subscriber: clel.Dec 23 2020, 1:04 PM
meven added a subscriber: meven.Jan 15 2021, 8:17 AM

Not a fan of this, my opinion would be to use a panel instead, what older versions of dolphin did.
This is reported as bug https://bugs.kde.org/show_bug.cgi?id=411500

This panel would be great below the information panel.

use a panel instead

I assume you would want this panel to be off by default?

Who is going to benefit from such a panel? Users who do not know how/when/why to right-click but who are still curious enough to discover such a panel even though they have no reason to believe it exists?

I think the target user group of the contextual action area are computer-illiterate ppl and touch users. We need to make sure the area is enabled by default or it won't help them. I don't think we can make any additional panels visible by default. This is maybe the most important constraint I had in mind while making these pictures.

meven added a comment.Jan 18 2021, 9:38 AM

I assume you would want this panel to be off by default?

Why would you assume that ?
I don't want that.

I think the target user group of the contextual action area are computer-illiterate ppl and touch users. We need to make sure the area is enabled by default or it won't help them.

Agreed, that's why I think such a panel should be visible by default.

I don't think we can make any additional panels visible by default. This is maybe the most important constraint I had in mind while making these pictures.

That's the bottom of the question.
I think we could integrate this feature to the information panel , in a new section in it, to be able to make well informed layout decisions, like d3phin did.
And allow users to show/hide previews/metadata/actions.
(old) Discussion suggesting doing this https://forum.kde.org/viewtopic.php?f=91&t=85171

Your proposal change the status bar paradigm with something that is unfamiliar to most users.
It changes the size of the view indirectly.
We should allow users to hide it for sure (I would).

Selection control in it seem overkill to me.

I assume you would want this panel to be off by default?

Why would you assume that ?

Because you said "below the information panel" which is currently also hidden by default. My assumption was wrong then.

I don't think we can make any additional panels visible by default. This is maybe the most important constraint I had in mind while making these pictures.

That's the bottom of the question.
I think we could integrate this feature to the information panel , in a new section in it, to be able to make well informed layout decisions, like d3phin did.
And allow users to show/hide previews/metadata/actions.

That could work. This way we would neither anger the more expert users by showing them a panel full of actions they can already access by keyboard shortcuts nor new users who wonder what they should do with all this extra information. Adding new panels highlights for me how T11579 should make it more easy for users to hide panel areas they don't currently want.

With this context I am not against having information panel and contextual action area as panel(s) on the right by default. Though we need to make a bunch of design decisions for that. Problems I see are:

  • the information panel is already quite full for the default Dolphin size. We would have to decide which information to hide by default. Putting (many) contextual actions below will be a trade-off between the default usefulness of the information panel for expert users and the default usefulness of the contextual action area for beginners. Your idea to "allow users to show/hide preview/metadata/actions" might work but I can't really picture where these buttons/UI components would go. Maybe the show/hide buttons themselves would be actions in the contextual action area? Not sure.
  • the contextual action area acts on the currently visited folder ("empty trash", "add network folder", maybe "create new", "sort by") but the information panel does not show the currently visible folder after hovering anything once. This might be confusing.
  • related to the previous: when the currently visited folder is displayed in the information panel, the status bar text and the amount of items listed in the information panel are closely related but we probably only want one of the two to list the amount of folders, files and total size.

Your proposal changes the status bar paradigm with something that is unfamiliar to most users.

It moves the status bar slightly up. I don't think this will be all that confusing.

It changes the size of the view indirectly.

But only slightly!

We should allow users to hide it for sure (I would).

Agreed.

Selection control in it seem overkill to me.

That part is optional and I mostly added it to stay on topic with the discussion I posted the mockups to. I don't have a strong opinion yet how selection control should best be handled in a single-click environment.

clel added a comment.Jan 18 2021, 4:09 PM

For reference, this is the task about improving single click which also contains the ideas for selection control: https://phabricator.kde.org/T9895

I also like the side bar approach for some quick actions, however I guess we all agree that side bar is really useful for selection related stuff but more for quick actions.

So I have the feeling that those two approaches can be both helpful in their own ways. One for quick actions (side bar) and one for selection control.

Also referencing my mockup for selection control: https://phabricator.kde.org/M179

Inline Comments

This is the most prominent mockup I was referring to when saying that those buttons are in close proximity to the status bar info text (probably also caused by the smaller window size).