Filtered Tree View

[zargron]

The following ideas obviously aren’t just my own. I spent quite some time trawling through the forum gathering the ideas and comments of others to add to my own. When I say “some” time, it was actually quite a lot of time. There has been a lot of discussion on this topic over a long period of time hasn’t there?! IMHO Kinook, you really should resolve this filtered tree issue sooner than later.

REQUIREMENT OVERVIEW
Create and save filtered tree views, in order to better manage large volumes of data, whilst enjoying the benefits of manipulating data items in an outline format.

DESIGN
1) Fundamental to this proposed solution is utilisation of the existing search item functionality.

2) Enhance the option Limit search to selected item in Data Explorer pane. Key to this enhancement involves allowing the user to lock in a particular data item as the one used to limit searching. There should be 3 choices when it comes to this option, and it might read something like this:

Limit search to:
[■] Whole Tree
[ ] Selected Item in Data Explorer pane
[ ] Specified Item ( …\… lineage …\… \ item title )

3) Make the following new options available to a search item:

(a) New option of grid view |vs| tree view. Grid view to present items in the search results pane just as it does now. Tree view however to present the fabled filtered tree in the search results pane. (Basically a mini data explorer in the search results pane.)

(b) With tree view specified, allow users to decide whether the filtered tree defaults to being expanded |vs| collapsed when the search is executed. For example:

Default display of tree to:
[■] Collapsed
[ ] Expanded

4) Exactly the same fundamental items should be returned by the search routine whether grid view or tree view has been specified. (The searching will of course need to be modified slightly to respect the enhancement proposed in point (2) above).

5) With tree view, after the matching items have been located, the following processing should occur:

(a) Find Parents. Recursively navigate from each matching item up the UR database tree, uniquely gathering parent items along the way, until reaching the specified root, or more correctly, limiting item. This limiting item is determined as per point (2) above. It can be the UR database root node (eg. whole tree), selected item in data explorer pane, or a specified item.

(b) Build Tree. Use lineage information to recursively navigate from the limiting root item downwards, building up the tree structure.

(c) Present Tree. If collapsed has been chosen, show the root node with a [+] next to it ready for expansion. If expanded has been chosen, show the tree expanded. This expanded tree will only go down to matching items. Put another way, every leaf node of the expanded tree will be an item that matches the search criteria. If any of these matching items has children, then a [+] should be presented, (allowing the user to expose the matching item’s children).

(d) Highlight. A highlight color, (eg. yellow), to be applied to the item title of matching items.

6) This proposed filtered tree view should operate in a similar manner to the existing data explorer pane. For example, when an item is selected, show its item text and data entry form in the item details pane.

7) Respect current tab navigation behavior. Obviously this involves preservation of the contents of the search results pane, (ie. filtered tree view), as the users moves back and forth between different tabs.

CLOSING REMARKS
The proposed Limit search to enhancement will always be available when searching, whether the user does a grid view or tree view search. UR already has a “Link/Move/Copy Item” dialog box. With minimal modification, this same dialog box could be used to set the specified limiting item. A small [Browse] button could be provided nearby for this purpose.

Straight after search execution, with default to expanded turned on, every leaf node will be highlighted yellow. Non-leaf nodes will of course also be highlighted if they match the search criteria. As the user collapses & expands various parts of the filtered tree view, the matching items will remain highlighted, giving the user a strong visual clue as to which items matched their search criteria.

I have NOT asked for hoisting to be made available in the filtered tree view. Perhaps this can be left for a later version? Besides, I suggest that the Limit search to option provides a form of implicit hoisting anyway.

Comments please.

[zargron]

Well Kinook, back on the 5th of July in thread http://www.kinook.com/Forum/showthre...&threadid=2744 you commented that there doesn't seem to be much interest in the filtered tree request. Well, I totally agree. There have been no responses regarding the content or format of my previous post. I suggest you put the filtered tree request at the back of the UR Development Roadmap.

[quant]

