incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wayne Witzel III <wwitz...@gmail.com>
Subject Re: a UI for filtering tickets
Date Tue, 05 Nov 2013 15:52:47 GMT
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
> > <><
>  




Mime
View raw message