Hi,

On Mon, 2008-02-04 at 01:35 +0100, peter sikking wrote:

and oh, note that the slider to set the alpha of what goes on in that window will be there anyway...

This is not currently implementable, so I would rather not base the spec on this opacity slider.

I also very much wonder why the window should have something as useless as a slider to control the visual appearance but lack any useful widgets to give people quick access to the things they will most likely do next. What's wrong about a link to the recently used images and to the New image dialog?

Sven

Hi,

On Mon, 2008-02-04 at 01:35 +0100, peter sikking wrote:

4) a plugin system for this window; we ship a standard, good one like above. If somebody really insists he or she wants to see a file open dialog every time or the 10 last edited pictures (both not very good ideas to force upon one million users) then let them write a plugin to do that.

We certainly don't have so much developer time at hand to design, implement and maintain a plug-in system to add gimmicks to this window. We absolutely need to find a solution here that works for everyone. Delegating this question to a plug-in system is not going to work here.

Sven

On Mon, 2008-02-04 at 09:01 +0100, Sven Neumann wrote:

I also very much wonder why the window should have something as useless as a slider to control the visual appearance but lack any useful widgets to give people quick access to the things they will most likely do next. What's wrong about a link to the recently used images and to the New image dialog?

Same here.

I think such a slider would be a waste of both developer and user time (a _million_ users wondering: ooh, what does this slider do? ... to never touch it again ;)

Reasons against having Recent/New in the window: - "visual noise"
- both are in the file menu already and duplication would lessen consistency in interaction / work against habituation.

But then I would prefer a window as narrow as possible, not much more than just a title and a menu bar. Any image would get old soon and putting effort into exchanging it frequently would be wasted.

Reasons for having Recent/New in the window: - fast access to the only 2 things a user might want to do (well, there's also accessing preferences)
- avoiding a mostly empty window which will trigger uncountable complaints through all eternity ;)

The audio application Ardour has a startup dialog with New and Open Recent tabs. The dialog has its issues, but feels very useful. I never use a file manager to open a project there. For GIMP, it should be possible to have New and Recent side by side.

On Mon, 2008-02-04 at 10:48 +0100, peter sikking wrote:

the slider is a dead serious key in the whole experience. to seamlessly track the mood of users over a a working day (or a hobby night) is worth gold in user interaction.

You seem to assume that
- users will adjust the slider repeatedly - this adjustment somehow reflects their mood (not just lighting conditions from day to night or whatever)

I mean to recall that the product vision stresses serious, professional level work. I don't see how playing with such a slider is compatible with a getting-stuff-done mentality. I very strongly doubt that users would adjust it repeatedly, anyway.

Then, even if they do: what does it tell us about their mood and what would we do with that information?

the thing to focus here is that GIMP is not going to behave like some
kid
yelling (yep, that is what a dialog is): "that was fun, what are we going
to do now... I mean now... really now!"

as long as we understand that, you will be able to understand the crucial decisions that I take here.

I fail to see how a full size window that is basically empty regarding its informational and interaction aspects could be a good thing. It manages to cover part of the desktop or other windows and distracts from the then only useful bit, the menu. Seen this way, your wallpaper window would yell, too, but it'd be: "BLAH!"

The opposite side of "what are we going to do now" would be "see how you get along, I will not raise a finger to help you".

I get the sensation that often most trivial solution are overlooked, only because are trivial, even if simple things often work better

Users, ( i state as users not as expert of usability) just are used to see graphic sw open with a image windows...i don't thing they will appreciate a special image windows with sliders or peculiar setting.

They will appreciate something trivial as gimp opening with a image windows, inside simply a new image,color white, type RGBA, of a default size (something as 600x600 should fit, aside to the toolbox in most of computer screen ,included little as 800x600)

That and , for the first time only, a dialog popped up prompting

1 to accept that size or
1 to reset that default size as from users wish

OR

3 instead then a blank image start with the last image opened

And a short info at end of dialog....if the user want change again that default, he may do from Toolbox/preference.

That in my opinion and experience as users will solve at best

