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



Hi guys, I'm the Bruce that Peter referred to in the first post in this thread. 

I thought I'd share some feedback about this, but in more of a brainstorm sort of way where we can just share and discuss ideas for what such a list might look. 

That way we can put the idea of creating it aside for the moment and better evaluate the idea and how it could be done in a way that is appropriate. 

So far the core issues we're discussing seem to be:

(1) how open does it make sense to be?
(2) can we do this in a way that is sensitive to the efforts of GIMP developers, and if so, how?


* * *

How open does it make sense to be?

On Fri, May 18, 2012 at 12:19 AM, peter sikking said:

- just thinking of what I can contribute to this list, I know
that this list is _not_ going to be short. also because all the
issues that I can put on it are ‘medium level to big-picture,’
none of them are going to be trivial to solve. thus my hesitation
is what this is going to make GIMP look like, and if the definitions
of open worked where meant to stretch this far.

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.

E.g. If you have personal notes for how things can be improved, you don't have to share those notes--they're for your personal reference.

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"), while still allowing people to keep private, personal notes and ideas that they can dip into and reference as it makes sense to (rather than just sharing them all publicly). 

I'll make another email after this one and you'll see a better idea of what I mean. 

As for the other topic of discussion…

Can we do this in a way that is sensitive to the efforts of GIMP developers, and if so, how?

On Fri, May 18, 2012 at 12:19 AM, peter sikking said:

- all of the issues that will end up on the list have been
created by contributors to GIMP. some of these issues have been
created 10 years ago, some of them last month. I wonder what it
will feel like to GIMP contributors when something they just made,
almost ‘immediately and automatically,’ (at least, feels like that
to them) ends up on the UI issue list.

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"). 

I feel the positive approach is more constructive and also more productive (and it also feels different). We want to inspire the GIMP community and developers and help them be clearer about the direction the user interface and user experience of GIMP is going.

In that sense, a list of current issues (which, by focusing on "issues," focuses on deficit) may not be the best way to approach this. That was what we (Peter and I) talked about at first, but let's iterate on that. 

Perhaps a better way to approach this is to have such a list list be more of a vision of what Gimp can be and a place where ideas for how things can be done can be documented for reference. E.g. There's a difference between a bullet point that says "X icon isn't very good" and "Several people have proposed ideas for how X icon can be improved; here are links to mock up images that people created." Again, one feels different to the other and has more of a collaborative, inclusive spirit that's good for the community.

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. 

Then, you could create a page at http://gui.gimp.org called  "List of ideas and proposed changes for the GIMP user interface"  (or something like that) and have:
  • a sub-section that describes (or links to) the overall vision of what you'd like to do with the Gimp UI in a general sense (which helps people to be on the same page)
  • sub-sections that act as buckets for documenting submissions made to the Gimp Brainstorm so you have a nicely categorised overview of the things people would like to see in Gimp in terms of the UI, and also a pool of solutions developers can draw on.
The idea behind that page would be two fold: 
  1. developers can go to it to get inspired and also see what can be worked on (in a UI sense) and basically pluck items from there and start a thread over in the UI contribution process for more in-depth focus on hashing out a solution that can iterated on and eventually be added to Gimp [assuming the UI contribution process goes ahead]
  2. people who are using Gimp (i.e. users) can look at the "List of ideas and proposed changes for the GIMP user interface" page and get an idea of ideas and solutions that have been proposed, and if they have an idea for how the Gimp UI can be improved that isn't listed on that page, they can submit an image via the UI Brainstorm. 
This way things will always be constructive. 

And you guys can still do your regular UI Brainstorm review--the idea is just to document what is submitted to the UI Brainstorm as a way of communicating what has already been considered, but in a categorised list format that is easier to browse through (for people looking to see what the state of things is and whether an issue has been addressed) and also easier to pluck ideas from (for UI developers looking to start a UI contribution process thread based on what they've seen on the "List of ideas and proposed changes for the GIMP user interface" page. 

People could still discuss UI topics in the developer mailing list, but "communicating ideas through images" via the UI Brainstorm would be encouraged. Image submissions don't have to be perfect; just "sketches" of what could be that:
  • communicate to the developers what the community would like to see in Gimp
  • give the developers new ideas 
  • and help flesh out the "List of ideas and proposed changes for the GIMP user interface" page as a community and development resource. 
* * *

Those are the best ideas I have so far in terms of how to make the process more constructive, productive, and hopefully a nicer experience for the developers.

I think it's still fine to document raw notes (like those found here: http://gui.gimp.org/index.php/Evaluation_Notes_-_Photo_Realistic#introduction ), (A) that can be done elsewhere, and (B) notes, by definition, are unrefined reference resources that have not been processed. Notes may contain good ideas, observations, and solutions, but those things--the "gold"--have yet to be mined out, processed, and then displayed in a format that is more useful and appropriate for consumption by the Gimp community and developers. Curation (what and how things are said) matters. 

Again, the idea behind the "List of ideas and proposed changes for the GIMP user interface" page isn't to spotlight and highlight what's wrong, but to help build bridges from where Gimp currently is to where it can go. Then, when someone wants to help construct one of those bridges, they can pluck out the notes on the "List of ideas and proposed changes for the GIMP user interface" page and create a new thread in the GIMP UI contribution process (if that goes ahead) and the actual development process (for that particular item) can begin. 

It's still possible that a new release of Gimp might come out and then shortly after people post images to the UI Brainstorm with ideas for how a feature can be improved, but when those images are reviewed and added to the "List of ideas and proposed changes for the GIMP user interface", when developers reference that page they'll see constructive ideas and visions of what could be rather than "X icon isn't good," or "this feature needs to be better designed." [Which aren't necessarily bad statements—they are what they are—they're just not that helpful when it comes to what we're trying to do.]

On Sat, May 19, 2012 at 11:59 PM, Jon Nordby <jononor gmail com> wrote:
On 17 May 2012 16:19, peter sikking <peter mmiworks net> wrote:
> a couple of days ago Bruce appeared on irc and we had a chat.
> (Bruce is now subscribed to this list)
>
> within a minute we were talking about whether GIMP has a list
> of known UI design issues. as far as I know we do not have one,
> it is certainly not part of gui.gimp.org.

<snip>

> - just thinking of what I can contribute to this list, I know
> that this list is _not_ going to be short. also because all the
> issues that I can put on it are ‘medium level to big-picture,’
> none of them are going to be trivial to solve. thus my hesitation
> is what this is going to make GIMP look like, and if the definitions
> of open worked where meant to stretch this far.
>
> - all of the issues that will end up on the list have been
> created by contributors to GIMP. some of these issues have been
> created 10 years ago, some of them last month. I wonder what it
> will feel like to GIMP contributors when something they just made,
> almost ‘immediately and automatically,’ (at least, feels like that
> to them) ends up on the UI issue list.

I support creating such a list. If we hope to solve these issues, and
keeping the amount of similar issues we introduce down, they need to
be visible for all to see. Being open is about transparency and
accountability. And it is just as important, or more, that we act in
such a way with respect to our problems.

--
Jon Nordby - www.jonnor.com
_______________________________________________
gimp-developer-list mailing list
gimp-developer-list gnome org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]