Calum Benson wrote:
> 
> On 11 May 2009, at 11:32, Darren Kenny wrote:
> 
>> Hi John,
>>
>> On 08/05/2009 21:17, John Leser wrote:
>>>
>>> Having outlined the concerns with the current method, the solution we
>>> are now considering for upgrades is:
>>>
>>>  1. At upgrade time, migrate existing NWAM state into the User NCP.
>>>  2. Always activate the Automatic NCP after an upgrade.
>>
>> I think that this makes sense, although I do think that some logic 
>> could tell if
>> the upgrade is different - mainly by generating a new User NCP, and 
>> comparing it
>> to the Automatic NCP - if they are the same use the Automatic NCP.
> 
> Either way (and this is more of a note-to-self), we might need a minor 
> tweak to the online help here... IIRC it currently specifies that the 
> User NCP will initially be a copy of the Automatic NCP, which isn't 
> necessarily going to be the case after an upgrade.
> 
>> The main concern I would have is that we are telling people things 
>> that they may
>> simply not care about - and we'd likely have to do this for all users 
>> of a
>> system, that's why I would prefer we at least try to ascertain if the 
>> switch is
>> really necessary.
>>
>> Calum, and ideas here?
> 
> Hmm.  As always, we certainly want to minimise the amount of stuff we 
> pop up in users' faces.  However hard we try, most people aren't going 
> to read it, let alone remember it later.
> 
> First off, from a user's perspective, I have to say I'm not immediately 
> convinced by the reasons for forcing me to the Automatic NCP after 
> upgrading.  If my seamless upgrade experience is best served by 
> switching me to the User NCP so that my network functions the same as it 
> did before I upgraded, then as a user, that's what I'd want to happen.
> 
> I certainly wouldn't care that it makes my configuration non-default, or 
> different from my co-worker down the hall who did a fresh install.  I 
> only expect default behaviour if I've done a fresh install, otherwise I 
> expect as much of my previous environment to be migrated as possible.  
> Users' number one concern when upgrading anything is that Everything 
> Still Works.
> 

Calum, I agree all of these concerns are valid.  Maybe I / we are 
underestimating the difficulty of educating the user through the UI.

I'd add that the idea of pushing people toward the Automatic NCP is also 
partially motivated by the idea that the default behavior in phase 1 is 
much better (esp. for multiple interfaces are available) so less 
customization should be needed.

My main concern for having people on the User NCP is that choosing 
between the User and Auto NCP is supposed to represent a selection of 
"less" or "more" automatic behavior.  We're making this choices on 
behalf of the user for an essentially unrelated reason.  If there were 
no distinction between the two NCPs other than one having read-only 
contents, it would be much easier for me to embrace the User NCP for 
migration.  If that's the design, "Default" might be a better name than 
"Automatic".  But I think right now, there are some difference in how 
new devices are handled that makes the Auto NCP more automatic than the 
User one, in terms of the default activation modes.

-John

> (If we went that route, I guess we could still pop up a message on first 
> login after upgrade if we really wanted to, that said something along 
> the lines of "for future reference, we've switched you over to the User 
> profile so that everything still works... but if you have problems, you 
> might like to try the Automatic profile instead".  But in practice 
> there's usually little point telling people about something they might 
> want/have to do at some point in the future, because they'll just forget 
> what it was they had to do or how to do it anyway.)
> 
> If we're stuck on the forced-Automatic route, maybe it would be 
> feasible, only on the first login after upgrade, to wait and see if the 
> Automatic NCP results in any connection being established, and if not, 
> switch over to the User NCP instead?  (And if that results in a 
> connection, *maybe* display some sort of message saying what just 
> happened; if it doesn't, just switch back to Automatic and report the 
> lack of connectivity in the usual way?)  Not suggesting that would be 
> foolproof, but it would at least give Automatic a fair crack of the whip 
> before falling back to the user's previous configuration if that was the 
> only thing that worked...
> 
> Cheeri,
> Calum.
> 


Reply via email to