-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New popup position means popup position varies based on size of popup #756
Comments
Yes, I've noticed this too and I tend to agree. The reasoning for the change is to try to do a better job with touch screen devices where you can't just scroll by spinning the mouse wheel.
Honestly I don't recall how the old popup positioning worked exactly because we certainly put the popup above the text sometimes but I'll have to look up exactly what those circumstances were. I tend to think that original heuristic worked pretty well. At very least, I think we should probably avoid putting the popup on the side as I mentioned in #752 (comment)
We definitely want to add the scrollable part, at least for touchscreen devices. Making the scrolling work for mouse users will be a bit harder but is something we want to do eventually.
Yes, I'll look into making the positioning a bit more compatible with what we used to have. Note that there is the option to turn on the j / k keys so you can force the popup to always be in, e.g. the bottom right, but that probably doesn't do exactly what you want. /cc @shirakaba |
I don't know how the code worked directly, but my guess based on my experience was that it preferred to put the pop-up below unless both were true:
My experience was that as long as the text I was highlighting was in the top half of my screen (so there was always more screen space below) then the popup would always appear below. |
Yeah, you're right. It would choose the side based on which one has more room: 10ten-ja-reader/src/popup-position.ts Lines 150 to 165 in 5465c00
Whereas now we do it based on the area of the popup (at least in the case where we find there's no unconstrained position in the block direction). I'm not sure what will be best for smartphones and other touchscreen devices but at least for mouse-based desktop devices I think we probably want to alter the behavior to:
|
Just fiddling with my iPhone it doesn't ever seem to use the inline positions (left/right) so I wonder if we really need those after all. If we dropped them, we could possibly drop the complicated code we have to make sure we don't overlap the text on left/right. |
I'm going to give @shirakaba a chance to chime in before jumping in to this but I agree this is a regression we should fix as soon as possible. |
This will tend to work fine on tall, narrow, windows, but on wide, squat screens (e.g. landscape on a phone, although I’ll admit not many people browse the internet like that often), we do need left/right sides as an option.
Not quite sure how this will differ from our area-based selection, particularly as we reserve extra space above/below to dodge the thumb. I can probably think about it more after I’m back home. |
@nlgiles Thanks for the report – maximising readability is a top concern. Note that in the below comments, I'm thinking principally about horizontal text and laying out the popup above vs. below, and am not really thinking much about laying it left vs. right and considerations for vertical text. The broad aimI think @nlgiles's sentiment is broadly that we should aim to keep a constant reading line each time the popup appears? i.e. each time the popup appears, we don't want to have to search around with our eyes for where the first definition starts. The original layout behaviourI'm actually surprised that this was ever achieved with the old layout code, but as @nlgiles confirms:
Indeed, when the popup spawns below, it keeps the same reading line. So given equal or unlimited space on each side of the lookup position, spawning below should certainly be preferred. Considerations for mobile devicesUnfortunately, on mobile devices, window space is very limited, and often we have no choice but to place the popup above the lookup position. Moreover, whenever the popup is placed below the lookup position, in practice, we need to spawn the popup at an offset to get out of the way of one's thumbs. So on small screens, spawning from the top is more of than not the only viable option. Keeping a consistent reading lineon small screensI can see the appeal, on small screens, of – whenever spawning the popup above the lookup position – always hanging it from the top of the window (well, below the safe area insets, that is). And in cases where we have no choice but to spawn the popup below the lookup position, then we can hang it from the lookup position (plus the thumb clearance and line clearance). But if we did hang it from the top of the window, although it would mean a consistent reading line, it would also mean further eye-travel. I wouldn't personally want to dart my eyes back and forth between the target sentence and the top of the window, even if the reading line were consistent (my iPhone 11 Pro has a rather tall screen). on large screensThis is essentially a reiteration of what I've already mentioned for small screens. It's just that you more often have multiple options for where to lay out the popup, rather than only one viable option. We can't solve all cases, but we can reverse the regression
So there's no good solution for improving the reading line of the popup when placing the popup above the lookup position. However, it sounds like the old behaviour was simply to prefer placing the popup below the lookup position, minimising the eventualities in which the "above" position would be presented at all. So maybe the best we can do here is adjust the priority order to ensure that "below" is preferred instead of "above", at least for non-puck users. As mentioned earlier, for puck users, preferring "below" is less viable because there's simply less space available below (due to thumbs and the iOS 15 safe area insets), and so more often than not, you'd get small popups appearing below and large popups appearing above, meaning that all the efforts towards keeping a consistent reading line would backfire. How about that solution (the sentence in bold), then? |
Thank you for giving so much thought to this. When I created this issue I hadn't thought about the complexities of small screen sizes, personally I don't use 10ten on a phone or tablet so I don't think I can give the best feedback about that.
Thank you for bringing this to my attention, I've tried using to force the pop-up into the top-left corner of my screen. You're correct that it's not my preferred solution but I didn't know about it before.
I've tried to gather up how I feel about this and summarize it. I'm going to start by assuming I'm always talking about horizontal lines of text as opposed to vertical lines as that's what I normally read, I don't know how my feelings would generalize to vertically oriented text. I think that when the popup is being positioned relative to the text, its for the best that it is either entirely above or entirely below the text, and not to the left or right of the text. I think this was the the previous approach to popup placement. This approach maintains a constant reading line below horizontal text if popups appear below, but also can utilize the space above the the highlight when the highlight is in the bottom half of the screen. With the current approach, popups are placed to the right or left of the highlight if the content in the popup would be too large to fit either above or below the highlight. When this happens the popup extends both above and below the highlight. This means the popup is larger than half of the height screen, often the entire height of the screen, at which point I feel like we've made a category error somewhere. A popup that covers more than three-fourths of your vertical screen space is more like it's own separate page at that point. Rather than having popups that large, I think it's at least acceptable and in many cases desirable to have the popup be limited to the space above or below the highlight, which is always at least half of the available vertical space. Then, for users that need to see the clipped bottom part of the popup there could be a feature to make popup content scrollable. Perhaps there could also be an option to enable/disable the ability for popups to appear left/right of the highlight when they do not fit entirely in either the above or below space instead of clipping them. For users on devices where that is not enough screen, placing the popup to the right or left of the highlight doesn't seem like it would fix the problem because if there is only enough screen space for a few lines of horizontal text, you still won't fit much of the popup on screen I think? Those users would probably want a solution where the popup always appears in a corner of the screen I think? |
I'm cautious of speaking too severely on this issue because I'm not aware what drove the initial change to popup placement in the first place. Ultimately, 10ten popups vary heavily in how many lines of text they contain. When highlighting a noun expressed with a small number of kanji characters and only a few meanings, there may only be a few definitions and the popup height is short. This popup will appear either above or below the highlight. When highlighting a hiragana phrase or a phrase with many connations, you get definitions for all substrings, sometimes including at the very bottom definitions for just the first hiragana character. This popup can be massive and take up the entire vertical height of the screen, moving the popup to the left or right of the highlight. The result is constant change of where the popup appears as you move between large and small popups, even when the highlight text is in the same area of the screen. Having my eyes jump back and forth from popups at the top of the screen to popups below the highlight, despite the highlights being in the same area of the screen, feels mentally confusing. |
Thanks @shirakaba and @nlgiles for your very thoughtful consideration of the issues here. Here are my takeaways:
Before making any suggestions, a little background on my understanding of that second point regarding where we are and how we got here:
My suggestions are:
So perhaps we could say something like, if the screen has more room in the inline direction than the block direction and the block extent is less than, say, 500 pixels, add the inline positions as candidates?
Let me try turning that into a PR anyway and see what it looks like. |
See summary of approach here: #756 (comment)
I ended up spending nearly all day on this but I think I came up with something that harmonises the old with the new over in #759. The key trick turned out to be changing when we revert the Still it's a pretty big patch because I also decided to generalise a fair bit of the positioning code. In my testing so far, however, it seems to do the right thing. |
See summary of approach here: #756 (comment)
See summary of approach here: #756 (comment)
After an update to the popup positioning, the popup now gets shifted up or down to try to fit the whole thing on screen. I get the reasoning behind this, but in some of my use cases it's quite troublesome. When using 10ten to highlight multiple words in a sentence, the position of top of the pop-up changes wildly from word-to-word, meaning the on-screen location of the top-most definition changes. For example, if you are highlighting several words all on the same line of text in the middle of the screen, as you move from one word to the next, the position of the top-most definition on the screen can vary from below the highlighted word if the whole box fits below the word, to the top of your screen if the box is big enough to fill the screen. This gives me a very cumbersome feel when I highlight a word in the middle of my screen and the top-most definition appears in a wildly different place on screen each time. Its extremely noticeable when I pass over particles while moving my mouse from one word to another because almost all particle popups are huge and fill my screen top to bottom. Before this change I would just always read text in the top half of my screen and the popup would consistently appear in an expected place beneath the highlighted words.
I think the best solution would be a scrollable popup with the same positioning code as before, so that when the popup is too large you can hover it and scroll down, but I think that might be troublesome. I would appreciate if if there were an option to force the popup to always appear below/right of the word being highlighted even if that causes the popup to get cut off, or at least just an option to use the old positioning code.
The text was updated successfully, but these errors were encountered: