Yes! Mea Culpa: i never saw those docs until yesterday, and now i am so impressed by them, and by the GSD5 product itself (which i can now use, thanks to the docs), i aim to give that product a proper trial before i do anything else.
Actually the opposite. Rather than verbs, we need to standardize on the nouns. It IT terms it’s a schema.
For example, if we agree that an “action” is a tiddler with the field “gsd-type” = “action” and its status recorded in a field called “gsd-status” with values “next”, “done”, “waiting” or whatever, and so on for all the other “things” required in a GTD system, and if that’s documented clearly and we all agree upon it then your personal GTD data becomes portable between different implementations. Conversely, if every TiddlyWiki GTD implementation invents their own similar but different schema, migrating your data from one to another becomes very difficult.
Oops: i inserted my User-Driven comment into a thread that was about data portability, which is of course a development issue (in this context [1]), so if it struck you as non-sequitur, the error is mine, clearly. Thanks for the timely whistle 
I will add that, as the GTD user rep in this conversation, this data migration feature (which i also value highly) will from UX perspective be triggered by a verb that is one of those 5 “GTD primitive verbs,” shall we say, or one of its child predicates.
OK so: in terms of development methodology, is it a data-driven approach, or process-driven, or is that a false dichotomy? Does it make sense to model the schema in an ERD or Class Diagram or some such?
[1] I know its a different world now from back in the day when i managed Oracle-powered business systems development, but still: though logical modelling prioritised development of RDBMS schema, it was all the more important that such development was preceded by business process modelling that was very much user-interaction driven. Maybe this is more of an agile prototyping process where you just dive in and Get 'er Done, but still: i can’t help but feel that all those fundamental GTD interactions, at all points around the GTD process flow chart, should be modelled somehow first, to some reasonable level of detail, before any code gets cut … But if that’s not the way it works here, i’ll just shut up and enjoy the sound of devs hammering away. In any case: thanks Mario & Simon for your patience w/ me thus far!
@ludwa6
I think the creator of GSD5 plug-in (Roma Hicks) might be the best person who can help you. Since he has worked on GSD5 project recently, he must be using it atleast semi regularly (I read somewhere in his project repo). The last update to the plug in was 8 months back, when he updated GSD5 to the TW 5.2.2 I guess. There has been no more updates in the GitLab repo after that. I created a few issues in the project repo, but he hasn’t repsoned till now. If someone here in the TW community has some contact with him, may be they can contact him and ask for his help if time permits.
1 Like
All, Whilst I know you are focusing here on the GTD methodologies I have for a long time focused on my own bespoke methodology built in tiddlywiki based on whatever methodology, analogy or metaphor I stumble upon and like the look of. My current working solution is effective but I am always looking to innovate further.
- I will not contribute to this thread directly but raise a method arising
An idea which I believe may be novel and innovative is to permit items to be recorded within tiddlers or the title of a tiddler then parse them (on addition or update) for natural language verbs used (English in my case). Add to this the ability to suffix an Item with “?” Question, “!” an assertion and a few other appropriate standard punctuation. Each item could be identified as a result of its own content and appropriate lists, workflows and status management used to “surface and manage all items”. For example;
- Call Tony
- Call Fred ?
- Do tax return
- Check bank balance
- Record bank code 344523
This the wiki will just identify which workflow to use given the words found in the item.
I thought of also parsing for Nouns (Things) and Proper-nouns (People) but realised it may be just as easy to provide a facility to rule items in and out and would in fact allow a search tool to suggest existing things/and people to stop multiple names for the one thing.
- using the various tiddlywiki relationship tools including references, backlinks, missing we would quickly find it possible to look at our data from any perspective.
- In fact our system can discover this information as soon as you create the item and simply ask appropriate necessary and optional questions. eg “Order dinner” gives “From where?” “Do you want fries with that”. This quickly adds more information to the system at that very first moment, when you were adding something and its front of mind.
Finally status is a critical part of workflows and whist we can provision a layer of management over any item we want to manage its workflow, arguably anything eg; now, urgent, on this date, by that date etc… Interestingly I think we chould make use of feely available information already in the wiki, or new somewhat automatic methods to automatically determine the status such as new, old, untouched, unmodified for a while, future dated, or prioritised by related noun / proper noun.
- With this approach we ensure items bubble to the top, fall to the bottom or slip sideways as desired, with little or no intervention.
If there is sufficient interest I will start a relevant thread.
The result would be a superset of all GTD methods.
Dev-talk low level warning! None of the things discussed below need to be seen by the user.
I was thinking to add a bit more abstraction but keep it understandable. While the tiddler itself is probably the best base we can build on, because it only needs a “unique title”, to be a valid object.
I want to make it easier to understand for the rest of the world.
So I was thinking more in the direction, that @linonetwo pointed out about Ontologies here at Talk. Without the discussion of creating our own Ontologies, which we can’t maintain anyway.
Having a closer look at some relevant definitions, it turns out, that I didn’t think about certain elements, that will be important in the future. So there is some value to use knowledge that has been developed for years and seems to be stable since years
That will need AI functionality that converts the text into an “actionable intention”. That “intention” needs to be sent back to the device, which has to know what to do.
That’s a nice idea but way out of the scope of tiddlywiki at the moment. Because I want to say: “Toni anrufen” which is “call Tony” and it still has to work.
No AI, just a smart/expert system, based on (single language) dictionaries.
That’s right. I want to stay within the bound of the 427 pages of text (not counting the index) of the 2015 Edition. So the book can be used as a training manual.
I think there is enough knowledge to be digested. …
There have been some discussions here at Talk, that the existing editions use some different “terms” as used in the book. … And that’s true. … I’ll try to avoid that.
So TW related terminology may be used for the development, but not for the UI
I don’t have the time to create yet an other parser. I’m not finished with my custom-markup plugin yet. There is a reason, why I Would Like to Fix the redundant P-tag Problem
The existing parser issues need to be fixed first. I didn’t find a proper way to work around it and keep the code maintainable.
I don’t expect you to. I can handle it in wikitext, macros and widgets. However it will be incremental. I am interested in the concepts for now, not the code. Although I am confident I have the code patterns, and see no reason they are not maintainable.
The ontology idea is interesting. My quick take after looking briefly at Task Model Ontology (TMO) …
The idea is in line with what I’m thinking about for a GTD/TiddlyWiki data schema, however:
- it doesn’t have the core GTD concepts, so we’d have to immediately extend it to add things like project, context, inbox item, etc.
- Also it’s maybe a bit heavyweight. It’s like an industrial strength enterprise model, but we want something light and focussed.
So imagine something like the tmo ontology but smaller, and TiddlyWiki oriented, so it talks about tiddler field names and values, and covers exactly what is needed for GTD implementations in TiddlyWiki and not much else. The first draft of such a thing is likely to be based on the existing definitions in GSD5. That’s what I’m thinking of.
How serious do you take the “universal inbox” concept, and how do you implement it in TW ? My feeling is that the rest off GTD is pretty straight-forward, but the physical limits of TW are a challenge. Unless you use a node based solution, with a file uploader, you really hit a barrier somewhere between 10 - 30 Mb . Your “inbox” could be linked references to external resources, but then you have to depend on the stability of those resources.
I’m not thinking about an XML implementation. I want to use tiddler fields. It’s only the names and the behaviour that can be defined by those field names. I think that’s already a big win.
@simon , I concord with your thoughts.
I was thinking of the possibility of being able to change the “workflow” of GSD5 to to adapt to each requirement. As I am using GSD5 currently, I realized the first “want/wish” for me is to be able to change the tiddlers format (from templates) to any direction in the workflow by adding/subtracting “contexts” . E.g., An input tiddler (collect, capture, other context of my preference) could be changed –on-the-spot– to an action (do now, engage, clarify, assigned to others, do in the future), project (process, organize, plan, review), tickler (do by due-date, future review), reference (to a project, to an action), archive or temporary trash bin; back-and-forth completely interchangeable.
Each type of tiddler template may contain different tags and/or fields for the contexts, to be used in filtered lists to create different UI’s according the each user requirement. Any user could add/delete contexts to control the workflow and the UI as them wish.
1 Like
If we look at GTD as “algorithms + semantics (meaningful words)” and look to modelling this in TiddlyWiki we can draw from a range of existing Editions, Plugins, macros and methods.
It seems to me that continued development of any solution can be considered as made up of various conceptual parts. The development or redevelopment of any solution, is the opportunity to identify and develop “algorithmic parts” and generalise them for reuse.
Theoretically the GTD methodology is only one of many possible solution/collections of “algorithmic parts” with specific naming standards.
- I am most interested in the analysis and synthesis of “algorithmic parts” from which we can build solutions, building the platform and the components are more important, even than the resulting solutions, because solutions are just one of multiple applications of the “parts”.
With sufficient “algorithmic parts” we should be able to construct solutions quickly, solutions that leverage
- what ever semantics we choose
- and from a wide and deep library of resources.
As such I would suggest in developing a GTD Project the designer(s) ensure the “algorithmic parts” can be accessed.
Thanks for your comments @TW_Tones.
You are a subject matter expert interested in algorithms + semantics to build solutions quickly, efficiently, and may be replicated to construct several applications with the same pieces of software. This is the goal of many software developers.
I am an engineer that look for applications or solutions that are easy to understand and that do not work as a black boxes. Perhaps this is why I like Mohammad’s very well explained solutions and; being an engineer himself, probably understand the communication needs from users-that-do-not-code.
I believe that one of the main reasons many applications/solutions are not adopted fully or left behind is because codes and end-users don’t understand each other.
The possibility of change the “workflow”, as mentioned in my previous post, was done already in TWC’s mGSD. It’s nothing new. Over 12 years using it, with very limited understanding of TWC, I was able to create the workflow and UI I liked. I believe this could be done in TW5 without spending too much time in modelling.
@Alfonso thanks for your reply, but it implies something about me that I don’t agree with, let me clarify.
- Actually this is my objective, to build solutions which are effective and;
- Actually black boxes are better than see through ones for end users. Black boxes just do what is on the label.
Sure you need not know the details of what I raised above, but the reason I try to analyse the needs is for building solutions for people like you (as described by yourself).
Again a model that is easy to understand can be made use of by anyone from user to designer. For example you are using the “TWC’s mGSD”, other examples are Cardio or Projectify (project model). The image in the top post is a model.
- What if you need to alter it slightly?
- What if you need to include a new model, like the tools to develop a book?
@TW_Tones, as you wrote in your first line, we will have to agree to disagree. Which does not surprise me as we come from different backgrounds. However, disagreeing is fine as many wonderful ideas in the world wouldn’t have appear without certain differences in opinion.
IMO, black boxes are not better for end users. I am not talking about the end user requiring to understand the code, but the logic, workflow, assumptions, and the math (if required) behind the application/solution. Many years ago, when we studied calculus, we were required to solve problems in a workflow or step-by-step scenario, not just produce a numeric result. I did some Fortran 4 programming to design equipment and some dBase programming for predictive maintenance in MS-DOS. These solutions wouldn’t have been used if the logic, etc. were not clearly presented and communicated.
Black boxes may do what is on the label; but the label could not necessarily represent what the end user need or want. When the workflow is well known, of common use, and standardized, a black box off-the-shelve application would suffice (e.g. Microsoft To Do or Things 3). In the case of a solution like GTD, the workflow is different at any point in time for each input, because there are several decisions that may change the direction of the workflow, and also several possible outputs for each input.
Lastly, a model (or workflow) for GTD exists already. What is required is a solution to the model. GTD5, Cardo, and Projectify do not solve the GTD model in its current status. TW5 is perfectly capable of solving the GTD model with all the decision, processes, inputs and outputs required. A solution should have plugins, lists, contexts, templates, inputs and outputs very well commented (in the code, using lots of <!-- -->), clearly communicated (tutorials), easy to be customized (with a library of potential lists and filters to create different outputs), and a simple utilitarian interface.
I doubt we need to agree to disagree because I dont think we disagree, perhaps we just have different views on terms and emphasis.
Never the less thanks for sharing your views.