Of course, the "go to the item of the secondary pane" command should be a toggle, switching from first item to secondary one, and vice versa: "go to other pane's item". This will greatly facilitate your having more than one target item, for switching between them within the second pane, and to go back to your respective source items (supposing sources and targets groups are in quite different locations of your big tree).

22111 wrote:

Thank you, Jon. So (and if I understand correctly), any second program
could be loaded, with a file referenced in the UR tree; the advantage
here would be that the external file would be readily accessible,
instead of searching for it in the file system.

That is correct. Of course, UR has to be configured, but this is a simple enough procedure.

Jon

FYI, the next version of InfoQube supports multiple editing panes (this thread inspired me to add this feature)

Testing is currently underway, so expect it to be released early next week.

HTH !

Pierre
IQ Designer
http://InfoQube.biz

Thanks very much to all who have replied - your replies led me to look more closely at some of the programs you mentioned (particularly Acute Notes, Sense, Whizfolders, and Scrivener). I was really thinking about the ability to view multiple items at the same time in a single pane, rather than multiple panes. I was glad to read about the "multiple items in mulitple panes, one per pane" options as well.

So many of the two-pane "outliners" we see have no "outlining" functions available in the editor pane itself. So called "single-pane" outliners - where a tree is integrated into the editor itself - not only allow me to see the content of multiple items in a single pane, which is only the first step - but also the ability to split/join items, promote/demote, and reorder items while seeing their full text. In the usual two-pane outliner, you can't split/join items, and the only way to promote/demote and reorder is to move to the "tree pane" where you work with "item names" only, and not the actual text of the items. And moving text between items is especially cumbersome - you have to cut text from one item, select another item in the tree, and paste the text in the desired location in the other item. This is so easy in a single-pane outliner.

These abilities make so-called single-pane outliners (where "outlining" is actually integrated into the editor) much more useful to me than most "two-pane" outliners.

And yet many of the single-pane outliners seem to be lacking in the kind of database functionality I want; many of the two-pane "outliners" excel at that. Often I think - if only these programs (e.g. Ultra Recall, Zoot, MyInfo, MyBase, TreeProjects, etc) would integrate the outliner tree into the editor, I'd have a lot more to choose from.

As it is, the only Windows programs I know of that approach what I want are Ecco and Infoqube. (OmniOutliner for Mac looks good but I'm pretty wedded to Windows). Ecco is great but I can't confidently throw my data into it because it can handle only a limited number of items - far fewer than what I generate over time. Maybe Infoqube is the solution for me but I would like to have more competitors in the field.

Maybe I am wrong but it doesn't seem like it would be that big a deal for the two-pane developers to integrate the tree into the editor. It seems they don't understand the importance of the capabilities that single-pane outliners provide.

on a different aspect of the topic - I thank you for introducing me to Scrivener and its Scrivenings view. I have occasionally looked for a program that would display and edit the contents of multiple files in a single pane as if they were a single file. I had seen a utility for *viewing* the contents of multiple files in a single pane - Depeche View - http://depecheview.com/ - but not one that allowed editing.

jimspoon wrote:

So called "single-pane" outliners
- where a tree is integrated into the editor itself - not only allow me
to see the content of multiple items in a single pane, which is only the
first step - but also the ability to split/join items, promote/demote,
and reorder items while seeing their full text.
These abilities make so-called single-pane outliners (where "outlining"
is actually integrated into the editor) much more useful to me than most
"two-pane" outliners.

Yes, as long as we're talking about outlining and writing, I also find single-pane outliners with inline notes superior.

And yet many of the single-pane outliners seem to be lacking in the kind
of database functionality I want; many of the two-pane "outliners" excel
at that.

But I wonder if the advantage of the single-pane outliners gets lost once the text/outline grows too huge. I certainly find that their utility decreases for me as the text grows beyond a certain size.

Maybe one solution could be to have the large text/database rendered as dual-pane, but have 1) the ability (a bit like Scrivenings) to pull up selected "folders" or outline items and combine them in a single pane, 2) switch off the "navigator pane," and have a single-pane outline view of the selected and combined text snippets (a bit like Scrivinings with folding text enabled with the full functionality of O4D outline mode). Actually ConnectedText's Table of Contents + folding in the editor view sort of work like that--except that this only applies to a single document within the database.

