More feedback
A couple more questions have come in. Nick says "I'm curious to know why don't you use Curio for filing as well. It seems to me that it can keep track of files and docs as well or better than Eagle Filer (which I have tried at least four times in the past 6 months and found to be too buggy)."
First of all, Nick, what bugs are you seeing? I run EagleFiler constantly, and I haven't had a single problem - is there some subtle thing that I am missing? Now, to answer your question: Curio is not designed as a "filing" application, but as a visual thinking environment. Certainly you could use it to organize files, but in my mind the Curio metaphor is a bit like pinning documents to a cork board, rather than placing them in a filing cabinet, which is the way I think of Eaglefiler. Further more, Curio does not lend itself to creating simple text documents on the fly - it needs to create a whole idea space every time. I use Curio to capture bulk information (I'm in a training course now, and Curio has my morning's notes in it), but if I just need to scribble down a URL or a password, it goes to EagleFiler. I think what I am trying to say is that EagleFiler suits the way my brain works when it comes to litter sorting. Your mileage may vary.
TheWolf asks "What I'm wondering is why you gave up using DevonThink Pro, because all the other software you reviewed was discussed more, but because Devon was your older software, it didn't seem to be mentioned much. What makes EagleFiler so much better than DevonThink? I'm trying to decide if I should try DevonThink or not. It seems to have a learning curve."
In answer: I haven't stopped using DevonThink Pro, but I use it in slightly different ways. I think I am using DT less, now that I have EagleFiler, but DevonThink still provides me great functionality for specific purposes. I find DT slower to start up than EagleFiler, but that is probably because I use DT to store and manage really big documents, mostly technical manuals in PDF format. The problem I had with DevonThink (apart from its learning curve, which is steeper than EagleFiler's) is that it doesn't always let you get a document back out in quite the same format that it went in. I just retested this, by importing and then exporting a fairly simple Word document. DevonThink preserved the text pretty well, but ate the footers. This was a show stopper for me. I've also had a couple of incidents where the database corrupted, and I had to restore from backups.
I'm happy to expand on this if anyone needs more detail. If you want to chat offline, look me up on LinkedIn, and you should be able to work out my email address.
Addthis
10 comments:
Melodie, have you had a chance to look at Leap (the spin-off from Yep) yet? I remember in your original review of Yep, not supporting arbitrary filetypes was a dealbreaker. Now that's fixed with Leap.
I've been using it since the early betas, and I like it a lot more than EagleFiler. Like EagleFiler, it uses your filesystem as a datastore, so you can drag things into Curio directly, and there's no export/import messing like DevonThink. What's more, it doesn't force you to keep your files in a specific location, though you can keep all your files under a hierarchy under one folder if you like, and there is no slow import step like EagleFiler.
Even though it doesn't have the same UI polish as Yep yet (it's still a beta v.1 product though), it is much more Mac-like than EagleFiler. (In my opinion EagleFiler really suffers from being written in a Python-ObjC bridge, rather than as a regular ObjC Cocoa app. I realize that makes it easier for a single programmer to develop, but the user interface has a bit of a 'Linuxy' flavor.)
Anyway, those are just my feelings. But it's definitely worth taking a look.
I don't think EagleFiler is buggy. In fact, people write to me saying that they switched to it partially because of its reliability. It's certainly possible there are bugs that I don't know about, but as far as I can tell, I've received no bug reports since EagleFiler was released from anyone named Nick. Please do me the courtesy of reporting any problems that you encounter, so that I can determine whether there's a bug and, if so, fix it.
Chris Thompson: First, you're mistaken that anything good or bad about EagleFiler's interface is related to the fact that parts of it are written in Python. PyObjC is not like REALbasic/Tk/Qt where the application is written to a cross-platform framework that sits on top of Carbon/Cocoa. On the contrary, EagleFiler is using the exact same Cocoa frameworks and APIs as any other Cocoa application. The hybrid approach allows me to take advantage of both languages' strengths. Apple recognizes that this is a good idea, and they've built PyObjC into Leopard. In any case, all this is under the hood and shouldn't affect the user interface.
Second, I don't really know what to make of the fact that you think EagleFiler feels "Linuxy." I've been a Mac user for more than 20 years. For 2/3 of that time I've written about Mac software, with a focus on user interface details. So I really care about applications being Mac-like. With EagleFiler (as with my other applications), I've gone to great lengths to follow Apple's interface guidelines, and to follow the Mac way in areas where the guidelines or frameworks are incomplete. (One example: the Unix/Windows/NeXT way would be to use paths, but EagleFiler uses aliases to keep track of which libraries were open when it quit, so that you can move the libraries around without it losing track.) I don't mean to imply that EagleFiler's interface is perfect, but frankly when you say it's Linuxy I just don't know what you mean. If you'd like to offer specific constructive criticisms, I'm listening.
Michael, I didn't mean for my post to come across as some kind of attack on EagleFiler. I know how much work it is to develop applications, and just getting a commercial app out the door is a major accomplishment which you should be proud of. I'm just reporting my personal impressions.
I realize that PyObjC creates "first-class" Cocoa apps (if you would have read my post carefully, I think it was clear that I understood that -- you didn't have to explain it to me). However, it's also true that using PyObjC to do more complicated Cocoa tasks is not as natural, and it's much harder to take advantage of some of the ObjC libraries other developers are creating and sharing, which is why (to me... again, I'm only reporting my impressions), EagleFiler feels like an app developed in Qt or WxWindows, not the Cocoa app that it is.
For instance, the source list on the left hand side of the EagleFiler window looks completely different from the source lists used in iTunes, iPhoto, Mail, etc. This is what I mean when I say it doesn't feel like a modern Cocoa app, and that it has a foreign feel. There are other aspects to this as well, e.g. the lack of modern Mac application idioms like HUDs, the perceptibly slower speed than most pure ObjC apps (could be Python garbage collection, could be marshalling through the ObjC bridge, I don't know, but it feels slower, in the same way that Java apps that use Cocoa widgets feel slower). Again, these are my feelings. Other people may have different impressions. No app is right for everyone. But I think if you honestly take a look at Leap versus EagleFiler, it's pretty clear which of the two applications tries harder to follow modern Mac application conventions, behaves more like Mail or iTunes or iPhoto, etc.
It's not just looks though. Leap provides more ways of looking at my files (one of my biggest gripes with EagleFiler is there's no unified graphical view, you only have the choice of looking at your files one-by-one, by clicking through a list, rather than seeing them all displayed visually side by side as icons, which is a pain for images, PDFs, certain types of documents, etc.). Both Leap and DevonThink have icon views. The tagging UI for Leap (or WebnoteHappy for that matter, which is basically the same) is far superior to the tagging UI for EagleFiler.
Some people may really like EagleFiler, so it's worth trying too. But people should also consider the alternatives.
Chris: I believe you when you say that you knew that PyObjC creates first-class Cocoa applications. However, I don't think this was at all clear in your post, especially for less technical readers who may not know what "bridge" means in this context.
You say that "using PyObjC to do more complicated Cocoa tasks is not as natural, and it's much harder to take advantage of some of the Objective-C libraries other developers are creating and sharing," which I think is totally false. I don't really know what you mean by a "complicated task," so I can't respond to that specifically except to say that I haven't run into any programming tasks that didn't feel natural. As far as libraries, EagleFiler uses the RBSplitView and NDHotKeyEvent libraries, as well as some libraries that I wrote. There are many other Cocoa libraries available, but these were the ones that best provided the functionality that I needed. It's not clear to me which library you think EagleFiler should have used so as not to feel like a Qt app to you.
You have some criticisms of EagleFiler, which is fine. And you figured out that it's partially written in Python. OK. Then you arrived at the conclusion that the former are because of the latter. I think this conclusion is mistaken and that you've provided no evidence for it.
The source list is an interesting issue. As far as the Cocoa frameworks go, there is no such thing as a source list. To get an appearance that differs from the regular table/outline view, the application must draw it itself. EagleFiler 1.2.5 draws its source list like the Finder in Tiger. When Tiger shipped, this look was standard across virtually all applications except for Mail. It's still quite common, even in flashy applications like Delicious Library, and it's what Apple's human interface guidelines say to do. With iLife '08, iWork '08, and Leopard, Apple has changed to a different look, with a blue background, capitalized group names, shadows, etc. (Unfortunately, it looks slightly different in each application.) It seems like quite a stretch for you to say that not using the Leopard appearance gives EagleFiler a "foreign feel" when Leopard hasn't even shipped yet.
I'm currently finishing up an update to EagleFiler that will adopt the more modern source list look. It actually looks much closer to the Apple appearance than Leap or the third-party source list libraries. In any case, the source list appearance has nothing whatsoever to do with PyObjC.
Where do you think EagleFiler should have a HUD? iTunes and Mail don't have HUDs. Do they feel like Qt applications to you?
EagleFiler launches relatively slow, and that's due to PyObjC. There may be ways to improve this with Leopard. I'm not aware of other aspects of it being slow compared to other similar applications. In fact, I often get comments telling me that it's faster at searching and with large numbers of documents. If there are particular areas or widgets that you feel are slow, please tell me and I'll try to optimize them. If something's slow, I accept the blame for that, but I don't think it's helpful or accurate for you to assume that whatever UI slowness you observe is due to PyObjC. You haven't seen the code or profiled Python and Objective-C versions of it. Performance issues are anything but simple, and there are actually a number of areas in EagleFiler where I found that Python was much faster than Objective-C.
As far as the other information manager applications go, I agree that people should consider the choices and see which works best for them.
I'd be interested to know what, specifically, you like about the tagging UIs for Leap and WebnoteHappy. It seems to me that, for assigning tags, they are virtually identical to EagleFiler. Each provides a token field for typing in tag names. For browsing, WebnoteHappy has a tags columns view. Leap provides a vertical list of tags, which is similar to EagleFiler except that (a) it's in a separate column from the source list, and (b) the tag sizes vary according to the number of files with that tag.
An icon view is certainly something I'm considering. However, it's currently not a high priority because few people have requested it compared to other enhancements.
Michael, that's quite a response and I don't have the time to get drawn into a discussion that's ballooning into something of this length, especially with someone who's livelihood partially depends on EagleFiler. You'll always have more time for words than I.
I hope this doesn't come across as negative sounding, but I do feel that both of your responses are a little patronizing in some places. Just because I'm sharing my personal impressions and speculations about the overall user experience doesn't mean I don't understand the underlying issues or are thinking about them illogically. For instance, you didn't have to explain to me that there is no official Cocoa implementation of iTunes-style source lists. I know that. I have as much of a technical background as you do, and I understand the issues, though I am just a hobbyist, not a commercial developer any longer (I've since moved into the legal profession).
The thing is, from a user's perspective, users don't care about the reasons why something behaves or looks differently. It's not enough to say that there isn't an Apple-approved widget for this, or the HIG (which gets updated slowly and is always years behind current practices) says something slightly different, when everyone, including iWork and the iApps, is going the other way.
(That said, you really should try to comply with some of the HIG regarding icon design. EagleFiler's icon violates some of the rules (e.g. the perspective suggestions and the shading suggestions), which is just another thing that makes the app feel like a Linux port, rather than a Mac app. I realize the HIG icon guidelines are not perfect, but it's easy to see that the EF icon does not follow trends in modern icon design just by putting it on the dock and seeing how out of place it looks compared to most other apps. This is just a minor thing, I know, but first impressions matter.)
One of your comments that I'd like to address directly is the following:
"You have some criticisms of EagleFiler, which is fine. And you figured out that it's partially written in Python. OK. Then you arrived at the conclusion that the former are because of the latter. I think this conclusion is mistaken and that you've provided no evidence for it."
While I've explained my arguments well enough already in the previous post, I would like to point out that I didn't figure out your app was partially written in Python by somehow opening the bundle and rooting around inside. I tried it out for a couple of weeks, and it was the combination of little niggles that made me suspect it wasn't written in pure ObjC/Cocoa. You may not appreciate how obvious this is (it's your baby after all!), but Mac users tend to be discriminating and pick up on little details that aren't right, and those little details add up.
Let me be clear about this: what I'm saying is that the EagleFiler user-interface itself made me suspect that it was written in a scripting language, NOT the other way around. I didn't find out it was written in a scripting language and then decide based on a personal prejudice against scripting languages to dislike the UI. You're assuming the latter scenario is the case, when in fact it was the former. (In fact, when I decided EF wasn't right for me, I didn't actually know for sure whether my suspicions were right, it was only through some scuttlebutt (probably on Daring Fireball) several months later that my suspicions it was written using a scripting language bridge were confirmed, and I put two and two together and concluded it was probably Python.) To be clear, the language doesn't matter, only the UI. I wouldn't care if it was written in COBOL if it didn't have wrinkles that made it feel un-Mac-like. It does have those wrinkles. You may not see them, or not see them as significant, but they give it away.
Regardless, most of the above is just geek wankery. Let's get down to features. Probably most important to me, EagleFiler's interface is optimized to handle only a very small number of tags. You can show all the tags you've used by popping open the disclosure triangle in the source list, but scrolling through a linear list like that is a pretty primitive way of dealing with potentially hundreds of tags. Other applications have various approaches to dealing with this issue (Yep has scrubbable tag clouds, Leap has less-interactive but still zoomable tag clouds, WebnoteHappy allows you to narrow the list of tags by selecting one, then it displays all possible intersecting tags (a smaller list) in a list to the right, etc.). EagleFiler doesn't have anything like that. Make no mistake, these aren't just gimmicky features, they make it possible to manage larger libraries more efficiently.
Similarly, I don't want HUDs just because they're nice-looking, but smart use of HUDs can make tagging much more fluid. Yep is probably the best example of this, with a HUD with various categories of suggested tags popping up only when you need it, then it goes away. This is nice in two respects: you can refer to the document's contents (e.g. author, byline) through the semitransparent HUD if it's covering something you need to refer to, without having to grab the mouse and move it, but more than that, the use of pop-up HUDs allows you to optimize your use of screenspace for the browsing case, rather than having to make space for inspectors that linger around even when much of the time you don't need them. Again, there are multiple approaches to user interface design, and I'm not advocating any one in particular, but there are competing apps that do have some very good ideas for optimizing tagging workflow, and that aren't just using HUDs because they seem flashy and the "in thing" to do right now.
Another EagleFiler feature I didn't like was the floating drop window. Why is it needed? Especially in the single library case, the EagleFiler icon is already on the dock, and it's a fine drop target, why would the user want another window floating around just for a drop target? Even in the multiple library case though, it's not well-thought out from a UI perspective, since you have to navigate to the drop window, switch the target library by choosing it from the drop down box, then navigate back to whatever window holds the icon you intend to drag and drop, then drag and drop it onto the EagleFiler drop window. It's a multi-step process that's not well-thought out in my opinion.
This is much too long already and I have a lot to do today, so I'm going to have to leave it at that. Again, maybe I'm a picky user, but user interaction/interface design is a hard problem (it goes far beyond arranging system widgets), and it's worth imitating other developers who stumble onto approaches that make sense.
Chris: I didn't intend for the responses to sound patronizing. I was simply trying to be as clear as possible, keeping in mind that while you may understand certain technical details, it's not safe to assume that everyone reading the post will.
Much of this is a matter of personal impressions and opinion. I wouldn't have replied in the first place except that you made what I thought were some incorrect implications. Reading your previous posts, it's easy to get the impression that you think EagleFiler is fundamentally limited in what it can do because of its implementation language(s). First you wrote that it "really suffers from being written in a Python-ObjC bridge...I realize that makes it easier...to develop, but the user interface has a bit of a 'Linuxy' flavor.)" Then you wrote that "using PyObjC to do more complicated Cocoa tasks is not as natural, and it's much harder to take advantage of some...libraries...which is why...EagleFiler feels like an app developed in Qt." You haven't defended these statements, so hopefully you agree with me that your interface criticisms and suggestions are orthogonal to which development tools were used.
I agree with you that users want a modern source list. EagleFiler will have one when Leopard ships. I was trying to explain some of the background to that issue because you had used it as an example of why EagleFiler feels to you like a Qt app. There are lots of well-respected Cocoa apps that currently have source lists like EagleFiler's, including Delicious Library, OmniOutliner, Transmit, Yojimbo, and WebnoteHappy--plus various Apple apps.
I'm working on an updated application icon, but it's not ready yet.
I didn't find out it was written in a scripting language and then decide based on a personal prejudice against scripting languages to dislike the UI. You're assuming the latter scenario is the case, when in fact it was the former.
The reason I was assuming the former is that you didn't provide any specific examples of your reasoning. There are lots of little details that Qt, Tk, wxWindows, etc. get wrong and which are clear signs that the application isn't Cocoa. But, instead, you mentioned the source list appearance and the speed, both of which vary widely across Objective-C Cocoa applications. In fact, most users have reported that EagleFiler 1.2.x is much faster than previous versions, which is evidence that the implementation language isn't why it was slow.
As far as the specific features that you mention, obviously there are things EagleFiler could do better, and new features that could be added. I welcome suggestions, although this blog probably isn't the right place for them. The user interface is a "hard problem," as you say it's never "done." Anyway, the reason I responded to these points is that I was taking issue with the implication that EagleFiler feels "foreign" or like a Qt app because it doesn't already do all these things. I'm not saying that HUDs are gimmicky; I'm saying that most apps don't currently use them, and that it's not obvious whether or where they should be used.
Another EagleFiler feature I didn't like was the floating drop window. Why is it needed?
Some people like it as an extra drop target (seriously; they've told me this) and as an indicator of which library has focus for the capture key. If you don't like the Drop Pad, just close it. EagleFiler will remember that you closed it, and it won't show it again.
@chris : thank you so much for saying much more eloquently than I ever could my exact feelings on EagleFiler. I agree with everything you've said 100%, and have had conversations with Michael about it on other forums.
I want so badly to like and use this application, but something about it just doesn't feel right.
And, no matter how much Michael might argue about it, this application is slow, slow, slow! on my G4 Powerbook.
I've been meaning to follow up that last comment from Grimper. First, "something about it just doesn't feel right" is a bit vague, can you give examples? I've had to recode things myself, to get around the "it didn't do what I expected" bug report. The code did what I expected, just not what the user expected. If a developer knows what the user expects, they can usually either accommodate the expectation, or write a disclaimer so there is no confusion.
As to speed, I've had no performance problems with EagleFiler on either my G4 Powerbook or my MacBook Pro (OK, it's faster on the MacBook, but I expected that). Can you quantify "slow", and provide system specs, size of your Library (both MB and items) and some detail from Activity Monitor about system resources and load? Also, what else are you running concurrently?
Chris: I have to say that I don't see much advantage in Leap that you can't duplicate to a large extent with the creation of a few smart folders in the new Leopard Finder. Of interest to me will be how the developers of DevonThink, Yojimba, EF, Journier (all of which I've used; a few of which I've bought) and other like-minded software respond if Finder continues to improve.
These comments have become quite enlightening in terms of what it takes to make a good mac app. And in my opinion, EagleFiler is a great mac app.
I've taken a look at Leap and I think you can't really make a comparison of the two because EagleFiler is an archive app and Leap is more of a alternative to the Finder, it even states that on their website.
Post a Comment