InfoQube IM - Community

Submitted by Hilary on 2019/11/02 05:26

Hi,

I'm rethinking how I use IQ in time for my New Year planning. What I want to be able to do is have a grid dedicated to a project, and then filter and view items (ie tasks) by time period - not actual dates/deadlines, but quarter, month & week.

Question: should I be identifying projects and time periods with fields or tags?

I'm tempted to use tags for both because the child/parent relationships would be very useful - but before I dive in, are there potential snags I should be aware of? What are the pros and cons of each, features present with one and missing in the other...?

Thanks!

Comments

Hi Hilary,

Good question...

The main difference between the two is:

Tags support parent inheritance and multiple parents. It is also easy to copy/paste all tags of an item to another
Fields support child inheritance and equations. An auto-assign equation can trigger a series changes to the item's field values

I would use a Y/N field for the Project but a tag should do it too.

If your tasks are structured as an outline and you want to filter you must ensure sub-tasks have the project field/tag checked. This can be done at the grid level (Grid properties > Data > field list to assign to all items), or if using a field, in the field properties > Equations

As to filtering, if your tasks are fairly long, this can a little tricky

That is, say a task starts on Sept 15th and ends on Nov 3rd. You want to see your tasks for October. Filtering start and/or end for October will not return that task

For that, you need to use a source filter of type Start<#2019-11-01# AND End>=#2019-10-01#

This is very flexible (show any week, month, quarter). But you must type in the filter textbox though. No UI tools to help you except the filter textbox dropdown list (which remembers your recent entries)

HTH !

Pierre_Admin

IQ Designer

Thanks, Pierre - much appreciated.

I use outlines with sub-items a lot. Is there a way to get a sub-item to inherit the tags of its parent? I had a look at 'Manage grids' and found 'Tag inheritance depth', but that must be something different...

(By default it looks as though the Scratch grid for a tag automatically includes sub-items of anything with the tag, but I'm still a little afraid of 'losing' items if they're not tagged themselves.)

[quote=Hilary]

Is there a way to get a sub-item to inherit the tags of its parent? I had a look at 'Manage grids' and found 'Tag inheritance depth', but that must be something different...

[/quote]

