Zoom option for panels

[balmas]

Offer a "zoom" option for each tab in the Alpheios panel to enable popping a particular view out to full screen with pinch, zoom and pan support.

[kirlat]

Should we use just gestures for zoom or should we also provide some additional controls: zoom in or zoom out buttons and maybe a zoom slider?

I'll check into a custom implementation of pinch zoom. The problem could be that we need to recognize several touches simultaneously. Hopefully it won't be too hard.

[aniseferreira]

Some inflection tables may need more room to zoom out perhaps.

[balmas]

Moved this issue from the pwa-prototype. We need this in the new mobile panel. (see also comment at https://github.com/alpheios-project/components/pull/474#issuecomment-487057306)

[kirlat]

@balmas, I've added support for the pinch-zoom to the mobile version of the panel. Please review it @ http://embed.yula.media/demo/ when you will have time.

I will start working on the button that will maximize the panel size on mobile so that the panel will take all available screen space. I think this will be very useful for working with complex panels such as inflection tables.

[balmas]

can be tested in 1.0.0.9 (but see #397 for some open issues)

[monzug]

here are my findings: tested in 1.0.0.9 on Samsung 5s (will check iPhone 6s later)

• it's easier to zoom in than zoom out. zoom out takes more time to apply. this is valid for each tab.
• in inflection table, the footnotes act funny. if enlarged, sometimes the close button goes under the footnotes title and there is no way to close the pop-up except to reduce the size. also there is some flickering with the font: if the finger is close to the footnotes without touching it, the font goes from bold to normal. this is more visible in normal view rather than landscape.

[balmas]

it's easier to zoom in than zoom out. zoom out takes more time to apply. this is valid for each tab.

This was my experience too.

[kirlat]

I think footnotes, as they are now (as popups attached to the host cell) are not very suitable for mobile UI, especially when scaled up. If not scaled, they are too small to by manipulated with fingers. When scaled up, they might take too much screen space at the center (usually) and will hide most of the table behind them.

Probably a footnote attached to the bottom of the screen will be a better alternative: We will loose an ability to keep the footnote displayed near the host cell, but that's probably not a big deal since a host cell has a footnote number and that number is part of the footnote itself. Also, we could highlight a cell with the currently opened footnote to make it more noticeable.

Also, we will not be able to open multiple footnotes at once as on desktop, but that's of no use on mobile anyway because there is so little screen space available.

On the plus side we will get plenty of space to display the footnote itself, along with its close button that is large enough to be an easy to use target. Located like that at the bottom, footnote will be easier to read too as they will be wider and have less line breaks.

Please let me know what do you think. Thanks!

[kirlat]

I need to confirm this, but I suspect our current delay during zoom in and zoom out is related to our current architecture when the table itself is rendered when the inflections view is shown. This process is controlled by the Vue's v-if statement. As a result, the table and the view are recalculated every time we're changing the scale. That's why zoom in is faster: it probably has less data to render.

I'll do some tests to verify this hypothesis.

[balmas]

I agree that on mobile, displaying the footnotes at the bottom makes more sense (if the inflection tables as they exist currently even make any sense at all on mobile -- this is is something we really need user feedback on)

[kirlat]

Any possible performance issues are not related to the inflection table rendering. We render the table that is opened by default when morphology results are displayed in the Morphology panel, and if there are any other inflection tables available, they are rendered after we choose a different table from the drop down. Each table is rendered only once. Zoom does not cause any table to be re-rendered. We're good here.

Will investigate further.

[kirlat]

From my tests it's seems that it's the redraw cycles caused by the zoom change one after another are making zoom sluggish. I've made a change to reduce the number of redraws by applying a zoom change only when it's effect will be noticeable enough. It did make the zoom process more responsive in my tests. Let's see how it will behave on the whole range of test devices. Depending on that, we can tweak it further, if necessary.

[balmas]

ready for retesting in 3.0.0.33/1.0.0.11

[monzug]

I can confirm that zoom in and out is more responsive. see my findings: 1) samsung 5s mini - it work well in both normal and landscape view, zoom in and out on different tabs is ok, footnotes are displayed at the bottom of the screen (in landscape view, it's basically next to the footnote number in the text). only in Grammar I could not zoom in and out. @kirlat, is this due to the zoom change that you have applied to reduce the number of redraws? 2) iphone xr - click on footnote, it brings me back to top of the screen with no visible footnotes. in landscape view, if I zoom in to the max level, I see a black stripe and I can't zoom out, I need to close the popup. 3) iPhone 6s - all good. the footnotes popup opens at the bottom, you need to scroll down to see it.

[kirlat]

only in Grammar I could not zoom in and out. @kirlat, is this due to the zoom change that you have applied to reduce the number of redraws?

No zoom in Grammar is an expected behavior, unfortunately: this piece is shown within an iframe. Its styles are defined by the source from where it is loaded, and they are not allowed to be changed in modern browsers due to security restrictions.

I think the performance increase should be due to the changes I've made (at least I hope so) as they, depending on the zoom speed, can provide up to several times better performance (the slower the zoom is, the greater effect will be), and I'm glad to hear that it is working.

iphone xr - click on footnote, it brings me back to top of the screen with no visible footnotes. in landscape view, if I zoom in to the max level, I see a black stripe and I can't zoom out, I need to close the popup.

Unfortunately I do not have an iPhone XR to reproduce. Would it be not too hard for you to attach several screenshots (or better yet, a video, if possible) of the sequence? Maybe I'll be able to guess what's going on by looking at that.

There are two different zoomings in place. The first one is a custom one of our own. It works when one zooms within the panel. It should not increase the size of the panel but rather change the size of the text inside it (except for the Grammar panel).

The second one is implemented by the browser. It works when one zooms over the page content (not over the panel). This one increases the size of text on the page, the size of the page itself and the size of the panel (all proportionally). If to zoom this way in all the way up, the panel will become so big that it will occupy the whole viewport and it will be impossible to zoom out: all zoom will happen over the panel and will be applied to the panel's content, not to the size of the page and the panel itself. However, it should be possible to scroll so that the portion of a page become visible, and then zoom out over that. It should reduce the size of the panel.

Because of this it sometimes can be important to specify what kind of zoom was used during a particular test.

I see that zooming too much can create some serious issues with usability. I'm wondering if it will be beneficial to limit the maximum zoom level. The problem, however, is that if we try to apply it to the page itself, we will be interfering with the intentions of page designers. It is usually considered a bad practice and I'm not sure if we should go this way. We can also be mistaken in determining the max allowed zoom level and this might kill the usability.

I'm wondering what's the best approach we can take to prevent issues like that.

[monzug]

@kirlat, I'll try to take a video and also screenshots. will do tomorrow morning.

[kirlat]

@kirlat, I'll try to take a video and also screenshots. will do tomorrow morning.

Great! Thanks, @monzug!

[monzug]

@kirlat, I am not done yet trying to track down the issue. I want to show you two screenshots: 1) the black stripe after zooming in 2) it's the footnotes in landscape view

