[When] making change to a wiki, [I want to] always see the save changes button, [so I can] easily save my changes without having to find the button.
Problem to solve
When editing wiki pages, the save button is not initially visible without scrolling down. This is inconvenient when making a quick edit and confusing for new users who do not know where the edit button is. Here is a screen shot of the main area of my screen when editing wiki pages (there is nothing below it):
Further details
The save button is obviously the most important (most commonly used) button on wiki-edit pages. The "new page" button is much better visible but much less important in my opinion. (It is rare that I want to create a new page while editing another page, typically I edited one page to add a link, save it, and then create that new page.)
Proposal
I suggest to put the save button in the bottom row next to the commit message and make the commit message bar sticky so as to always be visible. Instead, the "New page" button with the same color could maybe be removed, or be colored white like "Page history".
@jareko another one related to the two wiki editing ones. Personally, I'm inclined to leave the save button at the bottom of the text box as that's consistent with the rest of our editing experiences, but open to discussion here.
I've just almost deleted my wiki page while editing because the delete button is where I expected the save button to be. While I understand consistency, why can't the save button be at the top AND bottom?
@PhilippWendler@phikai What do you think of creating a sticky bottom container with the Save changes button, as well as the commit message input? This allows us to keep our current design paradigm of having the save changes button on the bottom of the form, but also have it be "sticky" so it's always visible.
This also allows us to edit halfway through a potentially long Wiki page and not have to scroll all the way down or up to hit Save.
@jareko that's pretty slick and aligns with what we do with items during the merge request review process. I think my only concern would be that it wasn't immediately clear that the there was text below the box until you scrolled.
Probably relatively small UI thing, but it looks like in MRs that bar extends from the left column and then over the right column.
Pending the input from Phillip I'm supportive of this as a solution. May also make sense to ask @pslaughter and @mishunov to make sure we're not solutioning something we can't do in the older UIs.
I do agree with the problem raised in the description. I totally agree that "New Page" is
an odd button to have when one is editing/creating a page. I also support the idea of having "Save" button visible all the time.
In this regard, the solution from @jareko looks very cool. I like it. I don't think there should be a technical problem with implementing it this way. However, if we strive for consistency I have to question this solution :) I don't think (@jareko might correct me here) we have any other place in the product with a sticky actionable footer. So, technically, we still introduce the new design element. Not a big deal, however, we should keep this in mind and, probably, have it added to the design system.
When it comes to the issue raised by @phikai, this is not the only place where we have an issue of the sticky footer (not actionable, however) overlapping content making it hard to realize there is more under it. Admin Area has the same in the left-hand column: "<< Collapse sidebar" footer doesn't provide a hint of things to go on further below in the column. So, I think if we are about to address the same problem for this Issue, we should keep in mind the same issue in the Admin Area and come up with a solution that could be used for both places. 100%-wide foot doesn't solve this at the moment, unfortunately.
Proposal
What about employing a subtle dropdown shadow to show different "visual layers"?
Before
After
This is a bit more universal solution than the 100% width I think.
However, some issues with this solution:
looks a bit "muddy"
again, I am not sure we have this pattern anywhere, but since we are about to implement the new one anyway, we could consider this option as well.
This is a bit more universal solution than the 100% width I think.
After looking at this existing behavior again, I'm not sure the 100% width of the page makes sense, I would push to change the styling for all instances of this "sticky action bar" to only span the width of the container in which is scrolls. The "Collapse sidebar" sticky button doesn't span the full width of the page, and if that's the convention, on top of this implementation, I would add an issue to update the width of the "Finish review" sticky bar to only span the width of the the container in which it scrolls.
@tauriedavis Do you agree that a sticky action bar should only span the width of the container in which it scrolls, like in my my initial proposal and if so, is this something I can update in Pajamas to create as the convention?
What about employing a subtle dropdown shadow to show different "visual layers"?
That's certainly an option. Another option could be adding an icon that indicates there's more content, but that will inevitably take up more room above the sticky container. We can hide this when starting to scroll down, but hide it thereafter:
@jeldergl Are there other ways we can indicate when there's more content behind/below a sticky container? What do you think the best solution is that doesn't cause accessibility issues?
FWIW, the sticky action footer is one of my least favorite parts of the batch comments feature
It shrinks the file content real estate, which most of the time is my primary focus.
It hides the bottom elements of the file tree because it's missing margin. In other words, global floating things create style coupling.
IMO, New Page, Page History and Delete are strange to see as first class buttons in an Edit view. I think we can easily put Save at the top, if we find a more appropriate place for these buttons. Maybe hide them behind a hamburger?
Also agree that stickiness makes sense in the container it relates to. Top bar is global, so its sticky globally. In this instance, its related to the page content container, so it would be limited to that space.
I do think we should explore other options than stickiness. There are issues out there about making the title sticky for issuables and there is a concern that we are shrinking our content area. This issue could be a good first candidate to introduce the changes we have documented in our design system: https://design.gitlab.com/product-foundations/saving-and-feedback#auto-save
@tauriedavis The Save button for Wiki's is actually a stage + commit + push option for the wiki. Do we have any examples of the auto-save functionality with things that are stored in Git?
Note that the guidelines in Pajamas are new, so they are not implemented in most cases.
However, changing themes in your project preferences is an example of autosaving.
I don't think we have an example of stage + commit + push. It may not be appropriate for that use case, its something to explore more.
@jareko I think @phikai may have a good point and I'm not entirely sure that the git workflow works well with autosaving. Do we want to perform a commit every time the user stops typing and the form is auto saved?
@cdybenko Oops! You mentioned another jarek in gitlab, I'm jareko . Didn't see this until now. I updated the description with the final proposal and link to the original comment with the video showing the behavior.
Lolz sorry @jareko - got make sure I don't miss the "o"! Glad you saw it anyways. This looks good to me! Should we remove you and move it along to planning breakdown or did you want to get feedback from anyone else on our team?
I'm a bit disappointed that there's no resolution to this. How many users have accidentally deleted or almost deleted their wiki pages because they clicked on the wrong button by mistake. Save should be just as prevent as delete, and when one is off screen and the other is on-screen, you might mistake one for the other if you don't look too closely.
Have the "Save changes" button at least on the top, but you could have another one at the bottom too, if it helps somebody.
It is very annoying that when I make often small changes ("Preview" is often not as good), I have to scroll it all the way to the bottom, possibly a long page in a small window.
Moreover, sometimes I'm about to accidentally delete the page, as "Delete" is the "color-suggested" button where one would expect the "Save" button.
A shortcut for "Save", like Ctrl-S or Ctrl-Shift-Alt-S or even some other than S would be the best solution, ideally together with a "Save" button both above and below.