SUGGESTION: Allow users to define the default values for task fields

[John . Smith]

In MLO Windows...

Hello 

I suggest MLO needs:

SUGGESTION 01) An new Option that offers the user a list showing the full list of task fields so that the user can choose which fields do and which do not inherit their values when a new task is created.  I suggest that these values should probably default from the parent task. 

SUGGESTION 02) However even better, the user should be given a further option of choosing where these values inherit from

a) The currently selected task

b) The parent of the selected task

SUGGESTION 03) Another useful option would be to give the option for any date fields to default now/today.

SUGGESTION 04) And another useful option would be to make the fields 'cascade'.

i.e. If the field is changed on a task that already has children, then all children tasks (and grand-children etc) would take on the value of that field.
This can be particularly useful for the Star field or any other field being used for "focus on today". 

Background

For me personally "Suggesion 01)" is a huge issue, as it would finally allow me to use to use Flag fields for GTD Action Status (Active, Someday, Waiting etc). Without this feature, despite my spending about 12 months of my life on MLO, I still have failed to get a satisfactory implementation of the GTD method when I am using a fairly large number (400+) tasks on my system.

Any takers?

J 

[Dwight]

Would suggestion 1 apply only when a task is created using the "new
task" button and the menu equivalents (task>new task; task>new subtask;
Ins; Alt+Ins)?

How about New Folder, New Project, and don't forget New From Template.

Would it apply for tasks created through the RTE window?

Would it apply to tasks emailed in through TBE?

How about tasks moved via drag & drop? Or cut/copy and paste? or the
Move To/Ctrl M command?

For inherited fields resulting from a copy or move command, when
inheriting a value in a field that can have multiple values (dependency,
context) would the new (inherited) value replace the existing value or
be appended to it?

For each of these questions there are probably existing users who could
only live with "yes" and others who could only live with "no" so if you
are answering too quickly go back and think through the implications of
each choice: what sorts of things will be enabled or disabled by each
choice.

And finally, be careful to avoid over-reliance on asking for a new
setting so that users can configure their personal choice for each
answer\. It's kind of a coward's answer, adds a lot of costs to the
development, adds to the complexity of the software, makes it hard to
understand and intimidates potential users

-Dwight

On 9/7/2016 8:10 PM, John . Smith wrote:
> In MLO Windows...
>
>
> Hello
>
> I suggest MLO needs:
>
> SUGGESTION 01) An new Option that offers the user a list showing

> the *full list *of *task fields* so that the user can choose which

> fields do and which do not inherit their values when a new task is
> created. I suggest that these values should probably default from the
> parent task.
>
> SUGGESTION 02) However even better, the user should be given a further
> option of choosing where these values inherit from
> a) The currently selected task
> b) The parent of the selected task
>
> SUGGESTION 03) Another useful option would be to give the option for any
> date fields to default now/today.
>
> SUGGESTION 04) And another useful option would be to make the fields
> 'cascade'.
> i.e. If the field is changed on a task that already has children, then
> all children tasks (and grand-children etc) would take on the value of
> that field.
> This can be particularly useful for the Star field or any other field
> being used for "focus on today".
>
>
> Background

> For me personally "Suggesion 01)" is a /*huge */issue, as it would

> finally allow me to use to use Flag fields for GTD Action Status
> (Active, Someday, Waiting etc). Without this feature, despite my
> spending about 12 months of my life on MLO, I still have failed to get a
> satisfactory implementation of the GTD method when I am using a fairly
> large number (400+) tasks on my system.
>
> Any takers?
>
> J
>

> --
> You received this message because you are subscribed to the Google
> Groups "MyLifeOrganized" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mylifeorganiz...@googlegroups.com
> <mailto:mylifeorganiz...@googlegroups.com>.
> To post to this group, send email to mylifeo...@googlegroups.com
> <mailto:mylifeo...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/mylifeorganized.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mylifeorganized/0a092c61-ce4d-4018-8b5e-6e6dccbc6531%40googlegroups.com
> <https://groups.google.com/d/msgid/mylifeorganized/0a092c61-ce4d-4018-8b5e-6e6dccbc6531%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[John . Smith]

I see this as a group activity and I certainly don't have all the answers, but here goes:

Surely new Folders and  new Projects are relatively rare events for most users, compared to creation of new tasks. And if so then what the defaults are for new items becomes less important. 

Moreover given how easy it is to convert a task into a Folder or Project what is the real problem here?

Tentatively I suggest we simply leave things as a user is creating a new Folder or new Project using a single transaction and only apply the above functionality to the moment of creating new tasks & sub tasks.

I'm sorry I have no experience with Templates and can offer no opinion. 

I can't see any good reasons why Rapid Text Entry (RTE) should work in a different way from normal task creation (e.g. Insert or Alt/Insert etc)m, as after all the user would be able to set RTE to add entries wherever they choose as their "inbox", and all the user needs do is change the properties of that Inbox to suit them. (Or simply make the field in question not inherit anywhere.)

I'm sorry I don't know what TBE is, but no I don't create tasks by email so I can't really comment. I tentatively suggest that the same rationale would apply as RTE.

For copying and moving tasks in any way I agree that the answer is not obvious. The simplest thing would be for the values not to change just because they have been copied. I concede that this may not suit everyone, but I would argue that almost nothing suits absolutely everyone. If it annoys enough people the only solution is to find a way that gives them the choice. If pushed (and this will annoy you Dwight) I would put this into settings.

Given that it's easier to delete stuff than add the right stuff I suggest that where appropriate (e.g. Context-tag fields) I suggest we append where appropriate.

Dwight, I partially disagree with you about settings.

I think the "cowards answer" is to fail to think very VERY carefully about what each default setting should be. 

It is also important to carefully word and structure the wording of the choices to make them as intelligible as possible to all users.

This may involve examples. And the exact messages in any mouse-over text and/or help messages are crucial too. 

This should be tested with trials on new users as well as on the Old Timers.

...And anything less is cowardly!

But to me giving the user more power to choose is generally a good thing. This will be particularly true with the mindset that can even begin to tolerate the existing interface of MLO. However in order to make applications less intimidating & confusing, I have long argued that all software needs to make it abundantly clear which options are for Novice, Intermediate and Expert levels of user, by marking up with colour etc. Or greying things out and deactivating them when you are in a more junior mode.

Either way let's face it complexity and intimidation is a battle that was lost long ago for MLO! 

MLO seems to have the reputation of being "the incredibly adaptable task management application everyone uses after they have tried all the others" and as such, for that to be true, some degree of "complexity and intimidation" is simply inevitable.

Fwiw, speaking personally all I need is to be able to control are the defaults for the Flag field, because this appears (after many months of trying alternative workarounds) to be the ONLY way that I can get a satisfactory implementation of the GTD method where one has a reasonably large (400+) number of tasks.
However having seen the full version of precisely what I describe in my "Suggestion 01)" working in a competitor product (TDL) it doesn't seem so unreasonable to give that degree of control over defaults of ALL fields as that would clearly add a lot of power to the user.

If Old Timers start to squeal, all we need to is set the defaults to not inherit and life for them goes on as before.

In conclusion
Yes my suggestion would add complexity, and yes this could be intimidating. And yes this would cost something to add.

But I feel it would add enormous power to MLO (and am pretty sure that it would be considerably cheaper than for example adding completely new user-defined fields for example)

Ultimately all I can say is that this is a deal-breaker issue for me personally. The reason is because thus far, after many months of workarounds, I have comprehensively failed to get GTD to work acceptably on MLO, but my Suggestion 01) would get me there.

Trying to help

J