Re: [Gimp-developer] about that student work...

[peter sikking <peter mmiworks net>]

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:

<http://blog.mmiworks.net/2013/05/design-lessons-with-daft.html>

(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