Re: One vs many directories

[Jean Louis <bugs@gnu.support>]

* Texas Cyberthal <texas.cyberthal@gmail.com> [2020-11-21 18:01]:
> Hi Jean,
> 
> > Navigating does not necessarily contribute to production. Productivity may say what it wants but it may not reach those who are actually more productive without using the navigation. So studies may not tell us what is more productive, such may only tell what is currently used within the subject of being productive.
> 
> Outside 10 Bins, navigation is often negatively productive.  Whenever
> the user navigates bad tree structure without correcting it on the
> fly, he suffers profitless friction.  That's why Treefactor combines
> with JiT sorting to make navigation and sorting a single activity.
> 
> Frankly I was surprised people prefer navigation despite being
> generally so bad at tree structure.  In the absence of good structure
> and tools, search is much better.

Do you really think people prefer? Or they simple have no other
option?

If I have no other option to drink a juice I will drink water, not
necessarily I prefer drinking water in hot sunshine. I like
Apfelschörle.

Searching file contents is database search. I am not any more fan of
that. Tools like Beagle or Tracker are making basically double
database of files only for me to find or search files. Most of time I
am only searching for meta data, not for contents. With 1000 GB one
would need to have maybe that much indexed database and constant
updating of files and their positions.

That is why I prefer relational pinpointing or relational access and
actions or locating files by using indexes.

Relational access would mean when you inspect the object to quickly
jump to all relational pieces of information relating to that
object. If I look on person's name there need not be any note or
contact information but I should be able to quickly access such
information. And each object should have general actions like actions
relating to email object could be to send email, delete email,
forward, etc. that is what mail readers do. Action on file relating to
user should be to quickly see emails of the user, social networks,
websites, to call user, SMS, send information, jump into XMPP chat,
share the file or request new version of file and similar.

Locating files by indexes would be to index only meta data and then to
use searches to find meta data such as title, date, author, or various
attributes. Tools like locate and similar do that. 

> I agree, email should be database-centric.  Manually organizing
> emails into folders (or worse, trees) is therefore wrong except in
> tiny doses.

You missed this:

- I am reading email, answering and if I wish to keep it all I do is
  `s` to save it into the mailbox related to the email address:

  ~/Maildir/texas@example.com

  Emails that I send to user are saved to same mailbox.

  That is all. No thinking, nothing, saving goes automatic. This
  single plan of filing emails enables me to see all conversations
  related to that email address.

  Database keeps all email addresses of specific person

  $ emailsof texas@examp

  would give me 3 views if there are 3 email addresses, I could
  basically review all conversations of that person.

  There need not be any true database like `mu` or `notmuch` as this
  way I find most of times what I need. I can search inside of
  mailboxes easily.

  I would not keep emails in the database like PostgreSQL, no. Emails
  have to be accessed by mail readers and there are just few that
  would be supporting databases. 

> > Take care of duplicates. When marketing contact database is
> > growing fast, some times 1000 people per day or more. People have
> > same names. Often one cannot even know what is first and what is
> > last name. You may know it for your country, in other countries is
> > not so. Then those people engage in a course on distance. They are
> > sending me images and files as results of their course
> > assignments. I have to file the files in proper folder. Because
> > names are not always unique I better file it under unique IDs, and
> > keep separate symlinks with names of people to such unique IDs
> > whereby symlinks can be automatically updated.
> 
> This is clearly a CRM database use case.  In this situation, the CRM
> should define the unique ID, and then Textmind should accept it.  You
> can still use the directory tree, though.  Just file it under
> ~/Surname-given-name/ID-number/~ for the non-unique name.  Recursively
> searching ~/1-Textmind/2-Linked/7-Name/2-Flat/~ for a directory named
> ~/ID-number/~ will find the target even if his name changes slightly.
> So you can save time by not inputting every scrap of text and files
> into the CRM.

That is right, good idea to file under surname/ID. I would rather
prefer the approach ID/Full-Name as if directory is automatically
created by its ID, so I do not need to think about it.

CRM is for me not the database, it is method of management of anything
related to people and I call it Central Files. I do not put text files
into database as that converts them into something else, they are not
text files. That is nonsense invented by people who try to use
exclusively web interface to manage anything and such interface is
limiting user. User for example is unable launch `mpv` video player on
the video file belonging to the person Joe Doe as browser will not
allow it to launch external programs.

CRM or Customer Relationship Management is just way of thinking, it
does not need to be computerized. Rolodex was one way of CRM method
and it worked well and works today well. Larger organizations have and
still have paper files, they open paper file and can see previous
conversation, which officer or sales manager handled the person and
how, and they would make a call and put note in the file and file it
back in place. To handle daily 100 or 300 people is quite possible by
using this system. I was handling usually 800 files per week and wrote
this many personal letters. Just take the bunch of paper files and go
over files, open, call, invite customer, make a note on paper, put
note in the file, close it. It is pleasure working that way and I can
tell out of experience. This is for reason that files are still
physical object that staff handling it can keep it in the
hands. Collaboration is also there, multiple staff members simply
exchange such paper files between themselves. And multiple staff
members can look into such files and see what other staff member has
communicated, offered, sold to specific person. And I still do have
paper files as such are also part of digital management. It is
often illegal not to have paper files pertaining to various
entities. If there are contracts, I have to have paper files, it is
yet another object. On paper file there must be unique ID written down
by hand. Contracts may be in such paper file. Digital index must tell
where the paper file is sorted, maybe it is A2 box on the shelf in the
green room.