Hi Keelan, Apologies for the late response, I wanted to wait to reply to your feedback until I had the time to do so properly. I am always happy to discuss at length when the feedback is both detailed and pertinent, as yours has been. I am going to going off on what seems like a bit of a tangent at first, to properly reply to some of the points you raised.
Firstly, I'd like to explain the concept of a TiddlyWiki edition, sometimes also referred to as a vertical edition. Simply put it is a TiddlyWiki meant to serve as a starting point, with a set of plugins and tweaks preconfigured that work together well with no clashes, to provide a specific set of features or workflow. The best example of this currently is Stroll from David Gifford, which encourages a notetaking style dependent on backlinks. The key part that is relevant here is that with an edition, you have the ability to make sure that all the plugins play together nicely and don't clash, and complement each other with their functionality. When writing a plugin you have to try your utmost not to make changes to the default TW behaviour beyond what you absolutely need to, to minimize the chance of clashes with other plugins. As an example consider Streams. If it were to be extended to tweak the default search results, it would clash with any other plugin that extended the search results or the search interface. With a pre-configured set of plugins, this isn't an issue. Furthermore, the more changes you make to the defaults in TW, the greater the chance the plugin will need updates when the TiddlyWiki core is updated, increasing the maintenance burden of the plugin. So at this point, you would be right in thinking that editions is basically what you alluded to when speaking of linear guides or "choose your own adventure" use cases. There are some significant challenges inherent in creating editions, amongst them: - the need for extensive user studies and testing, to design, test and refine a workflow and featureset. This requires a significant amount of time and effort from both the developer and the users working together. Furthermore it requires developer(s) and users working together towards the same end goal in an effective and efficient manner. A common shortcut that is employed is for the developer to also act as the user, which works in situations where the development is driven by the developer's own needs. This, by the way is not the case for Streams which I personally do not use and was created as a tech demo for the community. I will come back to this later. - Customizing, simplifying and optimizing the workflow for a specific use cases often involves making choices that limit or alter functionality. While the components of an edition can be designed to work together well, they are likely to clash with other plugins available in the community. This often leads to discontent from the users that are unhappy with the perceived lack of flexibility and customization in an edition, considering that it is still based on TiddlyWiki. For example let us consider WYSIWYG editors, something that has been a frequent topic of discussion in the TW community. Due to the way that TiddlyWiki widgets, macros and transclusions work, implementing a full featured WYSIWYG editor would be a very significant, challenging and time consuming endeavour. There have however been comments in the community that even a WYSIWYG editor that *only* handled simple text formatting would be useful for everyday writing, but at what cost? I have a prototype of such an editor that only supports text formatting, but that means giving up custom HTML and widgets and macros in the tiddlers where you use it. So for instance, in your case to use such an editor you would need to give up using the refnotes plugin in those tiddlers. This perhaps hasn't been the most ideal example, but hopefully it serves to illustrate the point about compromises and limitations imposed when designing specific features and workflows. In some ways TiddlyWiki's flexibility works against it in these situations, by setting certain user expectations. - Last but not least is the maintenance burden that comes with providing an edition, and keeping it up to date with TiddlyWiki core updates as well as plugin updates. I do agree that there is a lot of untapped potential in providing editions that serve specific workflows, but I am uncertain if a community as small as this has the resources to tackle this. Similarly Streams would benefit greatly from an edition that incorporated it and addressed some of the issues like search results, backlink results etc. However, considering both my limited availability and the fact that I do not use this myself, I am not the appropriate person to do so. Regarding Streams and the motivation behind its development: Overall I feel that there is a lack of innovation in the TW5 community in recent years, compared to the peak years with TiddlyWiki Classic (the previous version), especially in light of its potential. This may be in part due to a change in the demographic, I think there were more active developers in the community back then. The availability of more alternative platforms has probably also played a role. My perception is that there is far too great a dependence on Jeremy (the creator and developer of TiddlyWiki) for new ideas and features. Considering how long TW5 has been around, and how much potential and flexibility it offers even for those that aren't JavaScript developers, I am surprised at how many avenues are yet left unexplored. (Note that all of this is my perception only, as someone that only just became active again in the community recently after an absence of some years. Others will likely disagree.) TiddlyWiki 5 goes to significant lengths to allow things to be adaptable and customizable without needing to write JavaScript, however this potential is largely untapped. Consider that the entire user interface of TiddlyWiki is entirely built with widgets and templates, however we have seen so little innovation and experimentation with alternative UIs. I would love to see someone just throwaway the default interface entirely and start from scratch. It can be done without any knowledge of JavaScript. Streams was written as an adaptation of a personal task management solution, to demonstrate workflows and interactions that were previously considered difficult or not possible in TiddlyWiki. Towards this end the very first demo was written entirely without any extra JavaScript. As such, it was meant to be more of a technology demo and reference implementation to inspire other developers, rather than something for people to use, and this contributes to some of the current shortcomings in the workflow. I will endeavour to address them to the extent that I can within both my time constraints, and the scope of a single plugin (and not an edition). Regarding exports: exporting just the content of tiddlers in HTML is entirely possible via a button in TiddlyWiki. I suggest posting a thread in the group asking for assistance on this to get you going. You can then use Pandoc to convert to your format of choice. Note also that my work on the WYSIWYG editor that I mentioned earlier also involves a limited HTML to markdown conversion option in TiddlyWiki, that could potentially be reused to convert wikitext to markdown as long as its just plain text. Hopefully this addresses the more general feedback you provided, and I'll follow up with more specific replies to the Streams related items a little later. Regards, Saq -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/76c7de2a-25bf-458a-87e8-e4d9550e1cfeo%40googlegroups.com.
