Save Current Story River As A Workspace

Strangely I can’t seem to find any earlier questions on this one…

Concept of multiple workspaces, multiple desktops and so on to facilitate workflow on different projects.

Often I have ten or twenty tiddlers open on the storyriver for a particular bit of work, usually along the lines of cross linking and documenting common aspects between these tiddlers so I regard the contents of the storyriver in this scenario as my workspace for task 1.

Of course I often want to flip between task 1 and task 2 ie to be able to flip between two historic storyriver states previously saved with the caveat that I am not proposing here of reverting back to older versions of the tiddlers involved - for example probably simpler if a tiddler that was being edited at the point of saving the storyriver does not re-appear in edit mode when that storylist is re-loaded so looking for the simplest solution here - just relisting the current version of each tiddler that was in the original storylist when that storylist was saved.

I started thinking about special tiddlers created by a plugin that simply hold the list field of the core Storylist tiddler and so can then offer functionality to change the Storyriver to reflect task1 or task2 assuming I have previously saved the storyriver for those two tasks in two tiddlers.

Surely someone has already gone down this road? Does the plugin already exist?

3 Likes

It seems that it is not very difficult to implement the concept of workspace in tw. If each layout is regarded as a workspace, and each layout has its own storylist, it will look more elegant.

I have wanted to do this feature for a long time, but I think storylist is a difficult point and I may need to find some solutions from the source code, so I have been delaying it.

Hi I am interested to know why you think

“storylist is a difficult point”

My simple concept which admittedly focuses only on the storylist is as follows…

A New Side Bar Tab For The Plugin

  1. button to create and name a Storyriver capture-save. Copy Storyriver list into a new tiddler with a similarly named field to store the list of tiddlers, give it a special tag perhaps so it can be recognised easily. The storage tiddler is therefore pretty much identical structurally to the Storyriver tiddler apart from name and tags. It would be nice to be able to name the tiddler - example “My workspace1”.

  2. Display list of tiddlers which are the previous storyriver captures, for instance by listing all tiddler titles with the special tag mentioned in 1.

  3. Buttons along side each tiddler listed for [ delete ] [ populate ] where the latter will change the current storyriver to be the same as the saved list in that tiddler by copying across the relevant list of tiddlers from the field in the storage tiddler.

I anticipate draft tiddlers would need filtering out otherwise it gets more complicated because we are then starting to get involved with the state of the tiddler when the storyriver was saved so basically the way that the tiddler is actually displayed is not history dependent.

Hi @jonnie45 there is plugin that allows you to define permalinks that open a predefined list of tiddlers, but a quick and dirty way of achieving what you want would be to grab the permaview link of the list of tiddlers in your task and saving it somewhere for future access. Use the permaview button available in the dropdown tiddler tool menu:

Every unique view of your workspace can be saved as a unique link as you proceed with your work. To automate the task, one could make a button that captures this link and adds it to your list of views as a unique named link e.g. [[Task 2|permaview-link]].

Hope that helps for now. Ideas for a better approach are welcomed.

Ensemble feature of multicolumn plug in by @BurningTreeC if could be extracted to work with regular tiddlywikis must solve this problem

Also be-rad edition by @Brian_Radspinner has a similar concept I guess

I just tried to write it, and it feels pretty good. I am writing this plug-in, which will support the creation of new workspaces, custom naming, cycle switching, manual selection and other functions. There should be no difficulties.

2 Likes

There is value trying to generalise this further. To simple list handling tools, where the story is just a special case. I have investigated a number of these that can be populated with a button, or drag and drop, or by capturing the current story.

  • Although workspaces may make some sense, in some cases they are just a more specific view of a different list.
  • Projectify allows drop to move items between projects, and Mohamad baskets is another example of ways to handle lists.

List are a key feature of tiddlywiki, when designing something that is based on them try and build more generic tools, if possible, because it will enhance tiddlywiki design rather than make distinct solutions.

  • From which even more solutions and innovation can take place.

Interesting - so perhaps eventually core functionality?

If the concept is around capturing lists from different sources and then being able to remove or add to those lists (drag drop) what is the container for the lists - presumably a tiddler with a given name and one or more list fields?

For instance core functionality to create a new tiddler with given name and populate it’s list field from the current story river being one option offered by such functionality?

Just trying to flesh out what you are thinking about?

