Forum Posts Feed
Viewers? eBook Creators?
< Next Topic | Back to topic list | Previous Topic >
Posted by 22111
Oct 14, 2013 at 11:30 AM
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!
Posted by 22111
Oct 16, 2013 at 02:15 PM
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?
Posted by 22111
Oct 20, 2013 at 10:18 AM
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!
Posted by 22111
Nov 8, 2013 at 03:02 AM
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.
Posted by 22111
Nov 30, 2013 at 03:19 PM
To be continued here: