Sven suggested that I direct the mailing list's attention to http://bugzilla.gnome.org/show_bug.cgi?id=152224 to see if there were any ideas about the best way to go about fixing it. Basically, if you enter in that you want a 200 mm x 100 mm image using the order that makes sense (top to bottom, left to right), you enter 200 in width, 100 in height, and then mm for the units. Unfortunately, if you were to do that, you would end up with a 17 x 8.5 mm image, since changing the units causes the width and height to change as well.

Consistancy is a good thing, of course, and in all the other places where units are used, this is a very nice behavior to have. But the new image dialog is different in that there really are no pre-existing sizes or units, really. You are entering new ones from scratch.

It's not absurd to think of a case where having unit conversion in the dialog box is useful, but most of the time it's not a desirable behavior. Actually, that's being polite. In reality, it's the kind of frustrating, annoying thing that I make fun of the stupidity of the developers when I run across in propriatary code.

There are a couple of ways to fix it that we've discussed on the bugzilla. None of them are completely satisfactory. Does anyone here have a better idea, or, if not, which of the existing solutions do you think is best?

Rockwalrus

On 10 Sep 2004 11:53:17 +0200, Sven Neumann wrote:

Hi,

Nathan Summers writes:

Consistancy is a good thing, of course, and in all the other places where units are used, this is a very nice behavior to have. But the new image dialog is different in that there really are no pre-existing sizes or units, really. You are entering new ones from scratch.

I am sorry but I have to disagree with you here. You are seldomly entering new dimensions from scratch in this dialog. What you do is you start with the last values or the ones from the image you opened the dialog from. Or you are using a template. So what you usually do is to accept or modify the values that are present already. I don't think that entering new dimensions completely from scratch is a common use case.

It's true that you can get sizes from the last image or templates, but obviously you don't use the GIMP for the same tasks that I do. :) I frequently enter a new size from scratch. Apparently the reporter does as well. It's certainly not an unusual thing to do.

It's not absurd to think of a case where having unit conversion in the dialog box is useful, but most of the time it's not a desirable behavior. Actually, that's being polite. In reality, it's the kind of frustrating, annoying thing that I make fun of the stupidity of the developers when I run across in propriatary code.

Since you admit that it is useful, I don't understand why you don't want to learn that you need to select the unit first. Seems like you behave like the kind of frustrating, annoying users who aren't willing to learn.

The current behavior is wrong for the exact same reason that it is wrong to put a handle on a a door that is opened by pushing. Even if you mark PUSH on the door in big letters, and it's a door you use frequently, you will still ocassionally find yourself straining to pull the door open, simply because even though the door is documented properly, it's afforded incorrectly. It's not a matter of learning! It's a matter of the person who put the handle on in the first place being ignorant of human nature. The brain just is not very good at internalizing the rule "You pull doors which have handles except for this ONE SPECIAL DOOR which in defiance to both convention and practical physical considerations has a pull handle even though it can only be opened by pushing." It tends to spontaneously forget it, especially when you are paying attention to higher-level tasks, instead of focusing on the menial, uninteresting, and usually trivial task of door-opening.

In terms of hardware, routine low-level physical tasks are generally handled by the cerebellum and brain stem. These devices are capable of rather amazing feats of systems control, but are limited to relatively simple programming. They are quite simply incapable of learning rules with ONE SPECIAL DOOR exceptions. This is a hardware limitation. This restriction cannot be eliminated through practice, training, or having a good attitude.

On top of this basic, almost fixed-function hardware, we have the cerebrium and neocortex, which is capible of learning more numerous and more complicated rules such as "for this ONE SPECIAL DOOR, you need to push instead of pull." When you think of the amount of signal processing and storage this involves, this is really quite extraordinary, and yet we take it for granted.

In this case, humans are able to open a misafforded door because the cerebrium overrides the cerebellum's natural behavior. When the intentionality of the individual is such that a door opening is necessary (the cerebellum is smart enough to deduce this without input from the cerebrium) and it perceives that the door affords pulling, the cerebellum decides to run the door-pulling program. However, in this case, it is overridden and given instead the instruction to run the push program.

It should be noted that the cerebrium is incapable of meaningful systems control without the use of the cerebellum. While it is true that it can do systems control directly, it is not nearly at the same rate of speed that the more specialized hardware is capable of doing. Without the cerebellum, the cerebrium is incapible of processing incoming signals and sending outgoing ones fast enough for even the most basic physical tasks such as walking.

The inherent problem with the misafforded door is that in order for someone to be able to go through it, that individual's cerebrium must override the cerebellum every time. If, for some reason, it does not, such as if the person has the audacity to be thinking of something other than door-traversal, the cerebellum will run the program it thinks is most appropriate, and the individual attempts to pull the push door. When the cerebellum notes that it is unsuccessful at its attempts to open the door, it triggers an interrupt, notifying the cerebrium that there is a problem that needs to be solved. This inevitably irritates the cerebrium, because it does not like to be interrupted, and because it is not very good at context switches due to a relatively small amount of short term random-access memory. The cerebrium processes the information and makes a decision on how to proceed (this usually takes about 1-2 seconds of real time, but is usually perceived by the individual as much less) and tells the cerebellum to run the push program.

