Move section navigation bar to the left and (always, mostly) display

[ronaldtse]

For example, on this page, the user doesn't know where to find the rest of the content:

The user needs to click on the "..." on top to open the menu, and it is not intuitive.

Moreover, having navigation on the right is not intuitive for LTR languages since most navigations are on the left (including the one in Metanorma document.

What do you think @strogonoff ?

[strogonoff]

Sidebar position is by design, same is done on ReactJS and many other sites. Left-to-right, start in order of importance (content first). We can open the sidebar initially, that’s something I’m open to, though it was also a conscious decision. @ronaldtse you tend to see most of my deliberate design decisions a bugs, as I observe🤔

[strogonoff]

Actually, I don’t see that I can do much on this issue in good faith.

1. I checked and the sidebar is indeed open initially, unless viewport is narrower than 900px. In that case there’s a risk of overlapping content. This, again, is a conscious design choice, to have navigation “overshadow” content when both don’t fit. Thus, on narrow viewports the sidebar is collapsed by default. (900px is also the breakpoint below which we start hiding top navigation items behind a hamburger menu.)

2. I placed the sidebar on the right in accordance with LTR parsing order (main content first).

We could change the breakpoint so that sidebar is open by default on screens as narrow as e.g. 800px, but IMO 900px is small enough by today’s standards.

[strogonoff]

(Added and reverted the commit opening sidebar by default on all viewport widths)

[ronaldtse]

I checked and the sidebar is indeed open initially, unless viewport is narrower than 900px. In that case there’s a risk of overlapping content. This, again, is a conscious design choice, to have navigation “overshadow” content when both don’t fit. Thus, on narrow viewports the sidebar is collapsed by default. (900px is also the breakpoint below which we start hiding top navigation items behind a hamburger menu.)

Hmmm... 900px seems too wide -- I'm using a 15" MacBook Pro, and when I open Metanorma, I often do not see the bar.

If I open 900px and then shrink, the sidebar still stays. Perhaps that indicates we can use a smaller width.

At least, the "..." icon doesn't work. It must occupy vertical space for people to know that extra content exists?

2. I placed the sidebar on the right in accordance with LTR parsing order (main content first).

The table of contents should always be first (i.e. Left). The main content of that page comes later. People often want to jump to another page rather than read the "main content".

[strogonoff]

Hmmm... 900px seems too wide -- I'm using a 15" MacBook Pro, and when I open Metanorma, I often do not see the bar.

Fair point, agreed to try changing the breakpoint to 800px. I’m using same hardware though and haven’t had this issue.

If I open 900px and then shrink, the sidebar still stays. Perhaps that indicates we can use a smaller width.

Sidebar state won’t be toggled by window resize.

At least, the "..." icon doesn't work. It must occupy vertical space for people to know that extra content exists?

Not sure I get that point.

The table of contents should always be first (i.e. Left). The main content of that page comes later.

I weighed both options when originally designing the navigation, and made my design decision based on first principles and examples of subjectively well-designed and objectively successful documentation from other OSS products (e.g., React, Django).

I’m not responsible for the design of Metanorma documents, but for its documentation site. If the premise is to match documentation sidebar position to the one in Metanorma documents, we can do that though I am not sure why that would be important.

[strogonoff]

(Changed the breakpoint to around 800px, updated Metanorma to the new version)

[strogonoff]

In latest version of OP theme (which Metanorma.com was updated to) also ensured that ToC toggle button shows on software documentation pages, as it should by design:

I also made this button (alongside with “suggest edits” button) appear on project-wide documentation pages, not just software docs.

In medium term I’m looking into updating navigation with following goals in mind

• Combine two collapsible menus (top menu and docs navigation) in one to simplify UX
• Make docs navigation more elegant overall and consistent across software & project-wide docs
• Fix the issue where long anchor titles in in-page ToC would cause menu to overflow viewport, if viewport is narrow

(If it remains in sidebar shape, I might move it to the left as well, at least as an experiment)

[strogonoff]

Planning to do this for all project sites, as part of riboseinc/jekyll-theme-open-project#72 (upstream theme issue).