[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thoughts on usability of tutorials [Was: Making eev use a "smaller f

From: Esteban Ordóñez
Subject: Re: Thoughts on usability of tutorials [Was: Making eev use a "smaller full screen"]
Date: Wed, 21 Dec 2022 00:25:27 +0000

>> If you would go a little slower, it would help me a lot.  When you
>> explain, you go ahead and cover many things which are not my current
>> problem.  That makes me get lost about which are the steps I have to
>> take.  I do not have the criteria to know which of the informations
>> that
>> you provide is the one to use at that moment.  So I get paralyzed
>> and
>> just abandon.  (Of course that trying anything would be the right
>> course.  But it is not my normal reaction.)  I am very stubborn.  So
>> I
>> come back motivated by my belief that eev uses the correct policy
>> for
>> making machines: the most hackable construction, so that the user is
>> not
>> a slave to the machine, but its master!
>> The current problem that I have could serve as an example.
>> El 2022-12-19 23:51, Eduardo Ochs escribió:
>>> 1. Run this to download or update the subtitles for a certain
>> video:
>>> (find-psne-eevvideo-links "2021-org-for-non-users" ".vtt")
>> When I evaluated this hyperlink, a new buffer popped up as I have
>> been
>> accustomed to.  That is not complicated.  But that buffer contains a
>> lot
>> of information.  There are two keybinding which I have learned that
>> I
>> have to employ in these situations, F8 or M-e.  So when I use either
>> of
>> these keybindings, something will happen.  I do not understand
>> exactly
>> what happens.  (Lately I understand more.  But I do not follow the
>> direction that I need, it is just a flow.)  I have to do that
>> because I
>> do not really know what to do.  Sometimes I have to kill some of
>> those
>> buffers with M-k: when I either do not understand what has happened
>> and
>> hope that the commands do what I needed to meet a precondition for
>> what
>> I wanted (for example download a video into $S in order for it to be
>> played or a document in order for eev's versions of find-file to
>> open
>> it) or when I have read all the document which is in the new buffer.
>> It
>> is not clear what is to be read for the current situation or which
>> part
>> of the video is relevant and where to stop.
>> So my recommendation for the tutorials is to just mention the basics
>> for
>> the issue at the time and have an area to go for more information.
>> The
>> fact that those two informations (specific and extense) are separate
>> would be very helpful to avoid getting lost in the beautiful jungle
>> of
>> completeness.  If there is a video, have information of what to do
>> in a
>> summary.  Then show all the information as optional additional
>> resources.  If there is a tutorial, mention a summary of what to do.
>> Then describe the steps in detail.  (I have seen this process in
>> some
>> tutorial whare you have employed this process.)  If there is a
>> question,
>> just mention the next step, not the whole process.  Be sure to ask
>> what
>> is the current situation.  Then you can learn what to recommend.  It
>> is
>> great to have the whole library of information.  But it is better
>> for a
>> newbie that there is an obvious route to take as the first baby
>> steps.
>> Later, the newbie will become an expert which will go directly to
>> the
>> card catalogue, remember those?  :-D  I used to run away from those!
>> But I do think that they are useful when you know how they work.

I do think that this is a complete explanation of what could probably be
done.  But I do not think that you have understood it.  Perhaps I should
explain it better.  I don't think that you would want your tutorials to
be hard to understand for newbies.  I understand that you do not agree
with me.  But I do not understand why you want to do it that way.  Don't
you agree that helping newbies distinguish the relevant from the
irrelevant would be useful?

> You said (obs: sorry for the weird format, I am on a cell phone):
> Then show all the information as optional additional
> resources.  If there is a tutorial, mention a summary of what to do.
> Then describe the steps in detail.  (I have seen this process in some
> tutorial whare you have employed this process.)
> Can you try to remember what was the tutorial in which I did things in
> a way that worked for you? I think that one of my main problems is
> that I don't know what are the questions that people have, and it's
> very hard to get them to ask these questions... so when I interact
> with people by IRC I can usually solve lots of people's problems in
> five minutes, but by e-mail, or by docs and tutorials, the same
> problems take five years to be solved...

I am sorry.  I just tried to generalize from the example that I
presented on a provious email and cited above.  My problems are not in a
specific tutorial.  It is general on all tutorials.  But if it easier
for you to understand, I clarify when you ask.  I don't know how other
people work.  But I know that simple has no wrong route.  The
completeness can be there without it making the basic get lost.

I tried to contact you many times on IRC.  But usually you are not
present at the times that I connect.  Today I waited all day.

> Let me give an example. If a person asks "how do I change the default
> PDF viewer?" in many cases the real question is "how do I change the
> default PDF viewer in a way in which I can understand what has been
> done?"... and for some people a recipe using customize is the best
> way, for others a setq is best, and for others, like me, a setq
> preceded by two hyperlinks in comments that point to the docs and to
> the source code is best, because I am very good at noticing that the
> comments are pointers that can be ignored...

Exactly!  That is what I mean.  A method to make parts to be ignored be
less noticeable and the most important parts stand out would be very

I think that asking that the questions be clarified could help you
define the questions better and answer what is really the problem and
not what a certain perception would be.

> Some of the feedback that I receive on eev is from people who try to
> explain to me how they function, and they say things like: I am
> totally unable to skip over irrelevant information - every time that I
> read a page that has hyperlinks I read it linearly until I find the
> first hyperlink, then I follow that hyperlink, then I read that other
> page from the beginning until I find the first hyperlink, then I
> follow that hyperlink, and so on. Can you rewrite your documentation
> so that it will work for me? And I only know how to answer that in two
> ways: either with a "no" or as in one of the Zen koans about
> programming, in which, say, Master Sussman puts the sheet with the
> questions in the toaster, "and then the student was enlightened"...

I don't understand the second part.  But I will just have to keep on
trying the way you have constructed it before, if you are not interested
in my sugestion.

> Anyway, are you sure that what you asked above are your "real"
> questions? Because... well, let's imagine that you change them to the
> following. Let's imagine that you are on IRC, and you ask: "people,
> how do you read manpages and source code? How do you decide what to
> focus on and what to skip?"...

That question could mean many things.  But by clarification of the
question, it would be eventually solved.  I feel that IRC is less
optimal because my issues allow less time than email to properly be
explained.  But I understand that others which are more intuitive and
creative can be more comfortable in environments where spontaneity is
handy.  Anyway, I will use the communication medium which you decide.

Thank you very much for your help!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]