Currently one of SC’s killer features is the Pali or Chinese dictionary lookup. Enable it and you can hover over Pali or Chinese words on the page and get a definition.
The Problems
Touchscreens: using tooltips on touchscreen is bad. This is more than 50% of our users!
Positioning: It’s hard to get the position right in all contexts.
HTML title attribute is bad: this is the basic HTML way of putting a tooltip on, but it suffers severe accessibility issues and is especially poor for screenreaders. Also there is no way to style it or add functionality.
Too much info: MD guidelines say a tooltip should have just a short message, no more than a few words. But we put whole dictionary definitions in them.
Too much functionality: We add a link to full definitions, but this is hard to get to and not explained.
No MWC: the MWC does not have a tooltip candidate, and even the more advanced parent project lacks it.
A better way: use MD “bottom sheet”
A bottom-sheet is similar to a tooltip in that it appears for displaying transient information. However it differs in that it is attached to the bottom of the screen, rather than floating around, and contains rich information. Typically on a mobile a bottom-sheet might fill a third of the screen or so.
(In fact it is similar to how the editing window here on Discourse works.)
We can use this to display the dictionary lookup information. This will effectively be identical to the “dictionary preview” card that is displayed at the top of search results.
This means we can reuse components.
Activate it
The sheet can called by first turning the lookup on, then highlighting a word.
Interface is the same for desktop and mobile: just highlight a word.
Lookup only works for a single word. If user highlight many words, only look up the first one.
The sheet should be persistent: Once activated, keep it until dismissed by the user.
Navigate
User has prev/next arrows, similar to the prev/next arrows for suttas.
The “next” arrow is conveniently located by the user’s thumb on mobiles.
Touch target is large and static. Just keep clicking or tapping on the same spot to go through words.
Interface is identical for desktop and touchscreen.
Should also support keyboard navigation for desktop.
Current term is identified by both color and border
User can click to go to relevant /define/ page for full entries. (This is currently the case on the tooltip also, so the data is already there.)
Bottom sheet can be dismissed by swiping or clicking a down-arrow (not shown)
Bottom sheet is full width
Implementation
There is no bottom sheet in the MWC components, nor in the parent project. So in this respect it is no better than a tooltip. So we shall either have to find another source or roll our own.
Height of dictionary section will vary depending on entry length, we will need to consider how to handle this. Perhaps we will have to have a fixed height allowing for say three lines, then scroll to see more; however, it will not often happen that a user needs to see more.
Currently the lookup requires inserting <span class="word">Evam</span> on each word. On a text the size of the Mahaparinibbana Sutta, that’s a heckton of DOM! Will this still be necessary?
Nice! One bug that’s annoyed me a lot on iOS is that enabling this feature sometimes makes it impossible to highlight text! Hopefully this approach will fix that.
I did have one question about the design: the left/right arrows are a bit unclear. Do they display the definition of the previous/next word in the case where you’ve highlighted a phrase?
That’s right. You highlight a word, then the arrows move to the previous or next word, highlighting each one in turn. We should probably put a label on the arrows to make it clear.
If I’m getting this right, the main issue is with touch devices, and not on Desktop, right? (since Desktop seems great the way it is)
You mentioned 50% of your users are on mobile. Are there statistics on how many of those users even have Pali opened?
Just for a use-case from touch devices: I only use mobile devices to quickly check out a Sutta. I may check the Pali if I want to make sure a translation refers to a particular thing I know in Pali (e.g. is “absorption” Jhana or something else in this context?)
If I want to actually check the dictionary definition of Pali words, I’ll be on Desktop, with multiple tabs open, looking up different translations of that Sutta, and other Suttas where that word appears. I can’t imagine how doing this on mobile can be convenient, no matter how awesome the system is…
But, I’m just one user, others may use mobile differently. And they may use it more on mobile, if this works differently.
Either way, keep up the great work with this website!
That’s one issue. There are a whole range of problems with tooltips, some to do with the specific mechanism, others to do with the basic idea. Tooltips are also bad for:
People with motor-function problems
People with visual difficulties
Developers. Seriously, tooltips are one of those little things that are trivial to do badly, and really hard to do well. Which is why the developers of the main libraries on which we rely have not built them. And when/if they do build them, they will almost certainly not work properly for us, because we use them in improper ways. So we would have to make our own or hack a third party library (which is what we do currently).
Well, it’s kind of a chicken and egg thing. The bottom line is: we aim to provide full support for mobile and other touchscreen users.
I love the bottom sheet idea. However, I would prefer to click on a collapsed bottom sheet to open it if I wanted to look up a word. Then, if the bottom sheet is open I can look down for each word that I touch or simply close the bottom sheet to continue reading. This way I don’t have to change my settings for reviewing vs. study.
Yes, that sounds reasonable. I haven’t looked into usability patterns for bottom-sheets yet, though as usual the Material Design guidelines are a good start.
The dictionary must be explicitly enabled by the user for the first time. This is because the dictionary is about 2MB. And there are multiple dictionaries. Once the user has requested it, we should indeed make sure they can get it when they want. Perhaps there can be a pull-up sheet, and if the dictionary is not in cache, there’s an option to start it from there.
Once the setting is enabled, It would still be good to open/close (P1) and/or resize (P2) the bottom sheet so that the user could manage screen real estate in order to easily switch between reading, scanning and lookup. The current popup on hover makes it really hard to lookup a single word in a large paragraph–I have to dive onto the word threading an uncertain trajectory through the other words trying not to trigger their definition. The bottom sheet solves that problem (P0) very nicely so that the annotations do not disrupt the actual hovering.
P0: critical
P1: really helpful especially on mobile
P2: nice
so arahaṃ 
