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 _______________________________________________ gimp-developer-list mailing list gimp-developer-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gimp-developer-list
