Posted on

Surfulater V1.95, B0.10 released

I started writing about the new Surfulater release a few hours ago, and that turned into One or many Knowledge Bases and Tree Filters, so here I am again.

The reason I wrote about whether to use one or many knowledge bases, relates to the most important new feature in this release, which is the ability to copy or move folders and articles from one knowledge base to another. This has been needed ever since I updated Surfulater to enable you to use multiple knowledge bases.

A message I received earlier today from David Britton sums this up nicely.

THANK YOU SO MUCH for this latest version, especially the ability to cut and paste articles between databases.

I have a lot of databases that need consolidating and better organization, and now I can do that.

I don’t tend to plan ahead very well, so the ability to clean up things after several research binges is very welcome.

Sincerely,
David R. Britton Jr.

I suggest you read the Help Topic Copy/Move Articles & Folders across Knowledge Bases before using this new feature.

Other enhancements in this release, include the ability to expand and collapse the entire tree or all folders in a branch, the ability to only show articles for a given folder, so that it is easier to move articles around in the tree, reorganization and updates to the Help, plus other bits and pieces as documented in the Release Notes which are here and in the Surfulater Help.

While I was writing the previous article I discovered a nasty bug in yesterdays V1.95.0.0 release where Surfulater would  crash when you copied or moved an article in the tree. I couldn’t believe my eyes when this happened. It was caused by a a silly oversight I made while writing the code to copy across databases. The good news is it was easy to fix, as you can see by this rapid release of V1.95.0.10 which can be downloaded here.

Posted on

One or many Knowledge Bases and Tree Filters

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.