Check Updates - the definitive issue

[missyschoenbaum]

I was watching the update script run and thought it was interesting. Will we have the ability to watch it, or are you planning on turning it in to a status bar? Or can we toggle between a status and a cmd window view?

[josiahseaman]

This... is a combination of Design and Technical limitations. I can't answer this question right away.

[missyschoenbaum]

Another thought on this - would it be helpful to have a viable clue as to when you last updated the application? This crosses into design as well.

[josiahseaman]

Hey @tjmahlin I'd like your input on this issue. There's a number of technical options, but it really just comes down to what the best user experience is.

• I was planning on skipping the two stage "check updates" and "update ADSM" in favor of just "update adsm" which doesn't do anything if you're up to date
• Some of these downloads can be really long, a progress bar might be nice. There's no reason this need interfere with the operation of the program while it's downloading. But the program can't run when it actually unlinks and updates, which is why you have to restart the program.

[tjmahlin]

I'm pretty sure we talked about this and came to some conclusion last time we were up in Ft. Collins, but I will add my response here for the record.

We should definitely do away with the two-step approach. However, I don't like the idea of a button that is always there but doesn't always do something. Would it be possible to programmatically check for available updates whenever the application starts? If so, we would offer no button when the app is up to date, but when there is an available update, an "update available" button appears in the header.

I imagine the download/install process to look like this:

1. User notes available update and clicks button
2. Loading graphic replaces button as download begins and progresses - user can continue to work
3. When download is complete, a modal message is triggered offering the user the choice to save work and update now, or update upon closing the app at the end of the session.

[josiahseaman]

Huh... I neglected to link any of my commits to this issue. There's code in master that automatically hits the update button. So currently it goes from "button that does nothing" to "button that marks for update when you close". I like your UX better. I can the check to the startup sequence. The check takes about 0.8 seconds. It's just that our startup is really long. I've been looking for ways to shorten it. (First startup doesn't count, that's more like an install btw)

[josiahseaman]

I'm pasting some of Shaun's comments here since they were in another issue. @tjmahlin, I thought these might be helpful for you to consider:

Issue: The current program update methodology needs reworked

Explanation:

When epidemiologists use the software for research, they need to be absolutely certain that the entire software suite is identical throughout the entire research project. Any models created and simulations run must be done so with the exact same code. To do otherwise invalidates their study results, according to proper scientific method.

Having the ability to update the software by clicking on the "check updates" button, especially when it isn't working solidly and the program gives no real or standard indication of its current version, could put research and reputation in jeopardy.

Suggestions:

1. During program startup the current version (all of the information relating to that version, i.e. build number, version number, and whatever that hexadecimal number stands for. And for each component, i.e. the GUI and the CEngine) should be displayed clearly in a startup box or window.
2. The current adsm.exe program needs to start making use of Windows programming standards. It needs to, and can, popup message boxes and give user feedback other than a long stream of seemingly meaningless debug messages that scroll off the screen.
3. The program update process should be as it was before. The user should be required to go to the website and download a new version. This makes it a very deliberate act, and provides the user with several advantages:
   a) The user can run several different versions at the same time on their machine and be absolutely certain of what each version is and is not.
   b) Assures the user that they have not invalidated their study research by accidentally mixing measurement tools mid-study.
   c) Assures the user that the update process works as expected and does not have any unknown quirks, as experienced by me in the testing process.

[missyschoenbaum]

I think Shaun is still stuck in a place where the Force reset didn't work and the app didn't update. @casesp can you give us a status?

[casesp]

Yep, stuck, but Josiah has graciously created a new release candidate just for me. I'll use that.

--- Original Message ---

From: "Missy Schoenbaum" notifications@github.com
Sent: April 8, 2015 10:20 AM
To: "NAVADMC/ADSM" ADSM@noreply.github.com
Cc: "casesp" shaun.case@outlook.com
Subject: Re: [ADSM] Check Updates - can we toggle watch on/off? (#309)

I think Shaun is still stuck in a place where the Force reset didn't work and the app didn't update. @casesp can you give us a status?

---

Reply to this email directly or view it on GitHub:
#309 (comment)

[tjmahlin]

There have been numerous issues revolving around this interaction over the previous months, so I have created an overarching spec for update interactions and the associated UI leveraging the soon to be implemented Setup Menu from the application toolbar. @josiahseaman @missyschoenbaum, I believe we have most of the components in place and that implementing this should not be an onerous task. Once we get this integrated into the application, we should be able to determine pretty quickly if all of the issues have been resolved.

Josiah, I'm bouncing this issue back to you. Once you have the mechanics in place, I will take care of the styling.

[josiahseaman]

TJ, once again you make lovely comps. I can see you've thought through this issue. Just one thing I'd like to change after running it by you. The whole download progress bar is technically unnecessary based on the way we're doing it. Based on the latest changes (today) here's what happens:

• ADSM.exe starts
• Another process fetches (downloads) the current head from github.com
  • This doesn't modify any files the user would know about and it can continue to run
• When it gets a response from the server it checks if the versions match
• If it doesn't match, it sets the "Update Available" flag which makes the button visible

So by the time the user is notified of an update, it's already downloaded. Since we're using version control, this isn't a big download after the first time, since it's only the files that have changed. I would actually need to do a lot of technical work to go back and prompt for download, then show a progress bar (that's particularly hard). Would you mind if it just says "Would you like this new version now? Here's the release notes."? From there it could restart and install immediately.

[sarahjgarza]

@josiahseaman How do you want me to test this one?

[josiahseaman]

Great question. Mix these factors:

A) In restricted environments (GIS lab computers)
B) In non-restricted (personal desktop)
C) Fresh install
D) Over older install

1. Delete some files from your install directory
2. Add some files
3. Change the contents of files
4. Try to update when there's nothing available (shouldn't do anything)
5. Move the program to a new location and see if it'll continue to run from the new location.
6. Delete the workspace folder
7. install with an old workspace folder already around

Bryan is also finishing up the installer which will give you install and uninstall options. #522

[missyschoenbaum]

I just got an unexpected result on this - I am running 3.3.5 and I see the message there is an update

so I select to update ADSM, the command window comes up, asks me if I want to open ADSM after it is updated. Then I get the message that ADSM is already running. This is using Beta.

[missyschoenbaum]

@BryanHurst I am turning this one back to you.

[BryanHurst]

@missyschoenbaum I /think/ that is an issue that will only happen when updating specifically from 3.3.5.0 to a newer edition.
After that first release, I renamed one of the files for detecting if the program is already running.

If the update worked and your are now on 3.3.5.6, then it shouldn't happen again (and wouldn't be an issue for users in future releases).

[boomtown15]

@BryanHurst - for those of us on 3.3.5.0, how do we test this if we can't update to 3.3.5.6? Can we get a new beta build with this fix in it?

[BryanHurst]

It should still update properly, just not restart itself as intended.
If the update didn't work, then you can always run the NPU manually.

[boomtown15]

I ran the update a couple times and restarted the program. It still shows 3.3.5.0.

[BryanHurst]

Okay, I'll have a new beta and production release by this afternoon.

[BryanHurst]

@boomtown15 @missyschoenbaum There is a new beta zip that should be downloaded. It is v3.3.5.7.

[BryanHurst]

As this thread was started with the old updater, I'm going to close it in favor of #532