Window management - window animations are too fast for some people to see.

Reported by John Lea on 2012-06-25
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Ayatana Design
Medium
John Lea
Compiz
Medium
Daniel van Vugt
Unity
Medium
Ugo Riboni
compiz (Ubuntu)
Medium
Unassigned
unity (Ubuntu)
Medium
Unassigned

Bug Description

In user testing we found that when participants minimise their documents they don't know where they have gone.

-------------------------------------
Desired solution:

- When a new user starts using ubuntu, the window animation should be slowed down. However to prevent the slow animation making Ubuntu feel slow or frustrating over long term usage, the speed of the animation should increase the more it is used, until the speed reaches it's current value.

- The speed should increase over the first 100 window minimizations e.g. the very first time a user minimizes a window, the animation is very obvious and slow, and the 100th and subsequent times the user minimises a window the animation has the current fast speed.

- This will also need to be tested and the values refined, so the 'starting speed', 'speed decline duration in number of minimises' and 'ending speed' variables (as well as a 'reset' option for testing purposes) will need to be exposed in CCSM

John Lea (johnlea) on 2012-06-25
tags: added: udp
Changed in ayatana-design:
assignee: nobody → John Lea (johnlea)
Changed in unity:
importance: Undecided → Medium
Changed in unity (Ubuntu):
importance: Undecided → Medium
Changed in ayatana-design:
status: New → Triaged
Changed in compiz-core:
status: New → Confirmed
Changed in compiz:
status: New → Confirmed
Changed in unity:
status: New → Triaged
Changed in unity (Ubuntu):
status: New → Triaged
Changed in unity:
milestone: none → backlog
Changed in ayatana-design:
importance: Undecided → Medium
affects: unity (Ubuntu) → compiz (Ubuntu)
summary: - window management - Slow window minimise animation for the first few
- time a user minimises a window
+ Window animations are too fast for some people to see.
Changed in compiz:
status: Confirmed → Invalid
Changed in compiz-core:
status: Confirmed → Invalid
Changed in unity:
status: Triaged → Invalid

I suspect there are fixes that could be made to the zoom animation to make it more visible than it is at present.

Though, I do agree with slower animations. In upstream compiz, we use slower animations that are easy to see, and more visually pleasing. It's mainly only downstream in ubuntu where some animations have been made too fast to see.

I disagree completely with varying the animation speed over time. That kind of inconsistency will really annoy people.

Changed in compiz:
status: Invalid → Triaged
importance: Undecided → Medium
Changed in compiz-core:
status: Invalid → Triaged
importance: Undecided → Medium
Changed in compiz:
milestone: none → 0.9.8.0
Daniel van Vugt (vanvugt) wrote :

Also note: The number of frames of the animation you see is directly linked to the rendering performance. The better graphics performance you have, the more frames you will see. Because it's the duration of the animation that's fixed, and not the number of frames (hence visibility).

We are working to dramatically improve graphics performance of compiz and unity, which will make more animation frames visible in the first place.

John Lea (johnlea) wrote :

@vanvugt; the idea behind the having a slower animation to start with and then increasing in speed during usage is to solve the tradeoff between "slow clear animation allows the user to see exactly what is happening, but makes the computer feel slow and is annoying with repeated usage" and "fast snappy animation makes the interface feel quick and gets out of the way of the user, but is not so descriptive".

Once a user has learnt that minimised windows live in the Launcher, the best animation is something super snappy, exactly like we have at the moment. We don't want this to change. However to solve the 'new user using Ubuntu for the first time ever' use case, an initial slower animation that gets slightly quicker everytime a window is minimised should do the trick. Yes this approach has the animation speed change over time without explaining this to the user, but at most the perceived effect will be the computer getting quicker, and in most cases won't be noticed because minimise animations are the type of thing that are not consciously watched after seeing them happen for the first few times. This way we are teaching the user about how Unity behaves, and then getting out of their way with the minimum of fuss.

This will also need to be tested, so it would be much appreciated if you could expose 'starting speed', 'speed decline duration in number of minimises' and 'ending speed' variables (as well as a 'reset' option for testing purposes), and then we can experiment with tuning these variables.

Thanks,
John

description: updated
summary: - Window animations are too fast for some people to see.
+ Window management - window animations are too fast for some people to
+ see.
John Lea (johnlea) wrote :

@vanvugt; BTW, looking forward to the dramatically improved graphics performance ;-)

Daniel van Vugt (vanvugt) wrote :

John,

If a minimize animation is too fast to show you where in the launcher the window has minimized to, then that's a problem for all users, not just beginners. In that case, increasing the speed of animations is a terrible idea. Because even very experienced users need to be able to see _where_ in the launcher the window minimized to. If the animation speeds up to the point where you can't see where it's going then it will be useless to any kind of user.

We just need to choose an animation that is either more visible by design, or configured a bit slower. I recommend Magic Lamp which is the default minimize animation in upstream compiz. Its visibility is far superior to zoom. Though it needs improvement to look right with vertical docks like the launcher (bug 989463).

John Lea (johnlea) wrote :

@vanvugt; this is something we can easily user test to find the optimum value ;-) If you could expose the three variables I have added to the bug report, plus a 'Magic Lamp/Existing transition' toggle, I'll set up user testing with Charline to try measure the response to different values, and also the response to 'Magic Lamp' versus 'Existing transition'.

This is a great problem to apply user testing to in order to make an objective, as opposed to subjective, decision.

Changed in compiz:
assignee: nobody → Daniel van Vugt (vanvugt)
Sam Spilsbury (smspillaz) wrote :

