It takes zero steps as far as you accept what EF decides.
The dialog box is the alternative I’m talking about which actually is used in most applications which confront a similiar situation, going from the finder itself to any file management or DAM and so on. It looks like what Im saying sounds unlogical, but actually EF is the only application I know that do it the other way around.
Would you care to describe some examples of situations where you would want to keep the existing file vs. the new one?
The point is not what or what I do not want to keep, the point is letting the user decide what to do with his/her files and not EF:
- different metadata (don’t know jet how exactly EF handles metadata)
- different file names
- have the same file in different folders with different names
- have the same file in different folders because they are temporal projects
- I’m a web designer and many times files are identical in different projects.
I know it can be done with extra steps, but when you work with thousand of files these extra steps for a long list of duplicated files in the error window, becomes really… a loooong task.
In theory, I agree that the user should always be able to decide what to do, but in practice if you provide too many options the software becomes so complicated that most people don’t want to use it, and the code becomes more difficult to maintain and keep bug-free. So my aim is to provide only the options that a significant number of people will use.
Of course, you are the programer and base on your experience and user feedback you choose what to implement and what not. Since you have a lot to do.
The user could also choose if he/she wants the duplicate file dialog to appear or not, but I think most users would want use it, since it would make their lifes a lot easier.
This is a pet peeve of mine, but please don’t speculate as to how difficult you think something would be. The fact that you think (not having seen the code) that it would be easy is not going to affect whether I decide to do it. And things are often much more complicated (or, rarely, easier) than they appear.
Of course, you are right, from outside everything looks easy, but every little change represents a big amount of work, which most users do not really appreciate. I didn’t mean that, sorry if my message came wrongly.
For example, in this case:
- It’s not just a matter of presenting the user two choices like with iSync. There could be any number of identical files that are in the library or are in the process of being imported.
In this case it would help the user to have a wider overview, of what is going on with all the files, don’t you think so?
- These files may have different metadata, so you’d probably want to be able to examine that when choosing.
Well, this is one of the main points why EF should NOT choose what to do, since it cannot decide which metadata is more relevant.
- Each import operation is multi-threaded, and there can be multiple import operations active at a time.
Well, the dialog could appear when the import process is finished (as isync) or as the error window itself.
- Import operations can be stopped by the user.
Let it do it when import is finished (as isync)
- The import might have been invoked by a script, in which case user interaction might not be desired.
Again, Let it do it when import is finished (as isync) or the own error window of EF.