A few updates to the spec

For @blake and @Vimala, here are some thoughts I have had that update some aspects of the spec. If there are no disagreements, I’ll add these to the spec in due course.


Looking closer at Polymer, I noticed that they implement Aria metadata automatically.

Improving accessibility has been on the issues list for two years, but nothing has been done about it:

At last we have the chance to make this happen. I know little about it, except that it’s a good thing. But we should take care to ensure that where Polymer elements apply Aria metadata, that this is retained and is implemented correctly.

###Tools dialogue

This replaces the old “Tools” tab in the sidebar. The “Tools” tab is adaptive, and delivers different content depending on where you are. In the original spec, I had expected to do the same thing. However i now think this is unnecessary and it will be better to deliver just one Tools dialogue, which will be the same everywhere. This is because:

  1. We have more space, so this is not an issue.
  2. Adaptability is harder, because the line between Pali/translation is less clear with the text & translation view.
  3. It helps to surface tools, so more people can find that they exist.

I shared a Polymer mockup with Ayya recently. Here is a slightly developed version of that:


I have come to a clearer understanding of this, which I would like to implement consistently. The basic idea is simple: don’t second-guess the user.

This has come up in various contexts. For example:

  • When designing the nav drawer menu, if the user opens an item, do we close the already opened item? (No!)
  • If a user selects a tool in the dialogue, do we assume that they want to activate that persistently in the future? (No!)

The basic pattern should be:

  1. User initiates an action (eg. selecting a tool).
  2. A change happens that implements that action (i.e. the code runs).
  3. That change is communicated to the user in a clear and unambiguous way. (MD recommends indicating change with at least two things, eg. animation and color)
  4. Nothing else happens as a result of that action; there are no unexpected or hidden consequences.

A relevant MD element here is called a “toast”, which is a transient notification that pops up to inform the user.


We should use this in appropriate cases, for example, when asking the Tools dialogue to remember our preferences.

Thanks. Can you place them in the relevant section (or make a new section) in the SC Next category?

I will do, yes. Also as for the dialogue, i have an updated Polymer mockup, but I’ll keep it for now, as I might make some more changes. Let me know when you want to work on this and I’ll share it.