This is a typical Ultra Recall feature request:

http://www.kinook.com/Forum/showthread.php?t=1308

It's from 2005, and the developers say they are not interested; it's now 8 years later.

The request states that (even then!) myBase creates eBooks from its databases, meaning executable files that don't need you to install a "viewer" beforehand; in fact, most customers/prospects would not want some "viewer" to be installed within their system, in order to view your eBook (advertisement, technical things, reference material) on their pc; perhaps some will be willing to do that if they have become your customer already, but in order to show your expertize, you would have some interest in showing prospects a range of technical things, and here, having to install a "viewer" first would be considered unprofessional.

Now some outliners have viewers, among them, Maple and ActionOutline. For AO, the viewer is free, while the Maple viewer will cost you 10 dollars for every prospect, since their viewer license says every installation of the viewer will cost that, even if you don't sell your content but only hope the content will then sell your services or whatever - this is the most ridiculous thing I have encountered in a long time, so it's worth mentioning: Not only your prospects will have to install the viewer first, but you will have to pay 10 dollars for every prospect (if in the end he installs your viewer or not).

Now for AO: As unprofessional as for Maple, but free at least... But here comes the good news: While their program costs 40 dollars, they also sell an eBook maker for two times that price. This might appear "overpriced" on first sight, but then, for 80 dollars, you'll have a professional product, meaning an .exe file with your content, meaning, a self-installing viewer together with your content, and which is exactly what you need, so in the end, these 80 dollars are quite a bargain.

Of course, AO is abysmal in (lacking) functionality, especially for searching, so this .exe file will be the same as the running program, no search functionality worth mentioning - but the idea, creating an .exe file for your prospects/customers, is certainly 100 times better than these "viewer" offerings.

Now Ultra Recall: In 2013, it doesn't create such .exe files, and it will probably not in 2023. myBase does, as we know from the 2005 UR post, and even TreeDBNotes is mentioned in 2005 for being able to do this.

I now searched for some other outliner names, together with "electronic book creation" and so on, but it seems that in the end, there are not so many of them being able to to this; also, the visual aspect is important, meaning those "ebooks", in the end, will probably (as is the case for AO and Maple) recreate the layout of the original program, just without no editing (either in the tree or in the content pane), and some such outliners are not really extremely sober in their layout (but then, I did not trial myBase's eBook functionality, so perhaps this is a real good program for such things). As for AO, judging from their screenshot, this eBook Creator is even able to create eBooks with several tabs, meaning you don't only have one tree structure to the left, but you also could cut up your material into several "books" or "parts" or "super chapters", whatever, by this holding the respective trees straight, instead of overcomplicating just one single tree that would have to contain it all - this "tab functionality" might also apply to competing outliners and their "eBooks".

Since in this forum, a lot of small business people are writing, I both think this subject is of interest here, and that some of yours could be able to share some experience and/or mention other outliners for creating such "eBooks".

Some things are "understood" with this: We are speaking of "eBooks" that are visual replicas of what you do within the outliner, meaning a functional tree structure as in the outliner, and search functionality as in the outliner, for pc use, and NOT "eBooks" diverting from this original format but translated into Nook, Apple, Amazon reader formats; and it's also understood that it would be possible to continue to "write" what later on becomes an "eBook" this way, in the outliner of your choice, but then, why not, export it into that outliner that will create the best eBook for your prospects/customers, visually and/or by functionality (and be this creational functionality in-built, or, as with AO, from an additional program you'd have to buy separately; btw, askSam, years ago, also sold such an extra program, a "database builder" or something like that, and it was 1,500 dollar if I remember well... or was it 1,200 dollars?); also, if you have content to sell, this would be an alternative format, beyond Amazon, Apple, etc., to sell your content, especially if it's for office use - but I think the main use will be for promotional material, for prospects, and then, for reference material for customers if your business allows or even asks for such material; it goes without saying that creation of such material could give you some advantage over your competition.

So, any further experience/information about this subject to share here?

And then, if somebody knows a real excellent viewer (visuals, searching), why not distribute it, together with your database, together with a third-party installer that just is an .exe file, installing the whole thing in one stroke?

I should have mentioned the alternative to create a pdf together with an outline to the left which seems to have become possible today (but perhaps only with the latest versions of Adobe Acrobat Prof. or other expensive software), but then you will probably have compatibility problems with the respective pdf viewer your prospect/customer uses, let alone one page vs. double page and all this. With a viewer/executable viewer just replicating an outliner, it all would be without problems if you stay aware of the fact that you should cut up your content into pieces/items tiny enough to not ask for scrolling even on rather tiny screens: This way, the reader can hold focus within the tree, and navigate freely there, without switching focus problems.

