The 'Make linked' warning popup isn't urgent enough for an irreversible action

[Ben M]

I had a couple of images embedded in a Publisher document. I made some changes to them externally, was briefly puzzled when they didn't update (because I thought they were linked), realised the problem, and clicked 'Make linked' in the resource manager.

The popup says "Some images conflict with existing files. Would you like to replace them with your embedded copies?"

If you read incautiously (either by skipping over "them with" or by not processing the last two words), you'll think it's checking that you want the images in the document to be replaced with the up-to-date files. Which I'd go so far as to call the default case!

Instead, of course, it's asking if the files in the file system should be overwritten with the out-of-date copies in the document.

So having read incautiously, I clicked 'yes'.

Sure, it's mostly my fault for not reading closely. But the problem is that this is an irreversible action:

• Edit -> Undo link resource returns the images to being embedded, but doesn't restore your overwritten files.
• 'Undo' executed in the file system doesn't work.
• The files are overwritten, not just deleted and replaced, which would be reversible in various ways.

Luckily, it only took five minutes to recreate my two diagrams, but I can imagine scenarios where this would cause someone a huge problem, especially with a lot of images and/or without adequate backups.

If the program has to default to a behaviour, I think it should overwrite the images in the user's document, not the files in their file system. Alternatively, I'd like to see the Edit -> Undo functionality cover this case.

At minimum the popup needs an overhaul. In other cases where a program is going to do an unrecoverable file overwrite, there's a dedicated  alert with a sound cue and a ⚠ warning symbol.

[Old Bruce]

7 hours ago, Ben M said:

Sure, it's mostly my fault for not reading closely.

Before testing I read your post carefully, then I read the warning carefully while doing my test.

"Surely that cannot be what will happen." Is what I thought, "How is this outcome a desired outcome."

But I proceeded with the test. And I lost the Designer document, it wasn't overwritten, it is gone from the directory where it had been saved. I think it may have been destroyed by my having it  still open in Designer after placing in Publisher.

[fde101]

6 hours ago, Old Bruce said:

"Surely that cannot be what will happen." Is what I thought, 

Evidently you were right, but for the wrong reasons?

[matisso]

14 hours ago, Ben M said:

Sure, it's mostly my fault for not reading closely.

No, it’s absolutely not. It’s a common trait though, that people blame themselves for what they perceive as “failures” in operating a product, tool etc., while if it’s anyone’s actual failure, it’s of the people who had designed said tool (including those who wrote that warning). Norman’s “Design of everyday things” (where he mentions the above, BTW) is a great resource for making better products and tackling such pitfalls.

Then there’s also Jakob’s law, that states people spend more time using other products than yours, hence their patterns are already established when they become your users. Which is another way of saying that 99.99% of cases, you don’t get to create your way of interacting with your product, aka invent the wheel (save for some absolutely revolutionary inventions). The choice should be to go with already established patterns, otherwise you frustrate users who can’t rely on knowledge they already have.

7 hours ago, Old Bruce said:

Before testing I read your post carefully, then I read the warning carefully while doing my test.

"Surely that cannot be what will happen." Is what I thought, "How is this outcome a desired outcome."

I think it’s fairly safe to say that there’s little, if any, expectation among users that a layout / design program will alter their assets. Not many other programs do this after all, do they?

The safest way would be to automatically rename the files that are being saved and then link these, of course. Remember to inform the users, the worst scenario here is they are just a tad shorter on drive space but if it’s confirmed the files are duplicates, the other ones are binned. Or perhaps offer a choice between this, and actual overwriting, whilst making damn sure the information is as clear as it’s possible, with no room for interpretation at all.

Serif, are you having a vacancy in this department by any chance? I happen to be on the lookout. 

Cheers,

Matt

 

[fde101]

7 hours ago, matisso said:

No, it’s absolutely not.

It is from a certain perspective, because the message that was responded to did accurately spell out what it would do, so a failure to read that message carefully resulted in the product doing... exactly what it said it would do.

Admittedly, that was not the case (at least not in terms of the final end result) for @Old Bruce and his attempt to explore this feature.  What happened to him sounds like a more serious design flaw (if Serif failed to account for this scenario), or possibly a bug (in the event that Serif had attempted to account for this but their attempt to do so is not working as intended).

 

7 hours ago, matisso said:

The choice should be to go with already established patterns

If all you do is what everyone else is doing, then why do it at all?  Sure there are conventions that it makes sense to account for, and consistency with the user interface patterns of the underlying platform is certainly something to strive for, but there needs to be room for differentiation as well.

 

7 hours ago, matisso said:

I think it’s fairly safe to say that there’s little, if any, expectation among users that a layout / design program will alter their assets.

True under normal conditions, but consider that the resource manager is a tool specifically provided for managing those assets, and a function was being used that interacts with stored files, so there is some leeway in interpreting this aspect of the program.  By definition the feature in question is saving files, which alters assets in some manner (by moving their primary presence from being embedded in the document being edited to being stored separately on the disk).

Many programs (such as video editors) which use "linked" assets like this offer tools for manipulating them in bulk on disk to assist users with organizing and cleaning up their storage, and these features all involve some degree of "altering" at least the storage of their assets.

 

7 hours ago, matisso said:

The safest way would be to automatically rename the files that are being saved and then link these, of course.

Agreed, though this would also create duplication if the assets have not changed from the original names, so the user should obviously be made aware and given control over the decision.

7 hours ago, matisso said:

perhaps offer a choice between this, and actual overwriting

You are missing an option which should be obvious from the situation the OP started with.  He wanted to replace the embedded content with that of the original files which had been updated since being embedded.  For example, three options could be presented:

• Rename the embedded assets and save them alongside the existing files.  This will create additional files on the storage device.
• Replace the embedded assets with the assets from the files already present on the storage device.  This will cause any changes which were made to the embedded assets since they were embedded to be lost.  If the changes are deemed undesirable, the current versions may be recovered by using the Undo feature at least until the document is closed.
• Rename the files on the storage device and replace them with copies of the embedded assets.  This will create additional files on the storage device.  Any other documents which are linked to these files may be updated to match the content which is currently embedded in this document.

[Bound by Beans]

8 hours ago, matisso said:

No, it’s absolutely not. It’s a common trait though, that people blame themselves for what they perceive as “failures” in operating a product, tool etc., while if it’s anyone’s actual failure, it’s of the people who had designed said tool (including those who wrote that warning). Norman’s “Design of everyday things” (where he mentions the above, BTW) is a great resource for making better products and tackling such pitfalls.

Then there’s also Jakob’s law, that states people spend more time using other products than yours, hence their patterns are already established when they become your users. Which is another way of saying that 99.99% of cases, you don’t get to create your way of interacting with your product, aka invent the wheel (save for some absolutely revolutionary inventions). The choice should be to go with already established patterns, otherwise you frustrate users who can’t rely on knowledge they already have.

Thanks for emphasizing this. 🙂