Re: [Gimp-developer] hesitant about compiling a list...

[peter sikking <peter mmiworks net>]

Bruce wrote:

[I will snip here quite a bit to keep this post from ballooning]

> Hi guys, I'm the Bruce that Peter referred to in the first post in this thread. 
> 
> How open does it make sense to be?
> 
> I think a good approach is to be open to the degree where it is constructive and feels good, not just for the sake of it.
> I have an idea for how we can have "public flags in the ground" in terms of what can be improved (which are helpful for reference purposes, and also for communicating "this is something we feel we could improve"), 

I have ben thinking for the last weeks that this list should not
be called the issue list, but the to-do list. this matches how
the project is run. the UI team is simply working its way through
areas of GIMP, older ones and brand new ones. when we get there,
we design it, and make it work.

> Can we do this in a way that is sensitive to the efforts of GIMP developers, and if so, how?
> 
> Well, I think one way to approach it is how things are communicated. E.g. You can communicate things in a constructive and positive way (i.e. "here are some cool directions we would like to go in in regards to the various UI elements of Gimp"; sort of like the UI Brainstorm does), or you can communicate things in a remedial way with a focus on deficit (i.e. "this is broken and needs to be fixed").

well, design is not about cool, it is about identifying the problem
and then solving it (the hard design part). talking about design in
such terms is for me important; it is about respect for what
interaction design is and the value it brings to software.

thus it needs to be said that ‘this is broken.’ but let’s introduce
the convention that it can only written down that ‘this’ is broken,
when the next sentence discusses the (beginning of a) solution.
this means there is always light at the end of the tunnel, that the
UI team is able to put direction into the UI work, and that any
contributor has the chance to start from this direction.

> So, here's my idea:
> 
> As you already do, you could allow people to submit ideas to the UI brainstorm in the form of mock-up images. This keeps things solution-oriented. The idea would be to have all UI suggestions and ideas go through the brainstorm in the form of images that propose solutions.

there really is an ocean sized gap between the anything-goes world
of UI brainstorming and the rigour of interaction design. anyone can
participate in the brainstorming, that is the purpose of it. the only
way to bridge the gap from brainstorming idea to interaction that
is designed and can be implemented is to _design_ it.

the whole discussion about opening up this design process to more
contributors is in the ‘contribution processes’ thread.

> Then, you could create a page at http://gui.gimp.org

gui.gimp.org is a repository, of interaction designs, usability
projects and documentation of interaction design projects and
processes. similar to a code repository, the integrity of
gui.gimp.org must be maintained or else it is worth nothing.

this means there is no place for ‘ideas’ on gui.gimp.org, just as there
is no place for ‘casual talk about code’ in a code repository.

the to-do list fits gui.gimp.org, it contains already quite a bit
of contribution by interaction designers: the evaluation and
analysis where the real issue is, and by showing the light at
the end of the tunnel.

    --ps

        founder + principal interaction architect
            man + machine interface works

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