Awesome app!!

I’ve tried virtually every freeform database for Mac (Yojimbo, K.I.T., Journler, etc.) and Windows (Treepad, AskSam, Ultra Recall, etc.). EagleFlier is exactly what I’ve been looking for - a tree-like structure with easy drag-and-drop of web pages, PDFs, etc. combined with powerful search features.

A few quick comments:

Love the simple, non-proprietary storage method for imported files.

Auto-open of last database at startup would be swell. In the meantime, it is easy enough to make an alias to the .eflibrary database and double click that instead.

Is it possible for EF to act more like iPhoto or iTunes when deleting files from folders (i.e., the original file is not deleted from the Library)? Also, can a single file be stored in multiple folders? This would affect the current storage mechanism, I suppose, wherein files are stored in their respective folders. Perhaps symlinks could be used?

Being able to encrypt either individual items or the entire database would be nice.

Thanks so much for crafting my dream app!

Gratefully,

Miles

Auto-opening the last libraries is already implemented for the next version. Linking within the library and encryption are on the list of features to investigate. However, it is possible to make a file appear in more than one place if you use tags in addition to folders. You might use folders for the primary classification and tags for secondary ones.

I think EagleFiler works like iPhoto, where deleted items are moved to the trash, and when you empty the trash they’re removed from the file system. Could you explain why you prefer the iTunes model? Personally, I think it’s confusing to have a file in the library folder but not “in the library.” Also, I like having the trash (which iTunes doesn’t have), and I don’t like how iTunes asks what I want to do each time I delete a file.

iPhoto/iTunes like file handling
Aloha, Michael! Many thanks for your fast reply.

Here’s what I mean by handling imported files like iPhoto/iTunes:

Let’s say I drag a photo from the iPhoto Library into an album called “Maui Vacation” and another album called “New Friends”. Deleting the photo from the “Maui Vacation” folder does not delete the photo from “New Friends” or the Library. The same thing goes for songs in iTunes’ albums. And in both apps, deleting both folders would stilll leave the original album/song in the Library.

Whereas in EF, an imported file (say, a PDF) can only “live” in one folder, so dragging the PDF from one folder to another actually moves the file. And deleting the folder it lives in deletes the file from the Library as well.

INMO, this iPhoto/iTunes method has become the standard. It works quite well and is much faster than having to fuss with tagging, etc.

Again, many thanks, and congratulations on creating the best app of its kind!

Sincerely,

Miles

Hi Miles,

OK, so you’re not really talking about how iTunes and iPhoto handle deletion from the library, but rather how they handle playlists and albums. The folders in EagleFiler have a direct correspondence with folders in the Finder, so I think they should behave like folders. It’s the same as in iTunes and iPhoto where everything under “Library” (songs, film rolls, photos) refers to the actual file. A song can only have one artist and album, and a photo can only be in one film roll. And if you delete an item in the library, it goes away, even if it’s part of a playlist or album.

Playlists and albums are a different concept, which I think is basically the same as tags in EagleFiler, except that tags are a bit more flexible. You can treat tags as keywords (assigning them by typing or checkboxes) or as playlists/albums (assigning them by dragging into the tag sources).

The difference is that, at present, deleting a file from a tag source deletes the file rather than just removing it from that tag source. I agree that there should be an easy way of just removing it from that tag, but I haven’t figured out the proper interface for this yet. iTunes handles it by not allowing you to view a playlist and the library (or even two playlists) at the same time. iPhoto allows you to view two albums at once, or an album and a year, but you can’t delete unless only a single album is selected. I could make it so that if a single tag is selected deleting removes the tag, and otherwise deleting moves the file to the trash, but I wonder if that would be confusing.

Thanks for explaining your views on this issue, Michael. I guess I consider playlists and albums closer to folders than tags in EF. Tags require additional steps to setup and then to label items, whereas dragging and dropping is virtually instant.

“And if you delete an item in the library, it goes away, even if it’s part of a playlist or album.”

True, but if you delete an item in an album or playlist, it does not go away from the Library (which is what happens in EF).

In any case, this issue is by no means a deal-breaker for me. I will be registering today.

Gratefully,

Miles

