I'm vividly reminded of my software engineering professor's lecture on Friday, where he talked about how after someone has done something, when that person talks about it, they assume that the person listening realizes a lot of details that speaker doesn't explicitly say, yet the listener does not know, due to the lack of shared experience. Specifically, in this case, I assumed everyone knew I meant very small images, probably about 48x48 or 64x64. I assumed that people would realize bigger images would make the dialog awkward and use more disk space than provide benifit. (bex: the "they" in that sentence is grammatically correct -- see http://www.crossmyt.com/hc/linghebr/austheir.html for details. The extract from The Language Instinct that is linked in the bibliography has an excellent discussion.) With that out of the way, I'd like to make some specific replies to points that have been brought up. Since so many comments were similar, I have combined my responses together to form this (rather lengthy!) reply. On Sat, 6 Oct 2001, Daniel Egger wrote: > No, I think the tips should be kept rather simple. On 6 Oct 2001, Sven Neumann wrote: > perhaps I'm imaging something wrong here, but I think graphics would be > overkill for the tips. The intent was not to add a lot of complexity to the tips, nor to change thier purpose. The intent was to add to the expressiveness of the tips, which would lead to a corresponding increase in thier usefullness. Perhaps the example I gave was worse than I thought, which as I expressed, was that it was less than optimal. Later on I will try to provide some better examples of where it would be useful -- and useable! -- to have some small graphics in the tips. I must say that I am surprised and amused by the resistance people have to the idea of images in the tips box, this comming from the developers of a program that is highly graphical in nature, people who one would think would understand the value of images. I understand the mentality, of course. I only launch X when I need to run an X app, and I much prefer to program in vi on multiple virtual text consoles. Text is powerful enough that it is almost good enough for everything I do -- why should I throw in images where it is not strictly necessary? On Sat, 6 Oct 2001, Guillermo S. Romero wrote: > Graphics have a "small" problem: if it is not 110% clear, you need to > add text to explain it. That is why "Cut text" can be understood > better than "8<" icon. > Another thing, "cut the selection" is way better than "'dotted square' > then 8<" or "r then C-x" cos people can see and remember what they do, > while the others just show the graphics or the keys that can be > different from one place to another, but not the real thing that will > always happen and that should be easier to remember. This is why the combination of text and graphics is better than either alone. Creating a tips of the day box for illiterates would be frustratingly limited. Creating good image-free tips is also somewhat limited, because all of the tips must be limited by language and space considerations to what can be easily described by prose. Sometimes a picture really is the equivalent of a thousand words. To use the 8< icon as an example of the usefulness of a combined approach, were I to adapt the technique used by the application I am working on, the tip text for such an icon would be something like "To copy the selection and remove it from the image, press the "cut selection" button. ( 8< )" The application itself only uses an icon, and as is well documented, icons are not intuitive in the general case. The tip provides a concise statement that allows the user to form a mapping in thier mind between the icon and its function. This cannot be as effectively done with a description of the icon. Perhaps the loss is not apparent to a tool so engrained in the minds of the users of the modern user interface, and with an icon that is relatively intuitive, but consider the case of the gradient tool. Without graphics, an example tip might be something to the effect of "Click on the icon with the vertical gray stripes (it looks kinda like a TV test pattern) to create a smooth blend of colors. A variety of shapes are possible." (as an aside, if you don't know what cut and paste are, you are way below the scope of help that we can reasonably expect to provide, but it makes a good example.) On Sat, 6 Oct 2001, Guillermo S. Romero wrote: > Bumpmap can do different things, but you only show one, and at least > you have to show the original items (bumpmap and target layer). Or to > translate things to / from other apps, cos tutorials that tell you > "click here" are a pain to port to GIMP, but those that tell you "we > do this" are not, so tips that follow the trend would hurt more. The bumpmap example I gave was not the greatest -- it was intended to provoke brainstorming more than to be a concrete example. I agree that three images would be easiest to understand -- the two before layers and the after layer. I'm not sure that that would be best,however -- the dialog would be too big. An animated image might work better. The graybeards around here might remember my entry in the animated gif contest, where I took an image and applied bumpmap with depth=0,1,2,etc, causing the word "GIMP" to rise from the image. The text would explain that you use the gray level from the map image to set the height of the pixel. This seems to me to be a reasonable balance between the number and size of images and the amount of information conveyed. Let your imagination fill in any shortcomings that my examples may have. I am a programmer and not a professional technical writer. On Sat, 6 Oct 2001, Guillermo S. Romero wrote: > It is teaching in a way that people will never investigate, nor > develop their own methods. On the contrary, I believe that people are much more able to use a program effectively when they know what it does. You have to know what the features of a program are, be familiar with what they do, and experiment with them before you can develop your own techniques. When talking to the head usablity expert on my project, he gave a detailed list of principles that make a program more useable. Rule number 1 was that, "people never read the help file." That's probably a bit extreme, but the attitude is right. While most people are probably less likely to read the help when they know that they are being watched, the fact is that help files are not terribly effective at producing competent users, certainly much less effective than the average programmer, who is much more computer literate, would imagine. I was amazed when I saw my program been tested in the usablity labs and saw that people who rated themselves above average in computer literacy didn't even know how to resize windows. Shame on the usablity people for asking us to make that window that small in the first place, but the fact remains that we programmers often assume that the user will be able to use our programs as quickly as we adapt to new programmers. Even the best designed and written manual or help file is imposing. It is usually difficult to find what you need, because you have to know the exact terminology the program uses -- a case of having to know where to find something before you can find it. Windows users must also fight that nasty tree widget, but I digress. Help files are too long for casual reading, and don't draw your attention to the specific bits you need, like the tips dialog does. They are usually written at a level too high for the beginner, yet too basic for the advanced user. Due to the reasons described in the first paragraph, they almost invariably leave out critical pieces of information. Often they also overcorrect and include information that would insult the intellegence of my ten-year-old sister. Writing good documentation is daunting; I don't envy those who do it, but I have a lot of respect for those that do it well. This is not to say that documentation in the form of help files needs to or should be elimitated. But it must be supplemented by techniques that give the user the basic core competency to be able to use the application. The help file cannot be the only resource readily available if we want the number of people who use GIMP to increase. Of course, the best technique is that of an actual human being instructing the user in the use of the program. Obviously, we can't include a copy of yosh with every download of the GIMP to explain to the user what to do, and companies are not yet lining up for GIMP training for thier employees. Fortunately, there are other techniques. GIMP has a steep learning curve. It is beyond my imagination to think that a program such as GIMP could be designed in such a way that no external training of some form -- web, book, help file, homo sapien, whatever -- would be required for a person to become an expert in it. In fact, all of those methods are probably required. Yet more can be done to lessen the slope of that curve. One day my stepmother was interested in what that program was that occupied so much of my time and thoughts, that program that I constantly raved about. I downloaded a copy of WinGIMP for her and tried to show her the program. Immediately after she saw the nested menu structure she decided that the program was too complicated and soon lost interest in it. I have seen other people struggle with other aspects of the program as well, to varying degrees of success. In the 0.99.x series we realized that the learning curve for the program was too steep, and the tips of the day dialog was added. It was an immense improvement and immediately we saw a decrease in the number of certain basic questions on the mailing list. I do not criticize what has been done with the tips so far. I say that more is needed. We need the tips of the day to be able to take someone who has never used an image editing program before, and get them up to Paintbrush-level functionality quickly, and then beyond. It shouldn't replace the help files and user groups and web sites and tutorials and newsgroups and mailing lists, but should work hand-in-hand with them. Don't think that I am suggesting we implement a crippleware user experience level system -- many people are afraid to increase their level, and we cannot know what the average "beginner" is going to want to do. Nor am I suggesting a patronizing or officious system like everyone's friend Clippy. It is possible to lead someone step-by-step without handholding, but it is easier to give suggestions and the freedom to roam. Assume the user has a basic level of intelegence and proficiency, and lead the person to greater levels of competence. The tips file already implements this -- it just needs more. Plug-ins should also be able to add thier own tips, and be able to set the competence level the tip is displayed at. By giving the user an non-intrusive yet proactive suggestion (at the start of the program), the user is free to choose to persue the suggestion given or not. The user is seldom annoyed, and if he or she is, they can turn it off easily. On 6 Oct 2001, Sven Neumann wrote: > It would probably help to allow links to help pages in the tips > dialog... On Sat, 6 Oct 2001, Daniel Egger wrote: > But what I can imagine is a link to the correct sections in the manual > to look up more information on the tip. On Sat, 6 Oct 2001, Guillermo S. Romero wrote: > OTOH, having a "tell me more about this" that links to tutorials on > help system, webpage or any other docs would be nice. There you will > be able to show all the steps, comment all the options to reach some > point, put anims, show input values for the example and recommend > ranges for others cases... I see (properly done) tips as that, tips, > to give small concepts, maybe be the trigger some sparks in the mind > of the reader, not more. This is a great idea! Truly an innovation. Note that the help cannot replace tips, nor tips the help, but by adding the links we allow the user to explore more. The tips can't just be "click here to learn about the Transform Tool." But perhaps, "You can use the transform tool to stretch images into different shapes. Click here for more information." Whenever possible, the tip should be enough by itself for most people, but for more complex operations, this is not possible. This technique balances the size and amount of information, and allows the user freedom to explore. The help file should not be the only links -- to truly master GIMP you must learn lots of hacks and tricks that I would never imagine, and neither would probably most anyone else. They are the collective experience of thousands of talented artists. Space and bandwidth considerations prohibit us from including tutorials with the GIMP distribution, but we can and should link to them in the tips. Since we cannot control outside sites, all links should be redirected from www.gimp.org to the correct site, perhaps with a mirror in case that link changes. (I can see carol rolling her eyes already. :) If we get really ambitious we could even implement a method for the tips with tutorial links to be dynamically updated on a regular basis, with new tips added. And then we can get arround to fixing the bugs in the world_peace plug-in and get it released. ;) On 6 Oct 2001, Rebecca J. Walter wrote: > Maybe in the future, after we (we mainly means syngin) have finished > documenting all the stuff that HAS to be documented, it might be nice > to add some tutorial-like docs to the help stuff. Then the tips could > link to some of that stuff. But I can definitely see a lot of > potential in linking tips to the help. That way the tips can be > little tidbits that then link into the help to give more information. > I don't know that any of the help people have time to make changes > like this in the present, but I can see a lot of potential in it for > future development. It is nice to leave room for future development. Finding people willing to do implementation is always a challenge for any open-source project. I am willing to stand up and pledge to spend some time making the tips better, both on the coding and writing side. (although Mitch will probably fix my coding and bex will probably fix my writing :) I see a lot of potential for making GIMP more usable. Another one of those rules the useablity expert taught me is that if a user doesn't know about or understand how to use a feature, it effectively does not exist. On 6 Oct 2001, Sven Neumann wrote: > and [links] would also be much simpler to implement than text flow > around image boxes (unless you want gimp to depend on gtkhtml2 for the > tips). I hadn't considered implementation. I certainly don't want to write code to handle text flow. On my project we used an off-the-shelf rtf widget, which was good enough for us. Unfortunately there isn't really an equivent in standard gtk. Tips alone are not worth more dependencies. OTOH, putting the images to the side of the text would not be hard at all to do, thanks to the wonders of hboxes. I can't think of an example when we would really need more. Rockwalrus
