Re: One vs many directories

[Jean Louis]

* Ihor Radchenko <yantar92@gmail.com> [2020-11-26 16:29]:
> > Sorry for that vague expression. Let us say I open Completions buffer
> > I can switch into it, inspect it, ask for defined keys, evaluate with
> > M-:, Emacs allows me to remain in the window and go to other
> > window. Agenda buffer does not do that, this is probably because it
> > just waits for any key and does not allow anything else. That means I
> > will open Agenda and I cannot switch to other window, so I will close
> > agenda to switch. Maybe I have 10 TODO keywords, I have to open file,
> > I open Agenda again, aha, T... then close agenda, open file see
> > keyword, then open agenda again. Repetitions without end and user is
> > unable to use multiple windows. This really need not be so.
> 
> It appears to me (correct me if I am wrong) that you haven't tried
> agenda multi-occur/keyword/etc searches.

I know multi-occur and tried it. Functions of org-agenda are useful
while initial menu window of org-agenda is so much less useful and I
speak of menu, not of individual functions. If it is Org agenda, I see
no reason why it could not be displayed in Org mode being read-only
and having buffer not killed when user press q.

We spoke of standard Emacs way. Normally buffers are not killed. If I
press q in Dired buffer is just buried, not killed. I find Org agenda
useful and I would be maybe moving to *Agenda Commands* buffer by
using (next-buffer) and (prev-buffer) and those are key bindings like
hyper key - move-end-of-line and hyper key - move-beginning of line.

It is my standard behavior to move to one buffer and go to other
buffer.

User could have one tab open for Org agenda menu, other tab for
work. Why invoke all time C-c a to access org agenda.

I am not speaking for me personally, I am giving you clear comparison
of that menu to mu4e or org-agenda menu and other pop-up features that
do not block user in using Emacs. Org agenda menu blocks the
interface!

When invoking package-list-packages it does not block me moving to
other buffers and also offers complex menu system and key
bindings. Buffer is not killed but burried when I press q.

Functions of org agenda are fine, this is reference to blocking of
Emacs interface while opening Org agenda buffer. It diminishes
usability.

I guess nobody cares. It is how it is. No need to consult external
references such as
https://www.nngroup.com/articles/usability-101-introduction-to-usability/

No need even to look how other parts of Emacs are interacting with
user and to harmonize the menu. 

> > You know how agenda is made like the 1985 BASIC menu in Commodore
> > C=64, but even back then there was better interface for such menus.
> 
> FYI. Transient.el - menu dispatcher in popular magit package also does
> not let you switch buffers. So, apparently many people would not agree
> that it is so terrible design.

Compare things to things that are better not to things that are
worse. 

You have to read more about usability. To know what is the problem you
have to research and not assume that if nobody says anything that it
is usable enough. Nobody complains. I did not hear complain, so it
must be perfect. Irony. That is not how interfaces get improved and
definitely not how developer would discover if something is wrong.

If developer is waiting for somebody to complain that will be too
late. Thousands of users will have problems that were not told to
developer.

Was there any methodology to decide what is good user menu?

Reference:
https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/

Was there any survey here to ask about any usability?!  Hypothetical
question.

> P.S. Nothing prevents you from calling, i.e. M-x org-occur or binding it
> to a key of your choice.

Personally I know that. I speak for general usability. You know that I
have my system of doing things with or without Org mode.