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