about footnotes: in normal situation, I can see the footnotes. as soon as I start zooming in and out in other and current panel too, when clicking on the footnotes number, it takes me to the top of the screen. about the black stripe: I have seen it twice when I zoom in from word usage examples (without getting results) and then I go to Browse Inflection tables. the zoom in is still on in the new panel, when I zoom in more then I get the black stripe. also, when I lookup for a word from Define in landscape view, then the zooming capability is frozen. again, I am not done yet but I still have some errands to run.

[kirlat]

Thanks for the update @monzug! I will try to model the situation and understand what might be causing this.

[kirlat]

@monzug, the fact that it is showing a panel at the center in the landscape mode is probably an indication that an orientation detection fails. If so, this is a clearly defined problem we should solve before doing anything else. Some other misbehavior may be caused by it.

I've also tested some tricks to control the page scale on mobile and that might actually work and be helpful to us, but we need to test if and how well it will work on all different devices.

So I think our best approach would be for me to prepare a test version of the page that will report page orientation and have some zoom control features for testing and then we run it on all devices in our disposal. If results be mostly positive, I'll integrate that into the code and we can build our UI logic upon that.

Does it makes sense? What do you think?

Then it probably makes no sense for you to continue testing this issue before the "feature detection" is complete: it might point us to something more obvious things that we might, and should be able to solve before anything else.

[monzug]

yes, I am ready to test your fixes anytime. I have spent quite sometimes trying to find a reproducible scenario with no much success, unfortunately. it works well enough and then you get the black stripe or everything freeze.

On Wed, May 15, 2019 at 11:45 AM kirlat notifications@github.com wrote:

@monzug https://github.com/monzug, the fact that it is showing a panel at the center in the landscape mode is probably an indication that an orientation detection fails. If so, this is a clearly defined problem we should solve before doing anything else. Some other misbehavior may be caused by it.

I've also tested some tricks to control the page scale on mobile and that might actually work and be helpful to us, but we need to test if and how well it will work on all different devices.

So I think our best approach would be for me to prepare a test version of the page that will report page orientation and have some zoom control features for testing and then we run it on all devices in our disposal. If results be mostly positive, I'll integrate that into the code and we can build our UI logic upon that.

Does it makes sense? What do you think?

Then it probably makes no sense for you to continue testing this issue before the "feature detection" is complete: it might point us to something more obvious things that we might, and should be able to solve before anything else.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/alpheios-project/components/issues/482?email_source=notifications&email_token=AJ32UONKGFPSOUMM4PYQVTLPVQV2HA5CNFSM4HIXNQCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVPCVJY#issuecomment-492710567, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ32UOKIUED35SBD42XH3IDPVQV2HANCNFSM4HIXNQCA .

