Drop down menus give no indication of their existence, also are too slow to load.

[wwdillingham]

Throughout sugar the "drop down" menus do not provide any hint of their existence. For example, When I turned on sugar for the first few times I shut the machine down by issuing reboot in the terminal. This is because when I would hoover over my little guy in the center of the home view I didn't realize that I needed to continue to hover to view the control panel / shut down / restart option. Perhaps if there was a downward facing arrow users of the system could realize there was a drop down menu coming.

Additionally the drop down menu delay seems to add confusion as opposed to simplicity.

[RafaelOrtiz]

this was a most needed bug, while implemented sugar and trying it with children one notes this is an usability problem for them (and also for grown-ups). +1 totally.

[garycmartin]

A few quick comments/thoughts:

1) Right clicking will immediately show a full palette

2) It's been mentioned (Eben) that icons with no primary action (single left click), should treat displaying their full palette as their primary action, so a single left click would reveal the full palette. There are a number of such buttons throughout Sugar and various activities that would need to pick up this behaviour.

3) Showing downward arrows on all icons with secondary palette options... Hmmmm. I'm on the fence about this one, there will be little arrows appearing all over the place. It would need to be consistently applied from a low level within Sugar, so all Activities also correctly inherit this behaviour (down arrow for all buttons with secondary palettes). If it's not consistent it will make matters worse not better.

3a) Down arrows are already being used to indicate 'lockable sub-toolbars' for the upcoming 0.86 release and the toolbar re-design work. I don't think we want to confuse that new toolbar feature with the old existing palette behaviours.

4) Compromise... How about some visual indication inside the primary palette, that a secondary (delayed) one exists?

[alsroot]

Replying to garycmartin:

A few quick comments/thoughts:

1) Right clicking will immediately show a full palette

2) It's been mentioned (Eben) that icons with no primary action (single left click), should treat displaying their full palette as their primary action, so a single left click would reveal the full palette. There are a number of such buttons throughout Sugar and various activities that would need to pick up this behaviour.

3) Showing downward arrows on all icons with secondary palette options... Hmmmm. I'm on the fence about this one, there will be little arrows appearing all over the place. It would need to be consistently applied from a low level within Sugar, so all Activities also correctly inherit this behaviour (down arrow for all buttons with secondary palettes). If it's not consistent it will make matters worse not better.

3a) Down arrows are already being used to indicate 'lockable sub-toolbars' for the upcoming 0.86 release and the toolbar re-design work. I don't think we want to confuse that new toolbar feature with the old existing palette behaviours.

4) Compromise... How about some visual indication inside the primary palette, that a secondary (delayed) one exists?

another option, like it was implemented in sugar.graphics.RadioMenuButton(and used for share button) - do not paint any arrows, since if user wants to activate button he clicks(left) on the button and gets palette shown, I mean user shouldn't do any special procedures to open palette(just regular left click) and we shouldn't mark these buttons with special hints

[garycmartin]

Replying to alsroot:

another option, like it was implemented in sugar.graphics.RadioMenuButton(and used for share button) - do not paint any arrows, since if user wants to activate button he clicks(left) on the button and gets palette shown, I mean user shouldn't do any special procedures to open palette(just regular left click) and we shouldn't mark these buttons with special hints

+1, yes that works well for me.

This was the option 2) I mentioned above, sorry if it wasn't clear (Eben had mentioned in a separate thread a few weeks back that this had been the intention, but it had never made it into the implementation).

[tomeu]

we have a few days for doing something about this for 0.86, but we need to have well defined actions.

[garycmartin]

Replying to tomeu:

we have a few days for doing something about this for 0.86, but we need to have well defined actions.

I think this policy will go some way to help and seems reasonably actionable: "Buttons with no primary (left click) action, should treat displaying their full palette as their primary action, so a left click would reveal their full palette instantly."

So, for example, the users XO icon should display it's full palette instantly when left clicked.

[tomeu]

Replying to garycmartin:

Replying to tomeu:

we have a few days for doing something about this for 0.86, but we need to have well defined actions.

