For a reader, is TiddlyWiki better than reading a PDF, and why?

[Mobil Home]

I am thinking to publish "e-books" in TiddlyWiki format, but the problem is that I cannot publish it via Amazon Kindle Self Publishing  in TiddlyWiki format.

So the question arised:

From the reader perspective, is reading something (something with high complexity) in TiddlyWiki a better experience than reading it in an advanced PDF or E-Book format?

What are the pros and cons?

Is TiddlyWiki more suitable for publishing books than E-Book and advanced PDF format?

[Saq Imtiaz]

If you haven't already seen it, this might be of interest:

https://groups.google.com/forum/#!msg/tiddlywiki/_VLufc4Svp8/PiSC6LmgAgAJ

Would be great to get Xavier's perspective on this.

[Riz]

Yes.
PDF do not flow text, which makes it hard to read in mobile phones. PDFs are not easily annotable. The solutions for annotating PDF either permanently modifies the file or keeps the annotations tied to that software which might not be available cross platform. Epub annotations follow the same story.

TiddlyWiki allows you to annotate the book and avail annotations in all browsers.

Of all the purposes TiddlyWiki is proposed to be suited for, ebooks and documentation is the best IMO

[TW Tones]

Mobil

As the others had said tiddlywiki has a lot more power for interactive smart documents. However it is also easy to convert them to PDF (and possibly other formats) if desired. Using tiddlywiki to research and analyse is no doubt better. Its the old question of who is the audience. If the book is open source you could publish the PDF with reference to the online wiki as well. Using freelinks and search tools offer substantial functionality as well as annotation tools.

Not withstanding this I like using the Foxit PDF reader and its annotation features.

Regards

Tony

[Mat]

Mobil Home wrote:

... is reading something (something with high complexity) in TiddlyWiki a better experience than ...

PDF's are typically static. TW can simplify complexity with e.g Reveal widgets or StretchText (..to bring up an ol' goodie) 

Though presumably you'd have to hide most of TW for the reader.

<:-)

[CJ Veniot]

G'day Mobil Home,

To me, there is absolutely nothing wrong with a static PDF until I find myself bouncing around a lot between pages because something on Page X causes me to go back to Page X - Y, and I find myself trying to follow a thread in my head that the PDF isn't supporting.

That's when the ability to see extra information related to the current page, without leaving the current page, is oh-so-awesome.  Whether it be with simple things like modals or reveal widgets or tabs, or some other add-on mechanisms to see extra "stuff".

i.e. the ability to take a short non-linear side-trip within the greater linear journey.

That reminds me of a bit from this lecture by Ted Nelson, starting around at the 8:11 mark and  to the 13:30 mark :

https://youtu.be/9FqVqZXUFUQ?t=491

Sure, when writing a book in TiddlyWiki, you can certainly provide different sequences for content, but that gets hard trying to imagine different sequences.  Much easier to provide just one linear journey, but if you think of different linear journeys: cool.  To me, nothing wrong with just one linear journey, but the ability to take those short non-linear side-trips without losing the contextual milestone of the greater journey, that is the dynamic goodness of TiddlyWiki over static PDF.

Hmm.  I think that turned into a philosophical projectile rant rather than actual help.  Oops?  (Crap:  now I have "Oops, I did it again" stuck in my sponge...)

[Xavier Cazin]

Hi Mobil Home,

Others have already answered on the clear superiority of TiddlyWiki over other formats to express complexity in writing, and I think we still are far from having explored all the benefits of non linearity, asynchronous interaction, computed content, not to mention dynamically embedded external resources. My belief is that TW5 can help authors create Open Works, or better yet Works in Movement, as predicted by Umberto Eco back in 1962 (!) in his beautiful essay The Open Work.

However, a critical part of your question is "I cannot publish it via KDP". Actually, Amazon, Apple, Barnes & Noble, Google and Kobo have imposed ePub and Mobipocket to the publishing industry as the sole formats they accept to handle. Eventhough you may find independent bookstores that accept more formats, they represent peanuts in terms of revenue for the publishers. So, as of now, reaching your readers through actual sales cannot be a motivation for you as an author...

This may change though, as ePubs become easy to convert into TiddlyWiki (via Jeremy's side work on ePub parsing) and as Books in Movement get created and promoted, but this is a chicken and egg problem, so don't hold your breath!

Cheers,

-- Xavier Cazin

On Mon, Jul 20, 2020 at 7:35 PM Mobil Home <mobil...@gmail.com> wrote:

I am thinking to publish "e-books" in TiddlyWiki format, but the problem is that I cannot publish it via Amazon Kindle Self Publishing  in TiddlyWiki format.

So the question arised:

From the reader perspective, is reading something (something with high complexity) in TiddlyWiki a better experience than reading it in an advanced PDF or E-Book format?

What are the pros and contras?

Is TiddlyWiki more suitable for publishing books than E-Book and advanced PDF format?

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/10168c92-ff03-49f8-8b07-f7276579c128o%40googlegroups.com.

[Mat]

Xavier wrote:

[...] Amazon, Apple, Barnes & Noble, Google and Kobo have imposed ePub and Mobipocket to the publishing industry as the sole formats they accept to handle.

I know some reading devices have had primitive built-in browsers. Does anyone know if this is a fading or growing trend for these devices? My assumption is of course that these could then show TW files, at least if the browsers are better than the one I saw on an older device a few years back.

<:-)

[TW Tones]

CJ,

 

Sure, when writing a book in TiddlyWiki, you can certainly provide different sequences for content, but that gets hard trying to imagine different sequences.  Much easier to provide just one linear journey, but if you think of different linear journeys: cool.  

This comment reminds me of a compelling use I put tiddlywiki to before I decided to go out on my own as a business. My last working resume was built in tiddlywiki. I could customise and generate multiple views according to who I was sending it to, including shot and long forms. I even had pdf and word versions generated and available to the reader.

Dynamic and adaptive documents are really good in tiddlywiki.

One conceptual leap I have heard of which is not yet a reality is using analytics more. In this case the way you use a document can have all kind of analytics on your use collected then provided back to you so you can learn about your own interaction with the document. and also provide insight into your interests and all before we even consider alternate versions like the readers digest version included with the full version, annotations and automatic glossaries and more.

The thing is what can be done with such interactive documents is still in its infancy.

Regards

Tony

[Xavier Cazin]

Hi Mat,

Yeah, you often can find fully functional browsers in the "experimental" sections of many readers, and they do load and render TW5 pages! But they are almost unusable right now, not only because navigating and rendering is very slow, but also because the greyscale does not match (probably a special theme would do, though).

Cheers,

-- Xavier Cazin

--

You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/67da9db5-0f8f-45a3-9f53-9f1df3a9d59do%40googlegroups.com.

[Mat]

Xavier wrote:

Yeah, you often can find fully functional browsers in the "experimental" sections of many readers, and they do load and render TW5 pages! But they are almost unusable right now, not only because navigating and rendering is very slow, but also because the greyscale does not match (probably a special theme would do, though).

A special theme is of course the least problem :-)

But OK, navigation and rendering is still slow. I was hoping it had improved enough by now. I find a few intersting videos though:

This one is from 2017(!) and demos editing a google docs document (thus presumably online). Quite good actually. If that screen technology is representative for what is used in readers, then that would indicate it may be the reader device rather than the screen itself that causes slow rendering. It is not clear if that is just a monitor or a reader.

This one only uses eink for a monitor. Again 2017(!) and IMO both impressive and good enough speed wise IF it were a reader, which it is not though.

<:-)

[CJ Veniot]

G'day TW Tones and all, 

This is such an awesome thread.  And I'm oh-so-envious of how all of you are so smoking good at eloquently expressing them quality thoughts.

With the wiki product I use at work to document the software system I support, I have the information componentized to the hilt so that I can provide the various information views for various purposes/audiences: operational support, project/task management, user help/guides, architectural, change logs, release planning/history, help desk ... ad infinitum, ad nauseum.

So write once, use and reuse everywhere.  Intertwingled journeys galore.

Just throwing that out there 'cause TW Tones' example use case of multiple views gets my intertwingularity mojo right excited.  (Yeah, I love this stuff.  It just tends to hurtle out of me like overcooked spaghetti flung at a wall.)

Huh, everything is linked to everything else by pretty much one degree of separation.  I just got a flashback to the Patch Adams "pool of noodles" scene:  https://www.youtube.com/watch?v=t5RN8cYKCJ4

[TiddlyTweeter]

Mat wrote:

But OK, navigation and rendering is still slow. I was hoping it had improved enough by now.

Dynaview is very effective on the epub example Xavier gave in past. They are ideal for that. Its a "render when ready" approach.

E-Pubs tend to linear, as if they were books with a linear begin-middle-end, the scope is determinate so Dynanview, under that context, performs well IMO.

TT

[TiddlyTweeter]

1 - TW is better (in theory & practice). Once you got your book in it you can do things other tools can't. No doubt.

2 - In practice e-pubs are a market sector. Identifying TW as a player in that sector as a reader is not a trivial matter.

3 - EXPORT to the formats recognized by Amazon et al might be a thought in this. So users could prep for the major commercial formats.

Thoughts.

Best wishes

TT

[Joshua Fontany]

I Love Tony (TW Tone)'s example of outputting multiple view of a Resume depending on audience. THAT ALONE is the #1 advice given to job-hunters in the current digital landscape, but that often mean hours of customizing a resume for a single application that is then never re-used.

I am also looking at TW as a "publication platform" and agree with many of the points here in this thread. To follow up on Xavier's comment of "embedded content", I have something special in the works that may just be launching later today (hint: Oembed for TiddlyWiki5). :)

If I can figure out a couple of bugs... if not I may just release a Beta that you would have to configure manually.

Best,
Joshua Fontany

[TW Tones]

Joshua et al.

You hinting at more Easter eggs from you always excites me.

On Wednesday, July 22, 2020 at 5:45:56 AM UTC+10, Joshua Fontany wrote:

I Love Tony (TW Tone)'s example of outputting multiple view of a Resume depending on audience. THAT ALONE is the #1 advice given to job-hunters in the current digital landscape, but that often mean hours of customizing a resume for a single application that is then never re-used.

I get your point here, but such a resume will be reused every time one wants applies for a job, It becomes a career repository. Even an interview preparation tool and more.

I also design with a view to one time generalising the solution for others, and example may be templates that take the same details and presents them according to different CV standards, and fads.

Because of tiddlywikis versatility I think sometimes we need to be a little more specific when discussing, these variations come to mind here;

• as a tool to managed text to later be published
• creating interactive alternatives to book publishing
• As a reader of existing published books PDF epub...
• as a way to publish a book with in it 
• The whole wiki is the published book
• It contains the published book within it eg included PDF
• Providing tools to the reader of published works including annotation
• as a way to collect then generate and publish books as output in varying standards, PDF epub...
• as a way to generate new published documents from collected documents (mash  up)
• Provide an independent tool for the review or criticism of published works
• Provide an independent tool for the detailed research of published works

Regards

TW Tones

[john mcginnis]

Re:[tw5] For a reader, is TiddlyWiki better than reading a PDF, and why?

Wrong question. What is the function of a PDF? What is the function of TiddlyWiki? Well it can be boiled down to -

* A PDF was a concept to provide an immutable text document. That tech has figured out how to bend the rules does not invalidate the intent of a PDF.

* A Wiki was a concept to provide a mutable text document for both creator and reader. 

Different mission, different context.

A PDF is best for providing a reproducible document fairly free from tampering. The reader would have the same experience today or 20yrs from now a copy of 'Clear and Present Danger'. The reader's context may change but the document has not. A Wiki in a sense is a proof of work, a chorus of many if so allowed, updated as circumstances dictate. Its best use is via the creator(s) of the document(s). It can benefit the reader provided the understanding is the wiki can change. 

The Wiki would be great for creating the resume, terrible for distributing it. I will not provide my resume in anything other than PDF form. I have been in way too many instances where a headhunter changed the content of a resume (in .docx form) that I should not have been, would not have considered, the interview. You are your own brand, never let someone else modify your marketing. It can have disastrous consequences. 

--

You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/6ea4880c-531a-4147-9636-4bfc7d493d16o%40googlegroups.com.

[TW Tones]

John,

Good points but not universal. What you describe is a common and valuable use. Its ability to be distributed and confidently be read is one of PDF great values, but this is also true for single file tiddlywiki's HTML etc...

Its always important to remember the wiki in tiddlywiki is a useful descriptor, but in no way encompasses it possibilities. I prefer "tiddlywiki Platform" that can accommodate or generate PDF's if desired.

Yes send a PDF version of a resume, but I generate it from my wiki, edit update and generate again. The PDF I send is somewhat immutable over time. If I overwrite the file it has being "muted" :)

I collect PDF's from authorities, or documented tech manuals, however some are forms that accept input, signature and return, but I also use my beloved Foxit PDF (Free) to annotate these for my own record, even extract content and reuse it.

I can save a tiddlywiki away in an archive with the intention it is an immutable record of the circumstances at the time it was archived, so I can treat tiddlywiki as immutable as well.

Now start integrating the two and new variations occur. Interfering with your universal claims.

So the for the question "For a reader, is TiddlyWiki better than reading a PDF, and why?"

The answer as is often the case with tiddlywiki is "it depends".

Regards

Tony

On Wednesday, July 22, 2020 at 10:47:52 AM UTC+10, john mcginnis wrote:

Re:[tw5] For a reader, is TiddlyWiki better than reading a PDF, and why?

Wrong question. What is the function of a PDF? What is the function of TiddlyWiki? Well it can be boiled down to -

* A PDF was a concept to provide an immutable text document. That tech has figured out how to bend the rules does not invalidate the intent of a PDF.

* A Wiki was a concept to provide a mutable text document for both creator and reader. 

Different mission, different context.

A PDF is best for providing a reproducible document fairly free from tampering. The reader would have the same experience today or 20yrs from now a copy of 'Clear and Present Danger'. The reader's context may change but the document has not. A Wiki in a sense is a proof of work, a chorus of many if so allowed, updated as circumstances dictate. Its best use is via the creator(s) of the document(s). It can benefit the reader provided the understanding is the wiki can change. 

The Wiki would be great for creating the resume, terrible for distributing it. I will not provide my resume in anything other than PDF form. I have been in way too many instances where a headhunter changed the content of a resume (in .docx form) that I should not have been, would not have considered, the interview. You are your own brand, never let someone else modify your marketing. It can have disastrous consequences. 

On Tue, Jul 21, 2020 at 7:20 PM TW Tones <anthon...@gmail.com> wrote:

Joshua et al.

You hinting at more Easter eggs from you always excites me.

On Wednesday, July 22, 2020 at 5:45:56 AM UTC+10, Joshua Fontany wrote:

I Love Tony (TW Tone)'s example of outputting multiple view of a Resume depending on audience. THAT ALONE is the #1 advice given to job-hunters in the current digital landscape, but that often mean hours of customizing a resume for a single application that is then never re-used.

I get your point here, but such a resume will be reused every time one wants applies for a job, It becomes a career repository. Even an interview preparation tool and more.

I also design with a view to one time generalising the solution for others, and example may be templates that take the same details and presents them according to different CV standards, and fads.

Because of tiddlywikis versatility I think sometimes we need to be a little more specific when discussing, these variations come to mind here;

• as a tool to managed text to later be published
• creating interactive alternatives to book publishing
• As a reader of existing published books PDF epub...
• as a way to publish a book with in it 
• The whole wiki is the published book
• It contains the published book within it eg included PDF
• Providing tools to the reader of published works including annotation
• as a way to collect then generate and publish books as output in varying standards, PDF epub...
• as a way to generate new published documents from collected documents (mash  up)
• Provide an independent tool for the review or criticism of published works
• Provide an independent tool for the detailed research of published works

Regards

TW Tones

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tiddl...@googlegroups.com.