Outliner Software Forum RSS Feed Forum Posts Feed

Subscribe by Email

CRIMP Defined


Tip Jar

Showing more than one note concurrently is not enough

< Next Topic | Back to topic list | Previous Topic >

Posted by 22111
Nov 1, 2013 at 09:44 PM


You just have to look at the number of posts in this thread, and you easily see that this double-pane feature is one of the most important for many people; given that, AND considering that coding it is easy, it’s all the less understandable that most developers do NOT introduce it (or in such a ridiculous way as in MyInfo: as said, read-only (and awful pop-up) for several years now).

Of interest here, another consideration: That feature is not only of utmost importance in a “writing workflow”, but it is of even greater importance for CRM. Let’s have a phone call, from your customer/prospect, or from yourself, to him. Now you will have a “main item” for him, in your outliner, and then several sub-items, in chronologic order, for any “contact” you had with him, purchase, phone call, call. Of course, you could have these within fields on the main page for this customer, but the basic problem would remain the same:

For one, you write down some new info here, but for best playing role (both for your business and for the customer!), you need to refer to other info that is already there, be it a big field with scrolling, or be it “sub-items”: In either case, you must BROWSE various info with regards to your customer… and then, even general product info (goods, services, no matter), which means you must also browse somewhere else, and at the same time, you should have your core info before your eyes, and your “write field”, for this new contact.

This means that the software on your screen should take whole advantage of today’s large screens, and should allow for several navigation “threads” concurrently, in different panes, and of course it would be a good idea to allow for browsing different info as easily as possible, within these different panes, like in a pic viewer where it is the traditional way of doing things in the way “space or right arrow will go to the next item, within the same subfolder”, and then, some say “it’s the end”, and some others let you have an option to begin browsing from start again, by just doing the “next pic” command).

In such a way, such software should be able to have limited navigation panes and commands for each of its not 2 but 3 content panes, from left to right.

Pane 1 should contain basic info for the customer, and a text field for your current writing; the contents of which could then, when you leave this main item, automatically be written into a new “contact form”, i.e. another sub-item for this customer, within the “contacts” range if there are several, or as a “contact” if there is only one “timeline” = chronology but there are several different forms, for contacts, invoices, incoming mail from him, and so, all color-coded e.g.

In pane 2, you would browse all “child items” of the item displayed in pane 1, and since some good customers could have 50 or more such sub-items, it would be a very good idea to have another tree pane, here, too, for that 1- or perhaps 2-level tree for those “siblings” or such, and, as implied above, some key commands for “next” and “previous” here, and perhaps a special “lastviewed” = lastviewed in this pane 2.

