Update Process Improvements

[Jeremy Farber]

The update process from say version 8 to version 9 isn't good at all. This needs to be greatly improved. The entire process isn't designed under the idea that devices are all over the country and can't be brought back and put on a cradle. Maybe all of this has been solved with Andriod, but WM 6.5 it isn't.

Ideas to improve it.

1. Make things backwards compatible. If i have tracerplus connect 9 version 8 units should work fine.
2. Don't make Version 9 Connect install totally separately, install it over version 8
3. Make the upgrade process of handhelds easier, don't change exe location - TracerPlus8 vs Tracerplus9.
4. Make the deployment of the build files easier, you have to know where to put the files and even when you do they don't usally work the first time. If I make a change to the build files and want to push the files out to 30 units across the country, the process is 50/50 if it's going to work.
5. Make deployment of dropdown easier - you have to know exactly which directory to put them in.
6. If I make a change is tracerplus desktop, send the changes through traceplus connect automatically.

Once everything is installed and setup the software works great, but improving it with units not in your office or upgrading the software to the next major release is a total pain in the #$$. We have to do it one at time because it's so buggy and likely to fail which takes hours.

 

[Dan Peluso]

Hi Jeremy,

In response to your comments/questions.

1. Every release of TracerPlus strives to improve performance and/or functionality of the previous version. Sometimes, this requires changes to the underlying architecture that would make it unreasonable/impossible to support backwards compatibility. I agree it would be nice though.

2. We specifically have any of our major products install side by side as opposed to on top of previous releases because a *large* majority of our customers prefer it this way. They need to evaluate a new version alongside an existing install of a current version. We did not always do this but the overwhelming majority of folks dictated that this approach is better for them. Personally, I would be testing new releases on a Virtual machine or some other type of safe environment but our customer base is wide-spread so we have to strive to satisfy the masses in some cases.

3. This is really the same comment as Item 2.

4. I am not clear what would make this process inconsistent or really fail in general. If you could clarify what you are experiencing, we may be able to offer some advice. If you are building remote deployment packages with a tool like SOTI or similar, the file locations for TracerPlus components is generally identical from release to release. I cannot think when we have last changed system or data file locations. I imagine I am misunderstanding some portion of this comment.

5. As it relates to comment 4, Drop Down import files are always located in the \My Documents\TracerPlus\Data\For_Import folder. This will never vary and has been consistent since v1. Can you clarify what you mean here?

6. We are working on a couple of new features to aid the deployment process.

- One feature already released in v9.1 currently available is the ability to 'publish' your application via TP Desktop. We added a new publisher option to TP Desktop to allow packaging of all files needed for your project into one .cab file which can then be deployed via your remote device management platform of choice. You should check out www.tracerplus.com to see more about this. We should also have some videos posted describing how this works.

- A second feature not yet released but available soon is the ability to run TP Desktop as a type of deployment server. In this scenario, a user can update their mobile device project over the air via a menu option (or by scanning a QR code). This is mostly feature complete but has not been released yet. We are also still in the process of reviewing Mobile OS availability options for this feature as it relates to WM/Android and iOS.

** I would like to hear more about the failures you are experiencing in updating your devices. Using modern RDM tools as you are, I would expect this to be pretty straightforward and I am not clear if it is a failure of TracerPlus, your RDM tool, or something else. Feel free to expand on that here in the forum or directly with our support group if you prefer.

Thanks for the feedback. We always want to hear about the issues are users are experiencing so we can hopefully help resolve them quickly.

 

[OliverR]

2. We specifically have any of our major products install side by side as opposed to on top of previous releases because a *large* majority of our customers prefer it this way. They need to evaluate a new version alongside an existing install of a current version. We did not always do this but the overwhelming majority of folks dictated that this approach is better for them. Personally, I would be testing new releases on a Virtual machine or some other type of safe environment but our customer base is wide-spread so we have to strive to satisfy the masses in some cases.

Hi,

I just wanted to chime in to say that I wholeheartedly agree with this particular point. As a reseller and integrator, our customer base is spread over versions 7 thru 9 (with some even still on v6). I find it very handy that TracerPlus versions install alongside one another. I have both Desktop and Connect installed on my PC in versions 7 thru 9, and have a number of mobile devices also with multiple versions of the mobile client installed. This allows me to easily help customers troubleshoot problems with their apps if they run into anything; I just fire up whichever version they are using.

It's also useful for customers to evaluate new versions, as Dan points out. When a customer asks me if they should upgrade, I always tell them they can install the newest version alongside their existing one, and trial it as long as necessary to see if they feel it's worth upgrading, without worrying about losing their existing configurations.

 

[Jeremy Farber]

I thankful that you guys aren't taken these posts as complaining as I do love your software that's why we've been a customer for so long, 2006 I think.

So the issue as I see is End User vs Reseller. We are not resellers we are end users. The other issue at hand is testing vs deployment. Running the program side by side seems like a testing scenario. What I'm talking about is making it easier to deploy once you know that you are going to use the program on all of your devices. The process now you have to go to each device and make the change even if have an MDM like Soti MobiControl.

Another thought is why not make it so you can do either, run it side by side or install over the top. I agree that running it side by side is a good thing, but once you commit to the idea of using the software side by side isn't a good thing.

Again all of this is coming from an End User Standpoint, not a reseller. I can appreciate what @OliverR is saying, but we aren't a reseller.

Bottom Line, separate evaluation/testing from full-scale deployment.