Boolean Chart Redesign

[Guy Pyrzak]

So I thought I'd chime in and say, UI for boolean charts will basically be
worked on independently of whatever max does with the back end. I started
working on the boolean charts JS version a while back and we stopped
basically because there were plenty of design issues that I personally
wasn't happy with the solution etc. I also had to rewrite the back end logic
of how boolean charts work into JS which was also not so fun. Basically I
stopped working on the JS boolean charts when Max indicated he was going to
redo boolean charts.

But the point is, I'm happy to help work with anyone on UI designs for the
new boolean charts and implement it once the back end is done. We should
probably start a new thread/bug for the new Boolean chart design ideas that
people have. DWM if you have any screenshots or sketches available I'd be
happy to see them. I'm especially interested in hearing about your
interactions with managers since i'm pretty sure developers could figure out
whatever ui we come with.

Also i think for boolean charts requiring JS isn't the end of the world,
it's an advanced capability, but that's my opinion.

Good to see so many folks interested in how the UI would look though so
don't let me chiming in make it sound like these creative are anything bug
welcome, just don't want to distract the "how we rewrite search.pm"
discussion.

-Guy


On Mon, Jul 19, 2010 at 7:52 PM, Max Kanat-Alexander <mkanat at bugzilla.org>wrote:

> On 07/19/2010 05:16 PM, Benjamin Smedberg wrote:
> > I'll note that as an "advanced charts user" there are some things that
> > cannot be adequately expressed even with arbitrary AND/OR groupings.
> > These mainly relate to queries on attachments or flags.
>
>         Yes, the current implementation of Search.pm has serious problems
> with
> one-to-many relationships. I recently wrote a regression test that tests
> every combination of fields and operators for Search.pm, and there are
> literally hundreds of broken combinations. (And if you start counting
> groupings that break under AND/OR, there are probably millions of broken
> combinations.) If you take a look at the log of the "xt MySQL" tinderbox
> on the Bugzilla tinderbox tree, all of the tests marked TODO are somehow
> broken.
>
>        In general, searching attachments and flags does not work nearly as
> well as it should, and that's something that I'm going to be fixing
> regardless of what boolean chart design we end up using. I already have
> a general idea of how I'm going to do the fix, but I have to do a bit
> more refactoring first and then test some things out.
>
> > I would really like some clarity on how limiters such as "attachment is
> > obsolete" and "Flag requestee" and such are applied to attachment, bug
> > flags, and attachment flags.
>
>         Yeah, so would I. :-D
>
>        Once I'm completely done with the Search.pm refactoring that's
> underway, I plan to fully document (in public documentation, not just
> code comments) how it all actually works.
>
> > In addition, it would be really nice if we could have attachment
> > queries, where the results link to particular attachments and list
> > attachment metadata, instead of linking to bugs which you have to open
> > and then look for the attachment which matched.
>
>         Oh, that's an interesting thought. It's a possibility for the
> future.
>
>        -Max
> --
> http://www.everythingsolved.com/
> Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=guy.pyrzak@gmail.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20100719/af5a3b98/attachment.html>