Tobias Jakobs asked me in a comment on the blogpost

What does this mean for the Gimp team? Is it a good idea to use one ob this to redesign the tool or does it need more work?

I answered:

Good question. One has to value this work for what it is, student work from a class that ran one week.

One the one hand a certain part of GIMPin 2012 seam carvingthat has never received any interaction design thought, gets methodically worked on by 3 or 4 teams of talented designers. The results are a shot in the arm for GIMP.

On the other hand a week is very short and for the students it is their first introduction to interaction design. Thus the presented results are alway an _inspired_start_ but not complete and deep enough for implementation.

To do the methodical student work justice, the logical next step is that experienced interaction designers take the work forward and create a for-production design.

This is of course relevant to the SoC.

ps: I am blogging the results of 2013 right now.

--ps

founder + principal interaction architect man + machine interface works

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

Michael Henning wrote:

I agree; it would be beneficial for our SoC students to work with an experienced UI designer.

I'm not involved in the SoC myself, but if an interaction designer were to offer their time to help out, I'm fairly certain it would be welcome. In particular, some people on irc have raised concerns about how well the combined selection tool will turn out if only programmers guide the student.

of course I can do this design, and that includes addressing both user needs and developer needs.

but I do not want to have the same disappointing experience of SoC as I had in the last few years.

in particular, I do not want to be confronted by either student or technical mentor with the following:

- I did not expect the UI was going to be like this, so now we have a problem;
- the back-end is already fixed. no, we are not going to change it; - I never thought about that, so forget it; - first we going to put in some provisional UI, later we do your design

these are not just demands, it also comes with taking more responsibility from the design side, basically co-mentorship.

when UI is compromised to make it happen, it better be compromised by the designer, who can see _all_ the dimensions.

this is an invitation to start working again...

--ps

founder + principal interaction architect man + machine interface works

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

I wrote:

ps: I am blogging the results of 2013 right now.

done. how quaint, there is not enough functionality!

--ps

founder + principal interaction architect man + machine interface works

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

Michael Schumacher wrote:

of course I can do this design, and that includes addressing both user needs and developer needs.

nice to hear from you.

but I do not want to have the same disappointing experience of SoC as I had in the last few years.
in particular, I do not want to be confronted by either student or technical mentor with the following: - I did not expect the UI was going to be like this,

This is, I'd say, expected - if everyone knew how a particular UI would have to be like, it would just be done that way.

yes, it is solid ‘duh’ territory.

so now we have a problem;

I'm not sure how to read this correctly. After going over your mail multiple times, it seems more and more likely that this is meant as a caption for the following points, I'm going to read it as such.

no, it stands by itself. Although it was clear that the developers did not know what the UI should be like when I started designing, they did seem to have made up their mind about certain things, especially about exposing technological things directly in the UI and doing things ‘like always.’

when I—to address the needs of the project, users and developers, and make every part in the design work together—come up with something that is different, then the developers get really antsy about their foregone conclusions.

- first we going to put in some provisional UI, later we do your design

This, however, puzzles me a bit. I'll exaggerate to describe my confusion:

This means that no sign of any non-finished UI might become available to the public through GIMP code. The developers working on it would do so under conditions which border on an NDA, and only commit code to the public repositories once the UI has been completely finished.

good that you discuss this, because it is not what I mean at all.

I wrote about this in a recent blog post:

(actually that post is a lot about working on GIMP...)

‘Quite often developers like to first put some temporary—and highly technological—interaction while they sort out the non‑UI code. The real design will be implemented later. Then time ticks away, the design lands in a drawer and the ‘temporary’ UI gets shipped.

‘I do not think this is a malicious trick, but it happens so often that I do not buy it anymore. The only secret to getting interaction design implemented is to do it in the beginning.’

thus it is about what the initial energy of development is spent on: some clutch or the real thing? because after the initial energy has dissipated, inertia makes that whatever is there is the thing that gets shipped.

so you can guess my new motto: ‘from the first week we start building the real thing.’

