From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id SBxXIWVNuV+pQgAA0tVLHw (envelope-from ) for ; Sat, 21 Nov 2020 17:24:53 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id OOEeHWVNuV/TawAAbx9fmQ (envelope-from ) for ; Sat, 21 Nov 2020 17:24:53 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id D837594028F for ; Sat, 21 Nov 2020 17:24:52 +0000 (UTC) Received: from localhost ([::1]:38858 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kgWd1-0001iG-SI for larch@yhetil.org; Sat, 21 Nov 2020 12:24:51 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38794) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgWcW-0001g4-FK for emacs-orgmode@gnu.org; Sat, 21 Nov 2020 12:24:20 -0500 Received: from static.rcdrun.com ([95.85.24.50]:46531) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgWcU-000272-ET for emacs-orgmode@gnu.org; Sat, 21 Nov 2020 12:24:20 -0500 Received: from localhost ([::ffff:41.202.241.56]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C1AE3.000000005FB94D41.000072ED; Sat, 21 Nov 2020 17:24:16 +0000 Date: Sat, 21 Nov 2020 19:08:24 +0300 From: Jean Louis To: Texas Cyberthal Subject: Re: One vs many directories Message-ID: References: <87y2ive1i4.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "emacs-orgmode@gnu.org" Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -1.01 X-TUID: tZf70AGA/jWo * Texas Cyberthal [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.