How to design a 'Search for Duplicates' GUI in an Image Cataloging Program

Question

We have an image cataloging program in which we have a database holding the already cataloged images. Let's call them "The Archive".

Of course, everyone wants to keep the Archive clean, hence we need a GUI for searching duplicates in the Archive.

Besides the "Archive" users get photos/images from a myriad of sources: Internet, stock agencies, coworkers, friends, freelancers etc. etc. etc.

Hence, depending of situation, we need to check these new images (let's call them 'Candidates') if among them there are duplicates.

So, there are situations in which the users want to check their Archive for duplicates and there are situations to check their Candidates for duplicates.

But, also, there is the 3rd case in which the users want to check the Candidates against the Archive - perhaps a part from Candidates already exist in the Archive.

Behind the logical reasoning, the differentiation between Candidates and Archive is very important because:

1. searching through Archive is much much faster (due of DB backend)
2. by choosing how to search (eg. only between Archive and Candidates) we greatly reduce the number of comparisons. (in our example because the user accepts that Archive and Candidates are ok).

A GUI proposal is the wizard-like draft bellow: (the 3rd page are the methods of comparison - not directly related with the question)

How can we improve the above?

Answer 1

Fast/slow storage could be indicated by an icon, such as a snail vs. "speed stripes". It doesn't warrant separate input controls, because functionally they are the same.

Rather than making this two separate boxes for the user, give feedback:

• if you know the number of files, you can give a number of comparisons.
• if the user has selected the "slow" comparison, factor that in
• if you are still busy enumerating the files (in background) you can at least say "over two million slow comparisons". Users quickly learn that this isn't a good idea.

---

The first two property pages could be folded into a simple one without losing core functionality:

look if this
[list of locations]
[x] Look for duplicates within this list

contains images from here
[list of locations]

The only use case you lose is checking inbox for duplicates, checking archive for duplicates then checking between them. Seems hardly relevant enough for a single step to me.

---

The simple layout above can be extended by allowing the users to define their own locations that are collections of locations.

For example, I could create a location "Inbox" containing my download folder, %USERPROFILE% and camera memory cards. This keeps it simple when beginning, and can be discovered once users experience the limits of the simple design.

(I don't consider this "final" in layout or wording, I'm just trying to break down your first two pages to a bearable minimum.)

Answer 2

About naming. Archive is something rather old, non-actual, rarely used and covered by dust. So maybe better name is Collection?

I think you very concentrated on functionality, but less to user goals. The main user goal is to organize the photos and to get quick access to them.

Duplicates elimination is not user goal, it's a feature that helps to cope with huge amount of photos. It is no doubt very useful feature, but I cann't imagine user start your program and finds duplicates instead of browsing the catalog.

So my suggestion is don't make user think and act on something, that has no direct link to his goals. Let user always add all the photos to the collection. But do search the duplicates automatically, on the background, in the way not visible for user (and not consupting his time and efforts). So a user shoudn't do it explicitly, it is internal software feature.

For all the fresh photos apply concept "Recent", not "Candidates". And even if there are duplicates in Collection and Recent, make fresh photos accessible through Recent. It is user mental model: "I've added that photo yesterday, so I can find it in Recent folder".

It doesn't mean you collection contains dublicates, remove them, but do it in a smart way without disturbing a user. So you need no interface (at least, such complex) for this.

So resume is, concentrate on real user needs, automate and make transparent for user all the secondary tasks.