Suggested improvement for "Searching"

[David C]

When "View/Filter/Show only cells in current search" is in effect, the
cells not containing the search argument are merely grayed out. This
leaves the screen cluttered with irrevelant (grayed out) items. The
clutter could be greatly reduced simply by AUTOMATICALLY FOLDING all
of the grayed out cells. The cells would then be restored to normal
when the search box is cleared.

[Wouter van Oortmerssen]

Could you suggest this on http://www.google.com/moderator/#16/e=70f16
to see if others find this useful too?

Wouter

--
You received this message because you are subscribed to the Google Groups "TreeSheets" group.
To post to this group, send email to trees...@googlegroups.com.
To unsubscribe from this group, send email to treesheets+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/treesheets?hl=en.

[David Lynch]

I think it sounds like a pretty powerful and cool feature! It would also be useful to show yellow lines in the scroll bar at each y or x axis instance of the found word.  A complete collapse option would be rapid fast for zeroing in to the point you want to work from, or read about, and once you enter the cell the collapse could toggle back to normal.  It would also be interesting or handy to have a partial collapse with a sliding scale that could move like a zoom. For instance most of the branches that don't contain the found word could be collapsed, but as you slide the scale, more of the surrounding branches in the tree are uncollapsed.

David

[Vic]

Rather than changing the layout, I'd like to suggest that all the non-
matching cells have their text turned white. Then as you keyed the
search phrase in, what you would see would be and ever-narrowing focus
of matching cells.

As I see it, the disadvantage of folding is that the target would
effectively move around in the window.

And maybe I've missed an option, but the cells don't grey out for me,
they remain the colour I set them.

Vic

[Vic]

I missed the mention of filter, hence my comment about cells not
greying out for me. But suggestion for turning text white still
stands. I've added it to the moderator link Wouter mentioned.

[David Cunningham]

Yes, I concur...incremental search is the ideal solution!

[Wouter van Oortmerssen]

And maybe I've missed an option, but the cells don't grey out for me,
they remain the colour I set them.

That is odd.. can you email me a small example that shows this (along with exact actions you take) ?

Wouter
 

[David Cunningham]

--

[Vic]

Sorry, I missed David C's mention of filter, hence my comment about
cells not greying out for me. I'd forgotten about that option because
I found the change of layout that comes with it gets in the way.
That's why I'd prefer that all non-matching cells have white text and
are therefore blanked out.

On Sep 20, 1:17 am, Wouter van Oortmerssen <aardap...@gmail.com>
wrote:

[Wouter van Oortmerssen]

Ahh... so there's different people wanting rather different things here.

So you'd like it to white out on a normal, non-filtered search? I'd think at least light grey might be better, otherwise all these empty-looking boxes are a bit confusing for navigation?
It is definitely a feature I can add.. though the advantage of the current system is that you can continue to work with the search query on, whereas if you blank things out, you have to clear the search query before continuing. I prefer UI's that don't have "modes", that are more continuous.

And David, your screenshot looks like what I'd expect from search + filter. What about that image would you like different?

Auto folding is another option, but I think that be rather intrusive, with massive amounts of folds potentially really changing the document.

See, when it comes to changing TreeSheets behavior and UI at this point, I want to make sure I have a strong majority of users liking something that changes the default, or at least a large group of users for making something an option. You'd be surprised how many different workflows people have when using TreeSheets, and while I try to accommodate as many as possible, I can't accommodate all, even with options, as it is detrimental to the simplicity of the program. Hence why google moderator would be really helpful if more users would vote on it.

Wouter

[David Cunningham]

In my particular screen capture example, the "clutter effect" really does not manifest itself with such a small sample. 

At a minimum, I would like to see all cells that do not contain the search argument to become folded. 

When doing a search, it is advantageous to home in only on the relevant data, and in this respect I am a strong exponent of apps that employ "search/find as you type" aka "incremental search". NOTE: This would completely negate the need for "folding".

Of course, sometimes you don't always know exactly what to search for, especially as the database becomes more unwieldly, thus producing even more "clutter" to the point when even the folded items begin to take up more real estate. This is where I feel the need for a hierarchy tree. 

To summarize, ADDITIONAL components that would immensely improve Treesheets would be:

1) Folding of irrevelant cells -OR- Incremental Search

2) A hierarchy tree

[Wouter van Oortmerssen]

The current search is incremental, in that it shows search results on every character you type.

What you're asking for is a way to filter the document to just show relevant items as you type. This is a bit more difficuly in TreeSheets than it is in list based data managers because of the free form nature, since by hiding stuff in whatever way, the layout can change significantly which is disturbing, and because you can't tell from the structure which other cells may also be relevant (its children? its parent? its siblings to the right/left or up/down? children of children?).

Hence why I programmed the filter functionality the way I did: to try and shrink the document while keeping context sorta visible. I know it is not ideal and I am not that happy with it. But I am struggling to design a functionality that is going to work well for a lot of people's workflow, and I don't think auto-folding is it.

I am not sure what you mean by a hierarchy tree. The whole document is already a hierarchy tree. My original idea was that you'd shrink large amount of contents of certain cells down to tiny size so you can overview all your data to fit mostly on one screen. For some reason, people are not using the shrinking functionality.

