EF vs Yojimbo?

Has anyone used both?

Which do you prefer? And why?

I know this answer is self-selecting, since if you are actively using Yojimbo, you won’t be reading this thread, but I suspect some people have both.

Thanks.

Cheers,
Jon

When EF came out, Yojimbo was my front-runner, but was totally demolished. EF had tags, Yojimbo didn’t. End of story. Then, like a WEEK later, Yojimbo released a major update, with tags. They were pulled neck-and-neck again.

But I think EF is simply better, for lots of small reasons. Things like the absurdly intuitive unicode tag markers, the ability to nest folders, the one-button capture. Also, EF is, it seems, being more rapidly developed than Yojimbo, and I always like to see that.

One area where Yojimbo has the upper hand, I think, is speed—at least on my g5 iMac. On my Macbook, there is no noticeable slowdown in EF, but on the iMac, Yojimbo feels the faster.

Yojimbo also seems to put a lot of space, interface-wise, into weird interfaces that I would never use—like the quick capture overlay, and the folder dock thingie. I think the quick capture mechanism is much dumber (AI-wise) than EF; it has smart-ish data types, but it can’t sniff the data in your clipboard very well. EF uses Applescript, which makes it much smarter.

EF also uses multiple libraries which exist as folders in the filesystem, rather than a single opaque library, like in Yojimbo. I thought this would be a pain, but I’ve come to appreciate the flexibility.

Honestly, they’re both very good applications; I think the only way to tell which is better is to use both and examine how you react to the minutiae of each application: whether the layouts make sense to you, whether the buttons appeal to you, whether you feel like one makes you take more unnecessary steps than the other.

EF launches painfully slowly on my iMac G5 (2GHz, 2GB). Took ~30 seconds on the first launch after updating to 1.1.1; about ~15 after quitting and immediately relaunching. And that’s with just a two-entry Library(!)
In general, the UI isn’t as responsive as DEVONthink Pro (which also launches faster with my largest database).

I’m guessing the Python backend is at least partly responsible for the sluggishness?

I don’t have any Intel-based Mac for comparison. Patiently waiting to replace my iBook G3 (its display died a few months ago), probably after Leopard and/or the Santa Rosa Centrino platform is released. I definitely want a larger display like on the current 15.4" MBP since I suffered with 12" @ 1024x768 for too long. Also hoping for a user replaceable HDD like the current MB has.

EF also uses multiple libraries which exist as folders in the filesystem, rather than a single opaque library, like in Yojimbo. I thought this would be a pain, but I’ve come to appreciate the flexibility.

That’s a tough choice for me because of a strong interest in exploring alternatives to rigid file/folder metaphors.

Honestly, they’re both very good applications; I think the only way to tell which is better is to use both and examine how you react to the minutiae of each application: whether the layouts make sense to you, whether the buttons appeal to you, whether you feel like one makes you take more unnecessary steps than the other.

When evaluating apps in this category I eventually populate the “library” with a large and diverse amount of sample data to get some idea of how well each one will scale in performance and usability. Of course that might be a non-issue depending on the type of usage.

The slow launch time is mostly due to using Python/PyObjC. It has little to do with how many records are in your library or with how EagleFiler is coded. It simply takes a while to dynamically load the OS frameworks that EagleFiler uses: AppKit, Core Data, Quartz, WebKit, etc. Since Apple is making PyObjC an officially supported development environment in Leopard, my hope is that they’ll find a way to improve the launch times of applications that use it. For what it’s worth, this is definitely an area where the Intel chips perform well. On my iMac (Core Duo, 2 GHz) it takes about 7 seconds to launch EagleFiler off the freshly downloaded .dmg.

As to general UI responsiveness, some of that is due to the backend, but much of it is my fault. In developing software, there is sort of a four-way tradeoff between correctness, features, development time, and speed. My number one priority was to make EagleFiler reliable–it would be useless if you couldn’t trust it to store your data safely. And then, of course, it needs a certain set of features to be interesting, and it has to eventually ship. Speed is important in that it has to be fast enough on reasonably new hardware, but it’s otherwise been a secondary goal for the initial releases.

