On 7 May 2004, Sven Neumann wrote:
> Nathan Carl Summers <[EMAIL PROTECTED]> writes:
> > I took a look at the new image dialogs on the list today, and I made
> > a few improvements. I've posted them at
> > http://wilber.gimp.org/~rock/NewDialogSimple.png and
> > http://wilber.gimp.org/~rock/NewDialogExpanded.png
> Sorry, but I fail to see any improvements in these mockups.
Honestly, I would have expected you to reply in a more thoughtful and
constructive manner. It's obvious that I spent some time (hours,
actually) constructing this mockup, and that I didn't think that my
choices were stupid, yet it really feels like you have dismissed them all
out of hand. This is exactly the reason GIMP has problems attracting and
retaining new contributors.
I'm sure if you have asked yourself why I was suggesting the things that I
was, what you would have said would have been more reasonable, or at least
more reasoned. You know that I am not an idiot. You also know that I
spent three months as an intern in a usability lab, so I'm not completely
clueless about the topic. If you failed to see any improvements, you also
failed to see why others might think that there are, and to identify the
principles behind which the changes were made. Not only that, you didn't
give me the opportunity to comment more on them (like I said I would)
before summarily dismissing them. That is more than bad intellectual
practice; it is bad leadership.
That said, here is my responce to you comments.
> The icon next to the memory size as well as the bold label "Memory
> Required" don't add any value
The icon adds value in two major ways:
1. It provides instantaneous feedback about whether memory usage would be
above the threshold set in the user preferences. This is a usability
win, since it allows the user to immediately fix the mistake instead of
having to re-open the new image dialog after the warning comes up as a
separate alert as in http://bugzilla.gnome.org/show_bug.cgi?id=21028
and the user cancels the image creation.
Note that it's still a good practice to have the alert box come up as a
double-check that the user wants to create an overly large image, even
if they have already been warned here in the new dialog.
2. In its normal usage, the icon immediately identifies the corresponding
controls as being informational and not directly manipulable. Since
the general layout is consistent with other GTK applications, instead
of distracting the user, it allows the user to immediately recognize
that in order to get the work done, the user needs to manipulate the
controls in the other sections of the dialog. It would take a higher
level of processing to identify the purpose of the section if the icon
were not present, or if it were not placed where it was.
> wastes screen estate
Screen estate is really a non-issue here. Even with the ridiculously
bloated theme that comes with Glade for Windows (yeah, yeah, buy me a T1
so I can do this kind of stuff at home on my beloved Debian Sarge box
instead of at work) the fully-expanded dialog is by default 344 x 521
pixels, which means that it will fit on any display bigger than 640 x 480.
Actually, it will even fit on a 640 x 480 display, since the somewhat
ungraceful behavior of the dialog is to clip the bottom part if there
isn't enough space allocated. If your display adaptor can't do 640 x 480,
you will have bigger problems with GIMP than just the new image dialog
going off the screen.
Since the new image dialog is unlikely to be open very long, how much it
occludes other windows that are in use is unlikely to be an important
Even if real estate was an issue, the mockup in total is 32 pixels longer
than the screenshot you posted yesterday. The difference in real-estate
usage is not that great, and would probably be mitigated almost completely
if the same theme was used in both screenshots. I should note that the
screenshot posted yesterday wouldn't fit on a 640 x 480 display, either.
Regardless of whether minimizing screen estate is a priority for the new
image dialog, given the previously discussed utility of the icon, I would
argue that it is a very effective use of real estate.
In fact, I experimented with several layouts for the memory required
portion of the dialog. Some had icons and some did not. For those that
did have icons, I experimented with the size of the icon and with hiding
it when the memory requirements did not exceed the threshold. This layout
was by far the most effective, and that is why it is the one that you see.
It is the most effective because it is a slightly miniaturized version of
the standard HIG information window layout, and so, since it is consistent
with other applications, it is immediately identified by the user for what
it really is.
Furthermore, the icon area is designed so that it can accommodate vast
changes to the size of the dialog while still being aesthetically
pleasing. Without the icon area, there is no good way to accommodate
extra space along the Y axis. For this reason, I say that the icon area
is an excellent use of any extra real-estate. I encourage everyone to
download the .glade file and see for themselves.
For what it's worth, the icon isn't as big as you might think.
Eliminating it would decrease the vertical extent of the dialog by six
pixels (which you can see for yourself by experimenting with the dialog in
Glade.) The spacing to the left of the icon makes the memory required
area look bigger than it is, but this is an optical illusion.
If the left spacing is the issue, that can be easily changed, although it
should be noted that the exact algorithm I used to determine the amount of
spacing was emperically determined to be the best for a wide variety of
> distracts from the important parts of the dialog.
You can hardly call the information icon distracting. It would be hard to
design a less-distracting icon. The user will notice it when first
scanning the dialog, of course, but is unlikely to give it any further
thought other than "that looks professional."
When the icon changes to the warning icon, that is distracting, but it is
so on purpose.
The real issue is that the memory requirements section was not labeled
before. It was not clear what it meant. A user could reasonably infer
that if the dialog displayed "5 MB" that that meant that when saved as a
JPEG, the file size of the new image would be 5 MB, or any other number of
reasonable conclusions, since many different aspects of an image can be
measured in bytes. In the mockup I proposed, it is clear what is being
measured, and it is located at the bottom of the dialog, which is
consistent with the fact that it is a display of some of the results of
the input to the above controls.
It should be noted that you yourself considered the memory requirements
display to be important enough that it is featured in the unexpanded view.
If it is important enough to show, it is important enough to show
> Centering the unit menu next to the size entries does IMO look horrible
> since it deviates from the table layout of the dialog.
A slightly ironic comment, since the centering was implemented using
There's an idiomatic English expression that fits here: "There is no
accounting for taste." While I feel that centering the units dropdowns is
more aesthetically pleasing, as it has a more balanced look to it, I can
understand that others may feel differently. If this really were simply a
matter of aesthetics, then the logical thing to do would be to see what
the preference of the majority of the developers would be, and to do that,
since we want the dialog to look the best for the majority of the users,
and that is about the best sampling that we could reasonably do.
However, aesthetics was not the reason I made this change; there is a much
more important usability factor involved here. As the HIG states, "Visual
design is not just about making your application look pretty. Good visual
design is about communication. A well-designed application will make it
easy for the user to understand the information that is being presented,
and show them clearly how they can interact with that information." The
changes I made make the dialog much more effective at communicating to the
user the mechanics of the dialog.
With the units dropdowns positioned the way they currently are, it is not
immediately apparent that they apply to both of the entries. Aligning the
dropdowns with the bottom entry is especially bad because the first entry
is completely scanned before the dropdown is scanned. By aligning the
controls the way that they are, it take a lot more processing to realize
that the units dropdown applies to the entry above as well. This
processing has to take place at a very high level; it requires actual
conscious thought. To communicate less effectively, the dropdown would
have be be located in a completely separate part of the dialog from the
entries it affects.
By far the best layout is to center the control, because then the
applicability to both elements is most obvious. The human visual system
groups all three controls together, and so it would take conscious
processing to disassociate them instead; in other words, you get the
association for free. A distant second best would be to align the units
dropdown with the topmost entry instead of the bottommost. That way still
requires some conscious processing, but at least one wouldn't have to
backtrack to find which entries the dropdown applies to.
> Using a frame for the template selection seems wrong because a frame's
> supposed to group elements. The template menu is a single element
The problem here is that the existing layout breaks a cardinal rule of any
kind of layout: the dialog elements are not treated consistently. The
controls in the "Image Size" and "Advanced" groups are labelled with
headings, but the template control has no heading at all. This lack of
balance makes the template dropdown look like an afterthought. Originally
I simply bolded the Template: label, which made it look more balanced, but
the dropdown still looked out of place, so I indented it.
I agree that using a regular old frame would look bad with a group of one
element (although I have seen that done effectively before, even in the
GIMP) but the new "heading" style is a different animal. It separates
less and labels more, and since its characteristics are so different,
layouts that would be acceptable with one do not necessarily translate
into being acceptable with the other.
Users are quite familiar with seeing headings in other kinds of layouts,
and so it simply looks wrong if the conventions of conventional headings
aren't used here. I agree that there is still room for improvement, of
> and in your mockup it stands completely unlabelled.
This is not unlike the orientation buttons and memory size display in the
I agree that a label would make the dropdown seem less out of place, but I
left one off for the simple reason that I couldn't think of a good one.
Perhaps "Apply:" would work here? Or perhaps the heading should be
something else and the label would be "Template:"
Placing the template as part of the size group won't work because the
template influences more things than just the size. I also don't
think that templates should be place in the Advanced group.
> I think Jimmac and Tigert did a very good jo with their mockup and I
> don't see much room for improvement. IMHO we should stick to it.
This sounds very closed minded. The dialog proposed by Jimmac and Tigert
was a big improvement over the old one, but to say there is hardly any
room for improvement smacks of hubris. Even if you didn't see any room
for improvement when you wrote that, it does not in any way mean that
there in reality isn't any, or even that you won't see any room after more
Indeed, there still are real problems with the new image dialog. For
instance, the link control in the CVS dialog has no affordances; a user
may very well be unaware of its purpose, and also very well may
simultaneously be frustrated by being unable to change the "linked"
behavior. As another example, even though we now have the image mode in
the "Advanced" group, it still could be useful to warn the user of the
consequences of using indexed mode. Ignoring these problems won't make
them go away.
It is senseless to close discussion on this dialog so soon, not just
because of the areas of improvement we already know about, but because we
are still getting used to the newness of the current layout and so have
not yet been sensitized to all of the relevant issues. Discussion should
continue until everyone is as confident as you apparently were that there
is no real room for improvement, and even then, we should keep an open
mind towards any new suggestions or observations about problems.
I welcome your constructive comments, as well as the feedback of the other
developers. I am especially interested in the thoughts of those with more
training and experience in usability than I have, like those in the HIG.
Gimp-developer mailing list