I also should mention one big problem with every outliner / outliner viewer: You won't get a two-column layout with them, when with pdf this is possible, and large, "full-screen" pdf with two columns has certainly its advantages over just one column that shouldn't get too broad in an outliner viewer window, which thus would have to be artificially restricted in width, on today's large screens.

So, in the end, perhaps, realizing real good pdf's is not that bad an idea, over experimenting with outliner viewers, executable-file or not, but both ways are certainly worth discussing.

And then, there also are "flip-book makers" and such, but I don't think those will enhance your image in any way, since we are speaking of content you make highly navigationable, which is the strength of the outlining paradigma, when "flip-books" invite to to the browsing doubl-page by double-page, not by jumping freely around, so their tree navigation function, if they have any, would not be "first choice", then?

And a last aspect: I spoke of the 80 dollar AO eBook maker version (when in fact they also have a 40 dollar version for this), since there, you'll be able to have your own caption and so on (name of your corporation, not something like "ActionOutliner Viewer" or such), and I think for professional image creation, such details are important, and you would not want to have your content under the caption "myBase Viewer: Your content - your corporation name" or such (but as said, I did not trial, so cannot say what you'll get with the myBase thing).

It seems that the modern versions of the usual text processors can do pdf's, with headings becoming "bookmarks" = entries in the pdf navigation pane. Some outliners export to pdf. And it seems that rtf format plus some markdown (Pandoc style, etc.) will produce "bookmarks" of several indentation levels within a later pdf, so it seems this could be automatted from within any outliner, by putting the right number of special characters before each heading/item, depending on its indentation level. Also, there are Acrobat add-ins and such, but such tools seem often to be necessary just as a replacement for markdown codes, they don't do much but live from your not knowing how to process the details by yourself (macros, again).

Another aspect, it should be possible to do the navigation as in your original outliner, meaning by keyboard.

