MD Toolbar and menus


The top header AKA Title bar AKA “Tool bar”.

The Toolbar keeps similar behavior to the current design. I.e. it is narrow, retracts on scroll-down, and reappears on scroll-up. This is the default behavior of the Polymer app layout:

The essential elements are, from left to right:

  1. Hamburger for nav drawer
  2. Adaptable title
  3. Search
  4. Forum
  5. Tools/settings
  6. Vertical menu

  ≡  Middle Discourses                                🔍  🗪  ⚙ ⋮

Tools and chat are context dependent.


Toolbar background color should change according to context. Rather than the pastel yellow we use currently, we should use a bold color as usual for MD. We can define distinct colors for:

  1. Home page
  2. Suttaplex lists
  3. Text pages
  4. Search results
  5. Static pages

Let me discuss each item in turn.

≡ Main site navigation

Opens the nav drawer.

This one is cute:

Adaptable title

MD typically eschews the traditional “Home” icon. Instead, “Home” appears at the top when the nav drawer is opened. This is seen both in Inbox and the MD specs site.

Meanwhile, the Toolbar displays a context-dependent title.

  • On suttaplex lists, this would replace the “caption” on the division pages of the old site.
  • On text pages, we can have the Sutta title and translator.
  • On search pages, the search term (?)

:mag: Search

For apps where search is not the main purpose, such as SC, MD specs say display just the icon by default, and expands on click.

:point_right: Use expandable search

