I wish I could share the TWs we generate for our cardiovascular Data Mart product here. We generate the data dictionary/manual in a TW and all our test outputs are in a few TWs organized by test groupings. It definitely satisfies 2 and 3, as far as 1, I am still tweaking it to be more and more attractive and useful all the time. We started off very simply because we didn't want to commit too deeply down a path which would limit us from retargeting our documentation to HTML or Word later. However, as we progressed, it was more and more accepted to start using TW features more heavily as stakeholders started to get the hang of it, and there are some fundamental aspects of TW which we have taken advantage of to solve traditional problems in code/document generation:
Transclusion means that we can have parts of the TW that are manually edited and parts that are generated and that work can go along independently with each feeding off the other, without requiring significant synchronization between engineering staff and informatics staff - changes to the code/rules can be done independent of editing the TW template file independent of the data that is going to be imported from JSON to fill out many lookup tables and generate necessary tiddlers and indexes. Normally with code/document generation, you have to decide whether the template or the content is driving the design and what we've found with TW is both are on pretty equal footing compared to past techniques like in Excel or Word where areas have to be labeled and then only designated labeled areas can be filled in and there really isn't referencing back and forth. And you have to decide where longer narratives are stored and how they get combined in the document. And you have to decide how to handle multiple passes so that you can embed generated content in user content inside the generated content. That is simple for us, they are always in a tiddler, potentially itself transcluding generated data, and it's all seamlessly handled by transclusion. Macros/filters mean that the document in many cases is data driven on its own using TW features. Typically in a Word or HTML document generation, you would have to generate the index, often our indexes are not even generated - they are tiddler list macros on tiddlers with dedicated transclusion points for including manual edited tiddlers in appropriate places. Sure Word can generate a table of contents based on the heading structure in your document. That is nothing compared to what TW does for us because of how we tag everything in custom fields and then can have all kinds of options for organizing and displaying indexes of the same data. Tiddler grain - do everything at a small meaningful grain and tag/label data fully in custom fields. A lot of this could be done with an HTML site generator, but TW has really saved a lot of work for us by us buying into the TW philosophy of fine-grained tiddlers. So we use custom fields and tags and filters and generate tiddlers appropriately tagged for every element of our Data Mart and then they merge seamlessly with manually created tiddlers and index tiddlers which know how to group up different tags. I know there are other tools we could have looked at, but based on what we did with TW, I am not confident that we would have achieved what we did, or as well, or as flexibly accommodating the ongoing releases of our Data Mart as we curate more and more data, with any other product or technique. Thanks, Cade On Tuesday, October 19, 2021 at 5:13:36 PM UTC-5 cj.v...@gmail.com wrote: > I'm not clear on what exactly the problem is. > > What problem are we trying to solve, how will making TW appear alive solve > it? Alive to who? And alive how? > > Yeah, I think I'm either over-analyzing things or things are too > broad/unclear for me to contribute anything useful. > > I do look forward to seeing how this discussion thread evolves. > > > > > > On Tuesday, October 19, 2021 at 5:33:46 PM UTC-3 Mat wrote: > >> What does "nicely designed" mean? I may find something wonderfully >>> designed, while 99% of normal folk find the same thing awful. >>> >> >> So I'm talking about appealing to the 99%. If we look at, say, the >> "clothes design industry" we should realize how incredibly narrow our >> tastes are if we consider that clothes really could be designed in >> unlimited number of ways. Most of us have similar preferences about most >> things. (Of course, you and I have our own distinguished tastes and free >> minds... and that very belief is another thing we have in common with >> almost all other people.) >> >> [...], and who cares whether it looks abandoned or not? >>> >> >> Before people become full tiddlywikians, then need to decide if they want >> to try out TW to begin with. At that stage, impressions and feelings matter >> a lot. Things that look abandoned or outdated are generally less appealing >> than things that look up to date and alive. I'm pretty sure people are more >> interested in a software where it says "October 19, 2021" instead of , say, >> "May 7, 2018". >> >> [...] the best thing is to continously/regularly update it. >>> >> >> Of course, but that means responsibility and effort... >> >> >>> An alternative/complimentary approach might involve having the wiki >>> acting a bit like a portal, showing some dynamic content from somewhere >>> else so it looks like the TiddlyWiki has a pulse ? >>> >> >> Yes, that is a good idea. Any good examples of how this can be done? >> >> <:-) >> > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/2f4e8de9-d1c5-4c7d-a715-fded29130acfn%40googlegroups.com.