That's why you need to take the upload, check-out, copying out of the equation. Let them edit and save whatever they want to disk - the right technology can scoop those actions back up and bind it to the right repository transparently.
It's been our experience this highly depends on the business. Some embrace GDocs openly, love it - good for them. Others don't for all sorts of reasons. GDocs is not for everyone.
If it's the right technology than it *can* certainly help. The naming convention and the organization is a burden, one that can be easily abstracted away.
A filename solution is just not scalable and prone to error. Chances are they are using some sort of folder structure already, but they are humans, and things get forgotten. You come back to a doc two weeks later, you can probably find the last copy you touched, but everything else that's happened is forgotten.
When you are introducing parallel changes from multiple contributors, versioning alone doesn't help you. Say two people made a change to your document. The first messed something up, the second added something useful. With versioning if you revert before the first, you also lose the second set of changes. You need to be able to accept/reject change per user and versioning alone is not up to the task.
Google Drive and Dropbox have Versioning. When two people touch the same Dropbox file at the same time you end up with a conflicted copy that you have to sort out on your own. If two people edit a google doc whoever gets there first wins. But it's still just versioning. If after the fact you want to revert the first change, you also have to revert the second because you're just going to an earlier timestamp. Suggested Edits makes some progress in this regard, but you still have to deal with them immediately at next open instead of a time of your choosing.
This particular problem is very near and dear to our heart, and something we continue to see in companies both small and large, sometimes company wide, sometimes limited to a specific department or division underserved by whatever their IT has provided for them. We've spent quite a bit of time talking to people with exactly this problem and if you like what you read here, please contact us, because we'd like to offer an alternative that hasn't yet been mentioned. And if you're wondering about the plural pronouns, yes we're a startup.
The responses so far represent the usual dilemma when trying to establish a workable system of version control that can A. handle native desktop Microsoft Office and B. Remain appealing for non-technical users, with a minimal impact on their existing workflow.
A non-technical user suffering from poor version management will never ask for version control, they will tell you "I can't find the latest version of a document, I don't know who touched it since I last worked on it nor do I understand what changes have been made since I last saw it."
Solution 1: Is to go the parallel route - simultaneous editing, Google Docs or the like. That requires leaving behind Office entirely, and being comfortable with your docs belonging to Google. There is Office 365 which may be more palatable, but you leave behind desktop Office. There's one problem with the simultaneous edits though, as documents get complicated or the number of contributors rises dealing with change management becomes a huge problem - especially if inadvertent edits are significant. Also the version must be centrally stored, usually in one and only one cloud service belonging to the authoring app.
Solution 2: Is to go the serial route - using classic enterprise document management, with a master document check-in/check-out model. Most integrate with Office. Usually it adds a lot of interface to the workflow - to find and check out the document for editing. It's a serial process, when the document is locked, everyone has to wait their turn. So you trade the accessibility in solution 1 in the name of change management, but it's the opposite extreme in every way. Not to mention most solutions are either rather expensive, and/or require significant configuration and maintenance. And central storage is key, so portability is problematic unless you can tolerate long check out periods.
Solution 3: Is to leverage true multi-user version control, with forking and merging. Furthermore distributed systems provide storage independence. All of these tools are designed for source control, though they can be adapted. The interfaces and terminology are overwhelming for the non-technical user, and the process, while sublimely flexible is frankly overkill for document workflows. Then there's the non trivial exercise of conflict resolution, when the document is not simple text or some variation thereof, i.e. markdown or LaTex.
For many none of the solutions are viable. So they stick to some method of protracted suffering through filenames, folders, shares, and/or emails. Lots of aggravation ensues.
We like to think there's a forth option - one that integrates straight through Office so all people do is save, but is robust enough that we make both filename and storage location irrelevant - but still intelligently binding versions together in a way that can be inspected and acted upon at a glance to answer the who, what, when questions easily - all without threatening overwrites OR blocking access. Not trying to turn this into a commercial, but we're looking for exactly these types of cases to help shape our nascent technology going forward - it's reached an alpha state. Message us if you'd like to take part.
Slashdot Mirror
That's why you need to take the upload, check-out, copying out of the equation. Let them edit and save whatever they want to disk - the right technology can scoop those actions back up and bind it to the right repository transparently.
There is room for something in-between, more robust than simple timestamp versioning, but easier to deal with than full-fledged source control.
And what if you could?
It's been our experience this highly depends on the business. Some embrace GDocs openly, love it - good for them. Others don't for all sorts of reasons. GDocs is not for everyone.
If it's the right technology than it *can* certainly help. The naming convention and the organization is a burden, one that can be easily abstracted away.
Exactly - that's why you need something specifically tailored with documents in mind.
A filename solution is just not scalable and prone to error. Chances are they are using some sort of folder structure already, but they are humans, and things get forgotten. You come back to a doc two weeks later, you can probably find the last copy you touched, but everything else that's happened is forgotten.
Versioning != Version Control
When you are introducing parallel changes from multiple contributors, versioning alone doesn't help you. Say two people made a change to your document. The first messed something up, the second added something useful. With versioning if you revert before the first, you also lose the second set of changes. You need to be able to accept/reject change per user and versioning alone is not up to the task.
Google Drive and Dropbox have Versioning. When two people touch the same Dropbox file at the same time you end up with a conflicted copy that you have to sort out on your own. If two people edit a google doc whoever gets there first wins. But it's still just versioning. If after the fact you want to revert the first change, you also have to revert the second because you're just going to an earlier timestamp. Suggested Edits makes some progress in this regard, but you still have to deal with them immediately at next open instead of a time of your choosing.
This particular problem is very near and dear to our heart, and something we continue to see in companies both small and large, sometimes company wide, sometimes limited to a specific department or division underserved by whatever their IT has provided for them. We've spent quite a bit of time talking to people with exactly this problem and if you like what you read here, please contact us, because we'd like to offer an alternative that hasn't yet been mentioned. And if you're wondering about the plural pronouns, yes we're a startup.
The responses so far represent the usual dilemma when trying to establish a workable system of version control that can A. handle native desktop Microsoft Office and B. Remain appealing for non-technical users, with a minimal impact on their existing workflow.
A non-technical user suffering from poor version management will never ask for version control, they will tell you "I can't find the latest version of a document, I don't know who touched it since I last worked on it nor do I understand what changes have been made since I last saw it."
Solution 1: Is to go the parallel route - simultaneous editing, Google Docs or the like. That requires leaving behind Office entirely, and being comfortable with your docs belonging to Google. There is Office 365 which may be more palatable, but you leave behind desktop Office. There's one problem with the simultaneous edits though, as documents get complicated or the number of contributors rises dealing with change management becomes a huge problem - especially if inadvertent edits are significant. Also the version must be centrally stored, usually in one and only one cloud service belonging to the authoring app.
Solution 2: Is to go the serial route - using classic enterprise document management, with a master document check-in/check-out model. Most integrate with Office. Usually it adds a lot of interface to the workflow - to find and check out the document for editing. It's a serial process, when the document is locked, everyone has to wait their turn. So you trade the accessibility in solution 1 in the name of change management, but it's the opposite extreme in every way. Not to mention most solutions are either rather expensive, and/or require significant configuration and maintenance. And central storage is key, so portability is problematic unless you can tolerate long check out periods.
Solution 3: Is to leverage true multi-user version control, with forking and merging. Furthermore distributed systems provide storage independence. All of these tools are designed for source control, though they can be adapted. The interfaces and terminology are overwhelming for the non-technical user, and the process, while sublimely flexible is frankly overkill for document workflows. Then there's the non trivial exercise of conflict resolution, when the document is not simple text or some variation thereof, i.e. markdown or LaTex.
For many none of the solutions are viable. So they stick to some method of protracted suffering through filenames, folders, shares, and/or emails. Lots of aggravation ensues.
We like to think there's a forth option - one that integrates straight through Office so all people do is save, but is robust enough that we make both filename and storage location irrelevant - but still intelligently binding versions together in a way that can be inspected and acted upon at a glance to answer the who, what, when questions easily - all without threatening overwrites OR blocking access. Not trying to turn this into a commercial, but we're looking for exactly these types of cases to help shape our nascent technology going forward - it's reached an alpha state. Message us if you'd like to take part.