Honestly i can't image any advantage, or anything useful, or even "funny" in that proposed additional Transparency slider .

On the contrary i see a related usability problem, if something as that will be done:

Users will think that the slider effect may is also rendered in the saved image

More if they will forget to reset the slider, they will be easy misleaded.by a effect that is visible, but will be never rendered, (if not by a screenshoot)

Alchemie Foto\grafiche
---------------------------------

--------------------------------- L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail

The "no image window" should have a status line, as this provides useful feedback with regard to the hover-over hints of the menu commands.

Actually, if "plug-in" means something like a fill pattern that could be user-specified in the same way as the splash screen, I think it would be possible to implement everything Peter has specified here -- including the opacity slider -- using the "scratch image" framework I've been experimenting with.

There is one aspect of this specification that seems problematic to me, though. If the user closes the final image by clicking the "X" in the upper right corner of the window, we must close that window or we violate a fundamental rule of window handling. We can create a new window if we feel the need to, but we must close the original window.

-- Bill

Hi,

On Mon, 2008-02-04 at 10:48 +0100, peter sikking wrote:

just to clarify: are you assuming that the whole window will become transparent and the desktop shines through?

No. That would be implementable as there's GTK+ API to do that (though not supported on all platforms).

I am talking about
making some stuff transparent against a window background, hardly rocket science for GIMP...

There's no GTK+ API to do this (yet). Of course if all we have in the window is a background image, then we could make the window background shine through. But I still assume that we will have some useful content in the window. Useful content means GTK+ widgets. And we can't (yet) make GTK+ widgets translucent.

Even if this was possible, I still fail to see why this would be useful. To be honest, I am completely baffled to hear such a thing proposed from a user interface professional. What exactly, except for eye candy, is the purpose of this?

the slider is a dead serious key in the whole experience. to seamlessly track the mood of users over a a working day (or a hobby night) is worth gold in user interaction.

Would you please care to explain this?

Sven

On Feb 4, 2008 11:14 PM, Sven Neumann wrote:

in the window. Useful content means GTK+ widgets. And we can't (yet) make GTK+ widgets translucent.

Are you 100% sure?

http://www.breakitdownblog.com/gnome-murrine-theme-gets-transparent-widgets/

Alexandre

peter sikking wrote:

Alexandre wrote:

And we can't (yet) make GTK+ widgets translucent.

Are you 100% sure?

http://www.breakitdownblog.com/gnome-murrine-theme-gets-transparent- widgets/

that is cool (but not for this UI design). I would like to know how universally (all linux WMs, windoze, OS-X) that can be rolled out...

Sorry, but what is the use case for transparent image window? It is rather contrary to the idea of the dark room. The only thing I can imagine is a "lazy" :) user who doesn't want to make a screenshot of a window of some other program and put it to a new lower layer to be used as some base background.

On Feb 5, 2008 1:26 PM, peter sikking wrote:

And we can't (yet) make GTK+ widgets translucent.

Are you 100% sure?

http://www.breakitdownblog.com/gnome-murrine-theme-gets-transparent- widgets/

that is cool (but not for this UI design). I would like to know how universally (all linux WMs, windoze, OS-X) that can be rolled out...

Murrine's developer writes in his blog: "Then you need... a composite capable window-manager, like Compiz, future Metacity etc etc…"

I'm not quite sure about usefulness of transparence in a graphics editor (unless it's transparence of layers/selections/objects in a drawing). Sounds like distraction to me (and yes - I remember your argument on Aperture :-))

Alexandre

Alexandre,

What Peter describes does not involve transparent windows. I agree it does not seem useful, in sense of literal opacity.. Rather, a waterlevel-type adjustment could suit this idea better..with widgets appearing or disappearing according to whether they are above waterlevel. It's important in this case that disappearance or appearance should not change widget positions or sizes-- the widgets should not be repacked after the initial packing..

(well, we could consider, if needed, more specific instances of a general kind of action that could, at one level, have a widget for the general operation, and then as the waterlevel drops, be replaced in the same space by several widgets that are the more specific instances.)

On Feb 5, 2008 9:17 PM, Alexandre Prokoudine wrote:

