Mobile Development

I’ve been seriously investigating Progressive Web Apps the past month, and not only is it a good idea, it is important. The next billion users to come online will be using mobile devices and those mobile devices will be overwhelmingly low-powered and on low quality mobile connections. This makes websites which work well on these mobile devices very important. Also while mobile devices are getting more powerful and connections are getting better, the flipside is that mobile devices keep getting smaller and lighter, which means smaller batteries and more aggressive power savings and mobile networks keep getting more congested as more people come online and use mobile internet for more things.

A PWA provides native-app like performance and characteristics while still being a website. Some of the goals of adopting a PWA architecture would be to reduce the time to first interactivity by 90% (i.e. on a bad connection from 20s to 2s or so) and also improve search rankings by having a site that ticks the right boxes when it comes to implementing PWA technologies, of course presumably this would also create a more pleasant experience for users, including the ability to add the site to the the front page of an Android device.

The Plan

The basic idea would be to start developing a new version of the site on, we would use “next” because it’s not just the mobile version, it’s also the next version of the site (while it will be designed for Mobile first, the UI will also adapt a larger display)

Once that version reaches a high level of usability it would become, while the existing site is moved to

A couple of technologies

It’s come up before, and I think it’d be a good idea to use the principles of Material Design - for the greatest part we already do but we could adhere more consistently. It would be a good way to reduce decision fatigue (instead of having to decide how to do something, it’s a matter of “material design says to this approach”) and chances are that it’s very well researched and tested to be agreeable to users, certainly since Google uses it extensively it would be familiar to users.

Material Design, being Google, may occasionally be at odds with how Apple, Facebook etc like to do things. I think the Android look & feel is the best one to emulate, but slightly different patterns might be found in an iPhone app.

There are implementations of Material Design, like the “Paper” web components by the Polymer team. There are some other implementations, like Material-UI for React, and then there are Materialize, Material Design Lite and MDC-Web which use old style HTML4 elements with classes.

At the moment I’m inclined towards Polymer because it’s the most PWA, but it’s worth noting that it’s also relatively easy to use components from collections like MDL or MDC-Web. The main downside of Polymer right now is that it is transition between 1.0 and 2.0 and the site is a bit disorganized - however the paper collection is rather stable. (Polymer does a lot of other things besides just provide collections of elements, besides helping to make your own custom elements, it also has polymer-cli for building and deploying sites).

Design and Emphasis

When SuttaCentral first began it was almost strictly about sutta parallels. I believe it is not wrong to say that the emphasis has moved much more to texts and this will only become more true when the new nikaya translations are released, I believe this has to be reflected in the new UI, that the number of clicks from home page to reading an interesting text should be reduced, and users should be guided where to click so that especially new users can quickly find something interesting to them.

One thing which is interesting to see when you look at the analytics for SuttaCentral is a lot of users end up on /pi/dn1 - and I believe it’s not because so many people are interested in /pi/dn1, but because of a mentality of clicking on the first thing you see when you don’t know what to click on (that is the top-left most link tends to draw the most attention)

Mocking around with things, it struck me, at the moment the header is:

Sutta Vinaya Abhidhamma

How much does that mean to an english speaker who is casually interested in Buddhism?

Also, realistically speaking, how interesting is vinaya and abhidhamma for the majority of users? Is it imperative that you can navigate with least possible effort from any page on the site to these? I’m not saying to relegate them to some dusty corner of the site, but questioning the prominence of these categories and their primacy in navigation, yes, it makes sense from an organizational perspective, but does it make sense from a user experience perspective?

So I’m going to ask a few questions:

  1. What should be in the header?
  2. What should be in the sidebar?
  3. What should be on the home page?
  4. What other navigational elements could be use?

Here are my thoughts

What should be on the homepage?

Things that would most likely be interesting to the average user and especially a new user:

  • Top level navigation (links) - maybe
  • Showcase (I’m thinking here things like the Nikaya Translations)
  • What’s new
  • Some kind of “reading/category/explore lists”? I think there is a comprehensibility problem with the site, if there is say some lists of texts about “Compassion”, “Mediation”, “Equality” and so on - that would be something people immediately comprehend and lets them find something they are interested in. This way people are more likely to come away with a positive feeling about the site rather than feeling it’s way above their heads.
  • The intro - although if the site requires a guide to show how to use it perhaps the design isn’t very intuitive. Just saying. But still, some kind of intro/about/tour.

The material design specs indicates that the homepage should also change over time - essentially providing a simplified experience for a brand new user, providing tips and so on. This does require user login or at least recognition. It may not be for us, but it’s worth thinking about anyway.

What should be in the sidebar

In material design a sidebar is used for navigation and navigation only - navigation within the site and within the current page is fine. But controls shouldn’t be in the sidebar (controls are often in modal dialogs that drop down)

I think it could work well to have an accordion style navigation menu in the sidebar, maybe it starts as


But as you navigate it updates

  Pali (English Translation)
   Digha Nikaya
     DN 1 - Brahmajāla Sutta
       I. Talk on Wanderers

So this provides the ability to both navigate around the site, navigate to siblings at various levels, and navigate within the page.

The idea is then the sidebar would be usable on all pages. Perhaps for non-text views it should be visible by default on wide screens.

I believe that trying to stuff too much stuff into the sidebar is considered an anti-pattern, also it must be noted if the sidebar isn’t permanently extended then everything in it WILL be ignored by and unknown to the vast majority of users. I think it can still be acceptable as long as it’s not the primary way of finding stuff to read for new users.

What should be on the header?

Probably as little as possible.

The obvious things are the link to the homepage and the search icon. Those are very standard.
Maybe a site-settings cog. It is the standard place to put things.

What other navigational elements?

It is also possible to use “extra header” and bottom navigation. Condensing headers are popular, where you get more controls or links at the top of the page, then as you scroll down it condenses away.

Navigation pages should be strongly considered. In a PWA browsing from page to page can be very fast and back buttons are pretty good these days at returning a user to where they were before on a page so we should consider a link to another page - maybe for things like metadata.

A second header would be a good place for things like activating pali lookup and changing script. It would be nice if these things are fairly visible to make them discoverable.

Feedback welcome

Now would be a good time for anyone to provide critical feedback and ideas on how the site could be improved.


Hey Blake, thanks for the proposals, let me reply inline. As we’ve discussed, I support the idea of PWA, as well as a gradual shift to the Next version.

Actually, rather than Next, let’s call it the i18n version, because that’s what it is. And let’s use Internationalization is, as it has been for the past couple of years, the number one priority, and the single thing that will most improve the site for our users all round the world. The classic version can remain as the “expert” version, at least for the time being. In any case, the focus needs to be in getting the i18n version rolled out.

By the way, I just checked a bunch of Bible sites to see what they’re doing. The most interesting one is this:

It has a bunch of ideas similar to what we are thinking, but we will, of course, do it better.

As you know I am a fan of material design. In addition to the benefits you mention, one advantage is that it is designed to be internationalized. The development of Noto is intrinsic to the project, and obviously Google designs its apps to be read in Arabic, Chinese, or Swahili. This extends to even little details like categorizing scripts by line height adjustment, something we had to work out ourselves by trial and error.

If it’s any consolation, the traditional sequence would be Vinaya Sutta Abhidhamma. In the i18n version, of course, these will be translated.

Well, this would make John happy! I am dubious about implementation. What happens when there’s no updates for a while? But anyway, show me a convincing design …

In principle, sure, but again, I’d need to see a convincing design. It’s not too hard to select a few suttas on relevant topics.

But it seems to me the right way to introduce a reader is via a structured and guided course. It doesn’t need to be anything too complex. A simplified version of Ven Bodhi’s book, for example. I was hoping we would develop more of that kind of thing here, but so far it hasn’t taken off. It seems to me that by offering a selection of “popular” topics we risk being just half-baked: making it more complicated for we developers, distracting and taking up screen space for advanced users, while not really being useful enough to help newcomers. In any case, it’s more of an enhancement than a fundamental.

Allow me at this point to introduce:

##Sujato’s Grand Unified Theory of Websites

Known conveniently as SGUTOW.

###Axiom 1

  • Websites suck.

That’s it. There is no second.

