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

(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

(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.


Gimp-developer mailing list

Reply via email to