Kver wrote:Thinking about it carefully, the toolbox button doesn't properly follow the HIGs anyway; it looks more like a "chip" of panel than a button, which is potentially confusing to users. Also, arbitrarily gluing it to an edge is also a bit off, and it can't be resized either. There's a bunch of issues with it because it doesn't behave as expected: it doesn't look like a button, and it doesn't act anything like a plasmoid. Adding all these weird styles to differentiate it as "special" is breaking the guidelines were using in applications - maybe we need to treat it like it's nothing special.

Towards a solution, we have a UI guideline working its way into our apps where the design is usually a round clickable button. Methinks what we need to do is style the toolbox button like similar menus, and treat it like any other plasmoid by allowing users to move it away from edges/corners, with the option to be resized. It doesn't need to be removable (but I, personally, would like to have the option - even if the system sounds the klaxxon and requires 37 dialogs when you do).

If we allowed it to be configured, and alternate solution to allowing user to remove it might be allowing users to simply turn down its opacity to as low as 10-20%; still visible in case of "emergency" but not driving users insane with an omnipresent control either.

Proposed button designs;

I am loving the first version you placed here. I think the biggest issue right now with either proposal is the fact that it "could" interfere with a hot corner. Would it make sense design wise to place one of these in the middle left or right of the screen?

[quote="anditosan"
I am loving the first version you placed here. I think the biggest issue right now with either proposal is the fact that it "could" interfere with a hot corner. Would it make sense design wise to place one of these in the middle left or right of the screen?[/quote]

The radii of the hot corners are very small (one is supposed to really push the cursor into the corner to activate it), so if the button a bit away from the corner, it should not interfere.

The only problem I see here is that it doesn't show the name of the current Activity, which the current implementation does, if the Activity has a name:

colomar wrote:The radii of the hot corners are very small (one is supposed to really push the cursor into the corner to activate it), so if the button a bit away from the corner, it should not interfere.

The only problem I see here is that it doesn't show the name of the current Activity, which the current implementation does, if the Activity has a name:
*snip pretty picture*

We could keep the current behaviour for instances when the button is docked to an edge, and switch it to a simple button when removed from a screen edge or when it's placed into a corner. It would satisfy fans of the current implementation, too.

Kver wrote:

colomar wrote:The radii of the hot corners are very small (one is supposed to really push the cursor into the corner to activate it), so if the button a bit away from the corner, it should not interfere.

The only problem I see here is that it doesn't show the name of the current Activity, which the current implementation does, if the Activity has a name:
*snip pretty picture*

We could keep the current behaviour for instances when the button is docked to an edge, and switch it to a simple button when removed from a screen edge or when it's placed into a corner. It would satisfy fans of the current implementation, too.

I like that idea!

anditosan wrote:

daedaluz wrote:

anditosan wrote:I wanted to contribute to this discussion by giving the menu a different treatment. Once you hover over the corner, you would see this animation

https://www.youtube.com/watch?v=lMYRGsk ... e=youtu.be

Hover over and more pointless, distracting, useless animations? No thanks. I'd rather have the cashew occupy half the screen if it would just be still and quiet without throwing effect fireworks on my face if I move mouse near it. People already complain about GNOME activities hotcorner and message tray in addition to everyone hating on those Windows 8 charms that appear when least wanted. Let's not take that failed route.

Well... that is more like saying, "I don't like animations, I don't like Gnome." If you have something more consistent and proven, I think it would add to this conversation.

No. I'm saying that
a) animation like that serves no purpose other than distracting user. If it really needs to be animated, does it really need three separate flying things instead of just one? Konsole in 4.13 finally did away with that flying stack animation in color schemes, because it serves no purpose and is annoying.
b) animated actions happening seemingly out of nowhere (on mouse hover) annoy the hell out of users on every platform. Microsoft is yielding and doing away with charms on next Windows, because it's annoying. GNOME is rethinking message tray, because it's annoying.

colomar wrote:The only problem I see here is that it doesn't show the name of the current Activity, which the current implementation does, if the Activity has a name:

I like the first button style from

Kver wrote:

because the button icon follow the HIG. I also understand the problem when the activity has a name. why we can't use the button when the activity has no name and the style as now when the activity has a name. In addition I'd prefere that the standard activity has a name like activity than the user know that behind the name there are some additional informations.

with the undo function for plasmoids (viewtopic.php?f=285&t=123440&start=15) the "cashew" could be moved into a plasmoid and than you can remove the plasmoid if you like. and with the undo function the user get the necessary feedback that the cashew-plasmoid will be deleted.

So if you think this would work, please push it to plasma.

I finally found a foolproof way to permanently remove the cashew, use at your own risk but it works great for me and is reversible if need be.
http://askubuntu.com/a/480906/218383

The111 wrote:I finally found a foolproof way to permanently remove the cashew, use at your own risk but it works great for me and is reversible if need be.
http://askubuntu.com/a/480906/218383

The idea is to have a global solution which would work for the plasma developers, for the vdg and for the user. But thanks for the link I will check it.

Context menus should never be the only way to get to an important function (see also the HIG) because one cannot rely on users to find them.
The problem with the panel is that users might (accidentally) remove the panel, leaving them with no obvious function to bring it back.

What about if Plasma makes sure that there always is one panel left that the user cannot remove? If the average user still tries to remove the last one, there could be notification that says either a) that the last panel cannot be removed or b) that trying to close the last panel will reset it the default settings.