I’ve focussed a lot on making sure EagleFiler’s architecture will scale. It’s important to get that right at the beginning, to be building on a foundation that can last. I think this much has succeeded, as I have tens of GB of files in my libraries, with a few million messages. The UI is sluggish in places, but the libraries are definitely useable, searching is fast, and it doesn’t use a ton of RAM. Part of the UI sluggishness has to do with the correctness that I mentioned earlier. There are times when EagleFiler is doing several things at once where it will freeze for a short while. It’s possible to make this faster, but my first goal was to code it in a way that would definitely keep the data safe. The other reason it can be sluggish is that much of the code is not very optimized, as that would have slowed down development and made it harder to know that the code was correct.

Anyway, I’m not trying to make excuses, but rather to give you some idea of why things are the way they are. I would definitely like the UI to be snappier. There have been some steps in that direction in 1.1 and 1.1.1, and as the existing features become more mature I will be spending more time chipping away at the various slow spots in the code. If there are particular operations that you find sluggish, please e-mail me so that I can be sure to investigate them. Thanks for your patience.

both are truly excellent programs, designed by passionate and responsive developers. Eagle Filer would get my vote if not for one thing: cross-machine sync or usability. Yojimbo’s ability to sync makes it the winner in my installation - since I am on the road weeks at a time and need to be able to access the same info from several machines.

To me, this trumps EF - though with sync or some kind of seamless sharing, I’d jump to EF very quickly.

Would carrying a little USB flash drive work for you? Just curious.

I’ve used Yojimbo and switched to KIT when I learned that BareBones was not planning on having a way to iterate through the library using a script to export every items. I wanted to have automatic incremental backups of my documents in Yojimbo and could not find a way to do it.

What convinced me to switch away from KIT is the presence of tags, the ability to deal with email really nicely, and the amazing responsiveness of Michael.

I use EF on two computers and simply quit it at the end of the day, and synchronize its library using Unison. As I synchronize many things, it’s just part of my workflow.

That makes sense.

Since Apple is making PyObjC an officially supported development environment in Leopard, my hope is that they’ll find a way to improve the launch times of applications that use it.

If it’s not NDA-violating to say, is that related to the Scripting Bridge for Python and Ruby in Leopard? I noticed SB mentioned while browsing Apple’s developer site.

For what it’s worth, this is definitely an area where the Intel chips perform well. On my iMac (Core Duo, 2 GHz) it takes about 7 seconds to launch EagleFiler off the freshly downloaded .dmg.

Hey, you’re making my iMac G5 envious. :slight_smile:

Actually I haven’t been overly tempted to upgrade, especially since it’s the last partly user-servicable model. Nice being able to remove the SATA drive before taking it to the Apple Store for repairs (twice, ugh).

My number one priority was to make EagleFiler reliable–it would be useless if you couldn’t trust it to store your data safely.

Data integrity has always been a top priority for me, nurtured by a long sysadmin career. For various reasons many people (including some developers, alas) apparently don’t take it seriously enough. Backups and backup software on OS X are a favorite example, although that’s been improving. I wonder if Apple will get it right with Time Machine given how bad/sad Backup is.

Speed is important in that it has to be fast enough on reasonably new hardware, but it’s otherwise been a secondary goal for the initial releases.

I survived ~5 years using a 600MHz iBook G3 without its lack of speed becoming overly crippling. Frankly, the need for speed is just an excuse for some people not to learn to use their systems more efficiently.

Anyway, I’m not trying to make excuses, but rather to give you some idea of why things are the way they are.

Your detailed explanation was informative and appreciated, as always.

