[UX] Make form submit buttons "sticky".

[klonos]

This was brought up in #541 by @jenlampton:

We have problems with the location of the submit button in views, too. It's the only UI in core that puts it at the top right, and if your live preview is too wide, that submit button scrolls right off the page (scrolls to the right - where no one can find it). ...Here's an interesting idea, you know how we have a fancy new sticky-footer in the Bartik theme? Why don't we create a similar fancy new sticky-footer for forms where we can stash those submit buttons? The buttons would always be at the bottom left of the viewport, but we can let the page scroll behind.

This could be a handy UI pattern for any form that gets too long.

I recall bringing this issue up in d.org at some point, but I cannot remember where exactly or if it was for core or a contrib module like Module Filter.

Anyways, there is Sticky Edit Actions that does this in a really awesome way:

I think it uses Waypoints' Sticky Elements

---

~PR by @laryn: https://github.com/backdrop/backdrop/pull/2150~ PR by @wesruv: https://github.com/backdrop/backdrop/pull/2237 PR by @jenlampton: https://github.com/backdrop/backdrop/pull/2292

[tjdjours]

With save/preview buttons at the bottom, this is a great option for people who know/remember the form and its options. For those who don't know the form very well, there's a good chance they'll think it ends after the body, at that one screenful.

Maybe if the buttons were up top-right, near the overlay close button and they stuck there?

[docwilmot]

Anyways, there is Sticky Edit Actions that does this in a really awesome way:

Never heard about this. Its going to be a favorite of mine, starting today.

For those who don't know the form very well, there's a good chance they'll think it ends after the body, at that one screenful.

This is a reasonable thought, is there some way to help this? Maybe style the sticky bar similar to the sticky header? Or add javascript text on the sticky bar that says "form continues..bla bla"? Or a drop shadow? Or combination of the above? What do you think, @tjdjours?

[tjdjours]

I'm not so sure. I like the idea of drop shadow and maybe with a bit of an increased margin space beneath? I didn't notice the thin slice of the rest of the form beneath the stuck buttons in the eg illustrated above.

Frankly, it seems odd to me that those buttons still remain at the bottom of form pages by default. It'd make more sense to me if they were placed similar to local tasks/actions - near the header/title and top - given they're more like actions than options.

[klonos]

At some point over the discussion for the WYSIWYG in D8 core initiative I think there was a mockup that moved the form submit buttons on the admin toolbar. This sort of solution would require to have the admin bar visible to all registered and logged in users (items available would depend on access rights of course). In such a solution, we'd need to make the admin bar itself sticky. Not such a bad idea IMO.

[tjdjours]

Also not unlike the option in admin_menu to move local tasks into menu which renders View and Edit.

A lot of my thinking come from considering both responsive web design (RWD) and consistency in click locations, particularly when RWD exacerbates the location complication. Managing two admin bar type menus is silly/tough for small screens. Redundant, too.

My thinking, here, is leave the original buttons as-is and duplicate them into admin bar or something similarly RWD'd or sticky-handled.

To me, making form submit buttons sticky doesn't quite resolve the issue I see as conent-action buttons where you want them when you want them on a form, on any device.

[klonos]

In Drupal, there was a similar discussion on where to place the save buttons: https://www.drupal.org/node/1510550

...you can find some interesting suggestions there like placing them in the content edit sidebar (a thing that we do not have in Backdrop). That issue was just pushed from Drupal 8.0 to 8.1

[quicksketch]

I like to avoid anything "sticky". We disabled the sticky behavior of the admin menu by default (though it can still be turned on), because of it's tendency to break anchor links to the middle of the page. Combined with sticky table headers and you have additional problems (though they do actually work together). If we add a sticky footer in addition to sticky header functionality, we're potentially causing problems on small-screen devices. Imagine having a sticky admin menu + sticky footer + having the keyboard drawer open, hardly any space remains for the page content itself.

[jenlampton]

The top-right is also problematic, because if you get anything with a scroll bar and the buttons disappear entirely (people don't ever think to scroll to the right).

This was a major UX fail when we did usability testing on views module.

[laryn]

I just found this thread – I have actually been testing a sticky edit button in a subtheme of seven, just using CSS and not on mobile (via media query targeting). Something like:

#edit-actions {
  position: fixed;
  bottom: 0;
  z-index: 25;
  margin: 0;
  padding: 1rem .25rem 1rem 0;
  background-color: rgba(240,240,240,.8);
  border-radius: 5px 5px 0 0;
  box-shadow: 0 0 4px #000;
}