Since you won’t write in any of these items, in pane 2, pane 2 should NOT gain focus, so that you can continue to write in the “current-text” field in pane 1; the commands acting on pane 2 should all be triggerable from pane 1 (so you need different commands for navigation in pane 1, 2 and 3, but that’s only a problem for your keyboard (see the other thread with regards to today’s keyboards), not for the software. Pane 2 will then be the “contact history”, with mails, notes and all relevant documents, and it will be automatically loaded with the relevant items whenever such a customer, etc. in pane 1 is displayed.

Then, you’ll have a pane 3, for other reference material that is not directly connected to your customer in pane 1, and that thus will not be filled up automatically, but here you will choose any other content that you will need, e.g. product info of all kinds, or even info on your competition, etc. It goes without saying that in panes 1 and 2, there should be functionality for triggering relevant info for pane 3 whenever you have some “search term” highlighted there, i.e. if there is a product name on an invoice in pane 2, a command should bring up relevant info on this product in pane 3.

So the filling up of pane 3 would be by 3 different methods: By such direct triggering, by searching (here, a search results table would appear in pane 3 first, then there would be a toggle to switch forth and back between these search results, and the item in question; also, there could be some navigation commands here for displaying other results from that table, without having to display it and to click on it each time), and of course a tree navigation pane from where you will display any item that you might be in need of. So in the end, it would be best to toggle the tree and a search results in one navigation pane for content pane 3, and not toggle search results and content in that pane which should be content-only.

I am aware you would need a large screen for this (if you don’t cut it up into 2 or even 3 screens), but such a system, technically easy (!!!), would finally bring real crm functionality to such pim’s.

And yes, there should be some “storage” for such a setting, so that you will be able to switch forth and back between your previous customer (where you will have work to do, complete some notes, trigger some action from somebody (which might be yourself), e.g. work on an offer, etc. - and this customer phoning to you immediately after, and where you will have to react, too, so there should be a “history” function from which you can display not only the respective main items of these last days, etc., but together with their respective “environments” you had “open” when you were actively working on them (had the respective customer on the phone, etc.). This functionality, too, is easy, from the coding point of view.

My current crm system is abysmal, and if I judge the current situation correctly, even dedicated crm software mostly isn’t that much better, but there is no real sense in switching from one PIM to the other, because all of them are really bad in correctly organizing your business.

That’s why, e.g., yesterday on bits, I did NOT buy “Brilliant Database”, and my thinking about it was triggered by somebody on bits who, just days ago, asked for Ultra Recall there if it was right to assume UR is a DMS, too. Well, the developer answered affirmatively - I will not comment on such hybris here, but it’s evident all current PIMs lack a lot of functionality that would make your workflow much more natural than it can be, with current software, today.

And yes, ultimatively, access rights management would also be to be included within the set of new features. And dialling, caller identification, and so on, the usual goodies.


Posted by quant
Nov 1, 2013 at 10:35 PM


22111 wrote:
You just have to look at the number of posts in this thread, and you
>easily see that this double-pane feature is one of the most important
>for many people; given that, AND considering that coding it is easy,
>it’s all the less understandable that most developers do NOT introduce
>it (or in such a ridiculous way as in MyInfo: as said, read-only (and
>awful pop-up) for several years now).

could well be that your statement “coding it is easy” might not be the case in reality


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.


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



In some years, there will be better screens: Looking at a given pane (among the six above) should not switch focus to that pane, but should just switch “scrolling focus” to it, i.e. make apply home/end, pgup/pgdn, 4arrow keys to that pane, visual indicator could be chamois background instead of a white one, or vice versa.

In theory, touchscreens could “do it” even today, but here the problem is that such screens, in order to be “ready-to-be-touched”, they should lay, in 45 degrees or better less, perhaps 30 degrees, on your desk (and the “height” of your keyboard, between yourself and your screen, should be minimized, in order to bring the screen as near to your hands as possible) - but in such a setting, you would need to constantly bow your head to “read” the screen, and as we all know, screen stands have been invented for the precise reason that the screen should NOT ask you for even light bowing of your head, and in many countries (e.g. in Germany), the use of notebooks in the office, even with an additional keyboard, but without an additional screen, is forbidden by the law, in order to protect your staff, for them not forced to bow their heads to such a low (here: notebook) screen, so I cannot imagine that “quasi-laying” touch screens will be permitted instead, and “quasi-stand-up” touch screens would not permit easy “touching”, so touch screens for the office are a dead-end.

Today, you either need twelve additional keys, in two rows, for up/down of 6 panes (holding them down for e.g. 0,3 sec would then be home/end, etc., or 0,2 sec = pgup/dn, and 0,4 sec = home/end), or you need six additional keys for “scrolling focus”, and then the regular “tenpack” (= between the abc and the digits on your keyboard) would apply - I prefer the former solution, but both could be implemented. In the latter solution, holding down those “scrolling focus” keys for 0,2 sec would shift focus (where this would make sense, which is not the case in “read-only” cases).

In real life, all which would be needed for this is a two-rows F-keys set-up, with 24 instead of just 12 F-keys, for both alternatives - or then, some additional keyboard for your left hand; of course, you’ll need other additional keys, for triggering not one search, but 3 different search engines, for panes 1, 3 and 5, but here again, alternatively, you could have “scope” keys, and then the regular “find/search” key would trigger different commands, depending on scope: either you will need more keys, or you will need more key pressings.


Speaking of easy implementation, non-programmers (= programmers will know anyway) should know that any “import” of external documents is a very bad idea, but loading different “viewers” into panes 4 and 6 (= the content panes of frames 2 and 3) is easy, and this applies to any “file format”, just have a look at the 40$ viewer add-on for “Directory Opus”, and this does not only apply to files in your file system, but also to mail within Outlook (and I am sure that for mails in Notes and other corporate mail “servers”, similar access functionality is implemented):

You must know that it’s no problem whatsoever to access Outlook mail “from the outside”, and this includes retrieving/displaying original Outlook mails in the viewer of your IMS/PIM, and of course creating sub-folders in OL, and, as said, then fetching and listing the content of such OL sub-folders within e.g. pane 3 of 6, then displaying it (= from its original location in OL, not from some “imported stuff”) in pane 4 when selected. Such a system that systematically and automatically fetches and lists all the “originals”, but leaving them stored within their original locations, would avoid any “synching” problems at the same time, by this greatly reducing any coding problems that might arise with such “import frenzy”.

Just compare my concept with what e.g. UR is trying for replicating your file system, and you will see that “run-time link fetching” for content in “parallel original containers” is a much better solution than trying to get “snapshots of what is” at a given moment, and then have incredible synch problems for such snapshots ever since:

Have your IMS just “synch” and monitor parallel folders, but no myriads of parallel files anymore, and you’ll away with 95 p.c. of all synch problems, AND you will have a much clearer, neater IMS.


Posted by 22111
Nov 2, 2013 at 01:11 PM


Ok, the passage with regards to holding down dedicated “arrow” keys for replacing home/end/pgup/pgdn was the dumb part of the concept, of course you will hold down them in the same way as you would do with the original arrow keys (which are always there), i.e. for fast navigating up and down along several lines/entries. Thus, “fast double press” is possible, or then, why not use the native keys, after having selected their scope, in rare cases. In real life, the lists in pane 1 and 3 will not be endless, so a double press of their dedicated up or down keys will do a pgup/pgdn, and there will not be a dedicated home/end assignment - just do several such double presses when really necessary, and why not use the alternative of shift-dedicated-up/dn (pgup/dn), and ditto for control (home/end), or even holding down 0,2 / 0,4, but with control-key pressed, too, which will leave shift and alt combinations for other uses.

Also, bear in mind that in lists (panes 1, 3, 5), the left/right arrow keys remain unused, naturally, which makes them available there for other commands. And somebody please tell me why there doesn’t seem to be, at this moment, but ONE keyboard available worldwide that “fills up” the 5 free key positions beween the 6-block and the 4-arrows-block, on any keyboard where these 6 and 4 keys are placed in the traditional way: It’s from Cherry, it’s expensive, but the show-stopper is the absence of a sensible number of additional keys there (MultiBoard V2 G80-8200), and with other of their expensive keyboards, you’ll get even more, real big problems (cf. MultiBoard V2 G80-8113 where a totally crazy touchpad where you’d absolutely need keys totally invalidates any advantages of the second F key range).

These are details, the paradigm shift of this concept residing in the fact that for the very time, a PIM also replaces your file manager for all of your information management purposes, acting in real-time onto your file system and other parallel storage systems (databases like OL and others), instead of trying to work with partial snapshots of all these which then quickly run out of synch.

Permanent (and “invisible”, except if you check with “screen spy” tools) switching between the needed, dedicated viewers, within the content pane, is one of the things UR does do more than correctly (e.g. for displaying the 50 k “original” of a jpg, instead of importing it and by this inflating the database by another 1.5 million bytes), and as you see, such a hybrid system of (visually equally treated) content, internal or external to the IMS, can be optimized, for a brand-new IM experience. Also, when (as mentioned above), your notes of today (= in a field of pane 2 of 6), if they are business-related, automatically become stored, invariable, secured “documents” “tomorrow” (listed in the timeline in pane 3, and to be displayed in pane 4), this will make it a full-grown DMS, even for legal purposes - whilst today, not a single PIM would fulfill this role and could thus be used as a DMS; cf. similar problems with many accountancy softwares. Of course, this observation of legal regulations would imply the implementation of hash value storage and such; I do not pretend to be able to code this part of the thing, but then, it’s evident there are components to buy for such special tasks within the compound system.


Back to topic list