Opened 13 years ago

Closed 11 years ago

#2367 closed defect (notsugar)

[Dextrose 2] Secondary palette appears too soon on Neighborhood view buddy icons

Reported by: FGrose Owned by: smparrish
Priority: Normal Milestone: Unspecified
Component: Dextrose Version: Unspecified
Severity: Unspecified Keywords: design, dtst
Cc: bernie, m_stone, smparrish Distribution/OS: Dextrose
Bug Status: Assigned

Description

Observed on Dextrose 2 build 1dx2 Dextrose 2 International running on an XO-1.

When hovering an XO figure in the Neighborhood view, the extended palette appears almost instantly. This can be distracting when the intent is only to determine the name of the Learner, and also obscures more of the view than necessary for the task.

I would suggest that a slightly longer delay (perhaps 0.5 second) before showing the secondary palette and a similar delay before the name palette disappears.

One should be able to hover until the name palette appears, then move the pointer away to avoid revealing the secondary palette. The name palette would then disappear after about a half second. This method works well in OLPC build 802.

Change History (9)

comment:1 Changed 13 years ago by FGrose

  • Cc bernie added
  • Component changed from untriaged to Dextrose
  • Owner set to bernie

comment:2 follow-up: Changed 13 years ago by bernie

  • Cc m_stone added

This is an intentional change, the result of this experimental patch proposed by Michael Stone:

http://git.sugarlabs.org/projects/dextrose/repos/mainline/blobs/master/rpms/sugar-toolkit/kill-the-delayed-menus-for-good.patch

Some people seem like it, some don't. The patch has been included in Dextrose long time ago to observe the reaction of users. I asked my 5th grade testers whether they liked it more this way or the way it was before, but they couldn't tell. Apparently, this change is too subtle for non technical users to consciously notice it.

The delay parameter is global for all palettes. Would you be ok if all menus became slower as they were in 802? You can experiment with the timeout by editing the value of _secondary_anim at approx line 106 of

/usr/lib/python2.6/site-packages/sugar/graphics/palette.py

After waiting for some feedback, I'd be ok with increasing the timeout of the secondary palette from 0.0 to 0.5.

comment:3 Changed 13 years ago by FGrose

I've done some testing with Dextrose 2 build 1dx2 Dextrose 2 International running on an XO-1 and with Sugar 0.89.10 in a Xephr window on Fedora 14 beta (kernel 2.6.35.4-28.fc14.x86_64) in an 3.2-GHz, 3.3-GByte RAM workstation.

I tried these settings:

(in palettewindow.py) 0.0 to 0.6 seconds

self._popdown_anim = animator.Animator(0.6, 10)

The behavior varies with the processor and environment.

There is sufficient delay in system overhead for the primary palette popup,

self._popup_anim = animator.Animator(0.0, 10)

to use the 0.0 second delay and still allow one to move the mouse pointer casually over buddies or access points without revealing the name for every target annoyingly.

The popdown delay of 0.6 second allows one to hover a target, reveal just the name, and then move the pointer away, and still have sufficient time to read the name. (Setting this popdown delay to 0.0 second as proposed in http://bugs.sugarlabs.org/attachment/ticket/1169/0001-Reduction-in-the-time-taken-for-loading-of-the-menu-.2.patch (ticket #1169) is too short to comfortably read the name before the palette is dismissed.)

I tried these settings:
(in palette.py) 0.0 to 1.0 seconds

self._secondary_anim = animator.Animator(1.0, 10)

Here the different processors and environments had a greater effect.

On the XO-1 the secondary palette could be delayed only 0.6 second and usually one could move the pointer away from the target to avoid showing the secondary palette, but in the Xephyr window, delays less than 1.0 second would usually cause the secondary palette to be revealed briefly, and distractingly.

In summary,

self._popup_anim = animator.Animator(0.0, 10)
self._popdown_anim = animator.Animator(0.6, 10)

self._secondary_anim = animator.Animator(1.0, 10)

are the settings I would recommend based on these tests.

The 1.0 second delay for the secondary palette popup is beyond the 0.5 second limit that was suggested, but does help with discoverability (as suggested in ticket #1169), and avoids the surplus exposure of information for the Neighborhood view use case.

comment:4 follow-up: Changed 13 years ago by smparrish

Bernie are you ok to go with the fgrose's recommended settings?

comment:5 in reply to: ↑ 4 Changed 13 years ago by bernie

Replying to smparrish:

Bernie are you ok to go with the fgrose's recommended settings?

Sorry for not replying sooner. I was intending to try it out on my laptop first, but I can't seem to find the time.

I suppose we could tweak the values as recommended by FGrose and wait for you to issue the next test build to see what happens. To see if users notice any difference, let's not say anything in the release notes. Because these things are very subliminal...

comment:6 Changed 13 years ago by smparrish

  • Bug Status changed from Unconfirmed to Assigned
  • Cc smparrish added
  • Owner changed from bernie to smparrish
  • Priority changed from Unspecified by Maintainer to Normal
  • Status changed from new to assigned

Made the change today and its included in os3dx2. Will wait a few weeks and if we get no complaints will close this issue.

comment:7 Changed 13 years ago by smparrish

  • Keywords dtst added

comment:8 in reply to: ↑ 2 Changed 13 years ago by mtd

Replying to bernie:

This is an intentional change, the result of this experimental patch proposed by Michael Stone:

http://git.sugarlabs.org/projects/dextrose/repos/mainline/blobs/master/rpms/sugar-toolkit/kill-the-delayed-menus-for-good.patch

Some people seem like it, some don't.

Some discussion is here: http://lists.sugarlabs.org/archive/sugar-devel/2009-October/020141.html

comment:9 Changed 11 years ago by dnarvaez

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

Dextrose is not tracked here anymore.

Note: See TracTickets for help on using tickets.