And another aspect, it seems (?) you can use your own icons (corporate identity!) for the tree in your outliner viewer (in original Maple yes, in Maple viewer: don't know), but not (?) in the pdf "bookmarks" tree; the same applies to any formatting within that pdf navigation tree, it seems: Everything is just standard there, I'm afraid, icons and entries (text), when in most outliners, you can use the icons and the formatting of your choice.

So, in the end, a good (and executable) viewer, replicating your outliner, would be best, except for the fact that pdf only (?) would get you a two-column layout if you don't want to replace your displayed text with pictures of a two-column layout in Word or such and then re-imported into the outliner, which would be totally insane.

So, as always, there does not seem to exist a real good solution to this "publish for your customers' screens" task.

Hi 22111,

MyNotesKeeper can create standalone exe-e-books, incl. tab-display.

It also offers a free viewer.


additional it can create (though they don't match the criteria above):

CHM-Files (which even keep the file attachments)
HTML-ebooks
epub-files
kindle-files

www.mynoteskeeper.com

best regards

Achim

Thank you, Achim, for mentioning MNK. As I see from the screenshots, it has much better search than AO (as has Maple), and it's not 10 dollars per give-out, so this is a worthy contender (supposing the search, in the executable viewer, is similar to the main program, but that is almost certain, since fiddling with it, from their side, would be much more effort than just leaving it in, and just taking out the edit functionality).

Of course, all three (MNK, AO, Maple) are quite "little" contenders, as outliners, so they don't have a broad import formats range, and for MNK, it's the usual rtf/txt, but then also html, doc (Word), and then Treepad and Keynote, which means that the Treeepad format is of high interest here since "your" outliner will probably be able to export to the TP format which then can be read (and I hope, properly processed) by MNK.

So it seems this is the best one of those three "little" solutions: Can probably be imported to it, has probably the same good search as in the original program, and is free. Of course, it should be possible to have a white background for the content, instead of the yellow one in their screenshots.

It would be interesting to know if some of the "big contenders" ("big" for the respective original programs) would do something "better" here, "looks" (in its viewer version) more "professional", or something (provided they have such a feature or additional program to create executable files to begin with of course).

As said, with today's screens, while for writing, we are "happy" with a tree and a content field, customers/prospects would certainly be impressed by a two-column layout, for better reading, instead of having too long lines: Just compare with this OS edit field, it's way too long for (proof-) reading (and at the same time it's way too flat), on a 1280-wide screen; for an outliner viewer, perhaps you could enlage the tree, in order to queeze the content field, but I doubt in such viewers you could freely distribute screen width for tree and content, and that then it would remain persistent when the reader opens the executable file: It will very probably revert to standard "distribution", so he will have to fiddle with it, or even cannot do that, since repartition between the two panes could be invariable, in the viewer version(s).

I always craved for two-column layout in the content field of my outliner(s), but of course, this will probably never be introduced (since the coding is difficult), even for the original programs, let alone their executable files, and we all know that in the content pane, text lines will flow to the right, making the text unreadable if your overall window is too large.

And we know that with pdf, these problems are inexitant: Be it for a two-column, or just for a one-column layout, you'll set up line length beforehand, and then there will be just white space, to the right, unnecessary but neither ugly nor intervening with what you've set up within your "real frame" if I may describe it this way.

So, for output, for reading, pdf might indeed be the "better" format in the end. Why? Because I fear that these outliner viewers / executable files-for-viewing, will NOT permit their creator to set up something like "full screen height", but the reader will need this. This means, it's either "maximized", with reading problems for too broad the text lines; or it's "normal size", which means your window will not be as large (good), but not be long enough, thus forcing your reader to either fiddle around with the window height, or forcing him to switch around between tree and content pane, for scrolling the latter, and I fear many prospects will do the scrolling, for some of your items, then closing it, instead of manually readjusting the height of your viewer window (and if you only write bits for the default size of your viewer, those will be too tiny for much of your content: Splicing up your texts is a good thing, but not to that degree!) - also because they don't KNOW that your text length is adjusted to exactly this format: default width, and then height: 1024. On page 1, you could tell them, but this "invitation" to manually adjust things, before even to begin real reading, leaves a very unprofessional impression! (And as we have seen, "maximized window" setting" would not be good for reading at all, even for just 1024x1280.)

Of course, there's the possibility that all or some of such executables would open exactly in that size you will have had the original program when creating the reading file (let's say 1024 hight x 950 width), but I fear this will be replaced by some "default" size.

So perhaps the better solution would be pdf - I don't know yet, perhaps I should ask for some experience with "pdf for screen reading" creation in the Adobe Acrobat forum.if there is no such "user experience" experience available here.

And there is always the possibility to buy some "flip-reader" creator if it has good outlining (with keys, too, not by mouse clicks only), and a pre-settable display size on the readers' screens : It's all about professional image, no?

Anyway, the MNK files creation seems to be a much better alternative both to AO and Maple, so thank you very much again, Achim!

I had hoped for some experience with such things here, since the creation of such "books" is the "natural" next step for many publishing needs, when you do your work within an outliner, which greatly facilitates (in theory at least) this transition.

During the next days, on bits, they will sell "eFlip Professional", 200 instead of 400 dollar, and they present another real-world example here:

http://www.pageflippdf.com/example/house/index.html#p=12

from which it can be derived that if you imagine such a thing for mostly text, with some pictures only, it's perhaps not the best kind of presentation, all the more so since on a 1280x1024 screen, text becomes rather tiny in this example.

But I think it's an instructive example, since it renders obvious my assumption above (but which I didn't mention there) that for a screen, I had in mind 1 tree, and then 1 content page only, with 2 text columns, for text lines not getting too long, and with this flipbook paradigm, you either have a double page, or a double page with a tree (which seems to be possible with eFlip Prof, even if I didn't see a real-world example), and this means you would have just one column per page, but one subject would be treated on the left pane only, or then, on a double page left/right.

Of course, there is the "flipping" effect, meaning screen graphics imitating a real page being turned, and within a (mostly) "all"-text book, I'm not sure at all this would have any other effect than going on the nerves on the reader, so I will not buy this, in spite of its price and it being a good product, I think: Keyboard navigation is possible within the flipbook, and perhaps even (not tried) within the tree if you have any, with it.

Also, in the linked example, font sizes seem to be adjusted to bigger/larger screens, and for the unnecessary navigation ribbon on top (which is ubiquitous in such flipbooks) you need a lot of screen space, when in fact they all could perfectly do without it, whenever they permit arrow key navigation (and with home/end, pgup/pgdn, and perhaps space for "next page". As for larger screens, very well, you would adjust the font size to the height, not to the width, but this navigation ribbon is there anyway (can't say if it can be hidden, without making it "full screen", which is not "maximized", and only "maxized" is acceptable as a format for prospects) and will thus be a (lesser) problem, even on larger screens (height 1200 instead of 1028 though).

So, except for ideas from my readers here - I might be overlooking something again -, it seems classic pdf, with a tree (and hopefully it will be keyboard-navigatable, which is far from sure: in the meantime I had a pdf example with tree which was only navigatable by mouse clicks!!!), is the format to be preferred, even when those pdf trees look a little bit awful, no?

To round up the picture: If you buy some flipbook software for several hundred dollars, it's not so much for the result you'll get, since there are numerous free offerings out there, also for the transposition of pdf files into flipbooks. But you pay the money, more or less, for the abilities (and hopefully, strenghts AND ease of use) of the creation software, of the creation process.

Then, it occured to me that we have to consider another aspect for the comparison of outliner exe files / viewers vs. pdf vs. flipbooks: It's presentation of search results to the "viewer", to the people expected to view your material with it.

Here, an executable file like the one mentioned above, in MNK, seems to be best IF it preserves, on the viewing side, its "original" "found terms table/list". On the other hand, when it's true that with a pdf, you can have a navigation tree, I don't see good presentation of search results for pdf, it's "one by one", by mouse click or by F3, and without the user even knowing IF there are additional finds for the search term in question, so he has to do the F3 just in case of... and let alone context/relevance considerations.

The same is possibly true for all flipbooks, but then, it might be possible that some flipbook creator creates much better flipbooks, unknown to me.

But then, let's consider pdf's once more! Since even their regular navigation pane entries ain't but bookmarks, brought in a tree form, you should be able to build up an alternative tree, or in practice, just ADD some other tree "headings" into the tree, for MORE such booksmarks, and under which you can list "bookmarks as search results".

This would not replace regular search, but my idea is, most prospects / info users would often search for some standard terms they are interested in (like the main entries within the index of a book), and which are spread all over your navigation tree.

Now why not have, in this second part of the tree, something like "Direct access to...", and then a list of such relevant search terms the regular user might be interested in, and have just those same booksmarks for the relevant pages, that are already within your navigation tree, too?

Such a system

(that you could also replicate within a flipbook file, and also within the "viewer" file of an outliner: here, if bookmarks/references are not allowed in the tree, just copy (!) the relevant items from "above", into a "last section" of the tree: since it's "viewing only" anyway, the distinction between clones and copies isn't relevant here)

would present the additional advantage of GUIDING the user/prospect to some relevant "search" terms = relevant subjects YOU want him to check about, and this means that such a structure will greatly facilitate your EDITING/WRITING process, since now you can be sure that he will "SEE IT", even for subjects that logically should be spread over your whole text compound.

Which means, your text can be much more "natural", from "natural" subject to the next, without your being "forced" to "integrate the whole side-ways picture" into such subjects, but for which this "side-way" subject is secondary only.

This means you will be sure he will "get" those "particular" subjects, from gathering the relevant pages (where only parts of it are treated, those parts constituting a "whole picture" if brought together) under such specials headings, without interrupting the "flow" of "natural reading".

Of course, you should assure that those "parts being relevant in another context" of your "regular" subjects are visually distinguished within those "regular" subjects (for example, by bolding the passages/"search terms" here that become relevant in the special context, together with even an additional link within the text, in the form "(cf. ThatSubject)"), in order for your "reader" not having to "search" within those pages when he accesses them, in a row, from within that special part of the tree (and as I have said above, he should not have to scroll your content anwhere, on any screen 1280x1024 and above).

Such a text construction would permit you to have your "readers" read your "special" subjects, spread over "natural" subjects, both fast AND within their otherwise-relevant context, which is NOT the case if you try to develop those "gathered" subjects on their own, again, meaning WITHOUT the respective contexts in which you previously had positioned PARTS of this "spread" subject.

It goes without saying that in some instances, such a "particular treatment" would be helpful indeed, but in many, the "leave it spread" construction described above will be preferable.

So we see here that even in texts-to-be-read, "doubling/gathering" of parts, here by "virtual cloning", is a very interesting concept for "information management", and which can "straigthen out" your texts, meaning it will spare yourself, and your reader, irrelevant-there-developments of sub-subjects in other contexts, since those developments will be created quite naturally from the gathering of those parts.

It also goes without saying (and especially since such "special subjects" are perhaps only 12 or 15, for a work of perhaps 300 pages/mini-subjects) that you should gather, into an editor for example, those "spread parts", in order to see if the ORDER of them is ok, in order to make this "spread subject" something "readable on its own".

Here, remember your "special" subtrees (= the order of your bookmarks to those parts, there) are NOT bound to replicate the order of those pages within the very first, the "natural"/"chronological" part of your tree: Here, in this second part, you can mix up your reference in a way that makes sens for this particular subject!

As for ebook creation directly by your outliner, think again.

Your choice is reduced to the extreme if you try to do your work in program x, which then must create an ebook, and which then should also have a pleasant look and satisfying functionality.

MyNotesKeeper is not that appealing, layout-wise; Maple charges 10 bucks plus VAT apiece, and ActionOutline's separate ebook creator costs 90 bucks (no problem) and does not present any acceptable search functionality (which is a real problem); developers of the heavyweights don't seem to be interested in joining this feature (there are 2004 (!!!) forum entries in the MyInfo forum where the developer spoke of introducing such a functionality...). Also, a "viewer" instead of an ebook, is obviously NOT acceptable anymore, i.e. it should be an executable, not a viewer, and then a file to be loaded into the viewer - except for pdf's, but here, the standard viewer (be it from Adobe, be it an alternative) is pre-installed on every system.

Today, there is Pdf Flip at bits, 100$ instead of 300, and the numerous real-life examples on their website are highly instructive - it is obvious that if you want to do sort of a "magazine", such "flipbooks" are the medium of choice, but for information purposes, this would be totally a) over-the-top AND b) totally impractical for your reader.

On the other hand, it's obvious that pdf's ain't really but the second-best solution - it'll always be another pdf, not something that is your own corporate image at 100 p.c.

So let's see what you would like to have: You want a tree, with easy navigation (by keyboard); you want a caption not with ".pdf", "Adobe" and such, but with your company's name, and then the "book name"; you want a decent search function, which means, ideally, that the tree is replaced by a search results list, and, ideally again, the reader should be able to toggle easily between the two, which means the search results would not be lost by displaying the tree again. And it should all have a pleasant, professional look, also for pics here and there (no videos in my case, but your mileage might differ).

And yes, ideally, it would display two text columns wherever you want them, but this is the one criteria that would probably eliminate any possible solution from our choice (or is there a program that will display 2-column pdf's in its viewer?).

Now, there are many "ebook creators" to buy, and I'm pleasantly surprised that many of them offer, at reasonable prices (and, of course, without royalties, as is the case for Maple), totally acceptable "screen experience", their functionality must be further examined, of course.

This software category is not very well known, to say the least, and we do not speak here of those tools that do ebooks for special "readers", from amazon, Apple, some doomed bookstore chains, etc.

We can continue to use the outliner of our respective choice, and then there must be a stable export format, and from which then the ebook creator should import your tree - this remains to bee seen, of course; it would be weird to have to export, from a tree format, into some flat format as .rtf or .html, from which then the ebook creator will create a trew anew - perhaps some of them will have some standard outliner formats as import formats?

Anyway, your reader is not interested in your productive environment - he wants content of interest to him, in a professional "package" which allows for smooth reading (and this means, smooth navigation, and smooth searching, too), so the "visuals" of the ebook creator in question seem to be of extreme importance here.

Of course, there will always be the alternative to present such content within your web site, but if you want to have some control over this content, there would be coded access only, and which is more, with each customer/prospect needing his own access code, which is the only sensible way to monitor if some of them gave their codes to third parties.

It goes without saying that as soon as it is a web format, you can display two columns, either with html tables, traditionally, or, now, with css, of course. And this brings me back to ebook creators: If they allow for html/css content, or if html is their native file format, instead of .rtf, they could become an ideal presentation format for office use. So the traditional problem is the ubiquity of the .rtf format for text formatting, and which doesn't easily permit 2-column layouts, whilst it's perfectly probable that more and more developers will abandon that old MS format. Btw, my formatted-text export is rock-stable with html, but not so with .rtf, and thus I often use the html export for "plain-text" export, but while preserving my formatting codes - then, I replace the html codes with the appropriate codes for PageMaker in the past, now for InDesign. This is to say that the html export is perfectly "readable" for import usage, whilst using the .rtf format is often asking for trouble. Wysiwyg in your outliner is often .rtf-based, but then html export is the perfect format for replacing the wysiwyg by dtp codes, similar for footnotes and such - which means no outliner ever needs a "footnote" functionality since this can be simulated by such codes. The real problem, as said elsewhere in this forum, is the missing cross-referenciality in outliners: You can do something with external macros, as said, but having such a functionality in-built, would be extremely useful.

Anyway, there are some interesting ebook creators out there, and if the transition of your outliner data into their outlines is done smoothly, executables created by such ebook creators could be the very best possible solution here... if there is a solution for the 2-columns layout at least in cases where you really need it.

To be continued here:

http://www.outlinersoftware.com/topics/viewt/5203/0/some-outliners-and-the-features-unicode-search-in-the-tree-website-publishing