On Feb 5, 2008 1:26 PM, peter sikking wrote:

And we can't (yet) make GTK+ widgets translucent.

Are you 100% sure?

http://www.breakitdownblog.com/gnome-murrine-theme-gets-transparent- widgets/

that is cool (but not for this UI design). I would like to know how universally (all linux WMs, windoze, OS-X) that can be rolled out...

Murrine's developer writes in his blog: "Then you need... a composite capable window-manager, like Compiz, future Metacity etc etc…"

I'm not quite sure about usefulness of transparence in a graphics editor (unless it's transparence of layers/selections/objects in a drawing). Sounds like distraction to me (and yes - I remember your argument on Aperture :-))

Alexandre

Hi,

On Tue, 2008-02-05 at 12:07 +0300, Alexandre Prokoudine wrote:

in the window. Useful content means GTK+ widgets. And we can't (yet) make GTK+ widgets translucent.

Are you 100% sure?

http://www.breakitdownblog.com/gnome-murrine-theme-gets-transparent-widgets/

Yes, I am. What your links shows is something entirely different.

Sven

Am Dienstag, den 05.02.2008, 11:26 +0100 schrieb peter sikking:

GIMPsters,

Let me state that I wrote my first email in this thread because (yes) I am struggling what to put there. It is easy for me to make the list of gimmicks that not should go in there. Every on of those sucks so much... But what is left? The window needs to be there, already outlined above the functions it does. So instead of just plain bgcolor, let's do something a bit more stylish, without drawing any attention to it.

I thought about it and I created this mock-up: http://hagemaenner.de/stuff/gimp/PlanB/6.png

The idea is to use a simple radial gradient from the upper left corner to the lower right. (This should be switched for RTL languages.)

The gradient colours are calculated from the "selected forecolour" from the GTK theme. This way it fits nicely into every desktop environment.

In the center of the area I've added a simpel text "Drop Images here to open them." (Perhaps a native speaker should change the wording.) This is NOT the "Tip of the Day" and should NOT change. The colour of the text is the brightest colour from the gradient. This will give us a nice contrast and it will fit to the theme colours.

the slider is a dead serious key in the whole experience. to seamlessly
track the mood of users over a a working day (or a hobby night) is worth gold in user interaction.

Would you please care to explain this?

I am going to let the slider rest until the window content is sorted out.
Then redesign the whole package so it all fits together...

I don't get you slider idea. But if you think about a small timewaster what do you think about adding a colour slider to my mock-up?

Regards, Tobias

Hi Tobias,

I like the simple, functional design of this. Do you know, has what the toolbox would become, already been resolved? I notice this does not seem to concern people presently.

On Feb 8, 2008 9:01 AM, Tobias Jakobs wrote:

Am Dienstag, den 05.02.2008, 11:26 +0100 schrieb peter sikking:

GIMPsters,

Let me state that I wrote my first email in this thread because (yes) I am struggling what to put there. It is easy for me to make the list of gimmicks that not should go in there. Every on of those sucks so much... But what is left? The window needs to be there, already outlined above the functions it does. So instead of just plain bgcolor, let's do something a bit more stylish, without drawing any attention to it.

I thought about it and I created this mock-up: http://hagemaenner.de/stuff/gimp/PlanB/6.png

The idea is to use a simple radial gradient from the upper left corner to the lower right. (This should be switched for RTL languages.)

The gradient colours are calculated from the "selected forecolour" from the GTK theme. This way it fits nicely into every desktop environment.

In the center of the area I've added a simpel text "Drop Images here to open them." (Perhaps a native speaker should change the wording.) This is NOT the "Tip of the Day" and should NOT change. The colour of the text is the brightest colour from the gradient. This will give us a nice contrast and it will fit to the theme colours.

the slider is a dead serious key in the whole experience. to seamlessly
track the mood of users over a a working day (or a hobby night) is worth gold in user interaction.

Would you please care to explain this?

I am going to let the slider rest until the window content is sorted out.
Then redesign the whole package so it all fits together...

I don't get you slider idea. But if you think about a small timewaster what do you think about adding a colour slider to my mock-up?

