With the recent proposal of including a sidebar in Drupal core we now have an actual area where buttons could be placed in alternative to the bottom. In the discussion at Content creation redesign we noticed that many people would like to see the “Save” button at various places in the Drupal interface. We concluded for #1510532: [META] Implement the new create content page design, that there is no consensus yet on where they should be placed.

We would like to continue the discussion here, below are a few directions that where proposed in the threads:

buttonsinsidebar.jpg
buttonsinbarontop.jpg
buttonattachedtobottom.png

There are a lot of things to be taking into consideration when we are making a major pattern change like this one. From how its handled from an accessibility perspective, to how it should work on mobile.

My personal concerns are mostly about how applicable it is across core (e.g. does it make sense for configuration screens, to have save buttons elsewhere than the bottom), what kind of user behavior do we want to support (like Joomla, where all buttons are in the top right), how flexible is the pattern to handle specific contrib use cases (very horizontal interfaces like Views, Rules, Page Manager, etc).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Bojhan’s picture

Issue summary: View changes

fixin images

bleen’s picture

We have a site where we have moved our buttons from the bottom of the form to the top, and one UX issue we have noticed with our less-than-technical users is that if an error occurs (lets say they left a required field blank at the bottom of the form) then there is great confusion. Having the buttons at the bottom forces the user to scroll down and eventually see the red-hilited field and thus resolving the confusion.

That said, I dont think this UX issue should prevent us from moving the Publish/Preview buttons, but I wanted to throw it out there

pfrenssen’s picture

It is more conventional to have them at the bottom, but I must say that I really like the mockups where they both at the bottom and at the top right (like this one). This workflow is also used in Open Atrium, and it works really nice: when you are creating new content you can follow the top-down approach and submit at the bottom, and when editing existing content you typically submit at the top right because that is in plain view and saves quite a bit of scrolling.

This idea also works well with the latest design iterations since all the related information (publishing status etc) is also shown in the top right.

I have seen sites that solve the problem of form errors being "below the fold" is solved by scrolling to the first invalid form element. For this to work well the error messages should be shown near the form elements, but that is another issue altogether :)

I'm not such a big fan of showing the submit buttons in a transparant overlay such as in the second and third mockups, in my mind this is decoupled from the actual form (it seems to sit on another "level"), so this is not intuitive. The submit buttons should sit on the same level as the form.

alex.skrypnyk’s picture

Issue tags: +preview, +save button, +place

I've also placed buttons in bottom-only OR right-only OR both on my D6 and D7 sites, but it usually confused users: the ones that firstly saw buttons in the bottom always scrolled to the bottom, despite having buttons on the right at the top; the ones who got used to the buttons on the right would usually scroll to the bottom to check that content is correct and then would go back (!) to the top right to save the content.

So, IMHO, the idea of buttons in the semi-transparent sticky panel is great, but I would put them at the bottom of window.
They would be always visible and accessible when any field is filled-in and also on validation error with long forms (you would not have to fix-scroll-save -- just fix and save).

Also, placing panel at the bottom would avoid the confusion with top admin bar.

drclaw’s picture

I agree about your concern about how applicable it is across core. Most of the discussions I have read have been specifically about the content add/edit page, but if we expand the discussion to include all core forms (or all forms core and contrib...?) there will be a lot to consider. My first instinct is to say that there should be an option when creating the form (maybe in Forms API) that lets you choose where you want the buttons... but i feel as though that could cause some confusion as module developers start mix and matching...

I will say, however, that I've been using an administration theme with the Buttons on the top and the bottom of the content form for a while now and never get any usability complaints. This is from a relatively wide range of users (veteran CMS users, to Wordpress users to non-technical users.)

I think that having the buttons in the Toolbar is a bad Idea... but I've thought about floating them at the bottom before. Sort of like sticky table headers where they just stick to the bottom of the screen until you get to where they should be and the re-attach to their designated position. I'm still undecided on the issue, but could probably be swayed either way. =P

Jon Betts’s picture

