Re: Search in a Treeview

I concur that human-relevant hierarchies are problematic for humans.
The limiting factor in logic of human/computer interaction is not the  
computer.

If search isn't searching, then data isn't organized in a way that is  
searchable.

On Feb 11, 2011, at 2:46 PM, Jaime Guerrero wrote:

> Search and Hierarchical Browsing (i.e. Trees) are incompatible.
>
> That's because what "matches" the search criteria is likely to be  
> all-over-the-place in the hierarchy.  Tree widgets and other widgets  
> for browsing hierarchies are simply not good UI to represent objects  
> widely-scattered within a hierarchy.
>
> That's because Hierarchical Browsing (trees) requires the user to  
> drill-down through intermediate objects (then enclosing hierarchy)  
> to find an object (in this case, a search-criteria-matching object).
>
> Also, drill down is ok for browsing, but incompatible with Searching  
> when those intermediate objects don't match the search criteria.   
> Why are the intermediate nodes included in the result set if they  
> don't match the criteria?  Because of the mechanics of Hierarchical  
> Browsing, intermediate objects have to be included, to retain the  
> organizational "skeleton" of the tree.  Thus problem #1 the search  
> results include objects which do not match the search criteria--  
> breaking the metaphor for search.
>
> Problem #2 is that manipulating such a tree to peruse some of the  
> "matching" search results would be horribly unusable/annoying.   
> Consider a hierarchy that's 5 levels deep with an average of 10  
> items at each level of the hierarchy.  That's a total of 10^5  
> intermediate nodes (100,000 objects searchable).  Now consider doing  
> a search which matches 1% of all objects (1,000 hits).  Assume these  
> are evenly distributed.  Thus, a poor user could only visually scan  
> search results by opening 10,000 nodes in the tree, which would take  
> an eternity (and probably crash the UI).
>
> Basically the user's task is very different when browsing a  
> hierarchy and when searching a 'space'.   Searching, at least for  
> contemporary users with some experience, is a directed task where  
> users know to enter sufficient search criteria to get them a  
> sufficiently small result set, or where results are sorted where the  
> most-salient results are sorted to the top (Google).   Browsing a  
> well-organized hierarchical taxonomy is a completely different  
> task-- making a series of coarse, intermediate, and then fine  
> choices to get closer and closer to the desired target.  Nothing  
> about searching is about making a series of choices in a fixed  
> taxonomy; nothing about browsing is about being specific enough  
> about unrelated search criteria.   Note that refining search  
> criteria in several steps is kind of like making a series of  
> choices, except that these are quick, brainless decisions about  
> choosing from a small number of fixed taxonometric choices; the  
> mental processes during search ref!
> inement are more intense mental analysis- formulating more  
> expressive search criteria.
>
> Both Windows and Mac do a good job of offering separate UIs for  
> browsing a file-system hierarchy from searching a file-system  
> hierarchy.  There's a reason for this!   Note how in both cases,  
> search results are always displayed as a flat list.  (Windows XP has  
> the better UI here over Mac Leopard+, by including in the results  
> table the PATH of each item... that is the connection between search  
> results and where they 'live' in the hierarchy-- that appears to be  
> the justification you gave for using a tree-- well this is evidence  
> that the information you need is possible to render without using a  
> tree).  Study them !
>
>
> NOTE: for the same above reasons, "Filtering" (as opposed to  
> Searching) on a Tree is also usually problematic.  Specialized  
> applications might require it, but I'd be VERY careful in combining  
> search with hierarchical browsing in any context.
>
>
>
> On Feb 11, 2011, at 1:10pm, allu somnadh wrote:
>
>> Hi All,
>>
>> Daily life of UX Designer - Battle with Development every time you  
>> propose a
>> new concept.
>>
>> *Today's battle - Search in a Treeview*.
>>
>> User's - Skilled Users dealing with huge amounts of data (data  
>> analytics).
>>
>> Scenario - Our User's deal with a limited set of data objects  
>> (approximately
>> 10,000). We present these data ojects (4 different types)  in a  
>> windows
>> explorer format - Treeview with multiple nodes (max levels - 5).
>>
>> Workflow - User need to locate 1-n data objects through the Data  
>> Explorer
>> and launch a module to run data Analytics.
>>
>> Issue: I'm proposing a search in the Treeview which is actually  
>> filtering
>> the tree to only show the search objects retaining the treeview.  
>> The results
>> only show the searched objects with any hierarchy associated with  
>> it. Need
>> the hierarchy since it gives the object a context and help the User  
>> identify
>> the right object in case of multiple results with the same name.
>>
>> Looks like search results in a tree node is not a convention, and
>> development wants to implement a flat list because it's for them  
>> and quote
>> some Usability issues which make no sense to me.
>>
>> So, I'm looking out for some guidance / feedback from folks here on  
>> this
>> concept , attaching a mockup. Does any one know of examples where  
>> they have
>> implemented search in a treeview.
>>
>> Thank you in advance!
>>
>> Best Regards
>>
>> Gattu
>> _______________________________________________
>> This is the BayCHI Discussions mailing list, [email protected]
>> To change your subscription options, or to unsubscribe, visit http://baychi.org/mailman/listinfo/discussions
> _______________________________________________
> This is the BayCHI Discussions mailing list, [email protected]
> To change your subscription options, or to unsubscribe, visit http://baychi.org/mailman/listinfo/discussions

Greg Austin
[email protected]
_______________________________________________
This is the BayCHI Discussions mailing list, [email protected]
To change your subscription options, or to unsubscribe, visit http://baychi.org/mailman/listinfo/discussions