Wouter

[David Cunningham]

It is one thing to store information, but quite another to readily retrieve it later on.

The "Zoom" function can be very useful when you have finally homed in on the cell that you need to use. I guess my main issue is the need to quickly and easily locate exactly what I want without guessing what specific search term to use; and then, finally, when I am in the ballpark of finding what I thought I was looking for, I don't want a to see all of those "unwanted cells" hindering my view. This is especially true when you have many related notes separated by a plethora of other (irrevelant) cells.

I definitely like the way Treesheets works, but another (or at least alternate) search mechanism appears to be needed. I honestly don't know the best solution from either a programming or user point of view. However, the old tried-and-true tree hierarchy approach used by 99% of all note and PIM apps seems the most viable. Ideally, the "tree view" (on the left side of the screen) would be programically generated, and would use the cell names as nodes to display the precise structure of Treesheets. Then (in customary fashion), clicking on a node would immediately take you to the specific cell.

Perhaps I don't fully understand the use of "Tags" in Treesheets. They seem to work as a method of copying the cell text name for later pasting.

Could not the the tag also be used as a means to "Go to" specific cell? However, this would not be as elegant as using a tree hierarchy.

If I need to be better informed on the use of tags I would appreciate some guidance in this respect. Thanks.

[Wouter van Oortmerssen]

David,

Could you point me to which of these other note takers you feel has the best search functionality? Something that could be an example of what you would like to see in TreeSheets?

Tags will not help you with your filtering needs, but I'd be happy to explain anything. What exactly in the "Tags & Hierarchy" section of the tutorial can use more clarification?

Wouter

[David Cunningham]

There are an abundance of apps using a tree-like model that could be incorporated into Treesheets

Here is a list of common outliners, both commercial and freeware:

http://www.outlinersoftware.com/topics/viewt/807/0/list-of-outliners

Virtually all of these use a hierarchy tree to assist with organization and locating data, similar to "Explore" in Microsoft Windows.

This description of "hierarchy nodes" may be useful:

http://help.sap.com/saphelp_nw04/helpdata/en/c1/493d3854129f68e10000009b38f8cf/content.htm

The addition of a hierarchy tree would be an efficient way of visualizing (in outline format) exactly how all of the cells and sub-cells are related to one another. The tree nodes would be typically placed as a separate window on left side, with the corresponding Treesheet cells on the right side. Each tree node would be "internally linked" to its corresponding Treesheet cell. Clicking on a particular node would immediately display its cell counterpart (highlighted with a bold border as it does currently).

A hotkey could even be used as a toggle to show or hide the hierarchy tree (in "hidden mode" Treesheets would appear exactly as it does now).

I am still experimenting with "Tags and Hierarchy" in the TS tutorial. All I am saying is that the addition of a tree-like structure would not in any way change the way other Treesheet functions work. It would only be another complementary mechanism.

-David

[Wouter van Oortmerssen]

On Mon, Sep 26, 2011 at 5:30 PM, David Cunningham <dpb...@gmail.com> wrote:

There are an abundance of apps using a tree-like model that could be incorporated into Treesheets

Here is a list of common outliners, both commercial and freeware:

http://www.outlinersoftware.com/topics/viewt/807/0/list-of-outliners

Virtually all of these use a hierarchy tree to assist with organization and locating data, similar to "Explore" in Microsoft Windows.

Well, I of course know what those look like. I was wondering more about the searching/filtering functionality, i.e. does the tree shrink as you type, etc? to have an idea whether that is useful in TreeSheets.

The typical format of explorer-tree on the left and editing pane on the right was exactly what I was trying to get away from, as it requires lots of navigation to get to my data: scrolling the tree, and clicking on the tree to reveal cell contents. I don't like scrolling, and I don't like separating "title" from "body" contents, as to me they are often the same.

TreeSheets was made with the idea that compact layout in both dimensions with shrinking would allow people to organize their data on a single screen, with no scrolling required.

If you are using TreeSheets with large bodies of text per cell, either judicious use of shrinking (or folding) would be recommended.

This description of "hierarchy nodes" may be useful:

http://help.sap.com/saphelp_nw04/helpdata/en/c1/493d3854129f68e10000009b38f8cf/content.htm

The addition of a hierarchy tree would be an efficient way of visualizing (in outline format) exactly how all of the cells and sub-cells are related to one another. The tree nodes would be typically placed as a separate window on left side, with the corresponding Treesheet cells on the right side. Each tree node would be "internally linked" to its corresponding Treesheet cell. Clicking on a particular node would immediately display its cell counterpart (highlighted with a bold border as it does currently).

A hotkey could even be used as a toggle to show or hide the hierarchy tree (in "hidden mode" Treesheets would appear exactly as it does now).

I am still experimenting with "Tags and Hierarchy" in the TS tutorial. All I am saying is that the addition of a tree-like structure would not in any way change the way other Treesheet functions work. It would only be another complementary mechanism.

Having an explorer tree additionally would have to have tremendous benefits, because the cognitive burden of having 2 trees showing the same structure in different ways also has its downsides, and right now I am not seeing the benefits yet. It may be that your workflow with TreeSheets is very different from mine, in which case you'd have to show me.

Wouter