I don’t understand why you say that. In iPhoto you have to create an album, and in EagleFiler you have to create a tag. Are you saying that you want a different (easier) way of creating a tag? Once the tag is set up, dragging and dropping onto it is exactly like dragging and dropping onto an album in iPhoto.

This is what I was getting at in my last paragraph. I’m open to changing the way it works, but I’m not sure how it should work. What do you think should happen if two tags (or a single tag, or a tag and a folder) are selected in the source list, then the user selects a file that may be in one or both of those tags, and presses Delete?

The iPhoto answer is that if one album is selected, deleting deletes from the album. OK. But it doesn’t let you delete at all if more than one source is selected. Is that acceptable to you?

Aloha, Michael!

I don’t understand why you say that. In iPhoto you have to create an album, and in EagleFiler you have to create a tag. Are you saying that you want a different (easier) way of creating a tag? Once the tag is set up, dragging and dropping onto it is exactly like dragging and dropping onto an album in iPhoto.

Tags just don’t maintain the same context as having the files appear in their respective folders. And having to create tags rather than drag items to the folders I want them to appear in takes more time. Forgive me if I am not on board the tag bandwagon - I’m still a Treepad junkie.

What do you think should happen if two tags (or a single tag, or a tag and a folder) are selected in the source list, then the user selects a file that may be in one or both of those tags, and presses Delete?

I think the only time files should be deleted is when they are deleted from the Library (just like iPhoto and iTunes).

The iPhoto answer is that if one album is selected, deleting deletes from the album. OK. But it doesn’t let you delete at all if more than one source is selected. Is that acceptable to you?

Yes.

Gratefully,

Miles

P.S. Just registered - thanks so much for your time and dedication to this app and its support.

I’m just trying to understand what’s bothering you. I don’t see the difference. What do you mean by “context”? Folders and tags both have to be created, and once they exist you can drag items into them. So why do you say that tags take more time?

I’m just trying to understand what’s bothering you. I don’t see the difference. What do you mean by “context”? Folders and tags both have to be created, and once they exist you can drag items into them. So why do you say that tags take more time?

Um, “bother” is probably too strong a word here. “Context” means the tree-like outline structure itself contains valuable information about the data and its relationship to other bits of information. Tags don’t maintain that structure. After having created that stucture, I’d love to be able to drag and drop files freely between folders without having to spend more time on tags. If that is still not clear, I’d be happy to call or IM you to explain verbally.

Let me try to be more clear. Folders in EagleFiler are like folders in iTunes. In iTunes, the songs are arranged in folders by artist and by album, and this is completely separate from playlists. In iPhoto, the files are arranged in folders by year and by film roll, and this is separate from albums. In EagleFiler, files are arranged by folder, and this is separate from tags. Files can only be in one folder, but they can be in multiple playlists/albums/tags. In all three apps, deleting from a folder removes the item from the library; deleting from a playlist or album just deletes it from the playlist or album, and I plan to make EagleFiler tags work this way, too.

As to structure, tags cannot currently be nested in EagleFiler, but that’s just a limitation of the current version. In iTunes and iPhoto you can make folders of playlists and albums, and there’s no reason this couldn’t work for tags, too. (In fact, support for this is already built into the current EagleFiler file format; it just hasn’t been hooked up yet.) Perhaps you’ll like tags better when they have structure as well. Then they’ll be essentially what you’re asking for. I think the way to look at it is that, by letting you see the folders in the Library, EagleFiler is giving you more control than iTunes/iPhoto. However, you can also ignore the folders in the Library source, and then EagleFiler is just like iTunes/iPhoto except that it uses the term Tag instead of Playlist/Album.

Thanks for the feedback and for purchasing. Now that I understand your position better, I think we agree on how EagleFiler should work.

As to structure, tags cannot currently be nested in EagleFiler, but that’s just a limitation of the current version. In iTunes and iPhoto you can make folders of playlists and albums, and there’s no reason this couldn’t work for tags, too.

Yes, that would be swell. I also realize that when I was saying “folder” in earlier posts, you might have taken that to mean folders as they appear in the file system. I just meant folders as they appear within EF, which I took to be more like albums or playlists.

In all three apps, deleting from a folder removes the item from the library; deleting from a playlist or album just deletes it from the playlist or album.

