GNOME.org
 

[Gimp-developer] Interaction design. Used to be: Re: gimp gradients

Peter, and everyone else, excuse me for taking so long to reply.

OK, let me explain better: I was trying to say that people who
on this mailing list and irc obstinately imply that they also
got the interaction design angle somehow covered, should maybe check
their contributions, accomplishments and recognition by seasoned
peers (all three in interaction design, of course, as should be
the seasoned peers).
To be honest, I've seen this implication you mention both in coding and in design. A designer designs an interface and "implies that he/she also has the programming angle somehow covered". Just because there are open projects around with open code and similar functions, the designer presumes it won't take long to patch together a functioning code... Of course, this approach doesn't work at all. Either in programming or design. The only difference being that the comedy of failure is much easier to spot in the patchwork of code done by an overly enthusiastic designer then in the patchwork of GUI done by an overly enthusiastic programmer. :)
I think that with GIMP the delusive confidence in "having the interaction design angle somehow covered" is resting on a myth of a bitmap editor "as-it-ought-to-be" - the ineffable Photoshop. Often, while developing, there is a comfy crutch in the back of our heads, a mental model we gravitate to in a lack of a better vision, that "later, when we need to add the GUI, we should do what Photoshop did, or something similarilish…". I think that this is only normal. To notice the analogies between GIMP and Photoshop functions and transplant the existing user interface "solution" from Photoshop to GIMP. Honestly, this transplantation appears like a very efficient thing to do!
Unfortunately, since Photoshop and GIMP are not identical, these "transplantations" have paradoxical downsides. Internally, GIMP is definitely not chasing anyone's taillights thanks to brilliant work of many developers who created it as an advanced and unique piece of software. Externally, from the user interaction standpoint, GIMP appears as if it is chasing Photoshop's taillights. In other words, the unquestionable mastery in coding is paired with "not-really-mastery" in interaction/interface design.
As a result, the coded capabilities of GIMP often get buried in a patchwork of GUI approaches. Which is unfortunate considering the developer's work done on the inside. Admittedly, most of GIMP's functions can be accessed somehow, somewhere if you happen to know certain magic ritual of "unwritten wisdom". (e.g. see recent thread here on gradients, or follow many threads on GIMP user forums). That is not interaction design but "hide-and-seek".
With this paradox in mind, my understanding is that the best contribution to GIMP that interaction architects could/should/would do is designing the user interface and user interaction that complements the quality of GIMP code. To pull out GIMP's powerful functions into the light by shaping the interactions and controls for them. So that we can use them. Also, together with the developers and users, the designers can indicate the needs that would, once solved, round-up GIMP as a capable and enjoyable tool. (MyPaint and Blender3D got this part right, in my opinion)
This work is tough but well due. Inevitably, it will be perceived as "destructive" by many or "not sufficient" by many others. Like you said, it takes seasoned peers, i.e it takes mastery. The same level of mastery the code developers need to have when dealing with GIMP's insides. So far, you and your students did an admirable job in this field. Personally, I did not get your style always (as I have mentioned to you before here) but there is always a strong rationale behind your work. 100% rational decision making. Proper design work by all means.
Allow me get back to those taillights once more... Chasing taillights wouldn't be much of an issue if Photoshop's approach to workflow and GUI was a case in excellence. The issue is that Photoshop's approach has never been particularly smart. It did fit well into what was possible 20 years or so ago, and then it got stuck there. With every version, new layers of functions are being added but adobe is reluctant to introduce changes for various reasons (mostly profit). The same stance is shared by AutoCAD, 3ds max, Maya, Illustrator, MS Office (until recently), etc. I don't know if you would agree with me, but currently, from the user interaction standpoint, Photoshop suffers from a traditionalistic (atavistic?) approach. Some might argue that Photoshop's market share is an argument in favor of Photoshop's UX/UI, but I think we know better. 

because this is how it works in code in open source and the devs
are taking no prisoners in this regard.

meritocratic is how it is supposed to work.
I think I understand now what you were referring to. Thanks for the explanation. 
without any cynicism I say that I could use some evaluation and advice
here from you Aleksandar, because all pointers say that you are indeed
a peer, deep into open source and you are independent of me.

without trying to convince you, that design was developed in the open
at its wiki page:

<http://gui.gimp.org/index.php/Transformation_tool_specification>

even earlier sketches were blogged:

<http://blog.mmiworks.net/2009/03/working-on-gimp-transformation-tool.html>

there were quite few afternoons where I showed the design on irc and
adapted it after critique—especially the handle design—until it dealt with
the criticism without throwing out the innovation with the bathwater.

