Single Solution Structure

Because Transpose is a database application, it has a table at the core of the architecture. While the individual record (row) is often emphasized in the Transpose UI, the Solution (table) underlying the record and field structure is at the heart of Transpose functionality. 

Original Design

Transpose allows custom configurations of fields in a Solution. The Solution can be updated anytime—to add, remove, or change field options—and users can choose (when editing a record created before the Solution was updated) whether or not to update the record to match the new Solution structure, or stick with the structure that was there when the record was originally created. This is great if your record-keeping needs evolve, but you don't need to change your past records to match your new needs.

Problem

Over the course of about 6 months during which lots of database-centric features were being added, users transitioned from using Transpose primarily as a structured note or form repository to using it as a structured database application. So, many users wanted to be able to update the table structure on the fly, pushing changes made to the Solution to all existing records immediately. For instance, users wanted to make a change to the title formula records adhered to, and have that new formula change all the titles of their records. What the current behavior supported was individually editing a record, accepting the changes to the new Solution structure, and then seeing the record's title update. Obviously that's ok if you've just got a couple records, but it's totally infeasible if you've got 100 or more.

Solution

Needing to allow changes made to a table to automatically be reflected in older records introduced a variety of potential issues. We broke them down into four non-mutually-exclusive categories.

  1. Harmless changes - E.g. adding a new field, or moving a field to a different location. All records are updated automatically, user isn't warned or notified.
  2. Reversible destructive changes - E.g. changing the formula in a Calculation field. Because the user could simply edit the formula again to return to the old data, no verification or notification is given.
  3. Irreversible destructive changes - E.g. deleting a field or an option for a field. User is required to verify each individual destructive change individually, because they could lose data and it can't be undone.
  4. Field property changes - E.g. making a previously non-required field required. User must add values to records without anything the (now) required field before they can be done updating the table structure.
 
Screen Shot 2016-10-10 at 12.26.18 PM.png
 

A table describing notification behavior for various types of edits users could make to a Solution. For instance, see in row 2 that there are no notifications when new non-required fields are added to a Solution (so it's Type 1: a harmless change), whereas in row 5 they've removed an option that was previously selectable in a required field (which is Type 3 and Type 4), so user will have to verify the deletion of data and then replace the missing data with something else.

When fields are removed or edited in such a way as to delete data inside of previously created records (Type 3), users are prompted to confirm each bulk deletion.

Changes to the Required status (Type 4) get their own inline, contextual notifications in a unique blue script, letting the user know they'll need to update the records that are missing data in that field.

In this dialog, users supply a value to replace the now missing data in blank required fields (Type 4). They're also given the option to supply the values later (whenever they next edit the record), which would allow them to customize the value per record.