Where to put buttons on forms

• Buttons, Where
where-to-put-buttons-on-forms

Button placement on forms is often ignored or prioritised based on what looks good.

But button placement can make or break a form, and a form can make or break a user’s experience. That’s why it’s essential to get it right.

This is more challenging that in sounds because it depends on the buttons and the form in question.

It also requires us to analyse different forms holistically. Otherwise we could end up with the same button appearing in different places which is inconsistent and confusing.

Here I’ll explain where to put buttons across a range of different forms based on research and best practice.

Align the primary button to the left edge of the inputs

Left: a right aligned button (not recommended). Right: a left aligned button (good).

In his article reporting on eye-tracking research, Luke Wroblewski says the primary button should be aligned with the left-hand edge of the input:

“illuminate a clear path to completion. Aligning inputs and actions with a strong vertical axis clearly communicates how to go about completing a form.”

This layout also helps screen magnifier users to see it without having to pan across.

Left: right aligned button when zoomed in—can’t be seen. Right: left aligned button when zoomed in—still visible.

Put the back button above the form

Left: back button next to the primary button (not recommended). Right: back button above the form (good).

Some forms or questionnaires appear across multiple pages and some people want to go back to check or change their answers.

Unfortunately some users don’t trust the browser back button because of their experiences of poorly designed forms that lose data when they click back. The solution is to provide a form-specific back button.

Research carried out by Mick Couper, Reg Baker and Joanne Mechling shows that placing the back button to the right of the primary button is confusing and it should go either to the left or underneath instead.

Underneath is preferable because it keeps the primary button consistently located and lets keyboard users tab directly to it from the last field.

But their research did not include an option with the back button at the top of the page.

Joe Lanman, a designer at the Government Digital Service, put the back button at the top of the Register To Vote exemplar digital service. It’s now the standard approach for all government services.

A question page from the Register To Vote service which shows the back link at the top of the page.

Joe said putting the back button at the top works well because it’s:

  • in a similar place to where most browsers put the browser back button
  • most likely to be needed soon after the user lands on a page that looks wrong or if the user wants to check what they just entered
  • probably not needed once the user fills out the form—if they fill out the form and click back, they will lose their answers

This approach clearly differentiates the back button from the primary button which should decrease the time it takes users to proceed. And it makes room for additional buttons when needed which I’ll cover later.

Left: ‘forgot password’ link within the form (not recommended). Right: ‘forgot password’ link outside of the form (good).

Some forms have actions that don’t submit data and are only tangentially related to the form itself.

For example, a ‘forgot password’ link on a login form lets users reset their password—but it’s not part of the login process itself.

You’ll often see the ‘forgot password’ link next to the password field, but this is problematic because users:

  • expect the tab key to focus the next field/button
  • might have to scroll to find the link
  • might waste time typing in their email address before clicking the link

Putting the link above the form solves all of these problems.

Forms with multiple buttons are problematic.

The time it takes to make a decision increases with the number and complexity of choices, so extra buttons add extra choice and extra time.

Also, keyboard users can’t be sure which action will be taken when they press the enter key to submit the form.

That said, sometimes having multiple buttons is necessary.

Thinking about what the buttons do makes it easier to decide where to put them.

Let’s look at 3 examples that need different treatment.

1. Put the cancel button below the primary button

Left: cancel button alongside the primary button (not recommended). Right: cancel button underneath the primary button (good).

Luke Wroblewski’s research shows the cancel button should be to the right of the primary button and styled less prominently as a link.

But putting the cancel button below the primary button has some advantages:

  • Firstly, it conforms to forms expert, Caroline Jarrett’s rule, make it harder to find destructive buttons.
  • Secondly, as explained in the back button and additional links sections, the cancel button is not directly related to the form itself so it makes sense to put it below the primary button.
  • Lastly, it frees up space for other, directly related buttons to be on the same row. If you put lots of buttons in a row then it’s harder for users to work out which is most important.

2. Put the ‘add another’ button above the primary button

Left: ‘add another’ button next to the primary button (not recommended). Right: ‘add another’ button just above the primary button (good).

Sometimes users need to add additional information. For example, if they need to add the names of their family members to a booking.

Putting the ‘add another’ button above the primary button has the following benefits:

  • users don’t have to go past the primary button to select it, which conforms to Caroline Jarrett’s rule, put buttons in a sensible order
  • the primary button stays consistently located on the left hand side as explained earlier
  • like Erik Kennedy explains in The 3 Laws of Locality, it’s located where it affects change—next to the field being cloned

3. Put the ‘save and exit’ button next to the primary button

Left: ‘save and exit’ button button above the primary button (not recommended). Right: ‘save and exit’ button next to the primary button (good).

Sometimes users might need to save their progress on a long form.

Putting the ‘save and exit’ button above the primary button implies it’s more important, when it isn’t.

Putting it below can cause an unwieldy list of stacked buttons and uses the area reserved for the cancel button.

That leaves us with putting it next to the primary button which makes sense as the action is directly related to the form.

In some single field forms put the button next to the input

Left: button below search box (not recommended). Right: button next to search box (good).

On rare occasions, you can put the button next to the input, which is often seen in global search forms in site headers.

While there’s nothing especially wrong with putting the button below the input, putting it next to it saves space and looks a bit neater.

But do not do this on standard forms that happen to have just 1 field. It’s inconsistent and unconventional.

Put buttons on multi select forms above the form

Left: multi-select buttons below the list (not recommended). Right: multi-select buttons above the list (good).

Multi-select forms let users select and action multiple items at once. For example, in Gmail you can select multiple emails and archive them in one go.

In this special case, put the buttons above the form.

This is another example that works because of Erik Kennedy’s rule, if a control affects change across an entire area, put it above that area.

Putting the buttons above the form also leaves room below the list for things like pagination which is often needed in these types of interfaces.

Summary

In this article, we’ve looked at where to place buttons across a range of different forms.

Whether it’s 1 button on a standard form or multiple buttons on a multi-select form, button placement is crucial and needs due care and attention.

Checklist

  • Align the primary button to the left edge of the inputs
  • Put the back button above the form
  • Put tangentially related actions above the form
  • Place extra buttons based on what they do
  • In some single field forms put the button next to the input
  • Put buttons on multi select forms above the form

Thanks a lot to Caroline Jarrett for helping me write this.

—

I write articles like this and share them with my private mailing list. No spam and definitely no popups. Just one article a month, straight to your inbox. Sign up below:

Where did CSS named colours come from?

• named, Where
where-did-css-named-colours-come-from?

Talk.CSS, which is Singapore’s monthly CSS meetup, has a segment called CSS colour of the month, where we mention 1 of the 148 named CSS colours. This works out to more than 12 years worth of meetups, and I figured we’d run out of meetups before we ran out of colours.

Since Wei became a co-organiser, we’ve each been taking turns picking the CSS colour of the month, and for the August edition, she picked snow. The hex code for snow is #fffafa, which works out to a RGB value of rgb(255, 250, 250).

Some of you who are familiar with the notation may already have realised that this gives us a gentle tinge of red. Very, very slight, but still, red. And Wei noticed that snow was red(ish). I had no idea why that was, but I wanted to figure it out.

What do the specifications say?

There is a specification called the CSS Color Module Level 4 that is currently in Editor’s Draft status and it defines the colour-related properties and values that already exist in CSS1, CSS2 and CSS Color 3, plus new properties and values. So I thought that’d be a good place to start.

Scroll down to section 6.1 on named colours and we find this:

16 of CSS’s named colors come from HTML originally: aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, purple, red, silver, teal, white, and yellow. Most of the rest come from one version of the X11 color system, used in Unix-derived systems to specify colors for the console.

Ah hah! The X11 colour system! The specification also points us to a talk on the history of the X11 colour system by Alex Sexton in his talk entitled Peachpuffs and Lemonchiffons at CSSConfUS 2014:

It’s a great talk, and is one of my favourites. If words are not your thing, just skip the rest of the article and watch Alex talk about colours instead. Super entertaining. ❤️

Also, as someone who personally knows Chris Lilley, I’d like to publicly acknowledge that he is one of the nicest, sweetest people I know. Just putting it out there.

Another fun thing I discovered while reading the specification was that CSS defines a set of values which allow us “to specify colours in a manner that integrate them into the users’ graphic environment.”

There are security and privacy considerations to this particular feature because in theory, this exposes details of the user’s OS settings, which could be used for fingerprinting. Also, this may make it easier for malware site builders to create user interfaces that seamlessly correspond to an user’s system.

The specification does state that several system colours are now defined to be “generic”, hence mitigating this risk. This makes me appreciate the many different angles that the CSS Working Group considers when authoring specifications.

I really quite like this specification, so do give it a read if you like colours as much as I do.

So what’s this X11 all about?

I messed around with Linux operating systems quite a bit before I even go into web development, so X11 isn’t something that is foreign to me. X is a portable, network-transparent window system. X11 is version 11 of the X Window System.

X was built upon an idea developed by Jim Gettys and Bob Scheifler from MIT. Why the name X? It is a derivation of a pre-1983 window system called W, which ran under the V operating system.

From the documentation:

The X Window System is a network transparent window system which runs on a wide range of computing and graphics machines.

The documentation also contains a brief section about colour names, but it didn’t go into the choice of colour names. It just mentions that X supports the use of abstract colour names and that the value for this abstract name is obtained by searching one or more colour name databases.

I came across this excellent deep dive into colour-name dictionaries by MIT alum, mathematician and free software developer, Aubrey Jaffer. From there, I found some links to early X11 colour dictionaries, and also learned about colour spaces and tuning.

The X server’s database that contains all the colour names is commonly located at /usr/share/X11/rgb.txt. Upon further digging into the version control logs, we can find the list of original colour names that were checked into version control on 19 August, 1985 by Jim Gettys.

2 files were added in that initial commit. rgb.c for parsing the colour list text file and rgb.txt, which contains a list of 68 colours, each with 2 formats of name, camelcase and lowercase with spaces.

