TreeProjects - July 2013
< Next Topic | Back to topic list | Previous Topic >
Posted by Donovan
Jul 25, 2013 at 07:38 PM
I’m not a prolific poster here, but I read every day.
Just a heads-up that Smereka TreeProjects is coming up soon at BDJ for only $19.60 - that’s 60% off the normal $49 price. I have used the trial version a little bit and may have to get a license with this BDJ deal.
One thing I really appreciate is to see a developer participate in forums for their product category. I’ve seen Yaroslav participate here and he seems to genuinely appreciate quality feedback. That impresses me.
I’d like to hear thoughts about TreeProjects from any who use it as their primary PIM or outliner. My *sense* is it’s a top tier contender. Am I right?
Posted by MadaboutDana
Jul 26, 2013 at 03:13 PM
Hi Donovan: yes, TreeProjects is really very good, and Yaroslav is a very responsive developer. I’m currently using TreeProjects to translate a fairly sizeable magazine project; I’ve got the PDF originals in one window, with my translations in another window (TreeProjects has a very efficient MDI interface). I’ve got a couple of reference documents in background tabs, too (not just an MDI interface, but a tabbed MDI interface!).
The nice things about TreeProjects:
- very efficient (fast, small memory footprint)
- very stable (happily imports files in more or less any format; edits embedded files, all without blowing up or trashing the machine!)
- very good search engine (including hit term highlighting)
- very flexible layout (multiple windows; icons of nodes in navigation tree can be customised; nodes can be formatted, toolbars are easy to switch on/off etc.)
- limited but competent spellchecker
- capable rich-text editor
- excellent web import (almost as good as Alfons Schmid’s Notebooks!)
It’s missing a few things:
- authoring tools (notably wordcount, elegant quotation marks/apostrophes, conversion of dash to en-dash etc.)
- more sophisticated editor settings (autocapitalisation is slightly annoying)
- more selective search (but that’s getting fussy!)
but generally speaking, it’s got pretty much everything. And is a great deal less ponderous than UltraRecall or even MyInfo. Yaroslav really has created something that just zooms along; a perfect place to dump more or less everything. If it had mobile apps, I’d use it as my main info manager. As it is, I use it for a lot of stuff.
Cheers,
Bill
Posted by 22111
Jul 26, 2013 at 07:59 PM
@MadaboutDana and @Mr. Pidstryhach
Thank you very much for this overview about TreeProjects, and I have read many other reviews about it that seemed to value it high. So I had tried TP some time ago, also in order to see if I should buy it on bitsdujour.com, and my findings were:
1 - It is databased-based (SQLite), not text-based. This seems very good for once your data grows.
2 - It has “non-destructive item sorting”, which means you can have all your tree entries, independently of their tree position, have in a sorted view, then go back to the tree. In MyInfo, this is possible too, but they call it differently. Unfortunately, for practical purposes, this is not as valuable as it seems to be since most of the time, you would be willing to have a standardized entry format, but then, sort your entries by at least two criteria. For example, you would have your customers by town, let’s imagine 200 towns, and then from 1 to 100 customers as sub-items of these town items. Now you can only sort by the very first character in TP, which would be the (last) name, but even if you are willing to title your entries in the form
lastname, firstname, size, interest (your projection), branch
with all other info within the text field, you cannot sort entries/customers by anything else but by lastname/first character.
So some functionality is missing here: sorting by first word, then by second word, or by word #x, then by word #y, or just sorting by one word, but word #x and not necessarily the very first one.
This makes it impossible to sort your entries/customers by anything other than the tree order, or by the very first word. In MyInfo, the problem is similar.
3 - “Quick find by title” seems to be a good thing; it is something like “Search, but in tree only”. Any outliner should be able to make this difference since it avoids dozens of hits within the text of other items. But here, the search results of this feature are displayed within an additional pane, under the tree, not by indicators within the tree itself, as you might expect. So you have to change the active pane first, then only can display the relevant items found by this search.
When I think about it, this extra search pane has the advantage, at least, to make up for the missing sort by other criteria than just the very first character. But in normal work, you do not search for a list of items, but just for one item, and you want to work on it, directly, not switch panes, first, in order to access its text, meaning, you will have just one hit in that special search pane, and in this case, at least, that single hit should be accessible from the tree pane. Also, see my point 6.
4 - Keyboard shortcuts can be customized: good.
5 - The two tabbed toolbars above the text field cannot be hidden (only the main toolbar can be hidden, not these two): bad.
6 - The point I absolutely could not live with is this one: I do know some other outliners, but I do not know any outliner who forces you to press enter when you navigate in your tree - the same applies to the hit field described in point 3 - and then want to have a quick view of the content of the item in question. All outliners I know do this in the way that they only show the content after perhaps 200 or 300 milliseconds when you fast navigate your tree, but TP wants you to press enter, and when someone in the bitsdujour forum asked Mr. Pidstryhach why this was so, he answered there that he wanted to have TP have minimal response times. As said, all other outliners of my knowledge arrive at this same target by not presenting the content of an item at once, but only if your navigation seems to have stopped for a moment, so I don’t understand why this should not be possible in TP.
7 - It has advanced searches - see point 1, so it would be a shame if it had not - but no stored searches.
So these were my findings after playing around with TP for an hour some time ago. Perhaps there has been a new version in the meantime that addresses some of my critical points?
Without the big problem described in point 6, I would have been happy to buy TP, even full price, but on modern hardware, Mr. Pidstryhach’s argument does not seem to be a solution to a problem, as for 8088 processors, but create a serious problem for the user.
That’s why I ask here if there is good news, with respect to the negative points I discovered in TP.
Posted by Yaroslav Pidstryhach
Jul 28, 2013 at 11:00 AM
> As said, all other outliners of my knowledge arrive at this same target by not presenting the content of an item at once, but only if your navigation seems to have stopped for a moment, so I don’t understand why this should not be possible in TP.
Hmm, I never actually considered a delay between selection change in the tree, and displaying the contents. I still believe *immediate* (synchronous) display would kill tree navigation, but introducing a delay is a logical option. I added this to my issue tracker.
Posted by 22111
Jul 28, 2013 at 11:22 PM
Thank you very much for considering this very important point.
It goes without saying that we are speaking here of contents of the database, not of linked data: Here, the standard set by other programs like UR, MI, and so on is indeed to first press enter if you want those external files to be displayed - with the exception of pictures, though: As in UR and MI, they should be “immediately” displayed, without having to press enter. UR, in particular, does this extraordinarily well, with automatically launching an internal picture viewer, without the user being aware that the background is not the ordinary editor he looks at for non-picture content, and the internal viewer functions sufficiently fast in order to make display of text, rtf and pictures, in any order, a flawless “browsing” experience.
As for stripping the screen from unwanted toolbars, coding the necessary option for this is extremely easy, and many people for example use just one standard font, perhaps Arial 10 point or something, and then use keyboard shortcuts in order to apply bolding, italicising, and so on, so they don’t need formatting toolbars but love to have their screen as neat as possible.
With regards to the tree and the “tree search result” panes, I wrote my remarks from my notes done some/many months ago, without my memory recalling the details, but I firmly remember that the behavior of these two panes was unintuitive at the time, meaning the wrong pane had focus, in order to proceed from there; you might have changed this in the meanwhile, even.
But please consider three aspects, from a “workflow” point of view:
- When the results for this particular search are more than one item, the additional pane is really useful, but the focus should be switch to the additional pane since then you will choose “from there”. Immediately afterwards, though, in most cases, you will want to have focus again in the tree, and to have this item to be selected within the tree (!) - why? Because, if you work on that item chosen within the results pane, you will want to see your current item within its (tree) context!
- In rare cases, you will want to work on all (!) the finds, one after another, for example in my above example of a group of customers. Here - and here only -, the user would appreciate the tab to switch focus not between text/content and tree again, as elsewhere, but to switch between content and results pane, in order to select the next find there. This could perhaps be realized with a toggle, or with another special command. If I remember well, there were not special keyboard shortcuts for switching to content, to tree, and to results pane (I might be wrong here), but just one switch-around command you had to trigger several times, in case, which is not a good idea. Anyway, and also when you switch between content and results, for every such result selection, the tree should be updated in order to show the item in question in its context, too.
- But whenever the result of your special search is just one item, it is devoid of interest to show it within the/a special pane: In this case, just select it in within the tree (and even hide the result pane, when it had been shown for several results before this current search) - the coding of such differentiation between the cases “more than one tree search result” vs. “just one tree search result” would be very easy, but would have a very elegant effect.
On bits, I see TP is on offer there, today. There, you say (again) you want have TP “as simple as possible” - please, don’t say that (too often): It could be receoved as a thread that you would be unwilling to develop it beyond some minimum standards, which would be an absolute pity. Many outliner users want an elegant, smooth, uncomplicated UI, but powerful functionality nethertheless.
UR is bad on the first aspect, MI traditionally lacked some of the second, but is catching up, and there is certainly room for some technically not-too-basic TP.
My warmest wishes for your doing good business on bits, today!