On Mon, 2010-01-04 at 16:27 -0500, Mark Curtis wrote: > > > One thing I will say though - Owen, you say you're dead set > against > > > having a static list of the existing windows > > > > I did not say that. I said: > > > > - Adding a task list to the current design does not make sense > > *in isolation*. > > > > - We want to do user testing with the current design (including the > > message tray) and are unlikely to make any big changes without > > reference to that. > > What do you mean by the caveat "in isolation"?
That was described in considerable detail in my original mail: | In terms of a task list - I think *not having a task list* is one the | defining characteristics of the current design. Once you add something | like a task list or a dock, many other aspects of the design have to | change: | | - If the task list or dock goes at the bottom of the screen, where | does the message tray go? | | - What happens to the favorites well? It's essentially a dock, so | does it go away? (to avoid confusion and duplication)| | | - If the favorites well goes away, then the overview is no longer | the central destination to "switch to doing something else". | Does that mean that we should try to move recent documents to | the main screen as well? (An item on the dock?) > Also when/where/how is this user testing I keep seeing mentioned? > Jon has already done some early testing with (non-programmer) users around the Red Hat office here; he expects to do more of this this month, likely in conjunction with Maírín Duffy. If you want to help out, find Jon on IRC (nick 'mccann') > > > > but I for one need a visual reminder of what windows I've got open > > > for the current activity - it helps focus my mind on what I'm > doing, > > > what information I have available to me, what I need to do next, > etc. > > > > One of our big problems with the task list going in was that we > didn't > > feel it did that; window titles get abbreviated beyond > > comprehensibility, titles for tabbed windows aren't meaningful, it > > doesn't scale beyond 5-6 windows, and so forth. These are some of > the > > reasons that Windows 7 moved from a window list to an application > list, > > and are things that we are trying to address with the overview. > > But the main problem with the overview as opposed to Windows 7 or OS X > is that it requires user interaction. > By default, without user interaction, a person can see what programs > are running in Windows 7, OS X, GNOME 2.X, KDE, etc In OS X, the indication of what programs are running is normally very subtle - if the program is already on the dock, a shiny blue dot is added under it the dock. (And running apps might not have windows open, so it's even less of an indication of what you are doing.) I forget the exact feedback mechanism for running apps in Windows 7, but it's on the same order. > This is currently not the case with GNOME Shell. Also no matter what > sort of changes are done to the overlay the point is that it needs to > be activated in the first place. > It's meant to be very fast to activate the overview - you just slap your pointer into the corner, then back to select the window. > I do find it interesting you mention "window titles get abbreviated > beyond comprehensibility..." and yet in the applications menu of the > overlay there are STILL truncated applications names (which also > obscure the blue dots) Clearly the ellipsized application name problem is an issue, which we need to fix; the main mechanism for that requires distribution help - we need to say "Firefox" not "Firefox Web Browser", and so forth. But how is that related here? The "glow" is intentionally under the application name. - Owen _______________________________________________ gnome-shell-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-shell-list
