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 <[EMAIL PROTECTED]> _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
