Re: [Gimp-developer] hesitant about compiling a list...
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@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] hesitant about compiling a list...
On 17 May 2012 16:19, peter sikking pe...@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
[Gimp-developer] hesitant about compiling a list...
guys, 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. (I am not talking about a bug list, with nuts and bolts issues, I am talking about a list of medium level to big-picture issues and to-dos. the kind of design tasks I pick for my teaching are medium size ones, see http://blog.mmiworks.net/search/label/teaching ) Immediately I realised this list is missing and that there are real benefits to maintaining a list like that: - a clear list of design tasks to pick one from for people who want to contribute or run projects in interaction design; - GIMP as a project says clearly ‘yes, we know we have problem with XYZ in the UI.’ this can make certain discussions a lot shorter, by pointing at the list. also I feel that _part_ of the ‘GIMP has so far to go’ feedback that the 2.8 release gets is caused by us not communicating ‘yes, we have problems.’ - coordinating between open technical project work (GEGL migration, etc.) and interaction design project work. - the big picture concerning UI becomes clearer because it is written down. so far so good. but while talking to Bruce I realised that there are a couple of side effects to this list that make me hesitate to just go and get started with compiling it: - 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. so I would like to hear some opinion on this. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] hesitant about compiling a list...
Hi Peter, my opinion is 'the clearer the better'. Such a list could IMHO improve GIMPs product quality. Even if it will be a long list (and it will be growing, as user requirements and wishes always become more) this will show the necessity to priorize. I'm not (or not yet) a GIMP developer, but speaking as a software developer I know of the benefits of priorization. Of course, this priorization must be done together with the developers. The GIMP team could then define mandatorily, what will become realized at all or in the next version - which could make it easier to define release plans. The product vision is the big picture, but it needs refinement and this list would fill this hole. I think, contributors don't have much problems at all seeing their proposals/contributions at this list as long as they know it's part of the development process and they don't _end up_ on this list. If some contributors come with a ready-to-integrate idea (like Tito, a new brush engine etc.), such a list could/should be taken to examine, how these appreciated contributions can become a useful part of GIMP and keep track of that progress. So, you have my +1. Best regards, grafxuser ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
