The due date gaps between some of the key tasks are always the same.
For instance:
Print Order for Courseware (7 Days before Due Date of Ship Courseware
OR 17 Days before Due date of First Day of Class)
Ship Courseware (7 Days before Due Date of Meet and Greet OR 10 Days
before Due date of First Day of Class)
Meet and Greet Session (3 Days before Due date of First Day of Class)
First Day of Class 5/1/2010
The task due dates are relative to parent task.
It would be great if I could copy a project and have the time
intervals be the same on the new project as they were between tasks
old
I think this could be implemented in the "New from template"
functionality (No changes to UI).
Adding the following behaviors to "New from template" would *seem* to
do it:
(a) Check if the top level and at least one sub has a due date, if yes
then:
(b) Prompt for a new Project Due Date for the top level task.
(b2) OPTIONAL: Prompt whether to use completion dates or dues dates
for step (c)
(c) Recalculate all the due dates in the task set so that the existing
intervals between all tasks and the top level task due are preserved
when creating the new tasks.
It seems it could be implemented without inventing a new thing for
users to learn.
For my use case I would simply create an special template that had the
correct gaps.
For others, the timing of the last project of the same type would be
preserved.
Would love to hear if this sound interesting to anyone else.
I think this has come up before. However, this would take MLO to a
whole new level if Andrey can make it happen.
D.
--
You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group.
To post to this group, send email to mylifeo...@googlegroups.com.
To unsubscribe from this group, send email to mylifeorganiz...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mylifeorganized?hl=en.
I thought of an even simpler way of implementing this that also
increases its usefulness.
If when I *change any date in any task* and it has any child tasks
with due dates, then prompt whether to recalculate all the due dates
in the task set so that the existing intervals between all tasks and
the top level task due are preserved. (Perhaps this only happens if
"Project" is checked.
This approach handles copying templates, but it also handles easily
moving projects without the need to create a template from the current
one to move. So when I reschedule a class, I can just change the top
level date and have this prompt help me keep everything the same.
Also helps you to not forget that this particular project should be
managed with "T-Minus Due Dates". Again, no UI changes required.
If this functionality was seen as valuable enough, then a task
checkbox could be added that says "keep subtasks dates of all child
items proportional when changing the date on this task" - this would
prevent me from accidents like clicking "no" to the prompt and
realizing I want it on. It would also facilitate turning OFF the
global prompt if it was
This is actually different than the discussion of lag in that
particular post in that:
*) I want to see the due dates displayed in outline view and on my
calendar, rather than have them depend on gaps recorded within the
tasks. Otherwise I have to calculate in my head and mentally project
the schedule.
*) The task dates relationship is actually fixed, not floating with
previous task completion - so even if I don't ship courseware by the
right date, the class will still be held on the target date and I need
to compensate with rush shipping. The concept of lag would loose this
hard fact because if things get late, MLO would not be communicating -
through missed due dates - that a bunch of other stuff is also getting
crammed up.
So I think "T-Minus" task relationships are different to "Lag" in that
the top level task dates are completely fixed and I would like MLO to
be making that very evident.
D.
All the functionality you want (and more) has been available for a
long time in programs such as MS Project. I know Project is expensive
but there are also far cheaper alternatives.
MLO is superb at handling small intra-day tasks (what GTD people call
"widget-cranking" tasks) with basic dependencies (start task A when
task B finishes, sub tasks in order) and recurring task patterns.
Although there is provision for "Projects" this is more in the GTD
sense of a related series of low level tasks in support of personal
goals.
The scenarios you describe with variable and fixed lead times and
rescheduling calculations would, I suspect, be difficult to implement
and, more importantly, may have consequences for the speed/
responsiveness of MLO. There are a number of development requests
pending which would enable a great product do even better what it
already does well. I think it would be a mistake to succumb to "scope
creep".
Put another way, you could easily make Notepad a better text editor
but you wouldn't want to try and turn it into a tool for writing a
novel - you would use Word or similar.
On Mar 6, 11:37 am, djsdjsdjs <googlegroups.servi...@sanoys.com>
wrote:
I work as a one-person company and MS project would definitely be
complete overkill.
This isn't a complex or unusual concept - but the requirement is not
frequently articulated by users. I have also included implementation
suggestions that respects the desire of everyone (myself included) not
to turn MLO into MS Project.
I suspect other users have similar projects scheduling needs, but
perform a variety of work-arounds to make this type of scheduling work
within their GTD systems.
D.
I use MS Project quite a lot and it just doesn't work for this near
term planning.
MLO starting to get there,I think, in filling this gap. I have
partially adopted some of the Pomodoro techniques and I am now
flagging major tasks as Key Tasks, allocating Pomodoro's to them (= 30
min chunks) - just by adding to the caption eg [10] = a 5 hour task
and allocating these to particular days in the future (using a
'Calendar' view which just shows Key Task).
What I would like is to be able to actually have a field which I can
enter this figure and to then have MLO add up the number of Pomodoro's
I have allocated to each day and show this as a total for each day so
that I can see the days that I have over/underloaded.
The ability to link tasks along the lines outlined by dj would then be
an added bonus so that if I have a series related tasks and I push
back the starting task, it then pushes back all the following tasks
by the same amount.
For me, once you have linked the tasks, you should be able to adjust
the lead/lag time simply by changing the date of the successor task.
MLO/GTD and all the other time management schemes that I have seen are
useful for helping you identify what you need to be doing next and
helping you focus on that but useless for helping you work out what
you can get done in the next two weeks (happy to be told otherwise).
The Pomodoro Technique does offer some helpful, lightweight ideas in
that area and I would very happy to see Andrey take MLO in that
direction because I think there would be a good market for such a
product.
PS: A true calendar view would also be very useful.
> > > D.- Hide quoted text -
>
> - Show quoted text -
I have been involved in many projects big and small, from IT to
construction to outsourcing. I have also spent a lot of time in
manufacturing planning and scheduling. Project scheduling (which is
what you're getting into), even at a one-man business level such as
your own, can be a complex area.
A software developer would look to add functionality which has a broad
appeal. If scheduling functionality were to be added (and be useful to
more than one individual) they would have to look at adding a whole
feature set which takes into account things such as: -
Dependencies based on:
Finish to Start
Task can finish anytime but not before first task has started
(+/- lag/lead time if any)
Start to Start
Task can start anytime but not before first task has started
(+/- lag/lead time if any)
Finish to Finish
Task can finish anytime but not before first task has finished
(+/- lag/lead time if any)
Start to Finish
Task can start anytime but not before first task has finished
(+/- lag/lead time if any)
Working calendars - should the software take account of non-working
days?
Warnings when key milestones are missed, dependencies are broken when
changing dates
Critical path analysis
Gantt charts
etc etc etc
You could say well I don't need all that but then the issue becomes
where do you stop because you're already down that path and risk
having unhappy users if you don't finish what you started and do half
a job. Particularly if they are using it run their business.
I think the point is that MLO is principally for personal task
management rather than company (even sole trader) task management.
It's designed to accomodate methodologies such as GTD, DIT, Autofocus,
Covey, which are not really date or schedule driven. The date
functionality exists more for recording tasks related to specific
events or for basic individual work scheduling.
I'm not saying that MLO couldn't do what you want, it's a very
flexible tool, but if your requirements are not complex enough for
project management software then manual workarounds and existing
functionality should suffice rather than taking development down a
blind alley.
On Mar 7, 3:18 am, djsdjsdjs <googlegroups.servi...@sanoys.com> wrote:
In terms of functionality to help manage personal workload over time
(load balancing), I think this would be a very natural and desirable
development from where MLO is now.
As for the calendar view, I think that one's been done to death
already - do a group search ;-)
Regards,
Ken
I forgot to mention Richard, try the MS Project 2010 Beta it's light
years better - they finally got it right!
On Mar 7, 12:54 pm, Richard C <r...@rcollings.co.uk> wrote:
*scope creep*
pottster, I completely understand scope creep and what it can do to
software. However, I have submitted literally hundreds of software
ideas to open source and commercial software initiatives. It is a
purposeful focus for me to be exceptionally aware of the general
current scope of the software and understand the impact of adding
functionality. This is how I know to delineate between adding
functionality that has UI and/or UX impacts and those that do not.
New UI controls mean new explanations, new helpfile links, etc, so
they impact development and more importantly they impact whether a new
prospective user (revenue potential) feels overwhelmed by the amount
of software nomenclature they must learn. (I feel "Don't Make Me
Think" by Steve Krug applies to ALL software - not just the web).
When functionality can be added with a simple question or even a
default behavior, the impact is dramatically reduced.
I expressed the minimum requirement that I believe gives 80% of the
value of what I am getting at - something that seems to be an
underlying development theme in MLO already. The scope creep that you
outlined does not have to be a natural progression simply by
facilitating this request.
The potential for scope creep is always there and using the rationale
that it is a slippery slope should not be used to downplay an idea -
this downplay could be used on every feature request on this forum.
*Incremental*
I also want to point out to all that this suggestion is specifically
incremental. It does not require a comprehensive design of the whole
idea of "task dependencies" to add significant value. In fact, I
wonder why it could not be the default behavior when coping tasks
trees. I can't think of a time when I would need a complete duplicate
of a task tree with the same dates in real life. Can anyone enlighten
us on whether there is a use case for leaving all dates the same or if
it is simply the natural result of doing a copy of tasks in the
absence of any other requirements?
*additional value*
As background I use these dates to populate other systems - rush
shipping on registration systems, cut off dates, etc. So having the
system determine them automatically has a big productivity boost in
that it supports: *) fewer date determination mistakes, *) rapid setup
of dependent systems.
*nschm873*, thanks for updating me on the official term.
*My Workaround*
I held back on expressing my work around because I feel there is
significant value to the feature. Not only is my work around a lot of
manual work (hence the name "work around") but sometimes the long
standing devotees of a product (which I seem on my way to becoming)
almost consider work arounds to be features - even if they are buried
in forum content.
My work around is simply to add a T-minus tag to the name of each
subtask. "Print Courseware [T-5]" If I copy or move an event date, I
redo the dates using these tags. This way I can use start times for
their intended purpose and calendar sync is preserved.
Currently on my most complex "backward planned" event I only have
about 10 identified subtasks to change - but if this grows to include
more detail on these or other projects, the work around will be very
unmanageable.
Thanks,
D.
Phil.
Audrey what do you think? I'm in the software business too, and we
have clients pay for special work done. It could still be a part of
MLO that you sell to everyone. Only we would be able to ensure this
feature is in there.
Since this might be outside Audrey's product roadmap....would all on
this thread be willing to chip in $xx amount for Audrey to add the
feature or we could ask him what he would do if for and see if we
could rally others to join in to bring the cost down.
Lisa
Nice one! Appeal to the money-grabbing instincts of the Developer's
evil twin sister "Audrey".
But seriously, this suggestion is wrong on so many levels.
If money IS the motivation then, in the current recession, there are
two types of company doing well. Those selling small amounts of
expensive products and those selling large amounts of cheap products.
Unless Andrey is going to transform MLO into the SAP of the
productivity world overnight then I'd suggest it's the latter
strategy. In which case, right now, there's only one game in town and
that's smartphone apps.
If the motivation lies elsewhere, for example in making the best
product possible, then I think the model you're referring to i.e. B2B
pay by feature, custom built, "pig in a poke" has hardly been the
recipe for software excellence (I know because I've been on the
receiving end of it too many times). Instead, I think what we've got
right now, which is a Developer who actually uses the product
themself, has got good intuition about what works and what doesn't and
who seems genuinely proud of what they have created, works just fine.
Having said that, I think some way (whether it's a better forum or
some other means) of democratically arriving at popular feature
requests would be a good idea right now.
At the risk of being too altruistic I actually find this suggestion a
bit distasteful as well - it would be disturbing if we got into
feature set by auction. I also don't think the product would have a
long future if that happened - people tend to be averse to getting
ripped off.
Ok, enough ranting, I'll just finish by saying that I'd pay NOT to
have the feature(s) you're requesting (see my earlier posts in this
thread). If you have lots of money my friend (and it seems you do) buy
MS Project it should give you what you want.
Regards,
Ken
On Mar 31, 4:50 am, Lisa Stroyan <lstro...@gmail.com> wrote:
> At 06:13 PM 3/30/2010, you wrote:
>
> >Since this might be outside Audrey's product roadmap....would all on
> >this thread be willing to chip in $xx amount for Audrey to add the
> >feature or we could ask him what he would do if for and see if we
> >could rally others to join in to bring the cost down.
>
> Only issue I have with this is that if Andrey is doing
> everything...it delays other features (such as Android app, which I
> would gladly pay for and am sure others will too...)
>
> Lisa
>
> ----------
> Lisa Stroyan, mailto:lstro...@gmail.comwww.empathic-parenting.com
A great thing about MLO is that it has a really active user forum
where people thrash around ideas and this provides Andrey with good
feedback. And as you say pottster " a Developer who actually uses the
product themself, has got good intuition about what works and what
doesn't".
But I do think that relative dates is AN EXCELLENT IDEA - something
I've brought up in the past. In my opinion, it would fit perfectly
within the MLO logic and intended use, and it would add a tremendous
amount of value. Hopefully, Andrey (and his evil twin sister business
advisor "Audrey") would agree..
I am not going to pay for any feature extra. This idea sounds
hilarious to me after just paying my bucks for my Standard Edition 2
weeks ago.
A short rebuttal to Ken then further explanation of my first thread:
Ken, I'm sure Andrey is motivated by BOTH money and the desire to make
excellent software. There is nothing distasteful or wrong with wanting
to receive compensation for work. My suggestion does not compromise
either. In fact, if his client base becomes bigger he can actually do
both better. :)
A couple of questions Ken: Which product do you use? The free,
standard or professional version? What are the differences between
them? Price and feature set. You get a certain amount of features for
free or you pay extra for additional features. So the precedent for
paying for additional features has already been set...by Andrey
himself (or maybe it was Audrey) :)
And lastly (tongue in cheek), if you are willing to pay NOT to get a
feature you are suggesting essentially the same thing as I...paying
for something (of course in your case the feature is nothing). :)
Back to my original idea:
Customer funded development does work and can help expand the product
quicker. Andrey doesn't have to guess what people will pay for....he
doesn't have to take the risk. He is able to decide if it is something
that he wants to do, fits in the product roadmap and if it is worth
it. What we get is the assurance the feature will be in the product
(hopefully sooner)
So if we really want to have the OPTIONAL features described in the
above thread...we could poll the discussion group and see how many
people would be interested in paying something extra. Then see if they
would all chip in $xx (whatever depending on interest) and see if
Andrey will do it.
Thoughts...
I enjoy a good discussion but, really, just THINK about what you're
suggesting.
A few(!) questions...
How much do you think people would have to "chip in"?
Enough to engage another developer? on a contract/permanant basis?
Enough to suspend current development and re-prioritize?
Where's the spec for the feature?
Does everybody think they're getting the same thing?
When is the money paid, the beginning or the end of development?
Who has sign off?
When does the feature have to be delivered by?
What if people want to pay for competing features?
What are the legalities of "getting what you're paying for" in this
scenario?
Ok I'm getting bored now.
Regarding your "rebuttal" - you're missing the logic of my post
completely.
I agree that Andrey is probably motivated by both money and software
excellence. That's my point - your suggestion fails on both counts.
Financially, there are far bigger prizes at the moment principally the
successful delivery of smartphone versions of MLO. I think the amount
you (and others) would have to "chip in" to cause a change in
priorities might surprise you.
From the point of view of software excellence, B2B custom builds based
on "I can do anything you want if the price is right" invariably
result in an incoherent mess of a product and an unhappy customer
base. In any case, this is a B2C product not a B2B product - as
Chuckdevee said "different dynamic".
To answer your question - I use the Professional version. But again,
you're missing the point. MLO is a mass market software product and
the feature set is pre-determined based on the differing needs of MANY
people. The Professional version was the closest to what I wanted but
still represented a compromise - there are features I don't want or
use and others missing I would like. This is NOT a "precedent" for a
customer paid for custom build.
Finally, and most importantly, what we DO need is a way of capturing
user requirements that will be an effective decision making tool for
the developer in building a feature set that is as relevant as it can
be for the target market. This is a complex task (I don't envy
Andrey). It's not just about adding what's the most popular (whether
expressed in terms of votes or dollars) it's also about anticipating
future needs (i.e. being innovative), avoiding "bloat", design
consistency, product differentiation etc etc.
Personally, I think the way forward is a more robust forum to capture
user requirements and good ideas and secondly more advanced user
involvement in suggesting/developing/testing features. The recent
extended Beta phase on 3.5.0 was a good example of what can be
acheived if there is a good "live" dialogue between a few experienced
users and the developer.
Regards,
Ken