C-Command Software Forum

Spotlight and Tagging

Hi there

I’ve been through pretty much every version of these organiser apps. The big pluses in EF - for me - are the Developer (been using SpamSieve for years with nary a problem) plus the transparent file storage. But I have some queries:

  1. I’ve scanned the forum and can’t seem to get a clear picture. Are EagleFiler tags searchable by Spotlight? Or is it on the To Do List. I would like to be able to search EagleFiler tags without having to drop from where I am back to the EF window.

  2. I find the ‘tags:Whatever’ format of searching very clunky. I know that that there are ‘Smart-ish Folders’ that display files by tag, but I prefer use the search box rather than scrolling the Source Pane, so can a search ‘Anywhere’ include tags? And are saved searches on the To Do list?

  3. I love the ability to have nested tags, so that, for instance, I can have a Top Level Tag - Camera - and off that nesteds, like software, websites, exposure, lenses etc. However, surely adding a nested tag should also add the major tag - that is, if I add the tag exposure, then it automatically adds the top-level tag, Camera? (Checkout the iPhoto plug-in Keyword Manager if I’m not being clear.) Otherwise what’s the point of a nested tag?

regards

terrydev

Not currently. It’s on my to-do list.

Could you give me an example of what you’re trying to search for? If you just want to search for tags, you can use a Tags search instead of an Anywhere search, and then you don’t need the “tag:” prefix. Also, please note that you can type the first few letters of a tag’s name while in the source list in order to scroll to that tag.

Yes.

Please see this thread. In short, I think your idea makes sense, but it isn’t always what people would want. There are other possible uses of nested tags. I plan to make EagleFiler better leverage the tag hierarchy, both for assigning tags and for viewing them.

Michael

Many thanks for your reply.

I read the other posts on nested tagging - and apart from wondering how I missed the thread completely, then I realised I was searching on Spotlight - it was a very good discussion. So sorry for that. However, something caught my eye:

ianxwin wrote on 12/10/06

“Assigning a parent tag as well as a child tag means you are giving redundant information. As long as an item is tagged with the child, and if the hierarchy of tags is still the same, then the information that the item is tagged with the tag of a parent exists.”

This information is not redundant. Consider:

Top Level Tag: Camera / Nested Tag: Lens/ Further Nested Tag: Canon

If I type Canon I can get a tag that plays to my General Camera Folder, and/or my Lenses Folder and/or My Canon folder. Plus there is the possibility of searches for Lenses while excluding Canon, or Camera, excluding Lenses.

This is a great convenience and a major aid in quickly developing a complex and rich tagging environment. More tags are better, and the nesting gives tags a rich context, making more and more elaborate searches possible.

In relation to including tags in an Anywhere search, in retrospect I think you’re right. To include tags in an anywhere search could lead to massive duplication in the result.

reagrds

TerryDev

I think you’re right, that it’s possible to use nested tags in a way that the information is not redundant. However, it depends on the meaning that you assign to the tags.

For this example, though, I think that the information is redundant. That is, given the tag structure, all you have to do is tag it Canon and EagleFiler would potentially be able to support the kinds of searches that you describe.

For this example, though, I think that the information is redundant. That is, given the tag structure, all you have to do is tag it Canon and EagleFiler would potentially be able to support the kinds of searches that you describe.

Michael

Thanks for your response.

I’ve been scratching my head a bit: I don’t understand how my example demonstrates redundancy.

While my ‘Canon’ search will find all the files tagged ‘Canon’, how will it find the all the files tagged ‘lenses’, but not ‘Canon’? Or tagged ‘Camera’ but not ‘Canon’, unless the bottom of the nested list <i>implies</i> the top layers. And if this is the case then tagging the bottom of the list should also bring in the top layers. This way, a general search will find the generality of related file (top level) and a more specific search (lower down the nesting) will bring in more specific results.

Or am I missing something? (Which is possible…)

Otherwise, apart from making a tidier display in the Source Pane, what’s the point? Especially as my usage makes very little use of the Source Pane, and a lot of use of the Search Box. (So many years using LaunchBar I guess.)

Regards

terrydev

I’m saying that it’s redundant for you to manually assign all the parent tags when assigning a child tag, because EagleFiler could potentially do that implicitly at the time of the search based on the tag hierarchy. Do you want EagleFiler to make it easier to assign the parent tags, or to leverage the hierarchy when browsing and searching, or both? Or are you assigning meaning to the tags in such a way that the child doesn’t imply the parent?

