Re: Re: gnome 3.0 shell concept

[Eugene Gorodinsky <e gorodinsky gmail com>]

I gave this idea about the overlay and applications and recent
documents some thought, here's a mockup I came up with:
http://picasaweb.google.com/e.gorodinsky/Gnome#5293464024025970386



2009/1/19  <e gorodinsky gmail com>:
> Thanks for the long reply, Owen. I'll build the shell and try it out. I
> might have some ideas for mockups as well. As for zooming in and out: if
> gnome already uses that metaphor for the overlay, then I think it's great,
> because I find it a very good way of representing the environment a user
> works in. If there were no zooming out, but instead when the user clicks on
> Activities another screen is shown - that would be a bit confusing.
>
> About the javascript engine, I'm curious: why was mozilla's chosen? AFAIK
> Google's quite a bit faster at javascript.
>
> On Jan 19, 2009 5:06am, Owen Taylor <otaylor redhat com> wrote:
>> On Sun, 2009-01-18 at 03:23 +0200, Eugene Gorodinsky wrote:
>>
>> > Hi all. I've seen the gnome 3.0 concept shell with which people came
>>
>> > up at gui hackfest. In my opinion it breaks away too much from the
>>
>> > existing interaction model, and in some ways it makes it harder to
>>
>> > work with the desktop than it is now. For example the second
>>
>> > screenshot apparently makes the desktop zoom out at the press of the
>>
>> > Activities button, this is something that in my opinion would confuse
>>
>> > the user.
>>
>>
>>
>> Honestly, I have no idea whether the zooming will confuse users or not.
>>
>>
>>
>> (Actually, I'd guess zooming out is OK. But the combination of zooming
>>
>> out and moving windows around at the same might be too much going on.
>>
>> Or it might be OK.)
>>
>>
>>
>> Luckily, we have this implemented already so there's no reason to guess.
>>
>> If someone (like you) is motivated, they can build it, round up up some
>>
>> test subjects among their friends and family, and have them try it out
>>
>> for a while and see if they figure out what is going on.
>>
>>
>>
>> At this point, we probably can't make a final determination of good vs.
>>
>> bad, since it's hard to distinguish:
>>
>>
>>
>>  - An idea that could be tweaked into being good by adjusting the
>>
>>   details of animation/timings
>>
>>  - An idea that would be good if more features were implemented to
>>
>>   flesh things out (like dragging windows between workspaces)
>>
>>  - A basically unworkable idea
>>
>>
>>
>> until you add more of the missing features and work on the tweaking. But
>>
>> certainly raw data about what people find neat, what confuses the heck
>>
>> out of people, what people expect to work but doesn't would be really
>>
>> useful.
>>
>>
>>
>> > The mockups for navigating the applications menu are worse even, since
>>
>> > the menu replaces the whole screen apparently. I beleive such a menu
>>
>> > would make gnome unusable for me.
>>
>>
>>
>> Wow, that's a sweeping judgment :-) We don't have the full applications
>>
>> launching system implemented yet, but certain elements are there
>>
>> already, so you can try it out and see how usable it is in practice.
>>
>> (Marina is currently starting to work on the full-screen "More" for
>>
>> applications.)
>>
>>
>>
>> >  On the other side there were a few very interesting ideas in the
>>
>> > document, which I would like to discuss.
>>
>> > I've never before used virtual desktops, but after reading the
>>
>> > document, I agree that they are a grat way of separating activities,
>>
>> > or "contexts". Actually, the whole idea we group our activities by
>>
>> > contexts has been quite enlightening for me, however I bselieve these
>>
>> > contexts are sort of hierarchical, and not flat. This is actually the
>>
>> > reason for inventing tabbed browsing and a bunch of other things. For
>>
>> > example let's take an activity "programming an app": the programmer
>>
>> > writes some code, but at some point is stuck and wants to search for
>>
>> > information to help him with his task. The programmer then openshis
>>
>> > web browser and starts to look for the solutions: he goes to his
>>
>> > chosen search engine and enters some keywords, after that he gets the
>>
>> > results which he must look through one by one. Now to do that he needs
>>
>> > to open a window for each of them, especially if we consider that his
>>
>> > solution can only be pieced together from several sources. What
>>
>> > happens in this scenario is that writing/debugging code and using the
>>
>> > web browser are part of one activity or context, but looking through
>>
>> > the information using the web browser is part of a subcontext. This
>>
>> > subcontext requires more than one window just like the programming
>>
>> > context. So in reality, what I think happens is that while working on
>>
>> > some task we constantly zoom in to take a closer look at some aspects
>>
>> > of the task and zoom out to look over the whole thing and then zooming
>>
>> > in to some other aspect of the task. In fact, I think that zooming in
>>
>> > is quite a natural way of describing it all.
>>
>>
>>
>> There's quite a bit of literature out there on zooming user interfaces,
>>
>> as I'm sure you are aware. The focus is usually a bit different though,
>>
>> from what I've seen... often they involve something like putting all
>>
>> your documents into a big space, and then zooming in to edit them.
>>
>>
>>
>> The idea of mapping zooming to the user's dynamic work-flow is an
>>
>> interesting one, and it would be interesting to see some more mockups of
>>
>> how you see that behaving out in detail. For short-term work for the
>>
>> GNOME shell, we are trying to concentrate mostly on what we can do
>>
>> without modifying the applications much, but it looking ahead to future
>>
>> work where we dig more into the application layer is important as well.
>>
>>
>>
>> [...]
>>
>>
>>
>> > Another idea I liked is the expose-like switching between windows. I
>>
>> > really think it's a fine idea, however the user shouldn't have to
>>
>> > solely rely upon it, the taskbar is a faster way of switching between
>>
>> > windows and if the user is using the mouse to switch, they will
>>
>> > appreciate that.
>>
>> >
>>
>> > I've been thinking of improving the management of workspaces as well.
>>
>> > However instead of explaining I'll show the mockups I came up with,
>>
>> > first.
>>
>> > They are here: http://picasaweb.google.com/e.gorodinsky/Gnome#
>>
>> >
>>
>> > The first mockup is showing the normal user desktop, nothing radical
>>
>> > there and as is evident I'm not even trying to make the system easier
>>
>> > to use for people who've only seen computers on TV but never even
>>
>> > touched them. The reason is that you'll have to train these people to
>>
>> > use the mouse, explain to them the basic concepts of interacting with
>>
>> > a computer (what's a focus, why you need to click on the edit widget
>>
>> > to type anything into it, or that you can click on some text and get a
>>
>> > menu with more text etc.), so I don't think this will add up much,
>>
>> > better to have a book or a video guide on how to use a computer rather
>>
>> > than trying to make a computer so easy to use that the user wouldn't
>>
>> > need to read a manual to use it.
>>
>>
>>
>> Trying to make the basic operation of the computer fundamentally simpler
>>
>> really isn't in-scope for the GNOME Shell. After all, the user's real
>>
>> work occurs in applications, and we aren't modifying them, much.
>>
>>
>>
>> What we are trying to tackle are things like:
>>
>>
>>
>>  - How do you manage lots of open applications
>>
>>  - How do you navigate to a task you were working on 5 minutes ago,
>>
>>   a day ago, or a week ago, and pick up where you left off
>>
>>
>>
>> I tend to think of it as trying to make it easier for people to go from
>>
>> very basic operation (launch a browser, create a word processing
>>
>> document), to a more complex level of usage - to create ways of working
>>
>> with the computer that scale.
>>
>>
>>
>> > The second mockup is where clicking on that arrow in the first mockup
>>
>> > will take you. I actually think a better place for this button would
>>
>> > be the top right corner, but I'm not sure how to let the user know
>>
>> > that the arrow has an entirely different function from anything else
>>
>> > on the bar. The arrow takes you what I called a "meta space". The idea
>>
>> > here is that by clicking and dragging the windows, a user could group
>>
>> > them together and move them around as if they were pieces of paper on
>>
>> > a table. The DE could then identify which windows belong to which
>>
>> > workspace (i.e. virtual desktop) and add them to the task bar for that
>>
>> > workspace. The workspaces could be created and deleted dynamically and
>>
>> > also from this "meta space" the user can have the ability to click on
>>
>> > any window and automatically switch to that workspace as well as bring
>>
>> > the window they clicked on to the top.
>>
>>
>>
>> A lot of these elements are already present in the current gnome-shell,
>>
>> if you think of the overlay as your meta-space. You can dynamically
>>
>> create an destroy workspaces, you can click on a window and switch to
>>
>> the workspace. What isn't implemented yet:
>>
>>
>>
>>  - Dragging windows between workspaces
>>
>>  - Dragging application to workspaces to launch them on that workspace
>>
>>  - Dragging recent applications to workspaces
>>
>>
>>
>> These are all very approachable - they can be done pretty much
>>
>> completely within the Javascript parts of gnome-shell in a couple of
>>
>> hours apiece to get the basics there.
>>
>>
>>
>> To me the sidebar in the overlay is very much part of this idea of
>>
>> direct manipulation - your current windows are part of the things you
>>
>> want to manipulate, but they aren't all of it. The document that you
>>
>> want as part of an activity might not be open at the moment.
>>
>>
>>
>> That's a long answer to a long mail. I think it's great to have people
>>
>> looking at the mockups, and contributing their ideas. But I also think
>>
>> it's important that this list doesn't turn into a lot of abstract
>>
>> discussions about how things *could* work; I'd like it to concentrate on
>>
>> what people *are* doing. I've mentioned some concrete tasks above. Some
>>
>> other things:
>>
>>
>>
>>  * It wouldn't be that hard to make change to the current overlay
>>
>>   to make it much more like your second mockup. Doing the blur is
>>
>>   a bit tricky, but making the workspace background not zoom out
>>
>>   would be almost trivial. So you could experiment with that and
>>
>>   compare it to the current overlay.
>>
>>
>>
>>   [ I really wish we had gnome-shell in a DVCS already for things
>>
>>     like this... so people could publish a branch for other people
>>
>>     to try out. But anyways... a patch works for now. ]
>>
>>
>>
>>  * The sidebar feels like it will integrate very well with the
>>
>>   workspace view ... dragging a recent file to a workspace. But how
>>
>>   does that work when the file you want isn't in the short list
>>
>>   in the sidebar and you have to go to the "More"? I'd like to
>>
>>   see some idea generation / mockups there.
>>
>>
>>
>> - Owen
>>
>>
>>
>>
>>