Mailing-List: contact allura-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: allura-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: 76.96.62.24 is neither permitted nor
 denied by domain of dave@brondsema.net)
Message-ID: <527D1FDA.9060802@brondsema.net>
Date: Fri, 08 Nov 2013 12:31:06 -0500
From: Dave Brondsema <dave@brondsema.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: allura-dev@incubator.apache.org
Subject: Re: a UI for filtering tickets
References: <5272B04C.10206@brondsema.net> <52790763.8070109@brondsema.net>
 <4B592047379740319766690F1FE50F0D@gmail.com>
 <801F1D625EDB4EF18EBD5D49E82521CF@gmail.com>
 <2125263A-9F05-4C8C-A683-31D00F3F124F@jaguNET.com>
 <CAOH-Deo=he_8GGH2Ya45fhuvN434aVK9A2vxvg8Lr77FJMYStg@mail.gmail.com>
In-Reply-To: 
 <CAOH-Deo=he_8GGH2Ya45fhuvN434aVK9A2vxvg8Lr77FJMYStg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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 <jim@jagunet.com> wrote:
> 
>> +1
>> On Nov 5, 2013, at 10:52 AM, Wayne Witzel III <wwitzel3@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
              <><