With this suggestion I assume that the presence of at least one panel is an integral part of the Plasma desktop targeted at the average user. By contrast, the expert user - who would know the trick how to remove the last panel - also knows how to right click on the desktop which would render a separate floating "cashew" menu obsolete without loss of functionality.

gregormi wrote:

Context menus should never be the only way to get to an important function (see also the HIG) because one cannot rely on users to find them.
The problem with the panel is that users might (accidentally) remove the panel, leaving them with no obvious function to bring it back.

What about if Plasma makes sure that there always is one panel left that the user cannot remove? If the average user still tries to remove the last one, there could be notification that says either a) that the last panel cannot be removed or b) that trying to close the last panel will reset it the default settings.

With this suggestion I assume that the presence of at least one panel is an integral part of the Plasma desktop targeted at the average user. By contrast, the expert user - who would know the trick how to remove the last panel - also knows how to right click on the desktop which would render a separate floating "cashew" menu obsolete without loss of functionality.

It seems to me the simplest solution and intelligent, because really the cashew no sense

Just a note - it is not about whether the activity has a name or not. It depends on the placement.

If it is in the corner, no text is shown, if it is not, the text is shown.

It would be nice if the proposed design included this alternative state as well - it would be bad to have two separate visual styles for this.

The entire argument for the permanent "cashew" seems to boil down to "well, what if average X removes it and the panel?". Having worked in enterprise support, my experience is that in general, your average person is not likely to even click the cashew if they can't find the panel. Even if they should, on my Plasma 5.2 the cashew shows 5 options: "highlight panel", "activities", "lock/unlock widgets", "desktop settings" and "log out". Neither of these to my knowledge allows for recovering a panel removed by accident. However, the context menu does. But only when widgets are unlocked.

When it comes to people mentioned earlier in the thread, such as the boss who wiped his Chromebook by mistake, there really is no point in optimizing for that scenario by hard-coding a fairly useless widget in the top-left corner. As others have suggested earlier it then makes more sense to hard-code in the panel since the panel offers more functionality.

But to entertain the idea of the Apple-style "let's protect the user from everything". The "System settings" application comes to mind as a counter-example. It comes by default, ouis by default pinned to the start menu and y can do some really rather nasty (for the inexperienced) stuff in there. However, look into the composite section for the display and there are some rather neat boxes at the bottom. "Expert" is particularly interesting.

A lot of applications use an Expert-mode to hint to users that there might be dragons afoot. What if, (crazy idea inbound, hold on to your hats), an option to remove the cashew is put in an expert menu somewhere logical? Perhaps in the area designed for desktop effects, or background services? For the most part people who are unsure what they are doing, essentially the people earlier referred to as those that have no clue about context menus, are _very_ unlikely to go look in system settings in the first place, and even less inclined to go muck about in a screen as scary as background services.

1) arguments to keep the "cashew":
Here is a blog post about why is it good to keep the plasma toolbox. It also includes the official way of how to remove it correctly: http://vizzzion.org/blog/2015/02/killin ... one-right/.

2) arguments to remove it:
To support the removal of the "cashew" in its current form (the plasma toolbox as a separate icon) take a look that this screenshot on https://userbase.kde.org/KWin. It shows "An _empty_ desktop in KDE 4.5" which - surprisingly - contains a panel. And the plasma toolbox in the upper-right corner. My suggestion is to just move the plasma toolbox from the upper-right corner to the right corner of the panel and merge it with the menu which is already present there. Result: one of two menus less which already look equal. Note that in this scenario the right-corner panel menu should be always visible and not be insivible when the widgets are locked.

gregormi wrote:1) arguments to keep the "cashew":
Here is a blog post about why is it good to keep the plasma toolbox. It also includes the official way of how to remove it correctly: http://vizzzion.org/blog/2015/02/killin ... one-right/.

It contains good arguments, anyone know of any usability studies regarding the cashew? If not, then maybe we should see to getting some?

To get in the head of a more casual user than myself, I did a scientifically worthless study with a single participant.
I picked a very casual non-techie, that occasionally needs a computer to do some actual work (my mom). I sent her https://userbase.kde.org/images.userbas ... top1fa.png per e-mail and asked her to answer some simple questions on the assumption that "this is a new machine you got, and it looked like this when you booted up". '>' marks her answers.

1. Looking at the top-right there is a button would you intuitively guess it to be a button?
   > No, for me buttons are at the bottom.
   
2. Knowing it is a button, what would be your expected behaviour from clicking it?
   > It would open a menu to continue.
   
3. What would you expect if you clicked on the desktop with the left and/or the right mouse button? Would you expect anything to happen?
   > I would get a list of settings.
   
4. Looking at the bottom-right there is a similar symbol to the top-right one, what would you expect it to do?
   > Shutdown/reboot the computer.
   
5. The current background is not so fun, how would you go about changing it?
   > Right-clicked the desktop and looked at what pictures were available.
   
6. Let's say you did something and the bottom panel disappeared, how would you go about getting it back?
   > Pointed at the bottom of the screen and hoped it would come back.
   
7. If the former scenario actually happened, what action would you take (realistically)?
   > Looked around, shut down the computer, went away and started up my iPad instead.

My mom is a very casual user, the same type I regularly met during my work, and knowing her I have some additional comments to her answers.

On the third question, she means continue as in "continue with a wizard to set-up the system" realizing it was actually a menu, she would ignore it and thus not remember anything in the menu. For question 7, "looked around" meant moving the mouse about the screen for a few seconds, similar to answer 6.