We are re-writing the toolbar using LitElement, and should take the chance to address a number of long-standing issues and refinements. Here I will make a discussion post for proposals.
Each proposal links to the appropriate Github issue; if they differ, Github is the authoritative version.
As the toolbar and sidebar interact, some of the discussion affects the sidebar, too.
- Items end with an action point that looks like this!
Background
The toolbar implements a common Material Design pattern using the Polymer elements as a basis. In development we encountered a number of areas where the stock implementation was not ideal for us, and the current version, while serviceable, retains some bugs and compromises made along the way.
We should endeavor to eliminate these issues, and at the same time, take advantage of the more powerful LitElement approach to ensure the element is light and performant. As too what elements are used, or whether we just write our own, this is a decision for the developer. But we should always bear in mind that it is better to spend time doing it the right way, ensuring a clean, valid, readable code base with as few dependencies as possible.
There is a new component library that may be of interest:
Behavior
The behavior of the elements when responding to different screen widths has always been somewhat erratic, and while many of these issues are fixed, it is not perfect.
Obey the user
As a general rule, avoid second-guessing the user. Unless its really necessary, don’t do anything that the user does not explicitly ask for.
I would very much like the sidebar to only extend or retract on explicit request by the user. It should be closed by default at all screen widths, and only open or close when the user tells it to.
The only exception to this is on narrow screens, where it is essential that the sidebar close in order to read the content. Thus once clicking something on the sidebar, it should retract (as it does currently).
To sum up:
- Sidebar should be always retracted by default.
- It is only opened by explicit user request (either clicking the hamburger menu or swiping the screen from the left).
- On wider screens, it is only closed by user request.
- On narrow screen, it closes automatically when an item is clicked.
Be smooooth
The animations of the toolbar and sidebar must be carefully tested to ensure a nice, buttery smoothness. I still find that animations on the web are often janky, and SC sometimes suffers from this. The best solution for this is to use the FLIP technique:
Note that we should ensure we do not use neon-animations, it is deprecated. We should instead use the Web Animations API:
- Ensure animations are smooth, use Web Animations API and FLIP.
Heal the sliced toolbar
The static pages use a so-called “prominent” version of the toolbar, with extra height, and including the SC title and logo. When you scroll down, the prominent toolbar disappears and is replaced by a “standard” toolbar, as found elsewhere on SC.
If you open up the Home page and scroll down, you’ll see that the toolbar slices into two separate layers as it contracts. There’s an unwanted shadow that meaninglessly divides the area. This sometimes creates unfortunate effects.
This is in fact just a leftover from the initial mockup, it was never meant to be like this. We just always had bigger priorities and never got around to fixing it.
The correct transition looks like this:
Per Material design Guidelines:
The only difference is that we do not shrink the title as per the demonstration. Rather, we use the site name and logo on the prominent toolbar, and replace with the page title on the standard toolbar. (See next item).
- The transition between the prominent and standard toolbar should be smooth, with no jank or artifacts at any point.
Add titles to standard toolbar on static pages
Unlike say the suttaplex or text pages, the standard toolbar on static pages is blank. It should contain the title of the page. Thus for static pages:
- Prominent toolbar appears at the top of the page, containing the site title and logo.
- Standard toolbar appears when you scroll down, and contains the page title.
If you have a look at how Discourse does it on threads, we want something similar.
- To transition between the site title and page title, fade the site title out and fade the page title in.
Attach the Adaptive Tab Bar to the standard toolbar
Static pages make use of an Adaptive tab Bar (ATB). These provide a group of related, hierarchically horizontal, pages that vary according to context.
As a historical note, this idea was added in the late stages of the initial development. I like it and would like to extend the concept beyond just the static pages, applying them to text pages and maybe elsewhere, too.
The ATB is currently affixed to the prominent toolbar. So if you scroll down, the ATB disappears. If you scroll up, the standard toolbar appears, without the ATB.
The ATB should remain fixed to the toolbar regardless of whether it is in prominent or standard state. Adding the title also, we end up with something like this:
This has the advantage that when you are halfway down the page, you can scroll up a little, and the toolbar and ATB appear, so you can navigate between pages right there.
- The ATB should be always attached to the relevant toolbar, and display when the toolbar displays.
Functionality
Linkify the site title/logo
It’s common practice to click on a site logo and/or title to get Home. However SC breaks this: the main site logo/title is not clickable. The entire area (including logo, main title, and subtitle) should be a single clickable area that takes you back to the Home page. This should be the same on every static page.
- On static pages, make the site logo/title a link to Home
Remove HOME from ATBs
Currently the ATBs include a HOME tab. This breaks Material design, which specifies that on a Tab Bar, each option should be part of a horizontal navigation hierarchy. HOME is of course going up in the hierarchy, not sideways. Thus we should remove it, and users can get home via the main site title or the sidebar. (See previous).
- Remove HOME link from all ATBs
Reduce horizontal padding for toolbar elements on small screens
It’s hard to read the page title on small screens, as there is insufficient horizontal space. For narrow screens, therefore, we should reduce the horizontal padding between the various elements, i.e. the icons and the page title.
Remove white lotus logo Home link from toolbar
This is something was added quite late in the development cycle. We were concerned that there needed to be a more obvious Home link on all pages. So for the standard toolbar, i.e. not on static pages, we added a SC white lotus logo to serve as a Home link.
Of course it is always possible to go home via the sidebar, and I now think adding the lotus was a mistake. Why?
- It’s an extra thing and not really necessary
- It’s not really obvious that it is a Home icon
- It makes the toolbar too busy (see previous item)
- It is common on modern apps to omit such a Home button: Gmail, for example, does exactly what i am proposing, just have “home” on the sidebar.
This change comes with a cost: some functionality is removed, and I assume some users would prefer it the way it is. But I think on the whole it should be an improvement.
Combining the last two items, here is the toolbar on narrow screens as it is (left) and with the proposed changes (right).
Currently for small screens we shrink the font-size of the page title. These proposed changes would occur at the same break-point.
- Remove lotus Home icon and reduce horizontal padding of toolbar elements on narrow screens, using the same breakpoint as for reducing the font size.
Improve search field responsive behaviour
There are currently some bugs in the search field.
- On a narrow screen, if you open it, it makes the hamburger menu shrink away. At certain widths, it kind of half shrinks and leaves a ridiculous little thing behind.
- The search field also encroaches to the right for some reason, not just pushing out the vert-menu icon, but actually pushing out over the screen.
This all seems like bad CSS design. It should work like this.
On sufficiently wide screens, the search field simply opens and does not affect any other toolbar items.
- Current status:
On medium width screens, open the search field and hide the page title.
- Current status:
On narrow screens, open the search field and hide everything else on the toolbar, so that the search field takes up all of the toolbar width.
- Current status:
- Ensure search field has correct behavior in all contexts and screen widths.
Retain search term in search field
Currently when you enter a search, the search field retracts and the search item disappears. This is an example of an anti-pattern that arises because of not responding to explicit user requests.
Instead, keep the search field open when a search is entered, and retain the search term in the field. Then if someone wants to change the spelling or enter a new search, it is right there already.
The search field should only close if a user requests it, or if they go to a new page.
- Keep search field open with search term retained when a search is entered.