[jenlampton]

If we add a sticky footer in addition to sticky header functionality, we're potentially causing problems on small-screen devices.

@quicksketch what if we didn't have the sticky buttons on small screen devices, started only at ~768px. It sounds like @laryn is doing that, is it working? :)

This could be something we attach to form #actions, so all config forms could get it by default!

[laryn]

Yes, it's working fine in early testing. I'm sure it will need some tweaks but I'm liking it a lot so far. Using #edit-actions it works on Layouts, Views, Vocabularies, and Nodes. (Not on Terms so tweaking as you describe could be beneficial). The only strange thing is on really short pages it is still fixed to the bottom. Maybe there's a way to adjust that, I haven't gotten that far yet. :)

[opi]

Not on Terms

Terms/Taxonomy should use 'actions' too ; @laryn Could you tell us on which page your sticky buttons doesn't work ?

[laryn]

@opi For some reason editing a Tag term the buttons show up with #edit-actions--2. However if it's not casting the net too wide, using the .form-actions class (instead of the ID) might do the trick.

EDIT: And something to disable it on modals (e.g. editing a custom block in a layout)

Current version (SASS) I'm testing

.form-actions {
    position: fixed;
    bottom: 0;
    z-index: 25;
    margin: 0;
    padding: 1rem .25rem 1rem 0;
    background-color: rgba(240,240,240,.8);
    border-radius: 5px 5px 0 0;
    box-shadow: 0 0 4px #000;
    input {
      margin: 0 .25rem;
    }
    a#edit-cancel {
      padding: 0 1rem;
    }
  }
 .ui-dialog {
    .form-actions {
      position: inherit;
      bottom: inherit;
      background-color: inherit;
      box-shadow: none;
    }
  }

[opi]

@opi For some reason editing a Tag term the buttons show up with #edit-actions--2. However if it's not casting the net too wide, using the .form-actions class (instead of the ID) might do the trick.

because the redirect part of the form already have an "actions" container... So using ID is not a good idea. We might targeting the main "actions" of the form, so what about form > div > .form-actions ?

[opi]

FYI, here is what I use on some Drupal 7 with adminimal admin theme

/** ****************************************************************************
 * STICKY ACTIONS
 * Stolen from adminimal sticky actions
 **************************************************************************** */

#page {
  margin-bottom: 60px;
}
.node-form > div > .form-actions.form-wrapper {
  position: fixed;
  bottom: 0;
  background: #fff;
  border-top: 1px solid #CCCCCC;
  width: 100%;
  left: 0;
  padding: 20px 40px 8px;
  margin: 0;
  z-index: 999;
  padding: 10px 40px;
  box-shadow: -20px 2px 20px rgba(0,0,0,0.4);
  input.form-submit {
    margin-bottom: 0 !important;
  }
}

[laryn]

Thanks @opi! I tweaked that slightly and it seems to work very nicely (in my subtheme of seven at any rate) as follows, with no conflict on the modal editing of blocks on the layout page:

  .page {
    margin-bottom: 60px;
  }
  .l-content > form > div > .form-actions, 
  .l-content > form > div > #layout-edit > .form-actions,
  .l-content > .views-admin > form > div > .form-actions {
    position: fixed;
    bottom: 0;
    background: #fff;
    border-top: 1px solid #CCCCCC;
    width: 100%;
    left: 0;
    padding: 20px 40px 8px;
    margin: 0;
    z-index: 999;
    padding: 10px 40px;
    box-shadow: -20px 2px 20px rgba(0,0,0,0.4);
    input.form-submit {
      margin-bottom: 0 !important;
    }
  }  

(Screenshot below is creating a node; "Save Draft" module is in use so buttons looks different than stock). I've also done successful basic testing on:

• Create/edit a node
• Create/edit a taxonomy term
• Create/configure a taxonomy vocab
• Create/edit a view
• Create/edit a content type
• Add a user account
• List modules
• Add Layout
• Add Menu
• Configuration (e.g. Site Information)

[laryn]

After playing with this for a while I really like it and have popped it into a PR so others can test in the sandbox.

[olafgrabienski]

Looks nice! I found issues related to padding though:

There are two padding definitions:

