Showing more than one note concurrently is not enough

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.