Boolean Chart Redesign

Tue Jul 20 01:59:29 UTC 2010

Bernd Groh wrote:
> David Marshall wrote:
>>
>> On 7/19/10 5:20 PM, "Bernd Groh" <bgroh at redhat.com> wrote:
>>
>>  
>>> David Marshall wrote:
>>>    
>>>> On 7/17/10 3:09 PM, "Max Kanat-Alexander" <mkanat at bugzilla.org> wrote:
>>>>
>>>>        
>>>>> Hey folks. So, the Boolean Charts are great, they're powerful, and
>>>>> they've been an important part of Bugzilla since 2000. However, the
>>>>> Boolean Charts have some problems:
>>>>>
>>>>> * The way that AND, OR, and multiple charts work is really 
>>>>> confusing. I
>>>>> didn't fully understand it until I fully understood Search.pm, which
>>>>> very few people understand.
>>>>>             
>>>> I think they're pretty easy to understand, actually.  Each Boolean 
>>>> chart is
>>>> AND'ed with everything else.  A Boolean chart, which can be 
>>>> individually
>>>> negated, has rows that are AND'ed together.  Within each row, there 
>>>> are
>>>> columns that are OR'ed together.
>>>>         
>>> Well, that's how you'd read them, in theory. Yet, if you're a heavy 
>>> user
>>> of the boolean charts you quickly figure that that doesn't apply in
>>> practice. I've filed quite a number of bugs, because the result I got
>>> for `chart 1: A AND B` was different to the result I got for `chart 1:
>>> A; chart 2: B`, even though I thought these both meant (A AND B).
>>> Search.pm does a lot of things, but it doesn't really apply logic.
>>>
>>>     
>>
>> Because Yahoo has been way behind the curve on which Bugzilla to 
>> which we're
>> closest (2.22 !?!), I haven't been able to apply my changes to 
>> Search.pm to
>> the trunk.  If Search.pm is broken, it doesn't need to be.  That's 
>> separate
>> from any UI discussion.
>>
>> Below is my opinion on how the backend part should be changed.  I 
>> don't have
>> any opinion about whether/how the UI should change, but I intuitively
>> believe that is orthogonal to the backend.
>>
>> Recommendation: 2-D Boolean Charts!
>>
>> Right now, the Boolean charts have 1 dimension which implies that the 
>> charts
>> should be ANDed.  All the stuff above the Boolean charts section with 
>> the
>> numeric designation -1.  If I create two more Boolean charts, I AND 
>> together
>> chart -1, chart 0, and chart 1.
>>
>> Suppose we had Boolean charts in two dimensions?  The special chart 
>> would
>> now have coordinate (0, 0).  If a user creates one Boolean chart to 
>> AND with
>> the special chart, it goes at (1,0).  If the Boolean chart should be 
>> OR with
>> the special chart, it goes as (0,1).  Additional Boolean charts are 
>> created
>> as needed.
>>
>> More complicated expressions are possible if the contents of a chart 
>> can be
>> another chart.
>>   
>
> Charts inside charts? To be honest, I'd much prefer it if we did away 
> with this entire new chart thing. If you allow the use of parentheses, 
> and you apply logical precedence to your operators NOT, AND and OR, 
> you don't need any new charts, neither AND nor OR, as you'll be able 
> to express everything within a single chart. I'd much rather formulate 
> the entire query within a single chart, than using multiple charts in 
> multiple dimensions and having to consider nesting charts within 
> charts. But maybe that's just me? As to everything above the boolean 
> charts, I think the entire logic of the advanced search page implies 
> AND with respect to each of the sub-components. This should still 
> apply. Whatever is above the boolean charts, using the current logic, 
> AND the entirety of the one boolean chart. And in my opinion, there 
> should only be one boolean chart, and logic rules should apply.

I guess I should add, that's said with respect to the back-end. I 
believe it would be a lot cleaner if only a single chart was submitted 
to the "query engine", and the "query engine" would do with that single 
chart what it has to do in order to retrieve the result.

If, in the sense of divide-and-conquer, the UI would allow to build 
sub-components of a query (call them charts if you will), that you can 
can negate, conjunct and disjunct with each other, and even nest, then 
that's a different matter. But to me, that's a UI thing. I still think 
it would be a lot cleaner if the back-end was working on a single chart, 
or rather, on a single boolean string.

Cheers,
Bernd

>
> Cheers,
> Bernd
>
>>
>>  
>>>>        
>>>>> * You can't really do arbitrary AND/OR groupings. For example, 
>>>>> there's
>>>>> no way to do this search with the Boolean Charts:
>>>>>
>>>>> (a AND b) OR (c AND d)
>>>>>             
>>>> It is certainly not easy to do with with a Boolean chart, but it's 
>>>> possible!
>>>> However, I don't want to explain DeMorgan's Law to anyone who would 
>>>> then
>>>> need to apply them to a Boolean chart.
>>>>         
>>> I think something has to actually apply logic rules in the first place,
>>> in order for DeMorgan's Law to have any meaning.
>>>
>>>    
>>>> Hopefully I will someday be able to release Yahoo's replacement for 
>>>> the
>>>> Boolean chart, a predicate tree.  The reason we do this is so that 
>>>> we can
>>>> avoid OR'ing stuff together (we do a bunch of UNIONs).  However, it 
>>>> would
>>>> also allow us to perform any arbitrary AND/OR groupings.
>>>>
>>>> Perhaps what is needed is some crazy Javascript thing that allows 
>>>> building
>>>> advanced queries graphically - something that translates the query 
>>>> being
>>>> constructed into a statement of what search criteria are being 
>>>> applied.
>>>> Perhaps what's really needed is a complete overhaul of the advanced 
>>>> search
>>>> UI?
>>>>         
>>> Yes, please! It doesn't have to be graphical, it can just be the input
>>> fields we've come to ummm.... love, but if it were to create a single
>>> statement which represent the actual query to be submitted to the 
>>> "query
>>> engine", then that would be awesome. Then people could just build their
>>> own boolean query generators and simply make sure to submit a valid
>>> boolean query. But maybe I'm just dreaming here? :-)
>>>
>>> Cheers,
>>> Bernd
>>>
>>>    
>>>> I omitted the rest of Max's mail, but I want to chime in that I 
>>>> hate the
>>>> notion of a parentheses button.  We have a number of 
>>>> management-type users
>>>> at Yahoo! who just don't grok operator precedence and the need for
>>>> parentheses.
>>>>
>>>> We're doing a lot of work on UI these days, although I don't know 
>>>> that we've
>>>> talked much about advanced search.  I know, however, that most of 
>>>> our users
>>>> don't really know how to take advantage of its capabilities.  
>>>> There's a lot
>>>> of implicit ANDing going on, and I have fielded any number of 
>>>> questions
>>>> about it.
>>>>
>>>>
>>>> -
>>>> To view or change your list settings, click here:
>>>> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=bgroh@redhat.com>
>>>>         
>>> -
>>> To view or change your list settings, click here:
>>> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dmarshal@yahoo-inc.com>
>>>     
>>
>> -
>> To view or change your list settings, click here:
>> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=bgroh@redhat.com>
>>   
>
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=bgroh@redhat.com>