these are not just demands, it also comes with taking more responsibility from the design side, basically co-mentorship.

Going back to GSoC, and taking the limited time frame of the program into account, how is the sheer inability to finish the UI due to time constraints to be taken into account?

this is exactly what you want to ask the designer, exactly because of the following sentence:

when UI is compromised to make it happen, it better be compromised by the designer, who can see _all_ the dimensions.

assuming an agile way of working (which many do a little bit these days), it all starts in the first week of implementation: as a co-mentor the designer selects the first aspects of the design that are to be implemented.

the designer understands the state development is in so there will be no unreasonable demands. it is even OK to not develop UI in the first week or so. it is not OK to develop clutch UI.

if a ‘testing’ UI needs to be made first, the designer will happily design this for the developers, in a matter of hours. of course it will borough a lot of the ‘real thing’, that is why it is quick to design. it also ensures that energy is spent in the right direction.

when it is time for (horrible) compromises because of time or technology, the designer will make these. the whole point is that the needs of the project, users and developers remain balanced, and that every part in the (reduced) design keeps working together. that is what you have designers for.

that is how I see it working. I hope you can see that this is hardly a ‘designers paradise.’ it is about taking responsibility.

Just one thing there:
The issue of what communication channels to use has not been solved yet. You have mentioned that you prefer not to use low-width channels like mail or IRC, but what should be used instead?

in recent weeks I made a couple of tries on irc to contact Mitch about the following: to either meet in person when he is in berlin, or to have a talk on the phone.

I expect we will need several of these.

--ps

founder + principal interaction architect man + machine interface works

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

Alexia wrote:

so you can guess my new motto: from the first week we start building the real thing.

Developers work in iterations. When you start you have a vague idea of what its going to be, a goal, but you never know how it will make sense to reach that goal in the end. So you iterate, without polish and beauty you make a draft, test, make sure the framework is solid, etc and then go over it again. At some point you run into a fundamental issue and need to discard a lot of the underpinnings and the code above up to and including UI concepts.

I am all for making UI from rough to polished. after an initial analysis phase (which takes place in the first 20% of my work) I can guide this, rough to polished, from the first week of implementation, because I know exactly what we have to achieve and where we have to go. the throwing away of non-working UI concepts happens on my piece of paper, not in code written at much greater expense (in time and motivation).

but you (I mean: all GIMP devs) have to let me guide you.

you have to accept and trust that I can see, feel and judge a UI idea/concept in a minute without it ever existing in code or even a drawing. that I am able to tell you how it will work, for users, three months after the release of the software. that I can separate 977 bullshit UI ideas from the 3 that will work, and concentrate us on making the best out of them.

you have to let me guide you and at this moment there is, I believe, no developer at GIMP anymore that lets him or herself be guided.

It also means that you do not wish to spend time polishing things that might get discarded - the work goes from rough to good - from general to specific and in an ideal world, so would UI and interaction design. It would start off as rough guidelines and complete in a finished product... Sofar, we have tried to make it work in reverse - that the UI/interatcion is fitted on top of a ready bit of code like a mask. And in my personal experience... That does not work.

I am happy you say that. it is encouraging.

UI is not a skin/decoration of back-end code. UI is the realisation of the product, in this case the GIMP project. A lot of needs from product, technology and users put a lot of requirements on the UI, which I juggle in the design of it.

you notice that technology is only 1/3rd of the picture; of my puzzle.

and by my experience, the UI design has also an impact on ~33% of the back-end code. if developers refuse to harmonise this back-end code with the UI design (as happens now) then the devs are implicitly shaping the UI...

It creates frustration for both sides, because we cant get the mask to fit and you feel that we disrespect your work... And that is truly unfortunate, because we really really need your insights and input and I personally believe it's of most use when it is given in form of concepts, rules, insights and diagrams rather than ready made bitmap expectations of how it would have to look...

I am happy to develop and tune new methods of working, but it starts with trust.

--ps

founder + principal interaction architect man + machine interface works

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