[monzug]

one more side effect of zooming: can't scroll the results of word usage examples in landscape view see screenshot (zoom in and zoom out)

[kirlat]

@monzug: I've made a special version of an embedded lib page to test recognition of mobile devices' capabilities. This page is located at http://embed.yula.media/demo/.

It has a special header to prints out information in a cryptic form like below:

The first bluish panel prints out the device information: PT (platform): whether the platform is recognized as mobile or desktop OR (orientation): portrait or landsape DPR (device pixel ration): how many pixels on the device matches on logical CSS pixel OR.SUPP (orientation support): whether this device support an API for changing screen orientation SCR (screen): a screen size in CSS pixels. SCRxDPR should give a physical screen resolution of a device. INNR (innerWidth): a window.innerWidth dimensions. Should be smaller than screen because of the toolbar and (if any) scrollbars. OUTR (outerWidth): window.innerWidth dimensions.

The next silver panel lists calls of callbacks that are activated when device orientation is changed from landscape to portrait and vice versa. or.chg is a callback for orientationchange event, and rsz is a callback for resize. Some device support both, some - resize only.

The next three button activates forced orientation change, if the device supports it. When clicked, it should put a page into a full screen mode in a proper orientation. Reset should return device back to what it was.

Three buttons at the bottom allow to test the zoom control.

The idea is to test as many devices as possible and record whenever something is not working or if parameters are not determined correctly. We also should decide if zooming and manual orientation change as implemented on this page is usable (and useful) for us and our users.

@irina060981, can you please test it on your devices too, if you will have time?

Thanks!

[monzug]

@kirlat, what a cool tool you have put together! so, I used it on my Samsung 5 mini, it does support both call to resize and orientation change. zoom in and out did not work. Note that I had reported no issues on zooming in and out on samsung. see screenshot

[monzug]

iPhone xr. see screenshots: zoom in, zoom out and normal view

[monzug]

iPhone 6s will follow

On Thu, May 16, 2019 at 9:04 AM kirlat notifications@github.com wrote:

@monzug https://github.com/monzug: I've made a special version of an embedded lib page to test recognition of mobile devices' capabilities. This page is located at http://embed.yula.media/demo/.

It has a special header to prints out information in a cryptic form like below: [image: image] https://user-images.githubusercontent.com/18631055/57854892-62862a80-77fa-11e9-86f0-b708e14ede77.png

The first bluish panel prints out the device information: PT (platform): whether the platform is recognized as mobile or desktop OR (orientation): portrait or landsape DPR (device pixel ration): how many pixels on the device matches on logical CSS pixel OR.SUPP (orientation support): whether this device support an API for changing screen orientation SCR (screen): a screen size in CSS pixels. SCRxDPR should give a physical screen resolution of a device. INNR (innerWidth): a window.innerWidth dimensions. Should be smaller than screen because of the toolbar and (if any) scrollbars. OUTR (outerWidth): window.innerWidth dimensions.

The next silver panel lists calls of callbacks that are activated when device orientation is changed from landscape to portrait and vice versa. or.chg is a callback for orientationchange event, and rsz is a callback for resize. Some device support both, some - resize only.

The next three button activates forced orientation change, if the device supports it. When clicked, it should put a page into a full screen mode in a proper orientation. Reset should return device back to what it was.

Three buttons at the bottom allow to test the zoom control.

The idea is to test as many devices as possible and record whenever something is not working or if parameters are not determined correctly. We also should decide if zooming and manual orientation change as implemented on this page is usable (and useful) for us and our users.

@irina060981 https://github.com/irina060981, can you please test it on your devices too, if you will have time?

Thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/alpheios-project/components/issues/482?email_source=notifications&email_token=AJ32UOIBN7QEIPQNVXI545TPVVLXFA5CNFSM4HIXNQCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVRXWPQ#issuecomment-493058878, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ32UOO23W2CMGYZQER63DLPVVLXFANCNFSM4HIXNQCA .

[kirlat]

Phone xr. see screenshots: zoom in, zoom out and normal view

@monzug, can you please rotate it back and forth a little to see what callbacks are called then?

Please note that the resize callback is called for both zooming and orientation changes. So if we want to check what callbacks react to orientation changes we should avoid zooming during this test.

[monzug]

ok. if I move the screen in landscape view, I get or.chg rsz and back to normal view an other set of or.chg rsz. if I slightly move the screen on the left or right, orientation cbs does not change

On Thu, May 16, 2019 at 9:45 AM kirlat notifications@github.com wrote:

Phone xr. see screenshots: zoom in, zoom out and normal view

@monzug https://github.com/monzug, can you please rotate it back and forth a little to see what callbacks are called then?

