Sharing features allow users to collaborate over the production of assets and dissemination of information. However, there are various ways in which this can be done. This post outlines the key types of sharing behaviour, provides examples and describes some of the challenges associated with each type.

Send

Strictly speaking, ‘Send’ is not a form of sharing. However, Send actions are increasingly being lumped together with Share actions in order to reduce the number of top-level options, as can be seen in this example from Evernote:

Send is distinct from true Sharing in that it immediately creates multiple copies of the asset, with no possibility for the author to modify the asset later, or for the recipient to collaborate in modifying it.

Read Only

The most basic form of Sharing is to give recipients access to read from the asset, but not write to it. This is usually simple to implement and provides the benefit that the author can update the asset over time and the recipient always gets the latest version of it.

Targeted Read Only
Rights to view the asset may be given to one individual, or a relatively small group. Examples include:

• Google Docs.
• Intranet.
• Facebook.

Public Read Only
Alternatively, an asset can be made publicly available. Examples include:

• Publishing a web page.
• Blog posts.
• Twitter.

Read/Write

Giving recipients the ability to modify the asset makes the system, much more powerful. However, it also introduces significant implementation challenges – primarily how to deal with the fact that more than one person may be trying to make changes to a file at the same time. This is typically solved in one of three ways:

Last Save Wins
This is the simplest approach, but has obvious limitations: users open a local, editable copy of the file and save their changes back to the central copy on demand. Each Save event overwrites the shared copy, so the ‘last save wins’. This means that simultaneous editing by two or more users will end badly.

In some cases, this approach is enhanced by providing a change history and tools to manage inconsistencies.

Examples:

• Targeted Last Save: Basic shared server.
• Public Last Save: Wikis.

Checkout
The problems with overlapping save events can be solved by implementing some form of Check-in / Check-out workflow. This means that when a user opens an asset to edit it, other users are locked out – able to view the asset, but not edit it.

This prevents any overlapping save events, but brings with it an alternative problem: users failing to check-in a file properly, leaving it locked for everyone else.

Examples:

• SVN solutions.
• Sharepoint.

Autosave/Autosync
The best way to solve the problem is also the hardest: implement real-time autosaving and autosyncing, so that multiple users can view and edit the same asset together. They all see changes as they are made in real-time, allowing powerful collaboration and avoiding the problems listed above. The challenge with this approach is simply implementing it!

Examples:

• Google Docs.

Limited Write

A final form of sharing to consider is one in which the shared asset is mostly read-only, but contains limited writeable portions, or has distinct features that support viewers in contributing to it.

Examples include:

• Web-based forms.
• Comments on web pages, blog posts etc.
• Likes and comments on Facebook.
• User Reviews on products, hotel descriptions etc.