Before I head off to bed, the story list itself is just a list field in $:/StoryList, but tags are also lists, and if you reorder them they store that list/order in the tabs tiddler list field. Of course one of the key widgets is the list widget and this often used through out the core, such as viewTemplate tags to display your tiddler components, the page components and the toolbars, and cascades.

  • This is why I think we could easily make some primitive tools to see, capture and set lists that can also be used as a Work Space.
  • Since I set different object-types on tiddlers, Such as project, todo, reference, page I could also have smart lists, perhaps establishing a current project, or the list of projects I have open, had opened etc…

Oh and lists are directly related to sets, groups and other conceptual systems including trees (like the contents), or system tiddlers and the tree macro.

I did create a “stories-plugin”, that implements a new TW message tm-open-story, but I got a bit “over board” with the configuration UI. So some refinement would be required.

-mario

Is that publicly available somewhere?

ATM it overwrites the right sidebar Open-tab with 3 year old code. That needs to be changed.

IMO there should be a new Stories tab, that transcludes the Open-tab and adds a “save story” button to the footer.

The existing Open tab also contains “ancient” code so it is not very flexible to be extended atm.

2 posts were split to a new topic: [Idea] Bundler Plugin - should work with stories

Not sure if this is exactly what you’re looking for or not, but the Views plugin by Ben Webber does what I need. It will save story rivers as views that you can access via the sidebar.

I actually modified his Views sidebar tab to add a couple of buttons to delete the view or update the view (screenshot below).

image

1 Like

Yes, @benwebber view plugin uses a field to store a filter, which can always just be a list of titles as well. He also links to a permaview version of evidentlycubed.

My reimagine tags tool allow you to open all and close all tiddlers with the tag. In this case you can open multiple sets of tiddlers on top of each other, and close only those which are member of a set leaving the rest open.

  • This makes me think if tagging sets is the most functional, at least for tiddlers
    • if not system or shadow tiddlers, because tagging edits the tiddler.
  • Eg tag current story tiddlers with a workspace name?
  • The other alternative is something like @Mohammad basket tool, where the list is only saved in a field.
  • I have also being working on dragging and dropping titles on tiddlers to tag them, or drop on a tag pill to add the tag…

I do see a lot of opportunity here to satisfy @jonnie45’s “Save Current Story River As A Workspace” and turbocharge TiddlyWiki list and tag handling.

I have to say though - in the interests of simplicity I do rather like my original idea, that the tiddlers that store the list of tiddlers are pretty much copies of the storyriver tiddler that are used to restore the field of the story river to a former state by copying across the field contents of the storage tiddler.

I wary that a drive to generalise ends up creating something bigger and more complicated and less hackable by someone with medium level skills.

I think I am capable of writing this plugin myself but since oeyoews is already on the case then I am happy to stand back and wait for his version and perhaps tinker with it if required.

I favour simplicity and adaptability - I don’t use the standard Tiddlywiki tools like the tags manager that much preferring my own custom tabs with tools I have written or customised to work the way I want them to. I prefer to see low level functionality provided which eases the task for anyone who does not like the standard model for a particular workflow as imposed by a a particular UI to build their own that fits in with their workflow.

Its a difficult call - generality vs something that is designed to do the job but I do think there is an inherent and pleasing simplicity in a design that involves managing tiddlers that are effectively really just copies of the story river at different points in the history - they can be exclusively tagged, deleted, copied and modified - the transparent simplicity of the data model I feel suggests a final implementation that will be simple and easily customised according to taste.

1, Create tagged ‘copy’ of the Story river.
2. Side bar tab or similar to list tiddlers identified as copies mentioned in 1.
3. Row of buttons to the side of each tiddler in the sidebar list to perform operations including “restore story river to this”.

The model I suggested is I feel a very simple and potentially robust model - it simply “clones” and manages copies of the storyriver tiddler, conceptually simple and very hackable.

Maybe I am mis-judging alternative solutions, maybe I don’t have enough Tiddlywiki core vision to really say but my instinct here is that a simple “pure” design is perhaps in danger of getting complicated.

I use a similar approach myself and it works well. I think of them as user sessions. I have just never had reason to package it as a plugin, particularly since I use a completely custom UI that would not be very useful to others, but the approach is sound!

sure

That is the end game, I would not bother myself if it did not get easier and simpler

It would not matter if you were, go with your own vision, I too want simple answers, but they are my vision, let’s see yours.

I am looking forward to it.

Oeyoews seems to say he is going to have a go at writing this plugin so I am going to hold off writing one myself to see first how that pans out, but if that does not work for me then I will probably write what I need myself.

In order to facilitate later expansion, I am considering the storage structure of this data, instead of simply storing it on a certain tiddler. I plan to store multiple workspaces in the format of objects, and eventually provide the UI in the form of widgets. I may continue tomorrow. It does take time to try debugging, and it may not be completed quickly.