Re: network-manager-n2n

[David Woodhouse <dwmw2 infradead org>]

On Tue, 2009-06-09 at 14:01 -0400, Dan Williams wrote:
> On Tue, 2009-06-09 at 16:57 +0100, David Woodhouse wrote:
> > On Tue, 2009-06-09 at 11:37 -0400, Dan Williams wrote:
> > > Well, think about GUI config now *too*, since otherwise, you're
> > > basically giving users the finger.  If the VPN has a lot of options, a
> > > lot of thought needs to go into the interface to make sure you don't
> > > just have a huge dialog with a bunch of buttons that no user can ever
> > > hope to comprehend.  Just making it "the sysadmin's problem" isn't the
> > > right solution either.
> > 
> > Right. Although I do much prefer the 'run this shell script and then
> > it'll work' approach rather than trying to tell people how to set it up
> > the pointy-clicky way :)
> 
> That's because you use computers and know what to do :) 

That's precisely why. I know what to do, and I've encoded it in the
shell script. I don't want to play chinese whispers, telling the user
how to tell their computer what to do.

>  Too often, it doesn't always work after running the shell script, or
> it'll work for a while and then somethign stops working, and it's
> quite useful to have a UI that users aren't entirely confused by,
> where they can at least try and validate whether the settings look OK.

Well, maybe. For my sins I ended up doing the support for Linux
connectivity to our corporate VPN. Which included having to write a VPN
client from scratch, since the 'official' one was such a pile of crap ;)

I'm much happier with the instructions that say 'run this script which
will fetch your certificate for you and then set up NM for you', than I
would be with letting users set up NM for themselves.

The shell script in question goes something like...

CONNECTIONNO=1
while gconftool-2 --dir-exists /system/networking/connections/$CONNECTIONNO; do
      CONNECTIONNO=$((CONNECTIONNO+1))
done
echo Connection number $((CONNECTIONNO))
TIMESTAMP=`date +%s`
UUID=`cat /proc/sys/kernel/random/uuid`
gconftool-2 --load - <<EOF
<gconfentryfile>
  <entrylist base="/system/networking/connections/$CONNECTIONNO">
...


Of course there _must_ be a decent GUI too, and even when users are just
following instructions it's good for them to be able to see and validate
the settings for themselves -- but if they're going to report problems
to me, I want gconftool-2 --dump output not screenshots :)

> > > But if you're just getting it up and running for now, then yeah, the
> > > GUI bits aren't necessary quite yet, but can be done after that.
> > 
> > Yeah -- that's what I meant. You can get the nm-n2n-service bits done
> > first, then do the GUI _second_. Not that you can defer the GUI for
> > ever. I think I did it the wrong way round, by attempting to do the GUI
> > first.
> 
> Certainly not.  IMHO everything we do should look at user scenarios
> first (with a full knowledge of how things work underneath of course),
> and drive the interaction and operation from that angle, working to
> ensure that just because the UI doesn't expose something doesn't mean it
> can't be changed, but ensure that we don't show users options they won't
> require on a daily/weekly basis.  We should *always* be thinking about
> how the user (be they CLI or GUI users, doesn't matter) will interact
> with the software we write.  It shouldn't just be "magic!", but should
> give the users some understanding of how things work and operate.

Absolutely. But that doesn't mean you have to _implement_ the GUI part
first. In the openconnect case, the GUI would probably have been simpler
if I _hadn't_ done it first.

That's mostly because I was asking questions in the UI that turned out
not to be necessary -- I can _infer_ the answers reliably enough, but
that didn't become obvious until I came to implement the back end. 

So I don't _need_ to be asking about the type of the SSL client
certificate, and I didn't really need to ask about the username either
(since the auth-dialog will just store that for itself, along with all
form input other than the password).

The only reason I still have the 'authentication type' option in the UI
configuration is because I haven't worked out how to _remove_ a file
once it's been configured -- how, using the file chooser thingy, does
the user set it to its original state of 'no file selected'? 

-- 
dwmw2