I agree with #2 concerning the placement of buttons in the bottom as well as the top and for the use cases presented. There are many times when I just want to make a quick change to a title on a very long form and it is pretty tedious to have to scroll to the bottom. With vertical tabs on the bottom of the form, it makes more sense to only have Save/Publish buttons on the bottom of the form, but with the functionality in the vertical tabs now in a sidebar, I see more frequent edits occurring "above the fold". And so a set of buttons in the top right side bar would be very much welcome.

Sorry for long-winded +1.

Regarding error messages, perhaps we could just provide the error messages at the top with links to the problem fields. That way editors could just click on the error message and go right to the problem field.

ry5n’s picture

Seems like lots of us like the idea of the save buttons always being in-view. It would be a nice usability win, but I really don't like having them in there twice (simplicity? parsimony?). I also think the option of having them persist in one place has been sold short by the mockup with the transparent overlay. I've attached a quick sketch that hopefully clarifies how I can see it working here.

Sketch of d8 content creation sticky header

Mechanically, it's identical to the way the secondary nav works on the Twitter Bootstrap marketing pages, so you can head over there to see how this feels in practice. What do you think?

[edit for broken markdown link]

ryan.armstrong’s picture

This is a repost of a comment I made in the #1510532: [META] Implement the new create content page design issue and at r@y5n's request have posted it here.

I wanted to throw out a quick idea. In some of the comps, we had the save/preview/delete buttons in the right sidebar at the top. I think it's a good idea to keep that there and add in some sticky functionality where it it is situated within the overlay but as the page scrolls up and it touches the top of the browser window, it "locks" to it and stays there until the user scrolls back up past it's original position within the overlay.

This would be similar to how the sticky tables work in Drupal. One thing that gets very annoying when editing content types either on a small screen, or with a lot of fields is constantly scrolling all the way down the page to hit save or preview. This would address that, as the actionable items would always be in the same position, upper right of the overlay (or page if overlay is disabled). Thoughts?

ryan.armstrong’s picture

FileSize
282.46 KB

I've added a terribly drawn mockup to illustrate my idea.

Mockup

ry5n’s picture

The more I consider this, the more I’m inclined to think that this layout is the better option compared to mine. For instance, @yoroy already explored the idea of a horizontal layout for the publish actions in the design iteration phase and discarded it for a variety of reasons (readability, scalability). My initial concern with having a stacked set of sticky actions was that it would take up too much vertical space on narrow screens (netbook/horizontal tablet). That could make the usuable area for the rest of the sidebar uncomfortably short. There are a number of possible solutions: only publish, save and maybe preview are sticky, and modules are not allowed to add sticky controls. Another option is to only enable stickiness on taller displays (min-height media query).

Ultimately the best way to tell is to build a browser prototype and test. I'd be open to working on that.

ryan.armstrong’s picture

I'd be able to work up a prototype this weekend of my idea. I'll post it here when it's done. In response to the vertical issue, I think that only allowing the publish/save/delete bit be sticky would be the best idea. I don't think there is a big need for allowing the others be sticky seeing as they don't contain any "final actions." ie actions that end the editing or creation process.

ry5n’s picture

I agree on the solution to the vertical space. RE: building a prototype, sounds good! Let me know if you want me to help out.

omaster’s picture

I think the most important thing is that they are always visible on the page and consistant with all the other button placements for all the other pages. This being said everyone will never agree so this is where it should be come custom chosen by people. So instead of saying to all it will be top right or at bottom all the time allow people to choose a placement but have a default selection. While I realise this is a little extra work

I have done up a patch that would demonstrate having the buttons at the bottom of the page. it is by no means a complete solution and should be done a lot better but it demonstrates bottom of the page permanant buttons. It can be found here. http://drupal.org/node/752482

It fits into the style with the top menus in the new Drupal 8 system.

I like the idea of these buttons being at the bottom myself because it seperates the menu structure from the perform an action functions and really buttons are normally already found at the bottom. It also means the buttons are always avaliable which is the biggest peeve on a really long page.

pfrenssen’s picture

Issue tags: -preview, -save button, -place

Removed nonsensical tags which are not used in any other issues.

pfrenssen’s picture

Issue summary: View changes

some enters

LewisNyman’s picture

Issue tags: +frontend, +CSS, +Usability
Bojhan’s picture

Version: 8.0.x-dev » 8.1.x-dev

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.