Absent any general announcement, we posted 2.0.0 about one week ago.  On revolutionary re-designs, we like to have just a few users testing at first -- so, if there are any major bugs, they can be discovered before tons of people are affected.  During the week since, we have indeed discovered and corrected a few bugs, which is why we are now up to Ver. 2.0.7.

One bug in particular was nasty (resulted in PartsPick-usage data not going correctly back into SD).  It is corrected with this particular release (curiously, no one seemed to have noticed this bug until just yesterday).  Other bugs have been comparatively minor.

So, what's so revolutionary about our 2.0.x series?

In a nutshell, we expect it to fully eliminate "in-operation" UI (user-interface) freezes (some folks have called this "hour-glassing").  You'll notice, the UI itself (and interaction with it) is virtually unchanged.  What's been radically re-done is behind-the-scenes information-management and communication-movement.  In short, we adopted an entirely new strategy for these processes.  Our express purpose was to eliminate those freezes that would formerly sometimes plague you.

Why did you formerly get freezes?

To keep information flowing both ways, SDM must somewhat frequently communicate with the online server.  When it makes a communication request to Windows, Windows immediately goes to work, seeking to fulfill that request.  In the meantime, Windows keeps the application itself in limbo (i.e., while its working to fulfill the request).  This in-limbo state (pending Windows fulfillment of a communication request) is what was occurring each time you encountered freezes.  Over time, we tried a variety of methods -- seeking to eliminate (or at least reduce) this symptom.  None were fully successful.

Our new architecture avoids the problem by "off-loading" the communication task from SDM itself to a little companion/servant app (it's called SDM-DataMover).  That little app runs in the background, without you even being aware of it.  The genius is, if there is any delay when it requests communication from Windows, it's only it that freezes, and not your SDM interface.  Since it's not even visible to you, there's virtually no reason for you to even care.

A secondary (and huge) benefit to this new structure stems from how communication occurs between the unseen companion app and SDM itself.  It's simply done via files, stored on your local hard drive.  When SDM-DataMover has new data for SDM, it writes to these files (from which SDM then reads), and vice versa.

Since we're now storing all this operating data directly on hard-drive-based files (formerly much was being done via a more intimate connection between SDM and the online data source), it makes possible a new capability that formerly did not exist.  Specifically, once you've done your initial login for the day (and corresponding initial download of dispatch data), you can close and re-start SDM with no internet connection whatsoever.  Your jobs will be there, just as you left them, and you can proceed with your work, sans any internet connection at all.

Another benefit is these subsequent starts are all-but instant.  No delays.  SDM just starts, with all your data right there.

You might notice that, several paragraphs back, we placed quotes around the expression "in-operation" to describe the context in which UI freezes are expected to be entirely eliminated.  We used those quotes to call attention to a distinction.  We are referring specifically to the "in-operation" background operations that used to formerly cause unexpected freezes.  All of those kinds of processes have been fully "off-loaded" from SDM, per the above description.

By contrast, there are a few communicative operations that SDM still performs directly, and in connection with which you might still encounter communicative delays.  Specifically, these are as follows:

• User-authentication, basic user-files and dispatch-download on first-login of the day;
• User-initiated stock-inquiry;
• Call-ahead requests or call-ahead status-checking (i.e., robo-call work);
• Virtual Terminal transactions;
• ServiceBench Entitlement inquiries; and
• QuickPic requests.

You'll notice, each of these are of a nature that require immediate/direct online communication, and also immediately follow an explicit user request for same.  In such context, we think -- for any such delay as you might encounter in their connection -- it will seem normal and proper to the circumstance (in particular, as robustly contrasting against the "hour-glassing" which may have formerly frustrated you).

Above I indicated that our 2.0.x series changes the UI virtually not at all.  Well, it doesn't mean we were not able to do some significant enhancements, here and there.

The first is we created a button on which you can click to view, from within SDM, any QuickPics as connected to either the job itself or any UIS to which it's connected (this means you can see QuickPics as created on past jobs involving the same machine):

Usage is simple.  Click on the camera button.  Pick a picture from the list provided (assuming any pics indeed exist), and it will open on whatever viewer is setup, within your system, for opening that file type.

If QuickPics are available to you, it's likely you are using the SD-QuickPic smartphone app, from which you can also access exactly the same set of pics.  The benefits of doing it from SDM instead consist of: (a) potential convenience; and (b) likely a much larger screen from which to view the pic.

When we introduced the Robo-Call feature a few months back, it was deliberately barebones.  Often we can get a feature to you in its minimal state with much less programming effort (and therefore sooner) than what it takes to really enhance the feature set.  It is what happened in this case.  To give it to you just bare-bones required but a few hours programming.  The present expansion took much more time.

The present expansion provides what many asked for: visibility into what happened with your robo-call request.  We do this, largely, by changing the colors of the button (and by making ToolTips available when you float your mousepointer over), as follows:

No call-request made or pending on this item

Request made, transmission success not verified

Transmission succeeded, result not-yet-known

Call completed, and answered at recipient's end

Notice some of the ToolTips invite you to right-click on the button to make a current/direct inquiry.  It means exactly what it says.  You may in some instances want to do this because the automated status-updating mechanisms failed to update, or may be taking longer to update than you prefer.  The inquiry can even tell such things as if the line called was "Busy."

Specifically regarding confirmation that your call completed, this will not occur via automated means any sooner than 65 seconds following your call request.  This delay is purposely invoked to allow the call to complete prior to an automated behind-the-scenes check occurring on your behalf.  

This is a bit like the last one, but regarding a feature that's far older than Robo-based Call-Aheads.  In a nutshell, there has been no visual indicator to confirm for you which (of potentially multiple) disclaimers you have had the customer sign on a particular job.  It's easy to imagine you might reach a point, on the job, where you find yourself asking: "Did I get that disclaimer, or did I not."

Until now, the only way to determine was by clicking on the Sign-Disclaimers button, picking the disclaimer of interest, then looking to see if there was already a signature there, or not.  Now we make it visually apparent up-front.

Specifically, the button starts as all-green, to signify no disclaimers have been signed:

Instead of switching to all-grey as it did before when any disclaimer is signed, the "Sign Disclaimers" button instead switches to grey in particular segments, corresponding with which (if any) particular disclaimers have been signed.  There is also an explanatory ToolTip that will display as you float your MousePointer over:

As shown above, SDM is setup with four different disclaimers, so, once any of the four is signed, the button appears with four segments (your button will uniquely segment for whatever quantity of disclaimers you have).  For this example, the particular grey-segment as shown indicates Disclaimer 2 has been signed, but not 1, 3 and 4.  All-grey, of course, would mean all disclaimers had been signed.

Incidentally, the segments are solely indicators of what's signed versus not.  They are not request-designators (i.e., clicking within a particular segment does not tell the system it's the particular-position-corresponding disclaimer you want to sign or see).

Incidentally, as of the date of this posting, this is still a beta-release.  You must scroll to the bottom of the downloads page to get it (i.e., the standard update is still, essentially, old).