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:
- Hamburger for nav drawer
- Adaptable title
- 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:
- Home page
- Suttaplex lists
- Text pages
- Search results
- Static pages
Let me discuss each item in turn.
≡ Main site navigation
Opens the nav drawer.
This one is cute:
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 (?)
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.
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, https://www.wired.com/). 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.
- the title disappears
- Returning to material.io, 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:
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.
Use MD list
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:
- Textual Information
- Lookup dictionary
- Script switcher
- Text & Translation view selector (not yet implemented)
- ⇄ Parallels and References
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.
Toggle with a switch
Lookup Dictionary occurs on Pali and Chinese pages only.
Use a dropdown
Rather than having separate “select” and “activate”, as currently, include “none” as one of the options.
The script switcher allows to select one from a group. It occurs on Pali texts only.
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.
- Columns are good on a wide screen.
- Line by line is for narrow screens.
- Popup is good for occasional checking if using a mouse.
Use a radio button group.
Parallels and References
Open “suttaplex URL” in new tab.
Metadata displays the information as in the current metadata tab.
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:
- Change site language
- Abbreviations (include “Numbering”)
- Free, Open, Safe
- About SuttaCentral
Change site language
This switches the UI, etc., i.e. it applies the i18n.
Use a dropdown menu. Also see:
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.
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
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.