Dr Andus wrote:

Maybe one solution could be to have the large text/database rendered as
dual-pane, but have 1) the ability (a bit like Scrivenings) to pull up
selected "folders" or outline items and combine them in a single pane,
2) switch off the "navigator pane," and have a single-pane outline view
of the selected and combined text snippets (a bit like Scrivinings with
folding text enabled with the full functionality of O4D outline mode).

Though things could get messy when one would start hoisting and combining items etc. within such a 'Scrivening', creating conflicts between the original and the new hierarchy. Then the question emerges whether the ad hoc "collection" should be altogether a new document (or a virtual document independent of the original hierarchy).

This is what made Grandview so spectacular. It included every variety of method to expand and contract your document, so that you could always see just what you needed to see on the screen:

* Focus in on one piece of inline text in a dedicated word processor.
* See just the headings without the inline text.
* Open and close inline text on an item per item basis.
* Hoist to a section of the outline you needed to focus on.
* Show columns of meta data, or don't.

If someone would actually replicate this functionality in a modern, Windows-based application, it would be the killer outliner. (I know, broken record....)

Steve Z.

Dr Andus wrote:

Dr Andus wrote:
>Maybe one solution could be to have the large text/database rendered as
>dual-pane, but have 1) the ability (a bit like Scrivenings) to pull up
>selected "folders" or outline items and combine them in a single pane,
>2) switch off the "navigator pane," and have a single-pane outline view
>of the selected and combined text snippets (a bit like Scrivinings with
>folding text enabled with the full functionality of O4D outline mode).

Though things could get messy when one would start hoisting and
combining items etc. within such a 'Scrivening', creating conflicts
between the original and the new hierarchy. Then the question emerges
whether the ad hoc "collection" should be altogether a new document (or
a virtual document independent of the original hierarchy).

Dr Andus wrote:

But I wonder if the advantage of the single-pane outliners gets lost
once the text/outline grows too huge. I certainly find that their
utility decreases for me as the text grows beyond a certain size.

This is where filtering comes in. In both Ecco and Infoqube, each item can have any number of user-defined data fields attached to it. These data fields can appear as columns in a grid, and they also appear as "folders" in an explorer-like tree pane. If you double-click on a "folder", you display a grid of all items which have that field attached to them, i.e. the field has a value for that item. So, you are only seeing a subset of all the items you have in your database. And things (we hope) are manageable.

My practice has been to enter notes into a single chronologically arranged list - so that I have thousands of notes per year. Ecco can quickly display thousands of items that match a search. Infoqube and Ultra Recall are quite slow to sort or display a grid of thousands of items. I guess the key is to refine my search so that fewer items are displayed. The underlying database structure is obviously very different. I can't remember what Ecco is using; Infoqube is using microsoft Jet, which underlies MS Access.

jimspoon wrote: "Infoqube and Ultra Recall are quite slow to sort or display a grid of thousands of items. I guess the key is to refine my search so that fewer items are displayed. The underlying database structure is obviously very different."

I've complained about it elsewhere: UR does not "translate" the search functionality of its underlying database, SQLite (some other outliners do also use that since it's free AND it's real good, quite perfect for this task (desktop, not too much collaborative), entirely, but "shields" it from you.

And then, this is not new either, its search functionality is the only element of UR that is not rock-solid; in fact, search results can be unpredictable, which is one of the reasons I'm not so happy with it anymore, all the less so since the developer, while eager to de-bug his program any which way he can, does NOT do anything about UR's search in spite of the reports about its problems he gets.

Now let's see into this: If we hadn't the tree frontends set upon those sql databases, but some classic frontend you would have for the bigger databases and which are often also available for SQLite, you could do SQL searches, instead, and we all know that here, mainly two, three factors concur to give you search speed:

First, the repartition of your data within the relational database. Of course, this is a design decision, here of the UR developer, and you cannot blame the underlying database for possible data repartition (I'm not saying you try to do this, I'm just speaking in general); also, one user needing particular searches often, is "offered" the "general" database architecture, not something adequate to his needs, as if he had set up the database himself, according to these.

