Their are two schools of thought when it comes to filing information; store everything in one big file or break things up into smaller, easier to manage,Â separate files.
When I designed Surfulater I went down the path of one big file, thinking this would make SurfulaterÂ easier to use, because you didn’t need to go around opening,Â closing and creating files. It didn’t take long at all for our users to tell us they really did want to use multiple files and Surfulater was changed to suit. Their is no right or wrong way to handle this, although some may disagree. It is a matter of what works best for each individual.
The argument for one big file stems from the point of view that all content should be stored together in one place, and the software provides sufficient means to view and work withÂ various subsets of information, to overcome the problem of managing and working with what otherwise might be overwhelming. For example you could hide all folders except those in a specific branch, or only show articles that match some search criteria. You can think of these as filters which strain out most content,Â leaving behind only the juicy relevant bits.
SurfulaterÂ already has some capabilities that let you restrict the content shown inÂ the Knowledge Tree. For example you canÂ hide all articles except those in a specificÂ folder or hide all articles period, or show all folders fully expanded, without any articles.Â And there is the Chronological tree view that shows content according to when it was added. These are a good start but we need to do more and will.
Fortunately the tree control I’ve written for Surfulater is very fast and was designed to enable tree items to be shown or hidden at will, without having to re-populate the tree from scratch. You can see this for yourself by using F9 or Show Articles and notice that theÂ tree is instantly updated, even when it contains a large number of items. WithoutÂ this capability, filtering a large tree would be impractical.
So the groundwork has been laid to enable us to provide more ways to filter information to help you focus on what’s important at a particular point in time. I’ve got several ideas for filters including letting you create your own via say a search string. I’d welcome your suggestions on this.
I need to wrap up as I’m told some of my posts are getting a bit long. I’ll end with a few comments. Multiple knowledge bases currently work best for me. This may change as more sophisticated capabilities are added like filters and keywords, but I somehow doubt it. Trees are well trees, and the bigger they get the more time you waste working the tree, instead of getting things done.
5 Replies to “One or many Knowledge Bases and Tree Filters”
The most important things about filtering are:
1) First, there needs to be categories, tags, etc. to filter by, rather than just searching for text strings in the articles.
2)We need it to be customizable – every combination and configuration of filters should be available (and, or, containing, etc.) As I am a Getting Things Done junkie, I need to be able to generate a filter view as follows: “Professional Projects/Project/Next Actions for This Project.” Another filter view that is vital: “All Projects/View Next Actions Only”
Agreed. Tags or keywords will be coming very soon along with new Views by tags.
That will be followed by Advanced Search capabilities that will enable search on specific fields, folders, by date range etc.
The recipe used in an Advanced Search can be saved and applied as Filter. That’s the current plan at least. Stay tuned.
Another thought I’ve had is to have a type of “Filter Folder” that you define by adding your Filter Tag definition.
That way you could have as many Filter Folders as you like, and I guess could live side-by-side with your normal folders?
I also like the idea of being able to generate Tags from content (that’s a bit of a cross between a search and a tag), but if you’ve got heaps of articles tagging can get to be a bit of a burden. Some way of quickly copying the tags from one article to other articles is necessary too (using Drag & Drop would be handy).
Saving of Search Definitions is great. How about saving multiple search folders? That way you could collect X articles in one search folder and Y articles in a different folder (if you needed to work between them and keep them seperate).
Thanks for the suggestions.
Re. Filter Folders: do these folders contain articles that match a filter specification or are these folders that contain filter specifications you can use?
I’ve been doing quite a bit of reading and research into automated text classification and have touched on this in a few places including: http://blog.surfulater.com/2005/05/01/managing-knowledge-pt-1/ From feedback I’ve had automated classification isn’t the panacea we’d like it to be. Further it would likely be reasonably complex to setup, deterring many folks from using it. I’d still like to take it for a spin though.
Automated Tag generation maybe an easier nut to crack, but I don’t really know. You will be able to pick tags from a list, which of course you can add to.
After looking at various tagging systems I’ve decided to keep it simple, at least for starters.
Unfortunately content categorization, be it in trees, using tags or whatever requires time and effort.
Saving multiple search results folders is on the todo list. My current thought is simply to allow the search results folder to be copied.
Comments are closed.