2007 Roadmap Discussion
 

Do you have any comment on
http://www.kinook.com/Forum/showthre...s=&postid=9456 ?

regarding
# Export multiple item notes as combined RTF document

- I suppose in the language of UR, it was meant "item text". Please provide an option to include "item notes" in the export, just after each "item text". Thank you.

Finally!
 

The "Open New Tab as Blank" update is something I've really been anxious for. Glad to hear it will be in the next release.

This may ease the carpal tunnel I've developed from excessive clicking on the "close tab" button every time it opened yet another copy of an existing item. Not to mention the tendency to curse like a sailor after discovering I'm staring at the wrong copy (missing edits) of a document I was working on.....

Life is good! Kinook support is THE model for other software development companies.....

PIMfan

I guess it's in response to thread http://www.kinook.com/Forum/showthre...&threadid=2698 that I raised and presumed "nobody" likes :(, and until now, that "only" Kinook understood. I still firmly believe it's an idea with good merit. Regards the optional inclusion of Item Notes, not a bad idea. Perhaps export of either or both. In the case of either, the export of Item Text gives you class A document and Item Notes gives you class B document. If giving a talk, your speaking notes |vs| printed handout. Refining a system specification, draft design document |vs| work notes & ideas.

And, BTW, once the mechanism is in place, could be manipulated to export as HTML. (Perhaps seeing the term "HTML" might spark more interest.) Although, IMHO RTF is enough since there are heaps of editors around with which you can easily open RTF and save as HTML.

(PS: why is this in General Discussion and not in Suggestions?)

Hope search for DBCS text will be added in the next release.

Can't believe that Filtering the Tree has dropped so far down the priority list. Seems so fundamental to the concept of UR. Every other feature seems like a bell or whistle by comparison.

Among other things, task management is so cumbersome without it. Time to abandon all hope and find another program for task management.

I took a look at some forum discussions on this topic from 2004/2005. I think I understand the request fairly well. I also like it and am sorry to find out you've been waiting so long. I'll take a more serious look at it in the next week or so and might consolidate the previous discussions into a new forum thread. Perhaps there'll be enough current interest to find it a place in the Road Map.
I'm starting to use UR to good effect for Task Management. Would you like to start a new thread somewhere like User Tricks, Tips and Samples with say the top 3 hassles you are having specifically with task management? I'll try and contribute my sixpence worth and perhaps some other experienced UR users will help us both?

I use UR for task mgmnt via a modified GTD. There may be better programs but being able to include task mngmnt along w all the other stuff I do via URp is a definite plus in my book. It keeps everything in one place. That's my .02

I agree. All the "other stuff" is what has kept me using UR for task management. Unfortunately, lately I have had a lot more tasks to manage and it is to the point where the benefit of the other stuff is outweighed by the difficulty of managing tasks.

I have explained my reasoning for this ad infinitum on previous threads so won't reiterate yet again here or on another thread, but bottom line is tree filtering would give me the power to deal with large numbers of tasks with varying attributes... to be able to focus on different subsets of tasks and related info items while maintaining a hierachical view and without requiring spaghetti-like multilinks, which are too cumbersome to maintain.

I realize that UR is not a task manager and probably won't ever be as good at task management as a dedicated task management app. But this one feature would better allow me to keep all task management in UR and thus also enable me to keep it integrated with all the other great info management features.

My frustration comes from the fact that the more I have asked for this feature, the further down the priority list it has moved!

Thanks for taking time out to respond xja. Thanks also for your long list of contributions to UR in the way of comments and suggestions in the forum. Good luck with where ever your task management challenge takes you.

Yes, it is near the bottom of the list but, in a positive vein, it does sey 'approximate priority' which always leaves room for change.

Maybe Kinook will see the greater use of tree filtering & move it up the list. Development time could be relatively short.... or long.... I don't know.

But what I do know is that it would be a shame for you to have to go to the trouble of migrating to another program only to discover that tree filtering has been implemented.

Maybe Kinook will respond to this thread, your frustration or a private post from you. Seems to me to be worth a try.

I can only speak from my experience of migrating from:
Lotus Agenda -> Ecco Pro -> Zoot -> ADM + Ariadne -> Ultra Recall.

While I am keeping my eye on MyInfo, if the UR roadmap is implemented on a reasonable schedule, I think I'll stay where I am for the foreseeable future because of the above.