The next update to rgb.txt was on 23 February, 1988. That added brown, grey and gray to the list. The RGB values for white were updated from 252, 252, 252 to 255, 255, 255 on 13 May, 1988. An entire grey scale consisting of 100 shades of grey were added to the list on 3 September, 1988, and sandy brown was added the next day.

I highly suggest taking a look at the commit log because amongst the standard messages like added grey0-100, there were fun ones like removed blank line; boy, what a stupid program and made Keith happy among other gems.

snow was added to the list on 26 October, 1989 when the list was expanded with colours which were tuned by Paul Raveling at the Information Sciences Institute (ISI) for the HP monitor. From his notes, we find:

Light and off-white colors, copied from several Sinclair Paints color samples. The intent for adding these is to provide a better choice for light-colored window backgrounds.

Ah hah! The next clue is Sinclair Paints. The Sinclair Paint Co. was a family business founded and run by 6 brothers in the 1930s. The company expanded into several different product divisions, and individual family members specialising in certain aspects of operations.

Unfortunately, the company is now defunct and not much can be found about their original paint swatches. A couple of forum posts on PaintTalk.com are all we have left.

From Alex’s talk, I also managed to dig up links to the comp.windows.x mailing list comments which covered the issue of colours, like the one titled “This is pink??”.

Segue into paint colour names

Perhaps we won’t be able to figure out why snow has a red hue, but it does beg the question of how paint companies name their colours. British paint company, Farrow & Ball, which has been around since 1946, is known for their creative colour names.

Slate.com did some research into this and found that the quirkier names all have their own back stories, but to an extent, it can be considered a marketing thing.

Behr Paint even put a job listing for the position of Color Explorer, which has since been filled. For people who are interested, there was an AMA on Reddit done in 2015 by the folk who name paint colours at PPG Architectural Coatings, where questions about naming colours were answered.

Why did CSS use the X11 colours?

All the discussion around the development of CSS specifications takes place in the open, so it’s possible, with some patience, to dig up the relevant discussion threads on the www-style mailing list archives.

Much of the discussion took place during between 1996–1998 when CSS1 and CSS2 were released, then again between 2001–2002 when the CSS Color Module Level 3 was being released. Feel free to peruse the message threads if you would like to read some occasionally strongly-worded opinions.

To read through whole threads, scroll down to the bottom and click through the Next in thread link.

Of course, there were also some light-hearted moments in there. Tongue-in-cheek seems to be a popular style of humour on that mailing list.

A story about orange

Eric Meyer offered this lovely story of how orange made it into the CSS2 specification. Turns out, he used color: orange for a lot of tests in the CSS1 Test Suite, which the W3C published and browsers supported just fine.

However, because orange was never a colour name in CSS1, it was technically invalid CSS. (Refer to Preview: CSS1 Test Suite where Ian Hickson picked out the fact that orange is not in CSS1 and was an IE4 invention in his reply to the original post)

Basically, orange was added CSS2 pretty much specifically to make the CSS1 Test Suite valid, which led to jokes like “CSS2: Now with more orange!”. This incident was also referenced Easter-egg style in the January 1999 issue of Web Techniques.

Cover of the January 1999 issue of Web Techniques magazine

Eric had written the cover article about CSS2 in that issue and requested a detergent-style cover with orange as the primary colour. The article’s headline was also set in orange. I LOVE IT. And I’ll close off this little anecdote with a quote from Eric:

Remember, the root of it is: I goofed. Always validate, kids!

Wrapping up

So I didn’t manage to track down the actual reason why Sinclair Paint Co. named the white with a slightly reddish hue, “snow”, but I did find out a whole lot of interesting and entertaining things about colours.

The surface has barely been scratched here. And as someone who loves colours, I’m fairly certain this is not the end of things. Stay tuned, my friends!


Design, CSS

Where do you sit on the “martech is marketing” spectrum?

• MarTech, Where
where-do-you-sit-on-the-“martech-is-marketing”-spectrum?

McDonald’s.)

I’m curious: Where does your organization fit into this spectrum? Click here to find out.

If you agree that “martech is marketing,” join me and 2,000 senior-level marketers at The MarTech Conference, this September 16-18 in Boston. You’ll access 55 expert-led sessions loaded with creative, real-world, vendor-agnostic solutions and actionable tactics for overcoming sticky marketing challenges.

Ready to register? Pick your ideal pass and book now!

See you in Boston 🙂

Psst… I’m hosting a live Q&A webinar on all-things martech this Thursday, August 15 at 1:00PM. If you have questions, curiosities, or feedback, now’s the time to share! Secure your seat today.

Opinions expressed in this article are those of the guest author and not necessarily Marketing Land. Staff authors are listed here.


About The Author

MarTech® Conference, a vendor-agnostic marketing technology conference and trade show series produced by MarTech Today’s parent company, Third Door Media. The MarTech event grew out of Brinker’s blog, chiefmartec.com, which has chronicled the rise of marketing technology and its changing marketing strategy, management and culture since 2008. In addition to his work on MarTech, Scott serves as the VP platform ecosystem at HubSpot. Previously, he was the co-founder and CTO of ion interactive.