(As the title indicates, this does not treat the maths program.)
Maple Prof. is an interesting piece of sw, but my experience (checked with the developer) is somewhat mixed. Since there is no review yet, some info should help.
It's a regular 2-pane outliner, but db-based; this is worth mentioning, since from its regular behaviour, you would think it's text-based; for example, better db-based outliners like MI and UR store pics within the text content in a light format where jpg remains jpg (= even when you don't import the jpg as an item on its own), whilst "bad" outliners (like AO, Maple, Jot+ and others) blow those jpg's up into a format that for a 30k jpg imported into the text, 1 million bytes may have been added to your file.
Outliners (= tree-formed data repositories) often are very helpful on the road, with perhaps a tiny screen. Thus, I never understood why most outliners which have search hit lists, do these in an additional pane, since if you have 3 panes at the same time, tree, content and search results, on a 12- or 14-inch screen, you will not see much of any of them.
Now Maple uses, as search results pane, the tree pane, or more precisely, you can switch back and forth between hits and tree in that pane (different viewers), and this seems perfectly logical since either you browse the tree, or the search results, by you scarcely ever will need both at the same time.
Also, you can do regular search (over tree and content), or then, in tree only; this seems mandatory, but some outliners don't offer this way of searching.
Very unfortunately, though, Maple does not offer Boolean search, no AND, OR, or NOT, which means that any search will be primitive "phrase search" (which is a very good thing if it comes besides Boolean search, but which is unbearable when it's the only search you get); of course, presenting a hit table, but no Boolean search, is quite an incongruity, but the developer says Boolean search will be implemented in the future, but without giving a road map.
Sideline: From my memory, the corporation behind Maple (they do some other sw's, too, but for Maple, there is slow but steady development, whilst for AO, e.g., development is almost inexistent, and Jot+ is defunct or rather can be bought in its ancient state from multiple years ago; none of these sw's have a forum) seemed to be from Spain (which is quite exceptional), but the current stuff seems to be from Russia (which is quite regular); I don't know if I'm mistaken, or if they have been bought, or whatever.
Also, very unfortunately, formatting of tree entries (bolding, italicising, underlining, coloring, background color, etc.) is NOT possible with Maple, and it will NOT be implemented, which seems to indicate they chose a bad tree component and are not willing to replace it; of course, you have the usual icons instead, but from my (very extensive) experience, icons could never ever replace tree formatting; in fact, for me that's the ultimate deal breaker.
Now the outstanding Maple feature, which is why I took the effort to write this review:
The only (?) big shot "search over several files" outliner is currently MI, but Maple Prof. has got a similar feature. Now, if you need trans-file search, for outliner files, your best bet is some tool like "File Locator" (The internal text search functions of both XY and SC file managers do it, too, but don't find all occurences, as hopefully FL does, and, interesting, they overlook the same occurrences, which are listed in FL (free).)
Whenever you search in outliner files with such a tool (most indexing search tools refuse to index outliner files to begin with), you will (hopefully, see before) at least see where to look further then, but no exterior tool will get you to the right item there, of course, and this makes the tremendous interest of such in internal trans-file search tool: When you click on a hit there, the proper item will be shown.
Since Maple Prof. has got such an exception feature (as said, together with MI), it deserves its own review, after all, even in the absence of tree formatting and Boolean search. Let me put this straight: Permanent absence of tree formatting makes me discard this program which otherwise has lots of potential, even if I would like it to implement Boolean search immediately, not some day in the future, and I would even be willing to live with the rather bad rtf editor which blows up imported/inserted pics.
Or in other words, the day Maple would replace their substandard tree component, I would switch over to Maple.
Now some brief words on that age-old competition UR-MI.
MI development is much more "developed" than UR's is, and the key misses are:
- UR has no global replace, and the developer is unwilling to implement it (this is the deal breaker for me, since trying to replace some term in 20 or 50 items, by external macro, is crazy and unreliable)
- UR has no trans-file search, but then, you use both programs more or less as "global data repositories", i.e. few people will create multiple files in any of them, so this is less important
- MI (of which the cloning feature development is much more recent than in UR) has always a missing detail in its cloning function which makes it almost unusable: Whenever you add child items (or grandchildren and such) to a cloned (parent) item, this is then absent from the descendants of the clone. Now there are very few instances where this absence would be welcome indeed, but in most practical uses, this totally awful:
Not only for "one subject in different contexts in general", but especially in the "ToDo" part of your big tree: This absence makes it impossible to put some subject into the ToDo list, and then to work upon that subject from the ToDo list; instead, you will need to CROSS-REFERENCE the subject in the ToDo list, i.e. to jump to the "natural" (and unique) context, and to work from there then.
On the other hand, MI's developer could work on this, and then, his program would undoubtedly be the far better program, at least speaking of Prof. version in both instances, since only MI Prof. has the global replace feature (which everybody will need in the end, even if he thinks he can do without, that's blatant wishful thinking), and which UR presumably will never get.
(I'm repeating myself here: In UR, tree formatting is possible with a trick... whilst in MI, it's available straight on.)
Thus, with a little more development, MI will be number one (or, if you're willing to cross-reference instead of cloning), it beats UR even today).
And yes, Maple competitors should adopt Maple's hit table, in the frame of the tree, at least by option.