If you, in fact, decide to go elsewhere, I hope you'll join the outliner/PIM list where we keep each other up to date on what's out there, what' s working & what's not.

Good luck.

xja,

We're doing our best to accommodate everyone's requests (it would help if every user didn't have a different pet feature :^), and we'll think about adjusting the priority of the filtered trees request.

The problem with this feature is that there haven't been that many requests for it and it's a lot of work. To optimize loading, the tree is currently loaded from the root down, only processing expanded nodes. Filtering will have to load bottom up, or at least process every single node to determine whether it and its parents should be shown in the tree. And performance will be impacted significantly, since every node must be processed and a query performed for each to filter properly.

IMO, this is definitely an issue.

Currently, URp takes a while to load in on my system -- not too long, mind you -- just long enough.

To add significantly to that time frame would make me feel like I was using (god forbid) Outlook or an Adobe product -- something I try to avoid because it is such a PITA to start up.

Right--adding to the complexity is that the old behavior must continue to be used when not filtering to avoid unnecessarily impacting performance.

My plea is to not add features that would negatively impact on performance. UR is way too lethargic in my opinion. You have committed to improved performance for the next release (I cannot wait - when is it coming?), so why add a feature that will detract from your efforts?

Just my opinion though.

Jon

Jon,
I can not agree any more. Hope Kinook agrees.

I was thinking that there might be a way to accomplish the task requested w a practical workaround. If more details were available, someone might come up w a useful idea.

xja,
would it help if only the search pane shows some kind of tree structure?

Depending on the level in the tree, in the first column of the search pane (which is fixed to be an item name) would be indented (simple empty chars) and preceded with └ sign, sth like this

Column1 Column2
Root
_└ A
_└ B
__└ B2
_└ C
__└ C3

Note that there is an item C3 on level 3 straight under item from level 1, ie. item on level 2 doesn't pass the search query.
This should be very easily implemented based on the lineage attribute (ie. simply replace number of slash signs in the lineage attribute by number of empty chars), the only other thing that needs to be implemented is sorting of the search results to recover tree structure (again simple algorithm based on lineage attribute). There needs to be a little tweaking with the indentation based on whether parent/grand-parent/ ... are also in the search result (if not exist, decrease indentation).

The result would be a FILTERED tree structure based on your search. Sure, not aesthetically perfect (and only static with all nodes expanded), but would do the trick :)

But thinking about it, if this could be implemented, then surely the search pane could just use the "tree module" that Data explorer pane uses ... no overhead here, cause this is only the search result pane that "dies" once you click Enter on an item or navigate somewhere else in the Data explorer pane.

GREP
 

Would grep type search filter be hard to implement?

Thanks for the explanation. I understand that that could be prohibitively slow, although only when in filtered mode and with a large tree. If you could apply the filter to a particular branch, then a filter could be created that was quick and useful.

That said, even if the filter was applied from the top down, that would be useful. eg, when expanding a branch, hide any items that don't meet the filter criteria and hide those items' children. ie, hide the whole branch. Then the filter would only be applied when expanding a branch and would only be applied to those immediate children. Wouldn't that have much less of an impact on performance? I know that is different than what has been discussed before but still useful with more careful filter definitions.

btw, quant, thanks for the idea about a tree-like view in search results. what you describe would be similar to what I just described above... ie, every item in the tree would have to pass the filter criteria. I think it would need to work like I described though otherwise you could have some items that match the filter whose parents don't. How would they be depicted in a hierarchy if their parents are not? Would be a little confusing I think.

if the parent doesn't match the filter, I'd think that it shouldn't be in the results (case of C3 in the example), that's the main point of filtering.
It could be in the setting, that the tree structure itself should take priority, (ie. say keeping parent present even if it doesn't pass the result).
Probably only those that used it in another application could say which one is better for their needs :)

We discussed way back in the original threads whether parents and children that didn't match the filter should be shown. Rather than hijack this thread any further than I have, I'll defer to that discussion regarding my, and others', views on the "ideal" solution for that.

My comment above is my attempt to suggest an alternative that is more feasible to implement and that could still be useful, if not "ideal."

Consolidate Filtered Tree Ideas
 

Giday xja,

As promised, have started new forum thread on topic of filtered tree. Hopefully I've made an entry that contributes positively to getting this feature request resolved in the near future.

http://www.kinook.com/Forum/showthre...&threadid=2777