This is an initial speculative draft intended for clarification of ideas and feedback from SC team.
See the Material Design docs for background.
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:
- Menu
- Division pages (showing lists of suttas with brief information)
- Details pages (single suttas with detailed information)
- 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:
- Sidebar
- Suttaplex lists
- 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:
- 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!)
sutta{
middle{
majjhima nikaya{
mulapannasa{
mulavagga{
mulapariyayasutta{
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:
- How to organize the data
- How to manage data for the client
- How to present the data.
UI aims
- Consistency: present the same thing the same way, unless there is reason
- Fluidity: enable natural movement up and down the tree
- Donât lose anything: No capability in the current system should be lost
- Backwards compatible URLs
- 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.
Breadcrumbs
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.
- Highlighted item tells you where you are.
- Click on previous items to go back.
- Context is always visible, but never intrusive.
- Breadcrumbs dynamically reinforce the user perception of their place in the app.
- 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:
- On the left, it shows you your contextual place, eg. the name of the sutta.
- On the right, search and menu icons that apply app-wide.
What if we were to separate the universal and contextual functions?
- The universal appbar (in black) contains the breadcrumbs, search, and menu. This applies throughout the app. Menu settings are universal (eg. color scheme).
- 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:
- Search within the current view
- 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.
Transitions
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:
- Breadcrumbs move laterally
- Browser forward/back buttons are oriented laterally
- Swiping naturally movers laterally
- 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?
- The sidebar: itâs a complex bit of UI, lots of data, js, and CSS to make it work.
- Responsive design is easier. No need to worry about adapting the page when the sidebar expands.
- 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.
- 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?
- User feedback as to context.
- Very mobile friendly, it uses the âclick on cardâ movement that is natural to touchscreens.
- Information is organized and presented in relevant place. Currently, for example, essays are separated from the thing they are essays about.
- Flexible structure of cards enables context-dependent views.
- Depending on OS, browser forward/back buttons can also be used for navigating in some places they are not useful currently.
Implementation
Obviously this is a major UI overhaul and will be quite complex. Nevertheless, I donât imagine it will be too hard, as:
- We are mostly reusing UI views.
- The data is already present and organized.
- The breadcrumbs is the only truly new UI element.
Files
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.
sc_gingerbread.zip (892.6 KB)