Say goodbye to the ‘version misery’ of collaboration via attachments. Smart Sections are ‘inline’ like attachments, except they are Editable and Change-tracked.

EMail does not directly support the updating of content, but instead supports addition of new content (a new EMail message). Updating of content is a crucial aspect of many kinds of collaboration.

Users of Email work around this by using attachments to support content updating. The idea is that a user sends another user an attachment, who updates it and sends it back. Unless massive discipline is exerted, this approach falls apart because of lack of clarity on the version of attachments. This problem gets worse as more attachments and more users are involved in the process. In detail, here are some of the versioning issues of attachments.

 

1. Users are unsure as to the latest version of the attachment.
2. If a user edits a non-latest version of the attachment, this unwittingly creates a ‘inadvertent branch‘. A ‘branch’ can be thought of as a parallel set of updates.
3. The ‘branching’ process can be recursive. In other words, an inadvertent branch may be further inadvertently branched thus further compounding the version misery.
4. There is no easy way to reconcile ‘branch’ versions with other versions as there is no easy way to see the difference between the two.

Collectively, these problems lead to ‘version misery‘ as the number of irreconcilable attachment ‘branches’ explode.

So, what are some alternatives to attachments? The main alternative is to couple a shared document type of system and have the EMail refer to (link to) the shared document. Shared documents have the virtue of providing clarity as to the latest version of the document. However, when coupled with EMail, they lead to an (arguably worse) situation.

This figure above illustrates the pitfalls of using shared documents as a replacementfor email attachments. Essentially we have substituted ‘non-inlined’ misery for ‘version’ misery. See the sidebar below for more details.

Conversely it turns out that attachments do have some very nice properties related to their inline nature. These are:

1. No one can take away a user’s access to an attachment once it is sent to him or her.
2. An attachment once sent does not change and hence remains in synch with the corresponding message forever.
3. When Emails are forwarded or replied to, the forwarded users automatically have appropriate access to the attachments.
4. The permissions of the attachment and message remain in synch at all times.

Collectively we refer to these as the ‘inline‘ property of attachments.

Smart Sections (hereafter ‘Sections’) allow us to have our cake and eat it too.

They obliterate version misery by

1. Allowing users to always know that the latest version of the Section is. They do this by providing prominent visual indicators when a user is looking at a non-latest version. (See figure above)
2. Preventing inadvertent branching. Intentional branching is permitted and supported.
3. Allowing users to see the ‘diff‘ between different versions of the Section. This allows users to see what has changed between two versions as well as merge Sections back in the case of intentional branching. (See figure below)

Smart Sections also exhibit all of the inline properties of attachments.

Based on this combination, Smart Sections allows users to execute business processes in TMail that are very difficult to execute in EMail. Specifically, they allow users to reliably update content associated with a TMail without getting caught up in ‘version’ misery. They do this without introducing ‘non-inlined’ misery.

Because one of the goals of TMail is to be as familiar to EMail users as possible, traditional

attachments are supported in addition to Smart Sections.

In TMail there are 4 types of Smart Sections. These are:

1. Text – To add and update rich text.
2. Grid – To add and update tabular text. This looks very much like a Spreadsheet, but it has no formula support. The Grid layout turns out to be a very useful way t organize tabular content.
3. Form – to add and update Forms.
4. File – to add and update Files. This is the closest relative of Attachments. Unlike attachments these are designed for updating without getting lost in version misery.

a) The permissions of the shared document evolve independently of the permissions of the EMail. For example, if the EMail is forwarded, the forwardees will typically not have permissions to the shared document. This is worse than attachment behavior where at the very least every user who receives one, knows they can access it.

b) Even if a user has permissions to a document today, he or she never knows when the owner may remove my permissions. Again, this is worse than attachment behavior where no one can take away a user’s access to an attachment once it has been received.

c) The versions of the shared document evolve independently of the email messages.

This has two very negative side effects

i) Unlike email, where a message does not change once received, with the shared-document-as-replacement-for-attachment approach, the emailmessage is effectively changing even after being received. This breaks a fundamental property of email.

ii) The email message and shared document version will typically not be in synch. For example, a user may send an email and in his or her email refer to some aspect of the shared document that was true at the time of sending. However, after the shared document is updated, the message content may no longer be ‘true’ relative to the content in the shared document.

For all of these reasons the usage of shared documents as a replacement for attachments is effectively a non-starter.