unify, modularize, and expose the search/report/filter
This is by far #1 limitation of the software. The search, filtering, and reporting capabilities seem too 'unfinished' or 'disjoint'. I can search nodes with words, but not report on them, I can report on some attributes, but not search on them, and I can't filter based on my searches... A powerful and modular searching would tremendously enhance the usability of the software when you have thousands of nodes.
Why not rethink the whole search paradigm and make 3 main changes:
1) Modularize - look at search in Toodledo. Simple, yet very effective. You add additional sub-querries to make searches mode selective e.g. I could create (and SAVE) a search with these 'mini-searches' combined:
Creation date + is greater than + date (note: drop down lists change based on context of the previous list)
AND
TagName + is in list + 'myTag1, myTag2'
OR
TagName + color is + 'red'
AND
ThoughtName + is like + 'some text'
AND
NodeType + is not + 'Book'
AND
LinkType + is in list + 'reads, reports to'
AND
CustomAttribute1 + isLessThan + '1000'
(Custom type is a separate request but combined with this ability it would take the software light years ahead in terms of possibilities).
2) At the very least, if implementing a GUI is too much, PLEASE expose this via a query language
3) Finally, the search results can be presented as an outline (report), clickable breadcrumb list (search) and/or can filter (or at least hide) the non selected links and/or nodes
If such functionality, along with custom attributes is added, I'm willing to pay a higher price for the software. Those two are also the main reason why our company is holding on purchasing many licenses of the software...
Is there any chance that we can see this in 5.0?
LukeP
shared this idea
-
Konstantinos Psychas
commented
Based on my previous comment I started this https://github.com/kpsychas/brain2neo.
-
Konstantinos Psychas
commented
The truth is we don't actually need the Brain to implement this feature if we have access to exported XML of the Brain we want (I know this is a feature you have to pay for though).
I made a gist that counts the thoughts of a specific type or label by reading a brain XML file
here (I haven't found a way to access this information from GUI):
https://gist.github.com/kpsychas/3d94709909c24aa38e37If anyone is interested into starting a project with more features let me know in a comment under this gist.
-
Anonymous
commented
I fully agree that reporting is the weakest point within TB7. I use TB7 on a daily basis intensively. I would very much welcome a modular and far more powerful reporting module. For example it would be great if you can make a kind of reporting tag based on an underlying (nested, multilevel) query. The representation could be a subset of your Plex. If you could define how that Plex should be preseted (structure) that would be ideal for me.
-
Sharon Kay
commented
Amazed that this is still missing from TB7.
When you implement it, let us search on link parameters as well as thought parameters. Thanks. -
Joachim
commented
Especially the "SAVE" for a search ideally as the content of a though (smart content) would be terrific!
-
Anonymous
commented
Any comments from PB dev team on the search for V7?
-
Alan Lindsay
commented
Yes please, access to a query language would be oh so helpful.
-
LukeP
commented
Harlan, are there any plans to expose a 'search API' in the near future (in 5.0 that is)? Lack of API (or modular search abilities), especially for searches, was main reason why our company decided not to purchase licenses. Another reason was structured metadata, not being able to cross link brains or have multiple plex views in tabs...
-
sunwei415
commented
An API with access to the database will do the work, together with customaziable user interface.
-
twospoons
commented
need the ability to edit posts...
But I think there is a difference between filtering the plex based on types/tags (which preserves the current plex structure but shows only relevant information)... and completely restructuring the plex based on search parameters. Both can be extremely useful, but are NOT entirely overlapping features.
-
twospoons
commented
But I think there is a difference between filtering the plex based on types/tags (which preserves the current plex structure but shows only relevant information... and completely restructuring the plex based on search parameters. Both can be extremely useful, but are entirely overlapping features.
-
twospoons
commented
Saving a search as a thought and displaying the results as child thoughts has been discussed before. I really like that idea. It adds more context to the plex...
-
LukeP
commented
...expand all found nodes
-
LukeP
commented
After thinking about it some more, as a secondary step to exposing the search query language, for UI, the nodes themselves could be used to build a 'search tree'. With a notion of a 'saved search node' you could build the search with each node being AND/OR and leaf nodes acting as parameters. The search nodes would be displayed in the tree, could be 'refreshed' and if clicked would...
-
LukeP
commented
Combine this with http://thebrain.uservoice.com/pages/general/suggestions/70182 and ability to arrange and filter nodes by search results and custom attributes and it takes the software to the next level!
-
LukeP
commented
Harlan, is that something we may see for 5.0? there must be some sort of internal query language that PB uses already that could be exposed?
-
jostber
commented
Great suggestion. Access to a query language would be a powerful functionality. There could then be an option when entering a query if this should be a filter, search or report operation.