there are not so many active users on this forum, and for many of them, UR is already too geeky. The best strategy would be, if this feature could be implemented only partially, sth that wouldn't take too long to develop and wouldn't be hard to comprehend. Maybe then Kinook could see the response from clients who use it, and/or want further improvement to that feature (just like hoisting was done).

The better question would be,
"who doesn't want the filtering tree feature to be implemented?"
... and you'd see that none of the many many forum users objects, ie. Kinook should implement it ;-)

[zargron]

Originally posted by quant
The better question would be,
"who doesn't want the filtering tree feature to be implemented?"
... and you'd see that none of the many many forum users objects, ie. Kinook should implement it ;-)

Marketing consultant to food company executive:
"I set a billboard up with a phone number that asked people who don't want us to produce chipmunk dumplings to call the number. Since only two people called up, I advise your company to start making them as soon as possible because everybody else must want them."

[janrif]

Originally posted by zargron
Well Kinook, back on the 5th of July in thread http://www.kinook.com/Forum/showthre...&threadid=2744 you commented that there doesn't seem to be much interest in the filtered tree request. Well, I totally agree. There have been no responses regarding the content or format of my previous post. I suggest you put the filtered tree request at the back of the UR Development Roadmap.

Zargon, you put a lot of thought into your request.

The fact that no one has responded does not necessarily mean that there is no interest. I can tell you that I would be interested but not if it slows URp. I think I mentioned that.

The other thing to consider is that what you outlined might be above many of our heads.

For example, I understand hoisting & the concept of filtering the tree but I'm not sure how that is beneficial over just getting search results.

OTOH, I think I meekly suggested a grep-type search just for the tree that might provide some simple tree filtering & had no response either. So what?

Did that make it a stupid, useless ignorant suggestion? Maybe.

In any case, I'm glad you gave me something more to think about. Maybe it will be implemented some day.

[zargron]

Giday janrif,

The main intention behind my facetious comments was to illicit a response rather than quash the filtered tree idea. And yes, such a detailed & long enhancement proposal can easily confuse, but more likely, in this fast paced age in which we live, result in people not even bothering to read it. I considered this before preparing & posting, wanting to find out for future reference the impact / worth of a post of that style. It surprised me however that there were zero replies after about 10 days. Did people look at it and think "oh good, it's in the pipeline now so I won't even bother to post"? Did they think "what a load of crap, I'm not going to bother to post"? Were they fully confused? Unfortunately I'll never know...

I can tell you that I would be interested but not if it slows URp. I think I mentioned that.

I've proposed it being a search facility since that gives Kinook an opportunity to contain it's impact. The user creates the query and executes it when they want. I suggest that refresh of query results be left for the user to initiate rather than being triggered automatically.

For example, I understand hoisting & the concept of filtering the tree but I'm not sure how that is beneficial over just getting search results. OTOH, I think I meekly suggested a grep-type search just for the tree that might provide some simple tree filtering...

A couple of things.

Filtering the existing data explorer pane (if that is what you are suggesting) is in IMHO out of the question. It is a cornerstone interface component that all existing users have to be familiar with. Being fundamental to UR and very stable I suggest it should be left alone.

Regards whether being "beneficial over search results", try creating an item in the search results pane. In my post under Requirements Overview I subtly mention "...manipulating data items in an outline format". Having established and run a search (filter), I suggest that the user should be free to add, edit and delete items. This is a key issue with all outlining software - messing around getting to the right place in the tree before you can create a new item. UR already handles this problem quite well. For example:
--- search for an item nearby where you want to put your new item
--- double-click that item in the search results pane to highlight it in the data explorer
--- perform a short distance navigation in data explorer before creating your new item in the correct location

I had no response either. So what? Did that make it a stupid, useless ignorant suggestion? Maybe.

More significantly, it gives Kinook full right to decide that filtered tree view gets put at the back of the Roadmap.

[xja]

Zargron, Thanks for the detailed breakdown of how this could work. I spent a lot of time with similar (albeit a little different) suggestions a long time ago but to no avail. Unfortunately due to personal time constraints right now, I don't have the time to fully engage in a detailed iterative discussion of how tree filtering could work (I'll defer to my previous posts from long ago).

