Re: [Evolution-hackers] Integration of ximian-connector-setup with mail configuration for Exchange connector

[Not Zed <notzed ximian com>]

> Michael, Jeff, Surf, Other Mail people -- what do you guys think about 
> having a "Server Type" page first in the druid, before the identity 
> page. The page would be something like this:
>
> "What type of account do you want to add?"
>
> <radio button>IMAP
> <radio button>POP
> <radio button>Exchange
> <radio button>Groupwise
>
> etc.
>
> The advantage of doing it this way is that if we us radio buttons 
> instead of an option menu, we can list all of the account types so that 
> they are visible without needing to expand the option menu. Also, this 
> would prevent us from needing to put something on the "Identity" page 
> which is not strictly related to identity.

The only real problem here is that there may be many different account types, or not many at all.  It is a dynamic list based on the installation, so if you have too many there it could become unwieldy.  Perhaps a list with a description below or next to it would be better?

The other problem is that currently this code is driven by the same code that drives the 'sending' account info too, where it is needed - so that code would have to be done quite differently now.  But then again the changes required will already require some re-architecting, so this may not be a driving issue.
> > I have attached 2 images, which are just the prototypes,
> > which show how the druid would look like. I have not
> > taken care of any usability guidelines such as padding,
> > accelerators, separators, font size, alignments etc
>
> If you need any help with the HIG stuff, please let me know.
>
> > The "Receiving options" page, would be the 3rd page for
> > Exchange server type, and would remain as the 4th page
> > for other server types.
> > And for exchange server type, "Receiving options" page
> > would have only "Checking for New Mail" and
> > "GAL/Active Directory" sections as in the image-2 (recv-options.png
>
>
> This looks pretty good, basically. There is of course some HIG stuff to 
> be done, and some thinking that needs to go into how to phrase the 
> labels exactly, but all in all -- good work!

A lot of the hig policy stuff will/can be driven by the e-config plugin stuff anyway (e.g. spacing, labelling), so the problem will lessen.  The code needs some other fixes first for this to happen but they should be mostly transparent to the plugins.

--

Michael Zucchi <notzed ximian com> "Evolution - Mostly Practiced By Dumb People" Novell's Evolution and Free Software Developer