guys + gals,

for all of you who missed our presentation at the lgm, I have converted the talk into blog entries.

The first part (of three) is online now:

ps Alexandre Prokoudine: you can link to these as the definitive report of our presentation.

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Sven wrote:

for all of you who missed our presentation at the lgm, I have converted the talk into blog entries.

Thanks a lot. To give this a wider audience, perhaps you should ask Mukund to add your blog (or just a feed with GIMP related posts) to http://graphicsplanet.org/.

I already have the blogger label in place:

http://www.mmiworks.net/eng/publications/labels/GIMP.html

but there is no rss for it.

I'll ask Mukund when he gets back from travelling.

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

guys + gals,

part two of three of our lgm presentation is online:

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Thorsten wrote:

10. better printing support

Paper, maybe better called media, could be handled as special kind of layer that is restricted to stay below all image layers (unless hiding stuff below it makes any sense).

Think workflow, not about highjacking a image concept (layers):

_putting_ it on paper will be handled as a dedicated workflow.

It looks logical to reuse the main window for that, to reuse all that space, looks logical to us.

But paper alone is not a sufficient model, I fear. There's the thing you print on and the final product (after cutting, perhaps) ... PDF has this media/crop/trim/bleed/art box model. Scary stuff ;) http://bugs.scribus.net/view.php?id=1041 Better written, but german: http://www.dtp-praxis.de/tipps/ pdfboxen.htm

Wow scribus, a pre-press oriented (that is their product vision) dtp app.
GIMP's ambitions to not reach that far.

The essence of working on the user interaction level is to concentrate on what in GIMP will enable the user to deliver artistic results, and to handle all that technical gobbledegook in the code.

7. save for web

Should include indexing for GIF (mandatory) and PNG (optional). If one needs to create a number of images in indexed colour mode that share some colours and where deviations are not acceptable, there should be an alternative to indexing them all as one image to then cut them apart.

I would really measure this static-indexed requirement against the product vision before throwing in yaUIc (yet another UI complication).

And why are we talking teensy little details here when the presentation and blog entry was about solutions models: the general direction forward?

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Thorsten wrote:

10. better printing support

Paper, maybe better called media, could be handled as special kind of
layer that is restricted to stay below all image layers (unless hiding
stuff below it makes any sense).

Think workflow, not about highjacking a image concept (layers):

I thought I did. Think about workflow.

Then how do you end up selecting an intra-image concept (layers) to support the task of putting the actual image itself on another medium (paper)?

If you concentrate on understanding the task, then thinking about layers feels wrong within a second, and you can move on to solve the problem in another way.

But paper alone is not a sufficient model, I fear. There's the thing you print on and the final product (after cutting, perhaps) ... PDF has this media/crop/trim/bleed/art box model. Scary stuff ;) http://bugs.scribus.net/view.php?id=1041 Better written, but german: http://www.dtp-praxis.de/tipps/ pdfboxen.htm

Wow scribus, a pre-press oriented (that is their product vision) dtp app.
GIMP's ambitions to not reach that far.

The nature of Scribus is not of interest here, Ther just happens to be an english language description of the terms in their bug tracker.

The different nature of scribus is of interest here, because its users that fit their product vision (pre-press) need awareness of this technical pdf stuff.

It doesn't matter if you deal with complex page layouts or "just images".
It also doesn't matter much whether you target your desktop printer or a larger machine. The issues of media size, printable area, bleed and desired final size are just there.

All those concepts fall within GIMP users' awareness and are actually named in the blog entry as interrelated textfields that support the placement. But they will be handled in the UI in a way that gets artistic results done, and not in technical pdf file format terms.

And why are we talking teensy little details here when the presentation
and blog entry was about solutions models: the general direction forward?

It doesn't look to me like there is anything to discuss about your solutions model. I would mean this in a bad way if it didn't look like you know what you are doing there and if what I read didn't seem all agreeable.

What I mean to say is: can you see that all this detail stuff does not really matter at this moment, unless one of these details invalidates the overall concept?

This is the way to cut through the jungle of small details, and to concentrate on major problems that need to be solved first.

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Saul wrote:

Quoting peter sikking's weblog:
(http://www.mmiworks.net/eng/publications/2007/05/lgm-gimp-project- overview.html)

"ALSO NOT PAINTER the focus for GIMP is to work with ‘found’ images;"

I do not understand the reason for this restriction. Myself, I am not a painter. I do not use the GIMP for painting but I recognize that there are many who do.

"having a vision means saying no." --Steve Jobs

There is no obligation for GIMP to come to the rescue of every pixel pusher under linux. And if there are enough desperate painters out there who want really oil/water/finger paint in GIMP, then they can get _their_ act together and have some plugins written.

There is a long, hard road ahead of the GIMP team to get the product vision implemented by core GIMP.

It seems such a short stretch for the GIMP to extend its already powerful paintbox toolset to incorporate other painting concepts that I fail to see why development in this direction should not be encouraged.

If you going to support it, you have to support it well.

To give you an idea how this works out in user interaction terms, imagine that for supporting natural painting, or website mock-ups or page layout, an extra leg has to be sewn on the GIMP.

The GIMP will walk better and better, which each extra leg, no?

(sorry Sven, for using _the_ GIMP).

On a similar note, I wish to express a related concern with another category of "user" who, in my opinion, is not being sufficiently addressed in the current focus on user interface design: the developer.

These are the makers of software.

This is the difference between the coolness of making movies, compared to just going to the movies.

In the Free Software universe, the most important users of software are the ones who contribute to the project; whether through documentation, language translation, meaningful bug reporting, or actual programming. It would seem that minimizing the demands on potential contributors should be a major focus of proposed changes in the GIMP's "user" interface

Then I would like you to tell me how to make life easier for my fellow GIMP team members.

then Valerie wrote:

Well, I'm among those who would like to use GIMP for painting, and I have
tried in the past. But having seen that blog recently, I can accept that
the developers would like to concentrate their efforts in a particular direction, so recently I've been looking to other open source programs such as Inkscape instead. They have limited resources as is, so you can't
blame them to want to do one thing Well, even if it means setting aside
others for now.

I think the best alternative as a result would be to create a separate,
painting program, based on Gimp, but with more emphasis on painting options and less on filters and tools mostly used for photo manipulation.
Maybe it could incorporate Martin Renold's Mypaint and Levien's Wet Dream
for example.

So an Open Source painting program would center around things different
than a photo manipulation program.

I could not agree more with Valerie. There is a 'marketplace' for a painter-like application under linux. And also from a user interaction perspective a new application would be much easier to totally optimise for your painting user experience.

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

guys + gals,

the final part of our lgm presentation is now online.

whew, that turned out to be a long post to write, more pictures than ever:

ps: I am enjoying the feedback I am receiving, here and in the blog comments.

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Sven,

On Fri, 2007-05-25 at 02:15 +0200, peter sikking wrote:

BTW, the dialogs that you consider to be "unnecessary" can already be skipped using the Shift key.

Then the perfect solution is that we reverse the logic of that shift key. Only with the shift key down the dialog is shown.

Our users will be eternally grateful...

Sure, perhaps not the most intuitive and discoverable approach, but it works well for our power users.

Like I said, there is no such thing as intuitive >^}

And
sometimes the dialogs are not that unnecessary at all. So we can't just
remove them. At least not all of them.

After the provocative statements that needed to go in the lgm talk, I will be incredibly careful about recommending removing any of these.

But if like with the layers dialog, I see zero function 99% of the time, then I want us to try this out in an early (2.odd.2) development version,
wait a month (learning period) and then evaluate if that was the right choice.

Some UI streamlining is definitely needed, but the solutions aren't necessarily as simple as you put them. Actually a lot of what you say in
your blog entry is well-known and there are bug reports for it already:

http://bugzilla.gnome.org/show_bug.cgi?id=85579 http://bugzilla.gnome.org/show_bug.cgi?id=109929 http://bugzilla.gnome.org/show_bug.cgi?id=121087

These things are on our TODO for quite a while now. The problem is that
they are very difficult to implement.

Yes, the top-10 user request shows that on the user side there is a demand for change. And that the developers are thinking of the same things will only make it easier for us to go ahead and work together in the same direction.

But because of the work my team of usability and interaction professionals has put into this project since October the status of the issues we are talking about has changed.

Now they are no longer 'anybody's guess', they are official.

And my team is there to work with the developers to find solutions that can be realised, not pie in the sky. We are also there to make sure that our dear developer resources are not wasted on purely cosmetic UI makeover, and to make sure that the described productivity stoppers do not get shelved as an enhancement, but are treated as the GIMP-value reducers they are.

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Thorsten wrote:

On 4. better painting tools:

So you propose to have brush models in tools like dodge/burn. Why would this be preferable to having modes like dodge/burn inside brush tools?

because dodge/burn matches users' goal as a primary selector, and because within that certain task (brighten/darken) the image content dictates which brush model work best in a certain part. So main mode = dodge/burn, sub-mode = switch through the brush models fits that best.

Maybe brush model and mode should be handled separately?

A: The region/scope to work on - whole image
- a layer/group/set
- a selection
- brush strokes as they happen
B: Options for above
- mainly brush model with parameters comes to mind C: The action or drawing mode to apply - transformations
- filters
- paint

