The Digital Asset Transaction Management System – A Time Machine For Digital Assets
Subscription Only
This feature article was provided by Ralph Windsor, DAM News editor and is part of our Improving DAM In 2017 series.
This article is a narrative specification for a feature that allows each interaction with a digital asset to be dissected and rolled backwards to any point in time.
Subscription Required
You need an active DAM News subscriber account to access this content. If you already have a DAM News subscription, you can log into your account here.
Hi Ralph,
that’s a pretty cool idea! I’m not sure I’d want to be the developer who has to implement it… But it would be a great feature for the user who finds out that something went wrong during a batch update two months ago.
A subset of your proposal would be to implement “Undo” first, which should be simpler. I think “Undo” (together with “Redo”) is an important feature, taken for granted in desktop applications but very rare in Web apps.
Related, and also neat: The “Memento framework” https://mementoweb.org/guide/rfc/ which would allow users to browse DAM data as it looked like at some point in the past. (Via Martynas Jusevicius’ tweet: https://twitter.com/namedgraph/status/837251272063475712 )
Regards,
Tim
The implementation for this would be tricky, although probably not so bad if there was the opportunity to build it right from the start. This is like a lot of software development conundrums, the hard part isn’t so much the feature itself as integrating it with everything else (and realising that some prior design decisions were not the best ones on offer).
This is not an endorsement, but I believe Southpaw’s TACTIC has multiple levels of undo (not just one). I gather they are fairly production-oriented and you tend to find these apps have more sophisticated features (although they’re also not always the easiest to use and a good section of more conventional DAM users might not find a lot of the capabilities to be of much value).
As well as the undo aspect, I think it’s the API operations stack also and the ability to view a timeline for a digital asset (and the changes made to it). Very few DAM solutions offer scripting and macro support either. These are possibly features most users wouldn’t do a lot with, but then again, ‘most DAM users’ download a logo and a picture of the CEO once or twice, while a far smaller number spend all day plugged into it (and ensure that the requisite logo and picture of the CEO is in the thing to start with and can be found). Both these groups need to be catered for and there’s a symbiosis between the two.
There’s an interoperability advantage with this also. The apps that use something like this would also be a lot easier to integrate because it becomes a case of converting one transaction into the schema required by the other. There is a ready-made ‘unit of interaction’ which is standardised so it’s a bit easier to work out the differences and resolve them (like comparing two packets of data). I think this is the main point with all this, you need some kind of conventions for describing every user interaction, even if it’s only present (to start with) in one application – that’s probably the underlying message of the whole piece.
The Memento framework looks interesting, I’ll have to check that out.
This might look complicated (for developers) and new at first glance, but many of the concepts will be familiar to anyone with experience of event sourcing (which Martin Fowler first wrote about back in 2005: https://martinfowler.com/eaaDev/EventSourcing.html).
Architectures using event sourcing used to be quite niche but they are more common now. I haven’t heard of a team that’s implemented blockchain-based event sourcing yet, but it’s being talked about!
Thanks,
Martin