padding: 20px 40px 8px;
(...)
padding: 10px 40px;

I'd take the last-mentioned definition but would remove padding-bottom:

padding: 10px 40px 0;

Without the removal the bottom of the vertical tabs is always overlapped by the sticky element, which is confusing, imho.

[olafgrabienski]

Hera are two screenshots for comparison.

With padding-bottom the bottom of the vertical tabs is overlapped by the sticky area. That is confusing because it looks like there could be more tabs: Without padding bottom the bottom of the vertical tabs remains visible:

[laryn]

Good catch, @olafgrabienski, thanks! I've updated the PR and tried to reboot the sandbox.

[olafgrabienski]

The sandbox works fine and the change looks good, @laryn ! Not sure though if the margin between vertical tabs bottom and the sticky element is still a bit small. I haven't been aware that we can also add more margin than 60px to .page, for instance:

@media (min-width: 768px) {
  .page {
    margin-bottom: 80px;
  }
}

[klonos]

I'm really excited that we have got this going!! 😄

Everything works great on tablet (both portrait and landscape), and I see why we should not be using this on mobile. It does look a bit weird to have the submit buttons on the far-left on supper-wide screens though:

...so perhaps restrict the width of the sticky footer .form-actions div to the same width as the .container.container-fluid div?

[docwilmot]

Should we offer an option to turn this off, in case it interferes with custom themes or layouts? Its only in Seven in this PR; what if a person want to change their admin theme? I suppose its reasonable to expect that we only support this in Seven though. And also we should modify the actions div to add a container class. And is there any chance of having more than one actions div on one page, say from a contrib module?

[laryn]

Just updated the PR although I didn't use the container class since the actions div can come from a variety of places (so I rather used a max-width for wide screens). Comments welcome.

@docwilmot's questions stand.

[olafgrabienski]

Nice idea to add a border-top, was however wondering about the color #CFDE56 which seems strange to me at this place. What about a (lighter) variation of #0074bd for instance?

^ Wow, the editors shows the colors when I type them as code (using backticks)!

[docwilmot]

Adding milestone, since this is a good idea, and would work well with https://github.com/backdrop/backdrop-issues/issues/3062

[klonos]

New PR by @wesruv for anyone that is interested to test: https://github.com/backdrop/backdrop/pull/2237

As mentioned during today's meetings, we need to test this on mobile; especially iOS/Safari, and also make sure that it still looks and works as expected when using pinch-n-zoom.

[klonos]

My review feedback so far:

1. The current implementation does not make the submit buttons sticky if the screen is very short (e.g. phone landscape). This was intentional, with the reason behind it being that this would reduce the screen real estate to a point where you'd barely have enough room to edit anything.

   I personally found it annoying to not have the sticky buttons available there too (but that is my opinion), so I have messed with @wesruv's PR on my local. Here's the a screen capture when working of a node edit form, on iPhone 6/7/8 landscape:

   

   ...and with the admin menu sticky too:

   

   As I said, it is not bad at all IMO ...especially if one considers how much scrolling it saves to have the submit buttons be sticky.

2. I really liked how the "dirty form" message is animated into view, just above the sticky buttons ribbon in the Views UI:

   

   ...which would solve these old UX issues: #789 #1656

3. The only thing that I found to be a weird UX was that the form had no submit buttons to begin with when it initially loaded (I was about to report this as a bug). The submit buttons ribbon did come up when I edited one of the view settings, but I would still prefer it if the buttons ribbon was always visible, and only the "dirty form" message was animated.

4. Also, if we are to make this a pattern (I think we should), then we should ensure that the "dirty form" message works the same everywhere we are using it. The "Manage blocks" pages is one such place where this does not work with the current PR. Elsewhere?

5. @laryn's implementation had a shadow at the top of the ribbon, which gave things a bit more "depth", otherwise there might be cases where people might be missing that there is more if they scroll further down. I have tried some variations on my local. Here's one that uses a very subtle shadow:

   

   ...and another that applies transparency to the submit buttons ribbon:

   

   ...I don not particularly like any of them, but the point is to coney a "there is more if you scroll" message as best as possible. The plain border does not achieve that IMO. Other ideas?

