Showing more than one note concurrently is not enough

Posted by 22111
Nov 2, 2013 at 01:28 AM

quant, as I said before, I, a layman, programmed a PIM with two panes AND TWO TREES AND MORE (related panes for other links, etc.) 15 years ago, fully functional, and with that part of the coding, I didn’t had the slightest problem whatsoever. I know what I am speaking about, I know about coding difficulties, I know about software architecture, and I know that most problems reside in lacking imagination; this being said, we’re speaking of very simple systems here after all; I know nothing about scaling for big multi-user systems, but UR is NOT such a system; and UR is not a DMS, far from it; and UR’s editor is due to the fact that Kyle doesn’t spend a dime on his paying customers, so he chose a free one; I call this unprofessional, and I weight my words.

I forgot to mention above that pane 2 (of 3) should have its own search functionality “for searching within”, too. As said above, references to the “outer material” should be shown in pane 3, triggered from panes 1 and 2; this could be another database, a “facts and products” database.

Whilst panes 1 and 2 are filled up with data from the “prospects and customers” database (or of that specific part of the one big relational database), and here prospects/customers will mention facts within their “history”, too, so for these, you need a second search function, for “within this customer’s (= the one from pane 1) history”: So, in pane 2, there will be your navigation, and there will be a search results table, alternatively, as I explained for pane 3 above, but for different scope.

So, in the end, you’ll need 3 complete frames, all of them with a navigation/search pane, and a content pane; on a 1920xyyyy screen, this setting is perfectly realistic. You will have two search engines, one “just for this customer’s stuff”, i.e. for sub-items, and documents, even pdf’s, calculation sheets from MS Excel and such, and of course for e-mail. So panes 2 and 3 will be multi-purpose panes, in fact frames into which the program then loads the respective viewers, also for pictures (cf. UR).

Remember that the navigation/tree/search results lists panes don’t need to be large, and for lesser screens, you could provide an auto-resize function, which automatically enlarges the pane when you navigate (= navigate the tree, or the search results) in it, and whenever you made your choice, i.e. want to look into the content pane, it would retrecede to its standard width. Also, this feature could be optimized by enlarging navi panes 2 and 3 NOT into their respective content panes, but into the content panes of panes 1 and 2, respectively, so that browsing is perfectly possible, with the respective contents fully visible in width.

And yes, from a technical point of view, it would of course be possible that one customer wants to speak about the “history” of another customer, but that would be a theoretical scenario only. And whenever such a thing occurs, it would be advisable to treat this as an “intervening customer” (see above) and load it into pane 1, then switching forth and back. This is to say that pane 2’s search functionality would have a very restricted scope: Just the sub-items of item displayed in pane 1, and of course any content in the respective sub-folder for this customer within your file system, i.e. every prospect/customer gets his own subfolder (which is automatically created of course), and any search in pane 2 will search there, too.

And to say it all, search/display scope for pane 3 should include anything that normally would be displayed in panes 1 and 2, but for special uses only, and certainly not within a crm setting. But for strategy, planning and organizing, of course you should have access to, e.g. calculations made for one customer (and thus being stored in this customer’s sub-directory), for any other customer - but this would be read-only, this would be clones, or any other concept in that line, and perhaps it’s a better way of doing things to automatically duplicate all this, for referential purposes, into the general “facts” database, those individual “originals” being left unchanged and untempered with, within their respective sub-trees and sub-directories, also for legal (and fiscal/tax) reasons.

And, of course, the filling up of frame’s 2 navigation pane should be done in real-time, meaning there would be NO one-time “synching” between your file system and your IMS (cf. the respective function in UR), with endless real synch problems anytime after, but of course, any display of an item in pane 1 would trigger run-time display of the then current content of the respective file system sub-folder. And yes indeed, this concept means that NOT ANY SUB-item should be displayed in pane 1 - for PM systems, it’s quite similar. There HAS to be some superior hierarchy level, in order to put the lesser hierarchies at your fingertips. All men ain’t equal, as we see any day; all info items ain’t either. I’d explained my ancient, cascading system (which was without visual trees, but cut-up trees if I stay in the picture) here; this 3-pane system (of which a crm set-up is only an example) is something like a unification of that ancient cascading-lists system and the traditional tree system. Don’t mix it up with a traditional (if rare) 3-pane outliner: In my system, any such “pane” = frame is twofold, and that makes all the difference. We do have the necessary screens for that, today, so some imagination in TODAY’s software should be asked for. (And yes, there will be some navi tasks, so with traditional keyboards, without additional ones (and without Cherry and other makers not doing their homework), you’d have a “problem” - a false one, since it all can be done, with additional keyboards, or MS jumping onto the bandwagon.

Remember SQLite (= UR) and other such databases are relational databases - what those developer squeeze out of their tremendous possibilities, is a shame. And that’s why it’s devoid of sense to switch from one poor PIM to the next - they are all amateur stuff; I hope that the above synthesis will be of interest to SOME developers at least.

I repeat that from a coding point of view, all this is easy.