(no subject) plus dockables
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
(no subject) | oliver@first.in-berlin.de | 26 Aug 19:50 |
(no subject) plus dockables | gg@catking.net | 26 Aug 21:11 |
(no subject) plus dockables | Sven Neumann | 26 Aug 21:19 |
(no subject) plus dockables | Martin Nordholts | 27 Aug 07:25 |
(no subject) plus dockables | yahvuu | 27 Aug 12:39 |
(no subject) plus dockables | gg@catking.net | 27 Aug 13:23 |
(no subject) plus dockables | Martin Nordholts | 28 Aug 07:08 |
(no subject) plus dockables | gg@catking.net | 28 Aug 08:20 |
(no subject) plus dockables | Olivier | 28 Aug 08:27 |
(no subject) plus dockables | Sven Neumann | 28 Aug 20:17 |
(no subject) plus dockables | Sven Neumann | 28 Aug 20:13 |
(no subject) plus dockables | yahvuu | 01 Sep 12:45 |
(no subject) plus dockables | Martin Nordholts | 09 Sep 08:59 |
(no subject) plus dockables | oliver@first.in-berlin.de | 26 Aug 22:05 |
(no subject) plus dockables | Sven Neumann | 26 Aug 22:17 |
(no subject)
Bcc:
Subject: Re: [Gimp-developer] scanner support should be File->Acquire
Reply-To:
In-Reply-To:
Hello,
On Thu, Aug 26, 2010 at 12:54:38PM -0400, Christopher Curtis wrote:
On Wed, Aug 25, 2010 at 2:55 PM, Sven Neumann wrote:
"somewhere else" is not a very intuitive place either. We've had a longer discussion when these items were moved to File->Create and no one came up with a better solution.
I find the 'Create' label non-obvious as well. It makes sense for the logo scripts, but I'd suggest considering:
[...]
The problem is, that file->create as well as file->new do not really create a file.
A file is created, when it's written to disk.
It's an image that is created.
And getting data from a scanner is importing data to make an image out of it, which maybe later will be saved to a file (or thrown away/deleted).
It's the "we are used to misnomed menues since decades" as a heritage of M$-Windows, which sucks again and again, and will not stop. So... no wonder those discussions will come up again and again.
The only creative GUI that I've ever seen is that of Blender.
You need time to learn it, because it's so different, but it's good.
There are other things in the Gimp-GUI that slows down the workflow, for example in layer menue and in image menue, transformation tools are at different vertical positions. So you always have to switch in mind, or look up it again and again, which is time consuming.
It would be a good idea, IMHO to have same functionality at same vertical position, so that it doesn't matter if you want to rotate your image or your layer: the transformation will always be at the same height in the menue.
To achieve same vertical position, for menue-fields that are not used one could add an empty field.
This at first might seem strange, because other programs don't do it that way. But after people will be used to it, it will make the work with Gimp easier and faster. (Learn from Blender!)
Ciao, Oliver
(no subject) plus dockables
On 26/08/10 19:50, oliver@first.in-berlin.de wrote:
Bcc:
Subject: Re: [Gimp-developer] scanner support should be File->Acquire Reply-To:
In-Reply-To:Hello,
On Thu, Aug 26, 2010 at 12:54:38PM -0400, Christopher Curtis wrote:
On Wed, Aug 25, 2010 at 2:55 PM, Sven Neumann wrote:
"somewhere else" is not a very intuitive place either. We've had a longer discussion when these items were moved to File->Create and no one came up with a better solution.
I find the 'Create' label non-obvious as well. It makes sense for the logo scripts, but I'd suggest considering:
[...]
The problem is, that file->create as well as file->new do not really create a file.
A file is created, when it's written to disk.
It's an image that is created.
And getting data from a scanner is importing data to make an image out of it, which maybe later will be saved to a file (or thrown away/deleted).
It's the "we are used to misnomed menues since decades" as a heritage of M$-Windows, which sucks again and again, and will not stop. So... no wonder those discussions will come up again and again.
The only creative GUI that I've ever seen is that of Blender.
You need time to learn it, because it's so different, but it's good.
There are other things in the Gimp-GUI that slows down the workflow, for example in layer menue and in image menue, transformation tools are at different vertical positions. So you always have to switch in mind, or look up it again and again, which is time consuming.
It would be a good idea, IMHO to have same functionality at same vertical position, so that it doesn't matter if you want to rotate your image or your layer: the transformation will always be at the same height in the menue.
To achieve same vertical position, for menue-fields that are not used one could add an empty field.
This at first might seem strange, because other programs don't do it that way. But after people will be used to it, it will make the work with Gimp easier and faster. (Learn from Blender!)
Ciao, Oliver
I agree, I also find the file-create-screenshot *-scanner options rather forced and I have to do a double take to make sure it really says what I think it says and I have not misread something.
File - Create - Xsane: device dialog seems particularly contorted.
I don't really see the need for File - New to be on it's own. The amount of work that is done after this action makes one more selection irrelevant. File - New - Image would be fine.
File - New -Scan ; *-From clipboard ; *-screenshot would make more sense than the "create" paradigm.
File - Create - button , *-logo et al. seem more natural and are fine.
Since the subject here is "(no subject)" I will add a related comments on some similar oddities in the menu system
I want to comment on how hard/illogical it is to find the "layers dockable dialogue" without knowing what gimp calls it and knowing that "dockable dialogues" are found on the windows menu.
This is a recurrent problem that indicates that this is counter-intuitive for me. I go several times round the loop and sometimes just give up not having found what I know is there in the GUI - somewhere.
Some comments:
If I want to operate on layers , the most logical place to look is on the layers menu. No go.
Having done the tour , I may expect to find something about layers in Windows menu. Nope.
So now I'm reduced to scanning every submenu to see if I can spot something about layers that is not on the layers menu. As well as going minutely through the layers menu since I have presumably carelessly missed what MUST be there. Finally, I have to know it's called a dockable dialogue before I'm likely to find it
There are similar inconsistencies in several areas . The colour picker "dockable" is not on the Colours menu.
This would seem to be another case of organisation by programming implementation , not by USER work requirements.
These are all tucked out of the way , two layers down in the hierarchy because they are programmed as "dockables", not put where they need to be in terms of function.
If I want a colour , I should find it on the colour menu . If I want to select layers I should fine the necessary interface elements on the layer menu.
regards.
(no subject) plus dockables
On Thu, 2010-08-26 at 21:11 +0200, gg@catking.net wrote:
If I want a colour , I should find it on the colour menu . If I want to select layers I should fine the necessary interface elements on the layer menu.
Sounds reasonable. We could duplicate the menu items from the Dockables menu that raise/create those dialogs in the places where they belong. So we would have "Layers dialog" in the "Image/Layers" menu and the like. That's as simple as editing the XML files in the menus sub-directory. Perhaps someone wants to come up with a patch...
Sven
(no subject) plus dockables
On Thu, Aug 26, 2010 at 09:11:25PM +0200, gg@catking.net wrote: [...]
Since the subject here is "(no subject)" I will add a related comments on some similar oddities in the menu system
[...]
Sorry, I was too tried, it was "Re: [Gimp-developer] scanner support should be File->Acquire" before; I made a typo in editing... with mutt I can use my editor to directly change the mailheader - and also do some nasty stuff.
It should be in the same thread as "the "scanner support"-thread.
I want to comment on how hard/illogical it is to find the "layers dockable dialogue" without knowing what gimp calls it and knowing that "dockable dialogues" are found on the windows menu.
There are many things like that.
I'm not long enough on this list to know all the old discussions, but AFAIK Sven Neumann once (some years ago) was interviewed by the Cahos Radio, and mentioned there, that one person did a complete usability anylsis.
I don't know idf this work has already been finished and published.
Would be interesting to see at the recommendations. I mean: not necessarily adopt all such things (maybe thera ara also other concepts and ideas), but at least it could be something for a discussion.
Thanks for your comments on GUI inconsitencies.
Ciao, Oliver
(no subject) plus dockables
On Thu, 2010-08-26 at 22:05 +0200, oliver@first.in-berlin.de wrote:
I'm not long enough on this list to know all the old discussions, but AFAIK Sven Neumann once (some years ago) was interviewed by the Chaos Radio, and mentioned there, that one person did a complete usability anylsis.
I don't know idf this work has already been finished and published.
Would be interesting to see at the recommendations. I mean: not necessarily adopt all such things (maybe thera ara also other concepts and ideas), but at least it could be something for a discussion.
This is all documented at http://gui.gimp.org/ and for some years now we are changing the UI based on input from the GIMP UI team.
Sven
(no subject) plus dockables
On 08/26/2010 09:19 PM, Sven Neumann wrote:
On Thu, 2010-08-26 at 21:11 +0200, gg@catking.net wrote:
If I want a colour , I should find it on the colour menu . If I want to select layers I should fine the necessary interface elements on the layer menu.
Sounds reasonable. We could duplicate the menu items from the Dockables menu that raise/create those dialogs in the places where they belong. So we would have "Layers dialog" in the "Image/Layers" menu and the like. That's as simple as editing the XML files in the menus sub-directory. Perhaps someone wants to come up with a patch...
I don't think we should duplicate any menu items. Having things in two places tends to cause unnecessary confusion. A user will have to answer questions like "Why is this menu item in two places? Is it the same menu item? Does it do the same thing? Which one should I use now?" Having just one place to do things avoids such ambiguity and mental friction.
If people have troubles finding the Layers dockable, we should instead look into making it more discoverable, like adding a 'Dockables' top menu or moving them directly under 'Windows' instead of having a sub menu.
/ Martin
(no subject) plus dockables
On 27.08.2010 07:32, Martin Nordholts wrote:
If people have troubles finding the Layers dockable, we should instead look into making it more discoverable, like adding a 'Dockables' top menu or moving them directly under 'Windows' instead of having a sub menu.
What about naming it the 'Dialogs' menu?
-- 'Dockables' sounds like implementation slang to me. And the 'Windows' menu becomes confusing in single-window-mode.
Making the Layers dialog discoverable under the 'Layers' menu and color dialogs below the 'Colors' menu etc.. makes a lot of sense, but IMHO that's the job of a 3.0 redesign -- there is a whole lot more to do than just releasing the dockables from their current hiding place and distributing them over the menu structure. (E.g. what use is in displaying the brushes dockable while the gradient tool is active? etc..)
regards, yahvuu
(no subject) plus dockables
On 08/27/10 12:39, yahvuu wrote:
On 27.08.2010 07:32, Martin Nordholts wrote:
If people have troubles finding the Layers dockable, we should instead look into making it more discoverable, like adding a 'Dockables' top menu or moving them directly under 'Windows' instead of having a sub menu.
What about naming it the 'Dialogs' menu?
-- 'Dockables' sounds like implementation slang to me. And the 'Windows' menu becomes confusing in single-window-mode.
Well dockable is a adjective so it begs the question: dockable what?
I agree this is implementation terminology that probably should not be on the GUI.
I find calling these dialogs to be part of the confusion (as well as being buried) . A dialogue suggest some kind of direct one-off interaction, like entering image scaling information and pressing OK, not a utility window I put on one side to be used from time to time.
Since they are indeed windows , I don't see much wrong with that term.
/gg
Making the Layers dialog discoverable under the 'Layers' menu and color dialogs below the 'Colors' menu etc.. makes a lot of sense, but IMHO that's the job of a 3.0 redesign -- there is a whole lot more to do than just releasing the dockables from their current hiding place and distributing them over the menu structure. (E.g. what use is in displaying the brushes dockable while the gradient tool is active? etc..)
regards, yahvuu
(no subject) plus dockables
On 08/27/2010 12:39 PM, yahvuu wrote:
On 27.08.2010 07:32, Martin Nordholts wrote:
If people have troubles finding the Layers dockable, we should instead look into making it more discoverable, like adding a 'Dockables' top menu or moving them directly under 'Windows' instead of having a sub menu.
What about naming it the 'Dialogs' menu?
-- 'Dockables' sounds like implementation slang to me. And the 'Windows' menu becomes confusing in single-window-mode.
Yes 'Dialogs' is better than 'Dockables'. 'Dockable Dialogs' is even better except it's too long.
Making the Layers dialog discoverable under the 'Layers' menu and color dialogs below the 'Colors' menu etc.. makes a lot of sense
But won't that be a problem? Instead of having all dockable dialogs in a single place, a user would have to go hunt for the one he wants.
Regards, Martin
(no subject) plus dockables
On 08/28/10 07:16, Martin Nordholts wrote:
Making the Layers dialog discoverable under the 'Layers' menu and color dialogs below the 'Colors' menu etc.. makes a lot of sense
But won't that be a problem? Instead of having all dockable dialogs in a single place, a user would have to go hunt for the one he wants.
Regards, Martin
I think this is the logical error here from usage point of view. It is not the fact that they are "dockable" which means they should be grouped together. They should be grouped according to function.
If I want to hide a layer I should not need to think : "last time I did this what did it look like, what sort of GUI element was it that allowed me to hide a layer, was it dockable, where are dockables hidden?"
If I want to hide a layer , I go to the layers menu.
I find it strange anyone would argue against that.
/gg
(no subject) plus dockables
Just the simple point of a basic user:
2010/8/28
I think this is the logical error here from usage point of view. It is not the fact that they are "dockable" which means they should be grouped together. They should be grouped according to function.
If I want to hide a layer I should not need to think : "last time I did this what did it look like, what sort of GUI element was it that allowed me to hide a layer, was it dockable, where are dockables hidden?"
If I want to hide a layer , I go to the layers menu.
I find it strange anyone would argue against that.
The layers (dockable) dialog should never be hidden, every GIMP user guide says that. Thus for anybody following this idea, the real question is "If I want to hide a layer, I go to the layers dialog." Otherwise, it would be necessary to copy in the layers menu all the functionalities of the layers dialog, which means a lot.
Is this argument so strange?
(no subject) plus dockables
On Fri, 2010-08-27 at 07:32 +0200, Martin Nordholts wrote:
If I want a colour , I should find it on the colour menu . If I want to select layers I should fine the necessary interface elements on the layer menu.
Sounds reasonable. We could duplicate the menu items from the Dockables menu that raise/create those dialogs in the places where they belong. So we would have "Layers dialog" in the "Image/Layers" menu and the like. That's as simple as editing the XML files in the menus sub-directory. Perhaps someone wants to come up with a patch...
I don't think we should duplicate any menu items. Having things in two places tends to cause unnecessary confusion. A user will have to answer questions like "Why is this menu item in two places? Is it the same menu item? Does it do the same thing? Which one should I use now?" Having just one place to do things avoids such ambiguity and mental friction.
We do that for a few menu items already and I don't think it has ever
caused any problems. Some examples are (and there are many more):
Edit->Undo History
View->Navigation Window
Select->Selection Editor
Colors->Info->Histogram
Actually I think it's just an oversight that the Layers dialog is
missing from the Layers menu. IMO all dialogs should be accessible from
the menus where they belong to functionally. The "Dockables" menu is
just a place to list all the available dialogs. It should be secondary.
Sven
(no subject) plus dockables
On Fri, 2010-08-27 at 12:39 +0200, yahvuu wrote:
On 27.08.2010 07:32, Martin Nordholts wrote:
If people have troubles finding the Layers dockable, we should instead look into making it more discoverable, like adding a 'Dockables' top menu or moving them directly under 'Windows' instead of having a sub menu.
What about naming it the 'Dialogs' menu?
-- 'Dockables' sounds like implementation slang to me. And the 'Windows' menu becomes confusing in single-window-mode.
"Dialogs" is even more special than "Windows" and in single-window-mode it is at least as wrong as using the term "Windows". The "Windows" menu name on the other hand is pretty much default and used in many applications as a place to list all currently open windows. And that's the main use of it in GIMP as well. With the exception that we also list the dockables since we consider them something like sub-windows.
Making the Layers dialog discoverable under the 'Layers' menu and color dialogs below the 'Colors' menu etc.. makes a lot of sense, but IMHO that's the job of a 3.0 redesign -- there is a whole lot more to do than just releasing the dockables from their current hiding place and distributing them over the menu structure.
As I pointed out in another mail, most dialogs are already available in their respective menus. Completing this is not a major overhaul, it's a bug-fix.
Sven
(no subject) plus dockables
O Peter, Where Art Thou?
This is getting nasty quickly.
On 28.08.2010 20:13, Sven Neumann wrote:
On Fri, 2010-08-27 at 07:32 +0200, Martin Nordholts wrote:
If I want a colour , I should find it on the colour menu . If I want to select layers I should fine the necessary interface elements on the layer menu.
Sounds reasonable. We could duplicate the menu items from the Dockables menu that raise/create those dialogs in the places where they belong. So we would have "Layers dialog" in the "Image/Layers" menu and the like. That's as simple as editing the XML files in the menus sub-directory. Perhaps someone wants to come up with a patch...
I don't think we should duplicate any menu items. Having things in two places tends to cause unnecessary confusion. A user will have to answer questions like "Why is this menu item in two places? Is it the same menu item? Does it do the same thing? Which one should I use now?" Having just one place to do things avoids such ambiguity and mental friction.
We do that for a few menu items already and I don't think it has ever caused any problems. Some examples are (and there are many more):
Edit->Undo History View->Navigation Window
Select->Selection Editor
Colors->Info->HistogramActually I think it's just an oversight that the Layers dialog is missing from the Layers menu. IMO all dialogs should be accessible from the menus where they belong to functionally. The "Dockables" menu is just a place to list all the available dialogs. It should be secondary.
Another thing to note is that the 'Add Tab' entry from the dockable context menu provides a list of available dockables as well. I think i can explain why this additional option for dockable creation does not create much mental friction:
When i'm browsing the 'Layer' menu, i'm thinking of what can be done with layers. Here is the place to discover the layers dialog -- i can find it here even if i do not have prior knowledge that a layers dialog exists at all.
On the other hand, when adding a tab to an existing docbook using the 'Add Tab' menu, i'm configuring my workspace to better suit the task at hand -- that's a different kind of process than browsing for layer functionality.
Windows->Dockable Dialogs is literally in the middle of these two choices. Perhaps we can weasel out by proclaiming that this isn't a 'menu' but just a list of available dialogs and thus no decision has to be made about which menu to use... That is, paraphrasing what Sven said.
Also, interesting to note how differently the word 'dialog' gets perceived.
bye, yahvuu
(no subject) plus dockables
On 09/01/2010 12:45 PM, yahvuu wrote:
O Peter, Where Art Thou?
This is getting nasty quickly.On 28.08.2010 20:13, Sven Neumann wrote:
On Fri, 2010-08-27 at 07:32 +0200, Martin Nordholts wrote:
If I want a colour , I should find it on the colour menu . If I want to
select layers I should fine the necessary interface elements on the layer menu.Sounds reasonable. We could duplicate the menu items from the Dockables menu that raise/create those dialogs in the places where they belong. So
we would have "Layers dialog" in the "Image/Layers" menu and the like. That's as simple as editing the XML files in the menus sub-directory. Perhaps someone wants to come up with a patch...I don't think we should duplicate any menu items. Having things in two places tends to cause unnecessary confusion. A user will have to answer questions like "Why is this menu item in two places? Is it the same menu item? Does it do the same thing? Which one should I use now?" Having just one place to do things avoids such ambiguity and mental friction.
We do that for a few menu items already and I don't think it has ever caused any problems. Some examples are (and there are many more):
Edit->Undo History View->Navigation Window
Select->Selection Editor
Colors->Info->HistogramActually I think it's just an oversight that the Layers dialog is missing from the Layers menu. IMO all dialogs should be accessible from the menus where they belong to functionally. The "Dockables" menu is just a place to list all the available dialogs. It should be secondary.
Another thing to note is that the 'Add Tab' entry from the dockable context menu
provides a list of available dockables as well. I think i can explain why this
additional option for dockable creation does not create much mental friction:When i'm browsing the 'Layer' menu, i'm thinking of what can be done with layers.
Here is the place to discover the layers dialog -- i can find it here even if
i do not have prior knowledge that a layers dialog exists at all.On the other hand, when adding a tab to an existing docbook using the 'Add Tab' menu,
i'm configuring my workspace to better suit the task at hand -- that's a different
kind of process than browsing for layer functionality.Windows->Dockable Dialogs is literally in the middle of these two choices. Perhaps we can weasel out by proclaiming that this isn't a 'menu' but just a list of available dialogs and thus no decision has to be made about which menu to use... That is, paraphrasing what Sven said.
Your explanation makes sense, my reasoning was broken. I will try fix this for 2.8 (unless, of course, someone does it before me)
/ Martin