Hi there,
I’m getting use to using the coloured replicants and duplicates. I was wondering why the duplicates are both blue and bold, rather than just blue? To me the bolding makes it feel like this particular file is more important than the rest of the files in that group. Could it just be blue to distinguish it?
Thanks for your time,
Patrick
EDITED to correct my usage of replicant and duplicates as pointed out by Bluefrog below.
Me too, that is the exact intuition I have.
Actually replicants aren’t bold or blue. They’re italic and red.
From the Help > Documentation > Windows > Main Window > Item List section…
Oh yes, I have confused myself. Sorry.
Now that I’ve turned the colouration back on, I feel like my question regarding the bolding could be similarly applied for the italics on replicants. The colours are great for recognition. I’m just not convinced by the bolding and italics.
It’s a small thing.
Now that you mention it, yeah, why are they in bold?
Personally I would be fine with just the color, but keep in mind good UI design includes as many users as reasonably possible.
Apple has published an extensive set of UI design rules on their website, including best practice guidelines for accessibility:
Items in bold are unread, regardless of whether they’re duplicates, replicants or standalone files. Look carefully at bullfrog’s screen cap above, underneath the description of duplicates and replicants.
This is not the case. I’ve read many of the dupes and the items are still bold and blue.
You might still be missing something: For DT, they might be unread. I’m sure bluefrog will be able to explain more clearly. But here are two possibilities to consider. One: If you have duplicates, and you read one of the files within/using DT, that likely won’t mark the other copy/copies as read (because they’re duplicates not replicants). Two: if you read files using some other program (e.g., reading pdfs via Preview, Adobe Reader or PDFpen rather than within DT), they also will still remain, where DT is concerned, unread. AFAIK, this isn’t a bug. Double-click any file that DT can view natively, and the bold formatting will go away.
Actually, in this case it would be @cgrunenberg’s expertise needed here.
Duplicates are shown in bold blue regardless of the read state. However,this has been the case in DEVONthink 2. for years.
I noted this today as well. Bold means unread, so it really shouldn’t also be used for read duplicates, and it is.
There were a lot of design choices in DT2 that have thankfully been discarded. This one should go too, IMHO.
The original design choice was to give an additional visual clue for those of our male customers who are red/green impaired.
Is this a sign that the little associated icons need some attention instead?
Hmm, more a sign that it’s an old design choice that we might give another thought now that we have new icons.
The original design choice was to give an additional visual clue for those of our male customers who are red/green impaired.
I’m happy to hear about that choice, as it’s easy to overlook those adaptations when you’re unaware of such impairments.
Do you happen to be familiar with Apple’s UI guidelines I mentioned above?
I can imagine it would be difficult to follow them all, but knowing Apple I presume they put in some detailed UI research to come to the accessibility design they advise.
Yes, we have read them. Apple also updates them from time to time when they change or extend their UI on any of their platforms.
