Full Discontiguous Selection in the Tree for Reorganizing

[srdiamond15]

Some outline-based databases a) only allow selecting one topic at a time. Others b) provide for more, but require contiguity among simultaneously selected topics . Then d) the best allow you to select multiple topics anywhere, whether contiguous or discontiguous. To my knowledge, MyInfo is the only such database that occupies a position c). You can select multiple discontiguous topics, but they must occur at the same level in the hierarchy.

It is useful to be able to select anything, and then drag the selected items together to a new location, as a mean of reorganizing the tree. Why does MyInfo have this unusual limititaton of selections to the same level in the hierarchy?

[Petko]

This is doable for the future verions of MyInfo, however there is a little logical problem with such feature. When you select multiple documents and if they have subdocuments it will be confusing for the user: will the subdocuments be exported and moved too? In fact they will be moved, but it may seem that they will be not moved, because they are not selected.

What is your opinion about that?

[srdiamond15]

Some programs, e.g. the single pane outliner NoteMap by CaseSoft (http://www.casesoft.com), make an to allowing selecting everything. In NoteMap you can't apply the gather operation (equivalent to moving selected items) to a topic and its parent. The more common practice is that, as you surmise, that it is immaterial whether a child of a note to be moved is selected. It is moved the same way regardless.

My own intuition about how this should work to be logically consistent is different. I don't frankly know whether other users would find it confusing, but here's how I think it should work logically. Topics that are selected and moved to a new location are moved flat--that is, they emerge at the same hierarchical level regardless from whence they came. The same rule should apply to selected children. If the user expressly selects a child, it shoud go to the same level as its parent when it is moved. Otherwise, it should remain in its subordinated position as it is moved together with the parent topic.

If you decide to implement these somewhat more complex reorganizing methods, the possibility of the beginning user becoming confused and the advanced user forgetting what he's in the middle of doing does become greater. Then it becomes more important to allow the user to get back to where he was. Implementing undo--preferably multiple undo and redo--in the tree becomes more important.

[Clay Nichols]

I think that if you select multiple items then a Move would work the same way it would if you selected just one: Sub items get moved with the main item.

If you select an sub-item of an already selected item such as:

1. Project <selected>
a. Task
(1) Sub task <selected>

Then there are two options:
1. Powerful but complex: As described in previous post above, 1. and all it's sub items *except* for (1) and all of *it's* sub items would get moved to the new location. Likewise, (1) would be moved as well and now 1. and (1) would be siblings.

2. Simple, less powerful: Do not allow sub-items of an already selected item to be selected. Or, even more intuitive, UNSELECT the Item when it's subitem is selected.