You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@allura.apache.org by Dave Brondsema <da...@brondsema.net> on 2013/10/31 20:32:28 UTC
a UI for filtering tickets
We'd like to develop a UI for filtering tickets as a simple alternative to using
solr syntax. This should be helpful for those that don't know solr syntax, and
easier than learning it, for the simple cases.
I did a quick in-browser mock of drop-downs for various fields, but it doesn't
look very clean, and it takes up a lot of room: http://screencast.com/t/uUL2VeLybg
Side note: existing elements in that area could be improved:
* move "showing X of Y" to after the tickets, alongside pagination, like we do
on other places
* move "show deleted tickets" to after search help button
* make search text box even a little bigger
Since we probably only would show filter choices for the fields that have their
column shown, I was thinking perhaps we could put the filtering as part of the
column header. This could save space by moving each drop-down filter into a
per-column dialog that is not shown by default. It's also contextually relevant
to associate the fields with the columns. I think this would end up very
similar to the auto-filter feature on most spreadsheets.
That would require more UI work for the dialog and its contents, filter icon in
header, etc. Clicking on the column header currently sorts the column, so we'd
have to see if that still made sense or not. I imagine the filters would append
new clauses to the solr query, but it might get real weird if we don't put in
the extra work to parse a given solr query to know what filtering is active.
https://github.com/evolvingweb/ajax-solr/ might be worth exploring. Also
separating the user-entered query from the filter query would help some but
still would require some parsing. Solr seems to support this concept of 2 query
params, but I haven't used it myself
http://wiki.apache.org/solr/CommonQueryParameters#fq
Thoughts?
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
Re: a UI for filtering tickets
Posted by Wayne Witzel III <ww...@gmail.com>.
I guess my argument would be the average joe doesn’t really care or want to use the full power of solr. And providing a more intuitive UX that is familiar from every other site that does filtering hits a broader audience and I think has more overall value as a feature in Allura than a form view of solr options.
--
Wayne Witzel III (@wwitzel3)
wayne@pieceofpy.com
http://pieceofpy.com
On Tuesday, November 05, 2013 at 15:30 , Dave Brondsema wrote:
> The nerd in me likes that (tangent: I started writing one in Java a decade ago
> http://beej.sourceforge.net/examples.html) But I'm not sure it's easy enough
> for an average joe. And that's the goal of this UI - advanced users can still
> use the solr text search. Also -- to be clear, the mock I provided was my first
> pass and I don't like it any more, I prefer a column-header based dialog
> filtering each column.
>
> aside - agreed. We might even be able to do this with the column filtering.
> It'd help teach people how the solr query is constructed so they can tweak it.
>
> On 11/5/13 11:05 AM, Chris Tsai wrote:
> > I’d rather see something like Trac’s custom query builder, eg. http://trac.edgewall.org/query
> >
> > Maybe it doesn’t need to be quite as robust to start, but a few things I like that Trac does that’s different from how I interpret the mock are (1) it only shows elements that are actually part of the filter, and (2) clear delineation between ANDs and ORs.
> >
> > (aside) A "nice to have” for down the road would be to build a visible text representation of the search as you add filters with the UI.
> >
> > --
> > Chris Tsai
> > SourceForge.net (http://SourceForge.net) Support
> > sfnet_ops@slashdotmedia.com (mailto:sfnet_ops@slashdotmedia.com)
> >
> > ctsai-sf on irc.freenode.net (http://irc.freenode.net)
> >
> >
> > On Tuesday, November 5, 2013 at 10:52 AM, Wayne Witzel III wrote:
> >
> > > The rest of my email got cut off and I don’t feel like typing it again .. but +1 to approach with more UI work.
> > >
> > > --
> > > Wayne Witzel III (@wwitzel3)
> > > wayne@pieceofpy.com (mailto:wayne@pieceofpy.com)
> > > http://pieceofpy.com
> > >
> > >
> > > On Tuesday, November 05, 2013 at 10:51 , Wayne Witzel III wrote:
> > >
> > > > +1 to the idea of an easy to use filtering interface.
> > > >
> > > > The example UI is a little confusing, with the search input above the filtering options, it also appears you have to re-submit the search after you add filtering options.
> > > > Looking at other sites, I see a common pattern for simple filtering (which compliments robust searching)
> > > >
> > > > - Obvious that a filter is being used.
> > > > - Easy to clear filters
> > > > - Single click to apply a filter
> > > >
> > > > I see the example UI as just creating a UI around the solr syntax, but I think creating a more minimal UI and incorporating it in to / just below above the ticket listing header (like the Advanced filtering for browsing sf.net (http://sf.net)) is a better approach. It would be intuitive to the user and could auto-populate with only values that exist to be filtered. Avoiding typos in a label filter for example.
> > > >
> > > > --
> > > > Wayne Witzel III (@wwitzel3)
> > > > wayne@pieceofpy.com (mailto:wayne@pieceofpy.com)
> > > > http://pieceofpy.com
> > > >
> > > >
> > > > On Tuesday, November 05, 2013 at 09:57 , Dave Brondsema wrote:
> > > >
> > > > > Any opinions on this before implementation begins?
> > > > >
> > > > > On 10/31/13 3:32 PM, Dave Brondsema wrote:
> > > > > > We'd like to develop a UI for filtering tickets as a simple alternative to using
> > > > > > solr syntax. This should be helpful for those that don't know solr syntax, and
> > > > > > easier than learning it, for the simple cases.
> > > > > >
> > > > > > I did a quick in-browser mock of drop-downs for various fields, but it doesn't
> > > > > > look very clean, and it takes up a lot of room: http://screencast.com/t/uUL2VeLybg
> > > > > >
> > > > > > Side note: existing elements in that area could be improved:
> > > > > > * move "showing X of Y" to after the tickets, alongside pagination, like we do
> > > > > > on other places
> > > > > > * move "show deleted tickets" to after search help button
> > > > > > * make search text box even a little bigger
> > > > > >
> > > > > > Since we probably only would show filter choices for the fields that have their
> > > > > > column shown, I was thinking perhaps we could put the filtering as part of the
> > > > > > column header. This could save space by moving each drop-down filter into a
> > > > > > per-column dialog that is not shown by default. It's also contextually relevant
> > > > > > to associate the fields with the columns. I think this would end up very
> > > > > > similar to the auto-filter feature on most spreadsheets.
> > > > > >
> > > > > > That would require more UI work for the dialog and its contents, filter icon in
> > > > > > header, etc. Clicking on the column header currently sorts the column, so we'd
> > > > > > have to see if that still made sense or not. I imagine the filters would append
> > > > > > new clauses to the solr query, but it might get real weird if we don't put in
> > > > > > the extra work to parse a given solr query to know what filtering is active.
> > > > > > https://github.com/evolvingweb/ajax-solr/ might be worth exploring. Also
> > > > > > separating the user-entered query from the filter query would help some but
> > > > > > still would require some parsing. Solr seems to support this concept of 2 query
> > > > > > params, but I haven't used it myself
> > > > > > http://wiki.apache.org/solr/CommonQueryParameters#fq
> > > > > >
> > > > > > Thoughts?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Dave Brondsema : dave@brondsema.net (mailto:dave@brondsema.net)
> > > > > http://www.brondsema.net : personal
> > > > > http://www.splike.com : programming
> > > > > <><
> > > >
> > >
> >
>
>
>
>
>
> --
> Dave Brondsema : dave@brondsema.net (mailto:dave@brondsema.net)
> http://www.brondsema.net : personal
> http://www.splike.com : programming
> <><
Re: a UI for filtering tickets
Posted by Dave Brondsema <da...@brondsema.net>.
The nerd in me likes that (tangent: I started writing one in Java a decade ago
http://beej.sourceforge.net/examples.html) But I'm not sure it's easy enough
for an average joe. And that's the goal of this UI - advanced users can still
use the solr text search. Also -- to be clear, the mock I provided was my first
pass and I don't like it any more, I prefer a column-header based dialog
filtering each column.
aside - agreed. We might even be able to do this with the column filtering.
It'd help teach people how the solr query is constructed so they can tweak it.
On 11/5/13 11:05 AM, Chris Tsai wrote:
> I’d rather see something like Trac’s custom query builder, eg. http://trac.edgewall.org/query
>
> Maybe it doesn’t need to be quite as robust to start, but a few things I like that Trac does that’s different from how I interpret the mock are (1) it only shows elements that are actually part of the filter, and (2) clear delineation between ANDs and ORs.
>
> (aside) A "nice to have” for down the road would be to build a visible text representation of the search as you add filters with the UI.
>
> --
> Chris Tsai
> SourceForge.net Support
> sfnet_ops@slashdotmedia.com
>
> ctsai-sf on irc.freenode.net
>
>
> On Tuesday, November 5, 2013 at 10:52 AM, Wayne Witzel III wrote:
>
>> The rest of my email got cut off and I don’t feel like typing it again .. but +1 to approach with more UI work.
>>
>> --
>> Wayne Witzel III (@wwitzel3)
>> wayne@pieceofpy.com (mailto:wayne@pieceofpy.com)
>> http://pieceofpy.com
>>
>>
>> On Tuesday, November 05, 2013 at 10:51 , Wayne Witzel III wrote:
>>
>>> +1 to the idea of an easy to use filtering interface.
>>>
>>> The example UI is a little confusing, with the search input above the filtering options, it also appears you have to re-submit the search after you add filtering options.
>>> Looking at other sites, I see a common pattern for simple filtering (which compliments robust searching)
>>>
>>> - Obvious that a filter is being used.
>>> - Easy to clear filters
>>> - Single click to apply a filter
>>>
>>> I see the example UI as just creating a UI around the solr syntax, but I think creating a more minimal UI and incorporating it in to / just below above the ticket listing header (like the Advanced filtering for browsing sf.net (http://sf.net)) is a better approach. It would be intuitive to the user and could auto-populate with only values that exist to be filtered. Avoiding typos in a label filter for example.
>>>
>>> --
>>> Wayne Witzel III (@wwitzel3)
>>> wayne@pieceofpy.com (mailto:wayne@pieceofpy.com)
>>> http://pieceofpy.com
>>>
>>>
>>> On Tuesday, November 05, 2013 at 09:57 , Dave Brondsema wrote:
>>>
>>>> Any opinions on this before implementation begins?
>>>>
>>>> On 10/31/13 3:32 PM, Dave Brondsema wrote:
>>>>> We'd like to develop a UI for filtering tickets as a simple alternative to using
>>>>> solr syntax. This should be helpful for those that don't know solr syntax, and
>>>>> easier than learning it, for the simple cases.
>>>>>
>>>>> I did a quick in-browser mock of drop-downs for various fields, but it doesn't
>>>>> look very clean, and it takes up a lot of room: http://screencast.com/t/uUL2VeLybg
>>>>>
>>>>> Side note: existing elements in that area could be improved:
>>>>> * move "showing X of Y" to after the tickets, alongside pagination, like we do
>>>>> on other places
>>>>> * move "show deleted tickets" to after search help button
>>>>> * make search text box even a little bigger
>>>>>
>>>>> Since we probably only would show filter choices for the fields that have their
>>>>> column shown, I was thinking perhaps we could put the filtering as part of the
>>>>> column header. This could save space by moving each drop-down filter into a
>>>>> per-column dialog that is not shown by default. It's also contextually relevant
>>>>> to associate the fields with the columns. I think this would end up very
>>>>> similar to the auto-filter feature on most spreadsheets.
>>>>>
>>>>> That would require more UI work for the dialog and its contents, filter icon in
>>>>> header, etc. Clicking on the column header currently sorts the column, so we'd
>>>>> have to see if that still made sense or not. I imagine the filters would append
>>>>> new clauses to the solr query, but it might get real weird if we don't put in
>>>>> the extra work to parse a given solr query to know what filtering is active.
>>>>> https://github.com/evolvingweb/ajax-solr/ might be worth exploring. Also
>>>>> separating the user-entered query from the filter query would help some but
>>>>> still would require some parsing. Solr seems to support this concept of 2 query
>>>>> params, but I haven't used it myself
>>>>> http://wiki.apache.org/solr/CommonQueryParameters#fq
>>>>>
>>>>> Thoughts?
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Dave Brondsema : dave@brondsema.net (mailto:dave@brondsema.net)
>>>> http://www.brondsema.net : personal
>>>> http://www.splike.com : programming
>>>> <><
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
Re: a UI for filtering tickets
Posted by Chris Tsai <ct...@slashdotmedia.com>.
I’d rather see something like Trac’s custom query builder, eg. http://trac.edgewall.org/query
Maybe it doesn’t need to be quite as robust to start, but a few things I like that Trac does that’s different from how I interpret the mock are (1) it only shows elements that are actually part of the filter, and (2) clear delineation between ANDs and ORs.
(aside) A "nice to have” for down the road would be to build a visible text representation of the search as you add filters with the UI.
--
Chris Tsai
SourceForge.net Support
sfnet_ops@slashdotmedia.com
ctsai-sf on irc.freenode.net
On Tuesday, November 5, 2013 at 10:52 AM, Wayne Witzel III wrote:
> The rest of my email got cut off and I don’t feel like typing it again .. but +1 to approach with more UI work.
>
> --
> Wayne Witzel III (@wwitzel3)
> wayne@pieceofpy.com (mailto:wayne@pieceofpy.com)
> http://pieceofpy.com
>
>
> On Tuesday, November 05, 2013 at 10:51 , Wayne Witzel III wrote:
>
> > +1 to the idea of an easy to use filtering interface.
> >
> > The example UI is a little confusing, with the search input above the filtering options, it also appears you have to re-submit the search after you add filtering options.
> > Looking at other sites, I see a common pattern for simple filtering (which compliments robust searching)
> >
> > - Obvious that a filter is being used.
> > - Easy to clear filters
> > - Single click to apply a filter
> >
> > I see the example UI as just creating a UI around the solr syntax, but I think creating a more minimal UI and incorporating it in to / just below above the ticket listing header (like the Advanced filtering for browsing sf.net (http://sf.net)) is a better approach. It would be intuitive to the user and could auto-populate with only values that exist to be filtered. Avoiding typos in a label filter for example.
> >
> > --
> > Wayne Witzel III (@wwitzel3)
> > wayne@pieceofpy.com (mailto:wayne@pieceofpy.com)
> > http://pieceofpy.com
> >
> >
> > On Tuesday, November 05, 2013 at 09:57 , Dave Brondsema wrote:
> >
> > > Any opinions on this before implementation begins?
> > >
> > > On 10/31/13 3:32 PM, Dave Brondsema wrote:
> > > > We'd like to develop a UI for filtering tickets as a simple alternative to using
> > > > solr syntax. This should be helpful for those that don't know solr syntax, and
> > > > easier than learning it, for the simple cases.
> > > >
> > > > I did a quick in-browser mock of drop-downs for various fields, but it doesn't
> > > > look very clean, and it takes up a lot of room: http://screencast.com/t/uUL2VeLybg
> > > >
> > > > Side note: existing elements in that area could be improved:
> > > > * move "showing X of Y" to after the tickets, alongside pagination, like we do
> > > > on other places
> > > > * move "show deleted tickets" to after search help button
> > > > * make search text box even a little bigger
> > > >
> > > > Since we probably only would show filter choices for the fields that have their
> > > > column shown, I was thinking perhaps we could put the filtering as part of the
> > > > column header. This could save space by moving each drop-down filter into a
> > > > per-column dialog that is not shown by default. It's also contextually relevant
> > > > to associate the fields with the columns. I think this would end up very
> > > > similar to the auto-filter feature on most spreadsheets.
> > > >
> > > > That would require more UI work for the dialog and its contents, filter icon in
> > > > header, etc. Clicking on the column header currently sorts the column, so we'd
> > > > have to see if that still made sense or not. I imagine the filters would append
> > > > new clauses to the solr query, but it might get real weird if we don't put in
> > > > the extra work to parse a given solr query to know what filtering is active.
> > > > https://github.com/evolvingweb/ajax-solr/ might be worth exploring. Also
> > > > separating the user-entered query from the filter query would help some but
> > > > still would require some parsing. Solr seems to support this concept of 2 query
> > > > params, but I haven't used it myself
> > > > http://wiki.apache.org/solr/CommonQueryParameters#fq
> > > >
> > > > Thoughts?
> > > >
> > >
> > >
> > >
> > >
> > > --
> > > Dave Brondsema : dave@brondsema.net (mailto:dave@brondsema.net)
> > > http://www.brondsema.net : personal
> > > http://www.splike.com : programming
> > > <><
> > >
> >
> >
> >
>
>
>
Re: a UI for filtering tickets
Posted by Dave Brondsema <da...@brondsema.net>.
On 11/8/13 6:12 AM, Igor Bondarenko wrote:
> I've started work on this. First, I want to develop UI and then work from
> that. I'm considering using jQuery multiselect widget to implement
> filtering for columns with a limited choice values. You can see examples of
> this widget here:
> http://www.erichynds.com/examples/jquery-ui-multiselect-widget/demos/#basic
> It's functionality is pretty similar to that Google Spreadsheet
> filters
> provide.
>
Looks great to me.
> I see two ways to integrate this into table headers:
>
> 1. Remove current headers (and ability to sort by clicking on it) and stick
> multiselect instead with column name as displayed text.
>
> 2. Let headers remain as is (and with sorting ability), and customize
> multiselect to display only small icon to open the filter.
>
> (2) seems more user-friendly, but it can require more work to customize
> widget styles.
>
> What do you think about that?
I think the multiselect div will need more width than a column, so replacing the
column headers won't work. 2 sounds pretty good. Another option would be that
clicking on the header opens a new div which contains both a sort up/down link
and also the multiselect. Then you don't have to add an icon into the header
(space is very tight already, when you have many columns).
If we can avoid customizing the multiselect js & css, but just override things
and hook into events, that'll be best. I don't think it's a legal problem to
modify an MIT dependency, but it'll be simplest if we don't :)
>
> Another issue is licensing. I see GPL and MIT licenses in widget's repo (
> https://github.com/ehynds/jquery-ui-multiselect-widget). I suspect that
> MIT should be compatible to with Allura. Am I right?
Yep. Make sure you add a reference to it in our top-level LICENSE file and
Allura/LICENSE (we have both for the day when we start shipping each package on
pypi). Those files have a list of jquery MIT-licensed extensions that you can
add to. rat-excludes.txt will need to be updated also.
>
>
>
> On Thu, Nov 7, 2013 at 9:21 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
>> +1
>> On Nov 5, 2013, at 10:52 AM, Wayne Witzel III <ww...@gmail.com> wrote:
>>
>>> The rest of my email got cut off and I don’t feel like typing it again
>> .. but +1 to approach with more UI work.
>>>
>>> --
>>> Wayne Witzel III (@wwitzel3)
>>> wayne@pieceofpy.com
>>> http://pieceofpy.com
>>>
>>>
>>> On Tuesday, November 05, 2013 at 10:51 , Wayne Witzel III wrote:
>>>
>>>> +1 to the idea of an easy to use filtering interface.
>>>>
>>>> The example UI is a little confusing, with the search input above the
>> filtering options, it also appears you have to re-submit the search after
>> you add filtering options.
>>>> Looking at other sites, I see a common pattern for simple filtering
>> (which compliments robust searching)
>>>>
>>>> - Obvious that a filter is being used.
>>>> - Easy to clear filters
>>>> - Single click to apply a filter
>>>>
>>>> I see the example UI as just creating a UI around the solr syntax, but
>> I think creating a more minimal UI and incorporating it in to / just below
>> above the ticket listing header (like the Advanced filtering for browsing
>> sf.net (http://sf.net)) is a better approach. It would be intuitive to
>> the user and could auto-populate with only values that exist to be
>> filtered. Avoiding typos in a label filter for example.
>>>>
>>>> --
>>>> Wayne Witzel III (@wwitzel3)
>>>> wayne@pieceofpy.com (mailto:wayne@pieceofpy.com)
>>>> http://pieceofpy.com
>>>>
>>>>
>>>> On Tuesday, November 05, 2013 at 09:57 , Dave Brondsema wrote:
>>>>
>>>>> Any opinions on this before implementation begins?
>>>>>
>>>>> On 10/31/13 3:32 PM, Dave Brondsema wrote:
>>>>>> We'd like to develop a UI for filtering tickets as a simple
>> alternative to using
>>>>>> solr syntax. This should be helpful for those that don't know solr
>> syntax, and
>>>>>> easier than learning it, for the simple cases.
>>>>>>
>>>>>> I did a quick in-browser mock of drop-downs for various fields, but
>> it doesn't
>>>>>> look very clean, and it takes up a lot of room:
>> http://screencast.com/t/uUL2VeLybg
>>>>>>
>>>>>> Side note: existing elements in that area could be improved:
>>>>>> * move "showing X of Y" to after the tickets, alongside pagination,
>> like we do
>>>>>> on other places
>>>>>> * move "show deleted tickets" to after search help button
>>>>>> * make search text box even a little bigger
>>>>>>
>>>>>> Since we probably only would show filter choices for the fields that
>> have their
>>>>>> column shown, I was thinking perhaps we could put the filtering as
>> part of the
>>>>>> column header. This could save space by moving each drop-down filter
>> into a
>>>>>> per-column dialog that is not shown by default. It's also
>> contextually relevant
>>>>>> to associate the fields with the columns. I think this would end up
>> very
>>>>>> similar to the auto-filter feature on most spreadsheets.
>>>>>>
>>>>>> That would require more UI work for the dialog and its contents,
>> filter icon in
>>>>>> header, etc. Clicking on the column header currently sorts the
>> column, so we'd
>>>>>> have to see if that still made sense or not. I imagine the filters
>> would append
>>>>>> new clauses to the solr query, but it might get real weird if we
>> don't put in
>>>>>> the extra work to parse a given solr query to know what filtering is
>> active.
>>>>>> https://github.com/evolvingweb/ajax-solr/ might be worth exploring.
>> Also
>>>>>> separating the user-entered query from the filter query would help
>> some but
>>>>>> still would require some parsing. Solr seems to support this concept
>> of 2 query
>>>>>> params, but I haven't used it myself
>>>>>> http://wiki.apache.org/solr/CommonQueryParameters#fq
>>>>>>
>>>>>> Thoughts?
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Dave Brondsema : dave@brondsema.net (mailto:dave@brondsema.net)
>>>>> http://www.brondsema.net : personal
>>>>> http://www.splike.com : programming
>>>>> <><
>>>>
>>>
>>>
>>>
>>
>>
>
>
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
Re: a UI for filtering tickets
Posted by Igor Bondarenko <je...@gmail.com>.
I've started work on this. First, I want to develop UI and then work from
that. I'm considering using jQuery multiselect widget to implement
filtering for columns with a limited choice values. You can see examples of
this widget here:
http://www.erichynds.com/examples/jquery-ui-multiselect-widget/demos/#basic
It's functionality is pretty similar to that Google Spreadsheet
filters
provide.
I see two ways to integrate this into table headers:
1. Remove current headers (and ability to sort by clicking on it) and stick
multiselect instead with column name as displayed text.
2. Let headers remain as is (and with sorting ability), and customize
multiselect to display only small icon to open the filter.
(2) seems more user-friendly, but it can require more work to customize
widget styles.
What do you think about that?
Another issue is licensing. I see GPL and MIT licenses in widget's repo (
https://github.com/ehynds/jquery-ui-multiselect-widget). I suspect that
MIT should be compatible to with Allura. Am I right?
On Thu, Nov 7, 2013 at 9:21 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> +1
> On Nov 5, 2013, at 10:52 AM, Wayne Witzel III <ww...@gmail.com> wrote:
>
> > The rest of my email got cut off and I don’t feel like typing it again
> .. but +1 to approach with more UI work.
> >
> > --
> > Wayne Witzel III (@wwitzel3)
> > wayne@pieceofpy.com
> > http://pieceofpy.com
> >
> >
> > On Tuesday, November 05, 2013 at 10:51 , Wayne Witzel III wrote:
> >
> >> +1 to the idea of an easy to use filtering interface.
> >>
> >> The example UI is a little confusing, with the search input above the
> filtering options, it also appears you have to re-submit the search after
> you add filtering options.
> >> Looking at other sites, I see a common pattern for simple filtering
> (which compliments robust searching)
> >>
> >> - Obvious that a filter is being used.
> >> - Easy to clear filters
> >> - Single click to apply a filter
> >>
> >> I see the example UI as just creating a UI around the solr syntax, but
> I think creating a more minimal UI and incorporating it in to / just below
> above the ticket listing header (like the Advanced filtering for browsing
> sf.net (http://sf.net)) is a better approach. It would be intuitive to
> the user and could auto-populate with only values that exist to be
> filtered. Avoiding typos in a label filter for example.
> >>
> >> --
> >> Wayne Witzel III (@wwitzel3)
> >> wayne@pieceofpy.com (mailto:wayne@pieceofpy.com)
> >> http://pieceofpy.com
> >>
> >>
> >> On Tuesday, November 05, 2013 at 09:57 , Dave Brondsema wrote:
> >>
> >>> Any opinions on this before implementation begins?
> >>>
> >>> On 10/31/13 3:32 PM, Dave Brondsema wrote:
> >>>> We'd like to develop a UI for filtering tickets as a simple
> alternative to using
> >>>> solr syntax. This should be helpful for those that don't know solr
> syntax, and
> >>>> easier than learning it, for the simple cases.
> >>>>
> >>>> I did a quick in-browser mock of drop-downs for various fields, but
> it doesn't
> >>>> look very clean, and it takes up a lot of room:
> http://screencast.com/t/uUL2VeLybg
> >>>>
> >>>> Side note: existing elements in that area could be improved:
> >>>> * move "showing X of Y" to after the tickets, alongside pagination,
> like we do
> >>>> on other places
> >>>> * move "show deleted tickets" to after search help button
> >>>> * make search text box even a little bigger
> >>>>
> >>>> Since we probably only would show filter choices for the fields that
> have their
> >>>> column shown, I was thinking perhaps we could put the filtering as
> part of the
> >>>> column header. This could save space by moving each drop-down filter
> into a
> >>>> per-column dialog that is not shown by default. It's also
> contextually relevant
> >>>> to associate the fields with the columns. I think this would end up
> very
> >>>> similar to the auto-filter feature on most spreadsheets.
> >>>>
> >>>> That would require more UI work for the dialog and its contents,
> filter icon in
> >>>> header, etc. Clicking on the column header currently sorts the
> column, so we'd
> >>>> have to see if that still made sense or not. I imagine the filters
> would append
> >>>> new clauses to the solr query, but it might get real weird if we
> don't put in
> >>>> the extra work to parse a given solr query to know what filtering is
> active.
> >>>> https://github.com/evolvingweb/ajax-solr/ might be worth exploring.
> Also
> >>>> separating the user-entered query from the filter query would help
> some but
> >>>> still would require some parsing. Solr seems to support this concept
> of 2 query
> >>>> params, but I haven't used it myself
> >>>> http://wiki.apache.org/solr/CommonQueryParameters#fq
> >>>>
> >>>> Thoughts?
> >>>
> >>>
> >>>
> >>> --
> >>> Dave Brondsema : dave@brondsema.net (mailto:dave@brondsema.net)
> >>> http://www.brondsema.net : personal
> >>> http://www.splike.com : programming
> >>> <><
> >>
> >
> >
> >
>
>
--
Igor Bondarenko
Re: a UI for filtering tickets
Posted by Jim Jagielski <ji...@jaguNET.com>.
+1
On Nov 5, 2013, at 10:52 AM, Wayne Witzel III <ww...@gmail.com> wrote:
> The rest of my email got cut off and I don’t feel like typing it again .. but +1 to approach with more UI work.
>
> --
> Wayne Witzel III (@wwitzel3)
> wayne@pieceofpy.com
> http://pieceofpy.com
>
>
> On Tuesday, November 05, 2013 at 10:51 , Wayne Witzel III wrote:
>
>> +1 to the idea of an easy to use filtering interface.
>>
>> The example UI is a little confusing, with the search input above the filtering options, it also appears you have to re-submit the search after you add filtering options.
>> Looking at other sites, I see a common pattern for simple filtering (which compliments robust searching)
>>
>> - Obvious that a filter is being used.
>> - Easy to clear filters
>> - Single click to apply a filter
>>
>> I see the example UI as just creating a UI around the solr syntax, but I think creating a more minimal UI and incorporating it in to / just below above the ticket listing header (like the Advanced filtering for browsing sf.net (http://sf.net)) is a better approach. It would be intuitive to the user and could auto-populate with only values that exist to be filtered. Avoiding typos in a label filter for example.
>>
>> --
>> Wayne Witzel III (@wwitzel3)
>> wayne@pieceofpy.com (mailto:wayne@pieceofpy.com)
>> http://pieceofpy.com
>>
>>
>> On Tuesday, November 05, 2013 at 09:57 , Dave Brondsema wrote:
>>
>>> Any opinions on this before implementation begins?
>>>
>>> On 10/31/13 3:32 PM, Dave Brondsema wrote:
>>>> We'd like to develop a UI for filtering tickets as a simple alternative to using
>>>> solr syntax. This should be helpful for those that don't know solr syntax, and
>>>> easier than learning it, for the simple cases.
>>>>
>>>> I did a quick in-browser mock of drop-downs for various fields, but it doesn't
>>>> look very clean, and it takes up a lot of room: http://screencast.com/t/uUL2VeLybg
>>>>
>>>> Side note: existing elements in that area could be improved:
>>>> * move "showing X of Y" to after the tickets, alongside pagination, like we do
>>>> on other places
>>>> * move "show deleted tickets" to after search help button
>>>> * make search text box even a little bigger
>>>>
>>>> Since we probably only would show filter choices for the fields that have their
>>>> column shown, I was thinking perhaps we could put the filtering as part of the
>>>> column header. This could save space by moving each drop-down filter into a
>>>> per-column dialog that is not shown by default. It's also contextually relevant
>>>> to associate the fields with the columns. I think this would end up very
>>>> similar to the auto-filter feature on most spreadsheets.
>>>>
>>>> That would require more UI work for the dialog and its contents, filter icon in
>>>> header, etc. Clicking on the column header currently sorts the column, so we'd
>>>> have to see if that still made sense or not. I imagine the filters would append
>>>> new clauses to the solr query, but it might get real weird if we don't put in
>>>> the extra work to parse a given solr query to know what filtering is active.
>>>> https://github.com/evolvingweb/ajax-solr/ might be worth exploring. Also
>>>> separating the user-entered query from the filter query would help some but
>>>> still would require some parsing. Solr seems to support this concept of 2 query
>>>> params, but I haven't used it myself
>>>> http://wiki.apache.org/solr/CommonQueryParameters#fq
>>>>
>>>> Thoughts?
>>>
>>>
>>>
>>> --
>>> Dave Brondsema : dave@brondsema.net (mailto:dave@brondsema.net)
>>> http://www.brondsema.net : personal
>>> http://www.splike.com : programming
>>> <><
>>
>
>
>
Re: a UI for filtering tickets
Posted by Wayne Witzel III <ww...@gmail.com>.
The rest of my email got cut off and I don’t feel like typing it again .. but +1 to approach with more UI work.
--
Wayne Witzel III (@wwitzel3)
wayne@pieceofpy.com
http://pieceofpy.com
On Tuesday, November 05, 2013 at 10:51 , Wayne Witzel III wrote:
> +1 to the idea of an easy to use filtering interface.
>
> The example UI is a little confusing, with the search input above the filtering options, it also appears you have to re-submit the search after you add filtering options.
> Looking at other sites, I see a common pattern for simple filtering (which compliments robust searching)
>
> - Obvious that a filter is being used.
> - Easy to clear filters
> - Single click to apply a filter
>
> I see the example UI as just creating a UI around the solr syntax, but I think creating a more minimal UI and incorporating it in to / just below above the ticket listing header (like the Advanced filtering for browsing sf.net (http://sf.net)) is a better approach. It would be intuitive to the user and could auto-populate with only values that exist to be filtered. Avoiding typos in a label filter for example.
>
> --
> Wayne Witzel III (@wwitzel3)
> wayne@pieceofpy.com (mailto:wayne@pieceofpy.com)
> http://pieceofpy.com
>
>
> On Tuesday, November 05, 2013 at 09:57 , Dave Brondsema wrote:
>
> > Any opinions on this before implementation begins?
> >
> > On 10/31/13 3:32 PM, Dave Brondsema wrote:
> > > We'd like to develop a UI for filtering tickets as a simple alternative to using
> > > solr syntax. This should be helpful for those that don't know solr syntax, and
> > > easier than learning it, for the simple cases.
> > >
> > > I did a quick in-browser mock of drop-downs for various fields, but it doesn't
> > > look very clean, and it takes up a lot of room: http://screencast.com/t/uUL2VeLybg
> > >
> > > Side note: existing elements in that area could be improved:
> > > * move "showing X of Y" to after the tickets, alongside pagination, like we do
> > > on other places
> > > * move "show deleted tickets" to after search help button
> > > * make search text box even a little bigger
> > >
> > > Since we probably only would show filter choices for the fields that have their
> > > column shown, I was thinking perhaps we could put the filtering as part of the
> > > column header. This could save space by moving each drop-down filter into a
> > > per-column dialog that is not shown by default. It's also contextually relevant
> > > to associate the fields with the columns. I think this would end up very
> > > similar to the auto-filter feature on most spreadsheets.
> > >
> > > That would require more UI work for the dialog and its contents, filter icon in
> > > header, etc. Clicking on the column header currently sorts the column, so we'd
> > > have to see if that still made sense or not. I imagine the filters would append
> > > new clauses to the solr query, but it might get real weird if we don't put in
> > > the extra work to parse a given solr query to know what filtering is active.
> > > https://github.com/evolvingweb/ajax-solr/ might be worth exploring. Also
> > > separating the user-entered query from the filter query would help some but
> > > still would require some parsing. Solr seems to support this concept of 2 query
> > > params, but I haven't used it myself
> > > http://wiki.apache.org/solr/CommonQueryParameters#fq
> > >
> > > Thoughts?
> >
> >
> >
> > --
> > Dave Brondsema : dave@brondsema.net (mailto:dave@brondsema.net)
> > http://www.brondsema.net : personal
> > http://www.splike.com : programming
> > <><
>
Re: a UI for filtering tickets
Posted by Wayne Witzel III <ww...@gmail.com>.
+1 to the idea of an easy to use filtering interface.
The example UI is a little confusing, with the search input above the filtering options, it also appears you have to re-submit the search after you add filtering options.
Looking at other sites, I see a common pattern for simple filtering (which compliments robust searching)
- Obvious that a filter is being used.
- Easy to clear filters
- Single click to apply a filter
I see the example UI as just creating a UI around the solr syntax, but I think creating a more minimal UI and incorporating it in to / just below above the ticket listing header (like the Advanced filtering for browsing sf.net) is a better approach. It would be intuitive to the user and could auto-populate with only values that exist to be filtered. Avoiding typos in a label filter for example.
--
Wayne Witzel III (@wwitzel3)
wayne@pieceofpy.com
http://pieceofpy.com
On Tuesday, November 05, 2013 at 09:57 , Dave Brondsema wrote:
> Any opinions on this before implementation begins?
>
> On 10/31/13 3:32 PM, Dave Brondsema wrote:
> > We'd like to develop a UI for filtering tickets as a simple alternative to using
> > solr syntax. This should be helpful for those that don't know solr syntax, and
> > easier than learning it, for the simple cases.
> >
> > I did a quick in-browser mock of drop-downs for various fields, but it doesn't
> > look very clean, and it takes up a lot of room: http://screencast.com/t/uUL2VeLybg
> >
> > Side note: existing elements in that area could be improved:
> > * move "showing X of Y" to after the tickets, alongside pagination, like we do
> > on other places
> > * move "show deleted tickets" to after search help button
> > * make search text box even a little bigger
> >
> > Since we probably only would show filter choices for the fields that have their
> > column shown, I was thinking perhaps we could put the filtering as part of the
> > column header. This could save space by moving each drop-down filter into a
> > per-column dialog that is not shown by default. It's also contextually relevant
> > to associate the fields with the columns. I think this would end up very
> > similar to the auto-filter feature on most spreadsheets.
> >
> > That would require more UI work for the dialog and its contents, filter icon in
> > header, etc. Clicking on the column header currently sorts the column, so we'd
> > have to see if that still made sense or not. I imagine the filters would append
> > new clauses to the solr query, but it might get real weird if we don't put in
> > the extra work to parse a given solr query to know what filtering is active.
> > https://github.com/evolvingweb/ajax-solr/ might be worth exploring. Also
> > separating the user-entered query from the filter query would help some but
> > still would require some parsing. Solr seems to support this concept of 2 query
> > params, but I haven't used it myself
> > http://wiki.apache.org/solr/CommonQueryParameters#fq
> >
> > Thoughts?
>
>
>
> --
> Dave Brondsema : dave@brondsema.net (mailto:dave@brondsema.net)
> http://www.brondsema.net : personal
> http://www.splike.com : programming
> <><
Re: a UI for filtering tickets
Posted by Dave Brondsema <da...@brondsema.net>.
Any opinions on this before implementation begins?
On 10/31/13 3:32 PM, Dave Brondsema wrote:
> We'd like to develop a UI for filtering tickets as a simple alternative to using
> solr syntax. This should be helpful for those that don't know solr syntax, and
> easier than learning it, for the simple cases.
>
> I did a quick in-browser mock of drop-downs for various fields, but it doesn't
> look very clean, and it takes up a lot of room: http://screencast.com/t/uUL2VeLybg
>
> Side note: existing elements in that area could be improved:
> * move "showing X of Y" to after the tickets, alongside pagination, like we do
> on other places
> * move "show deleted tickets" to after search help button
> * make search text box even a little bigger
>
> Since we probably only would show filter choices for the fields that have their
> column shown, I was thinking perhaps we could put the filtering as part of the
> column header. This could save space by moving each drop-down filter into a
> per-column dialog that is not shown by default. It's also contextually relevant
> to associate the fields with the columns. I think this would end up very
> similar to the auto-filter feature on most spreadsheets.
>
> That would require more UI work for the dialog and its contents, filter icon in
> header, etc. Clicking on the column header currently sorts the column, so we'd
> have to see if that still made sense or not. I imagine the filters would append
> new clauses to the solr query, but it might get real weird if we don't put in
> the extra work to parse a given solr query to know what filtering is active.
> https://github.com/evolvingweb/ajax-solr/ might be worth exploring. Also
> separating the user-entered query from the filter query would help some but
> still would require some parsing. Solr seems to support this concept of 2 query
> params, but I haven't used it myself
> http://wiki.apache.org/solr/CommonQueryParameters#fq
>
> Thoughts?
>
>
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
Re: a UI for filtering tickets
Posted by Daniel Hinojosa <dh...@slashdotmedia.com>.
+1
On Thu, Oct 31, 2013 at 12:32 PM, Dave Brondsema <da...@brondsema.net> wrote:
> We'd like to develop a UI for filtering tickets as a simple alternative to
> using
> solr syntax. This should be helpful for those that don't know solr
> syntax, and
> easier than learning it, for the simple cases.
>
> I did a quick in-browser mock of drop-downs for various fields, but it
> doesn't
> look very clean, and it takes up a lot of room:
> http://screencast.com/t/uUL2VeLybg
>
> Side note: existing elements in that area could be improved:
> * move "showing X of Y" to after the tickets, alongside pagination, like
> we do
> on other places
> * move "show deleted tickets" to after search help button
> * make search text box even a little bigger
>
> Since we probably only would show filter choices for the fields that have
> their
> column shown, I was thinking perhaps we could put the filtering as part of
> the
> column header. This could save space by moving each drop-down filter into
> a
> per-column dialog that is not shown by default. It's also contextually
> relevant
> to associate the fields with the columns. I think this would end up very
> similar to the auto-filter feature on most spreadsheets.
>
> That would require more UI work for the dialog and its contents, filter
> icon in
> header, etc. Clicking on the column header currently sorts the column, so
> we'd
> have to see if that still made sense or not. I imagine the filters would
> append
> new clauses to the solr query, but it might get real weird if we don't put
> in
> the extra work to parse a given solr query to know what filtering is
> active.
> https://github.com/evolvingweb/ajax-solr/ might be worth exploring. Also
> separating the user-entered query from the filter query would help some but
> still would require some parsing. Solr seems to support this concept of 2
> query
> params, but I haven't used it myself
> http://wiki.apache.org/solr/CommonQueryParameters#fq
>
> Thoughts?
>
>
> --
> Dave Brondsema : dave@brondsema.net
> http://www.brondsema.net : personal
> http://www.splike.com : programming
> <><
>
--
*Daniel Hinojosa*
*Community Manager, SourceForge / Slashdot Media*
p: 415.890.3608
e: d@slashdotmedia.com
Twitter: @hinojosad
Skype: hinojosad