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) [email protected] 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) > [email protected] (mailto:[email protected]) > 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 : [email protected] (mailto:[email protected]) > > http://www.brondsema.net : personal > > http://www.splike.com : programming > > <>< >
