I have a simple form like so:


download bmml source – Wireframes created with Balsamiq Mockups

The SMTP settings have a bunch of fields, so the field group is quite long. Some fields have pretty long descriptions. Fields also have different widths to hint to the user the expected field length.

I would like to have a button for the user to test their SMTP settings and return some sort of feed back immediately. I currently have it on the bottom right, but due to the issues with non-uniform field length and descriptions, the button feels very out of place.

Is there a better way to position the Test SMTP Settings button? I would like to avoid it being confused for the submit button as well.

3 Answers 3


Either provide it as a secondary action next to save changes or or simply move to its own row instead of sharing the row with an input field (esp. with the last one, which I guess would be 'port').

In case you're limited in vertical space as well, put it next to hostname - hostname is what defines an SMTP server, everything else is "optional". In case you expect users to authenticate mostly, put it under the password field (in its own row)

In general:

  • in case a secondary button applies to a single field, put it next to a field
  • in case a secondary button applies to a subset of fields, put it under the fields (grouped together) in its own row
  • in case a secondary button applies to the whole form, use the secondary action pattern.

I usually explained proximity of the C.R.A.P. rules as:

"If two things are close together in their topic, they should be close together spatially as well. If two things are entirely separate, they should be separated spatially as well"

Real world is much more complex but one liners are easier to teach.

  • Someone posted this: lukew.com/ff/entry.asp?571. On a question about where to places secondary buttons in forms. It's well worth a read through.
    – Alvin
    Commented Sep 26, 2012 at 10:17

I wonder if you really need that button at all.

Even though it's not mentioned in your question I assume that you later on have some validation to make sure that the email credentials entered are correct? You don't only rely on a user checking if the email is correct, and in that case risk users storing non functioning emails in your service?

In either case I would suggest a different approach, namely removing the separate validation check and integrate the validation and save into one:


download bmml source – Wireframes created with Balsamiq Mockups

Now the email is validated on routine after entry and a user will not have to bother with whether they should check if their email is correct or not, the application handles all entries the same. This way a typo or other problems are handled early on for the users who wouldn't have initiated a validation themselves.

This approach would fall under the error prevention design principle, and is an established strategy to improve the UX of the applications you create.

  • HomerMobile: IMO F21 is not thinking about an email verification like in a logon process, but in the technical checking of the SMTP parameters set like the servar address, the password, and such. Something like the "test connection" buttons in database connection forms. The idea is to reassure the user about the validity of the settings set before commiting them.
    – Juan Lanus
    Commented Sep 26, 2012 at 13:18
  • @JuanLanus oh yea, I'm fully aware of what is going on. I've actually designed the entire sign up process for an Android email client called Mobile Documents. So I'm very well aware of what type of form this is. And I think it's important to validate the credentials early on, thereby integrating it into the flow to completion, rather than having it as a separate validator that's optional. If you have it separated the user will eventually find out if the credentials are incorrect any ways, and then have to revisit the form. It's better to have it done right the first time visiting the form. Commented Sep 26, 2012 at 13:34
  • Interesting idea. This was my initial design as well, but my concern is that it is a bit too rigid. For example, if for whatever reason the SMTP server has an outage, and the user is trying to save the form, saving would fail. The user would then have to wait until the server is back up to save the form. What are your thoughts on this?
    – F21
    Commented Sep 26, 2012 at 23:31
  • @F21 I see your point. That's a bit tough though. A solution in this case would have to be for the user who's a 100% sure of their credentials AND very accustomed to/experienced with setting up email. You could after the validation fails offer the option to [Continue anyway] in addition to the [Proceed]-validation. I assume though that a low amount of users would still continue after the system responds that it can't contact their email servers. It's very very hard to design solutions for external errors, internal are easier. =) Commented Sep 27, 2012 at 7:20

Just as a test, I rearranged your single-column form (labels on top of inputs) as a two-column form (labels before inputs), thinking that the test button might appear misplaced because all the data was so stacked at the left of the container, and there was a huge whitespace spanning the right half.
The form got "shorter", less daunting. Maybe it doesn't need to be scrolled now.
It looks so:


download bmml source – Wireframes created with Balsamiq Mockups

Also, I gave the "Test..." button a secondary action look through a smaller font. In the actual UI it can also have a lighter color and border, etc...
One nice touch would be to show the "Test..." button disabled, and only enable it when the user has entered enough parameters to allow the connection test.

Who said that labels have to be one-liners? Not me.

  • Having labels left aligned and the input fields aligned left as well widens the distance between description of a field and the actual field, this is generally not something you want. Plus, white space is good, it makes it easier for the user to orientate. And yea, having labels one-lined is definitely something to strive for, especially if they're descriptions for input in a form. Commented Sep 26, 2012 at 13:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.