the whole puzzle is about decomposing ortogonal modes, and then flattening these multidimensional tool spaces again. Our only guide can be here the graphics concepts our product vision users think in.

On power modes

Sounds like a rather vague distinction, makes me wonder if is such a good idea to split the modes based on it. Shouldn't layer and paint modes be kept the same?

Not necessary to keep both the same. With the brush tools you have this opportunity to take out the modes with natural descriptions (vs. mathematical) and make unhide it out of these modes and integrate into an existing or new brush tool, that matches a user goal directly.

no such chance for layer modes.

dipping and smearing

Considering GIMP is not and shall not be painter ... but this would be very nice especially for drawing from scratch ;)

fine with me. but you can see how this solution came about, straight from the product vision, via the user scenarios.

Regarding adjustment layers and GEGL

GEGL is graph based, somewhat comparable to the nodes in Blender, right? If so, the concept of a layer stack does not match GEGL. I would propose to go all nodes and have no layers, if the layer stack wouldn't match the common case so nicely.

I was very happy when I reached a consensus with pippin and mitch on hat the GEGL graph is an internal technical representation that is not exposed in the UI. Maybe, only, to the developing users who use GIMP as stated in the third point of the product vision:

"GIMP is a platform for programming cutting-edge image processing algorithms, by scientists and artists;"

So yes, the graph is more flexible than a image->layers->operation history
structure. But I am convinced that the latter will help users more in getting the job done.

On window management

I have been thinking: What if GIMP was represented by a window with just the main menu. Image windows could be dockable palettes. Requires docking side-by-side. For SDI style, one would dock one image window and the inspectors all to the main window. Several images could docked together to have tabs.

Although I will have to push the boundaries of the look + feel guidelines every once and a while, I do prefer to stay 90% within the law. It does not hurt to go far out for an hour, but after applying some sane laws like "the menu bar sits at the top of the main window, on linux and windows," I am mostly back where I am in the last blog entry.

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Sven Neumann wrote:

On Fri, 2007-05-25 at 19:03 +0200, peter sikking wrote:

BTW, the dialogs that you consider to be "unnecessary" can already be
skipped using the Shift key.

Then the perfect solution is that we reverse the logic of that shift key. Only with the shift key down the dialog is shown.

Our users will be eternally grateful...

Oh come on, you are really making things simpler than they are.

that is because from the perspective of my profession and after the systematic effort put into evaluating this, it is really clear that doing this benefits GIMP.

Either a
dialog is really redundant, then it should be removed. Or a dialog is useful and even necessary for certain important tasks.

I found 'reversing the shift key' a beautiful solution because the dialog already exists and GIMP is full (rightly so) of these power features.

It fits the interaction principle that straight ahead user concepts (new layer) have a straight ahead UI.

Then we can not
only make it available by pressing some obscure modifier key. It would be more or less undiscoverable and we had effectively removed an important feature.

The choice it to make either the dialog or 'no dialog' a tricky power feature. I choose, without a doubt, the former.

We will have to stay with the current solution until we have found other
ways to provide the functionality.

But if like with the layers dialog, I see zero function 99% of the time

The dialog saves you the extra step of filling the layer. In my opinion
it is very useful and speeds up the workflow. After all the user just needs to press the Enter key to acknowledge the last used settings.

When I look fundamentally at what layers are, the optional character of all functionality (name, size, fill) offered by the dialog, combining that
to realise the percentage of times that each will be useful and the alternatives to reach the same goal, take into account that this is part of user request #5, then dealing with this dialog dozens of times a day is a burden on GIMP's user experience.

All I ask for is to give it a chance. GIMP has what adobe has not, a community. They want to participate by using developer versions in real life situations. I say let them help.

Try this in an early development version (like 2.5.2) and wait for the learning effect (you changed it!) to go away. Then after a while evaluate.

If it then turns out to be the wrong idea, I'll be the first one to admit it.

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Sven Neumann wrote:

On Sat, 2007-05-26 at 16:50 +0200, peter sikking wrote:

The choice it to make either the dialog or 'no dialog' a tricky power feature. I choose, without a doubt, the former.

I explained you why that choice is not acceptable. If you did not understand my last mail, why don't you just ask?

I think we are talking now past each other...

When I look fundamentally at what layers are, the optional character of all functionality (name, size, fill) offered by the dialog, combining that
to realise the percentage of times that each will be useful and the alternatives to reach the same goal, take into account that this is part of user request #5, then dealing with this dialog dozens of times
a day is a burden on GIMP's user experience.

Please stop reiterating these buzz-words; it starts to become annoying after a while.

If user interaction problems need to be solved, then it needs to be discussed in user interaction terms. If I would translate this totally into user-space or developer-space, then it would trivialise the issue.

So that's it then, for this issue...

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture