Suggestion: Somehow express dependencies visually in the Task Tree

[Gary]

Suggestion: somehow express dependencies visually in the Task Tree. The goal would be to have a clear visual clue that one task has to be performed before another. For the moment I just create a dependent task as a child subtask and mark it with a different color. Previously, in a rich text editor, I used to double-indent a prerequisite task "above" its dependent task:

- [black] perform A

- [yellow] perform a prerequisite for B

- [black] perform B

- [black] perform a subtask of B

- [black] perform another subtask of B

- ...

Perhaps some kind of an arrow pointing from the icon for "perform B" back to the icon for "prerequisite for B", even if both tasks aren't siblings? Not sure there.

[.dan.g.]

Hi Gary

Have you looked at the Gantt View?

[Brendan T]

Hi Gary,

As Dan mentioned, linking in Gantt view is one option.  How do you use the dependencies?

Going out on another tangent.  Would simple ordering of the tasks be sufficient?  If you wanted a focused view only of the next actionable task on which other tasks are predicated, perhaps the ordering could be coupled with the ideas discussed over at this other thread.

https://groups.google.com/forum/#!category-topic/abstractspoon-todolist-support/usage-questions/ZtS4kbSgW4Q

Brendan

[.dan.g.]

Hi Brendan

>> Gantt view is one option

It is also the industry standard for representing dependency relationships. I'd rather no re-invent things that already work...

>> Would simple ordering of the tasks be sufficient?

Maybe. Sorting by dependency is already supported if the dependency column is visible.

[Gary]

The way I look at it, Gantt is intended for people who are primarily (or, at least: substantially) interested in dependencies within their data and work with relatively few, but "macro-" (important) dependencies. For me, dependencies are a secondary concern and tasks are the primary concern, so I work inside the Task Tree, inserting dozens of tasks, subtasks, constantly changing icons, colors, adding comments, etc.

My point: it is quite "troublesome" for me to have to keep switching to Gantt back-and-forth just to review those numerous "micro-" dependencies. Any kind of visual clue right in the Task Tree, say, across sibling tasks (?), would be more useful to me than a separate Gantt chart. But I do understand that you do not want to duplicate functionality across views.

[.dan.g.]

>> Any kind of visual clue right in the Task Tree, say, across sibling tasks (?

Is your primary interest only in the 'next' task, or are you wanting to colour more than just the next?

[Gary]

>> Any kind of visual clue right in the Task Tree, say, across sibling tasks (?

Is your primary interest only in the 'next' task, or are you wanting to colour more than just the next?

All in all, I'm not that sure that using coloring and sibling subtasks is the way to go when working with numerous "micro-" dependencies.

I used to use a rich text editor for all my notes and when working with such a "flat" structure, I had to use different indentation and different coloring to express dependencies visually:

- improve CPU cooling

          - replace the case

          - replace the motherboard with full ATX

     - install a 1 kg heatsink

     - install more high-speed case fans

...

- start zcash -ing the heck out of the CPU [this month]

The main point here is to be able to have one look at a particular portion of a Task Tree and immediately see what needs to be done first and in what order. (In a sense, a list of necessary prerequisites becomes an indented "sub-list".)

However, the coloring/indentation approach does not work if: 1.) a prerequisite task is located in a completely different subtree from a dependent task (as well as possibly at a different level) or, 2.) more than one dependent task needs the same prerequisite task.

That's why I thought of some kind of an arrow (?) from a dependent task back to a prerequisite task (?). But it's just a loose thought about a possible solution to the problem - not a suggestion.

[Tony G]

Just chiming in, I've been experimenting with approaches to this as well.
I'm currently using priority to focus on where I should go next, with 10 being the project and decreasing the priority as a clear and colored visual cue to indicate the order of operations.
Sub-tasks help. Ordering of child tasks within the parent helps.

I also have custom attributes to tell me how some tasks are related, with a FromTask and ToTask linking in both directions. That helps to bind them outside of the physical organization. I have UDTs to move forward and back. In the following screenshot we see consecutive tasks in the tree structure, but it's clear that they are not to be processed in the linear order - task 21 forward-links to task 37 as a "do this first". Task 37 backward-links to 21 to say "this needs to be done for 21".

Another way I use these is when I'm tracking tasks for a client by month, and the same task continues into the next month. I have a custom field that essentially says "further effort continues in this other task" and the backward link says "this was continued from a prior task".


As usual the tool doesn't come with a prescription for how it's to be used, it's just versatile enough to provide us with various creative ways of using it.

HTH
T

[Gary]

 

In the following screenshot we see consecutive tasks in the tree structure, but it's clear that they are not to be processed in the linear order - task 21 forward-links to task 37 as a "do this first". Task 37 backward-links to 21 to say "this needs to be done for 21".

Interesting: you are, in a sense, creating "pointers" from dependent tasks back to prerequisite tasks, right in the Task Tree, as opposed to using the Gantt View, only your "pointers" are numeric "characters" as opposed to graphical "arrows". However, that probably wouldn't work for me too well, since I have to work with multiple different Task Trees with dozens and dozens of nodes. I have too many nodes to scan visually for all the possible "pointers". Even if "pointers" were graphical in nature, I would still prefer them to be placed right in the leftmost tree structure (pointing across task titles), not in the rightmost property columns (pointing to task shapes - their respective "rows").

I think a possible solution to this problem would have to involve graphical arrows in the tree structure itself, and/or automatic coloring of node titles based not only on task priority, but also on task dependencies. This way one could just look at a long list of tasks and immediately see what needs to be accomplished first (due to priority coloring) and what the necessary prerequisites are (due to dependencies coloring).

[Tony G]

Your requirements seem quite site-specific. If you have any development resources there who work with C++ or C#, perhaps you'd consider having them write a plugin to create the visualization you're describing? If you don't have internal resources (or friends/family who code) I will encourage you to participate in the FOSS model by helping to support development of features your company values. Part of my business is to provide ad-hoc development services in C# and I would welcome an opportunity to create a solution for you which we can then publish as FOSS for others to use. Perhaps you could offer Dan the same opportunity. We all use a lot of freeware and developers easily get burned out if there is no motivation other than joy to support it. Businesses spend a lot of money on commercial software and they also appreciate the benefits of FOSS. It's appropriate for users, IT Management, and business owners to recognize the equity in helping to support the model by supporting the offerings that they value.

For free options within the limits of the existing application ...

I only use Gantt when I have a schedule, but in most cases my projects are just priorities and related tasks. I'd rather not use the built-in fields for something other than their actual purpose. The same prioritization can be accomplished if we could use Custom Attributes with date fields, and an alternate Gantt view based on Those fields.

It occurs to me that an alternative to this pointer mechanism is to use numbers for steps, like a BOM system. For example, the morning schedule:
100 Get up
200 Shower
300 Shave
Oops, don't forget the teeth!
100 Get up
150 Brush teeth
200 Shower
300 Shave
Well, I prefer to shave before showering:
100 Get up
150 Brush teeth
180 Shave
200 Shower
400 Get dressed ...

So that's yet another text-based sorting mechanism, essentially a different priority system. Just use the normal column Sort feature to see tasks in order, and maybe filter out tasks that don't have a sequence number. Have a Lot of tasks? Use sequence numbers in the range of 1000000 to 9000000 rather than 100 to 1000.

As far as left-side, right-side, just drag the column to wherever you want to see it. :)

But to visualize that in a way that pops out at you, you'll need someone who can write some kind of code, any language, doesn't matter. Create a UDT that gets the sequences and assigns a color or icon to tasks. It should be easy to translate the increasing sequence number across a gradient from red to green (lower numbers get done first and are therefore red=hot). You can also save your current position in the sequence, so with the example above, if I'm shaving, the next hot task (pun intended I guess) is to shower, not to get up. All that is within the UI itself.

Now consider that we can also export and transform tasks, and then manipulate the data with XSLT. XSL can convert the XML data to HTML and of course with HTML we can do all sorts of visualizations. You can simply load the data into a JSON definition and let JavaScript do some amazing (and dynamic) task re-ordering and rendering. I think a combination of the above and this will accomplish your goals (all free and with local resources if you have them).

As an alternative to HTML/JavaScript you could transform the data into pure data, CSV, JSON, or XML, and then open that with another graphical reporting tool that renders the data exactly as you wish. This is what happens when we use the Export feature - and with the plugin mechanism described above you can create your own export target.

Whenever I save my tasklist (automatic every 2 minutes) it does a transform, exporting the data into HTML with a nice structure, coloring, etc, and that then gets published to my website. With this my clients can see to-the-minute what I'm working on and how much time has been spent. Picture that same mechanism being used where you just need to click a toolbar icon to display that web page.

That scenario gives you Exactly what you want with no changes to this software whatsoever.

If you want a built-in site-specific solution, you may never get it. If you then do not make use of development resources, you will certainly never get it. But if you can motivate people to do what you want, you Can get the business functionality you want, though probably not as it's been envisoned. At this point it's not a matter of possibilities, but choice and priorities.

HTH
T

[Gary]

Well, if a development project decides to go the FOSS route, as opposed to closed-source commercial, it is unavoidable that programming-related work remains free and only support/services -related work can be charged for. That's how it's supposed to work. Sponsored features might make sense for a large, business-oriented FOSS project such as Apache, used commercially by, say, a web hosting provider, but that kind of a business model does not make sense in case of a single-user app like ToDoList. It is possible for a large business to pay for months of custom development, but it is rather impractical for a (single) end-user of a Windows application to try to afford a few days' worth of work of a professional developer (or even weeks, which an advanced UI feature might require). Perhaps a secondary, commercial (closed-source) pay-for edition would be the way to go? However, in case of commercial software, entirely different levels of software quality, support, documentation and marketing are required. It seems there is no free lunch, after all.

The feature of "dependencies" ("prerequisites") visualization I had in mind was based on two goals: (1.) real-time visualization of data (thus without the need for any kind of export and/or transform, in order to be able to quickly assess multiple "subtrees" in multiple lists), and (2.) inline visualization of data (thus without the need to jump across entirely different views, across different left/right sub-tables, or mentally calculate ordinals or indexes).

[Tony G]