Then, more or less parented to the first factor, is the maintenance of indexes, meaning, which possible info is indexed, which is not, and we recall UR does not offer any options here: Again, it's the standard fare you'll be served.

And third, we all know that there are often lots of different ways to to sql searches, very "dumb" ones - let's call them "beginner style", and then, very smart ones, that often might not be tenfold as fast, but hundredfold or even faster - or let's say the "beginner style" can be very, very slow!

Now if you do sql searches, direct, you will "learn" from your response times, meaning if your search is too slow, you will try to find a better way to do the "same" search, and here, many web sites and advanced books on sql will be of big help (if you can justify the buying and reading).

Now back to UR. I strongly suppose its search panes (regular and "advanced") do translate your search wishes, in the most inflexible, rigid, "stupid" way possible, into "dumbest" sql search commands, or let's be nice and say, UR does standardize your sql searches to the core.

I'm perfectly aware that in such an environment, there are not 51 possibilities, but there would be SOME possibilities at least, but which would need to be implemented and coded, and you cannot expect this from UR.

Technically, it's perfectly possible to predict some MORE standard uses of the database, and to have at least additional indexes built and maintained by option. Then, it's possible to introduce some more search search panes, not just "standard" and "advanced", but to have several "advanced styles", for different, typical tasks, and for which the translation into sql would be quite different = optimized for the main elements of your different searches, since of course, it's quite another task to just combine different key words, or to select/sort by some attribute, and then only be interested in key words, to give an example.

And then, it also would be perfectly possible to implement "stored searches"... but for sql searches: Have a search "line" (in fact, since we're speaking of sql, a search field with perhaps twelve lines) for entering sql blocks, and have a pane to which you can store, and from which you can then retrieve both stored searches with theirr content, and just skeletons, or combinations of real search "terms" and just empty command parts first to be filled up and/or to be adjusted to any new search, meaning you will store some dozen such sql searches, grouped by kind/complexity, and then retrieving one will place it into the search field, where you will probably want to do adjustments (or even not, for your most standardized, recurring searches), and then a key (perhaps a double return) would trigger your "optimized" sql search, optimized if you took the effort to optimize it.

Such an approach would also eliminate the unpredictability of UR's current search, since you can be 100 p.c. sure that these bugs don't come from SQLite, but from UR's "translation services".

And again, we face the old problem that we don't constitute enough of a "market" in order for developers doing the work, and thus we live with sub-standards that technically could be easily avoided. We just ain't worth it.

This reminds me of MindJet: In so many years, with so much money earned, they weren't able to introduce inter-illustration clones, which for a mind-mapping system are so necessary though, since the philosophy beind mind-mapping is certainly not to create monster maps with 5,000 items, but to discard anything not relevant in a given context to another context, but since things are interrelated to other contexts, too, this supposes clones updated in different maps.

In fact, the absence of this feature invalidates the whole concept, but without them being bothered by such considerations. I say it reminds of MindJet since some days ago, I got a mail praising the newest version, now with a better database, of a macro program that tried to update such things, from the outside, in your MindJet map collection, be it for your own use of "cartography" of your things, or for collaborative tasks. This macro program, costing several hundred dollars, is expected to be run before 9 in the morning, then again around supper, and then perhaps again in the evening, instead of next morning before work: As said, it maintains its own database in order to do all this that should be done from within MindJet's database in real time, from the outside, "manually", when there is a break in your work.

So this ridicule is proof that our not getting needed functionality has not too much to do with our being too small a "market", but if we were a great many (as paying MindJet users are), the return maximization efforts of the developers/suppliers would assure we didn't get our needed functionality there either.

Technically, it's almost always possible, and more often than not, it would be even rather easy to code. Evernote is a good example: It has certainly got some new, state-of-the-art functionality, so they prove they are technically able to do a lot of things, and then many "basics", also needed, have even been eliminated, instead of having been developed to a higher degree.

Anyway: My starting point was, don't blame the database here, blame stupid frontends.

jimspoon wrote:

This is where filtering comes in. In both Ecco and Infoqube, each item
can have any number of user-defined data fields attached to it.
So, you are only
seeing a subset of all the items you have in your database.

Aren't we talking about tagging every piece of data/outline item then? The problem is that tagging everything is time-consuming and not necessarily worth it (or I'm just lazy... Maybe that's why I'm not an Evernote guy...;)

