Introducing Gyroscope Notepad July 8, 2020

We have long established that Gyroscope applications, in addition to their wide device compatibility, can withstand high latency, low bandwidth network settings. What about no internet at all?

Well, starting 16.8, Gyroscope comes with an offline module that allows you to keep working even when you are out of network coverage. When you are out of a train tunnel, or back from an underground bunker, the collected data can be conveniently patched in.

It is important to note, that Gyroscope's offline mode does not aim to create the illusion that the user has non-stop internet. In a complex ERP system where records are inter-connected, merging offline data without user supervision could easily erode data integrity. Besides, when the network is out, whether planned or not, the user is placed in a very different situation, so the application should also accommodate the new context.

Before we dive into the reasoning and design behind the new subsystem, let's just take a look at how Gyroscope's offline notepad works.

Maybe before you get a chance to log on, the internet is already cut out. The new Gyroscope login screen detects network outage and switches the interface to launching the notepad:

The Notepad screen can be manually launched by opening "notes.php", regardless of network connectivity:

From this point on, any data that's input on the Notepad stays on the device. It's important to recognize that some "field data" might be sensitive, and the user should transfer the data as soon as there is internet connectivity.

If you are already signed in, the current Gyroscope session will launch the same Notepad in a full screen view:

Once the network is resumed, the Notepad will notify the user of the good news. Depending on whether the Notepad is running in the standalone mode or from inside Gyroscope, a suitable way to resume work is provided:

Out of the box, the Gyroscope Notepad offers two types of offline data: plain text, and user. These are for demonstrations. The Notepad can be extended to support a wide list of rich, structured objects:

Look for the red clipboard icon; it is both a warning symbol and a trigger to open the offline clipboard:

In the more compact tablet view, the clipboard icon is shown on the top of the screen:

Click on the red clipboard when offline will bring back the full screen Notepad. This is useful to transfer any work in progress that cannot be otherwise saved.

Objects in the Gyroscope Notepad carry out user defined actions. For example, clicking on a simple text copies the paragraph into the system clipboard. Selecting a user record, on the other hand, launches the New User screen with both the login and display name pre-filled in:

It is also possible to consume offline data in the other way. For example, in the New User screen, when the login field is active, and when there is an outstanding offline user record, the clipboard will show only the compatible records; in this case, all the users from the Notepad:

This is an example of a "typed lookup", which is part of a larger, more important concept of "anchoring".

"Anchoring" and the Thoughts Behind

The core challenge of offline editing in a collaborative environment is not only technical but also somewhat philosophical. A task list application can easily settle the difference between offline and live data. Even a cloud-based spreadsheet program can merge data from multiple sources without breaking sweat.

Gyroscope applications tend to capture more complex relationships among business objects. Instead of a linear list of records, or a grid of cells, the Gyroscope universe is better described as a graph. As one record establishes connections to other records, the graphs develops in real time. When editing conflicts happen, Gyroscope's web socket notification quickly brings every user to the same page.

If a user goes offline and continues to use the Gyroscope application to create new records, or more importantly new relationships between records, it would be like forking into a parallel universe where the outcomes drift further and further away. When multiple users go offline, the merging of all their universes becomes a daunting, if at all possible task.

A traditional method is to download the relevant data onto the local device as working copy. Modifications and additions to the working copy are then synchronized with the live version. There are many issues with this approach. One is privacy and confidentiality. Once the data is downloaded, it is no longer protected by the user login. It is also unclear how much data is enough, let alone that it's difficult to predict when a network outage would take place.

The Gyroscope Notepad focuses on Information Gathering instead of maintaining existing data offline. The common use case is that a field worker is out about gathering new information. The collected data should be easily imported to a live, online system. The structured records in the Notepad are snapshots of Reality Fragments that can be later incorporated with the "mainstream reality".

A Notepad record can be imported as a new base record. An existing record on the live system can also serve as a container, or an "anchor point" for Notepad records to be inserted as sub records. Notepad objects can act as anchor points of each other once they are issued identity by the live system.

Implementation Considerations

Creating new Notepad object types is easy. Each object type should be given a unique key. This key is declared in notes.php. The handling of this object type is further defined in gsnotes.js with 4 actions:

• input form: gsnoteform_objtype
• record creation: gsnotes_add_objtype
• snippet view: gsnotes_preview_objtype
• clipboard action: gsnotes_apply_objtype

The input form should mimic a live data creation interface as much as possible. If, for example, a Chair is described with its dimensions, color and material, the Notepad interface should have the same fields.

The record creation function calls a unified gsnotes_addnote function to store the data on the local browser.

The snippet view is optional; it defines a friendly rendering of the record. By default, the summary of a Notepad object is its object type.

The action, or "apply" function is the most interesting. Depending on the nature and the context of the record, different data entry automation can take place.

The skeleton of the offline actions is generated by the Base Record code gen.

Full Resolving vs Partial Resolving Insertion

If the Notepad object contains enough data to complete a record creation, the live Gyroscope application can be harnessed to consume the offline clipboard data. At the developer's discretion, the gsnotes_delnote function can also be used to remove the record from the clipboard.

There are times when the Notepad data alone is not sufficient to complete a record creation. For example, if a field requires entity/identity resolution, but the offline interface cannot access the live database, plain strings can be entered into the lookup fields. Another example is that the Add button is protected by gskey. In this case, the Notepad object can fill up the entry form as completely as possible, bringing the user one click away from creating the record.

Object Filtering and Anchoring

The gsnotes_listclips function is called in the Gyroscope context. If the network is out, both the embedded Notepad and the side clipboard are pulled out. If online, the clipboard only shows if there are outstanding items.

The onfocus attribute of a form field offers an easy way to trigger the matching Notepad object types. For example:

, will display only car records that are entered offline.

If we are associating car records with an owner, the owner_id then serves as an anchor point:

Then in the gsnotes_apply_car function in gsnotes.js, we can easily target the DOM elements and automate the data entry.