The real issue here is that the cerebrium shouldn't have to bother with details like the mechanics of door opening. It should be able to concentrate on the high-level tasks that it is good at, instead of being distracted by insignificant low-level details. The only reason that it cannot is because of poor engineering by the door designer.

It should be obvious to anyone with machine learning experience that it is for good reason that ONE SPECIAL DOOR rules are especially difficult to learn -- the ONE SPECIAL DOORs in training datasets tend to be noise, and are properly filtered out, since they have no genericizing power. In fact, internalizing that rule would be overfitting, which is the opposite of learning.

This is the reason why push doors with handles are annoying to most people. Perhaps you don't get annoyed by them. Perhaps you have never accidentally pulled a misafforded door after you realized that, despite all appearences to the contrary, it was a push door. You are in a very, very small minority if that is the case.

To apply the analogy to the issue at hand, humans tend to enter data in reading order. They just do. They did it before the invention of the GUI. They did it before the invention of the computer. They do it on paper just like they do it on the screen. There are good psychological and practical physical reasons why this is the case. Furthermore, convention dictates that forms be easily fillable in reading order. Even before the idea of rasterization popped into the head of Philo Farnsworth, it was considered a misdesign for the contents of an entry to be affected by an entry that follows it in reading order. A good form has its dependencies topologically sorted because it's frustrating and couterproductive to have to go backwards to a previous entry and check to make sure that it still is correct in light of the way the following entry affects it.

Computerized form designers have tended to follow this aspect of the centuries-old accumulation of form design wisdom with remarkable consistancy -- honestly, even racking my brain, I can't think of another application that breaks with it. Even with GIMP, this is the only dialog I know of that does.

So what it comes down to is that here we have the rule that you can enter things into any form you run across in reading order except for this ONE SPECIAL DIALOG, where if you enter things in reading order the program goes and changes previously entered entries. Even though you probably remember that behavior after it bites you the first time, human nature is such that inevitably you will be surprised by it again -- or in other words, interrupted. This is because while your cerebrium should be handling more important, high level tasks like deciding what the optimal size would be, it instead has to be distracted by the manual mechanics of how to enter the size in this ONE SPECIAL DIALOG, when for every other dialog it can mostly relegate that low-level task to the cerebellum. It is impossible to "learn" to do otherwise. Perhaps it may someday be possible with intricate brain surgery or computer implants.

This is furthermore complicated by the fact that you are used to letting your cerebellum handle the manual aspects of data entry, and so it is not on guard for exceptions.

When you consider the amont of work it takes to change gimp such that gimp nature to match human nature versus the amount of work it takes to change all of our human users such that human nature matches gimp nature, it seems pretty arrogant to conclude that the right answer is to make human nature match gimp nature.

There is a reason why user interfaces are called user interfaces -- they are just like adaptors between different electronic devices. Just like the two devices must agree on a common protocol in order to use an adaptor, and do whatever conversions are necessary in order to use that protocol, to be usable, a program has to interface with the way the human user processes data and signals its intentions. It has to convert between the way that things are represented internally and the way that humans represent things.

Making ONE SPECIAL DIALOG that works contrary to the way that humans naturally process information differs from displaying the dialog using ultraviolet light or requiring all information to be entered using a Morse key in reversed Manchester encoding only by degree. All three are examples of interface mismatches. With the right hardware and APIs, both of those extreme examples would be just as easy for the program as using regular monitors and keyboards, but that doesn't mean that people would be lazy if they were unable to work with such a program as efficiently. Indeed, no amount of learning would make it possible for them to use it as efficently as the more human-centric program.

There is a reason why people tend to use systems more designed towards people. I could sit here all day and argue about why the binary system is better -- the multiplication table has only four entries, you only need to learn two symbols, etc., but it won't change the fact that the human language processing system is simply not that good at parsing long two-symbol streams. The chances of the appropriate regions of the brain adapting to able to easily understand what it means when a car has 111010100110101.0110 on the odometer in my lifetime is about as good as that of the Earth's orbit deciding to go along with the French revolution and change the number of days in a year to a convenient multiple of ten, and both of these probablities are so low for almost exactly the same reason.

Usablity is not really about enabling the user to be lazy about learning things, even though programmers often misperceive it as such. True usability is about enabling the user to really use the program efficiently. By relegating as much as possible to the cerebellum, and by minimizing distracting interruptions from the cerebellum, users can use the program faster because the cerebellum is more efficient at manual tasks, and because optimal parallelism between the two parts of the brain is achieved. Furthermore, since the amount of high-speed random-access memory available to the cerebrium is extremely limited, and unlike computers, cannot be swapped out to long-term storage due to hardware constraints, good usability enables the user to actually perform more sophisticated tasks, since vital memory and processing power is not wasted by low-level tasks and can therefore be used solely for the high-level task at hand.

