Submitted by Armando on 2009/09/01 22:52
Filters (filter text box, alpha numeric, date, column filters), sources (source box filter) and other related  feature (hierarchy, full hierarchy, context parents, filter applies to sub items) interactions are at the root of many questions and problems users face when using IQ.
 
This is in line with point #10 in my Armando's list. in the "High Priority Features and Bug Fixes" forum.
 
[quote]
10- Simplify Filters complexities and awkwardness in some areas (source + filter + column filter = complex)

 Again, this one is not really for me. But I've witnessed over and over that it's still hard for new users (and even experienced ones) to clearly see which filters are active (it's a UI thing, but not only...), which ones are not, and how they affect the items in the grid, etc. This is especially difficult because of the source notion and the idea that not all items have to meet the source to be in a grid... but also because it's just not obvious to a new user to see which filters are active, in terms of UI

 Some progress has been made though (the yellow bar that appears when column filters are active...)

 Not many many Mantis issues have been created around this UI "problem" : 154 (reporter : Armando)

[/quote]
 
 
I'm confident that one simple UI device could tremendously help the user see exactly how each filter influences what is displayed. But what could it be ?
 
 
 
Maybe to display what the full SQL query looks like in the status bar using different colors for each filter section ?...
 
 
I don't know, but since my first days with IQ (SQLNotes), I saw that "filter clarity" problem as an important problem to solve for the sake of user friendliness -- especially because the filtering aspect is at the very hearth of the software.
 
Would IQ benefit from such an UI "filter helper" ? What do you think ?

Comments

> Would IQ benefit from such an UI "filter helper" ? What do you think ?
 
Absolutely - the yellow when column filter is active is a great help.
If that idea could be continued/extended in some way, a problem could be when multiple filters are active ? - I'm very inexperienced with filters myself.
 
Going with the statusbar idea: if it was segmented, each segment being a different colour when a particular filter is active - even if it just says e.g Date filter active and is brighter colour when active

I dont have any original ideas here, just really wanted to add my support to the idea

Greetings Armando

First up, I think we need a documentation entry that enumerates all of the internal tests and toggles that determine whether an item will appear on the grid.  Something like:

1. Item meets the source, passes all active filters, has no parents that meet the source. Appears at Top Level; # is an integer.
...
7. Item meets the source, passes all active filters; context parent meets the source but is excluded by filter. Item appears as sub-item to context parent.   (Jan's case?)
...
11. Item is sub-item of an item that meets display criteria; filter is active; "Filter criteria applies to sub-item" is ON; item meets second part of 2-part filter.
...
29. Item does not meet the source but is parent of sub-item that does. Hierarchy is OFF; Context Parents in Grid Properties is ON. Item appears in Blue as top-level context parent; # is an integer.

Links, naturally, to manual articles discussing each cause or toggle. And a version in table form if possible.

Then, each grid row should store a 3-char reason field that maps to one of the causes above. This can be displayed in a column just like "#", even though it isn't a true Item field. With bubble pop-ups enabled (please can we make these optional per grid), hovering over the code would show the full explanation and the status of the toggles.

Jerome
 
 
 

jan_rifkinson

2009/09/02 12:52

In reply to by JJSlote

@Jerome, just finished reading your post after I wrote mine. I think we might be on the same page. See bottom of www.sqlnotes.net/drupal5/index.php my response to Pierre.
@ Armando, I definitely think some kind of dynamic help / explanatory bubble or status line would be very helpful
 
--
Jan Rifkinson
Ridgefield CT USA
HP Blackbird Vista Ultimate SP-2

Armando

2009/09/02 18:41

In reply to by JJSlote

[quote=JJSlote]
Greetings Armando

First up, I think we need a documentation entry that enumerates all of the internal tests and toggles that determine whether an item will appear on the grid.
[/quote]
 
[quote=JJSlote]
Links, naturally, to manual articles discussing each cause or toggle. And a version in table form if possible.

Then, each grid row should store a 3-char reason field that maps to one of the causes above. This can be displayed in a column just like "#", even though it isn't a true Item field. With bubble pop-ups enabled (please can we make these optional per grid), hovering over the code would show the full explanation and the status of the toggles.
[/quote]
 
It's not a bad idea at all... But, wow, there are lots of possible combinations... and that would be a huge job for Pierre.
 
I was thinking that a simple exposition of the whole SQL query + the added query (id needed) for subs + the hierarchy and context parents effects would already help without being tons of work for Pierre and the community.
 
However, maybe... each important part of the query could be colour coded (fields vs operators), and popups could send the user to a glossary of SQL terms, or something like that. I think I've seen that used in RegexBuddy (http://www.regexbuddy.com/create.html)

Armando

2009/09/02 18:47

In reply to by Armando

Also... Filters in the UI should maybe be organized in a way that makes the logical sequence immediately apparent. Which is not the case at the moment.
 
Source --> (AlphaNumeric and Date) --> Filter --> Column filters = results shown in the grid --> if filter applies to sub items is ON, Filter is then applied to subs.

 

jan_rifkinson

2009/09/02 19:22

In reply to by Armando

[quote=Armando]
Also... Filters in the UI should maybe be organized in a way that makes the logical sequence immediately apparent. Which is not the case at the moment.
 
Source --> (AlphaNumeric and Date) --> Filter --> Column filters = results shown in the grid --> if filter applies to sub items is ON, Filter is then applied to subs. [/quote]
 
YES !!  
 
Now how does heirarchy play into this?
 
--
Jan Rifkinson
Ridgefield CT USA
HP Blackbird Vista Ultimate SP-2

Armando

2009/09/02 20:53

In reply to by jan_rifkinson

Jan :
It's in the glossary.
Basically :
plain Hierarchy : hides all the TLI  from the grid and shows them only under their respective parents IF they have a parent that's displayed in the grid. Only children meeting the source will be shown
Full hierarchy : all children will be shown (unless they don't meet the filter criteria)

jan_rifkinson

2009/09/03 09:51

In reply to by Armando

I knew that. I was just asking you to include it in your logical filter explanation for grid / view display because it does play a role in what user sees in grid
 
--
Jan Rifkinson
Ridgefield CT USA
HP Blackbird Vista Ultimate SP-2

JJSlote

2009/09/02 20:32

In reply to by Armando

[quote=Armando]
It's not a bad idea at all... But, wow, there are lots of possible combinations... and that would be a huge job for Pierre.
[/quote]

Perhaps not. Somewhere in the guts of IQ, there's surely a filtering routine that determines whether an item is or is not going to appear in the grid. Where the routine decides in the affirmative, it can throw off a return code, concatenated in tests along the way. If the return code is a field that can be displayed in the grid, we can probably discern its meaning, and will always be able to answer questions like Jan's. And the combinations are not overwhelming if described in table form:
 
Source metYNN-- - N
Alpha filter metN      
Hierarchy OnYNY -   N
Context OnY Y ...   
Market Up Y   ...  
Filter criteria applies to sub-itemNYY   ... N
Oysters in SeasonYNM    
Return codeABCXYZQMW... ... ...ETC
 
 
The filtering behavior will never be intuitive because the options are so abundant. But where it isn't obvious, the presence of an item in the grid can be easily explained. We probably don't need a UI device if we have access to the return codes. And anyway, the best a UI device could do would be to obliquely describe the toggles at grid level. Explaining Jan's seemingly extraneous items requires information at the item level.
 
Jerome
 

Armando

2009/09/02 20:57

In reply to by JJSlote

Thanks for your clear presentation, Jerome.
 
Well... Then let's wait for Pierre's comment then. :)
 
[quote]
And anyway, the best a UI device could do would be to obliquely describe the toggles at grid level. Explaining Jan's seemingly extraneous items requires information at the item level.
[/quote]
 
A description at the grid level is better than nothing, IMO. Info at the item level would be better, yes.