In order to allow for collapsing and expanding the sidebar we add one more row that's anchored to the bottom.
When the sidebar is collapsed its width changes to 48px + 2px border (total 50px). This gives us 16px margin on either side of the icons.
The height of each row is the same as in the expanded state. This way there is minimal vertical movement of the elements in the sidebar.
The avatar in the header must shift a few pixels to the left to be centered in the new width.
Expanded
Collapsed
There must be at least 16px margin between the last navigation row and the collapse button.
Expanded
Collapsed
When there isn't enough space to fit all the rows in the sidebar, the collapse button floats above the others. A top border (#e5e5e5) and a drop shadow (rgba(0,0,0,0.03), 0, -2, 2) are added to the collapse row.
This issue proved to be a little trickier than I was expecting. The proposal may feel a little awkward at first glance, but I think it's the most solid option.
The Expand button (>>) on the collapsed sidebar and the Collapse button (<<) on the open sidebar should sit in the exact same position and have the same dimensions. This is to keep the entry and exit points consistent, which will let users form a strong association on the collapsing feature.
To keep things consistent, the same position and size should be used for the buttons that open and close the sidebar on mobile.
Taking that into consideration, I think the best place for this button is the top-left corner of the sidebar.
Placing the button there means that the header needs to be pushed to the right, and the sidebar as a whole needs to be made a little wider (24px) to make room for everything. Taking up more horizontal space with the sidebar is not ideal, but the total width will be just under 250px, and it's all for the benefit of introducing the collapsed state, so I think it's a fair tradeoff.
Desktop - Expanded
Desktop - Collapsed
Mobile - Collapsed
Mobile - Expanded
Here's a GIF of a simple prototype for the desktop version
Putting the button anywhere else requires that we place it in a different position on desktop and mobile, or that the expand and collapse buttons be in different positions.
For example, if we place the button at the bottom of the screen like we had in GitLab 8.X we can put it in the same position for three of the four screens where we need it. But the hamburger button on mobile needs to be in the breadcrumbs bar, so the entry and exit points for mobile would be different.
For the mockups in my previous comment I highlighted the active element with the same style in the collapsed and expanded sidebars. @pedroms mentioned a few days ago that he thought the active element wasn't noticeable enough with this style on the collapsed sidebar.
I agree it's less noticeable than an active element on the expanded sidebar, but looking at these mockups I actually think the active element has a good contrast with the rest of the elements thanks to the purple border. It would also be good for us to keep the active state consistent for both sidebars.
When we had the original sidebar the button was at the bottom:
It then got moved to the top, so it would be in the same place as the hamburger menu:
The width of the button matches the width of the collapsed sidebar, so if we reduced its width they would no longer match.
If you clicked on the right portion of the 'Expand' button by mistake and wanted to undo your action, you may click again on the same spot, effectively clicking on the sidebar header and navigating away.
We may in the future, actually. It makes sense to collapse the sidebar when resizing the window, so we could add a pin for users who don't want that behavior.
I tried putting the collapse / expand button at the top of the sidebar, but I didn't include the pin so it looked unbalanced and empty. I can give that another try now.
We may in the future, actually. It makes sense to collapse the sidebar when resizing the window, so we could add a pin for users who don't want that behavior.
If we allow users to keep a full width sidebar with a small window width, the main content is going to wrap/break all over the place. We previously only allowed pinning at larger viewports.
@annabeldunstone thanks for clarifying that! I think that's perfect. We have previous experience with this kind of stuff so we should use what we learned from that.
I spoke to @pedroms about this and we reached the conclusion that the best approach is to anchor the collapse button at the bottom of the sidebar. This way we avoid having to push the project header to the right, or having to rearrange the elements when the sidebar expands and collapses.
I updated the issue description with this proposal
On gitlab.com using Firefox 54 with the new navigation enabled, the collapsed side bar does not always show icons as links when hovering. When hovering over an icon with a sub-menu (e.g. Issues) and moving the cursor down to the next item (e.g. Merge Requests), the cursor does not activate the link. It shows as a pointer cursor and the icon is not highlighted. Doing the same motion but upwards seems to work. Also, this does not seem to affect the non-collapsed sidebar.
@iamphill The navigation tunnel fix may need some more fine tuning for when the sidebar is collapsed ☝ Was this fixed in the dynamic MR you made and its just not deployed to prod yet?
@tauriedavis Yeah it should be fixed in the dynamic tunnels. It isn't pick into stable though, not sure if we should or not as its a pretty big change 🤔