6. On mobile, landscape mode, with Save Draft enabled (which adds another submit button in the content create/edit forms), the "Cancel" link gets wrapped into a second line, and it looks as it could use some bottom padding:

   

   ...If it wasn't for #1383, I would not have mentioned this at all, because we cannot possibly be accounting for every contrib module out there; nor making an exception for save_draft specifically. But it look like we are aiming for most of the functionality of save_draft to get into core, so this will become an issue then.

[klonos]

Other ideas?

...by @wesruv on our Gitter channel:

there might be a better solution than just adding the shadow though

I think this might be a good middle ground? it's not fuzzy, but maybe still does a better job than a regular border?

[laryn]

Thanks for the in-depth reporting @klonos. I took a quick spin and will add that there are no sticky buttons on some config pages such as the ones below (it's not an exhaustive list)

• http://2237.backdrop.backdrop.qa.backdropcms.org/admin/config/content/formats/filtered_html
• http://2237.backdrop.backdrop.qa.backdropcms.org/admin/config/system/site-information
• http://2237.backdrop.backdrop.qa.backdropcms.org/admin/structure/types/add

[jenlampton]

@klonos wow, thanks for the super-in-depth review. Very helpful :)

1) your mobile examples look good for iPhones, but I'm worried about making an assumption that all phones are as large. Let's start with what we have and reduce down lower in a follow-up (if necessary).

2) I like the dirty form message there too, and the animation!

3) This is a separate issue - views forms not having submit buttons until changes have been made.

4) Love the idea of applying this to layouts as well, but let's do so in a follow-up issue.

5) I think I prefer the shadow to the funny transparent border. Anyone else have thoughts?

@laryn We may need to add some follow-up issues to make sure all admin forms use #actions (which will make the buttons sticky).

[jenlampton]

I looked at the PR and didn't like having to specify all the forms individually in the CSS, so instead I've gone through and and added a class to each form/type that we want the sticky buttons on... I've also tried with a box-shadow instead of a transparent border: https://github.com/backdrop/backdrop/pull/2292

I'd love to get some feedback from everyone on whether we think this is an overall improvement? I do, but have heard some concerns. Should we hear those out?

[quicksketch]

We don't have the time to adequately test this rather wide-reaching UI change, so I'm moving this to the next release.

[jenlampton]

We haven't gotten any additional feedback in the entire 1.11 cycle, so I'm guessing this feature isn't high priority for everyone. Removing milestone.

[laryn]

I'm still using a version of this on most of my sites and I find it a great improvement from a site admin perspective.

[stpaultim]

NOTE: The sandbox isn't working and needs a refresh.

[klonos]

(let me know if what follows belongs to the issue summary, or even moved to a separate issue altogether)

The https://www.drupal.org/project/gin theme moves the submit buttons to the top-right of the page, and makes them sticky. Here's a screenshot where I've intentionally made the browser window short enough to allow scrolling, and have scrolled down, past the title field of the node edit form:

On narrower screens and on mobile, the sticky bar does not include the page title, and is moved to the bottom of the page:

[olafgrabienski]

let me know if what follows belongs to the issue summary, or even moved to a separate issue altogether

This issue could however need a revival. There wasn't enough feedback since https://github.com/backdrop/backdrop-issues/issues/566#issuecomment-418035109. In my opinion we should restart at that point and maybe then take the Gin approach into consideration.

[stpaultim]

I'd like to offer feedback on this, but the sandbox isn't working. Atten: @jenlampton

[jenlampton]

Rebased the PR, and generated a new sandbox.

[klonos]

Thanks @jenlampton 🙂 ...I've re-tested and the behavior and look/feel are a big improvement compared to what we currently have 👍 - I've left a couple of comments/questions in the PR re formatting (coding standards).

For those who don't know the form very well, there's a good chance they'll think it ends after the body, at that one screenful.

We have previously discussed adding some opacity to the background of the div that holds the submit buttons? Here's how it would look with 80% (rgba(255, 255, 255, 0.8)):

How does everyone feel about something like that?

Then, another idea is to reduce the div from being full width to only enough width to hold the submit buttons. This is basically what @laryn mocked up back in April 2018, as well as what's shown in one of the mockups in the issue summary in https://www.drupal.org/node/1510550 :

Here's what it'd look like with some additional shadow, and the buttons directly "attached" to the left of the screen:

...or with some added margin to the left:

[findlabnet]

How it should look, if javascript is not enabled?

[jenlampton]

@findlabnet I don't think that's a real concern anymore, but I'd recommend that it look exactly the way it looks now w/o js :)

