I noticed two limitations about the way instances are presented:
There is no visual distinction between replicants and duplicates in the search results when the search term matches the item names.
There is no visual distinction between regular replicants and replicants that are also duplicates. They both look the same (red).
Please see the attached mock-up for some possible solutions:
Excellent suggestion; nice mockup. I’d probably prefer the Attribute Icons method. Btw, searches only match a single instance of replicants (which I’ve previously mentioned seems counter-intuitive to me, partly because my Unix background wants searching to treat them like hard links).
Two issues (also reported with a support ticket):
• Replicate an item and delete one instance. Color is retained on both instances (i.e. untrashed and in Trash); seems confusing not to exclude items in Trash from influencing untrashed items in this and possibly other ways.
• Duplicate an item and delete one copy. Color is removed from the untrashed copy (as desired/expected) but retained on the Trash copy (buggy behavior).
I’m glad you brought up the issue regarding a single instance of replicants in search results. I noticed that too. At first I wasn’t that concerned because I thought I’ll just keep using duplicates instead (like I was doing in Firefox). But then I came across some comments from the developers about the new tagging feature/interface and how it will make use of replicants and groups. And that’s when I started to panic. Ok, it wasn’t that bad, but it’s a big bummer because I was looking forward to the new hierarchical tagging feature and started daydreaming about how it could improve my workflow or even completely change my categories structure. If this issue doesn’t get fixed, I’m afraid I will not be able to make use of tagging or replicants. Let me explain why (sorry it’s a little long):
My bookmarks or rather my categories hierarchy (tree structure) has gotten very large, to the extent that it has become difficult to manually navigate to a specific group (category) when adding a new bookmark. Not only does it take lots of clicks to get to the right group with such a deep hierarchy, but remembering the name or location of that group in the first place has become a matter of trial and error that would result in endless clicking. This might be acceptable if you don’t add a lot of new bookmarks on a regular basis, but in my case, any small improvement that speeds up the filing process would have a significant impact on my productivity.
The best way to add a new bookmark under these conditions is to first search for a category or a similar bookmark that is already in the database. When I find one, I locate (jump to) its location in the database with the Reveal command and then drag the new bookmark to that location. (The Reveal command is the main feature that qualified DT as a potential alternative to my previous Firefox setup. In Firefox I used an extension called “Locate in Bookmark Folders.”) These two features, search and reveal, allow me to stay productive and continue building my category structure regardless of its size.
Another nice feature in DT, that is not available in Firefox, are the item breadcrumbs that are displayed in the search results list. (Btw, it would be nice if the breadcrumbs link to their respective groups). These breadcrumbs speed up my workflow because they help me make a faster and more accurate decision whether or not an existing bookmark/group is similar to my new bookmark. I can decide not only based on the name, but also based on its parent categories visible via the breadcrumb. This is especially useful with instances because there is no other way to differentiate them. And this is where we run into the problem. Unlike duplicates, only one instance of the replicants will show up in the search results (and in Smart Groups). I cannot easily see if one of the other replicants is located in a more suitable category for the new bookmark. Also, the only way to navigate to the other replicants is to use the [Previous/Next Instance] command. This breaks the workflow and slows down the filing process considerably. (The [Previous/Next Instance] command also collapses all expanded groups and therefore makes it difficult and time consuming to go back to the previous location I was at. It only works with replicants too, which is confusing because duplicates are also considered instances.)
I hope this use case highlights the importance of being able to see all instances of replicants in search results.
I have a couple of other suggestions for better ways to navigate instances. However, I’m afraid that these suggestions will not be possible because of the same issue; which I guess is the reason why DT lacks better instances navigation tools in the first place. Nevertheless, I’m working on some mockups and will post them later.
One last thing regarding the two issues you mentioned at the end. I agree, it’s confusing that the color/status of the remaining (former replicant) instance does not update when the last replicant is trashed. I also noticed that items in the trash appear in search results and an option to exclude the trash from search (like with groups) is not available. Another useful feature would be an option to automatically delete instances in the same group.
I noticed that all replicants display the same location inside the Info Panel, even though they are all in different locations. Using the Reveal command on one of the replicants inside List view, reveals the same replicant instance for all of them. So even if they would all show up in the search results, they would all point to the same replicant instance when revealed. Another related observation is with an item that is a duplicate of a replicant. This duplicate item will only show that it has one duplicate. Only one of the replicants is considered a duplicate. The other replicants are not counted in the total number of duplicates displayed in the info window. Why does DT treat all replicants as one item in these cases? Why is there a distinction between the first replicated item and the subsequent ones? Shouldn’t each replicant be treated as an independent item, the same way aliases behave in OS X? The lack of distinct paths disables search and reveal, therefore making replicants less flexible than aliases. Aliases have their own location paths and show up in search results. Replicants all share the same location with DT’s own version of an “original” (the first item that was replicated, and if that one gets deleted the second in line will take it’s place and so on).
I posted some mockups on how instances navigation could be improved in DT. However, without absolute paths for replicants it would not be possible to implement them:
Ideas for Better Instances Navigation
Thank you for the suggestions, the final release of v2.0 will revise the appearance of replicants & duplicates.
Nice, can’t wait! So many new things in the final version. You should just skip straight to 3.0 beta 
.
That’s a great idea for Eric and the DTPO team! The team could put out all kinds of press releases and interviews talking about how the hundreds of rapidly implemented new features requested by customers during the 2.0 beta phase required the team to renumber the product version to 3.0b1 to avoid confusion, and how this effort shows how much the company cares about its customers and their specific needs.
