+1 On Nov 5, 2013, at 10:52 AM, Wayne Witzel III <wwitz...@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) > wa...@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) >> wa...@pieceofpy.com (mailto:wa...@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 : d...@brondsema.net (mailto:d...@brondsema.net) >>> http://www.brondsema.net : personal >>> http://www.splike.com : programming >>> <>< >> > > >