Just a few days ago, I tried deleting my user account on my laptop Chromium, just to see what it would do. So back to a vanilla browser. I used it for a few days, and O. My. God. The absolute horror of almost all websites when you can actually see the ads and all the other crap they have. It’s just unbelievable. Now I have back my ad blocker, popup blocker, autoplay-blocker, social media widget blocker, etc., and it is relatively sane again. It is very telling that one of the most popular extensions is readability, as if that is not the basic function of a website.

Okay, so the web began as a way of sharing info, primarily text, which is what we deal in. HTML allows us to structure that, CSS to style it. The point is, you have something worth saying and the web is a bunch of technologies to help you say it.

But instead of saying what needs to be said, people try to impress people with their cool stuff, pull them into their marketing schemes, sell them some crap they don’t need or want. That is to say, the thing becomes about the website, instead of being about what it is you’re saying. I have probably shared this before, but for those with no fear of profanity, this is the best piece on website design you’re ever going to read. To quote:

all the problems we have with websites are ones we create ourselves. Websites aren’t broken by default, they are functional, high-performing, and accessible. You break them. You son-of-a-bitch.

The fundamental assumption of SC is that the words we have are the best words there are. Nothing, certainly not some shitty website, is better than that. So the entire focus of the design serves one end: the encounter between a reader and the words of the Buddha. Every single detail, every piece of code, every design decision, should be forced through the tightest of wringers in the service of this. Anything that gets in the way, that distracts in the slightest, must be eliminated.

In this way, our site is the anti-web. It stands against the distraction, confusion, and ever-changing jumble of nonsense. It should have a peaceful and timeless quality to it. Many Buddhist and Sutta sites try to identify their “Buddhist”-ness by putting cheery pix of the Dalai Lama, or big stupas, or whatever. But instead we should do it by embodying the principles of the Dhamma, the peace, clarity, and wisdom that people are looking for.

While the UI design of the modern web is something we can learn from, we should not defer to it, or imagine that our own tradition is lesser. On the contrary, our own UI, the design principles of the Dhamma itself, have proven themselves in multiple forms for far longer, and will be here when the web is long gone. From MN 77:

Once the recluse Gotama was teaching his Dhamma to an assembly of several hundred followers and there a certain disciple of his cleared his throat. Thereupon one of his companions in the holy life nudged him with his knee to indicate: “Be quiet, venerable sir, make no noise; the Blessed One, the Teacher, is teaching us the Dhamma.”

None of this is to mitigate against any specific idea, but rather to bear in mind that our aims, and hence the means we use to achieve those aims, are radically different than other sites. The website is not the purpose, it is simply one means of helping get the Dhamma in front of people.

In any case, as far as the Home page is concerned, putting more stuff there is easy. What’s not easy, though, is translating it and updating it. You want to have dynamic content? Sure. Is it automated or hand-curated? Fine. But automated content sucks, and hand-curated is a lot of work. And how do you get the same content updated in 30 languages? Ensuring it is fresh and reliably curated? Do you want to do that? I don’t.

You know what’s starting to sound attractive? Static text.

Another way in which we differ from other sites is that we have a didactic purpose. The basic purpose of most sites is to give people what they want. Our purpose is to help people stop wanting. And to do that, we have an ought. You might want to read a sutta with a million things in the background, listening to your favorite song, but you should read it in quiet, in a still place, free of distractions. This also relates to the appearance of the Pali and other parallels: you might only want to read the Pali texts, but you should be aware that they are only one part of the EBTs.

This sounds complicated. I like having a static and predictable menu. I know where things are and where to find them.

How’s this: make this system work so that you get to any sutta in the canon with less clicks than currently (maximum 4 clicks). I dare you. Oh, and no cheating: you must start with the sidebar retracted, because that’s how it has to be for mobile.

But doesn’t this illustrate the problem with this approach? Our texts are not structured in one list. Each root language must be considered separately. That’s why we use a two-dimensional (table-ish) layout for the menu, not a one-dimensional (list-ish). Admittedly, on a mobile we are pretty much limited to one dimension anyway. And maybe we could expand the sidebar on wide screens to have a two-dimensional view. Still, a sidebar is, at the end of the day, a sidebar, and if it is used for navigation, as in material design, it is standard to have that as a list.