Remember the door with the wrong handle. Misunderstanding the fundamental reason for usablity leads almost inevitably to poor engineering.

It is certainly a desirable goal to make things intuitive but I don't think that useful features should be removed for the sake of intuitivity.

I haven't suggested that we remove features. I don't think that anyone has suggested that we remove features in the general case. No one wants to remove features. Maybe I should say that again, because I've said it several times before and you still seem to think that I want features removed. I don't want features removed. No features need to be removed. It's very rare that removing features is the way to solve usablilty problems, although sometimes people chicken out that way. Really, you don't have to remove features. I've counted three suggestions on how to solve this problem without removing features. Two of them were present before you sent the email I'm replying to. There seems to be considerable evidence that no one wants to remove features.

I also very much doubt that users will find it intuitive if the size entry in the New Image dialog doesn't behave like other size entries.

This is only the case if the size entry looks like, or in other words affords the same as, the other size entries.

Rockwalrus

Note: Brain fans may notice that I've left out a lot of details in the analysis above. Most importantly I left out details about how the hindbrain (technically cerebrium) does a lot of signal processing work for the cerebellum in higher order animals. These kinds of details just complicate things while doing nothing for the final analysis.

On 10 Sep 2004 13:53:38 +0200, Sven Neumann wrote:

Dave Neary writes:

You forgot a third solution, proposed in bugzilla, which you said yourself wouldn't be too bad

[...]

That provides the affordance for people who want to create images by unit, and also allows us to keep the current behaviour for unit changing without confusing people too much.

Apart from the fact that it looks like crap,

I'd rather use a dialog that's somewhat less enjoyable asthetically than enjoy a dialog that's somewhat less usable by humans.

I don't think I'm unique in that opinion, although I can point you to some apps whose developers obviously disagree. Trying to get anything accomplished with them is almost physically painful, but look! Pretty buttons!

it also looks different
than in all other places where lengths are being entered. If the size entry looks different than other size entries, how is the user supposed to understand that it behaves like the others?

Perhaps they won't. Perhaps they won't need to. You can't say that it would be particularly surprising to discover it does, or unreasonable to try it out if you need that feature. At any rate, once they learn the first time that it works that way, they will remember it and be able to use it, since unlike the way that the dialog currently works, being able to consistantly use that behavior doesn't require working against the fundamentals of the way our brain is designed.

At a more technical level, what I mean by that is that cerebellum is quite capable of finding the nice affordable button with the current unit on it with rather minimal input from the cerebrium; at any rate, no more input than it takes to find the units box normally. It's true that it has to look around a bit longer to find it, but it's even capable of optimizing that to a surprising degree.

The reason for the difference is that "convert these numbers to a different unit" is not a task that has years of convention to unlearn, while "fill in the desired information" is.

And why do the other entries look different then?

Ony the terminally nitpicky would even notice. The terminally nitpicky probably have bigger fish to fry.

Rockwalrus

On Fri, 10 Sep 2004 18:41:07 -0400, Kevin Cozens wrote:

Joao S. O. Bueno Calligaris wrote:

Just another thought. What about adding some sort of "lock" icon beside the X&Y values that, when set, would prevent changes in the units from affecting the X&Y values. This would be similar to how we have the link icon that locks the X&Y together to maintain the aspect ratio when changing one of the values.

An alternative would be to have a link icon between the unit box and the X&Y values. When the chain is complete, it will affect the X&Y value. When the chain is broken, you can change the units without affecting X&Y.

This seems to me like the best idea so far. Let's develop it some more.

Rockwalrus

Packet:ve3syb@ve3yra.#con.on.ca.na

Hmm, I can't say that I can make head or tail of this. Do I need to rot13 it?

On 11 Sep 2004 01:47:03 +0200, Sven Neumann wrote:

Kevin Cozens writes:

Just another thought. What about adding some sort of "lock" icon beside the X&Y values that, when set, would prevent changes in the units from affecting the X&Y values.

I think that such a lock would add unnecessary complexity to the dialog. It will be easier for our users to understand how the UI works if we don't add another button.

True, but then again, it would be easier still to understand how the dialog works if it did nothing at all! Engineering always involves trade-offs between competing goals. I find a slight increase in learning how a dialog works to be an acceptable trade-off for being able to enter the size you want without facing frustratingly broken behavior.

Rockwalrus

On Sat, 11 Sep 2004 07:47:39 -0700, William Skaggs wrote:

Remember, even moving a menu entry to a more logical place is annoying to many people. We don't want to offend our most loyal customers!

Of course, since this dialog is already radically different from how it looked in 2.0, making a minor redesign to it now isn't going to change how different it will appear to users switching from 2.0 in the slightest.

Rockwalrus