Rethinking SC navigation: the gingerbread edition

This is an initial speculative draft intended for clarification of ideas and feedback from SC team.

See the Material Design docs for background.


SuttaCentral deals with the complex task of navigating around the vast mass of texts, contained in some 100,000 files in over 40 languages, as well as organizing and displaying information about those texts.

The previous iteration of SC had a fourfold presentation:

  1. Menu
  2. Division pages (showing lists of suttas with brief information)
  3. Details pages (single suttas with detailed information)
  4. Text pages.

In the new iteration we have combined 2 and 3, and made the top menu into a sidebar, leaving us with three components:

  1. Sidebar
  2. Suttaplex lists
  3. Text pages.

These three kinds of thing offer a progressively closer view into the data. Obviously they work fairly well, but there are a number of problems.

UI repetition

Consider an object such as a vagga, which is found:

  • in the sidebar as a link in green. Click it and it takes you to another “place”, the suttaplex list.
  • in the suttaplex list as an openable item in grey capital case. Click it and it dopesn’t take you anywhere, but it reveals more information.
  • and in the text page as a supertitle item in grey small caps. Currently this is staic, but there is a proposal to make it navigable, i.e. to replicate the functionality of the sidebar.

So each place the vagga has a different appearance and function. Moreover, it draws from different data, so that the spelling or translation may differ.

There are other instances of repetition, too. The suttaplex, for example, appears both in the suttaplex list and in the text page.

Data repetition

Underlying this, the data for each of these contexts must be fetched. Different components sometimes use different data sources. In the case of the sidebar, the data is loaded several times to enable the flexible opening of different levels of hierarchy.

All this violates DRY, making it harder to maintain data, and adding expense in loading and parsing data in the app.

Navigation in root languages

This is embarassing, we should not expect the user to know Pali to find a sutta. But it’s not as simple as replacing root with translation. Sometimes there is no elegant way to distinguish things in translation (think Madhyamagama vs Majjhima Nikaya, or Dharmapada vs Dhammapada), sometimes the root is more familiar (every knows the Satipatthana Sutta), sometimes there is no translation, and so on.

The essential limitation is that the sidebar should have only one line per item, so we can’t have text and translation. It’s already heavy with information, we cannot overload it further.

Mixed UI messages

Items in the sidebar open downwards. At a certain level, they open sideways. Clicking items takes you to a different page. On that page, the suttaplex list, some things open to reveal more information, other things take you to a further place, the text pages.

There’s nothing wrong, in principle, with having different UI interactions for different kinds of things. But this all rather disguises the essential fact: clicking gives you more information.

Sorry, where am I?

We are currently considering making the text supertitles navigable; in essence, making them more like the sidebar.

We’ve also considered connecting the sidebar with the text more closely, so that the sidebar indicates where in the hierarchy the current text is.

These examples show that the current UI is too disconnected, too inorganic, so one part yearns to become the other.

Conclusion: A sidebar is the wrong choice of navigation for SC, as it only works with simple information, but our context requires a degree of complexity

One object

How about we replace the three components with one:

  1. Like, literally everything.

View is handled in one context. Everything from the basic division of Sutta, Vinaya, Abhidhamma, down is part of the same tree.