Difficulty: Easy
Method: In UnityWindow::windowNotify (CompWindowNotify n) track the number of times CompWindowNotifyMinimize comes in -> save it to a GSettings key, once it surpasses a certain number, you can change the option in the plugin like this:

CompPlugin *p = screen->findPlugin ("animation");

if (p)
{
     CompOption::Vector &options = p->vTable->getOptions ();

     foreach (CompOption &o, options)
     {
        if (o.name () == "minimize_animations" )
        .... (scan list for first minimize animation for "normal" windows and change the value to something slower.

John Lea (johnlea) on 2012-08-08
Changed in ayatana-design:
status: Triaged → Fix Committed
Olivier Tilloy (osomon) on 2012-08-10
Changed in unity:
assignee: nobody → Ugo Riboni (uriboni)
status: Invalid → Triaged
Ugo Riboni (uriboni) on 2012-08-10
Changed in unity:
status: Triaged → In Progress
Changed in compiz:
milestone: 0.9.8.0 → 0.9.8.1
Daniel van Vugt (vanvugt) wrote :

Update: Unity 6.4 is revision 2632, so this is actually fix committed for Unity 6.6.

Changed in unity:
milestone: backlog → 6.6
status: In Progress → Fix Committed
Changed in compiz:
milestone: 0.9.8.2 → 0.9.8.4
Omer Akram (om26er) on 2012-09-14
no longer affects: compiz-core
Changed in unity (Ubuntu):
status: New → Fix Committed
importance: Undecided → Medium
Changed in unity:
milestone: 6.6 → 7.0
Daniel van Vugt (vanvugt) wrote :

Invalid for compiz. The fix for this seems done in Unity.

Though compiz bug 1004251 released in 0.9.8.0 would have helped a lot.

Changed in compiz:
status: Triaged → Invalid
Changed in compiz (Ubuntu):
status: Triaged → Invalid
Omer Akram (om26er) on 2012-09-20
no longer affects: unity/6.0
Changed in unity:
milestone: 7.0 → 6.6
Launchpad Janitor (janitor) wrote :
Download full text (9.2 KiB)

This bug was fixed in the package unity - 6.6.0-0ubuntu1

---------------
unity (6.6.0-0ubuntu1) quantal-proposed; urgency=low

  * New upstream release.
    - Fixes non-escaped character sequences in dash previews (LP: #1039020)
    - Updated background layer for preview cover-art and details panels
      to be 10% low-light
    - Expand a PlacesGroup if it is the only category that contains results
      (LP: #950710)
    - Update unity autopilot tests to match autopilot API
    - Updated the convert files to fix some typos in the key names
    - Add gmodule dependency
    - Activate proper result if the categories aren't displayed in-order
      (LP: #1040101)
    - Refactor device launcher icons (LP: #713423)
    - LauncherController: make the controller enable the launcher struts,
      based on hide-mode option (LP: #1044005)
    - Launcher: make always possible to drag an icon to the bottom or top
      of its sub list (LP: #1043968)
    - Don't desat bfb/hud icon in DNDReset (LP: #1043963)
    - Progressively adjust the speed of the minimize animation. First
      time it is used is slower, then speeds up the more it is used.
      (LP: #1017510)
    - Implement new ordering of categories for home lens. (LP: #1043915)
    - UnityWindow now implements ScaleWindowInterface (LP: #876017)
    - Launcher: restore an icon position after that the dragging has been
      cancelled (LP: #955561)
    - LauncherDragWindow: cancel drag on window mapped/unmapped
      (LP: #1044723)
    - Now there is a check of an override color in RefreshColor (which is
      called when a PropertyNotify event happens). Also added a check in
      FullySaturateColor to a void division by zero. (LP: #975350)
    - Queue redraw after cover-art texture is updated from a url/file source.
      (LP: #1043947)
    - Fixed ability to delete glib::Source wrapper during its callback
      (LP: #1044823)
    - Close preview when dash is hidden. (LP: #1045298)
    - LauncherModel: rewrite the Reordering functions to keep the icon
      priority deltas (LP: #761155)
    - Make sure we can pass extra hints when activating preview actions.
      (LP: #1046352)
    - UnityWindow: scale window code improved (LP: #1033935)
    - The mouse will now cause the HUD buttons to change selection
      (LP: #1042692)
    - "Alt+Space" shortcut to reveal the window menu is not hardcoded, but a
       Compiz key option. " (Hold)" should also be translated. Made all
       Compiz plug-in names and all Compiz plug-in option names in
       unityshell.cpp static constants.
    - remove unity --reset, it's not anymore really needed now that we are
      in stable days of unity and we moved to gsettings
    - Removed the variables 'oldPrev' and 'oldNext' which got assigned the
      value NULL, but then were never used
    - Fixed the size of the previews to 770x380 pixels. (LP: #1045243)
    - UnityWindow: use smart pointers, use static close_icon (with dynamic
      state) and PanelStyle context (LP: #1033935) (LP: #1045127)
      (LP: #1046124) (LP: #1046126)
    - Remove everything in the #ifndef USE_MODERN_COMPIZ_GL ifdefs and remove
      the ifdefs alltogether. unity now requires compiz...

Read more...

Changed in unity (Ubuntu):
status: Fix Committed → Fix Released
Changed in unity:
status: Fix Committed → Fix Released
Changed in compiz:
milestone: 0.9.8.4 → none
Changed in ayatana-design:
status: Fix Committed → Fix Released
tags: added: reviewedbydesignq
removed: udp
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers