Hi Christoph,
thank you for your arguments!
Your genuine appreciation for good design makes discussing and searching for ideas an enjoyable experience for me as well, thanks. :)
First, I share your concerns about too much interruptions from a UI. However, I would differentiate between hints and warnings. Hints should be optional and non-interrupting, but IMHO, warnings should indeed assure to attract the attention of the user. IMHO, "there is a superfluous halt in this method" goes into the category of warnings. Thus, I don't want to press an additional button to get that information. Similar to commiting a version without a message, I would consider this a situation where it would be appropriate for the tool to interrupt me and ask me to confirm my intention.
I agree with those sentiments about hints vs. warnings, however, I don't think they're germaine to this feature about slips. For the "maintenance" phase of a project, where basically only bug fixes are being done, I can appreciate your position better. Developing a large complex project from scratch over a period of months, however, often involves making "checkpoints" along the way that one can easily revert to, for example, to conduct a design experiment that might turn out to be infeasible, and require a reversion. The project is not close to done, and so there's a lot of debugging code still lying around. It's a time when the developer WANTS her halts, and doesn't want to be distracted by a bunch of pop ups about lint just to begin working on the experiment. And yet, if an update to a CORE package were necessary along the way in order to support the new project, she might want to check for slips in THAT package before committing. It really needs that on-demand capability which a global preference cannot do.
Also, how often do you actually see a detected slip? Keep in mind that this feature is enabled by default for changesets. I'm working quite a lot with changesets (just search the list for "[Review Request]" :-)), and I would estimate that I see a warning in maybe 1 of 50 file-outs. Given such a low positive rate, my (and probably many other poeople's) motivation to press an extra button would be pretty small.
I don't care for economic arguments like this because they can have a compromising effect on quality prior to asking the question, "what is the flat out best design, independent of development cost?" I feel this should be asked first, THEN figure out how to make it economical. I also believe it's important to also always favor the *user's* economy over the developer's, because the developer's cost is finite, whereas the user's costs (and benefits) are theoretically infinite. I don't think the ideas we're tossing about are overly difficult, so they're at least worth considering.
Second, a good portion of your arguments reads to me as if they would relate to the existing checkForSlips preference/behavior in general but not to a - kind of missing - application of the already existing concept to the Monticello UI. Maybe we should consider to turn off this feature by default or make it non-interrupting. I like your idea of color cues, which could be applied both to the ChangeSorter and to the MCSaveVersionDialog. We could also colorize the "accept" button itself to make it more obvious. I want to give this approach a try. I will send another changeset for that.
Thanks for exploring options using colorization and/or emphasis to instantly inform the user (possibly without any button presses)! I was only thinking about the MC save dialog during this discussion and not filing out changesets. I wouldn't want "consistency" to be a reason the MC save dialog would be restricted from being the best design it can be.
Still, I am not convinced that we should *not* interrupt users before they are saving an isThisEverCalled to the Trunk. :-)
I understand, but we should be careful, such an interruption will not catch other slips, nor guarantee quality. Having tools that "kinda sorta halfway help," could potentially deter the development of other true processes and tools for guaranteeing quality, while accumulating complexity into the system over time.
Best, Chris