I’ve read War and Peace! It’s really good!
The initial aim of TWPUB is to upcycle the EPUB format into a multibook format based on TiddlyWiki, that allows users to write on their books as well as read them, through the most versatile multimedia apps, namely web browsers.
Of course, books written directly in TiddlyWiki would be superior, but they would request a know-how that isn’t common in publishing. By contrast, there are literally millions of EPUBs around, so why not start from here.
@Mark_S remark regarding DRMs is unfortunately valid, but some publishers allow small bookstores to sell books without DRMs : https://www.ebooks.com/en-fr/searchapp/searchresults.net?Filter.FormatType=Epub&Filter.DrmFree=true.
@poc2go I only just recently saw your comment so allow me to add my two cents to this topic.
TiddlyWiki is a powerful platform, and offers a lot of features equivalent to or superior to other more “hip” alternatives like Notion and Roam. The problem as I see it from running experiments for a possible TiddlyWiki online platform is that it’s a question of meeting mainstream problem solution fit in the most convenient and painless way possible.
People want to use tools like TiddlyWiki for many different things. Segmenting these user needs/intents into clear categories with proper SEO practice is I think one key towards driving more traffic to TiddlyWiki. In addition, most folks I’m afraid are not tech savvy. You give them any edition of TiddlyWiki and they see the potential, but they feel overwhelmed by it. The end result is them retreating back to a tool that they are most comfortable with, or in the best case scenario, they restrict their use of TW’s toolset to a workflow that resembles Evernote. So, designing TW editions for mainstream adoption should keep these facts in mind.
However, having said all this, we should also remind ourselves one thing: mass adoption is usually led by a select few group of influencers who act to propagate the tool towards mass adoption via anything from word of mouth to making it a mandatory requirement. We in the community are the influencers so we should continue to play our role as ambassadors for TW and insist on its use wherever possible, and contribute code/feature suggestions to solve real world problems we encounter as we use it. TW is thriving because we’re using it everywhere, sometimes for things that even many of us didn’t think was possible.
So, in summary, to ensure TW user/market share if I may:
- Focus on user needs and segment these needs. Stay focused on meeting those needs, but allow for extension.
- Design for a broad class of user backgrounds, and remain user-centric
- Continue to influence adoption like mad! Be TW’s propagator at work, at home, at a conference, etc.
WRT PDF use specifically, I’d suggest that there are probably many ways we could use TW to enhance the user experience in dealing with PDFs and other published formats like EPUB, but it really depends on what problem we’re trying to solve. This topic deserves its own discussion, but I suggest that, as far as PDFs are concerned, I would rather not use TW just to read PDFs (there are better tools for that), but instead use it as a meta tool for handling curation and researching many pdfs at a time, if that makes sense. That adds value given that other tools that do this aren’t free or open, and aren’t as lightweight as TW. Hope that makes sense. This probably needs to be its own topic for discussion.
I agree. In addition to technical discussion of TW, presentation of end solutions by functional need is still needing adding in public fora.
In my fantasy a search for TiddlyWiki might bring to the fore …
-
Tiddly Anthropologist
-
Tiddly Novelist
-
Tiddly Back-Problem Tracker
You get the idea?
The issue here is not generic tech issues so much as precise differentiation of end purposes. Each app with its own approach to the specific problematics involved.
Just a comment
TT
Indeed. My primary concern however is not getting into a situation where we join all the other major tools for thought platforms in a perpetual race to the bottom (see here).
Differentiating ourselves in a saturated market: here lies the crux of the problem. You can either be like everyone else, or you can try to actually solve excruciating problems plaguing this ecosystem. That’s what we’re all about!
I think the best thing about TWPUB is that it is dynamic and card-based, and can be put together very well, which fits well with the incremental reading proposed by SuperMemo author Piotr Wozniak.
This is something that PDF do not have, and importing PDF into SuperMemo is very cumbersome.
Agree. And that is a great point! How to address this issue? I have three broad comments …
-
TW’s flexibility is so vast you can basically do most anything the net can do in it.
-
That very flex is (maybe) an issue in promoting “apps” (functional specific TW implementations). What do you promote: the “app” or “TW”?
-
Also, in a way, with a neat “app” (e.g. a novel in epub format) in a way TW (maybe correctly?) disappears? What I mean is that with a functional whole for purpose (hopefully?) you don’t need explain TW, merely the behaviour of the “app”.
Regarding the OP by @poc2go, the promo side of TW I would love if we all talked about more sometimes. It would be good to see it used more, even if the end-page-user doesn’t know what it is.
Just a comment
TT
Right. And interesting you can go more with it too. Easily adding linked “segues”. And potential to annotate to infinite transcluded (i.e. nested) note depths.
I thought your OP very interesting.
Just comments
TT
Chiming in here with my general thoughts on TWPUB. My challenge is I would like a way to read EPUB directly in the browser, but also as typographically pleasing as possible. I would like to read them within a TiddlyWiki so I can customize the CSS as much as possible. Unfortunately most EPUBs that one might encounter aren’t always internally (HTML) or typographically consistent (em dashes for example). I’m not sure if this use case of using TWPUB as a general purpose EPUB reader is even possible.
-
I recently wrote about creating a standard to make filters for plugins, themes etc within tiddlywiki - so that tiddlywiki is more consistent, logical and non-linear too… anyway this is the first step.
-
The second step is to have more serious governance as a community, to focus on really building more value. For this second case, some companies do things like ‘user questionnaire about user experience’, ‘some companies implement ITIL to organize services and products’, ‘other companies tried to extend the product - see Figma that works and/or integrates practically any web product like google drive to display files inside a design project etc’
each way is good or bad in some cases, but what I want to leave here would be this idea… to seek what the end user wants, in this case the people who will use the tiddlywiki software that can be developers, non-technical users or end users (companies, business partners, schools, institutions, governments, non-governmental organizations, etc.)
Right. What is interesting in your point is the potential complexity of doing that well … What I mean is the “languaging” to those different groups might well need to vary?
For instance, in my own case I learn what a tool is by examining it “visually”, using it. But that implies it already exists–that I have something to examine .
I think that is a bit different for those users/devs who better understand the underlying tech? They are more able to “think-forward” to what an app “looks-like” even though it does not yet exist?
Just a comment
TT
this I don’t find that problematic, big apps have a search category… the same could apply here - example: “plugins”, “models”, “templates”, “templates to gamers”, “plugins for developers” etc
another way to make tiddlywiki better in terms of GUI, user experience could be this:
- add showcase in tiddlywiki as Framework7 Showcase and/or https://threejs.org/ → https://tiddywiki.com /showcase/
- add ‘user questionnaire about user experience’
- 'implement ITIL to organize services and products’
- tried to extend the product: opensource/closed-source/public-source/foss source etc
Right. I’m not disagreeing with you really. I’m not anti-centralisation.
As @jeremyruston wrote—of some points I made earlier …
So, I may be in a minority of one?
But it seems to me that, finally, there are TWO main routes …
1- From TW Central to find “Fitted Applications” (your cases)
2- From An Application to find TW Central (my thought case)
Both seem viable to me and could complement each other.
I think it is an empirical matter to know where & when one is better than the other?
Just a comment, TT
another way to make tiddlywiki better in terms of GUI, user experience could be this:
- add ‘user questionnaire about user experience’ → this could be done here on discourse or anywhere like google forms
- 'implement ITIL to organize services and products’ → this could be done here on discourse or anywhere like google forms
- tried to extend the product: opensource/closed-source/public-source/foss source etc → this could be done here on discourse or anywhere like google forms
- add a category in discourse called integration or business partnership - where we can advertise companies that want to implement tiddlywiki
TiddlyWiki foundation and philosophy is geared toward individual and personal longevity of data security and access. But in a commercial world is more about publishing timely updates of evolving and current data sets.
In the commercial world time is everything. The quicker can be implemented, the sooner, and less costly the better. Is not storage of dated information.
The real question is what is the focus of TiddlyWiki? Is it to store and preserve personal information, or to be used as a tool to publish changing information to the world? If for personal information - then TiddltWiki is pretty much complete. Is only a matter of enhancing personal access to that data, with ever more complex filter markup - with """
, {{{
, <<
. Which is making personal data more unaccessable barring a full, indepth understanding of TiddlyWiki internals.
More and more of TiddlyWiki development has been focused on online, cloud based information presentation and synchronization. Just a quick view of all the ‘saver’ options will contest.
The number one issue with selling TiddlyWiki to the corporate ‘board’ is the learning curve. The power of JQuery and BootStrap is they are ‘dumbed’ down. JQuery allowed a single codebase to work in IE, Chrome, FireFox, Sarfari - without special coding; Bootstrap allowed menus, headers, content, and footers to be built quickly without knowledge of the underpinnings required to make it work. Want a a new font? Google Fonts - given a high level CSS (html, body) change - re-visualizes the site.
I find TiddlyWiki to be unfocused. @jeremyruston has always insured that data remain compatible from software release to release - and kudos for that, but there is a point where the software development of two decades ago - just can not compete with our quickly evolving world. Javascript now has ‘classes’ - gone is the era of 'prototype’s.
As @TiddlyTweeter would say - ‘Just a comment’
That is not true. The Data is accessible and always will be, and features allow you to make it more accessible with automation.
Actually TiddlyWiki is easier than those if you know, learn tiddlywiki.Its a higher level “language”.
- Tiddlywiki works in all these environments and more without difference.
- Bootstrap CSS can be use in tiddlywiki along with other open source
- Work in tiddlywiki
I am happy to “agree to disagree”, but I do
Javascript is still a functional language, and classes us just some syntactic sugar that initializes the prototype chain.
I have no idea what that means!
But it sounds like maybe I should?
Does it matter that @poc2go comments …
Attempting to understand, TT.