InfoQube IM - Community

Submitted by jan_rifkinson on 2009/08/31 11:08

Unless I've missed a setting somewhere, it appears to me that sub-item sorting goes on in a grid whether the function is engaged or not. I cannot demonstrate that the grid menu item "sort criteria applies to sub-items" is not engaged so you'll have to take my word for it.

The image below is from my contact list

filtered for "S"

sort item asc

Comments

Humm... but I don't see any sub-items here, these are all main items (TLI)

Look @ sub-item under Tim Taylor

and

Steve Bell does not exist anywhere as a TLI, only as a child of Ridgefield Glass

If this doesn't make sense, maybe you can explain the sorting pattern then.

Jan Rifkinson

Ridgefield CT USA

HP Blackbird Vista Ultimate SP-2

The setting applies to sub-items that don't belong to the grid. All the items there belong to the grid. You can check the grid source to confirm this.

[quote=jan_rifkinson]

Look @ sub-item under Tim Taylor

and

Steve Bell does not exist anywhere as a TLI, only as a child of Ridgefield Glass

If this doesn't make sense, maybe you can explain the sorting pattern then.

[/quote]

I'm unsure what exactly it is that you are unsure of Jan...

Are you saying you think Steve Bell should be elsewhere? Are you confused by the hierarchy (what are the hierarchical settings btw?)

Are you confused because the grid goes (bottom to top) R - S - T - S

Could it be that the T is there in the middle of the 'S's because it's a context parent and therefore ignored - or is it simply blue because of a link?

Definitely, "Tim ..." and "Ridgefield ..." are context parents. You can hide those if you want....

Here's what is confusing to me. I'm going to repeat some of my first post.

This is an alphabetic contact list

The portion I demonstrated is filtered for "S"

I assume filtering for "S" with the option to sort sub-items off will only filter TLI

Tim is a TLI that does not begin w "s" but the sub-item, i.e. child of Tim does (sending)

Ridgefield Glass is a TLI that does not begin w "s" but the sub-item, i.e. child of Ridgefield does (Steve)

I did not expand these two TLIs

IQ did that when I filtered for "s"

Therefore -- to me -- this means that the sort criteria was applied to the subitems in addition to the TLI items

However I did not 'activate' (select) Grid > Sort Criteria Applies to Subitems

What am I not understanding?

This is nutz

Jan Rifkinson

Ridgefield CT USA

HP Blackbird Vista Ultimate SP-2

I'm not sure I like that either, but I guess it's logical :

1- all TLIs which meet the source AND the filter are displayed.

2- The TLIs who were filtered out expose their sub-items meeting the source AND the filter and these become TLIs.

This sounds like a very Ecco behaviour. But I don't know ecco enough to really tell...

(Or is it a bug that I'm tring to make sense of ?)

Of course, it's weird, because it shows the relative nature of being a subitem -- Pierre usually says that all items are equal...

At the same time, for 99% of users (my estimate... ;) ), a subitem is a subitem (heck : it has a parent !), and its position in the hierarchy has the same weight (or more...) then the fact that it now logically meets the grid's source and filter (after being striped from its parent(s)) and should not be treated as a real subitem...

Just a thought...

I always had issues with the way TLIs and "source field" function in IQ (with source field deassignation when items are demoted etc.) : see Discussion about IQ's treatment of item field(s) auto-assignation in relation to the grids' sources and Grid Source EditBox...

Pierre : did you see that discussion ?

If you turn off context parents, you should get the display you expected to see.

Grid>>context parents

I believe, this has nothing to do with sub-items.

As Armando pointed out, all items are treated equal in IQ, as such there is no such thing as a Top Level Item (TLI), or more accuratly, a TLI is simply an item that (currently) has no parents (but at anytime, you can add a parent to it). If an item has 1 or more parent, the main parent will be displayed in the grid if grid>>context parents is checked.

HTH

[quote=Pierre_Admin]

If you turn off context parents, you should get the display you expected to see.

Grid>>context parents

I believe, this has nothing to do with sub-items.

[/quote]

