Opened 15 years ago

Closed 11 years ago

Last modified 11 years ago

#1169 closed enhancement (incomplete)

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

Reported by: wwdillingham Owned by: shanjit
Priority: Normal Milestone:
Component: Sugar Version: Unspecified
Severity: Critical Keywords: r?
Cc: eben, erikos, sascha_silbe, garycmartin, manusheel, bernie, HoboPrimate Distribution/OS: Unspecified
Bug Status: Needinfo

Description

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.

Attachments (4)

0001-Reduction-in-the-time-taken-for-loading-of-the-menu-.patch (1.7 KB) - added by seeta 14 years ago.
Patch File for 50% reduction in the loading time of the menus
0001-Reduction-in-the-time-taken-for-loading-of-the-menu-.2.patch (1.6 KB) - added by seeta 14 years ago.
Reduction in the lead time for loading menus
0001-Reduction-in-the-time-taken-for-loading-of-the-menu-.3.patch (1.5 KB) - added by shanjit 13 years ago.
Patch file for reduction in time for loading menues.
0001-Reduction-in-the-time-taken-for-loading-of-menues1.patch (855 bytes) - added by shanjit 13 years ago.
Patch file for reduction in time for loading menues as suggested by FGrose.

Download all attachments as: .zip

Change History (34)

comment:1 Changed 15 years ago by RafaelOrtiz

  • Severity changed from Unspecified to Major

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.

comment:2 follow-up: Changed 15 years ago by garycmartin

  • Cc eben erikos added

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?

comment:3 Changed 15 years ago by sascha_silbe

  • Cc sascha_silbe added

comment:4 in reply to: ↑ 2 ; follow-up: Changed 15 years ago by 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

comment:5 in reply to: ↑ 4 Changed 15 years ago by 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).

comment:6 follow-up: Changed 15 years ago by tomeu

  • Cc garycmartin added
  • Milestone changed from Unspecified by Release Team to 0.86

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

comment:7 Changed 15 years ago by tomeu

  • Bug Status changed from New to Needinfo

comment:8 in reply to: ↑ 6 ; follow-up: Changed 15 years ago by 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.

comment:9 in reply to: ↑ 8 Changed 15 years ago by tomeu

  • Keywords sugar-love added

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?

comment:10 Changed 15 years ago by tomeu

  • Milestone changed from 0.86 to 0.88

This has missed the 0.86 release :(

comment:11 follow-up: Changed 15 years ago by gregorio

  • Keywords GPA added

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

comment:12 in reply to: ↑ 11 Changed 15 years ago by 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.

comment:13 Changed 14 years ago by garycmartin

  • Milestone changed from 0.88 to 0.90
  • Severity changed from Major to Critical

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).

comment:14 Changed 14 years ago by 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.

comment:15 Changed 14 years ago by menon.samir

  • Severity changed from Critical to Minor

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.

comment:16 Changed 14 years ago by sascha_silbe

  • Severity changed from Minor to Critical

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

comment:17 follow-up: Changed 14 years ago by seeta

  • Cc manusheel added
  • Owner changed from tomeu to shanjit
  • Status changed from new to assigned

Changed 14 years ago by seeta

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

comment:18 Changed 14 years ago by shanjit

r?

comment:19 in reply to: ↑ 17 Changed 14 years ago by shanjit

Replying to seeta:
r?

comment:20 Changed 14 years ago by walter

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

comment:21 Changed 14 years ago by shanjit

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

Changed 14 years ago by seeta

Reduction in the lead time for loading menus

comment:22 Changed 14 years ago by seeta

  • Keywords r? added

comment:23 Changed 13 years ago by tomeu

  • Keywords r! added; r? removed

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.

comment:24 Changed 13 years ago by FGrose

  • Cc bernie added

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.

Changed 13 years ago by shanjit

Patch file for reduction in time for loading menues.

Changed 13 years ago by shanjit

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

comment:25 Changed 13 years ago by shanjit

  • Keywords r? added; interface design usability sugar-love GPA r! removed

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.

comment:26 follow-up: Changed 13 years ago by 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.

comment:27 in reply to: ↑ 26 Changed 13 years ago by 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.

comment:28 Changed 12 years ago by HoboPrimate

  • Cc HoboPrimate added

comment:29 Changed 11 years ago by dnarvaez

  • Resolution set to incomplete
  • Status changed from assigned to closed

comment:30 Changed 11 years ago by dnarvaez

  • Milestone 0.90 deleted

Milestone 0.90 deleted

Note: See TracTickets for help on using tickets.