No, sub-items cannot inherit tags of their parent. But as Wayne pointed out, sub-items will always show under the parent (well, that's not quite true, but good enough for now)

You only need sub-items to have the parent tag if you plan on filtering for that tag and some other field/tag that the parent may not have

Tag inheritance depth goes the other way around: if you filter for the parent tag, items with a sub-tag will show up

When filtering, a key thing here is the difference between source filters (including date and alpha) and column filters. If you need details on these differences, do not hesitate to ask.

If you want sub-items to inherit something from their parents, best is to use field inheritance.

HTH !

Pierre_Admin

IQ Designer

[quote=Pierre_Admin]

No, sub-items cannot inherit tags of their parent. But as Wayne pointed out, sub-items will always show under the parent (well, that's not quite true, but good enough for now)

You only need sub-items to have the parent tag if you plan on filtering for that tag and some other field/tag that the parent may not have

Tag inheritance depth goes the other way around: if you filter for the parent tag, items with a sub-tag will show up

When filtering, a key thing here is the difference between source filters (including date and alpha) and column filters. If you need details on these differences, do not hesitate to ask.

If you want sub-items to inherit something from their parents, best is to use field inheritance.

HTH !

Pierre_Admin

IQ Designer

[/quote]

Thank you - again. I'm not bothered about which tags sub-items have, unless a missing tag could mean I get myself into the situation of imagining I'm looking at everything I need, when I'm actually missing something.

If I...

tag a bunch of items 'ProjectX'
identify some of them (with a tag or a 'month' field) as 'January'
create a grid with source '#ProjectX'
filter that grid - with source bar or column filters - for 'January'

...am I going to miss seeing any sub-items for my January tasks in Project X?

I suppose what I'm really asking is this: given that I don't particularly know what I'm doing, can you imagine a scenario in which I could 'mislay' items because I'd only tagged their parent?

Or one in which I'm suddenly going to realise I should have used fields and need to start over?

[quote=Pierre_Admin]

You only need sub-items to have the parent tag if you plan on filtering for that tag and some other field/tag that the parent may not have.

[/quote]

Err... wait... filtering is not the same as 'grid source' - or is it?

Parent: tagged 'ProjectX' (but no 'ThisWeek' field)
- Child: has field 'ThisWeek' (but no 'ProjectX' tag)
- Other children: 'January' 'Q2' etc.

Muggins wants to find things to do on Project X this week. Grid source is Project X, filter is 'ThisWeek'. Success?

(Sorry to be slow. I hope I'm a useful 'example non-specialist user' or something, though I know you can have too much of a good thing with those.)

[quote=Hilary]

[quote=Pierre_Admin]

You only need sub-items to have the parent tag if you plan on filtering for that tag and some other field/tag that the parent may not have.

[/quote]

Err... wait... filtering is not the same as 'grid source' - or is it?

Parent: tagged 'ProjectX' (but no 'ThisWeek' field)
- Child: has field 'ThisWeek' (but no 'ProjectX' tag)
- Other children: 'January' 'Q2' etc.

Muggins wants to find things to do on Project X this week. Grid source is Project X, filter is 'ThisWeek'. Success?

[/quote]

hi Hilary

I haven't used Tags as a grid source (so I'm not the expert here) -- but in this case I would recommend using a field for the Project name. Me, I keep it totally simple and use a tick-box field with the project name. You could also use a pop-up field 'Project' with a list of project names - this would be more suitable if you want to see all projects in one grid.

All I can tell you is that if you use a field, and set that field as source for a grid, and use the normal (default) outline mode, all subitems will display -- once the hierarchy is expanded -- shortcut below for this.

Re filtering versus source:

yes the source is a filter, the general idea is to always keep it simple (one field). Then you can filter those items in other ways.
re column filtering -- first the column has to be displayed in the grid; important also to note that only visible items will be filtered. Ctrl+Shift+9 will expand all items in grid to the ninth level (of sub/sub-items) allowing you to filter all (not sure if there's a shortcut to expand *all* hierarchy in case of deeper hierarchies).
there is a sourcebar which can be displayed which has a filter box -- I dont normally use this as it is more advanced. It does have the advantage that you can filter and sort by fields that are not displayed in the grid

Tom

PS I'm not the expert here so hope someone will confirm the details

Hilary,

Subitems will always travel with their parents (at least I'm not aware of an exception). They can't be lost in the way you're thinking.

So if you tag the parent, the children will always be there where the parent is displayed. I don't know of any advantage to tagging the children separately unless you want to give them a tag different from the parent. In that case:

1) If you open a grid based on the parent's tag, ALL the parent's subitems will appear, regardless of their own tagging.

2) If you open a grid based on a child's tag, ONLY that child will appear. It's siblings will not appear unless they''re also tagged. The parent also will not display except as a context parent.

I think I have that right.

Wayne

Superb, thank you.

Alas, Wayne turns out to be wrong about this.

A parent item and a couple of its children have a tag; it also has a lot of untagged child items.

In the tag pane, I double-click this tag to create a scratch grid based on that tag. (No other filter.)

It only shows the items that actually have the tag. The remaining children are missing.

Unfortunately, I just removed a stack of items from my Inbox after tagging them, and I can't remember which had child items. Is there some way to have a tag as grid source and get all child items to display there?

This is by design when both items and some sub-items have the field value / tag

To show other sub-items use one of:

Right-click on the parent item > Sub-items > Show all children
Change to the flat list display mode (Grid > display mode)

Pierre_Admin

IQ Designer

...oh, or remove the tag from the child items! Thanks.

or... Look at the Properties pane for the complete list of children / siblings

Pierre_Admin

IQ Designer

Hilary,

I tested what I told you before posting but didn't pick up the behavior you described because my scratch grid normally opens in flat list mode.

Sorry for the confusion. I didn't realize the outline mode of the scratch grid would cause a problem. I'm glad Pierre clarified that.

What shows and doesn't show with various combinations of grid assignments and outline modes can be confusing and I still have to periodically remind myself of how it works.

Wayne

I aspire to reach the stage of needing to remind myself... ;)

Re fields or tags, you can do it so many ways. The way I look at it is to think of a document management system. Some of them work on pure metadata. There is no "place/folder structure" for any document, you find everything based on meta data. Then there are hybrid document management systems, where files are stored in folders, and also have metadata associated with them. IQ can duplicate either method of document management for the information you store it in.

I prefer the hybrid system, and that is how I visualize working with IQ. That is, for every item I want to "store" it in a location/grid (even though it might appear in more than one grid) that I would know to go to if I wanted to find it. And then I also use tags to apply metadata so I can find information in many different ways.

So to get specific, at the present I use fields and tags as follows, which I do consistently across the IQ database:

Fields - I use fields for use as a "location"* to file something (grid source). So I have a grid named "notes" that it is field. AND/OR I use fields for all attributes I want to track that can have multiple states. Priority as an example (high/medium/low) I would use a field for.

Tags - I use tags as a way to assign attributes that do Not have multiple states. So a single item might be tagged with "Hawaii", "Volcanoes", "Lava" and "Ecology". None of those attributes have multiple states. So for me tags are a way to find information in many different ways, or look at information with similar tags that you would "file" in completely different locations. A word of clarification. For something like year, I would still use a tag. So a history article might be tagged "1944". You might say "wait a minute, that would be a field based on the rule you stated in the paragraph above, because you will have many different years. But actually it would not, the date for the item would never change. So it is still an attribute that only has one state. Whereas the priority for an item could change or be a judgment call, so I consider that a "multiple state" item.

Using the above system has allowed me to achieve some consistency in IQ and feel like I know exactly what I want to do when I enter an item, so that I can easily refer to it later at any time.

*Technically of course nothing in IQ has a location, if an item meets the conditions for a grid, it will appear there. But for practical purposes, a grid can be thought of as a "location". I suspect this is why Pierre started calling grids notebooks. It's easier for people to think of them that way. i.e. as a location.

This sound like a good approach !

[quote=Tom]

This sound like a good approach !

[/quote]

Thank you Tom. One of the things I find interesting is that doing away with filing locations altogether and just applying metadata is in theory the best way to go, the system of filing something in a "place" is antiquated. But I think as humans the idea of things things having a "place" is deeply ingrained in us, because that's how things work in the physical world. To use only metadata also requires a very disciplined system.

Below is a short 3-minute video showing M-Files my favorite document management system. In the normal config it works on pure metadata. It can do that very well because it is very structured in how it enforces users to apply metadata. But interestingly, even they now also allow folders because they found some users simply could not get past the "obsolete" method of also wanting to put the file "somewhere". www.youtube.com/watch

In a perfect world I think pure metadata is the way to go, but unless you have that perfect system. I find having a "location" is very helpful to be able to fall back on. YMMV