It doesn't seem to me that Jan is having troubles with context parents. It seems to me that he wonders why -- since the "Apply to sub-item" option is not checked -- some items which were sub-items a second ago are now showing as TLIs and others not (hence : they wen't "through" the filter...) after the filter is applied.

I think he expects that none of these sub-items should appear as TLIs since they were sub-items at the time of applying the filter (and hence shouldn't be part of the source + filter equation... ~~and after all, subs don't really need to meet the source to be in a grid... right ?~~ I'll stop there to keep it simple).

The "apply to sub-items" would really works as he'd expect only if all the TLIs met the filter AND the source -- none of the sub-items would then be "filtered" when "apply to sub-items" is on . But when a TLI doesn't meet the source -- like in his example -- then sub-items are put in a TLI position (since they don't really have a parent in that grid context anymore) and are filtered accordingly... oops.

In other words... ? What Jan seems to say is that it doesn't seem to matter whether "applies to sub-items" is on or off If a TLI doesn't meet the filter + source, and its sub-items do. The effect will be exactly the same for that TLI and its subitems : all sub-items meeting the filter + source will be displayed as TLIs. And "Apply to sub-items" would only matter (and changes what's displayed) if the TLI met the source... and if some subs do and others don't.

That's confusing for most user, and Jan's astonishment is one proof of that, IMO.

One more thing... An advice for Jan : the "sending me herding DVD's..." etc. type of items, which look more like some notes, todos and stuff like that, should probably not meet the source anyway (or at least not all of it... if it's a complex one), and hence would not as easily figure as a TLI after some logical filtering...

"Normally", items meeting the grid's source, are really the item which share a same "nature" or identity so to speak. I.e., in a contact list, "sending me herding DVD's..." is not of the same nature as, let's say "Jack Sparrow". Just a thought... But you're the master of your own database...

(...your other item showing as TLI after filtering (is it "Steve..." or something like that...) is more like a contact, an so I wouldn't havce a problem seeing this sub showing asTLI after some filtering... But... That's me, and I still do understand your precious point.)

Armando, In your posting that begins "It doesn't seem to me that Jan is having troubles with context parents".

you capture the essence of the situation. This has little to do w context but more to do w filters applied to sub-items

However, we part company only in the sense that beyond my professed confusion, I simply don't think the function under discusion works properly.

Either IQ applies a filter to a sub-item or it doesn't..

I asked IQ not to do so yet it does so anyway.

It seems to me the user has to consider an item as it appears in the grid view. I don't think it makes much practical sense to ask a user -- under certain circumstances -- to suspend belief that a child item is not really a child item because philosphically all items are equal since at any point an item could become a parent,granchild, grandparent, sibling etc.

Pierre, I'm sorry. If that is your argument, I think it's not useful. Again, I don't believe the function is working properly. Now maybe you don't want to look @ this or maybe you don't have time to look @ this, etc. but I don't think it can be explained away. The situation I reported is not the end of the world, certainly. But I do think it's a problem, albeit, perhaps a small one in the scheme of things.

@Armando: In your 2nd post beginning w "One more thing", I understand your point however I use the contact list as a repository for any exchange between myself & the contact. That data could take the form of sub-items or links. That way, the next time I'm dealing w that contact I have a short history of relevant items, some described in more detail in the HTML pane or shown as completed while some that have due dates attached to them or are marked pending, important, etc. Other than this one structure (coontact list) & my daily journal, most of my other items are free flowing & are filtered one way or another.by project, etc.

Thanks for your interest in the situation I reported.

Jan Rifkinson

Ridgefield CT USA

HP Blackbird Vista Ultimate SP-2

[quote=jan_rifkinson]I use the contact list as a repository for any exchange between myself & the contact. That data could take the form of sub-items or links. [/quote]

I understand all that. I was suggesting that maybe, the "source field" (whether it's addressBook or Contact, or whatever) could be removed/deassigned from these items to make sure they're not identified as contacts and never appear as TLIs.. And you could use Full hierarchy to make sure that these will always be visible as sub items.

Ah, yes. Stupid me

Now I understand what you meant & of course you are right. The question then becomes how did the 'send DVD' get assigned to Contact list? The other 'confused' item is really one of several people who work @ Ridgefield glass so that would make sense to me assigned to contact list.

But even so I'm still left w don't-assign-filter-to-sub-item seemingly assigned to a 'sub-item'. I don't think Ridgefield Glass should appear.

Jan Rifkinson

Ridgefield CT USA

HP Blackbird Vista Ultimate SP-2

>I don't think Ridgefield Glass should appear.

If I may insist, simply set Grid>>Context Parents to off to hide it.

For more info on the various display settings, in particular in relation to contact lists, this page is useful: 1. Grid Display Modes

Pierre, did you read the other posts ? I'm just asking because, if Jan maybe made a mistake by invoking the "Ridgefield Glass" item in his last post, the first posts are pretty clear : the problem wasn't "Ridgefield Glass" per se, but sub-items starting with "S" appearing as TLI etc. But I'll stop there as I wrote plenty already.... And I believe it's clear. But maybe someone else than me can explain in a better English.

[quote=Armando]

the problem wasn't "Ridgefield Glass" per se, but sub-items starting with "S" appearing as TLI etc.

[/quote]

I think they aren't sub-items in this particular grid. If "Steve" and "sending" meet the source for Contact and meet the filter for "S", then we absolutely want them to appear. They're TLI's for the purpose of this grid, despite being displayed with optional context parents. The status of "sort criteria applies to sub-items" does not filter them, nor would we want it to. If they're "S" Contacts then they have to show.

Jerome

[quote=JJSlote]

[quote=Armando]

the problem wasn't "Ridgefield Glass" per se, but sub-items starting with "S" appearing as TLI etc.

[/quote]

Jerome

[/quote]

Jerome,

What do you mean, "they aren't sub-items" ? The fact is that they were, according to jan -- yes, of course they aren't anymore, after applying the filter... and if they aren't maybe there should be a special definition of what a sub item truly is in the special context of IQ (...not sure that will help).

The fact that they meet the source is another story altogether. Let's forget about context parents. I don't think that context parents are the crux of the matter here.

NOTE that I don't really have a "intellectual" problem with them showing up either. I understand why they do : IQ does a first round of filtering, and then does it's subitem thing on the resulting item's subitem... I don't think that it's not intuitive though [edit : because of the name "applies to sub-items"], but I can live with that...

I'll repeat : I understand why IQ behaves the way it does. But let's pretend I'm a new user, and a non-programmer one.

Here's my hierarchy :

Full hierarchy is on. Save item state is on.

Ok, I decide that I'll Turn my filter on (item like "T*") and decide that I don't want the filter to apply to subs. Only TLI.

This is what I -- as a non armando new user who's not a programmer having insight in IQs depth -- would expect to see after the filter has been applied :

[Edit : NOTE to readers: THIS SCREENSHOT HAS BEEN MODIFIED TO FIT THE ARGUMENT -- this is NOT IQ's normal behavior]

But instead I see this (as if the sub items had been going through the filter too) :

Now I decide to turn ON the apply to sub-items, wondering if maybe that'd turn it off and I see :

Basically the same thing. And so I -- as a newbie -- am starting to wonder.

Now, please, you guys, again : I undertand why this happens. But I'm also interrested in what Jan finds difficult to grasp !!! Obviously, it seems to be causing problems ! as for the user it's a bit like if the previous Sub-item status of an item was suddenly completely evacuated in the logic of the filtering process.

Jan is not the first one to be puzzled. He is absolutely not.

"Filter applies to sub-item" should actually be "Filter applies to sub-items of the resulting TLIs" or something like that -- sorry English is not natural for me. Of course, that's long and ugly.

Let me ask this question another way:

What does the command Grid > filter criteria applies to sub-items refer to,

i.e. what does it control?

Let's take Ridgefield Glass example

and

Let's assume that source, etc is ok, i.e. no errant assignments

If I was filtering for 'R' I would expect 'Ridgefield Glass' to show up

Only if I manually expand 'Ridgefield Glass' would I expect to see 'Steve Bell'

If I was filtering for 'S' I would not expect to see 'Ridgefield Glass' as a context parent to 'Steve Bell'

if the command Grid > filter criteria applies to sub-items was not activated

However, this seems not to make a difference

The only thing that makes a difference is if Context Parent is activated (or not)

So, back to my original question: what does Grid > Filter Criteria Applies to Sub-items do?

I'm not bitching & moaning about this as I know enough to noodle around & probably get the results that I want in the grid view. I just find that's a bit much to expect users to divine that what looks like a sub-item is actually a TLI in disguise.

I hope I'm not muddying up the waters again. I just think this is an example of another one of those things which may prevent users from diving into IQ and using the hell out of it in their daily lives as some of us on this forum do.

Jan Rifkinson

Ridgefield CT USA

HP Blackbird Vista Ultimate SP-2

[quote=Armando]

"Filter applies to sub-item" should actually be "Filter applies to sub-items of the resulting TLIs" or something like that -- sorry English is not natural for me. Of course, that's long and ugly.

[/quote]

Jan hasn't been asking about "Filter [criteria] applies to sub-items" but about "Sort criteria applies to sub-items." Perhaps that's the "source" of confusion.

Jerome

[quote=JJSlote]

[quote=Armando]

"Filter applies to sub-item" should actually be "Filter applies to sub-items of the resulting TLIs" or something like that -- sorry English is not natural for me. Of course, that's long and ugly.

[/quote]

Jan hasn't been asking about "Filter applies to sub-item" but about "Sort criteria applies to sub-item." Perhaps that's the "source" of confusion.

Jerome

[/quote]

Yes, maybe. One needs to be careful with terms. But we also need to look at the thread globally. From what has been discussed, shown, and confirmed by Jan, the discussion seems to be around "Filter applies to sub items" and the confusion about how it operates in the grid. And no matter how clear the explanation will be, it seems that it'll always be a problem because it's not "intuitive" (I hate that word... as if there was some kind of acontextual objective intuitiveness...).

[quote=Armando]. From what has been discussed, shown, and confirmed by Jan, the discussion seems to be around "Filter applies to sub items" and the confusion about how it operates in the grid.[/quote]

Filtering is what Jan is trying to accomplish, but "Sort criteria applies to sub-items" is the toggle he's seeing as inoperative or "stuck." Jan, what's your setting for "Filter criteria applies to sub-items" ? That grid property seems far more likely than "Sort" to determine whether non-TLI's appear.

Jerome

[quote=Armando]

[snip] if Jan maybe made a mistake by invoking the "Ridgefield Glass" item in his last post, the first posts are pretty clear : the problem wasn't "Ridgefield Glass" per se, but sub-items starting with "S" appearing as TLI etc.[/snip][/quote]

yes. sorry to add to the confusion

Jan Rifkinson

Ridgefield CT USA

HP Blackbird Vista Ultimate SP-2

Winding back to reduce indenting...

Hopefully I can summarize what you're seeing. Also, lets ignore item "sending me ..." as it has been concluded it was incorrectly put in contacts

You clicked on the AlphaFilter to see all contacts starting with S, sorted by item (i.e. name)

Your screenshow shows the list of contacts, properly sorted as you would expect. The only issue here is that Steve Bell, while properly sorted is shown under Ridgefield Glass (itself shown in blue, to show it is a context parent: not apparent in the screenshot, because the focus is on that item).

Jan, could you please answer these questions:

If Steve Bell's parent was not shown, would you not get the expected list of contacts?
Is showing Ridgefield Glass in the grid an issue for you?

As I wrote earlier, this has nothing to do with "sorting applies to sub-items" or "filtering applies to sub-items", but with context parents. In a contact list, you want to see contacts, irregardless of whether the item has parents, grand-parents, etc.

"sorting applies to sub-items" or "filtering applies to sub-items" take effect when you expand an item which belongs to the grid. So, if in the above example, Shelley Ross had numerous sub-items (some contacts, some tasks, etc), you would turn on "filtering applies to sub-items" to only show contact-related sub-items and hide task-related ones.

HTH

Can we agree that

[quote=Pierre_Admin]So, if in the above example, Shelley Ross had numerous sub-items (some contacts, some tasks, etc), you would turn on "filtering applies to sub-items" to only show contact-related sub-items and hide task-related ones.[/quote]

Pierre, are you sure? I would have thought that "filter criteria applies to sub-items" relates to the filter "S", not to the source Contacts. By "contact-related sub-items" do you mean sub-items that meet the Contact source, or is there some other hook?

Jan, any chance you could redisplay that grid and add the Contact column, so we could see which items actually meet the source?

Jerome

Good point Jerome, but not quite correct.

The "filter applies to sub-items" uses the filter text box, not the AlphaFilter, which I assume Jan used.

e.g. Lets say the source is "Contacts" and the filter is "Contacts or Tasks" then clicking on the contact would reveal tasks (and contacts) related to this contact, but hide notes and other non-relavant sub-items.

This also works for 2-parts filters (filter="Contacts | Tasks" would show contacts and expanding a contact would only show tasks for this contact

see Source Filter Editbox

[quote=JJSlote][snip]

Jan, any chance you could redisplay that grid and add the Contact column, so we could see which items actually meet the source?[/snip]

[/quote]

Jerome, There is no contact field per se so no contact column.

Item = contact

Maybe I should have a contact column.

Maybe that's part of the problem...?

Jan Rifkinson

Ridgefield CT USA

HP Blackbird Vista Ultimate SP-2

[quote=jan_rifkinson]

Jerome, There is no contact field per se so no contact column.

Item = contact

[/quote]

Hi Jan

Sorry, that was indeed unclear. I meant it would be helpful to see, in a column, whatever field you're using as the Source for the grid being displayed.

Rgds

Jerome

[quote=JJSlote][snip]

I meant it would be helpful to see, in a column, whatever field you're using as the Source for the grid being displayed. [/quote]

No problem. Source = Contact List

Jan Rifkinson

Ridgefield CT USA

HP Blackbird Vista Ultimate SP-2

[quote=jan_rifkinson]

[quote=JJSlote][snip]

I meant it would be helpful to see, in a column, whatever field you're using as the Source for the grid being displayed. [/quote]

No problem. Source = Contact List

[/quote]

Right, but how about with the items in question: Tim Taylor, herds of DVD's, Steve Bell... :-)

JJS

[quote=Pierre_Admin][snip] Also, lets ignore item "sending me ..." as it has been concluded it was incorrectly put in contacts[/quote]

ok but I didn't put it there so that's another issue for another time I guess

[quote=Pierre_Admin][snip] Jan, could you please answer these questions:

If Steve Bell's parent was not shown, would you not get the expected list of contacts?
Is showing Ridgefield Glass in the grid an issue for you?[/quote]

1. yes & this is accomplished w context parent on / off

2. yes but this can be resolved the same way I think

[quote=Pierre_Admin][snip] "sorting applies to sub-items" or "filtering applies to sub-items" take effect when you expand an item which belongs to the grid. So, if in the above example, Shelley Ross had numerous sub-items (some contacts, some tasks, etc), you would turn on "filtering applies to sub-items" to only show contact-related sub-items and hide task-related ones.[/quote]

I think I've got it now. sorting / filtering applies to sub-items is only useful if TLI has sub-items & is expanded.

If I've got it, then a couple of thoughts come to mind:

1. I can see sorting sub-items but it might be more useful if it could be sorted by a different criteria, i.e.

TLI sorted alpha

sub-items sorted by creation date

2. but, to be honest, I don't know what filter sub-items would accomplish. Maybe an example would help

3. finally, to simplify the GUI, I think the two sub-item functions we are talking about should be un-available to user unless TLI item is expanded since that's the only place it's useful. Maybe the same for 'Context Parents'

And while I'm at it, is full hierarchy = <CTRL>9 or 0

so maybe the cause of my confusion could be solved / summed up this way:

Step 1 - user looks @ grid & only TLI is shown, only Full Hierarchy & <CTRL>1-0 is available to expand

Step 2 - user expands TLI to show sub-items & sort / filter / context options become available

It's almost like these 3 options are offered to the user out of context (pardon the pun)

Jan Rifkinson

Ridgefield CT USA

HP Blackbird Vista Ultimate SP-2

[quote=jan_rifkinson]I think I've got it now. sorting / filtering applies to sub-items is

only useful

if TLI has sub-items & is expanded.

[/quote]

well, if an item (TLI) doesn't have children, it would obviously be useless. But I often use "apply to sub items", whether they're expanded or not in the first place if... I want the sub items to be filtered too !

The only confusing thing is that, when you apply the "apply filter to sub items", you have to think logically and not hang on too tightly to what is shown in the grid before you're applying a new filter. That's the trap. You need to "start from scratch" so to speak, every time you apply filters. You have to ask yourself : what will these filters, all put together, allow the grid to show from this whole DB.

The filtering section of the manual explains how filters are put together

example :

let's say your filter textboxes are filled like that :

- source = contacts

- filter = item like "*S*"

- Alphanumeric filter = item like "A*" (of course you don't see it like that... but that's what it'll mean if "item" is selected in the field area and "A" written in the textbox)

You have to recompose the whole thing in your head like this :

Contact AND item like "A*" AND item like "*S*"

The order in the sequence is important -- and as you can see, the Alphanumeric filter has "priority" over the filter textbox (well... if I'm not mistaken -- hopefully not).

So :

1- this filtering sequence (Contact AND item like "A*" AND item like "*S*") is applied to all items in the DB and the result is displayed

2- then, if hierarchy is ON (otherwise it's kind off useless -- but not necessarily... depending on what you're working on...) and "applies to sub items" is ON, IQ will apply the filter part ( item like "*S*" ) to the sub items of the previous resulting view and display the results.

[quote=jan_rifkinson]If I've got it, then a couple of thoughts come to mind:

1. I can see sorting sub-items but it might be more useful if it could be sorted by a different criteria, i.e.

TLI sorted alpha

sub-items sorted by creation date

[/quote]

I know Pierre intended to add the possibility to add the "|" seprator in the sort text box to separate 2 different sorting filter set (one for TLIs, one for children) -- something that's already possible with filter. I use it all the time.

[quote=jan_rifkinson]

2. but, to be honest, I don't know what filter sub-items would accomplish. Maybe an example would help

[/quote]

Well... If you don't want you sub items to be filtered in the same way your TLIs are...

I use it all the time...

Let's say you want the displayed TLIs's subs to also be filtered according to the filter text box parameter... well this is when you use it ! However, I must say that I mostly use the "|" separator in the filter text box.. that is to apply a different filter to subs than the one used for TLIs. But there's no rule... I hope I,m not confusing you.

[quote=jan_rifkinson]

[/quote]

Why ? items are always potentially expandable. That would be uselessly restrictive IMO. But others might think like you... let's see.

[quote=jan_rifkinson]

And while I'm at it, is full hierarchy = <CTRL>9 or 0 [/quote]

None, ithink... ctrl - 0 does nothing here... And ctrl 9 expands up to level 9...

But maybe there were some changes I'm unaware of.

The manual explains that, I think.

[quote=jan_rifkinson]

Step 1 - user looks @ grid & only TLI is shown, only Full Hierarchy & <CTRL>1-0 is available to expand

Step 2 - user expands TLI to show sub-items & sort / filter / context options become available [/quote]

That means that you couldn't set your filters to affect sub items before hand -- again, I think it's too restrictive. Better to have a better UI implementation of all these filters to get a better grasp of how they interact.

(crazy but sometimes I can't change / correct the formatting of my posts... It took something like 10 tries to put back the quotes correctly. I had to remove all formatting.)

Armando, I'm taking some time to try to absorb your post. Thank you for the effort & your time.

Jan Rifkinson

Ridgefield CT USA

HP Blackbird Vista Ultimate SP-2