Initial design-offline

MCe was designed to give you optimum performance in a disconnected (off-line) mode; it was not initially trying to give optimum performance in an on-line mode. This compares with MC Express and MRO and almost all Internet sites. They require a solid Internet connection–always connected.

There is no reasonable way, in an offline mode, to have all the data of a large system all the time. So we very carefully made every decision to optimize your offline experience. We still do that!

The downside of this was that there are certain things that are difficult to do if we assume that you will be offline for days or weeks at a time. So we avoided those features.

Added: "temporarily online when data needed"

With version 8.1, we added features to work in a hybrid environment to bring you more functionality by taking advantage of what we call 'occasionally connected' or 'online when data needed'. What this means is that features that normally would require an 'online' connection were added, but in a more robust 'temporarily connected' mode.

This means, when you need data that isn't on your device, you will have to get a good enough connection to load that data. Depending on how much data you need, it may not require an 'office quality' connection – but it does need some connectivity.

Then, we store that data for a limited period of time, typically hours, so that you can now work with that data in an offline situation. Indeed, if you stay offline for a week we won't delete that data until you have stopped using it and you have a good internet connection again.

You have to be connected initially to automatically download the application, log in and get your initial data. You also have to be connected for the data from your portable device to be saved to and new data downloaded to your device from the server, that is: "sync'd" with the server. Almost everything else in MCe runs without communicating with your server; it runs in a disconnected (off-line) mode as much as it possibly can.

Surprise: It's significantly faster than fully online almost all the time!

One of the advantages of this design is that even when you are online with a perfect connection, under normal circumstances, our design means you will run faster than software that was not designed for offline and occasional connected! Why? Largely because of what is called 'latency' and partly by minimizing the 'extra stuff' that goes along with your data and partly by not downloading the same data over and over and over again.

Latency:

Latency is the time it takes from the time you request data to the time you get it back on your device. If you see an application like MRO pause for a ½ second or longer when you select a different WO or switch to working on Assets – most of that delay is 'latency'. This latency delay is there even if you only need a tiny bit of data.

Extra data over and over:

You undoubtedly have noticed with most web sites and most web applications that each time you click a button, there is a pause while it goes and gets your data from the server. Often it doesn't just download your data, it also downloads all the information about how to display your data.

If you do this 100 times, it will 100 times grab the same data from the server (with latency and data transmission every time) and 100 times grab the information about how to display your data. On a very fast, high bandwidth connection with very low latency it approaches instantaneous, and if you never see a delay, then you will not get any benefit.

But in a well designed 'offline/connected only when needed' application like MCe, we download the 'code to display' your data only one time – never again unless you do a wipe data logout or there is an upgrade. So the code to display your data is downloaded typically once every month or more instead of several times an hour or more.

Caching your data:

We also download and cache your data so that we only talk to the server when we need to. This means we get rid of all the latency of the network connection except when we are getting data. And when we are getting data – we only get the data not all the other stuff that goes with it.

Trimming large files/data before transmitting:

Also, when doing things like uploading pictures, we trim the size of the picture before we send it to the server instead of sending a huge multi-gigabyte image, and the letting the server trim it down to a megabyte or several kilobytes. This means we literally send 1-1000th or 1 millionth the data! On a cell phone or other slow connection you will really notice the difference. Even on a high speed network, you will notice at a minimum a small improvement in speed.

We also download what are called 'thumbnails' of images by default instead the whole high resolution image.

And for larger 'html' documents, we auto load the first few sentences so you can decide whether you want to download the whole document.

Default values – we KNOW this data so we do NOT send it back and forth!

Finally, when you look at most data, except when working with images, videos or documents, about 1/3 to ½ of the data is the 'default' value for that data. We never send the default data. So if you send 30 rows of data in a normal app, we will only send ½ to 2/3rds the data for MCe and yet you have all the same 'data' on your screen. This again saves you time while running the application whenever you do need data from the server. Sometimes the benefit is as much as saving 90%.

Similarly, when sending data back to the server, instead of sending all the data on the screen like most applications – we only send the data that changed and the bare minimum additional data so that the server can properly make the changes.

Important implications:

After the initial application load and data sync, MCe will run faster than any other application can possibly run because we remove latency and data bandwidth/speed issues much of the time and the rest of the time we download JUST the data needed, not extra stuff.
Not connected to the Internet in most cases means you are not connected to your MC server. In some cases, it means when you are not connected to your Intranet in situations where you have a local, corporate Intranet – just like the Internet but not external access. This means you can run MCe in an elevator shaft, in a warehouse, in a sub-basement, on the roof, in a submarine, in an airplane (when legally allowed to!) and then when you get back to a good internet connection, sync to save your changes to the server and receive new work orders back to work on.
While you are not connected, you can make many changes, the save them so that later, when you are connected, they can be saved to/sync'd with your server.
It is impractical (typically impossible) to load all assets and ID's of various types to your device. As such, you cannot look up various ID's when you are offline. You can enter them in if you know them, or you may need to look them up yourself using MRO later, or have someone else who can run MRO do so. MCe provides error handling to make this as easy as possible. So for example, if you enter an ID of My-Favorite-Part-01 and you should have entered My-Favorite-Part-001, you will be presented with the error after saving to the server (Sync'ing) so you can fix it when you have a connection to the server. Hint: Barcoding parts bins (or the parts themselves) and assets is a great idea to make this work even better.
Any changes made that affect your data made by other people will not take effect until the next time you save (Sync) to the server. So for example, if you take a list of Work Orders for a shift and you decide to do 3 of them, until you save to the server (sync), no one else will know that you have done those 3. If there is someone else that also decides to do one of those three, unless they can tell by looking, they will not know that you have done the work. Of course, if you sync at the end of your shift, and then the next shift can sync and see what you have completed.

As we add additional data to be downloaded to your device, in many cases, you or a manager will have the option of deciding whether or not certain data is brought down. These choices will affect how long your sync takes, especially the initial loading, how much you can do off line, and it may affect how much memory your device requires.