On 7 May 2004, Sven Neumann wrote: > Hi, > > Nathan Carl Summers <rock@xxxxxxxx> 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 consideration. 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 dialog sizes. > 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 correctly. > 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 GtkTable. :) 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 course. > and in your mockup it stands completely unlabelled. This is not unlike the orientation buttons and memory size display in the CVS dialog. 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 discussion. 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. Rockwalrus
