Large menus need to scroll

[Calcipher]

Thanks to a curious cat, I came to have over 100 instances of the 'take a screen shot' dialogue open. When I went to the grouped Docky item (thinking I could select the 'close all' option) the list of open windows just expanded beyond the top of my screen and I couldn't get to the 'close all' option. So, perhaps we can lump all of this into a feature request, or perhaps this can be considered, in part, a bug, but here are the problems as I see them:
1. When the number of grouped open windows grows too large, the list scrolls off of the available screen real estate.
    -Possible solution: Cause the list of open windows to scroll after some logical number of windows have been open.
2. When #1 occurs, there is no way to access the Docky grouped item controls.
    -Possible solution: Move the controls to the bottom of the list.
I know this is more feature request-y, but it would really be nice to have the menu items moved to the bottom of the list without even considering the 'bug' that such a change would solve.

[Robert Dyer (psybers)]

@Dan: so what do we do if the menu is larger than the screen? I have ideas but I'd like your input.

[Danielle Foré (danrabbit)]

Well, I would assume it would simply scroll. Something like this: http://www.flashtory.com/upload/files/med/1941/vertical-scrolling-menu-xml-as3.jpg with a faded top and bottom. Sorry the example is kind of lame.

What to you think?

[Robert Dyer (psybers)]

Keep in mind, our menus have tails. Scrolling makes sense, but how do you visually handle that with these damn tails? ;-)

[Danielle Foré (danrabbit)]

Kind of a crappy mockup, but you get the idea.

There's a gradient if you can scroll down, and it's sharp if you can't. I think we're doing this in the stacks branch.

[Calcipher (calcipher)]

I'd think a simple arrow at the bottom indicating that the menu should scroll would make sense and look professional. What about moving the controls to the bottom of the menu?

[Calcipher (calcipher)]

I'd like to add that the behavior of a favorites folder in Firefox might make a decent model for this.

[Robert Dyer (psybers)]

@Dan: good thinking, but two things:

1) how do we decide the height of the menu? Fill the screen?

2) I dont think it would make sense to make *part* of the menu static and *part* scroll, all or nothing

@Zach: the FF has no tail, it is a box so scrolling there is quite easy to do.

[Danielle Foré (danrabbit)]

1. Hmm I'm not sure filling the screen would be good. But some sane default max size would be.

2. I disagree. Imagine scrolling through 1000 windows when you really just want to click "close all". Cats + Keyboards.

[Robert Dyer (psybers)]

Exactly, so the menu starts at the top (like all scrolling menus) and scrolls down by default. Thus you will see the global actions immediately.

[Danielle Foré (danrabbit)]

eh... I still feel that it should be separate. But that is just my opinion I suppose.

[Robert Dyer (psybers)]

And if they have helpers, which add a 3rd (or 4th, or 5th or ..) section to the menu?

[Danielle Foré (danrabbit)]

hmm.. I suppose that's a good point. As long as the starting position is always those controls I suppose.

[Calcipher (calcipher)]

I'm not sure I agree that it always makes sense to start from the top of the menu. If you are at the bottom of the screen and need the controls your mouse would have to travel all the way to the top of the scrolling menu to get to the controls. If, however, you are on the top (or sides?) of the screen you'd want the controls at the top. Honestly, I think the best situation would be to put the controls closest to the grouped Icon (or mouse? I'm not sure there is a meaningful difference.).

Also, I agree with Dan that there needs to be a fixed max height of the menu; what happens if there are too many helper controls and you have to scroll to get to the actual windows?

[Danielle Foré (danrabbit)]

Hmm, yea it might freak people out a bit at first, but putting controls close to the dock would actually give them a more consistent placement for muscle memory.

so +1 to that idea.