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:
- We have more space, so this is not an issue.
- Adaptability is harder, because the line between Pali/translation is less clear with the text & translation view.
- 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:
- User initiates an action (eg. selecting a tool).
- A change happens that implements that action (i.e. the code runs).
- 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)
- 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.