Agreed, which is why the primary navigation shouldn’t be there. If you do this, then mobile users have zero guidance how to get anywhere without opening the sidebar. Hamburger sidebars have a lot of problems:

That’s why I was always happy we didn’t use it for primary navigation. The primary navigation is in the header, clear and present, and the sidebar gives you extra stuff. Much of the stuff in the sidebar is precisely things that not every user wants or should want to use. There’s nothing wrong with expecting a user who wants advanced, extra features to do a little digging: and it’s not as if it’s far to dig.

Why? What’s the problem with having navigation in the header? I know it’s not the standard material design pattern, but what purpose does it serve? Maybe it makes sense in the case of dynamic, non-hierarchical content, like, say on this forum, or an email app. But I can’t see why creating blank space in the only visible, universal component of the site is going to improve accessibility. It’s not as if it’s overloaded or confusing.

On the other hand, there is no compelling reason why the header must have Sutta, Vinaya, Abhidhamma, or Discourses, Monastic Training, Meta-teachings.

In support of keeping them, they serve a multiple purpose. As well as being a navigation, they tell a user what is on the site and what it is about. Of course, this means little to someone who doesn’t know what they are, but for those who do know what they are, they convey useful information. Even for a beginner, they provide an initial exposure to the idea of the Tipitaka, the content and scope of the site, knowledge that will be reinforced as they learn.

Perhaps we could replace them with something more useful, but I can’t think what.

  1. Languages? No, bad idea.
  2. Nikayas? But then you ignore the other languages, and anyway, they are no more comprehensible.
  3. Topics? Reductive, too specialized. Fine for a guide, not for a main menu.

I am fine with the idea of emphasizing Suttas over Vinaya and especially Abhidhamma, but I have not seen a compelling way of achieving this.

When it comes down to it, we are dealing with texts that are structured in this way. They have their own internal hierarchy. Of course, this is complicated by the other languages, but still. We should work with the hierarchy, not against it. I think this is another example where we should not be too compliant with modern UI trends, which are often designed to solve exactly the wrong problem—how to find your way around ever-shifting unstructured content.

If I could see an example of how that would work, that would be good.

The Guardian uses a second header quite nicely:

To me, the singular advantage of our current sidebar is this. You don’t need it. You can use the site fine without ever knowing it exists. But if you want any kind of extra stuff, there it is. Maybe it is a little obscure—although frankly I think this is overblown, it is pretty damn obvious. But once you’re there, it has everything. Whatever tools exist, they are in this place. So you can easily explore and find out what is to be known. But if some things are in a header, some in a sidebar, some in a second header, some in somewhere else, this just seems confusing to me. Not mention, much harder to design and maintain. Each different element has to work across all platforms, and this is never easy. Keeping our design patterns to a single, universal header menu, and an adaptive sidebar helps keep development overhead down. Again, not saying other patterns can’t work, but I need to see a compelling case.

If we look at the various kinds of flexible navigation around the place, mostly they don’t really apply to us (similar articles, trending, timeline, etc.)

I have previously requested, and stand by this, that a meaningful improvement on our current design would be to give every page a standard set of navigation options, in addition to the universal menu. These can be visualized as a 3D pattern:

  1. Left/right: i.e. prev/next, applied not just on the text pages, but on Details as well.
  2. Up/down: “Up” to the next level in the hierarchy, i.e. from a sutta to a vagga, etc. “Down” as appropriate, obviously this does not apply on a sutta, which is already all the way down.
  3. Out: to Details, especially parallels
  4. In: to the root text.

I don’t have any specific ideas about where this should go; perhaps as a second header. But in any case it seems to me that this would be genuinely useful, and not that difficult to achieve.


I don’t have much more to add than what is already written here. But when we are going to make a new site, it would be good to think about the accessibility aspects in a bit more detail, especially for the visually impaired.

After our discussion on header behavior, I checked out the Polymer website.

The basic desktop display uses a horizontal menu:

While the mobile version hamburgerizes it:

In between, though, you have this awkward transition, with things just shoved over on to the next line, and the last menu item floating in space.

Responsive design is hard!

I just came across the article, which you may find interesting. They’ve just implemented their site as a PWA:

just some various thoughts.

