Introduction to TeamWraps

TeamWraps can be open on two or more devices at the same time. Two users can walk through a train from either end, reporting in the same Wrap instance. Changes made on either device are also reflected on the other. All changes are persistent and automatically saved in the database.

TeamWraps gives multiple users concurrent, shared access to a Wrap instance. Small, colored markers show what field each connected user is currently editing. All the users that are connected to the same Wrap instance see all the changes made to the instance in real-time, as they happen.

TeamWraps also greatly reduce the risk of data loss, since all data entered by different users is saved continuously, field-by-field in real-time, often surviving also local power cuts or network disconnections.

The main drawback of using TeamWraps is that there is no option to cancel changes you have already made to a currently open instance. If you often open an instance, make changes, and then press Cancel because you changed your mind, TeamWraps may not be for you, because there is no Save or Cancel button – every change is persistent by design.

The value of shared forms

With paper forms, it is practically impossible for two depot teams to share the same form unless they work very close to each other. When forms are put online, many users may have access to each form, but typically only one user at a time. Most online systems place a hard lock on forms that are currently being edited by another user. You have to wait for your turn.

For ExcelWraps users, time is always a crucial factor. To shorten turnaround times, teams need to work concurrently on similar or related tasks, and report status without having to take turns. ExcelWraps was designed to overcome this legacy limitation of online systems and freely allows multiple teams to use the same, shared electronic form simultaneously. In ExcelWraps, forms are called Wraps, and concurrently shared forms are called TeamWraps.

TeamWraps don’t have a Save button

The most apparent change with a TeamWrap is that it has no Save button. Since the 1970s, all online systems have provided the same “lock-open-edit-save-unlock” cycle when changes need to be made to an online form. The first step towards an agile environment where all forms can be shared is the removal of the Save button. With TeamWraps, there really is no “cycle” at all; the life of the Wrap is an endless, ongoing continuum. All changes are immediately persistent as soon as you exit the input field. Even if you pull the plug, close the edit window, throw your device in the sea, no change is ever lost in a TeamWrap after it has reached the server.

TeamWraps doesn’t even lock fields

When you start working on a TeamWrap together with other members of your team or other teams, you quickly notice the small colored markers that represent what fields other users are editing. This is because TeamWraps doesn’t lock forms for single user access – a TeamWrap is always open for any new user that wants to contribute.

Screenshot of the colored symbol that appears when another user is editing a field

Normally, you may want to delay editing a field as long as another user’s name appears next to it, but this is not enforced by TeamWraps. In the example above, if you know “Wayne” is not going to make any changes to the field, you can still select it, type a different value, and move on to the next field. Your change will be saved, the new value will be reflected also on Wayne’s screen, and for all connected users. There is never a need to wait, because TeamWraps doesn’t lock fields, either.

But what about conflicts? As we see it, two users should not have a different opinion about what to type in a field. If they do, they probably need to talk. TeamWraps is not intended for opinion surveys or any other forms where two users may have different responses.

Also, TeamWraps doesn’t really work well with free-for-all, general comment fields, because the last user to exit the field will replace the contents of the field completely, possibly removing text that was simultaneously added by others. If you need to offer free-text note fields, it is best to redesign the Wrap so that conflicts never occur, e.g. by providing one field for notes related to electrical work, another for comments related to stain removal, etc.

All users must have compatible permissions

The ExcelWraps permission model offers enormous flexibility, and you can even design Wraps that look completely different depending on the user. A manager may have access to sections related to cost, a union representative may have access to sections related to average task times, and a welder may see other fields than a cleaner. TeamWraps currently cannot hide some sections for some users while making them visible for other users, so you can only offer a TeamWrap to users that see exactly the same parts of the Wrap, i.e. have compatible permissions.

To prevent inadvertent changes to the Wrap instance, you can still use Roles to make the Wrap read-only for some Users, use &openmode=fast in the link if Users with Edit permission only need read access, and use intermediate signatures to lock completed units of work. All three options are described in detail below.

Working with TeamWraps

TeamWraps are really not much different from other Wraps.

Designing a TeamWrap

You design TeamWraps as spreadsheets in Excel and convert them to Wraps with WrapCreator.

A Wrap becomes a TeamWrap using a setting on the Wrap page of the WrapCreator task pane.

Screenshot of the TeamWraps setting on the Wrap tab in WrapCreator

If you want to protect your users from inadvertent changes to a TeamWrap, you may want to use signatures to lock sections of the TeamWrap as soon as they are complete. Such intermediate signatures, e.g. by team leaders, protect the data entered by each team until the whole instance is signed off and frozen.

Defining Users and Roles for a TeamWrap

If changes are made to a TeamWrap instance, they are saved directly. If you worry that people will make changes by mistake, you may want to protect the data by splitting the related Roles into two, one for those Users that may edit the TeamWrap and one for those that may not.

Creating a TeamWrap instance

When you have uploaded the converted Wrap, you need to create an instance before you can share it. Once you have created a new instance in your browser, it is available also for other users that use a link with the same Unique Keys or Wrap ID.

Opening a TeamWrap instance

You open a TeamWrap just like any other Wrap instance, by clicking on a link that contains its Unique Keys or Wrap ID. If the access is read-only, you should append &openmode=fast to the link. This will open the instance much faster and in a read-only mode that protects it from inadvertent changes.

If your connection to the TeamWraps server is broken for some reason, TeamWraps automatically tries to reconnect every twenty seconds. Just leave the window open until the connection is established again. If you do close the browser window, you lose any changes that you made in the window that didn’t reach the TeamWraps server before the disconnection.

Ensuring changes are saved

If you get a message saying “save is paused”, there is a problem with your connection. You can still make changes, but you must keep the window open until the message disappears. If you close the window, the changes you have made since the last automatic save will be lost.

Screenshot of the Saving is paused message for TeamWraps

Closing a TeamWrap instance

When you’re done using a TeamWrap, you just leave it by closing the window or with the Back button in the browser. All the changes you have made to the instance have already been continuously saved in the database.

Participant list

You can see the other users that are connected to the same instance in the participant list available from the TeamWraps button in the toolbar. You also get notified when additional users enter the sharing session.

Screenshot of the participant list for a TeamWrap instance