|
> 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?) > Which to me reads "I don't want a task list because it throws off the rest of the design which may actually be fundamentally flawed but rather than think of that I'll just ignore any bit of negative feedback" > > 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') > > I'd love to know the results of said testing > > > > 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. > A frame around the icon would I suppose be the best description. But the point is, in all of them you can see without user interaction. > > 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. > It doesn't matter how quick the animation is, the point is that any movement is required in the first place. > > 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. > I brought it up because it felt like you had said "welp, can't use window lists because it gets truncated, but when it's in the beloved Overlay it's fine". As far as saying "Firefox" instead of "Firefox Web Browser" that still doesn't help applications like "OpenOffice.org". I know the glow is intentional, I'm saying the names (which are often truncated) make it hard to see. I would think it would be best to not have any words listed. Only have the icon for the application, with the dots underneath. Hotmail: Trusted email with powerful SPAM protection. Sign up now. |