Regards, Tobias

I thought about it and I created this mock-up: http://hagemaenner.de/stuff/gimp/PlanB/6.png

In the center of the area I've added a simpel text "Drop Images here to
open them." (Perhaps a native speaker should change the wording.)

I really like this image. I think what could make it really good is adding to it a toolbar with "new" and "open" buttons at its top. I understand Peter when he says having the "new image" and "open document" displayed prominently can get annoying, however having it as icons in a toolbar like in most applications do would be a good compromise in my opinion

On Fri, 2008-02-08 at 19:12 +0100, peter sikking wrote:

Tobias Jakobs wrote:

I thought about it and I created this mock-up: http://hagemaenner.de/stuff/gimp/PlanB/6.png

[...]

I have been moving in the same direction in the last days.

If the main function of the window 'body' under the menu bar is to have a nice size drag + drop area, let's on its look + feel for that. As for the size of this window: just wide enough to fit the menubar for the running localisation,height of the window, 1/4 or 1/3rd of the width, some nice proportion.

Perhaps it could contain an icon for each active image, so that left-clicking on the image would bring the image window and any associated pallettes or whatever to the front, and right-clicking (or the reverse for left-handed people) would give an image-specifc context menu as one would expect, either with "close, save a copy, save as, revert, properties" or the same menu as clicking on the image.

If you make the area useful (drop an image...) and then when the image is dropped, that area and message are replaced by the image, it's no longer clear how to open a second image. The obvious way would be to drop it in the same place, but that wouldn't work, it would add a layer.

So then you need a visible drop target...

One solution would be that opening an image makes also a new empty image window to drop things in but that's absurd.

Another (better I think) would be to have a drop target pallette area/window, that could be docked.

None of this really helps the "window with no image for beginners" question though.

Liam

Sorry if I'm too late with this reply, but I just came back from my vacations.
A couple of months ago I studied this issue and proposed a mockup of an introductory window for using when no image is open. http://www.blog.ohweb.com.ar/?p=59
Sven explained some of the technical problems of this approach, but since the discussion is opened again and there are new ideas, I'd like to bring this mockup back for your consideration. I hope you find something useful in it.

Regards, Gez.

Oh... the "no gimmicks" thing.
Nevermind then...

Gez.

Anyway, I'd would like to know why common tasks wouldn't fit there (apart of the usual "it sucks").
"Create a new image", "open an existing image" and "open a recent file" are the first things people do with gimp. So why not? I use drag and drop to open files, but I wouldn't put "new image" and "open recent" as secondary commands, available only via a menu. Those three actions share the same hierarchy, imo.

And finally... a "drag here" sign sounds as a gimmick too for me.

Hi,

On Sun, 2008-02-17 at 05:13 -0200, Guillermo Espertino wrote:

Anyway, I'd would like to know why common tasks wouldn't fit there

Yeah, I would also like to know that.

And finally... a "drag here" sign sounds as a gimmick too for me.

Indeed. In particular since we already found that using this window as a DND target has a severe usability problem. Where do you drop images when there is already an image opened?

Sven

On Feb 18, 2008 8:27 AM, Sven Neumann wrote:

Hi,

On Sun, 2008-02-17 at 05:13 -0200, Guillermo Espertino wrote:

Anyway, I'd would like to know why common tasks wouldn't fit there

Yeah, I would also like to know that.

I thin peter explained i in one of the first mails:

"the thing to focus here is that GIMP is not going to behave like some kid yelling (yep, that is what a dialog is): "that was fun, what are we going to do now... I mean now... really now!" "

You can see the problem very good, if you start Krita. Krita has such a yelling start dialog. But I'm not sure if not having common tasks in the start window is the solution or if we just have to design it more carefully than Krita.

And finally... a "drag here" sign sounds as a gimmick too for me.

Indeed. In particular since we already found that using this window as a DND target has a severe usability problem. Where do you drop images when there is already an image opened?

If you see the window as a DND target has a severe usability problem every other thing in this window will have the same problem after opening the first image. This puts us back to an empty window without any functionality. And that doesn't sounds like a good solution, too.

