Re: How to make Emacs popular again.

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-09-26 19:55]:
> You cannot learn this stuff by walking around the UI and reading the
> tooltips.  It's unrealistic.  Those tooltips assume some minimal
> knowledge of the terminology and the UI elements, which are described
> in the tutorial and in the first chapter of the manual.

It is your opinion.

I tried finding what should undecided-unix mean, and I cannot find, I
just found that "unix" is alias for "undecided-unix".

Does the tooltip assume that only experienced user, in this case,
experienced developer is to know what it means?!

You say that it is described in the tutorial and in the first chapter
of the manual, and I gave you example with one term "undecided-unix"
and it is not described or defined. It could be defined in the source
code, but tooltip should not be written with such assumptions, tooltip
should help the user understand what is it.

In general tooltips are good. I just say there is space for improvement.

> Making each term a hyperlink that leads to its description, then
> each term in that description a hyperlink, and so on and so forth,
> will in effect take the user down a huge rabbit hole.

Is not that complex, maybe you should try wordnut package, I am using
it all the time. I can find definition of the word "time" and I am
facing new split buffer and if there is other word I do not
understand, I can enter into its definition, and come back with "l" or
quit, so it is very easy to provide a system of defining terms, they
need not be underlined or highlighted as words. I think every term
should be reachable from Emacs, as defining and helping users define
and clear the meanings of words is what is making users understand the
Emacs. 

> Users who need to actually do something useful with their time, not
> just follow hyperlinks, will very quickly lose patience and stop
> following.

I just have a feeling you got that opinion too subjectively. In my
opinion, every word should be reachable, so that user can understand
everything, that was already principle of Emacs, that is why there is
{C-h k} or other describe functions. It just needs better
interactivity with users and improvements.

> > - Making Emacs friendlier will be easier with a built-in dictionary
> >   that will describe any terminology in easy English
> 
> We already have that: the Glossary section of the manual.  But I don't
> think taking the user there for each non-trivial word in our
> documentation is a practical idea, or even a good one.

If user cannot understand the word, then cannot understand the
sentence, so how it can be good to bring users to misunderstandings? I
don't get the logic.

What is good is to bring users to understanding.

> > - I press {C-h k} and then choose Tools -> Search Files (Grep)...
> > 
> > Side comment: if it runs "grep" command, I don't know why it is
> > capitalized, but alright.
> > 
> > I wanted to find out about "Search Files..." so the menu option is
> > pretty clear, it helps me search files, but then description about
> > "Search files" does not even mention the word "search".
> 
> Unsurprisingly, the doc string assumes the user already knows what
> Grep is.  So it doesn't say "search", because that's what Grep stands
> for.

>From the new user viewpoint I cannot possibly agree with that
explanation. Descriptions of menus should be accessible and
understandable for users especially from a new user viewpoint.

> Doc strings are in generally terse; if you want more details,
> including background etc, you need to read the description of the
> commands in the user manual.  There's a 95-line section there about
> M-x grep and related commands.

I am not speaking of myself Eli. I am speaking of new user viewpoint.

Even "Search files..." is not well described. You cannot possibly
design any interface for new user with experienced user viewpoint.

The "Search files" with grep would actually mean to search the files
containing certain term.

But for new user, "Search files" would probably mean to find those
files named "Alice-Homework.txt" or something like that.

It is good for developers to think more from a new user viewpoint.

Within Gnome, if you wish to find files, you open some find file
dialogue and you type file names and if it is using grep or not, why
it does matter? It does not matter for new user, as person wants to
use "Search files".

We speak here more of principles of design of the interface and
descriptions. Practical implementations may come later.

Jean