And I wasn’t complaining, just observing/reporting/inquiring. I tend to make that disclaimer more often than necessary as a result of posts on other forums being misperceived and misunderstood. Never ceases to amaze me how some people are so sensitive and easily offended, irritated, or downright angry.

If there are particular operations that you find sluggish, please e-mail me so that I can be sure to investigate them.

Are there certain types of issues you’d prefer receiving e-mail about instead of being*posted here? I usually prefer the latter if it seems like it might be of some interest to other people. And hopefully mentioning things here helps cut down some redundant e-mail to you about them.

I’ll save my observations/suggestions about using forums as a support resource for some other time/place since they’d tangent this already long enough post even more off topic. I’m guilty of threadjacking more than I’d like to admit.

Thanks for your patience.

No worries. Thanks for your time, etc.

As I understand it (and I believe this is public knowledge), Scripting Bridge is the technology that allows you to control AppleScriptable applications such as iTunes using Cocoa. It translates method calls to Apple events and vice-versa. This has nothing to do with the PyObjC and RubyCocoa bridges except that they all involve “scripting languages” and are built into Leopard.

I prefer bug reports to be sent via e-mail except in the case where you aren’t sure whether what you’re seeing is a bug (and, thus, other people may be wondering about it, too). Otherwise, it’s easier for me to get to the bottom of the bug via e-mail, and most people probably wouldn’t be interested in the details.

Well, I like e-mail because it’s easier to track to-do items and to search. Also, the redundant reports can be useful to see how wide-spread a problem is. I only opened these forums slightly before shipping EagleFiler; prior to that I did everything via e-mail. So far I’m happy with the way the forums are working.

I’m a registered user of both Yojimbo and EagleFiler, having switched away from SOHONotes (I used StickyBrain for years) and MailSteward.

I got hooked on writing in StickyBrain back when they gave v2.0 away as part of the .Mac membership. (Remember when being a .Mac member was cool and actually made sense?) I kept everything in it - all of my writing, addresses, useful snippets of text, to-do lists, and suffered through all of the upgrades before the current explosion of text editors/info managers. Seriously, there are a ton of programs in this vein these days, and I think I own about half of them: KIT, EagleFiler, VoodooPad, SOHONotes, DevonThink, xPad, Mori, etc etc.

I eventually settled on Yojimbo for two reasons - it’s lightning fast when launching and when searching, even on my database of text documents stretching back eight years. (We’ll see if it can keep pace as I start adding PDFs and web archives to the mix, which I never used to do.) The other reason is that it’s created by BareBones, which has been around forever and is likely to continue to be around. I’m fairly certain they’ll keep Yojimbo alive and kicking with new features, though hopefully they’ll avoid the bloat that eventually made SOHONotes unworkable for me on my iBook G4. Not that I won’t upgrade to a better Mac eventually, but I tend to ride the trailing edge of hardware, which can be a tough place to be.

I bought EagleFiler after trying to make MailSteward work, which was a disaster. A $50 disaster. (It didn’t import all of my mailboxes and I couldn’t figure out why, and the UI plain stinks. It is one of the most un-Maclike Mac products I’ve ever made the mistake of paying for.) EagleFiler, on the other hand, just works. It imports mailboxes from Apple Mail like a dream and does it reliably. I can search for that old piece of mail and actually find it. I’ve long been a happy user of SpamSieve so a mail archive solution from Michael was a no-brainer. EagleFiler’s emphasis on being a filing and organization tool as opposed to an editor makes it ideal for storing years of back e-mail, while Yojimbo’s quick-and-dirty emphasis on editing text and collecting data from random sources makes it the tool I look to for writing and squirreling away the snippets of info from my everyday life. (I realize that EagleFiler does some of this too, but it’s definitely slower on the G4 and the emphasis is certainly *not *on editing.) Who knows? If my Yojimbo database gets too large maybe I’ll start filing old notes from it in Eaglefiler. :slight_smile:

So I use them both. Happily. And I hope it stays that way for a while.