From: Jean Louis <bugs@gnu.support>
To: Tim Cross <theophilusx@gmail.com>
Cc: daniela-spit@gmx.it, emacs-orgmode@gnu.org,
Ihor Radchenko <yantar92@gmail.com>
Subject: Re: Adding Org Files to org-agenda-files
Date: Mon, 14 Dec 2020 02:28:11 +0300 [thread overview]
Message-ID: <X9ajiy/RgJ/OVJms@protected.rcdrun.com> (raw)
In-Reply-To: <87tuspidsz.fsf@gmail.com>
* Tim Cross <theophilusx@gmail.com> [2020-12-14 00:42]:
>
> Ihor Radchenko <yantar92@gmail.com> writes:
>
> > Dear Jean Louis,
> >
> > Thank you for the detailed insight into your extensive experience of
> > project management and practical planning. I do not have that much
> > experience, but can provide a significantly different point of view
> > related to my research work.
> >
>
> Some good observations. I have cut most of it out to stop the thread
> from becoming too long.
>
> I think it is very important to recognise there is no one way to do
> project management or organise a project. Different industries have
> different requirements. For example, project management requirements to
> build a bridge are very different from those to build the software that
> will be the next evolution of social networking sites.
I do recognize, but the Org manual does not:
(info "(org) TODO Items")
> 5 TODO Items
> ************
> Org mode does not maintain TODO lists as separate documents(1).
> Instead, TODO items are an integral part of the notes file, because TODO
> items usually come up while taking notes! With Org mode, simply mark
> any entry in a tree as being a TODO item. In this way, information is
> not duplicated, and the entire context from which the TODO item emerged
> is always present.
> Of course, this technique for managing TODO items scatters them
> throughout your notes file. Org mode compensates for this by providing
> methods to give you an overview of all the things that you have to do.
Thus the Org manual is already giving a technique for managing TODO
items and admitting it is scattering things. Why not then straight
give to users one page with at least 3-5 other paradigms that users
can follow. This way users follow only the scattering paradigm.
> The way Jean Louis describes project management sounds very similar to
> the waterfall methodology which was popular in software development up
> until the late 90s. It is a methodology that can work well when you have
> a well defined and understood project, like building a bridge where we
> have a couple of thousand years of experience and engineering
> knowledge.
It sounds right.
> It doesn't work particularly well with software projects and has been
> largely replaced by various 'Agile' methodologies which are similar to
> what you outline as your experiences and approach with research. Even
> within the software development space, you find considerable variation
> because different stages within the software life-cycle have different
> requirements.
You may be right, I never used Org mode to plan software. I know those
workflows and it should be planned and so on, but I don't. Instead of
planning I just make what I personally need.
> For example, during the R&D stage, there are far more 'unknowns'
> than 'knowns'. Often, many things will need to be tried and then
> accepted or rejected (suck and see). At this stage, you need to be
> fast and flexible with maybe 80% of ideas ending up on the scrap
> heap.
I like to see some concept. All our projects also have R&D
stage. Preliminary Site Assessment and Inspection project is
such. That is why it is part of the project. After that project has
been done the next project is devised. But there is overall plan that
says:
- do the R&D
- devise project for result from R&D
> You have limited ability to identify all the stages, all the tasks
> or make terribly accurate estimates on completion time.
That stage is defined on my side as part of the plan. We know that we
will have limited ability, but that is why projects can branch, expand
dynamically.
> Later, the software will move into production status. Things change
> considerably at this point. Here you need stability, reliability and
> performance. Changes often need to be justified from a return on
> investment perspective. There are fewer unknowns, more accurate
> estimates and better defined tasks.
Even this is qualification stage where it is obviously and your
description shows it, part of the overall plan.
> Is org mode suitable in all these scenarios? Possibly not or perhaps
> there are dedicated project management tools which are better suited.
> Org is not a project management tool, but it is a tool that is flexible
> enough for many people to use it for either project management or for
> part of the project management process.
As a document preparation system it is possibly suitable, more than
suitable for planning of what you described. And nothing you described
does not seem to fall out of planning capability.
Any scenario may be described by documents. General text is enough. So
Org mode is more than enough to describe such planning. Unless you
refer to something else than what I think.
As a planning system with TODO stuff, or actionable items, I am
arguing how useful it is in that scenario or any scenario. What you
described has its logic, chronology, it has its plan. You described
overall plan. Nothing different than my scenario. Paradigm is same,
maybe you do not see it. We have all time R&D and dynamical branching
of projects. But all that is part of larger plan.
Often we will not know where is the water source, how much water we
could get from specific water source, if water is polluted or used by
people that we should not use it and find other ways, if it is on 2
kilometers or 100 meters. That requires a project or branch to be
devised when the time comes. This is first done by people on ground
who propose the project then by collaboration it becomes well defined
and engaged. It can be that person need to go to other city to
purchase pipes for 2 kilometers and couplings and that person need to
talk to chairman and neighbors where the pipe passes and that
collaboration of many people is necessary until water may be brought
to the place. Many things may be involved only to bring water to the
site.
But the plan says:
- conduct Preliminary Site Assessment and Inspection (project in itself)
- solve water supply (make project yourself)
> To argue for a specific workflow using org mode in a specific manner
> with only the task types you believe are relevant fails to recognise the
> vast differences in requirements everyone has or personal preferences in
> how individuals like to manage their projects or information.
Everybody has personal preferences. What I do not fail to see is that
many people popularize Org mode by using the scattered technique just
as advertised on the website, on videos, and Org manual, and just as
compensated by the org-agenda. Those others who handle their things
are not in the scattering group.
> The great power of org mode is in the ease to which it can be bent
> to fit with the individual's preferred workflow.
Org mode is too much high level. There is no inherent power in
itself. Put a person behind computer and observe how that person
"plans" or do anything with Org mode and inspect.
Today we discussed on different mailing list about the menu item Tools
-> Search files (grep) and Tools -> Recursive grep and main developer
finds the option user friendly, I don't find the option user
friendly. Then I ask staff member, geologist in Tanzania, who anyway
used computers for many users and finished doing Emacs tutorial if she
can understand what is "Recursive grep", so there is no way. She would
not be able to find files by using Emacs. For full understanding one
has to know GNU/Linux or BSD/Unix command line and to know what "grep"
means in the first place, and then one has to have experience of using
it and then one can understand "Recursive grep".
And I compare that real life inspection of Emacs usability to your
statement of great power of org mode and easy it can be bent to fit
whatever workflows. That is what you think, I do think the same, but I
do not agree it is user friendly.
Among all various free software note taking applications it is
probably unfriendliest. I also love it, but I look at its face without
closing my eyes (or one eye).
TiddlyWiki note taking in a browser
https://tiddlywiki.com/
That note taking application can be also used for planning. If
information is stored on remote WebDav server maybe it could be used
even for collaboration. But it is intuitive and more accessible than
Org and way better usable than Org.
Or:
Cherrytree - hierarchical note taking application with rich text and syntax highlighting
https://www.giuspen.com/cherrytree/
Everybody can make a test:
- open up Org mode in Emacs, and call somebody who used computer, but
never Org mode and tell him to make a note, or task
- open up TiddlyWiki, Cherrytree, Joplin, Turtleapp, Leo editor and
then tell him to make a note or a task
- let them create project of 3 items in each of those.
- write down your findings and bring it here that we may make
conclusions what Org mode needs to catch up with those maybe
friendlier tools.
Using family or friends is fine. I would like to see how it will look
in Org mode, probable scrabble that does not look like anything that
experienced people do with Org mode.
Love is a strong bias or prejudice. We love it, we have
prejudices. But where is comparison?
> This is significantly different from many other solutions which
> require you to adjust your workflow to fit with the tool.
When you say it I find it funny. Yes, Cherrytree and TwiddleWiki and
others will ask you to adjust to fit to the tool. There are subtrees,
headlines, rigidness, etc.
But how much is Org asking us as users to fit with the tool?
Tremendously, uncompared to anything else!
- try opening Org menu item and if you have more than one agenda file,
you will not be able to use the mouse to come to the documentation
section. Usability? From 1 to 10 I rank that to 1. User would need
to learn from somebody that mouse pointer has to be moved away from
the drop down menu to go around, to skip the agenda list of files,
so that it may reach down to Org documentation (maybe this is why
there are not many bugs reported)
- did we already say that Export menu does not fit well on the screen?
Terrible usability. We can customize what to export but we cannot
practically use it on screen. We talked about Org capture screen
being too small. Not only that user has to adapt to the tool, user
is asked to learn Emacs Lisp. I find that positive in one way,
rather negative in practical as such learning requirement is too
steep!
- this list of our adaptations to Org may be followed
indefinitely. User cannot find some feature useful, the answer is
more or less that user can make it. If not user maybe somebody makes
it simply. Ah, something does not work. We are Wizards of Oz, we
just use Emacs Lisp and look hey, it does work now. Ah, again
something does not work, ah there is solution, just learn Emacs Lisp
and it works. I don't mind, I enjoy that, but adaptation never ends,
software never completes, and usability does not raise.
I have three people in this house and each of them would be able to
use Gnumeric spreadsheet for planning but not Org mode. Taking notes
is not intuitive in Org mode. Even making a headline is not as
intuitive compared to all those other tools.
I did listen to the advise: if something does not work, you can DIY,
so I did myself what I need myself. I skipped the great Org and placed
it as a possible node between all other nodes which can have any other
mode: markdown, asciidoc, rst, txt2tags, you name it. Implementing
babel-like functions is also possible and user extensible in much
simpler way than hard coding it with Org babel. Cherrytree also leaves
code blocks user extensible, just decide how to run it yourself. No
need to hard code.
> The great weakness with org mode is that this tends to make everyone
> think they have found and defined the ultimate approach, which can
> easily reach religious heights and inspire a missionary zeal to
> evangelise their perception of the world. -- Tim Cross
I do not see that as weakness, I do understand you and where you wish
to go, but no.
Great weakness is its foundation as how it was designed only for
advanced users using Emacs who cannot understand they are advanced
users and so everything becomes little bit or much hackish and that
does not really help great number of people who hear about Org mode as
"powerful" tool.
Jean
next prev parent reply other threads:[~2020-12-13 23:32 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-28 15:39 Adding Org Files to org-agenda-files daniela-spit
2020-11-28 16:51 ` Jeremie Juste
2020-11-28 16:54 ` daniela-spit
2020-11-28 17:01 ` daniela-spit
2020-11-28 17:41 ` Jeremie Juste
2020-11-28 18:12 ` daniela-spit
2020-11-28 18:30 ` daniela-spit
2020-11-28 18:43 ` daniela-spit
2020-11-28 19:01 ` Jeremie Juste
2020-11-28 19:16 ` daniela-spit
2020-11-28 19:26 ` Detlef Steuer
2020-11-28 19:44 ` daniela-spit
2020-11-28 19:55 ` Jeremie Juste
2020-11-28 20:06 ` daniela-spit
2020-11-28 20:11 ` daniela-spit
2020-11-28 20:27 ` Jeremie Juste
2020-11-28 20:40 ` daniela-spit
2020-11-28 21:32 ` Jeremie Juste
2020-11-28 21:45 ` daniela-spit
2020-11-28 23:18 ` Jeremie Juste
2020-11-28 23:29 ` daniela-spit
2020-11-29 1:36 ` Tim Cross
2020-11-29 2:54 ` daniela-spit
2020-11-29 3:51 ` Tim Cross
2020-11-29 4:05 ` daniela-spit
2020-11-29 5:23 ` Tim Cross
2020-11-29 9:30 ` Jean Louis
2020-11-29 6:50 ` Jean Louis
2020-11-29 6:41 ` Jean Louis
2020-11-29 12:28 ` Ihor Radchenko
2020-11-29 13:00 ` Tim Cross
2020-11-29 17:11 ` Jean Louis
2020-11-29 17:05 ` Jean Louis
2020-12-01 2:24 ` Ihor Radchenko
2020-12-01 8:59 ` Jean Louis
2020-12-13 15:36 ` Ihor Radchenko
2020-12-13 16:27 ` steve-humphreys
2020-12-25 2:17 ` Ihor Radchenko
2020-12-13 20:21 ` Jean Louis
2020-12-13 20:59 ` Tim Cross
2020-12-13 21:59 ` pietru
2020-12-13 23:28 ` Jean Louis [this message]
2020-11-29 4:46 ` Jean Louis
2020-11-29 14:46 ` daniela-spit
2020-11-29 17:01 ` Tim Cross
2020-11-29 17:38 ` daniela-spit
2020-11-29 20:55 ` Jeremie Juste
2020-11-30 0:21 ` Tim Cross
2020-11-28 23:36 ` daniela-spit
2020-11-29 5:51 ` Jean Louis
2020-11-28 20:28 ` daniela-spit
2020-11-28 18:50 ` daniela-spit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=X9ajiy/RgJ/OVJms@protected.rcdrun.com \
--to=bugs@gnu.support \
--cc=daniela-spit@gmx.it \
--cc=emacs-orgmode@gnu.org \
--cc=theophilusx@gmail.com \
--cc=yantar92@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.