Rather than try to describe how the tree filtering should be implemented, let me try to explain what I want it to accomplish. I do this for 2 reasons: (1) Maybe others would want similar functionality, (2) maybe Kinook can find the ideal way to implement (since we are not familiar with how the code is designed, it is difficult and pointless for us to suggest approaches that are easier to implement)

I use UR as a project/task manager that has information management integrated, so all info related to each task or project is kept together and is readily accessible. I want tree filtering so that I can see subsets of tasks (with or without all linked info resources) in their hierarchical context (eg, tasks grouped by project, subproject, etc.). Examples of how I would use that:

- hide completed items
- show only high priority items
- show only items due in the next n days
- show only items with certain flag(s) (I use flags to denote task status)

If anyone else uses UR as a project/task manager, I would be interested to know if they would find such capabilities to be useful. If no one else uses UR as a project/task manager, I wonder if that is because these capabilities are not possible.

Kinook, if you have another approach to achieve the above functionaltiy, I would be open to hear it. If you feel that such project/task management functionality is too far outside the scope of what UR is, then let us know.

[zargron]

Excellent comments xja.

Starting with your concerns as to whether UR is able to cope with project/task manager functionality. I'll take a punt here by suggesting that you know in your heart that UR is able to cope with it - otherwise you wouldn't have persevered with UR for so long. What you are asking for is a specific interface enhancement that you feel would make your experience with UR take a huge leap forward.

You can already do some pretty comprehensive filtering of completed, priority, flagged and next due tasks in UR. What frustrates you is being forced to see the results of your filtering in a flat list. You would love to see the results in an outline format.

For a long time you have been using UR to build up your own unique way of handling project management. You have become very familiar and comfortable with the outlined view of your information. Seeing it as a flat list robs you of familiarity, comfort and obviously the organisational power that comes with an outlined data view. No matter how hard you try to force yourself to work with the search results pane, you end up going back to the data explorer pane. You waste valuable mental energy manually separating the wheat from the chaff.

(Oops – there I go rabbiting on again… )

I spent a lot of time with similar (albeit a little different) suggestions a long time ago but to no avail. Unfortunately due to personal time constraints right now, I don't have the time to fully engage in a detailed iterative discussion of how tree filtering could work (I'll defer to my previous posts from long ago).

You don’t get off that easily. If you want this facility bad enough, allocate 15 minutes as follows:
--- 5 mins = read my proposal;
--- 5 mins = read it again making note of exactly 5 criticisms;
--- 5 mins = post those 5 remarks in this thread.

