Re: How to make Emacs popular again.

[Jean Louis <bugs@rcdrun.com>]

* Eli Zaretskii <eliz@gnu.org> [2020-09-26 21:12]:
> > Date: Sat, 26 Sep 2020 20:36:51 +0300
> > From: Jean Louis <bugs@rcdrun.com>
> > Cc: jamtlu@gmail.com, emacs-devel@gnu.org
> > 
> > * 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.
> 
> Each one of us expresses his or her own opinions.  It's a trivium.

Sure, but we talk about users, so to say that one cannot learn the
stuff in general, should be supported by some kind of a survey. The
fact is right now is that not every tooltip is usable, so fact is now
in present time, that in my particular example, I cannot learn several
words.

So it will happen to new user to get confused. Users expect tooltips
to describe the function, and description shall be made better
understandable. 

> > I tried finding what should undecided-unix mean, and I cannot find, I
> > just found that "unix" is alias for "undecided-unix".
> 
> Type "C-h i m emacs RET i undecided RET", and read there.

I did not find the definition for undecided-unix by following your
example. That it is alias, does not define it.

> > Does the tooltip assume that only experienced user, in this case,
> > experienced developer is to know what it means?!
> 
> Not "experienced", but one who have read some minimal introductory
> material about the Emacs UI, and/or have learned how to use the manual
> to search for (as yet) unknown concepts.

For that group of people I disagree they need any tooltip
then. Tooltip is for users to understand it, it is not for Emacs UI
skilled people. It is for unskilled.

> > tooltip should help the user understand what is it.
> 
> It does.  It just doesn't (and cannot) explain everything, because a
> tooltip is a small widget which cannot display a very long text, and
> because clicking on the text in a tooltip is impossible, at least in
> some/most toolkits we use.

The point is not one tooltip, there are many examples, yet it is hard
for you to see what I see, and what could be obvious to many, that is
why few threads have been spawned here.

In marketing, I always learn to look from client's viewpoint. 

> > 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.
> 
> The logic is that when they find some term that is not clear, and the
> text there doesn't have a hyperlink to where that term is described in
> more detail (there usually is), then the user should go to the
> Glossary and search the term there.

Sure, you know it. But does it say anywhere? Does it guide the user?

Emacs as Lisp have all the capacities to guide the user. It has the
capacity to provide a humorous psychoterapist, so it can also guide a
user in better way.

> > > > 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.
> 
> Once again, there are limitations of what can be usefully said in a
> short menu entry and its tooltip.  If you have practical suggestions
> for how to use up the available screen estate better in that case,
> please propose how to improve the wording we have there.

I think that general principles shall be set first, as to improve
wording, there are so many that could be improved, the descriptions
should not be written in first place that do not describe it
meaningfully. So I do not speak of a specific bug, I speak of general
flaws hindering understanding for users.

> > > 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.
> 
> So am I.

Alright, then your viewpoint for new users is way advanced. You are
targeting various groups, not only Unix hackers or experienced users
or UI skilled users.

> > Even "Search files..." is not well described. You cannot possibly
> > design any interface for new user with experienced user viewpoint.
> 
> Once again, the menus assume a certain level of understanding and
> expectations.  You are claiming that those assumptions are incorrect,
> but the solutions you propose are simply not practical, as they ignore
> the basic limitations of the screen estate we have for this, and would
> make the doc strings impractically verbose and full of loosely-related
> background information.  Our policy is to leave the extra information
> for the manual.

The doc string, if it is taken out of it, that relates to Search
files, should be more descriptive.

From grep manual:

       grep searches the named input FILEs for lines containing a match to the
       given PATTERN.  If no files are specified, or if the file “-” is given,
       grep  searches  standard  input.   By default, grep prints the matching
       lines.

So something like:

Search files (Grep...) is using the external shell command "grep" that
searches the named input files for lines containing a match to the
given pattern.

That would be in this particular example much better described then:

> <menu-bar> <tools> <grep> runs the command grep (found in global-map),
> which is an autoloaded interactive compiled Lisp function in
> ‘grep.el’.

> It is bound to <menu-bar> <tools> <grep>.

> (grep COMMAND-ARGS)

>   Probably introduced at or before Emacs version 1.4.

> Run Grep with user-specified COMMAND-ARGS.
> The output from the command goes to the "*grep*" buffer.

> While Grep runs asynchronously, you can use C-x ` (M-x next-error),
> or RET in the *grep* buffer, to go to the lines where Grep found
> matches.  To kill the Grep job before it finishes, type C-c C-k.

> > We speak here more of principles of design of the interface and
> > descriptions. Practical implementations may come later.
> 
> Emacs already does have the practical implementations.  They are
> well-thought and are being constantly improved.  There's no need to
> start from scratch, as what we have already is a reasonably good and
> newbie-friendly UI.  It is newbie-friendly because the Emacs
> developers of past and present invest a lot of efforts into making it
> so.

I don't say from scratch, many things are already there, descriptions,
Info, docstring, I just speak of better connectivity to instructions
and to information and improvement of those sentences that appear not
understandable to average computer users, with the purpose to bring it
to more users in the world.

Myself personally, I like it how it is, but to draw new users, it has
to become fancier, easier, moderner, use any attribute here, the point
is that it does need that group of improvements that will attract
larger users' base, and not have them reject it.

It is good to read what some people are writing here:
https://news.ycombinator.com/item?id=24593616&p=2 so read those
comments and see.

Jean