GNOME Bugzilla – Bug 105502
s/Roll Up/Show Titlebar Only
Last modified: 2004-12-22 21:47:04 UTC
and s/Unroll/Show Full Window The menu items Roll Up and Unroll do not describe what this function does. There is no real "rolling" involved. These menu items retain the original shade metaphor. The suggested replacements above describe what this function actually does. These menu items are also present in the Window List applet.
Seth did you do any user testing on this?
Nope.
If this change is made, as well as the Window List applet, we'll also need to modify the Windows preference tool. "Roll up" is one of the options in the "Double-click titlebar to perform this action" drop- down list.
oh that's not the half of it. You'd also have to update all the translations... fun fun fun!
To be fair, some sort of animation to show the window 'rolling' and 'unrolling', similar to the one we already have for 'minimizing', would probably reinforce Seth's choice of wording and give the user a big clue as to what was actually happening here (it's a bit of a shock the first time you come across it otherwise). Be prepared for another lengthy debate like the one in #95777 and elsewhere if we did that though :)
Enlightenment had a pretty good animation of this I think.
Are we redesigning the UI to fit the menu item text?! Even with the animation Calum suggested, I think users would still have trouble understanding Roll Up and Roll Down. The menu item text I suggested describes what actually happens, not the style in which it happens. I think that changing the menu item text would provide users with a clear description of what the menu does, and it also has the benefit of being a (AFAIK) simple solution to implement.
I don't think anyone is trying to redesign the UI to fit the menu item, rather that the functionality that they wanted to convey in the first place was that the window is still present but hidden within the visible titlebar. This really is a Usability issue, although with a linguistics slant. Strictly speaking Eugene's suggestion "Show Titlebar Only" is correct, but lacks the pizzazz of "Roll Up". Also, "Roll Up" does suggest that the window is still present, just "rolled up". On the other hand "Show Titlebar Only" has a hint of separation about it, as if the window has somehow gone somewhere else. If we have evidence that "Roll Up" is indeed understood by users, and if the perceived action suggests rolling up, then "Roll Up" might be acceptable. However, in the absence of those pieces of the puzzle, Eugene's suggestion is the most accurate right now.
Patrick: I've first read the terms "Roll Up" and "Unroll" in GNOME. I instantly knew what it was referring to and still find it pretty nice as it's very pictographic. I vote for leaving it as-is. regs, Chris
Chris: I suspect that your experience is fairly normal. However, even if you intuitively grasp what has happened, there still remains a problem of definition. When the documentation team came to look at the terms "Roll Up" and "Unroll", we had some difficulty squaring the terms with the actual functionality. Frankly, I must say that Calum's suggestion rather appeals to me - in other words rather than changing the terms, we make sure that the >>perceived<< functionality accurately matches the terms. Of course, I do not know what effort this would require from an engineering perspective. Pat
So we have two choices: 1. Change the functionality to match the current menu items. 2. Change the menu items to match the current functionality. Is there much engineering effort required to implement choice 1? Would the rollup/rolldown animation have a significant impact on performance? Might the animation end up as a GConf key? Personally I favor choice 2. I feel that a rollup/rolldown animation is unnecessary. And I think the proposed changes to the menu items describe the current behavior accurately and unambiguously.
We could do an outline animation for the rollup similar to that for minimizing with essentially zero effort. But honestly if the user can't tell that the window is now just a titlebar after doing roll up I don't think that anything short of a miracle will help him figure it out.
Eugene - I'm going to have to break rank with you on this one. I do believe that if the action the user requests from a menu is accurately reflected in the perceived result, then we have done our job properly, from the language perspective, usability perspective and engineering perspective. A skimpy outline animation would be sufficient to produce an impression of Rolling Up. So I vote to keep the rolling metaphor in the menu language, and also include the metaphor in the functionality. Pat
This functionality is already in metacity HEAD. Havoc def'ed out the mentioned section in src/windows.c:1888, though: http://makeashorterlink.com/?C32412564 Just remove "if 0" and it's "endif" to see a lovely shade effect when rolling up. Havoc: CCing you so that you can explain us why you did so. I just see one problem at the moment: If the window is very large the effect doesn't look pretty. regs, Chris
Basically the animation is turned off because it was ugly. It may have also had redraw problems. I just filed bug #123162 which we may want to consider rather than the rename here. I guess my net feeling on the rename is just that it seems a little longer and more pedantic, "less friendly" on some level. But if there were any consensus to change it I wouldn't stand in the way.
the point is now moot. "Roll Up" is no longer in the window menu.