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.

###Accessibility

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:

###Intentionality

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.

https://www.webcomponents.org/element/PolymerElements/paper-toast

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.