D’oh!

So I was missing something. Your meaning. Yes, to manually assign all the tags in the hierarchy is redundant, and yes, the lower tags should automatically assign the tags higher up the tree. Utterly agreed. The child does imply the parent. This is exactly what I meant when I cited Keyword Manager in my first post.

Regards

terrydev

Let me try to be more explicit about the different designs we’re discussing.

  1. No special hierarchy treatment when browsing, like in EagleFiler 1.1.3. However, there could be enhancements (e.g. a hierarchical inspector) to make it easier to manually assign parent tags when assigning a child tag.
  2. Like (1) but when you click on (or search for) the parent tag, (optionally) show all the records that have any of the child tags, even if they don’t explicitly have the parent tag.
  3. Assigning a child tag assigns the parent tag. When you click on a parent tag, show the records that actually have that tag, which will generally include the children. However, re-arranging the tag hierarchy doesn’t change the already tagged items.
  4. Like (3) but automatically add and remove parent tags when you re-arrange the hierarchy. This is what Keyword Manager does.

(3) is what I thought you were asking for. I don’t like (4) very much because I may have deliberately assigned certain tags, and I don’t want it to silently remove them just because I re-arranged the tag hierarchy. (2) allows the same functionality without this problem and without cluttering the tags bar with all the ancestor tags.

I have been looking for a document tracker but have held off so far on purchasing EagleFiler because I’m a bit underwhelmed by the way it handles tags as well. So far I like it best of all the alternatives, but the lack of smart folders/saved searches and hierarchical tags that aren’t really hierarchical have both put me off a bit. (As a side note, I may have to get it anyway, since saved searches are on the horizon and it looks like there’s certainly thought being given to tag usage).

In any case, I just wanted to point out that there is a fifth option, one that mimics the functionality of Shoebox (another iPhoto organizer).

In this scheme, the hierarchy within the tags list is intentionally set up so that tags are categories, and children refine the category of the parent. An item with the child tag doesn’t have the parent tag, but the program knows that it belongs to the parent as well.

The reason that this works is because tags are not restricted to one category. For instance, I could layout a tag structure Countries -> France -> Paris, but still also add Paris (or, essentially an alias of Paris) to Vacations -> Favorite Places. The program then knows that Paris is a refinement of France (so clicking France would also show everything tagged Paris), but it also knows that Paris is one of my favorite places.

Obviously, a layout like this would still need an option to restrict searches to items that only had the France tag, but I think that a hierarchical scheme that allows for tags to be more than one thing has a lot of potential power. (On the other hand, EagleFiler’s current interface probably would need to be changed a little to make this kind of thing work).

How to make an interface for that work is a whole seperate question, but I wanted to throw out that conceptualization of tags for consideration (regardless of whether or not I buy the program, I think that it’s worth thinking about when you’re planning out where to take EagleFiler). I personally am strongly against adding the parent tag when the child tag is added, but I think that the current hierarchical tag list isn’t nearly as powerful as it could be.

Purely as an aside, it would be nice if tags allowed spaces, too. Currently EagleFiler is cool with “fiction” but uncool with “short stories” which baffles me a bit.

Thanks for reading my comments!

Michael

Number three is exactly what I was asking for.

regards

terrydev

So this is like my (2)?

Interesting. I agree that this would pose some interface challenges.

How would you like it to work?

For now, please use underscores instead of spaces. I may allow spaces in the future, but I’m reserving them for now because they could potentially conflict with other things I’m planning to do, and I don’t want to paint myself into a corner.

Yep, pretty close to #2. By offering the ability to put tags in multiple categories, though, it expands on the conceptualization of tags as nested categories and allows for attaching a lot of meaning to an object with a minimum number of tags.

On the other hand, I was thinking about this last night, and a potential problem is that sometimes it’s nice to nest tags in ways that are not strictly categorical. For instance, perhaps I have an RTF document about my vacation to Paris that I’ve tagged “Paris” (so the program shows it when I’m looking at tags France and “Favorite_Places”). If I haven’t finished my little review of my trip, I may want to tag the document “unfinished” which is a status. However, do I then create a root-level “status” tag for things like “unfinished”? This doesn’t make sense in the system that I proposed unless I can somehow designate “status” as a group of tags instead of a tag itself. However, as you mentioned before, this adds a level of complexity that is unnecessary for many users (and roughs up the interface once again). Problematic.

