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

Developers
,
#21

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

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.

#23

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.

#24

@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?
#25

@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.

#26

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.