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



Hello David, Ettore, Michael and hackers:

The plan discussed here seems fairly reasonable to me; I have only a few
simple concerns.

Il mar, 2003-07-22 alle 15:34, David Woodhouse ha scritto:

> True -- if they have to look at the help text we're already doing
> something wrong. 

This isn't necessarily true. Presumably the widgets associated with this
command have to appear in the account setup druid as well as in this
dialog, right? It is standard practice to put a bit of help text at the
top of each druid page.(Which is not to say that we necessarily should
include info about this custom command business in the druid, but rather
to point out that including some measure of help within the window the
user is using is not always a sign of defeat.) 

> That's why I put in a default command which uses both
> $URLUSER and $URLHOST, rather than leaving it blank by default and
> forcing the user to enter _something_. It's self-documenting like that.

Hmm. The need for a custom command isn't predicated on the ability to
understand syntax like '$URLUSER'. (Which, btw, if you read it aloud in
English, is a homophone for "You are loser." eek. Hardly the message we
want our users walking away with, is it. :) 

(It also concerns me a bit to put text in the entry, which if the user
just accepts it as is, would lead to their mail setup being necessarily
dysfunctional. I'd rather force them to type something into the entry..)

Speaking of odd wording, in one of your earlier mails, you proposed the
following structure for the "Connection type" option menu. 

>  Connect using' [remote host]
>                 [always ssl]
>                 [ssl when possible]
>                 [command] 

I have to wonder how many average users would understand "remote host"
in that context. To be frank with you, I have worked on Evolution for
three years, and I do not know what you mean. Can you think of a more
simple way to explain what that option means? 

Further, the current UI gives some context for "ssl" by saying "Use
secure connection". It would be nice if your UI provided some context
for "SSL" as well. (Besides "connect using", which doesn't so much get
the whole "this is related to security" thing across. :)

> > > In the case where the connection type is set to something other than
> > > 'Custom command', we can either grey out or completely remove the text
> > > entry box for the actual command -- and when we first enable 'Custom
> > > command' the text entry box for it comes back, with the sane default
> > > which makes the $URLHOST and $URLUSER stuff obvious.
> > 
> > If we go this way we should be hiding the entry completely, because you
> > don't want the default page to be clobbered with details 99% of the
> > users do not care about.

You also, though, don't want the dialog to resize (grow larger) when the
entry is shown. (Yes, if we had the super smooth and gliding animation a
la OSX, then the effect of a dialog growing like that would be less
jarring. While we don't, though, we should avoid subjecting users to
nasty jumping dialogs.)

Within the rest of the account druid and account editor, 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-- cf
the "Authentication" options in the "Sending Email" page of the druid.
For consistency's sake, I would prefer that we handled the custom
connection command stuff in the same way.

My recommendation for how to handle these options is therefore:
(NB: I followed the Gnome HIG's recommendations for frame style,
bolding, etc in the following mockups-- we are definitely going to
eventually use the HIG everywhere, you might as well see how it would
look HIG'ified for now. (Following the HIG cuts down a bit on how much
stuff we can put on once page anyway, because they specify significantly
more space/padding between widgets than we had been using.)
 

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

2) Make sure that you really cannot accidentally specify a custom
command by only allowing those widgets to be sensitive when both the
"Use blah blah" checkbox is clicked, and the "custom command" option is
selected in the option menu. The shot below shoes the entry still being
insensitive, because a different command is selected from the option
menu... 

http://primates.ximian.com/~anna/mailsettings/secure_selected.png

3. Move the authentication stuff to the next page, with the other
receiving mail settings. Rename that page "Receiving Email, Continued"
or something. 

4. In the account editor (that is, the dialog shown in the screenshot
you posted..) take out the "Description" stuff, and add a frame for
"secure connection options" a la the druid.

Now, maybe this is way too much work, or maybe it isn't technically
feasible to just move the authentication stuff over a page, or maybe
<insert some other reason why this approach is nonviable here>. Maybe
these options are really *so* esoteric that they just don't deserve the
real estate I am giving them.

In that case, what I think you should do is: try to come up with more
simple and descriptive labels, include the desensitized command widgets
by default so that the dialog doesn't jump around, and, if you are going
to include an example, include it beneath the "command" entry so that
the user is less tempted to think that it is a valid command.

My 4 cents.
Anna

-- 

Anna Marie Dirks <anna ximian com>




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]