A lot of people talk about wikis 'replacing' email - which I think is too broad a statement - but very few people focus on the impact wikis have on shared drives.
Let me just come out and say it. Shared drives suck. There, I said it. I feel better already.
They're an absolutely awful way to store content and files over time, but we stick with them in organisations. Why? Because they're easy to use. Setup a Samba share or an NT server somewhere and just start throwing files into it. You're sharing with colleagues.
The more I talk to customers who are switching to using a wiki, the more I hear about the pain of shared drives. Let me try to enunciate all the reasons why they're moving:
The more people started to use Confluence in the early days, the more we heard back from customers that their shared drive was being replaced by it as a location to store documents and files.
Over the years we've added more and more tools to help this process:
(The Attachments feature tour page can explain to this far better than I can.)
There is one remaining problem though - people don't like using their web browser to manage files.
Using a wiki is traditionally a browser based activity. Open Firefox, navigate to wiki, hit edit, type content, hit save - voila.
Browsers however are a little clunky when it comes to manipulating files, especially in large volumes. They're fine for uploading a single document, but if you have 30 photos of the office Christmas party to upload you'll understand the pain.
One solution to this we've had for a long while is the Confluence File Uploader which is a WebStartable Java client for very quickly uploading multiple files with drag-and-drop, multiple server support etc. It's a good tool and it's cross platform but it does require an extra download.
What are people comfortable using to manipulate files? Windows Explorer. Mac Finder. Why can't we use those tools to manipulate files in our wiki? The answer is we can.
Enter WebDAV.
Confluence 2.3 was the first major release of Confluence to include the WebDAV plugin by default. It allows you to browse a Confluence enterprise wiki as a folder tree, adding files, seeing images as thumbnails, opening files, editing files - all without leaving the Explorer/Finder. How about editing a presentation in PowerPoint and just "saving it" to your wiki? (which of course will index it and make it available for search instantly to your colleagues)
As Jonathan explains :
Thanks to the new plugin, Confluence can now function as a full WebDAV server. You can mount your Confluence instance as a networked drive in Windows, OSX or Linux and interact with it just as you would any traditional file system. The plugin represents each Confluence space as a hierarchy of directories, just like the operating system does.
The attachments in Confluence appear as regular files. You can double-click to edit them and each time you save Confluence will create a new version of the attachment. You can drag and drop new attachments and they'll be added to the page. And you can delete attachments just like files and they'll disappear. Best of all, you can do bulk operations: Add 100 attachments at once, move a whole tree of pages, or simultaneously drag multiple pages to a new parent.
Want to see it in action? Watch the movie attached to Jonathan's WebDAV in Confluence blog post and install it into your instance today.
Quite simply it'll change the way you use a wiki. Can your wiki do that?
Great going. The plugin looks great.
Useful interfaces for data input and retrieval are so important...Although, I never used to think that way until I read a post from Ari Paparo.
Ari had raised $13 million to commercialize Blink.com years before del.icio.us. Blink did very well in landing over a million users who used it for social bookmarking, but the service eventually died out and years later Ari posted about all the GUI design mistakes that they had made.
He's got great things to say about the use of hierarchies and folders for storing and displaying information.
http://www.aripaparo.com/archive/001456.html
The fact that shared folders suck is probably the biggest single seller I have used to convince organisations to use confluence in the past (and I've sold a few). The "shared folder replacement on the web" is a great value proposition for all the reasons you've mentioned above.
Web accessibility is another, because VPN connections for customers to work with you on a project and your shared folder just don't happen. Enterprise security won't let you (and probably saved you more renaming headache and security paranoia about what's stored on the drive).
Webdav is a step in the right direction for people who insist on keeping their folders. Win them over without them knowing it (their peers will do the rest of the job).
Now if confluence could do diffs on word and excel - ok i'm dreaming :)
"Now if confluence could do diffs on word and excel - ok i'm dreaming :)"
not as a far away as you think esp. with the new office xml formats
Daniel - amazing. The irony here is that I sold my first startup _to_ Blink.com and know Ari through there (he was the COO there when they bought us). Small world indeed. And yes, I agree with a lot of his analysis of the social bookmarking sector in 2000 vs 2005.
Hi all,
the problem with WebDav is the "each time you save Confluence will create a new version of the attachment". What about the MS Offcie Autosave Feature ? If someone just opens the file from the WebDav folder an has Auto save enabled - BANG !!! Hundrets of file copies filling up the database or disk space - that's a definite show stopper - so it's IMHO NOT a replacement for shared drives as long as there is no limiting on existing versions or a time treshold.
Sugestion :
1.) Modify the plugin so that only version snapshots are being saved - say once per hour if a save takes place.
2.) As such, only a maximum of 8 or 9 versions of one file do exist during a workday. Allow a limit of maximum versions
As a temporary workaround i'd suggest to store the attachments on disk and not in the database (although a maintenance script could as well clean the attachments from the DB instead of disk). Now let a maintenance script clean up all intermediate versions and keep only those within the one hour intervals during a day.
As a result only 8 or 9 versions of a file do exist. As you can limit the WebDav version visibilty to only the current but be free to list intermediate versions in Confluence, you have teh advantage of in place versioning AND be able to keep your file space clean.
Jus my 2c ;-)
Hi Steffen,
I'm not yet sure what the right way to solve this problem is, but I agree that it is annoying. I've filed the issue here (http://developer.atlassian.com/jira/browse/WBDV-78) and we'll work to find the best solution.
Cheers,
Jonathan
Hi Jonathan,
sounds very good :-) . This "replace at least the team folders with that Confluence thing" is what is seen as a unique selling proposition in my current organisation. Hope we can find a solution asap. In the meantime we try to keep the things going by applying my cleanup script solution once a day per cronjob.
Best regards,
Stefen
Yes, it sounds good. But it doesn't really work very well. We're a Confluence customer, and it's a good product. But the user interface is simply absurd in places, and file attachments is one of those places. For example, if you attach a document to a page, then download it, it will download with "+" character replacing spaces in the file name. A user will then edit the file and upload it to the page - and Confluence will save it as a new document - unless you train all users to replace all the spaces before uploading.
Unfortunately this is just one of many anomalies you have to deal with. If you plan to get business users to use this as a shared drive replacement, plan on lots of time training and retraining and explaining why you chose this particular productivity tool.