I think this policy will go some way to help and seems reasonably actionable: "Buttons with no primary (left click) action, should treat displaying their full palette as their primary action, so a left click would reveal their full palette instantly."

So, for example, the users XO icon should display it's full palette instantly when left clicked.

Sounds good, though seems like a good amount of work, though not particularly difficult. Any volunteers?

[tomeu]

This has missed the 0.86 release :(

[gregorio]

On drop down menus (AKA palettes) we did see that in the GPA experience. Kids have a super short time frame before they move on. It came up especially when using mouse over in the Network Neighborhood.

I'm not sure which design best addresses this but I recommend that you pay careful attention to t he performance of mouse over and click on drop down menus.

See this comments "- Didn't wait for popup/hover text when moving cursor around network neighborhood so couldn't find anyone" in this report:
 http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06470.html

HTHs.

Thanks,

Greg S

[tomeu]

Replying to gregorio:

I'm not sure which design best addresses this but I recommend that you pay careful attention to t he performance of mouse over and click on drop down menus.

Just noting that this is not a performance problem, these are delays that are there on purpose. So we can change those at will but should try to make sure that any changes are better in general.

[garycmartin]

Slipped 0.88, moving to 0.90. FWIW I still think Eben's original design call that icons with no primary action (single left click), should treat displaying their full palette as their primary action, so a single left click would reveal their full palette – this way a user always gets immediate feedback from any click (either some real action, or a palette of secondary actions appears).

[FGrose]

In my estimation, reducing the hover-delay-time-before-palette-showing by 50 to 70 % would make the palettes more discoverable. Pop-up help and previews on the web seem to pop up pretty quickly these days.

This would be an easier mitigation to implement and would help on action buttons with palette menus as well.

I like the left click reveal, where possible, as well.

[menon.samir]

Some thoughts:
No offense, but I think that the current system is fine. It is similar to microsoft word where not all of the menu is visible on the first click, but if you wait the entire menu reveals. I don't think that it isn't discoverable. Right clicking is, in my opinion, a fairly discoverable and logical. If we implement the entire menu on left-click, new users may become overwhelmed by menu choices.

[sascha_silbe]

Please don't change the severity unless there's consensus about it.

[seeta]

Patch File for 50% reduction in the loading time of the menus

[shanjit]

r?

[shanjit]

Replying to seeta:
r?

[walter]

Why the change in the license string? Does going to 0.0 really result in a 50% reduction in the hover delay?

[shanjit]

The 50% reduction in lead time is an approximation realized not through simulation.

[seeta]

Reduction in the lead time for loading menus

[tomeu]

I'm confused by the patch, which proposal is it implementing? Please don't be afraid to extend too much on explaining what you are doing.

[FGrose]

Please see  http://bugs.sugarlabs.org/ticket/2367#comment:3 in ticket #2367.

In particular, the popdown delay of 0.0 second is too short for comfortable viewing of information in one important use case.

[shanjit]

Patch file for reduction in time for loading menues.

[shanjit]

Patch file for reduction in time for loading menues as suggested by FGrose.

[shanjit]

Tomeu : The proposal being implemented is the same one as suggested by Fredrick Grose on the comment above.

Patches are now added. Changes are made to two files.

[HoboPrimate]

Might I suggest that those with access to kids new or newish to Sugar, and make an experiment with 2 groups of them, one with Sugar + patch, another with vanilla Sugar. Observe (a subjective thing, but try) which group has an easier learning curve, and can explore the system more fluidly.

[bernie]

Replying to HoboPrimate:

Might I suggest that those with access to kids new or newish to Sugar, and make an experiment with 2 groups of them, one with Sugar + patch, another with vanilla Sugar. Observe (a subjective thing, but try) which group has an easier learning curve, and can explore the system more fluidly.

I'm afraid this is too subtle to conduct a scientific study, "drug test"-style.

All we have now is the (subjective) observation that users seem to find the delayed menus irritating (perhaps more than adults). If we want stronger evidence, perhaps the burden of proof should go on showing the benefit of delaying all menus by 1 second.