The way the site is organized now, you need to understand the organization of texts before you can really find anything. Also, the amount of links you get when clicking on Vinaya for example, is quite daunting. Plus there’s no translation there so new people will have no idea where to go.

The problem is trying to provide both all early source texts for the ‘pros’ and translations for the ‘amateur’ :slight_smile: in one system, while both on their own would be difficult enough. :slight_smile:

I don’t like those accordion menus much since you end up scrolling up and down, forgetting what you have opened and closed etc. But yes, you can use some more structure in the navigation. For example, you now have

Collection: Pāli Suttas
Division: Saṃyutta Nikāya (SN)
Sub-Division: Kosala Saṃyutta

If it’d be: Collection / Saṃyutta Nikāya (SN) / Kosala Saṃyutta you’d have the same info but it’s more intuitive that one is contained in the other. Also these things are now not clickable. Neither is it consistent once you open a text.

You could load all main links in one go. What I mean is, if I go from the home page to reading a sutta, only the sutta is a new page to load, not the books or sections such as SN, SN3, etc.

The hamburger menu now does not really do much for me personally. The links to pages are already available elsewhere (at least I prefer to just click “back” or the header menu instead of having to try and figure out a second way to do things) and the extra info can be put at the bottom of the page for example.

When you click “textual details” you don’t really get details, but mainly the parallels (which are also findable in other ways) and details of many texts.

but it’s a great site already! don’t forget that :smiley:

Thanks for the comments, ven.

I’ll have a think about that, but it doesn’t seem that persuasive to me. By labelling things explicitly as "collection, “division”, and so on, we are making clear the inner terminology we use for these things. Taking that away, and having a long horizontal line to read, doesn’t seem to add any clarity. But like I said, I’ll have a think about it.

These are things we are working on.

You mean, we prefetch all the intermediate pages so they load faster? This won’t be necessary with the direction we are planning.

That’s fine if there’s nothing you need there, that’s the point, to keep unnecessary things out of the way. But there are a lot of things on there apart from what you mentioned. So when you do need them, they’re waiting for you!

This is now renamed Parallels & References

Correction: renamed only on staging!

it doesn’t have to be horizontal.

This is the book
|-> This the division
… |-> This the sub.

(I hope this works…)

but my point is you don’t actually read it all, but use it more like a menu.

Not sure on how you’d do it specifically. My knowledge of the web is when everybody still used tables and mouse trails were cool. :wink:

So you’re thinking of something like this, am I right?

Maybe, I quite like it, and it’s easy to code. But while doing this I stumbled across this, which I actually like better. It’s simple and clean: never do by adding what you can do by taking away.

Actually, scratch that, why should anyone need to know about divisions and such? Why don’t we do something simple and similar to the sutta titles.


Here’s the code.

caption div{
  text-align: center;
caption div:last-child{
<div title="Collection">Pāli Suttas</div>
<div title="Division">Saṃyutta Nikāya (SN)</div>
<div title="Subdivision">Kosala Saṃyutta</div>

Done on staging.

Nice, thanks. I’ll play with the CSS a little, but the markup is there. But it doesn’t work everywhere, as we still have:

Do you also want to do the triangle-replacements I discussed elsewhere? Or should we throw that one to Blake?

1 Like

Done that too now,
I will have a look at the triangles at some point but I’m not very good at doing too many things at the same time :slight_smile: I’m now working on the english Vibhanga Pootle files and on the parallels pages on staging. Most bugs are out now, but there are still a few things that need to be done.

1 Like

@Blake. I have downloaded and tested some of the Polymer elements on the poly branch that you made. But implementation is not so straightforward in our current structure.

Rather than trying to substitute existing elements with polymer elements, I think it would be better to build things up with Polymer from scratch if we decide to go that way.

1 Like

Just some thoughts:

Personally, I’d prefer the example with the arrows: It gives both a written and a visual view. I think that especially in these times when people become more and more visually oriented, it is good to have both text and visual cues.

Additionally, I think it would be more logical to use the more “official” name “Sutta Pitaka” for the collection instead of the word “Pali Suttas”.
After all, the division and sub-divisions are not translated either, and someone who doesn’t know what “sutta pitaka” means, probably also has no idea what “samyutta nikaya” means.

1 Like