I personally prefer the buttons on the bottom of the screen, full-width, with a shadow, on a white bg with no transparency, similar to the screenshot in laryn's comment

[findlabnet]

I personally prefer to avoid the "sticky footer", especially where action buttons are separated (isolated) from their native forms, but maybe that's just me. BTW, I use one such approach implemented in Adminer ;-)

[laryn]

I really like how this is coming along!

I did notice in the sandbox that there are a number of forms that don't pick it up because the current PR requires a sticky-enabled class which hasn't been added to them yet (e.g. add user, edit user, manage a file, add/edit content type, manage fields, and there may be more).

I looked at the PR and didn't like having to specify all the forms individually in the CSS, so instead I've gone through and and added a class to each form/type that we want the sticky buttons on.

The downside to this approach is that it lays the burden on contrib to also do the same, which would lead to inconsistent admin interface (in my opinion). I'd prefer to specify something in the CSS that applies to all the core forms we want, but also to contrib forms that use $form['actions']['#type'] = 'actions';.

[jenlampton]

I like the approach of adding a single class everywhere, but would prefer it was added automatically to something like the action div in system_settings_form() so contrib wouldn't need to do anything special to have it enabled.

This also would also open up the opportunity to have a setting control the class, so of you didn't like the sticky submit buttons, you could disable it site-wide.

I'm not sure where a setting like that might live, but I find the idea attractive.

On Fri, Jul 24, 2020, 5:40 AM Laryn - CEDC.org notifications@github.com wrote:

I really like how this is coming along!

I did notice in the sandbox that there are a number of forms that don't pick it up because the current PR requires a sticky-enabled class which hasn't been added to them yet (e.g. add user, edit user, manage a file, and there may be more).

I looked at the PR and didn't like having to specify all the forms individually in the CSS, so instead I've gone through and and added a class to each form/type that we want the sticky buttons on.

The downside to this approach is that it lays the burden on contrib to also do the same, which would lead to inconsistent admin interface (in my opinion). I'd prefer to specify something in the CSS that applies to all the core forms we want, but also to contrib forms that use $form['actions']['#type'] = 'actions';.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/backdrop/backdrop-issues/issues/566#issuecomment-663518756, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADBER45POTX4V77TJGDW4LR5F6NFANCNFSM4A2BY5JA .

[laryn]

That sounds great.

Many contrib modules end up in a Configuration > User interface submenu but I don't think we have anything there in core presently.

Or maybe since it's really an admin-only feature, it could be under a new form at Configuration > Administration > Admin interface?

[jenlampton]

We have the placeholder for user interface in core, but nothing in that section.

On Fri, Jul 24, 2020, 10:11 AM Laryn - CEDC.org notifications@github.com wrote:

That sounds great.

Many contrib modules end up in a Configuration > User Interface submenu but I don't think we have anything there in core presently.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/backdrop/backdrop-issues/issues/566#issuecomment-663641000, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADBER2EUWLP7SMYTC3OUGLR5G6DJANCNFSM4A2BY5JA .

[findlabnet]

...so of you didn't like the sticky submit buttons, you could disable it site-wide

Like disabling overlay in D7 - great opportunity.

[klonos]

How it should look, if javascript is not enabled?

@findlabnet I meant to reply a couple of days ago re js: the PR does not touch any .js files - only CSS changes were required to get the desired effect. I've actually tested this in the PR sandbox, and the node edit form for example loads without the admin bar, CKEditor, the vertical tabs, and other things that require javascript, but the sticky form submit buttons ribbon is still there and works as expected.

@jenlampton I also noticed that the toggle for this is a class added to the form (I've left a comment in the PR re the class name btw) and I am of different minds re which should be the default ...the consistency freak in me thinks that we should implement this globally, for all forms (still not on mobile devices, where the screen estate is an issue) ...the UX freak in me on the other hand thinks that having the sticky submit ribbon in shorter forms would make for a worse UX (more distance for the mouse to travel to get to the submit buttons) ...the DX freak in me thinks that we should implement this so that it detects whether the page is long enough to have a scrollbar, and then automatically places the submit buttons in the sticky ribbon, or at the end of the form as per usual (so that we don't have to turn this on via the form class individually for each form).

As for the last bit, I did some research and there seems to be no way to detect page height or the existence of vertical scrollbars with pure CSS and no JS 🤔 😞