Since the cutover to 1.2, many editors have expressed confusion in the way old revisions are presented -- primarily how all old versions are compared to the current version. If a story has dozens of versions, this makes it incredibly difficult to trace when a change was made. They'd prefer one of two different ways (1) the old version is simply presented as it was, with no comparison to any later version; or (2) the old version is compared only to its immediate successor.
Have you got feedback from other clients? Is one of the two ideas easier to implement?
Ken Carriere
| Categories | Layout |
We shipped broad improvements to Revision history with Composer 2.0. When users click on a revision, we now show what was changed compared to the immediate successor.
Same here. We had to build our own tool using the API.
This idea is so old people are filing brand new ones for the same gap: https://ideas.arcpublishing.com/ideas/SB-I-217
Our newsroom also finds it very difficult to review versions within Ellipsis for exactly the reasons that are described here. We've found it cumbersome enough that we've built a tool that pulls revision data from the API and allows users to view revisions outside of Ellipsis. I found this ticket because we've had two issues this week where users needed help tracking down specific information from versions and we could only provide the info that they needed for by viewing the versions directly in the API.
FYI, it's the preference of our newsroom to see (1) the old version is simply presented as it was, with no comparison to any later version. Forget about (2) in my original ticket.
I think you mean for option 2) that the selected version is compared only to its immediate predecessor?