Boolean Chart Redesign

Tue Jul 20 01:42:34 UTC 2010

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.

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>
>   