Re: [Evolution-hackers] [Fwd: Re: [evolution-patches] [PATCH] IMAP preauth and subcommand connection.]

[Not Zed <notzed ximian com>]

On Thu, 2003-07-31 at 11:30, David Woodhouse wrote:
> On Mon, 2003-07-28 at 14:14, Ettore Perazzoli wrote:
> > On Wed, 2003-07-23 at 14:59, Anna Marie Dirks wrote:
> > > the way that we present information which is optional to the user >
> > > is to desensitize it, until the user makes a selection which calls >
> > for it to become live
> > 
> > No, the entry isn't used by 99% of the users and is just a hinderance
> > unless you need it.  It makes the dialog more difficult to parse and
> > hence more difficult to use.
Neither is 'Organization' yet we have it there (as do most other mailers, god knows why, its kind of useless, pointless, and i dont think anybody shows it by default in the mail display).

How is it a hinderance if you can't even select it?

> Personally, I agree with Anna -- but I don't care much either way. Sort
> it out between yourselves and I'll implement whichever I'm asked to.
>
> > > 1) In the druid, stop trying to cram settings for server identity,
> > > connection type, and authentication all on one page. Just relax. We have
> > > other pages, we even have another page for Receiving Mail stuff.
> > > Constrain the widgets shown on the first page to be: 
> > > 
> > > http://primates.ximian.com/~anna/mailsettings/start.png
> > 
> > See what I mean?  It shouldn't expose the concept of a "command" to me
> > in the default page.  If I am Joe Random user, I don't even know what a
> > "command" is.
>
> Neither do you know what a namespace is. And, for that matter, you don't
> know what 'IMAP' and 'POP3' are either. Or what a 'server' is unless
> she's bringing you your drinks.
>
> You have to draw the line somewhere, Ettore -- and I think it's sane
> enough to expect a user to be able to understand that they can ignore
> something that's greyed out.
And the worst that  can happen is they get an error box, give their isp/sysadmin a call, and they have to fix their config.

Why all the fuss about such a simple thing?  As stated above, we already have a huge pile of jargon-terms, and if you try and 'hide' too much detail it simply creates more confusion.  Should we call 'pop' 'server mailbox' instead, no of course not.

'Command' is what the panel launchers use to specify commands.  However the Ximian menu's call them 'programs' (e.g. 'run program' in the system menu).  So there's already an inconsistency there, and it would hardly make sense to create some other name, or HIDE what is ALREADY DIRECTLY VISIBLE in SEVERAL LOCATIONS, it would just create more inconsistency.

> > The command isn't necessarily a security feature though.  So "command"
> > should be a separate option from "secure connection".
No, its a connection type, and it makes sense to have it there.  Its where it physically needs to be in the code, and its logically how the user selects what to use.  Unless we add another layer, e.g. connection type 'host or command' and then security type 'none/ssl/tls' for that connection.

Actually this discussion has been going on so long i've got no idea what the last iteration of the ui was.

And i can't see the ui images anymore so i can't remember exactly what is going on on that page, can they be restored or is the work lost?

> Yes, possibly -- and technically I suppose we could even do SSL over the
> socket we open to stdin/stdout of the command... but I wasn't going to
> suggest that. Again, sort it out between yourselves and let me know :)
>
> Perhaps I should split the patch into two -- the implementation and the
> user interface which lets me set the appropriate bits in the
> configuration?

Well we need both.  I'm not sure why there is so much disagreement here, many of the UI's we've come up with are certainly usable enough, and there is no perfect ui for anything anyway.

I think we should get this in, the next freeze is soon, and quite frankly we've wasted far too much of our own and David's time to be bickering about petty issues to do with what is a pretty minor alteration to the interface.  And one that will benifit from user feedback more than a re-run of the same arguments.

Is the latest patch on this list still applying against head, or can you send an updated one David?  Its time to move this forward based on real technical issues.

 Michael