On Thursday, February 6, 2020 at 11:18:39 PM UTC-5, Thomas Passin wrote: > > > > On Thursday, February 6, 2020 at 10:59:37 PM UTC-5, Thomas Passin wrote: >> >> Andy, thanks for your comments. I will give my reaction to them in a >> series of posts, one per item. >> > > Continuing my reactions to your comments - > > 10. Display Styles > @andyjin: "Could this be called 'mapping'? e.g. a simple tree is a mapping > or 'display style' of relationships. > To me this is one of the most important elements of the system, and it's > all about accessibility. I want to be able to find any note or group of > notes in the system very quickly and intuitively. > On my wish list is a search/navigation system that will enable me to > locate items by tag(s), date, hierarchic relationships, linked > relationships, text search terms, any other useful relationships that may > be conceived for the system, AND any combination of these, in one search. > My (only partially conceived) notion is for search results for such a > search involving multiple types be displayed in a mapping or tree, and that > that that tree be navigable. This is not well conceived as yet, but > hopefully the general concept is understandible." >
All things are possible, but it's easy to make a system that's too complicated. In that case it doesn't get used for very long. If you think how valuable the original zettelkasten seems to have been, it didn't have any of those capabilities. In my experience, it's good to start out simple, and slowly extend the capabilities as you find you really need them. In my bookmark system, I started with maybe half a dozen features that it turns out I almost never use. Other features I modified after a lot of experience. For example, I can do a simple text search for a phrase. What's especially useful is that it returns hits for both web page titles and also for the indexing terms. These two are displayed separately, mot mixed together. I have working code to do approximate searches - matches will be found even if a single character is wrong or missing - but so far I haven't bothered to include it because I find I don't need it much. It's almost as easy to spot a typing error if I don't get any good search hits, and I don't have to remember the limitations of the approximate search algorithm. So I haven't bothered to add it so far (I do have it in a different application). As another example, back around 1990 I wrote a small personal phonebook app. I still use it. I can search for a person's full name. The search is progressive, so that if I get a match before typing the whole thing, I get to the right entry. However, I have to start with the last name first. In hindsight, I would like to be able to start with either the first or last name. But the system I used to create the app (Powerbuilder) is long gone and so I can't change it. I have never felt that it was worth re-creating the app in a different language, so I live with it. It's not too big a pain. My point is that these systems need to start simple, but be designed so that it's not too hard to change or extend them as you learn how to use them. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/758f1345-1461-4af7-bb50-1a0034cf228b%40googlegroups.com.