I've made some mock-ups and I like nr. 5c (with common tasks, like Gez one) and nr. 6 (DND area). I definitive don't like the nr. 4 (without any functionality). But this is just the look and not the feel. http://www.hagemaenner.de/stuff/gimp/PlanB/5c.png http://www.hagemaenner.de/stuff/gimp/PlanB/6.png http://www.hagemaenner.de/stuff/gimp/PlanB/4.png

Regards, Tobias

Hi,

On Mon, 2008-02-18 at 12:21 +0100, Tobias Jakobs wrote:

You can see the problem very good, if you start Krita. Krita has such a yelling start dialog. But I'm not sure if not having common tasks in the start window is the solution or if we just have to design it more carefully than Krita.

I don't know the Krita start dialog, but I have seen the mockup that Guillermo has drawn and it doesn't seem to yell at me. Perhaps it could benefit from a little less content, but overall it looks like a very nice mockup and it provides exactly the functionality that the user needs at this point.

Sven

Hi,

On Mon, 2008-02-18 at 14:54 +0100, peter sikking wrote:

Our core users are people who know what they are doing. They do not need 'help'.

Yes, they do. This dialog is the first thing people see when starting GIMP. And a large fraction of our users are beginners. So we have a good chance hear to give them a helping hand. If we don't do that, this will most likely be the last time they ever used GIMP.

"we already found that using this window as a DND target has a severe usability problem"

who found that in what usability test? I must have missed that.

You missed one of the mails in this thread then. If we use this window as a DND target, where should our users drop images when it is not there? That looks like a severe usability problem to me and I don't think we need run any tests to see this.

Sven

Hi,

On Tue, 2008-02-19 at 19:46 +0100, peter sikking wrote:

Just like Sven or Mitch cut the crap when users keep discussing things that are technically not possible, I have to cut the crap when we keep discussing interaction that simply does not make sense.

OK. As long as the result is something that doesn't look like crap and also appeals to new and occasional users.

I think the remaining question is: when GIMP is not the foreground application (toolbox and inspectors hidden, as they should) where can users d+d files apart from on the taskbar icon?

This sounds a lot like the solution will be a lot more complex than the intermediate that can be implemented for 2.6. Anything that requires complex interaction with the window manager might take years to implement as we would most likely have to push quite some changes into GTK+ and/or get the EWMH specification changed.

Sven

peter sikking said on Feb 19, 2008 13:46 -0500 (in part):

You missed one of the mails in this thread then. If we use this window

as a DND target, where should our users drop images when it is not there?

I think the remaining question is: when GIMP is not the foreground application (toolbox and inspectors hidden, as they should) where can users d+d files apart from on the taskbar icon?

I have Windows only experience (not Linux or Mac) so maybe I'm missing something here ...

In Windows D'n'D, for a non-visible application works "everywhere" as drag to taskbar button which brings that application to foreground. User (still w/o releasing mouse button) then drags to to window which has just been brought to foreground and releases.

This works now with current Gimp whether there is an image open or not so long as the first bring to foreground is done to the Gimp toolbox window.

So wrt. remaining question: "where can users d+d files apart from on the taskbar icon?" . Why is there any need for anything else? That's how Windows user expect ALL applications to behave.

Regards ... Alec -- buralex-gmail

On Feb 20, 2008 11:07 AM, wrote:

peter sikking said on Feb 19, 2008 13:46 -0500 (in part):

You missed one of the mails in this thread then. If we use this window

as a DND target, where should our users drop images when it is not there?

I think the remaining question is: when GIMP is not the foreground application (toolbox and inspectors hidden, as they should) where can users d+d files apart from on the taskbar icon? I have Windows only experience (not Linux or Mac) so maybe I'm missing something here ...

In Windows D'n'D, for a non-visible application works "everywhere" as drag to taskbar button which brings that application to foreground. User (still w/o releasing mouse button) then drags to to window which has just been brought to foreground and releases.

This works now with current Gimp whether there is an image open or not so long as the first bring to foreground is done to the Gimp toolbox window.