[ Note that this is just a simple exchange of ideas and in no way reflects Dan's views or policies or whatever he decides to do with your request or his software. ]

I like what you're talking about. You're describing new views on TDL data, which is the reason the plugin model exists. The only question is how and when can that functionality be created.

Summary: "Free and Open Source" does Not imply "free beer"=no cost. One reason (of many) that software is open sourced is so that consumers can add more features to it if they wish. However that happens is up to them. Or as a colleague of mine says:
"Linux is only free if your time is worthless"

There is wide range between the scale of Apache-sized projects and single end-users at home or with a small business. All I'm saying is that businesses that earn a profit from things they get for free should recognize the benefit of in some way supporting the providers of those things so that they can continue to receive the benefits and profits. It's quid pro quo, simbiotic survival. The FOSS world has more dead than live projects from burned out developers who lost motivation - look at any repo to verify that. It seems people think the FOSS model is to burn out one project/developer and move on to another - that's what we all do, no? I'd suggest the implementation of the model is flawed and that in order for it to work there needs to be a more balanced relationship between supply and demand, between vendor and consumer. Any business owner will tell you it makes business sense to try to keep your valued vendors in business. The relationship between FOSS consumers and FOSS developers is no different. That the initial price for their offering is $0.00 is irrelevant.

"if a development project decides to go the FOSS route, as opposed to closed-source commercial, it is unavoidable that programming-related work remains free and only support/services -related work can be charged for. That's how it's supposed to work."

As a developer for nearly 40 years and an avid contributor to FOSS and various communities, I've never heard that. As a business owner I can tell you that is not how it works at all. It's absurd to think that programming time is worthless while non-programming time is not.

Time is time. My time has value. I choose how I spend my time. And I spend a Lot of time learning and sharpening my development skills. There's value in those skills as much as in any hard-goods you buy in the store. My development time is even more valuable because "time" it's a limited and non-renewable resource. If someone wants me to spend my time doing something else then it's up to them to motivate me. Publishing FOSS does not obligate a developer to do anything - continued free labor on FOSS is not "unavoidable". The "freemium" model is extremely common where the developer offers a package for free, and the source is open, but if you want his extended features you need to pay a premium for them. These developers may diligently fix every bug in the free offering but they are not obligated to add new features. That's why That model works - you get teased with the free time/drug so that you'll pay for more.

When Dan gives us the benefit of his hard work for free, the other side of the FOSS model puts a small bit of burden on the consumer to balance out the equation, even if he doesn't ask for anything. We've all seen that without some amount of support that freeware authors frequently get burned out. We are compelled to pick up maintenance of the FOSS ourselves (rarely does this ever happen) or to migrate to the next offering, which is painful for all of us. We can get more life from the projects we value by contributing in some way: tell others about the software, send beer or pizza or a postcard, express random gratitude, write a review, contribute to some other project as a form of "pay forward", contribute code, or do something else to make the author smile. If you personally don't code then perhaps your contribution might be to encourage a family member or your company to allocate some developer time. If your company doesn't have a developer, then perhaps they can offer a donation to help you get what you want - beer, pizza, cash, $5 card for coffee, whatever. They are motivated to keep you productive and to reduce their overall cost of business. I need some kind of motivation to create new software. including FOSS addons for ToDoList or addons for my own FOSS. I, and others with similar skills, need some reason to take time away from my paying clients, family, and personal initiatives to create something that you want.

As I said before, you can ask Dan for features and it's up to him to decide if he wants to add them. He wrote TDL for himself and in a lot of ways we're just here to help him make it better for himself. But if his priorities and preferences for time allocation don't agree with yours, then I encourage you to consider the wide range of options that you have available to get what you want. Let me be clear - you CAN get what you want. Your decision is to balance how much you want it with these other dynamics. If you make the decision to take no assertive action, you simply may not ever get what you want. That's the chance we all take, and I'm not pressuring you to do anything except consider the options. Dan has built-in features for developers to create new views such as those that you have requested. This is where I said it's your choice how all of this works.

HTH
T

[.dan.g.]

Hi Gary

Could you take a screenshot of the 'Introduction.tdl' (which contains some dependencies) and edit it in MSPaint to show, as closely as possible, what you imagine the 'arrows' would look like?

Dan

[Gary]

@Tony: you are making quite a few excellent points and I do agree with you more often than not, with one exception: "the FOSS model puts a small bit of burden on the consumer to balance out the equation". IMHO, speaking practically (as opposed to ideologically), the moment you decide to go the FOSS route (as opposed to the commercial one), you should pretty much expect very little or nothing back, at least when it comes to getting rewarded for >>improving your core FOSS product<<. If it's FOSS, it's for freeloaders. Period. (Donationware does not work out too well even for the most spectacular projects, such as the #1 home user -oriented Linux distro, Linux Mint.) Please note that I do NOT, and I repeat: I do NOT think that a developer's time is worthless. Quite the opposite. All I'm saying is that if you decide to go the FOSS route, you need to have a secondary plan on how to monetize: through providing support, through providing installation services, through providing training and so on. Otherwise, one of the very few and far in between ways to get paid for improving your core FOSS product is indeed sponsored features and bug bounties. However, due to the fact that software developers are (rightly so!) quite expensive to hire, sponsored features can be afforded by businesses only, and are rarely practical to be paid for by individuals. Thus, if you want to monetize on FOSS through sponsored features, you need a product targeted at businesses, not individuals. Due to the fact that ToDoList has no multi-user/collaboration/cloud functionality, it is probably (?) a product for individuals, not businesses. It could be adapted for the small business (?) market, but then it would have to be ready to start competing with the likes of Evernote, Microsoft OneNote, Google Apps, etc. A tough, cutthroat market. Otherwise, if a product remains to be targeted at individuals, not businesses, monetization on >>core FOSS product development<< will remain very hard. That's where the freemium model usually comes in. *** I definitely understand that my preferences might not align with the minds of the developers of a FOSS product. I completely accept and respect that. I'm offering my feedback just for the heck of it, really :). (Maybe that's where we were having a disconnect.) "No promises, no demands", as the old Pat Benatar tune went.

[Tony G]

On Friday, December 2, 2016 at 4:27:58 AM UTC-8, Gary wrote:

@Tony: you are making quite a few excellent points and I do agree with you more often than not, with one exception: "the FOSS model puts a small bit of burden on the consumer to balance out the equation". IMHO, speaking practically (as opposed to ideologically), the moment you decide to go the FOSS route (as opposed to the commercial one), you should pretty much expect very little or nothing back, at least when it comes to getting rewarded for >>improving your core FOSS product<<. If it's FOSS, it's for freeloaders. Period.

Thank you, I'm glad this isn't perceived as adversarial. You're absolutely right. My intent there is that there is no expectation on the part of the developer, but consumers should recognize that They should be participating in the model beyond basic usage of FOSS. The problem with "FOSS is for freeloaders" is that this is the common perception, but obviously that just leads to a huge amount of developer burnout. So I'm saying much of the software we value does and will disappear if we agree with that premise, where it will probably last longer if consumers recognize a more symbiotic relationship.
 

(Donationware does not work out too well even for the most spectacular projects, such as the #1 home user -oriented Linux distro, Linux Mint.)

Agreed, wouldn't even suggest it. The fruit rots on the vine.
 

Please note that I do NOT, and I repeat: I do NOT think that a developer's time is worthless. Quite the opposite. All I'm saying is that if you decide to go the FOSS route, you need to have a secondary plan on how to monetize: through providing support, through providing installation services, through providing training and so on. Otherwise, one of the very few and far in between ways to get paid for improving your core FOSS product is indeed sponsored features and bug bounties.

I think we're in agreement here too. I don't know any developer who requests recompense for fixing his own bugs in core. But when a single user requests a feature which may be of use only to that user, it's not unreasonable to suggest the effort should be commissioned by that user - for cash, pizza, coffee, a postcard, whatever. The way I see it, when it's FOSS the user can ask anyone on the planet to add a new feature. It just so happens that the author is most familiar with it. That shouldn't put the additional burden on him to add one-off features. So the developer and guys like me can offer our time, in exchange for whatever we want, to give the user whatever they want - the deal is struck in common "whatever the market will bear" negotiation.

 

However, due to the fact that software developers are (rightly so!) quite expensive to hire, sponsored features can be afforded by businesses only, and are rarely practical to be paid for by individuals.

Complete agreement. I've never suggested that individuals be required to pay for features. However, note that I am talking about pizza and coffee too. I'll charge my normal business rate to a business. But I'll usually gladly spend time for individuals if they'd just offer to send me and my wife to the coffee shop as a token of appreciation. That's like 1% of the business rate. When I personally get the impression that someone is all "take" and no "give", I'm not inclined in the least to give unless it's something that I personally want to do for free. Feeling like people are being greedy is a strong Dis-incentive. A little bit of appreciation goes a long way with developers.

However, when it's obvious by the complexity of a request, volume of data, etc, that freeware is being used for business, then the discussion needs to shift toward business services at business rates. FOSS isn't always created just for the love of it. Corporate appreciation doesn't cut it when they get monetary value but don't translate that into equitable value for the developer. Some developers create FOSS with the specific intent of getting corporate sponsors for special business-scale features. Individuals usually reap the benefits. But again, if the developer gets burned out by personal-user demand, we never get to sponsorship and everyone loses. I'm trying to encourage people to (1) know that anything is possible, and (2) if they're using FOSS to benefit their business then they can't assume some developer is always going to help that cause for free - we have our own businesses and families to help.

 

Thus, if you want to monetize on FOSS through sponsored features, you need a product targeted at businesses, not individuals. Due to the fact that ToDoList has no multi-user/collaboration/cloud functionality, it is probably (?) a product for individuals, not businesses.

Actually it does. Check the wiki and concepts like source control (sharing, locks), time logging, reporting, and the Gantt/Kanban views - that stuff isn't just used by Mom and Dad to plan parties. :)
The beauty of ToDoList is that it can be used by Mom and Dad as well as ParentsForHumanity Inc.

 

It could be adapted for the small business (?) market, but then it would have to be ready to start competing with the likes of Evernote, Microsoft OneNote, Google Apps, etc. A tough, cutthroat market.

Well, it does compete with them. We're all using it here, no? I'm not using any of the other many free or commercial task/project-management tools out there, though I have used Microsoft Project and Todoist.com and others. We have a LinkedIn group for ToDoList where I think most or all of the members are business users.

 

Otherwise, if a product remains to be targeted at individuals, not businesses, monetization on >>core FOSS product development<< will remain very hard. That's where the freemium model usually comes in. *** I definitely understand that my preferences might not align with the minds of the developers of a FOSS product. I completely accept and respect that. I'm offering my feedback just for the heck of it, really :). (Maybe that's where we were having a disconnect.) "No promises, no demands", as the old Pat Benatar tune went.

ToDoList is not only an app but it's sort of a platform on which we can build. That _core_ feature of versatility is there to allow _us_ to create solutions that _we_ want that Dan prefers not to do, now or ever. So it's now upon us to decide whether or not to use that feature. If we can't do so ourselves we either need to motivate someone else, or we simply don't get what we want. That's all I've been saying here. There is no obligation, but we have a choice. This choice is an option for All FOSS, just moreso for ToDoList. This is far from the common belief that everything must come from one developer, a ridiculous concept considering we're talking about software where the source is open. The choice that people usually make is to disconnect with their FOSS of choice rather than giving anything to anyone to improve it. When this happens we all lose. I encourage everyone to consider the alternative options.

We really are in sync and I thank you for the cordial exchanges.
( I also thank Dan for allowing this discussion as I'm certain he's been tempted to delete it. )  ;)

Just remember: I help Dan outside of the code where I can - that's part of how I try to "pay-back/pay-forward" to him and other developers of FOSS that I use. But all requests are his to consider. So all of this is just discussion and does not directly relate to your feature request. :)

Regards,
T