Planned for Future Release

This will be in Tridion Docs 15, due out next summer.

Updating an image in the Draft Space

It appears that there is no way of updating an existing image from within the Draft Space; there is only the ability to replace it with a different image which is not the same thing.

Updating an image means creating either a new revision or a new version of the same GUID. Replacing the image means that I add a new resource with a new GUID to the repository, which, unless that is the effect I actually want, makes NO sense in a system designed to enable reuse.

When I replace an image that is a part of a reused data set instead of updating the image, I then have to go to every other place in the repository where the original image is in use and update that one, manually, as well. In essence, the workflow encouraged by Draft Spaces is forcing me to either branch of manually maintain my data set. 

I should be able to right-click on an image (or click a drop-down associated with image, or whatever) and be given the opportunity to actually update the existing source. 

Currently, unless I want my web users to spray a firehose of redundant images into the repository I need to direct them to take the GUID of the image from the attributes panel of the Draft Space, open the Content Manager, use Locate to find the resource, and use the Update feature of content manager to update the graphic. That's the kind of thing that makes people question whether or not I think their time is worth anything.

Parents
  • I feel like I should expand on why it is that the Draft Space is particularly broken when dealing with released resources.

    When a publication that has a status of "Released" is versioned in anticipation of a new round of updates, the starting point for every single topic and image in the Publication is "Released". 

    Therefore, if I want to update a topic, I need to create a new version of it first. There is a drop-down menu for that, so that's all good.

    However, if I want to update an image, there's no such tool. I have two different workflows available, and both of them are badly flawed:

    First Workflow: I create a new version of the topic containing the image, and then replace the image. This does not update the image itself, so if I've been a good content-reusing author and that image is reused in other places, then I've just broken the reuse flow. Additionally, I've versioned a TOPIC unnecessarily when I should have versioned an IMAGE. I've just created noise and smoke in my repository. Great.

    Second Workflow: I take the GUID of the image from the Draft Space and open up the Content Manager. In the Content Manager I find the graphic, version it, and update it. Now I have to get someone who is using the desktop Publication Manager to accept the updated graphic, because the change was done in isolation instead of being done within a publication and therefore will not be automatically added to the publication.

    Both workflows are utterly infuriating; when I explain either of them to a new user they look at me like I'm an idiot. 

  • Hi Jeff, thanks for bumping this up and adding more info on the use case. In brief, it makes sense, and the timing is right to start to put this in motion. There are dependencies across teams and even between organizations that mean it's not nearly as simple as it might look -- images are handled differently at various points. But we are planning this for the next product release.

    Near the beginning of Draft Space, it was a conscious decision to keep image updates to "replacements" rather than "new versions" since it made for a simpler mental model and a more obvious way to recover from user errors. At that time we didn't even have the "new version" button on topics although it became clear with initial customers that that was needed. It turned out that that new topic version button worked well and didn't create any particular problems, and so we are more confident that the same principle can be applied to new versions of images.

    As always, there still needs to be a power user / publication captain involved at various stages with any publication to check, wrangle, and finalize content, but by allowing authors to update image versions then that power user doesn't have to get involved in this particular use case if everything follows the happy path. And, if an author accidentally creates a new image version, it's relatively easy for a power user to remove the new version and to amend the baseline in Publication Manager.

    (We'll do this with new image versions rather than revisions because then it's more obvious and easier to fix things if needed, and also then there won't be confusion if someone else has the current version of an image checked out elsewhere.)

    Thanks again,

    Joe 

  • Hi Joe. Just wanted to point out that this is not in Tridion Docs 15, nothing of significance has changed, the workflow is still screwed, and I'm sad. 

    We've got the new "update" button, but we already had a workflow for that: if the image is not released, update it in the Content Manager and it updates in the publication. 

    If the image is released, we're just as screwed as we were before. 

  • Hi Joe,

    Just wanted to say that I'm trying to document how to do image updates for our users right now and it's hellish. There is no way of making this make sense. The RWS authoring tool cuts directly against the RWS workflow expectations. It's so weird. I can't picture the conversations that resulted in this flow. 

    Thanks,
    Jeff.

Comment
  • Hi Joe,

    Just wanted to say that I'm trying to document how to do image updates for our users right now and it's hellish. There is no way of making this make sense. The RWS authoring tool cuts directly against the RWS workflow expectations. It's so weird. I can't picture the conversations that resulted in this flow. 

    Thanks,
    Jeff.

Children
No Data