"The most valuable commodity I know of is information."

rebelutionary / 2.0

Enterprise Wikis Replace Shared Drives - Confluence & WebDAV / 2007 Feb 20

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 Problems With Shared Drives

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:

  • Structure - Because they're so simple, there's no structure. Vast forests of folders spring up and people aren't generally sure where to put things anymore. They find their own little corners of the drive, and just put all files there.
  • Gardening - People are afraid to delete anything because they didn't put it there. Someone else stored the file, so I'm not going to delete it - they might want it.
  • Search - Well, quite simply for 90% of share drives (probably 99%) there is no search. Google boxes and other tools can solve this one, but most people don't have them on the "server in the corner".
  • Versioning - How are files versioned in a typical shared drive? Renaming! You know what I mean. Which is newer specification-17Nov06.doc, specification-v2.doc, specification-mikes-edit.doc, specification-draft.doc? No one knows. In the end you probably look for the file modification date, but that can be dangerous.
  • History - Who changed what and when? There are no names with file changes and no comments ("I've edited this and it's good to go."), so it can take a long time to work out exactly what has changed.

Confluence As A Solution

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:

  • searching of document and file contents,
  • versioning of attachments,
  • file change comments and meta data,
  • image thumbnailing and galleries,
  • various attachment macros, lists and views for display.

(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.

Moving Beyond The Browser

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?

Comments

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

Posted by: Daniel Nerezov at February 20, 2007 2:07 PM

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 :)

Posted by: Simon at February 21, 2007 10:51 AM

"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

Posted by: nik cubrilovic at February 21, 2007 1:49 PM

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.

Posted by: Mike Cannon-Brookes at February 23, 2007 11:53 AM

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 ;-)

Posted by: Steffen at July 13, 2007 11:47 PM

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

Posted by: Jonathan Nolen at July 21, 2007 5:14 AM

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

Posted by: Steffen at July 24, 2007 10:34 AM

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.

Posted by: Jim Hanna at August 23, 2007 12:08 PM

Post a comment











Type the characters you see in the picture above.

Remember personal info?







Follow / ACTIVITY

About / LIFE

Atlassian

Atlassian / WORK

Photos / PERVE

Search / SEEK

Mates / BLOGROLL

Investments / FUTURE

© Mike Cannon-Brookes - 2000-2006