| Summary: | Fade animations for Maximize | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Eric Moffatt <emoffatt> |
| Component: | UI | Assignee: | Eric Moffatt <emoffatt> |
| Status: | VERIFIED FIXED | QA Contact: | Eric Moffatt <emoffatt> |
| Severity: | normal | ||
| Priority: | P3 | CC: | lars.sonchocky-helldorf, marcel.bruch, markus.kell.r, remy.suen, tor.norbye |
| Version: | 4.2 | ||
| Target Milestone: | 4.2.2 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 357923 | ||
|
Description
Eric Moffatt
Animations can indeed enhance the user experience, but only if they serve a purpose other than just showing off. The current fading effect just makes Maximize/Restore operations slower, but it doesn't *add* any information. If the animation would somehow grow/shrink the editor to its new size, then the user could at least follow the transition by e.g. watching the caret move to its new position. From movies etc., I associate fading with a transition to something different from the previous scene. This is not applicable here, so I'm afraid fading is not the right effect for this operation. See also "Clarify and Communicate with Subtle Animation" here: http://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/AppleHIGuidelines/UEGuidelines/UEGuidelines.html#//apple_ref/doc/uid/TP40002720-SW6 Markus, thanks for the comments (and the link !). By the end of M3 you should see this animation augmented with a visual clue as to where the stacks are going in the trim (the equivalent in 3.8 is the black rectangles) so it will be giving valid feedback. I do realize that for power users the time it takes to do the animation is 'wasted' but the flip side is that eclipse is not only used by us but also by folks that create products that they sell. What can I say...this 'demos' well and makes the environment appear more up-to-date. Not to worry, whatever effects go in will be controllable in some fine-grained manner like a check-tree... Who needs transitions and fades when basic bugs like 8009 (almost 10 years old and top voted) and 35779 (over 8 years old and also a lot of votes) don't get fixes. First things first, folks! (In reply to comment #3) > Who needs transitions and fades when basic bugs like 8009 (almost 10 years old > and top voted) and 35779 (over 8 years old and also a lot of votes) don't get > fixes. First things first, folks! Those bugs are then the place to ask for or offer help (and communicate with committers who understand the code for that area). But enhancements to the user experience are welcome in this bug. PW (In reply to comment #2) > By the end of M3 you should > see this animation augmented with a visual clue as to where the stacks are > going in the trim (the equivalent in 3.8 is the black rectangles) so it will be > giving valid feedback. This didn't make it into 4.2 M7, so we're currently losing information that was available in 3.8. Maximize editor animations are very slow on my mac. It takes roughly two seconds before the maximize animation starts and the editor is resized. When disabling animations it works instantly. > Maximize editor animations are very slow on my mac. See bug 378671. <Sigh> Due to negative feedback for at least some systems I'll be changing the initial state for IWorkbenchPreferenceConstants.ENABLE_ANIMATIONS to 'false' so that folks will have to 'opt in' to see them... git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_2_maintenance&id=62ce52763110657797d2a42ae70b871f1da22798 Set the preference to 'false' by default.... *** Bug 382533 has been marked as a duplicate of this bug. *** *** Bug 378671 has been marked as a duplicate of this bug. *** Verified in M20130116-1800. |