item detail (i.e. volume) hard to interact with

Bug #688975 reported by cde
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ayatana Design
Opinion
Undecided
Unassigned
Indicator Applet
Opinion
Undecided
Unassigned
One Hundred Papercuts
Invalid
Undecided
Unassigned

Bug Description

In indicator-applet (0.4.6 and earlier), clicking the volume icon then moving the mouse (diagonally) to interact with the volume level typically leads to deselecting the volume icon and moving to the envelope icon, forcing the user to retreat, and make conscious & deliberate vertical-then-horizontal movements.

Expected behaviour - after clicking the volume icon, volume detail should remain visible. Selecting adjacent indicator icons could be achieved by an extra click, which would be consistent with how the user would interact with the date or session applet in the same region of the default panel. Alternatively a brief "hover" could be required to activate adjacent applet icons.

Revision history for this message
Chris Wilson (notgary-deactivatedaccount) wrote :

I agree that there is a problem with the deselection of applets as the user attempts to interact with the dropdown menu, and that there is an inconsistency in the user experience with regard to the behaviour of these applets when the calendar applet is taken into consideration.

When reproducing this bug, I also noticed that when moving from one applet to the next, the dropdown menu for the next applet would appear, but when the calendar applet was moused over, any subsequent mousing over of an applet no longer results in the appearance of the dropdown menu.

I think this is a larger problem in the behaviour of the indicator applets, and of the panel in general which the Ayatana Design team should look at, and given the scope of this problem, this is not a valid papercut.

Changed in hundredpapercuts:
status: New → Invalid
Revision history for this message
cde (c-d-everett) wrote :

Considering the similar behaviour on the session indicator applet, I agree this is seemingly not a single-package papercut. But isn't it still a papercut (presumably trivial to fix, easy & common to encounter, makes Ubuntu less nice to use)?

Any thoughts on how/where to file this as a papercut, or would you not consider it suitable for the hundred papercuts project?

Revision history for this message
Chris Wilson (notgary-deactivatedaccount) wrote :

Reviewing comment #1 (https://bugs.launchpad.net/hundredpapercuts/+bug/688975/comments/1) I think it was inappropriate of me to include the calendar applet in this discussion, since that appears to be a separate issue, which I will report as a separate bug myself.

I still believe this is not a valid papercut because while change the code may be a trivial task, the issue of what it should be changed to will require some discussion. I've been thinking about the behaviour of the applets and I wonder if requiring a click to access them may not be a bad idea after all. The current implementation of the applets leads me to believe that they were designed to facilitate rapid movement form one to another, allowing the user to quickly access the contents of the applet without the applet itself getting in the way.

How many people really need to move quickly between them though? I my day-to-day use of them, I only ever find myself needing to access one at a time, and so I would never notice the requirement of a second click to get from one to the other.

Moving the mouse from where it is now to where they want it to be in a straight line is what come naturally to people, and the current behaviour of the applets goes against notion.

I will mark this as an opinion and see what other people think.

Changed in hundredpapercuts:
status: Invalid → Opinion
status: Opinion → Invalid
Changed in ayatana-design:
status: New → Opinion
Changed in indicator-applet:
status: New → Opinion
Revision history for this message
cde (c-d-everett) wrote :

Thanks Chris, very welcome & constructive comments. Whether it remains a papercut or not, I hope it gets changed to bring consistency to that region of the default panel.

I was going to compare it to selecting open apps on the panel - similar to the Windows taskbar, a click is required to switch apps, and I find the new Win7 "hover" behaviour on the taskbar to be one of the worst additions to the OS. But then again, the Ubuntu Applications/Places/System menus don't require separate clicks, and that seems fine. Perhaps we are more inclined to move vertically in menus?

- Chris (snap!)

Revision history for this message
Chris Wilson (notgary-deactivatedaccount) wrote :

The Application/Places/System menus do indeed not require a separate click to move between them, though the start point (the menu name eg 'Application') is much larger than the start point in the indicator applets, so a slight movement of the pointer to the side will not take the user out of the Gnome menus like it does in the panel.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.