So wrt. remaining question: "where can users d+d files apart from on the taskbar icon?" . Why is there any need for anything else? That's how Windows user expect ALL applications to behave. Regards ... Alec -- buralex-gmail

There is no guarantee that there will be any taskbar at all. On linux, there are plenty of WM's that either provide a taskbar that is not suitable to implement your described behaviour, or no taskbar at all ( i use one of these myself, DWM (http://www.suckless.org/wiki/dwm)). IMO taskbars are a kludge, and it is a mistake for an application to *depend* on them for basic usability.

Hi,

On Wed, 2008-02-20 at 11:34 +1030, David Gowers wrote:

There is no guarantee that there will be any taskbar at all. On linux, there are plenty of WM's that either provide a taskbar that is not suitable to implement your described behaviour, or no taskbar at all ( i use one of these myself, DWM (http://www.suckless.org/wiki/dwm)). IMO taskbars are a kludge, and it is a mistake for an application to *depend* on them for basic usability.

I don't think opening an image per DND counts as basic functionality. If you are working on a desktop that doesn't provide basic functionality like some sort of taskbar, then you may miss a feature or two. No problem as long as you can still open an image somehow.

Sven

On Wed, Feb 20, 2008 at 7:45 PM, Sven Neumann wrote:

On Wed, 2008-02-20 at 11:34 +1030, David Gowers wrote:

There is no guarantee that there will be any taskbar at all.

IMO taskbars are a kludge, and it is a mistake for an application to *depend* on them for basic usability.

I don't think opening an image per DND counts as basic functionality. If you are working on a desktop that doesn't provide basic functionality like some sort of taskbar, then you may miss a feature or two. No problem as long as you can still open an image somehow.

Completely agree. GIMP need not worry too much about this. If you still want a place to DND in this situation, you can always write a simple but separate app that gives just a DND basket like d4x or kget gives. For whatever is dropped on it, you can always call gimp's remote. Heck! you can even make it intelligent and open the app you want based on different criteria! But that is enough said on GIMP's list. :-)

On Wed, 2008-02-20 at 11:34 +1030, David Gowers wrote:

There is no guarantee that there will be any taskbar at all. On linux, there are plenty of WM's that either provide a taskbar that is not suitable to implement your described behaviour, or no taskbar at all ( i use one of these myself, DWM (http://www.suckless.org/wiki/dwm)). IMO taskbars are a kludge, and it is a mistake for an application to *depend* on them for basic usability.

To quote from that "Window Manager's" web page:

"Because dwm is customized through editing its source code, it's pointless to
make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions."

I think you just disqualified yourself to say anything about usability here.

ciao,
--mitch

On Thu, Feb 21, 2008 at 10:12 PM, Michael Natterer wrote:

On Wed, 2008-02-20 at 11:34 +1030, David Gowers wrote:

There is no guarantee that there will be any taskbar at all. On linux,

> there are plenty of WM's that either provide a taskbar that is not > suitable to implement your described behaviour, or no taskbar at all ( > i use one of these myself, DWM (http://www.suckless.org/wiki/dwm)). > IMO taskbars are a kludge, and it is a mistake for an application to > *depend* on them for basic usability.

To quote from that "Window Manager's" web page:

"Because dwm is customized through editing its source code, it's pointless to
make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions."

I think you just disqualified yourself to say anything about usability here.

That's a straw man. There are many tiling WM's, and only two of them are written by Anselm Garbe. It's quite common for tiling WMs (eg. dwm, Ion, wmii, ratpoison, stumpwm) to not have taskbars, because they are simply unnecessary when you can see the current windows at a glance. Mainstream WM's are a window management nightmare -- by which I mean the user is constantly being called on to manage windows, to make decisions that could in most instances be made well by the computer, and the need for a task bar in such WM's just reflects this basic demand for micromanagement imposed by an overconfigurable concept of window management. It's not bad that the user can configure their WM, or even their windows -- they should only rarely be called on to configure their windows, since it's perfectly possible to treat the majority of windows in a way that Just Works.

In short -- taskbars save you some of the time that your WM otherwise calls upon you to waste.