I personally would like to see something similar to what I described (or to #2) where the program “knows” that things tagged with a very specific tag also belong to the more general tags further up (while still allowing me to search for things only within those general tags). Adding the parent just seems to me like I’ll end up with a million tags that all mean roughly the same thing, but I do want the program to associate the parent’s meaning with the child.

Even if you don’t go overhauling the tag system, it would be nice to at least have a checkbox in the preferences that allows us to set the program to have parent tags own their children.

Will do. It would be nice if, when typing in the bottom bar adding tags to items, hitting space added an underscore instead of closing the tag. Then again, I don’t know what other people’s workflow is; perhaps they use space to end tags.

Also, there’s a bug in that hitting space in the tags window sticks the underscore ahead of the cursor (instead of entering it and advancing the cursor).

Thanks again for reading my comments!

Right. I’m considering the multiple categories idea separately from the main child/parent issues that we’ve been discussing.

Yes, this is part of the reason that I’ve thus far avoided having EagleFiler assign meaning to the tag nesting. I want to first understand the different ways that people are using nesting and then come up with something that’s useful without being constricting.

This is the direction I’m leaning as well. What I like about it is that it separates the information that you’ve manually added (the specific tags) with the information that EagleFiler can intuit (the more general tags). So it’s clear what’s real and what’s synthetic, and you can freely re-arrange the hierarchy to view and search in different ways.

Thanks—I’ll see about fixing that.

I feel that during the discussions on tags we often are looking to use them for something which is more suited to assigning a field which can hold multiple values. For instance George the Flea talked about a desire to have a flag status - but really wanted it to have multiple values, while a tag as implemented inherently has two values - true and false.
So:
a) Would it be desirable to be able to have fields with (our) predefined values
and
b) Would this be possible to implement a gui for it in a way which is neat, cool and intuitive for the user
and
c) Would it be feasible to program it and be worthwhile to enough users for the effort involved
It sounds kind of fun - and would be immensely powerful, but I suspect i for one would just manage with tags - assuming Michael builds on the super search gui for tags.
Love the discussions, keeps my brain ticking if naught else.
Ian

That sounds right to me. However, there is certainly a point of diminishing returns, in that supporting custom multi-valued fields would make the interface more complex and require the user to make another choice. I’ve already heard people say that they aren’t sure whether they should be using folders or tags in a given situation. Often, there isn’t a right answer. But when there are too many possibilities, people have a tendency to give up rather than possibly choose incorrectly.

And of course there are coding and performance considerations—there’s no denying that storing booleans is much more efficient. Anyway, my opinion is that although multi-valued fields are in some sense the “right” solution in many cases, creative use of tags provides almost the same functionality with a much simpler interface. And the programming and design effort could (especially at this point in the product’s life) be better spent on other areas that will be useful to more people.

Whoops, sorry, my bad for phrasing things incorrectly. I actually meant that sometimes I organize parent tags in nested categories (Country->France->Paris) and sometimes the parent tag describes something, not about a theoretical tagged object, but about the tags themselves (Status->unread, status->flagged, etc.). If I had the nested tags status->unread, an item I tagged “unread” is not also a “status”. Rather, the tag is a status.

If that makes any more sense.

I’m all for spending the bulk of energies on tags. I’m a tag fanboy. I personally think that a creative combination of tags and smart folders (saved searches) allows you to sort and find things far quicker than ordinary folders or needing to define your own categorical system.

As an aside, having to create a tag cloud can be a daunting task. It would probably help users who are struggling with the idea of tags to provide tag templates (Shoebox from Kavasoft does this).

Agreed, but I find it daunting to create a list tag templates. :slight_smile: Perhaps we should start making a list of the tags that people are using.

Michael wrote:
Anyway, my opinion is that although multi-valued fields are in some sense the “right” solution in many cases, creative use of tags provides almost the same functionality with a much simpler interface. And the programming and design effort could (especially at this point in the product’s life) be better spent on other areas that will be useful to more people.

I agree with Michael’s opinion.
Ian

As of EagleFiler 1.2 there is a preference to make the tags searchable by Spotlight.

EagleFiler 1.4 added support for saved searches (a.k.a. user-created smart folders).