There are a number of different styles of search fields in MD apps. I dislike extreme search fields, where clicking on the icon radically changes the view (like, say, In fact, as a general rule, when you click on the search field, nothing else should change unless necessary.

Nor, in my view, should a search input field expand the whole width of the screen. Rather, when you click on the search icon, you should expect to write text fairly close to that.

So let us have a search that expands modestly from the current position. We can take the material specs site itself as a model:

  • On a wide screen, when you click, the search field appears, expanding to 360px.
  • Once clicked, focus is automatic, so you can start typing.
  • The opened state of the search field does not persist when going to a new page. (I think the point of this is that if the search is opened, you may have hidden the title on the new page. Best to keep the navigation clear.)
  • The first break point is at 790px. Not sure exactly what is going on here, as this is not one of the MD break points. Anyway, let us assume we use the MD breakpoints. Since we will have quite long titles, let us make this first breakpoint at the next larger MD point, 840px.
  • At the first breakpoint, two things happen:
    • the title disappears
      • This is good, we should do the same
    • the search input field shrinks.
      • I don’t see any reason why the search input field should shrink at this point. Let’s keep it at 360px.
  • Returning to, at mobile widths, 480px, the input field shrinks again.
  • For us, I would suggest that at mobile width, make the input field 100% of the available width, allowing for padding, etc.
    • If it gets too cramped, we can hide the other icons when search is expanded. But hopefully this won’t be necessary.
  • One detail: as noted, we sometimes have long titles. The behavior described here will, I hope, handle most cases well. But there may be cases where the title clashes with the expanded search input. To handle this, ensure that the search input has a higher z-index, and the title is hidden properly underneath.

For the search results pages, see the dedicated page:

🗪 Forum

Connection with Discourse is similar to use of social media widgets, etc. Display this everywhere, and add badges indicating the number of conversations where relevant.

On click, it should open a dropdown menu listing the conversations, as in the current design. If there are no conversations, have a dialogue saying what Discourse is, and inviting them to join.

:point_right: Use MD list

:gear: Tools

:point_right: Use MD dialogue

Dialogs inform users about a specific task and may contain critical information, require decisions, or involve multiple tasks.

Dialogues can include a greater variety and complexity of interactions as opposed to Menus.

The Tools dialogue would be context specific, and would only appear on Text pages. By appearing only then, it calls attention to itself.

It would include:

  • image Textual Information
  • :eye: Lookup dictionary
  • image Script switcher
  • Text & Translation view selector (not yet implemented)
  • ⇄ Parallels and References
  • image Metadata

Generally speaking, when choosing from a set of options, it is best to use a dropdown menu. This is especially the case if there are many options, and in cases where the number of options can vary or grow over time.

Here is a discussion of each element.

Textual Information

:point_right: Toggle with a switch

Lookup Dictionary

Lookup Dictionary occurs on Pali and Chinese pages only.

:point_right: Use a dropdown

Rather than having separate “select” and “activate”, as currently, include “none” as one of the options.


Script Switcher

The script switcher allows to select one from a group. It occurs on Pali texts only.

:point_right: Use a dropdown.

Text/Translation view selector

The Text/Translation view selector allows the user to compare the translation with the original text in a variety of ways. Each of this has its own use case.

  • image Columns are good on a wide screen.
  • image Line by line is for narrow screens.
  • image Popup is good for occasional checking if using a mouse.

:point_right: Use a radio button group.

Parallels and References

:point_right: Open “suttaplex URL” in new tab.


Metadata displays the information as in the current metadata tab.

:point_right: Toggle view with an expander.

In addition to the info currently available, extract data from github, such as contributors, last modified, etc.

⋮ Toolbar Menu

Menus in MD display a list of choices, with one choice per line. They are not used for primary navigation. Represent with a three vertical dot icon (AKA vertical ellipsis) at the far right of the Toolbar.

Whereas the Tools is for the text pages only, the Toolbar Menu applies site-wide. Here we include:

  • image Change site language
  • :pray: Donations
  • image Downloads
  • :busts_in_silhouette:Acknowledgements
  • Methodology
  • Abbreviations (include “Numbering”)
  • Bibliography
  • Free, Open, Safe
  • image About SuttaCentral

Change site language

This switches the UI, etc., i.e. it applies the i18n.

:point_right: Use a dropdown menu. Also see:

No Help

Help = :poop:

Among the many, many disadvantages of help pages:

  • Who uses them?
    • When was the last time you ever used a Help page on a website? Was it in a year that started with a “2”?
    • According to Google Analytics, the current Help page accounts for 0.01% of our page views, with a bounce rate of 100%.
  • Hard to update
  • Each time the site changes we have to check it. Our current Help hasn’t been updated for years, and I am sure it has lots and lots of wrong things. Who cares? Not me!
  • It’s almost impossible to anticipate answers to specific problems with a general solution.
    • Someone goes on to the site who knows nothing about computers. Like, literally, say a Burmese monk who has just got their first Android phone and has never used the internet before. “Click” on a “link” or “use search” or “open sidebar” are just meaningless to them.
    • Someone else comes on who wants to know how to extract JSON data via our REST API.

Let Help die already. Use Discourse instead.


:point_right: Use a Stripe form:

Downloads, Acknowledgements, Methodology, Abbreviations, Bibliography, About

These all lead to static pages. We can review them, but otherwise they stay much the same.

Free, Open, Safe

Here we can include:

  • Copyright policy
  • open source policy, link to Github
  • security, privacy policy

This page is expanded from the current Copyright page, and gives an overall view of the ethics and legalisms of our site. If we call it “copyright”, it sounds like we are making copyright claims, rather than relinquishing them, so let’s call it the opposite.

We can explain the copyright situation as currently. In addition, promote the open source nature of our work, encourage people to fork the repo, etc. And we can make an assurance that there is no advertising, tracking, etc. on the site.


@Sujato. Your tools-menu has been uploaded in the new suttacentral/next-sc. My mockup is hereby abandoned.
Go to Digha Nikaya, click on “Bodhi” or “Sujato” at DN1 or DN2 and then the settings-icon will appear in the toolbar. Note that the menu is not operational yet. I also left out the Chinese because that is supposed to just appear on the Chinese pages and I will add that when I make these things operational.
The data is in the file elements/menus/settings-menu.html

Some remarks:

  1. Same problem again with the fonts. You had changed them in the bower-components which does not work. So some are still in Roboto. Will leave that to you to sort out.
  2. I found the error with the colors and changed that on the language menus in the suttaplex also.
  3. In the files you sent me for the tools-menu, there was a lot of superfluous CSS code and superfluous loading of polymer elements. I filtered out the bits that were needed but when you make something in the future, please clean up the code to remove what is not needed.
  4. Your mockup did not have an operational paper-dialog box, only part of the coding thereof, so I made it the way I think you meant it.

Another thing that needs to be done is the CSS for the actual text page. This you can find in styles/text.css.

I’ve got the updated version, but it’s not working: the settings icon doesn’t appear, and instead the contents appear as a glitchy overlay.

No, the dialogue is now static, it should appear in the same way everywhere.



I think you don’t have the necessary bower components. Hold on, I will check.

Indeed, you are missing the bower-components. @Blake, is there a specific reason why the bower components are not pushed to next-sc?

@Sujato, just run an install of the following items and it should work:

bower install --save PolymerElements/paper-dialog-scrollable
bower install --save PolymerElements/paper-radio-group
bower install --save PolymerElements/paper-radio-button
bower install --save PolymerElements/paper-dialog
bower install --save PolymerElements/paper-toggle-button
bower install --save PolymerElements/paper-dialog-behavior

It might already do it when you just run one of those because you probably have the correct bower.json.

Great, thanks, now it works fine! Everything looks great.

Are you going to go ahead and make it functional now, or is that for later?

I’m working on some JS problems at the moment first. I cannot make it functional until I figure those out (with the help of the guys on Stackoverflow and Slack :slight_smile:) In the mean time, you can work on the CSS. Will let you know when I will start working on this again.

And I will add the Chinese back now first. Note that some of the fonts are still in Roboto!

Okay, no worries. I’ll check out the font weirdness.

It’s uploaded with the chinese now.

Awesome, looks good.

I suspect the trick is in something like re-defining the default font, like you did with the default color:
--primary-color: var(--sc-gold-500);

The default SC styles should go in styles/sc-styles.html

Okay, thanks. Yes, we should have Skolar Sans as the general default, applying Skolar PE (serif) on texts and certain other cases.

So it seems the problem is it’s importing paper-styles, which imports typography.html, and certain elements get their fonts from there. Anyway, add the following to sc-styles.html:

    --paper-font-common-base: {
  font-family: 'Skolar Sans PE', 'Noto', sans-serif;
  -webkit-font-smoothing: antialiased;

Tomorrow I’ll look at getting the proper text styles working.

1 Like