On Fri, Sep 18, 2009 at 9:26 PM, peter sikking wrote:
> hey guys,
> I have now blogged about the single-window mode:
> <http://www.mmiworks.net/eng/publications/2009/09/gimp-single-mode.html>

Peter, I'm afraid this is not going to work for a lot of users.

Let's start with a mission statement: a user should be able to a)
compare several images and b) have editing access to multiple ones.

To me your proposal fails here, in both tasks. Let's go into details:

Comparison. You solve the comparison task by introducing windows that
overlay actual content and duplicate existing views of same images.
What needs to be thought about here is that there are two reasons to
compare images, and your proposal deals more or less nicely with just
one of them:

1. Quick comparison, basic overview of differences between several of
images, usually up to four. This is where your proposal sort of works,
up to a point where there are too many polaroids around overlaying
your current image. Think about poor netbook users with 1024x600px
displays. Two polaroids is best what they can allow.

2. Detailed comparison, when you lock view of several similar images
and thus get synced navigation. Your proposal sort of deals with this,
but what it basically does is creating temporary view windows on top
of just one current image. What is wrong with that? The fact that
detailed comparison is often coupled with introducing gradual changes
to several images. So this is time for the b) part of the mission
statement: Editing access to multiple images.

Why is it important to have access to several images at once? Consider
a situation when you have two versions of a project you've been
working on, that is -- two image windows/views. And you need to add
elements from a couple of other projects to both of them. It looks
like this:

1. You have a source file(s) window(s) and two target projects.
2. You pick, say, a group of layers from it and transfer (let's omit
details for now) it to a different image.
3. You do the same for the second target project.
4. In both target project you aply a number of changes (like
reordering objects in layer stack, moving dropped objects around,
applying some filters, etc.)
5. You overview changes in both target project and decide whether you
need something else from the source project(s).
6. If you do, you repeat steps 2-5.

What is the fastest way to drag'n'drop stuff (paths, layers,
selections etc.) from one window to another? By having image windows
side by side. Why is the presumably optional (C)SDI not right for the

1. Because you don't always need that, so switching between (C)SDI and
MDI modes is tedious.
2. Because you don't always need that for *all* opened images, so when
you have five images opened and you need to see just two or three of
them at the same time, by switching to (C)SDI you end up with several
more images floating around that you don't really need right now.
3. Because in the upcoming new GUI using (C)SDI based UI means having
varios dialogs floating around, so you will have to manually resize
image windows to see both of them, which is, again, tedious.

You could say "Hey, then let's just drag'n'drop stuff to polaroids!".
But then you will still not have the editing functions available. So
why introducing polaroids that overlay actual content and do not allow
to edit content they display? If not polaroids, then what could be
done instead?

Custom tiling of images. The space inside working area should become a
container that can have both groups of tabs and tiles. You can drag an
inactive image using by its tab caption to either of the side of the
currently visible image, and they two will share tiled part of the
container. Then you can add another one. Each tile would have a sort
of draggable caption to help you distinguish one tile from another, so
if you don't need that image window anymore you just pick it and drag
back to the group of tabs, and the container would refit the rest of
the tiles.

Why is it better than the proposed solution?

1. Solves the need to view as many images as you need without adding
overlay clutter.
2. Solves the need to have a fast editing access to multiple images.
3. It's flexible - it's up to users how exactly they organize images
in their working environment.

There is a number of things to be thought here like exact method of
focusing between tiles (sloppy focus won't work, I guess), especially
re. drag'n'drop, but pretty please think about tiling.

For developers: CurlyAnkles gtk+ lib has tab/tile widgets I'm talking
about: URL.

Not that I'm suggesting to reuse it, but at least it demonstrates the
kind of flexibility I mean.

However I agree that the proposed polariod widget would help with
viewing same image in different zoom.

Now, as for the "filmstrip", it's quite okay, but I'd mention just one
thing here. It really would make sense to display basic metadata
there, e.g. title of an image. Because when all you see is a (even
large) preview of a 14 Mpx multilayered image and a very similar one
next to it, you can't alwyas say which one you need exactly.
Especially when it wasn't you who created the images and thus naming
of files isn't obvious to you. Whereas metadata can have that
information for you.

P.S. I do know that it's much easier to be a smartass (like me) than a
UI architect (like you) :)

Gimp-developer mailing list

Reply via email to