Getting Stuff Done -- Basic Elements -- implemented using TiddlyWiki

Developers
,
#1

Long post warning:

TLDR;
The minimal viable product needs to start small with a simple ToDo app, because most users don’t need a full blown GTD app right from the start. … But there has to be “no friction” in the underlaying data-structure, if it needs to grow.

hmmm, I think that estimation is not right. Neither in complexity nor in the amount of time needed to make it a “product” that users would want to pay for.

IMO the UX has to be the “killer feature” …

At David Allen gives away his design for the Ultimate GTD App (GTD Summit 2019) - YouTube David Allen pointed out, that there where 2 serious attempts to implement the “perfect GTD” app … Both “failed”. …

The past attempts probably failed, because “cramming” everything into 1 “hardcoded” app did blow up the complexity to infinity. … (I’m exaggerating here :wink:

IMO the key point to success is the underlaying “data structure” that connects all the different elements together. As shown in this thread it seems everyone is using at least 3 different apps to get stuff done, because no single app will do the job.

Also user needs are different. eg:

If you are new to Getting Stuff Done workflows you’ll probably start with a simple ToDo app, so Projectify is a professional looking starter … but

After some time that’s not good enough anymore … So you may want more, but it should be possible to carry the “existing” data with you, because a lot of value was already created.

May be there should be a Contacts addOn so you can speed up contacting people.

But …

if you collect data to prepare a PhD theses and want to define some “due dates” a Callendar addOn in combination with a BibTex addOn may be more important

… and so on. …

IMO the GTD concept is flexible enough to handle both usecases,

IMO TW tiddlers are flexible enough to handle both usecases

but none of the existing TW plugins are able to handle that out of the box, because most of the community pluigns are not compatible enough. Neither in UI, nor in the underlaying data structure.

As I did read in this thread the existing TW implementations are also “not good enough”, mainly because the have been written by devs, that did develop them for their own preferred usecases and not to build the “perfect GTD elements”.

@ludwa6 linked a workflow image at: Any new GTD plug ins available other than GSD5, Cardo and Projectify - #43 by ludwa6 which looks “simple” on the first view.

image
image942×197 53.8 KB

Top left it contains 1 elements from “Collect” to “Do” and it shows point 2 & 3 in more detail. The funny thing here is, that every single element from 1 to 5 is a complete app for itself.

eg: Collect. … tasks for “a project” which is the orange bubble in the details workflow

  • Some users may want to use an “outliner” to collect input for the “inbox”
  • I personally would like to use a mind-map (In the video David Allen also mentioned a MM, which can be a complete app on itself)

eg: Process - Organize details

  • Shows a workflow using some terms form GTD … but
  • I can tell you an implementation of the Eisenhower principle can do that too.

It will be possible to create both workflows in TiddlyWiki … but

I think the underlaying data-structure has to be identified first. The “killer UX” I did mention above has to stand on a solid base concept that has the “big picture” in mind. … where

The minimal viable product needs to start small with a simple ToDo app as 1 component, because most users don’t need a full blown GTD app right from the start. … But there has to be “no friction” if you need to grow.

Just some thoughts.

PS: I’ll probably move this post and comments into its own thread…

2 Likes
Any new GTD plug ins available other than GSD5, Cardo and Projectify
RFI: the "MyGSD Wiki" theme
RFI: the "MyGSD Wiki" theme
Any new GTD plug ins available other than GSD5, Cardo and Projectify
#2

Insightful post, @pmario . Easy as it may be to conceive of yet another “simple ToDo” app- what you propose as “killer UX” -the devil will be in the details of that underlying data structure to support all core GTD workflows, along with others that people value in these other GTD-inspired derivatives.

Great. I’m pretty busy ATM, but i look forward to engaging in a focused conversation on this topic, as it develops.

#3

Reading the GTD book in more detail, ToDo or “yet another todo app” probably is the wrong name for an MVP (minimal viable product) as discussed here.

IMO it needs to be Next-Action, which may be the name of the first edition that should present something usable, which should be able to scale.

That needs to be considered in a second step. Some info may be possible to be reused … but that should not limit the new development. TW can convert meta-data while importing content form other wikis.

#4

The idea of an agreed upon data format completely separate from the UI is interesting I think. This could allow users to export all their tiddlers out of one TiddlyWiki-based GTD implementation and import them into another and have all the projects/actions/contexts etc show up and work in the new system.

1 Like
#5

The high quality docs at GSD5 — a getting-stuff-done tool make me think gsd5 could be a good starting point.

2 Likes
#6

Interesting idea indeed- moreover, i’d call it necessary for this product to have “legs” to go far & wide in the world -but i wonder what it requires, i.e. what you mean by “data format.” I presume you mean something deeper than Markdown (more of a presentation format, i guess), but rather something related to semantics?

Tho i am no programmer, i gather that the most powerful construct in any programming language is that controlled vocabulary of verbs which enables the language to DO stuff -yes?

If so, then it seems to me that the most fundamental Next Action required in this systems analysis would be to define the set of verbs to be established as canonical for all anticipated versions (even if we won’t really be using them all in v1 -a proposition i must confess some doubts about [1]).

To that end, i note that there are different versions of the fundamental 5-verb set in the GTD canon floating about. The one in the flowchart image above (Collect, Process, Organize, Plan, Do) was modified in v2 of David Allen’s book, such that the set of {Capture,Clarify,Organize,Reflect,Engage} might be considered canonical. Yes?

Once this set is ratified, there will be other verb-sets associated w/ each of the 5 terms to be defined-e.g. the famous 4 {Do,Delegate,Defer,Delete}, 4 different ways to actually Engage with the object -but that is a deeper level of analysis, which the developer(s) may wish to Defer (or not; must confess, i’m not quite clear about this).

[1] About the MVP proposition as discussed thus far in this thread, i don’t know if it will actually work in practice. In my own experience, if you don’t run the objects in your system all the way through to appropriate mode of engagement (e.g. an action that is for me -important, but not urgent- i should Plan, that is to say migrate it to a Calendar entity), then you quickly wind up with a mess of stuff not fully processed, either in some unconnected system or (what’s worse!) in your head. I recognise the risk of scope-setting too ambitiously at outset, and the importance of a tight MVP focus… But to me, that means TSTTCPW (The Simplest Thing That Could Possibly Work), and i think we should probably those necessary but non-integrated elements of the system (e.g. a Calendar?) that must still be part of our outboard brain from the get-go, even if the transport of data has to be via some sub-optimal process until it gets better integrated. Does this make sense?

#7

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.

#8

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.

#9

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 :smiley:

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!

#10

@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
#11

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.

#12

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

#13

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.

#14

No AI, just a smart/expert system, based on (single language) dictionaries.

#15

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

#16

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.

#17

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.

#18

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.

#19

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.

#20

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.