For example user have Options page with long form in it. The most popular options are often on the top of the form, so user is changing them and have to scroll to the bottom of the form to hit "Submit" button. Imagine if user have to change something often and each time user should scroll to the bottom of the page to submit the form. IMHO it would be better for users to put "Submit" button above the form and they would scroll less. Example for testing two different types of forms on jsfiddle.

Sometimes long forms are splitted into tabs for making the form easier to use. But still it would be better to place "Submit" button above the tabs, because the height of tabs are different and the position on "Submit" button will not be the same.

Advantages of placing "Submit" button on the top:

  • "Submit" button is always on the same place no matter of how long form is
  • if the most frequently used options of the form are placed on the top part of form (as it should be) than in most cases "Submit" button will be visible for user without the scroll

Is there any disadvantages in placing "Submit" button on the top of the long form?

Possible compromise: maybe it would be good for users to put two "Submit" buttons in the long forms (one on the top of the form, another - at the bottom).

Similar question.

P.S. In the login or registration or survey forms "Submit" button should be in the bottom of the form because user will fill the text-inputs one-by-one and in the end user will hit "Submit" button. It would not be useful to place "Submit" button on the top of the form in these (or similar) cases.

  • 4
    You could try a fixed header/footer solution where the submit button is always there
    – Ben Brocka
    Aug 16, 2012 at 21:23
  • @BenBrocka +1 Great solution. IMHO fixed block with "Submit" button solves all the problems with long forms.
    – webvitaly
    Aug 16, 2012 at 21:38
  • I swear I've seen that used as a pattern but can't find an example
    – Ben Brocka
    Aug 16, 2012 at 21:41
  • @BenBrocka Similar approach is used for 2-level menu on Bootstrap site - twitter.github.com/bootstrap/base-css.html (try to scroll the page) and imho it would be useful for forms too as you described.
    – webvitaly
    Aug 16, 2012 at 21:44
  • how about making the submit button a floating action button so that it is always persistent on the screen? Dec 1, 2022 at 4:21

2 Answers 2


Expanding on my comment, a possibility is to simply use a floating header/footer submit button. This way the submit button is always visible and can easily be accessed regardless of one's position on the form.

This has a potential to be confusing though; it should be clear that you can't just press the submit button whenever (unless you can, of course). Instead you should use some inline validation to show what's missing on the form. A possibility is scrolling to the error on the form when clicking the submit button (since it might not be on screen) but I'd want to test that. Automatically moving the user's scroll position is rarely desired.

Consider the linearity of your form as well; a floating submit button would be best if your form is:

  1. Multiple, scrollable pages in length
  2. Either doesn't have a definite ending point or invites editing multiple parts of the form out of order
  3. Often accessed to edit previously completed forms.

I can see this pattern being especially effective if the form were something like customer information where I might repeatedly need to access and edit an already filled out form. This becomes more like editing a document in Google Documents; Submit is now an easily accessible Save feature more than a final note on a sequential form.

  • Someday I will found the example of such form and I will post the link to that form here :) About "can't just press the submit button" - Submit button could be disabled if not all required inputs are filled and the form is not ready to be submitted.
    – webvitaly
    Aug 16, 2012 at 22:07
  • I liked the fixed header/footer solution in your comment better. Personally I dislike floating content in that I really dislike content that moves as I scroll. It's distractive and intrusive... But hey, maybe it's just my old eyes... :-) Aug 17, 2012 at 9:09
  • @MarjanVenema I'm not sure we're on the same page here. A "fixed" header/footer is the "floating" content I'm talking about...and that's why it moves as you scroll. What difference are you thinking of between the two?
    – Ben Brocka
    Aug 17, 2012 at 11:57

What do you think about to create overlay bottom bar with the context buttons?

Buttons on long form

Update: Just to explain the color scheme behind the screen: Green button is 'Save', red button is 'Cancel', blue button is in this case used to check not assigned entries. This is just concrete implementation of idea to have bottom-bar to eliminate 'scrolling orgies'.

  • Please could you explain the UX rationale behind your suggestion.
    – JohnGB
    Sep 2, 2014 at 0:34
  • UX rationale behind my suggestion of using bottom bar is to eliminate "scrolling orgies". In the typical LOB applications where you are working with the lot of entries, and you change only some of them, you don't need to scroll somewhere to find button to submit. Instead, you have all of the buttons, visible at the same place. The bottom-bar was, in my case, great welcomed UX feature by users. Sep 2, 2014 at 3:41
  • @AntonKalcik Interesting option. I can understand why established users appreciated this change. My concern would be around learn-ability. New users may not realise significant content is below bottom bar. Does UI have any scroll hints?
    – Jason A.
    Sep 2, 2014 at 7:51
  • @Jayfang There is nothing special about scroll hints.Like for any other content in browser you will see scroll-bar on the right side. The bottom-bar is just any navigation bar, but only at bottom and overlays content. Sep 2, 2014 at 10:52

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.