Positioning a secondary button within a form group with fields of varying widths

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.