Please note that the resize callback is called for both zooming and orientation changes. So if we want to check what callbacks react to orientation changes we should avoid zooming during this test.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/alpheios-project/components/issues/482?email_source=notifications&email_token=AJ32UOO5AQO5VIBXKRVKEATPVVQQTA5CNFSM4HIXNQCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVR3LRA#issuecomment-493073860, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ32UOPX6ZOYY6XL5H2N5PLPVVQQTANCNFSM4HIXNQCA .

[monzug]

iPhone 6s: zoom in and out worked, orientation not supported

[irina060981]

I am not sure, I have understood everything correctly - but here it is And it is the first time I see normal font size in the panel on mobile! I have Samsung A5(2016)

[irina060981]

[irina060981]

[irina060981]

I have opened in portrait, opened grammar tab - zoom is not working (on the page - it is working)

@kirlat, What should I check here else?

[kirlat]

And it is the first time I see normal font size in the panel on mobile!

This is because we now have <meta name="viewport" content="width=device-width, initial-scale=1"> at the beginning of the page. It tells browser to set page width equal to the viewport's and assign 1 to the scale (i.e. enforce no zooming). So if it's Samsung Samsung A5(2016) in portrait, the page width will be set to be 360px (equal to the screen width of 360 CSS pixels). If turned to landscape, the page width will be adjusted to 640. Because of this, no browser scaling occurs and we see fonts and UI element 1:1.

Without this meta element the page width will be set to 980px (that's the usual default for many browsers, but it may vary). Because the viewport width is 360px in CSS pixels, the browser will try to fit a 980px page into a 360px space. As a result, everything will become smaller because the page has to be scaled down.

The problem, however, is that this meta directive on the host page is the only way to set the zoom level and the page width I know of. And the host page does not belong to us. So it can have no meta element at all, or a meta element with parameters different from what's listed above. The page author may choose to display the page scaled intentionally. Problematic part is it will affect both the look of the page AND of our extension/embed-lib too: zoom will be applied universally to all page elements, and our elements belong to the page too.

We can change the viewport meta parameters of the page by injecting our own values (that's what Zoom in and Zoom out buttons do), but I don't know if it will be too invasive or not. Page owners may not like it (but we can make it a configurable option).

The other option would be, knowing the host page's width and the viewport size, adjust the size of the text and UI elements within the panel (with CSS vars) to achieve the same font size look, but this will require a lot of testing on different devices: there are so many possible phone/OS/browser combinations out there, and they all differ a little or a lot.

@balmas, what do you think?

[balmas]

The problem, however, is that this meta directive on the host page is the only way to set the zoom level and the page width I know of.

For now, this really isn't a problem. For as long as the browsers don't support webextensions in their mobile versions, we won't have the ability to provide the alpheios mobile functionality on ANY page, only on pages that use the embedded library and host the content themselves. So we can make that change when we use the embedded library on the pages that belong to us (i.e. in alpheios_nemo_ui) and advise other users of the embedded library to do the same, and not worry about the rest for now.

Does that make sense?

[balmas]

Here's the results on the Samsung Galaxy 7

Callbacks supported or.chg.rsz and rsz All buttons functioned

One weird set of behavior:

• If I physically change the orientation to landscape by rotating the phone, , after changing back to portrait the popup did not reposition itself to the bottom of the screen and stayed on the left side. I had to reload the page to get it to go back to the bottom.

• on the other hand, if I change the orientation to landscape using the button (but keep the phone upright), the panel stays on the bottom and then when I use the portrait button to switch it back to portrait, the panel suddenly appears on the left.

[balmas]

@kirlat note that on the Samsung Galaxy Note 8, when you switch to landscape it thinks we are on the desktop

[kirlat]

Thanks for the note, I've updated detection algorithm to fix this

[balmas]

@monzug the fixes for orientation detection are in 1.0.0.14 up now in the texts-beta environment

@kirlat and I discussed today whether we should try to do more, such as adding UI buttons for manual zoom or manual orientation shift. We decided to leave it as is for the moment pending additional user feedback. Hoping that these changes fix at least some of the projects you have on the iPhone XR and @abrasax has on the Galaxy Note 8

[monzug]

tested in 1.0.0.14 in Samsung 5 mini and iphone xr, confirm what @balmas has reported above: when changing view from normal to landscape and then back, the popup is on the left side of screen and the arrows are left/right to move on screen and not top/bottom. need to reload to go back to popup on the bottom

iphone xr: unfortunately I still have problems with footnotes in landscape view. it just moves at top of popup. note that it works fine in portrait view. also, I got again the black stripe when zooming in in Inflection tables (testing the footnotes) and a blank screen when zooming in in Lemma, then the popup froze and needed to reload. when zooming in and out a lot in landscape view, the zoom functionality becames unstable.