There seem to be to different types of need here: 1) how to capture, store, and find notes. And 2) how best to use selected notes for outlining and writing. I don't think it's necessary to do this all in one software.

"The problem is that tagging everything is time-consuming and not necessarily worth it"

That's why some applications try to (half-) automate the tagging process, for example RightNote, even when RN's way of doing does not seem to be that smart to me (the children can get, as tag, the title of the common parent, which means that often, you would have to rename the common parent into something adequate for a tag, trigger the children tagging command, then rename the common parent again: in most cases, it would be better to assign a common tag, or in practice, to assign ONE of the tags the parent items has got already, to the children, too.

"There seem to be t[w]o different types of need here: 1) how to capture, store, and find notes. And 2) how best to use selected notes for outlining and writing. I don’t think it’s necessary to do this all in one software."

This is only an excuse for permitting laziness to developers, and for crimping. In fact, ONE program should permit GOOD storage functionality, AND good editing/grouping/evaluation/use of stored data, all the more so since for most of such combinations of several programs, all such fiddling around will transfer your data in ONE direction only, but not in both directions, or just with lots of additional, "manual" work from the side of the user.

A blatant example of this being EN and then an outliner: I perfectly understand the interest of EN's capturing capabilities since most outliners do NOT have those. Here, if you use EN as your "inbox" only, then transfer groups of things into your outliner, no problem here since you will not want to transfer them again into EN (where your grouping/sorting efforts made upon this content in the outliner, will be lost again), so this might be a very valid combination, but the above example - "1) how to capture, store, and find notes. And 2) how best to use selected notes for outlining and writing." is devoid of sense since here, data transfer is supposed to function in both directions, and with most current software, this is not a valid workflow.

As I have explained here some weeks ago with outliner data THEN exported to an "analysis editor" like KEdit, combinations are ok when transfer of data is done just in one direction, and if you can optimize (half-automate, by macro for example) this transfer. But whenever you need your new data again in the former program, such a concept bears lots of unnecessary, additional problems.

Btw, the "add-in" concept, which has been very well realized with Outlook, is a possible solution to such "why pay for additional functionality only some users will really need" problems.

FYI :

Version 0.9.26PreRel12 is now available for download and supports multiple editing panes (no limit to the number of panes)
Content is shown in a round-robin fashion. Panes can also be locked on a particular item.

This version also includes a demo of a much improved calendar.

HTH

Pierre
IQ Designer
http://InfoQube.biz/download

-------------------
Pierre Paul Landry wrote:

FYI, the next version of InfoQube supports multiple editing panes (this thread inspired me to add this feature)

Testing is currently underway, so expect it to be released early next week.

Pierre Paul Landry wrote:

Version 0.9.26PreRel12 is now available for download and supports
multiple editing panes (no limit to the number of panes)
Content is shown in a round-robin fashion. Panes can also be locked on a
particular item.

Pierre - Thanks for the heads-up. Haven't played with IQ for a while. Looks like you got a pretty good coverage of different outlining scenarios there. I can't make it out from the screenshots: is it also possible to do single-pane outlining with inline notes with IQ?

dr. andus - we'll see how Pierre replies on the "inline notes" question, but I think the answer is no. By "inline notes" I think you mean text which is not an item or subitem, but which is rather "attached" to an item, and which may be displayed either in a separate pane or underneath the item to which it is attached. e.g. as in Grandview. But I think in IQ you can only display items and subitems in the grid (outliner or tree) pane. Each item can have HTML content attached to it - but it is displayed in a separate HTML pane - not "inline" in the grid pane. (i suppose he could implement inline notes.)

(The HTML pane has HTML content - it can be edited either in WYSIWYG or source code views.)

Pierre describes the new feature as "multiple html editing panes". Before we could see the HTML content attached to a single item - the item presently highlighted in the grid, Now with multiple html panes, does the content in each html editing pane come from a different item? How do you go about displaying the HTML content for different items in the multiple HTML panes? I just downloaded the new version so I will soon see.

IQ can certainly be used as a single-pane outliner - you can hide the HTML pane and put your notes in the grid pane (items and subitems) rather than in the HTML pane attached to each item.

i am warming up a litle to infoqube lately - I've been put off with the lack of some synchronization features I'd like for use on both desktop and laptops - but last few days I've been surprised at how well it's performing just running the program from an SD card with the databases also on the SD card. So, when I want to work with the data on a different computer, I can close down IQ on one computer, eject the SD card, put into the desired computer, fire up IQ again, etc.

jimspoon wrote:

By "inline notes" I think you mean text
which is not an item or subitem, but which is rather "attached" to an
item, and which may be displayed either in a separate pane or underneath
the item to which it is attached.

Not in a separate pane, but the note can be in a separate field (though it doesn't have to be). In principle it's "title" + "note," and while they can be in too separate fields, they are associated, and when exported to RTF or similar, the title would become formatted as a heading according to its level in the hierarchy, while the note would be normal text under the heading.

Dr. Andus,

If the inline note only needs to be "inline" in an exported format, then, yes, IQ can do this. I've put an example of such export (Print > Selected items and colums...) here:
https://dl.dropboxusercontent.com/u/106577/InfoQube/Welcome.htm

There are many export options. I've chosen these such that the outline remains dynamic, meaning that users can expand/collapse the hierarchy AND show/hide the inline content.

Content can be viewed in a browser and/or edited using MS Word.

HTH !

Pierre
IQ Designer

Dr Andus wrote:

Not in a separate pane, but the note can be in a separate field (though
it doesn't have to be). In principle it's "title" + "note," and while
they can be in too separate fields, they are associated, and when
exported to RTF or similar, the title would become formatted as a
heading according to its level in the hierarchy, while the note would be
normal text under the heading.

Pierre Paul Landry wrote:

If the inline note only needs to be "inline" in an exported format,
then, yes, IQ can do this. I've put an example of such export (Print >
Selected items and colums...) here:
https://dl.dropboxusercontent.com/u/106577/InfoQube/Welcome.htm

Thanks, nice export. Personally I also find inline notes useful in a single-pane outlining situation.

BTW, when I tried to install your latest installer on a Win7, 64-bit machine, I got the following error (and then it aborted the installation):

C:\Windows\system32\ChilkatMHT.dll

An error occurred while trying to copy. The source file is corrupted.

Dr Andus wrote:

BTW, when I tried to install your latest installer on a Win7, 64-bit
machine, I got the following error (and then it aborted the
installation):

C:\Windows\system32\ChilkatMHT.dll

Humm... I'll check it.
Perhaps, you can try to use the Portable version. It is more robust since isolated from the OS and from other programs.

Dr Andus wrote:

BTW, when I tried to install your latest installer on a Win7, 64-bit
machine, I got the following error (and then it aborted the
installation):

C:\Windows\system32\ChilkatMHT.dll

An error occurred while trying to copy. The source file is corrupted.

Me too, but I just pressed "ignore" and the installation seems OK .... up to now.

For what I personally consider the best implementation of "inline" notes, see the article I wrote about Grandview several years ago:

http://welcometosherwood.wordpress.com/2009/10/10/grandview/

It's not really handled like a field in Grandview, but something else entirely. Because Grandview also did meta-data fields very well. I have yet to find an outliner that does inline text as well as Grandview, though some come close -- OminOutliner for one.

Steve Z.

@Graham and Dr. Andus :
Thanks for reporting the issue. I've updated the installer version. It now installs correctly.

Pierre
IQ Designer
http://infoqube.biz/download

Graham Rhind wrote:

Dr Andus wrote:

>
>BTW, when I tried to install your latest installer on a Win7, 64-bit
>machine, I got the following error (and then it aborted the
>installation):
>
>C:\Windows\system32\ChilkatMHT.dll
>
>An error occurred while trying to copy. The source file is corrupted.

Me too, but I just pressed "ignore" and the installation seems OK ....
up to now.