also I linked to the design in progress on this list, of course looking
for attention and feedback.
Thanks for the links. I am not sure if I am able to provide you with deep evaluation or advice. I can only try.
In my opinion, from the interaction design side the transformation tool proposal looks very well done. It would be an elegant solution for transformations (once deployed in parallel with its counterpart, i.e. the precise transformation tool that I yet have to see). The decision to split precise/by-feeling transformation controls seems sound and well grounded to me. For several reasons:
1. It allows us to bring from the real world to computer realm two very natural approaches of operating anything: by-feeling and precise (Peter, you called it differently before, I just forgot the terminology you used, sorry; e.g. freehand drawing vs. precise drawing using precision tools). This dichotomy for toolmaking is essential and it rarely (never?) mixes into one. e.g. Typesetting machines do not have pens and pencils, hammer and chisel don't have angle indicators, etc… That is not to say that using skillfully either of the two approaches cannot appear as if it is performed "intuitively". (think of sound engineers using studio mixing desks, for example, they are using precision tools very intuitively)
2. Giving dedicated sets of controls to by-feeling and precise transformation approaches will benefit both approaches. By-feeling approach retains the speed and hands-on experience, while precise approach (hopefully) will build on numerical/algebraic expressions. In other words, no stepping on each other's toes. (Provided that users will be able to switch between the free and precise transformation approaches smoothly...)
3. Seems to clean-up the GUI a bit. A cleaner interface that accomplishes the same (or better) functions is always good. "no matter how cool, no matter how beautiful your interface is, it would be better if there were less of it!" ;)
4. The transformation frame approach concept seems reusable. Meaning, I could imagine the same workflow implemented in other graphic software projects.
5. It is uncompromisingly designed to provide as good as currently possible control for transformations by-feeling, and to achieve that, it did not chase any taillights! I think that this is a new value for GIMP. This might be a good step towards getting out of the St. Photoshop's geriatric shadow. Of course, there is other good stuff peppered around GIMP, but "transformation tool" is symbolically fundamental.
One question… I understand that it might not be in the spirit of the transformation tool proposal, but I think that there is a need for something like an "augmented" intuitive approach. I am referring to various snaps (grids, angles, points) that would allow us to work by-feeling while being reasonably precise. For example, a layout grid of guidelines might be laid out; from then on a user could use only a combination of snapping and transformation tool you proposed to achieve precision and speed. Perhaps this ability is considered as understood in your proposal?
Some said that transformation modes (rotation/scale/shear/..) should be kept as separate tools. I don't think that would be the best approach. Imagine you want to accomplish a ride from A to B in a car. Naturally, first you will get in the car. This ride will demand from you to control acceleration, braking and steering either simultaneously or in rapid sequences. This is easy because, once you are sitting at the driver's seat, you will find a set of controls that are all within your reach, dedicated for efficient driving. Convenient. Now, back to transformation tool... Imagine you want to transform a selection. Equivalent of having the transformation "modes" as separate tools would be like having 3 driver seats in one car. One seat for controlling acceleration, one seat for braking and one for steering. Driving from A to B would have to be accomplished by doing a little acceleration on the acceleration seat, then switching to steering seat, then a little braking seat, then... Plus, each time you would have to get out of the car to switch the seat. Not convenient. 
well, I would not like to see that this comes to that I have to be more
catholic than the pope. developers, open the source for inspection and
sharing. but they do not have to justify every micro decision of every
line of code, certainly not to non-developers (heh, try...)
the code has to work and get past the quality standards and technical
architecture requirements of the maintainers.
I agree, there is no need to explain every tiny decision made that ultimately led to your solution proposal. Also, it is true, as you said, that the code has to work and get past the quality standards and technical architecture requirements of the maintainers.
Maybe this is a good place to try to say what I had in mind when I mentioned "opening" your design process. I truly hope this topic will not be too cryptic or patronizing.
Getting past the quality standards and technical architecture requirements of the maintainers is not the exclusive pathway leading to solution implementation. Open source does not impose legal confinements for ideas and solutions so ideas can be forked and cloned by others, too. Which in turn brings more ideas and more feedback, more interest and more drive to make it. This ensures that a good idea will "live"… So, it will happen that someone, somewhere (maybe not even connected to GIMP community) will be able to develop and implement solutions that were based on your work.
So, I am thinking… Are solutions "delivered" to the community in an "open" format? Could your design proposals be presented in a way that would improve the chances for the ideas behind them to be implemented, forked or cloned?
That said, I think that the specs are very terse and condensed, maybe even intimidating? I read your specs like a recipe. They are excellently executed, no question about it, but readers have no option but to accept them. I am aware that this is exactly what specs are supposed to be. The specs are lacking the verifiability and fallibility (to introduce a little bit of ol' Karl Popper). Probably only because I have been dealing with specs I am able to "decode" them and visualize the final design in my head or on a piece of paper. Even so, there are some points where I have to invest some faith, and trust your expertise that it will be OK in the end. To use developer language: you are giving us a packaged/compiled solution (which is great!) but not so much the raw source.
Also, GIMP is code-developer initiated and maintained project. It will remain code biased, I think. Or, as you said, leaning towards "tech" in "user-tech-project" balance. Perhaps your design specs introduce a bit of culture shock, too. This transformation tool proposal is quite different from the existing models. It might not be a trivial thing to understand for any design non-expert. I hope I am not insulting anyone's intelligence by saying so. Especially if one has to "decompile" it's true value solely from the specs. One way, I imagine, would be to provide more articulation and rationale (as señor Prokoudine mentioned) of the final proposal. A clear narrative that will articulate these interactions in a simple, but real context. It would be very helpful to see a visualization of the basic interactions using the proposed transformation tool frame. Ideally, a video mock-up or a sketch, but even a static storyboard with basic interactions depicted could do, I think. Without this narrative, we have to read the specs carefully and reconstruct the interaction in our heads based only on the static descriptions of the elements that constitute your solution. Consequently, the acceptance of your solution proposal will depend on reader's (developer's?) imagination and willingness for leaps of faith. This kind of imaginative process demands a lot of experience in interaction design. Same as imagining some program structure demands a lot of experience and skill in programming. It is a little bit like facing orchestral notation. It takes a lot of note-reading experience to "hear" it just by reading. Live or recorded performance, on the other hand, will captivate ears of even those not experienced among us. I imagine that there is no "fun, contribution and accomplishment" in coding according to the dry specs without getting hooked to the ideas that are behind those specs first ;).
I believe that a visual narrative for your transformation tool proposal would give plenty of reasons to get hooked and ultimately inspired to clone/fork it or contribute the coding component to this solution. Because it is a good solution!
We all come here from different backgrounds and I cannot expect a person who diligently dedicated time to master programming to the level to be a GIMP developer will intuitively understand the thinking that went behind your design spec. By all means, I hope no developer ever makes that mistake and expects from me to understand the thinking that went behind some (even the simplest) piece of code! In that regard we are different cultures altogether. On the other hand, we both take on challenges, grasp concepts, focus on purposes and pursue functional "beauty" of our work. We (declaratively) tend to make rational decisions, too. This constitutes a good "common ground" for us to exchange ideas and communicate successfully. 
the interaction design has to work and get past the quality standards
and interaction architecture requirements of the lead designer.