No sidebar, and no separate suttaplex list. Navigation is more like twitter. You keep opening up to reveal more. In essence, this is just like a traditional tree of directories. (Pseudodata follows!)

        majjhima nikaya{

Each node is more or less complex and is associated with several types of data.

majjhima nikaya{
     root: Majjhima Nikāya
    translation-en: Middle Discourses
    parallel: madhyamagama

Obviously this is a conceptual model of a single tree, not an actual file. Our task then becomes:

  1. How to organize the data
  2. How to manage data for the client
  3. How to present the data.

UI aims

  1. Consistency: present the same thing the same way, unless there is reason
  2. Fluidity: enable natural movement up and down the tree
  3. Don’t lose anything: No capability in the current system should be lost
  4. Backwards compatible URLs
  5. Dunceability. Idiot-friendly.

Imagining the user journey

They come to the Home page. There’ll be other stuff here too, but prominently will be three cards for the three baskets: these cards are already present on the Home page, but their position and function would change.

So you get

  • the title in Root and translation
  • a blurb
  • a button for the major action
  • a badge for the “yellow brick road”, telling you that there are translations in your language.

All these things will be pretty much universal to all cards so far as possible.

You also get some rich optional information, in this case a link to the Introduction for each pitaka. Some information may or may not be present on a card by card basis.

Assume you want to read Discourses, click the card and see.

Instead of the cryptic “Long”, “middle” etc. you have a clear description what each one is. Ooh, also notice there is a breadcrumbs menu at the top. It tells you where you are and where you came from! Nice! There’s also a contextual search box. I’ll talk more about these features later on.

Okay, now click on “Long”

Now we get more rich information.

  • link to an essay
  • some fancy stats. Just an idea!
  • link to the "edition"page (which is a proposed portal for accessing a whole translation.)

Click on the first card, or the “View Chapters” button, and you’ll see the three vaggas of the DN.

If instead you want to go straight to the suttas, click the button.

Click on the first chapter and you go to the suttaplex list, pretty much as it is currently on SC.

Compact view

I think this is a much better experience for new users, they can get oriented step by step. But what of power users? You don’t want to see that stuff every time. Don’t worry, we already have a Compact view, let’s apply that throughout.


We should intentionally design UI feedback to ensure that the user stays oriented within the collection as a whole. This is done using the well-established UI pattern of breadcrumbs.

An important thing to bear in mind is that breadcrumbs show you your contextual position within the site hierarchy, not your history.

  1. Highlighted item tells you where you are.
  2. Click on previous items to go back.
  3. Context is always visible, but never intrusive.
  4. Breadcrumbs dynamically reinforce the user perception of their place in the app.
  5. If breadcrumbs are too long, especially on mobile, they scroll horizontally.

Two header bars

By adding a breadcrumbs menu, we create a second header bar. Perhaps that can be used for something more?

Currently the header bar gives you two things:

  1. On the left, it shows you your contextual place, eg. the name of the sutta.
  2. On the right, search and menu icons that apply app-wide.

What if we were to separate the universal and contextual functions?

  1. The universal appbar (in black) contains the breadcrumbs, search, and menu. This applies throughout the app. Menu settings are universal (eg. color scheme).
  2. The contextual appbar (in orange) contains the present context title, as well as options that apply in context. For example, on the navigation pages we have a “compact” setting. On text pages, we can change the views or see text meta-information.

This would allow us to avoid using the “adaptive tab bar” (ATB) in such contexts.

Contextual search

Enabling search per context is a long-term goal. It has two dimensions; the back end and the front end. here I discuss only the front end. The UI is inspired by the search on Github.

Limiting search to a particular context is done via filters such as in:dn. The user can enter any ID, or a predefined set of abbreviations, including sutta, vinaya, ebt, etc.

On the navigation pages, there is an extra search field, which is pre-populated with an appropriate filter. The user gets immediate feedback on two things:

  1. Search within the current view
  2. The fact that filtered search is possible.

This lets them learn about how filtering is done.

The secret, which they will get in good time, is that there is really only one search! You can put filters in any search box and get the same results. And, the filters can be a lot more specific or broad than just the contexts in the navigation. For example, you might remember a simile found in a short sutta and filter in:an in:sn, etc.

Suttaplex view

Remains mostly the same, but we can simply it by removing the "node entries for vaggas, etc. Just have the cards.

Text view

Again, mostly the same, except we can remove the suttaplex card from the text page. You can always access it via the breadcrumbs.


Currently this is naive HTML and one page replaces another. But as SC is a SPA, we can use whatever kind of transition we like.

Look at how movement works on the page as-is:

  1. Breadcrumbs move laterally
  2. Browser forward/back buttons are oriented laterally
  3. Swiping naturally movers laterally
  4. Prev/next buttons on text pages are lateral.

Hmm, am I picking up a theme? What if transition from one navigation view to the next were also via a lateral transition? When you click on a card, the view moves out to the left, and the new view moves in from the right. This would reinforce a consistent sense of movement tied between the page and the breadcrumbs.

OTOH hand, some users find movement disorientating, so that needs to be considered. But “prefers-reduced-motion” exists for this reason.

What have we lost?

By “lost” I don’t mean in a bad way, I mean, from what have we been freed?

  1. The sidebar: it’s a complex bit of UI, lots of data, js, and CSS to make it work.
  2. Responsive design is easier. No need to worry about adapting the page when the sidebar expands.
  3. The breadcrumbs menu is a simpler than the sidebar: no green dots, no language icons, no side and down arrows and movements, no typographic hierarchy. That’s a lot.
  4. I imagine the routing etc. will be easier as you are just managing one set of views.

The only bad loss can think of is that you no longer have universal navigation on every page. This is on the one hand a perceptual loss, a user may feel as if navigation is slower. But I don’t think it’s a genuine loss in terms of number of clicks. It depends a bit on how the sidebar state is left (open or not, or how many levels are open), but generally speaking it’s the same number of steps to get anywhere.

What have we gained?

  1. User feedback as to context.
  2. Very mobile friendly, it uses the “click on card” movement that is natural to touchscreens.
  3. Information is organized and presented in relevant place. Currently, for example, essays are separated from the thing they are essays about.
  4. Flexible structure of cards enables context-dependent views.
  5. Depending on OS, browser forward/back buttons can also be used for navigating in some places they are not useful currently.


Obviously this is a major UI overhaul and will be quite complex. Nevertheless, I don’t imagine it will be too hard, as:

  1. We are mostly reusing UI views.
  2. The data is already present and organized.
  3. The breadcrumbs is the only truly new UI element.


Here are the HTML files I used for the above screenshots. They work, but not fully. Generally only the first card is clickable. Comment in/out the code block at the end of the CSS file to get the compact view. (892.6 KB)


Some articles on breadcrumbs:

This article suggests using left-pointing arrows for breadcrumbs:

I wonder if we can enhance breadcrumbs by remembering where you have been?

As you navigate, more breadcrumbs are shown. Now, if you navigate back, the deeper breadcrumbs disappear. But what it they didn’t disappear, they just became de-emphasized? That way you could one-click back and forth anywhere in your trail.

Going in:

Home > Discourses > Long > Long Discourses

From there, click on “Discourses”, you get:

Home > Discourses > Long > Long Discourses

So long as you stay on the same trail, your footprints are preserved.


This is great. Thank you and anyone else involved for all the hard work, Bhante. Awesome idea and I think it will make navigating the already amazing site, even easier. Sadhu!!!


Goodbye sidebar. Hello simplicity! :man_cartwheeling:

And I suppose search results are just a bunch of “little cards” as well.


{Please delete this if you weren’t looking for general feedback}

I have seen this in GIMP file dialogue box and I find it confounding every time. Is this the standard way that the Mac finder works?

For me, I’m conditioned to know where I am by looking at the end of the trail. Your proposal breaks this. I have always understood breadcrumbs to indicate where you are and the levels above you. Adding in “where you have been deeper down” confuses this. That’s what the back button is for.

In your example when you have clicked “Discourses”, you obviously don’t want to be in “Long Discourses” because you just clicked away from there. What’s the point in having this so prominently indicated? The only point I can see is if you realize you went to high and really just wanted to be on “Long”. But at least in this case, Long would be an option on the Discourses page.

But simply put, I find having crumbs scattered in front and behind to be confusing. :boom::cookie::boom: :slight_smile:


Yes, I see your point. I just checked GIMP and I agree, although it also seems that in that case the styling doesn’t highlight the current position very clearly.

Perhaps the best approach would be to build it the most simple way to begin with, and add “preservation of footprints” if user feedback suggests it is useful.