Info boxes about locking panels (without actually doing it)

[mccalluc]

• Towards Lock page to changes #88
• Keep track of which panel we should be on, even if we clicked on a tab to look at another panel.
• Explain why the user won't be allowed to touch these other pages
• Wrap the message in a bootstrap info box.

There's enough here that I'd like sign off from @Shoeboxam and someone else before going farther.

For reviewers:

• For both Mike and someone else: Do the warning messages express well why folks shouldn't be on the other tabs?
• Is the styling ok? I'm not intending to spend a lot of time tweaking the UI, but do you think this is adequate? Maybe the boxes are too much, and bold text would suffice?

[ekraffmiller]

I think the explanatory text is good, it describes well why the user shouldn't go back and tweak the inputs.
One comment on the locking behavior - could we make the lock only appear if the user has actually downloaded the release, as opposed to just viewing the download page?

I'm leaving this as a comment rather than approving, because @mccalluc mentioned that he would like @Shoeboxam's feedback on this.

[mccalluc]

could we make the lock only appear if the user has actually downloaded the release, as opposed to just viewing the download page?

Right now the final tab is just buttons, but my sense is that we may want to include a summary of the results on that page itself... perhaps the graphs? so the release would happen when you enter that tab by clicking the submit button on the previous tab. I think consistency in the locking behavior would be good: When you submit your selections on one page they are fixed, whether that is the first or the second tab.

[ekraffmiller]

@mccalluc, ok if the release is going to appear on the page itself, I think that makes sense. Do you want me to go ahead and approve this or wait for comments from Mike?

[mccalluc]

@ekraffmiller, I'll wait for Mike's thoughts, so probably better to just to leave this as a comment so I don't merge it by mistake. Thanks for the feedback.

[Shoeboxam]

Upon further consideration, I've weakened the "we should lock once set" opinion I had, because I had a specific vision that may not be consistent with the intended use-case.

I think there are two modes:

1. privacy unit and loss are configured externally and can never be changed
2. privacy unit and loss are configured by analyst and can be changed, but with some cautions:

What to caution about:

1. If there are existing releases, state that changing the privacy unit will re-run the release? Or maybe reset all stats? It should explain that changing the privacy unit is resetting the app in some way, or causing new releases to be run, and dropping the previous privacy spend. As we move forward, you (Chuck) may want to keep in mind that changing the input metric (from symmetric distance to user id distance, for example) could potentially make later queries invalid.
2. The privacy unit has a significant impact on the integrity of the privacy guarantee. Please carefully consider if your new privacy unit is meaningful. While making your privacy unit more fine-grained can give the appearance of greater utility for the same privacy loss, it commensurately weakens the strength of the privacy guarantee.