…maybe Kinook can find the ideal way to implement (since we are not familiar with how the code is designed, it is difficult and pointless for us to suggest approaches that are easier to implement…

All I can suggest to you and others is that you assume UR is based on high quality software design principles. Basically this means you assume it is very modularised with minimal dependency between each module. For example, assume that each pane is a separate object that has a carefully crafted low dependency on any other pane. Assume each toolbar has little or no dependency on any other toolbar. Assume importing and exporting has “no” dependency on printing and visa versa. If would be nice, (but very rarely happens), if the software vendor conveys dependency problems when responding to suggestions.

If anyone else uses UR as a project/task manager, I would be interested to know if they would find such capabilities to be useful. If no one else uses UR as a project/task manager, I wonder if that is because these capabilities are not possible.

Amongst other things, I use UR as a “project manager”. I’ve started to package up my “project management” implementation in preparation for submitting to the forum at the end of August 2008.

[xja]

With all due respect, I defer to the lengthy discussions in which I have participated on this matter as reference for how things should work (search on "filter tree"). Bottom line is it is not terribly dissimilar to what you suggest. Kinook is familiar with all these discussions. I really don't have anything else to add as to my recommendations for implementation.

[zargron]

To you xja I simply ask a quick final question on this topic. How close to the mark was I with the first 3 paragraphs in my previous post? (eg. "Starting with your concerns...")

To you Kinook, good luck deciding where to place Filtered Tree View on the UR Roadmap.

Ciao for now.

[xja]

Originally posted by zargron
To you xja I simply ask a quick final question on this topic. How close to the mark was I with the first 3 paragraphs in my previous post? (eg. "Starting with your concerns...")

Those comments are accurate, with the exception being that my project/task management requirements have gotten more complex (juggling a lot more tasks) recently, which has magnified the shortcomings of UR's data explorer to the point where it may be better to use a solution better optimized for task management. The sacrifice will be the loss of having the excellent info management of UR integrated into and linked to my task management solution.

[zargron]

Volume breaks things, whether it be a normally adequate breakwater or a tolerable spreadsheet payroll solution. With information, it’s about managing scope. "Show me the unresolved production alerts grouped by production line and section. I don’t care about the 1,000’s of resolved alerts or which production lines are open or closed - just give me a data view of what I should be working on now! Oh - and make it an outlined data view so I can navigate more efficiently."

Thanks for your reply xja and I agree with your sentiment. It is annoying however that UR is so close on so many fronts. If UR was just OK, then we wouldn’t store all that much information in it. However, it is so good that we get wildly excited and start shoving data in at a fast rate. With this large volume of valuable information, UR holds together rather well with only a few small leaks appearing. What’s the main source of these leaks? Scope & Navigation. Potential repair? Filtered Tree View.

Kinook will do it one day. Perhaps you need to go find that other …task management solution… whilst continuing to use UR for other purposes?

[StephenUK]

Most of the discussion is over my head. Nonetheless, in my simplistic way, this is what I personally would like to see as tree filtering / viewing (although I realise many of these suggestions are not new):

- At the top of the Data explorer pane a row of buttons (maybe with toggle on and off functions).

- The buttons would allow one to do the following:

1. Determine to what depth to display the tree, as in an outliner.

2. Possibly access the excellent hoist functions from this point rather than from the menu bar.

3. Possibly have more than one possible list of hoist functions. (The existing straight drop down list soon gets quite long). Thus, there can be different sets of hoists associated with different projects.

4. Whereas hoisting shows only one branch of the tree, it would be nice to have a way to hoist several branches at once. Put another way, it would be useful to have a dialog with tick boxes against directories, to indicate which ones to view. (Searches would then only be against those shown, of course). A view that represented only part of the tree would be in a different color to avoid confusion. And maybe one could save several different subsets of the tree in some way.

5. A button to toggle on and off viewing of all of the Templates, Recycle bin and Imported items directories. (This can already be achieved by a workaround using hoisting, but it would be nice for newcomers to have an easy way to reduce clutter).

6. As a slight aside, the ability to background color rows (not just text color) in the Data Explorer. Then to say "display red rows" etc. (This is really just an alternative approach to No 4). I use colored rows in ListPro and in Excel and they are really helpful visual clues and yet simple. I know there are already flags, but I feel colored rows that go the whole width of the data explorer screen are easier on the eye and they can have a different function to flags.

7. I would like easily to be able to choose different colors for directory icons. This is not a filter, but it provides an easy way to set up visual clues. Or just maybe, when searching, those directories containing search results might change color?

Hope some of this makes sense.

[reesd]

Personally I can't live without tree filtering which is why I stopped using UR, MLO, and everything but bonsai over six months ago. After I did so I became completly convinced of the importance of it and how it actually makes things simpler if built into the interface well.

Unfortunately, Bonsai is missing custom columns and its view definition is really limited which is why I look though all the outliners every so many months to see if they have added tree filtering. Unfortunately no joy, maybe I will finally install a Mac vmware image just so I can play with the great outliners they have.

Thanks,

d

[quant]

Originally posted by reesd
Personally I can't live without tree filtering which is why I stopped using UR, MLO, and everything but bonsai over six months ago.

I don't know, probably it's one of the features that if you never tried them you dont know how useful they are ...
but I suppose bonsai filters only based on the item title, so can't you just create a search based on item title? Is is that crucial to see the tree structure for the items matching filter in the search result pane? You can navigate the search result pane, see given item's parent's, children, open it in new tab, rerun the search etc.

Can you give an example or explain when having a filtered tree is a necessity for the problem at hand, so that I can better understand its usefulness?