[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

[klonos]

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

A great place for the setting for #4478 as per the discussion during the dev meeting 😉

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

I believe that most (all?) UI tasks refer to the admin interface. I'm trying hard to think of one that doesn't ATM.

[jenlampton]

Content entry is not an administrator task, and this would be most valuable on the node form.

I don't like having per form configuration, I think it needs to be a global yes/no. Anything else can be left to contrib.

Wasn't there one example above of the buttons being at the bottom of the form unless the form was longer than the page? I suspect they could do that based on scroll, just like we do sticky table headers. We might need JS for that, but I don't see a downside to including it.

On Fri, Jul 24, 2020, 3:04 PM Gregory Netsas notifications@github.com wrote:

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

A great place for the setting for #4478 https://github.com/backdrop/backdrop-issues/issues/4478 as per the discussion during the dev meeting 😉

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

I believe that most (all?) UI tasks refer to the admin interface. I'm trying hard to think of one that doesn't ATM.

— 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-663752408, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADBER34NMZP2OL7OJSSHW3R5IAPFANCNFSM4A2BY5JA .

[klonos]

Content entry is not an administrator task, and this would be most valuable on the node form.

Touché 😅

I don't like having per form configuration, I think it needs to be a global yes/no. Anything else can be left to contrib.

Yes! ...but if this is to be a global setting, it needs to be for both non-admin tasks (such as the content editing form) as well as admin tasks (editing content types, menu items, and pretty much any other form - perhaps exclude the login, register and password reset forms). So I think that we should use the existing "placeholder" Configuration > User interface.

I suspect they could do that based on scroll, just like we do sticky table headers. We might need JS for that, but I don't see a downside to including it.

Yes, we'd need JS. ...no downside other than that we'd need a fallback for people that have their JS disabled. ...each time I disable JS for testing purposes, the UX is degraded (no admin menu, no CKEditor etc.); so I'd be interested to know how many people do disable JS after all 🤔

[jenlampton]

I think that we should use the existing "placeholder" Configuration > User interface.

The placeholder is only a parent menu item. We'd need to add a child page like Configuration > User interface > Forms. That's a really bad example, let's not use forms, but we will need to think of a name and URL for the settings page.

[jenlampton]

each time I disable JS for testing purposes, the UX is degraded (no admin menu, no CKEditor etc.); so I'd be interested to know how many people do disable JS after all 🤔

@quicksketch looked at stats on that and IIRC it was less than 1%

[klonos]

The placeholder is only a parent menu item. We'd need to add a child page like Configuration > User interface > Forms. ...

Right! Since this will only be a checkbox/toggle for now, can't we just use something generic, like Configuration > User interface > Settings? I would like to stick the setting for the partial path matching for #4478 in there if OK.

[philsward]

+1 for this

Some thoughts:

1) move core related functions / actions / settings to a permanently visible side bar. Kind of like how WP does it, but more specific to the page being viewed.

• Top bar for site admin stuff
• Side bar for page admin stuff.

This would probably be easier as a future idea when the frontend is more JS framworky.

2) Given the current discussion, I think I prefer the buttons at the bottom more than the top. It's a natural workflow that you start at the top, finish at the bottom. I tend to overlook buttons like this at the top of the page because a) that's relatively new UI b) it doesn't follow the natural start/finish workflow. Possibly make this configurable or rely on a contrib to move it?

3) try playing around with making the background color a dark color or distinguishable color that effectively says: "any time you see this bar, it's where you do an action"

---

Overall, I like where the discussion is going. It's one of those things that I think most people would highly appreciate, but it isn't at the top of the "UX problems list" to complain about hence the seemingly low enthusiasm.

[laryn]

@philsward RE: your first point, it's slightly different but you may be interested in this one: https://github.com/backdrop/backdrop-issues/issues/3072

[klonos]

Thought that it'd be worth mentioning here that the Gin admin theme, which seems to be trending in Drupal-land, has implemented this in a very nice way, placing the buttons in the top-right corner of the page:

The entire ribbon at the top that holds the page title and the submit buttons is sticky, and subtly semi-transparent towards its lower end as you scroll down:

The reason that I'm mentioning that the Gin theme is trending is not just for the sake of that fact itself - it means that people coming from Drupal will be most likely accustomed to seeing/using it (content editors may have not chosen it themsleves, but the people that have set up the sites they are using will have - similarly to the Adminimal theme I guess), and will inevitably be comparing the UX with that in mind. Also, Gin is an additional layer on top of the core Claro theme - Claro does most of the "heavy lifting", and the community has poured a lot of time and effort to make that theme accessible and to address heaps of UX issues according to years of feedback. Not sure if any actual user studies have been done for Claro/Gin, but I'm assuming that since our Drupal brethren have more resources, then that must be the case - even if not, the large user base certainly provides for a decent "playing ground" for things that people can test and provide feedback for, which in turn means that things improve over time. My point is that it seems to me a good source of inspiration - not just a "trendy" thing.