it brings me to the actual point that is so galling for me at
the moment. as a designer I have several long-term relationships
with clients and partner companies. what I notice about them
is the giant trust that comes with them:

clients and partners trust that when I lead the design the problems
(and they are always big and complex) will be solved and the
results will be great; just build it;

clients and partners can trust that I never let them down, I am
always there for them when they need it.

I am now 6 years active at the GIMP project (long term, I call that)
and the trust is not there. I really would like to see an explanation
for this.
In the open source, conventional organizational structures necessary to support the designer role do not exist and without them the conventional design methodologies fail, too.
In the conventional profit-driven organizations, members communicate directly, they plan and schedule efforts, assign responsibilities, resources and expertise, and so on. Conventional organizations plan and manage design early. For them, production (and very often - profit) depends on a well structured environment where defined methods, roles, needs, goals, schedules, and so on play very important roles.
In contrast, an online communal social environment of the open source software development is fundamentally different from work organization the designers are commonly prepared for. Organizationally, the open source has been described as action-driven, network distributed, asynchronous, concurrent and unmanaged system of mostly individual actions. In other words, A mess. :) But, it is a beautifully creative mess. To make design work, we have to stop relying on the old organizational crutches. I consider this to be a liberating condition, albeit a stressful one. So, let's find better design methodologies that free from the dependency on conventional organizational structures. I am *always* open to discuss/try those! 
the unworkable thing is that the middle finger comes from the people who
are supposed to be partners in this: developers.

the implicit agreement—I scratch your back and you scratch mine—has
been broken with that.
This will bring no consolation. Unfortunately, I am not sure if such an agreement could be carried-out in the open source since it implies the code of duty (of respective back-scratching) and we are rarely driven by duty here. But, as you have mentioned yourself before, challenge, fun and accomplishment are a different story!
It is obvious to me that your work in interaction design is preceded by deep understanding of human perception and cognition, creative and work processes, workplace design, etc. Also, you put a lot of care to keep the tools you design simple yet open-ended, i.e. you are not creating dumb, narrowly specialized tools. I know that such open-ended yet simple tools are the most rewarding for users, but at the same time immensely demanding to design and I admire that you don't wiggle out! I can only learn from you!
That's why I believe that the middle fingers came from those who merely didn't get it yet. Certainly not on the level we would like them to get it. But this is something that, I believe, can be improved with some articulation.
Please excuse me for taking so long to reply. I tried to make up for it by an overly lengthy post, it seems. :) Or, did I just make it worse? Probably.
Cheers, award yourself with some meze. If you read all of this you are probably very hungry by now. 
:)

admiring the magic,
Alex
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]