Yes, but there is no interface within iTunes or iPhoto to delete the folder - one would have to use the Finder or Terminal to get to it and then delete it. Again, I thought folders within the EF interface were meant to serve more like playlists. Sorry for the misunderstanding.

As of EagleFiler 1.1, tag sources behave like playlists/albums in regards to deletion.

Wow!
Amazing amount of work you’ve put into 1.1, Michael! It should have been at least 1.5 or even 2.0 based on how much you’ve done. I love the nested tags feature, auto open of last database, capture support for individual emails, etc, etc. I can’t think of a single feature request! Excellent!

I haven’t thoroughly read this thread so my apologies for any redundancy …

That was my a priori expectation (and hope), too, as I began testing EF today. Then I anticipated that selecting a folder containing subfolders and documents would display a list of the union of documents within each subfolder (like iPhoto/iTunes), basically creating a subset of the Library view without explicitly selecting (sub)folders. From there drilling down into the hierarchy would reduce the view to smaller subsets.

So far I’m left with the impression of EF having both a Finder-like and iPhoto/iTunes-like UI, which isn’t immediately intuitive or comfortable to me. I’d prefer it behaving closer to iPhoto than Finder (or even iTunes), with the Library being an unhierarchical view of every document and the ability to construct a variety of virtual hierarchies/views from it. Removing an EF “folder” (analogous to an iPhoto album) wouldn’t actually delete documents unless explicitly requested. And documents could easily appear in multiple “folders”. Sort of like tags, with the ability to be easily organized within different structural views (like TinyApps.Org’s “context”, as I understand it).

I think Yojimbo uses that kind of all-inclusive Library metaphor, but doesn’t support hierarchical views.

And at times I’ve been critical of DEVONthink for its dependency on rigid Finder-like hierarchy of groups, with the History window being the closest thing to a Library view. You can sort of simulate “the Library” by leaving every item in the top-level (root) group and cloning (aliasing) items into various group hierarchies, but it’s not designed to be used that way (I’ve tried; I’ll spare details of my failures).

Even if I were more familiar with other organizer/outliner apps this post is already too long to analyze them.

I’m no expert on the topic, but I’ve thought and written quite a bit about it over the past few years. The gist is how hierarchical filesystems and “desktop metaphor” have negatively influenced UI design. I see an increased urge (or necessity, for scalable usability’s sake ) to find and use design metaphors that can be more effective for organizing/managing ever-growing amounts of data when hierarchical boundaries are optional or dissolved. The relative proliferation of “o/o-style” apps on OS X, with similarly recognizable yet “slightly” different UIs with overlapping functionality, is one symptom of that effort.

I have great appreciation for what EagleFiler, DEVONthink, Yojimbo, OmniOutliner, KIT, et.al. developers are doing regardless of any personal preference for one of more apps in their category. And I’ve wondered if Apple’s lackadaisical Finder development is a mixed blessing in disguise as partial inspiration for some of them.

If it did that, how would you see the immediate contents of a parent folder? The iTunes solution is to only let you put files at the leaves (playlists), but that won’t work for EagleFiler. Since EagleFiler folders match the folder hierarchy of the library in the Finder, I think the only reasonable design is to make them behave that way in EagleFiler, too.

I think that’s how it does work. The Library source is like in iTunes–it shows everything in one big list. Then you can use tags to create virtual hierarchies with the properties that you describe.

EagleFiler 1.2 lets you create encrypted libraries.

Hi! I haven’t thought this through, but would it be possible to encrypt individual items within EagleFiler using some of the tools in the Mac GPG project?

Yojimbo’s ability to encrypt individual items is the main reason I still use it.

Dave

Perhaps, but this raises all sorts of issues, and I’m not sure how useful it would be. Performancewise, it would probably be much slower.

First, this sort of encryption wouldn’t play well with other applications, since they wouldn’t know how to decrypt the files (or re-encrypt them after editing). With the current design, this is transparent.

Second, EagleFiler maintains indexes to speed up searching, and this gets messy when some of the files in the index are encrypted and others are not, especially if the files have different passwords. With the current design, it’s very simple because there is one password per library, which EagleFiler uses to encrypt all the files, indexes, and temporary files.

For now, I recommend creating two libraries (one encrypted, one not) if you only want some files to be encrypted. If this is not a good solution for what you’re trying to do, I’d be interested to know why.