Re: gnome 3.0 shell concept
- From: Milan Bouchet-Valat <nalimilan club fr>
- To: Eugene Gorodinsky <e gorodinsky gmail com>
- Cc: gnome-shell-list gnome org
- Subject: Re: gnome 3.0 shell concept
- Date: Sun, 18 Jan 2009 11:42:49 +0100
Le dimanche 18 janvier 2009 à 03:23 +0200, Eugene Gorodinsky a écrit :
> 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. 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. On the other side there
> were a few very interesting ideas in the document, which I would like
> to discuss.
Keep in mind those are experimental, AFAIK. I think the overlay mode (as
we call it) is interesting but should not be the only way of doing
things. But I guess testing will show what's best.
> 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 opens his
> 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. I'm not sure if you
> realised this already or not, so I'm just mentioning it in case you
> haven't.
I'm quite interested in the ideas of activities and I've thought a bit
about them. While the idea of sub-activities (or contexts) is
interesting, I don't really think we need to implement it in a
hierachical way. For me, the best is to associate one or more workspaces
to an activity, and each workspace would then be something like a
sub-activity. In your example, this would mean code tools are on one
workspace and Firefox on the other one. I think it solves many issues
quite simply and is still very intuitive (to hackers at least!).
> It was mentioned in the article that tabs are a failure of the window
> manager. Indeed the window manager should do these things, though at
> the moment I'm not sure how the window manager could manage windows in
> a different way so that tabs were not required, but I beleive some
> sort of releif could be provided by creating a tabbed window manager
> (maybe something like google's browser).
I've never really thought about that, I let this to others... It can be
quite long to implement, anyway.
> 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.
See previous mails this week on the list: standard windows switching
should be available because it's much quicker.
> 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.
Pretty looking! The panel menu is too classical, I think we want to put
this in the overlay mode, else we would lose the ability to improve
things there, and we be stuck with what we already have in GNOME. But
your second button can be useful (see below).
> 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.
I can see some good ideas here IMHO. Your "meta space" has to do with
"overlay mode". In the mockup, it's like Exposé, but what you describe
is more complex. I don't really know what is doable in it, but that
could be a nice feature and would make complex tasks more intuitive
maybe.
More generally, I'm wondering whether it could be nice to separate
overlay from Exposé in the current design. For now, switching windows
inside the workspaces is quite hard because of the lack of space, and we
need to hide them anyway if we want to show more actions (see the
mockups on GNOME's wiki). So why not keep the windows/workspaces issue
to another mode, triggered by a new button just like on the screenshots
above? Overlay could then simply go over the current desktop, and could
be used in a simpler way, since it wouldn't imply a so complex, which
can be tiring if you use it all the time. What do you think? I'm just
thinking the current layout will soon be full if we add so many
functions to it...
Cheers
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]