Feature Suggestion: Selection based on Find tool [edited]

First of all, fantastic application! I’ve been waiting for a non-hierarchical mapping tool for over a year now, and am delighted it is coming from L&L. Looking forward to buying it. Coming to the beta at this later stage, I have not yet come across any bugs yet, but I do have a couple of small feature suggestions which might be easy to implement (I did not see this elsewhere while browsing, although there was a more complex request for tagging I think):

  1. Find All: Extend the “Find” tool just a little so that there is the option to highlight/select all the notes containing the search string (a “Find All” or maybe “Select All” button).

  2. Export Selected: Allow for exporting to text/lists only currently selected notes, e.g. a cluster or a Find All search result. [EDIT: My apologies, this feature is actually already there! it is just hidden further in the File > Export as…plain text list > Save As dialog. That means Keith read my mind and we are already halfway there!]

This would mean that even in a very large map, as you swim around it, it would be possible to tag certain notes (e.g. with a story character name, or other hashtag) and then later export only that subset of notes to focus in on that topic.

Another practical use is for those of us who might use this to plan out projects, actions, errands, tasks. It would be great for me to just doodle all over the place and then simply search for anything I tagged with @action or @errand and export to somewhere else where I can integrate into more hierarchical work.

Since there are already great tools for multiple selection, from individual Cmd-clicking to connected and cluster selection, the ability to export selected would allow for a much more flexible way of actually exploiting and compiling the final results of all that creative thinking (e.g. query for a character name and extract all notes to build a character description sheet).

I realize you could achieve the same final export result by simply exporting everything to text and running it through a query in a decent text editor such a BBEdit, but a) this requires an extra step and outside app, and b) you would not have the ability to do other things with selected results of a search, for example to connect them all to one central note or to format all of their styles.

As I see it, these two features [EDIT: one feature!] might be fairly simple to implement and they wouldn’t impose any kind of hierarchy on the app itself. It would just allow a more structured search through the creative soup so that you can do the “serious” work elsewhere. :wink:

Keep up the great work!
Patrick

Hi Patrick,

Thanks for the kind words! (Sorry for the late reply; I took a two-week Christmas vacation.) I’m glad to see that you found the export feature you were after.

The Find All feature is actually problematic from a technical perspective. Scapple adopts the standard OS X way of editing large, muti-text-object, views, which is to use one, single editor for all text objects. When you look at a Scapple board, you are just looking at a static drawing of all the text and lines. When you double-click on an item (or create a new item, or whatever), the single text editor is adjusted to look like the note at that point, and superimposed over the view. This keeps things fast and efficient: text editors take up resources, and having dozens (or hundreds) of them stuck to a board would slow things down. This is how lists, outline views and any other controls that have rows or grids on OS X work.

What this means, though, is that your suggestion isn’t as straightforwards as it at first might seem, because your suggestion would mean that multiple text editors would need creating and inserting into the view hierarchy in order to highlight all the search terms. This would involve quite a rewrite, because the main Scapple view, like most such controls on OS X, assumes that only one note can be edited at a time. Thus, it’s not that it’s a bad idea, but it’s not something that is really feasible for version 1.0.

Thanks and all the best,
Keith