We are going to release Docs/Rich Edit text editing history soon, it will work like this:
Will you miss anything in this implementation? What are your cases for Docs/Rich Edit text editing history?
4 Likes
Selecting a past version and having a toggle to highlight the changes vs today’s version (added lines colored in green, changed in orange, deleted lines in red) would be nice, Google docs style. Not a deal-breaker for me, but I see two main use case for this
- 1 recover a previous version in case someone messed up
- 2 checking up on a doc that has changed a lot in the past few days / weeks and see at a glance what is new and who made the change.
It seems your implementation currently covers use case 1 but if you have a very busy team (not my case), use case 2 might be even more important… Otherwise people have to signal their important changes using comments which rapidly becomes a bit cumbersome.
5 Likes
Yes – the ability to see differences between any version and the previous version, and any version and the current version would be super useful, to figure out which version you want to restore after a bunch of changes have been made.
4 Likes
How will this functionality integrate with the existing entity activity history?
It looks like they are two separate history logs…
So far they are fully separated. We’d like to collect cases when you need the merged history. It’s possible to do, but we are not sure it is important enough.
100% agree with @Simon_JB and @Matt_Blais that a “highlight changes” will be important for this feature, at least long-term. Initial release can be without that, but to really be a good implementation it should have version differencing, ideally between arbitrary versions, but at least between immediately successive ones. Once again I’d point to Discourse as a pretty good implementation. 
Although I don’t think it does arbitrary version comparison (that one’s not a must though, as I say).
Two other things I’d love to have, that sort of work together. One is Named Versions, the other is Copy version to new document. The use case here, for example, is let’s say I make a proposal document and it is version 1.0. I send it to an external client for review. They request some changes, I make those, then some other team members make some changes, there are many revisions until a 1.1 of the doc which we send to the client. Later a different client wants something similar to what was in 1.0 of our proposal. The one we sent to the first client was a PDF, and nobody wants to edit a PDF or copy the text out into a doc to redo it. We could try to edit 1.1 back to 1.0, but that sucks too when we already have the 1.0 version in there somewhere. We can check the date of that PDF export to find the approximate revision, but if there were several that day it might be hard to find the exact one. A named version would let us call it “1.0” when we export that version, then return immediately to that version at any time in the future. Then once we do find it, it would be nice to be able to just copy that out to a new doc to start a new version/“fork”. This may sound like a bit of a contrived case but I do things like this all the time in my day job, usually using GDocs.
I do want to say, though, that these latter two features are definite “nice to haves”, but whether you should work on them obviously depends on how useful they are to others, how long they would take, and how much they fit with the sophistication you want Fibery docs to have. I don’t need to remind you of that (Fibery team), I more just want to acknowledge that I’m aware that not everything that would be “nice to have” should be implemented. They are indispensable features in Google Docs in my opinion, but may be out of scope for Fibery. Certainly there are other things I’d want to see developed before these, if it was a choice between, say, improved activity/notifications features and named version/copy version.
2 Likes
No it’s not that important, I just wanted to check I’d understood the implementation.
To be honest, I’d like support for named versions for the entity as a whole (I guess implying that it is shown in both activity histories). And the icing on the cake would be being able to name versions programmatically (via buttons/automations)
2 Likes
DEFINITELY THIS 
I find named versions indispensable in Google Docs. We use Google Docs to author web page content, and I make a version name for a doc whenever I upload its contents to the web page (“Uploaded to website [date] - Matt”). That way I can quickly check the doc’s version history to see if it has been modified since I uploaded it to the web page.
Super useful!
2 Likes
What was your assumption for what a merged history would look like?
I would think that you at least want something on the entity change history that mentions there was a change, with maybe a link to the view you demo’d. Otherwise, it would likely be confusing to people that the entity change history doesn’t include all changes. I don’t know how important that is though. Document and entity change history isn’t a big need for us currently.
Yeah, that’s basically what I was getting at.
But as long as people know to look in both places it’s not the end of the world, I suppose.
Adding my voice to the thread: highlighting differences since last visit would be great, or at the very minimum indicating that the content has changed (maybe with a visual denotation of changes in the clock icon?).
The use case being: I’ve looked at that document a while back, has there been any change since then? and if so, what did change?
1 Like
I move much of my activity over to ClickUp because of their History & writing features. (but am still hopeful for Fibery!)
1 Like
Very nice! I see you’ve been keeping history already. 
So I take it the version comparison is between selected version and the one immediately previous? (i.e. "what changed in this version) Rather than e.g. between selected version and current version. This is not a complaint, just want to clarify/confirm.