Structured Projects and Contexts

[Winfried]

Hello Nicolas,

Jello Dashboard provides flat lists both for projects and contexts.
I'm handling more than 100 projects so a flat list is a little bit
confusing. The same is for a long list of context.

Do you think it is possible to have a structured list for both?

For example if you would use the "/" inside a project name or a
context name to interpret it as a sub-project or sub-context (i.e.
@errands/diy, @errands/walmart, project/subproject.

Than you could show the "root" below "context" and "projects" on the
sidebar and if you click on a project you could show a combo box to
show and select a subproject (perhaps with an "empty" selection for
the overall project)


Best regards, Winfried

P.S. I know that David Allen doesn't talk about structuring projects
and contexts but I feel that it is much easier to handle the lists and
keep the overview

[Stm]

I agree that this should be supported. Also notice that the GTD
Outlook plug-in Allen endorses supports subprojects.

Best, Stm

[dr.Uqbar]

This will not be supported. At least not exactly.

Building project hierarchies needs something like a database and I could not find a solid way to implement it.

But... Multi action projects will be supported in the next release. I got a working prototype on this and it is really functioning.

You could mark an action as a multi-step action, navigate into it and start adding actions which can be multi actions as well.

The bad news is that this hierarchy can only be viewed from inside jello because related information is stored into user defined fields.

You will have a chance to test the forthcoming alpha release in a couple of months and share your thoughts on my implementation.

thanks

Nicolas

--
Nicolas Sivridis
Author and hobbyist Developer
http://jello-dashboard.net

[Stm]

Couldn't you just store as some Outlook object (a note, an e-mail) a
very simple database with records of the following form:
<Proj1> is_a_subproject_of <Proj2>.
<Proj3> is_a_subproject_of <Proj2>.
...

Best, Stm

On Sep 3, 7:17 pm, dr.Uqbar <druq...@gmail.com> wrote:
> This will not be supported. At least not exactly.Building project

[JoeAtTrends]

You might not need a database per-say, if you switch to an object
oriented style of storing information in the memory, similar to how
ExtJs does its storage. You could then instead of storing strings of
array data split by |s in the journal, you could actually store a
large amount of database like data through JSON. This will be super
easy to load (by using Eval) and could support a whole heirarchy of
information. That would cover the structure in the contexts. Then you
could put custom attributes on tasks to actually note other tasks
which have dependancies on this one, or even create a structure of
which tasks need to be done before others can begin. Something like
that could be used to throw tasks into !Next context automagically by
tracking dependencies, not just contexts of what is needed to complete
them.

On Sep 3, 1:17 pm, dr.Uqbar <druq...@gmail.com> wrote:
> This will not be supported. At least not exactly.Building project

[dr.Uqbar]

Joe,

This was an idea I had beginning the new version (not the hierarchy, but the settings change) but I've decided to keep my core intact so users can work with their existing setups without the need of conversion. And changing of the settings engine would take really more time.

Jello already has a form and people who use it like it. I do not intend to change that and make another application from the scratch (I'm already in trouble trying to write from the scratch many lines of code).
Apart from that I believe that hierarchies are SO out. I've been dealing with them for years and in my opinion should be used when its absolutely necessary. You may not agree with that, but since I run an one man project cannot have multiple versions of an application for novice and experienced users. The whole thing can get easily out of hand.

I could later make a special hierarchy view out of tags and multi step actions (it's the same thing actually) but maybe hierarchy lovers won't be happy with that and insist on project hierarchies.
Right now I need to simplify things with the less developing time I can use and I know I can't keep everyone happy.

thank you for your excellent feedback (made me think a lot)
I'm counting on your opinion on the first alpha.

Nicolas