On 26.01.2013, at 00:50, Chris Muller <asqueaker at gmail.com> wrote:

>>> I do like what you're trying to do here in terms of streamlining the
>>> Review & Save use-case.  How about, upon clicking Save, it simply
>>> re-snapshots the package, then enumerates the definitions and
>>> re-ignore the ones which the user said to (I)gnore the first time and
>>> re-ignore them just before saving?
>> 
>> I have to think about that.
> 
> The goal is to streamline the Review & Save use-case so we don't have
> to click two buttons (Changes and Save) to open two windows up every
> time.  Is that right?

That, and being able to selectively commit changes.

> But by not allowing *corrections* to methods during Review, it
> actually makes things a lot worse.  Let's detail the process steps of
> the Review & Save use-case.  First with what we have today:
> 
>   1) click the Save button.
>   2) click the Changes button.
>   3) review the changes, typing release-notes text as you go.  Make
> any necessary improvements right then and there based on the review.
>           (3.1)   -- If the phone rings, pick up the phone and have a
> conversation --.)
>   4) click the Ok button and be assured, everything that was reviewed
> and corrected is now saved.  Serenity!

5) Nothing happens. Why? Oh, I remember, an error popped up while I was reviewing and fixing stuff, which killed the process that the save dialog is supposed to be waiting on.
6) copy the release-notes to the clipboard,
7) click the Cancel button to close the Save window,
8) click the Save button again to reopen it.
9) re-paste the release-notes text.
10) click "Ok" this time to save what was listed in the.

(this problem is actually not addressed by my version, but it's the reason why I always open a new save dialog when I do want to save)

> With Monticello-bf.532.mcz here are the steps:
> 
>   1) click the Save button.
>   2) review the changes, typing release-notes text as you go.  Make
> any necessary improvements right then and there based on the review.
>   3) if no changes were made, skip to step 8.
>   4) copy the release-notes to the clipboard,
>   5) click the Cancel button to close the Save window,
>   6) click the Save button again to reopen it.
>   7) re-paste the release-notes text.
>             (7.1)  -- If the phone rings, pick up the phone and have
> a conversation --.)
>   8) click "Ok" this time to save what was listed in the.
>   9) Feel insecure about whether all the review updates are, in fact,
> saved.  Stress!  Better double check, step 10??

You should start writing comedy ;)

> The irony is that by every effort to integrate Review+Save, they are
> being made wholly separate activities; exactly the opposite of the
> intended goal.

It also encourages beginners (and reminds seasoned developers) to actually review the changes they are about to commit. That was the purpose of the textual list of changes in the save dialog, and it is made even more in-the-face by the proposed change.

>> Maybe the best of both worlds would be if any change done while the save dialog is open would be added to the changes list automatically? Not sure how to implement that though, MC is thoroughly snapshot-based, and taking a snapshot is not cheap.
> 
> No, the solution is to simply do what we have today.

Other folks seem to like where I was heading. Let's find a solution. I'm pretty sure we can have our cake and eat it, too.

>> Easier to implement might be to warn about intermediate changes.
> 
> No, we need to be moving toward a _less_ rather than more intrusive
> UI.  Warnings create a modal situation and end up getting ignored.
> The user must stay in control.  See
> 
>    http://en.wikipedia.org/wiki/The_Humane_Interface

Agreed, I was thinking out loud and had a better idea below.

>> Upon accepting the save dialog I snapshot the package anyway,
> 
> Yes!
> 
>> to mark the working copy dirty or clean. If this snapshot differs from the earlier snapshot, it could bring up a
>> warning.
> 
> No!
> 
>> Or even better, it could update the changes list with the current one. How does that sound?
> 
> Yes, we must preserve the original save behavior by taking a final
> snapshot and if you want that new (I)gnore feature, then simply let
> that function capture the #description of the Definitions being
> ignored.  Then when the user clicks OK on the Save dialog, after the
> new snapshot, THEN enumerate those definitions of the new snapshot and
> skip the ones whose description matches the ones previously ignored.
> 
> This way the acts of Reviewing and Saving can truly be integrated into
> one step.  Thanks.

So we are in agreement after all? Why do you make it sound all bad then?

- Bert -