Closed Bug 1193633 Opened 9 years ago Closed 4 years ago

Close Zoomed View after user clicks a link

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Version:
42 Branch
Platform:
All
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: antlam, Unassigned)

References

Details

Continuing the discussion that started in bug 1170713. > After a user takes an action inside the zoomed view, it should close. Reason > being, the purpose of the zoomed view is to disambiguate links. Once that > purpose has been served (i.e. a clear tap/press has been triggered), it > should close. I can see how there might be issues around collapsible menus and such but I think that's not an assumption we can make. Essentially, we are looking to disambiguate a press. So this should only show up if there was a press. After it's launched and the user uses it, it should close because it's served it's purpose. It's also weird because maybe what showed up (after the first press) doesn't need it.
(In reply to Anthony Lam (:antlam) from comment #0) > Essentially, we are looking to disambiguate a press. So this should only > show up if there was a press. After it's launched and the user uses it, it > should close because it's served it's purpose. > Nothing to do here; click on a link in the zoomed view ( the classic <a href='http:// ...), the zoomed view is closed and the new page is loaded. > It's also weird because maybe what showed up (after the first press) doesn't > need it. With the close of the zoomed view on other cases, it's also weird because maybe what showed up does need it. From the first design of the zoomed view, it has been decided that the zoomed view is used for cluster of links but also for small elements in html form. Read back the original design if you need again to understand this user case.
(In reply to Dominique Vincent [:domivinc] from comment #1) > (In reply to Anthony Lam (:antlam) from comment #0) > > It's also weird because maybe what showed up (after the first press) doesn't > > need it. > > With the close of the zoomed view on other cases, it's also weird because > maybe what showed up does need it. Yes, that's exactly what I mean :) > From the first design of the zoomed view, it has been decided that the > zoomed view is used for cluster of links but also for small elements in html > form. Read back the original design if you need again to understand this > user case. I understand the user case just fine. But I think we miss an opportunity by keeping the view open when users don't need it though. As long as it closes after an action has been taken inside the view, then that's OK.
NI-ing to get going on something here
Flags: needinfo?(michael.l.comella)
Flags: needinfo?(domivinc)
Anthony, I have already discuss the opportunity to close the zoomed view after an action here: https://bugzilla.mozilla.org/show_bug.cgi?id=1170713#c3 The code change has been implemented in the patch attached to the bug. There is also an APK attached to the bug The conclusion of this work is that this behavior is not good from the user point of view in all the pages. Please, take the time to read the comment, install the APK and load the sample page to see that the behavior you want doesn't work on the sample page. You have to follow the 3 steps to open a sub-menu ... The current behavior close the zoomed view when the click occurs on a "normal" link. It seems to cover the main user case. In all the other cases, the user has the choice to keep it open or close it. Now, if you have new ideas to get a correct and automatic behavior in all the cases, we can try to improve the current code. You can start to work on a design that should work on the sample page where the "automatic" close doesn't work. The starting point is: how can we decide to close or not to close the zoomed view automatically?
Flags: needinfo?(domivinc)
Flags: needinfo?(michael.l.comella) → needinfo?(alam)
(In reply to Dominique Vincent [:domivinc] from comment #4) > Anthony, I have already discuss the opportunity to close the zoomed view > after an action here: > https://bugzilla.mozilla.org/show_bug.cgi?id=1170713#c3 > The code change has been implemented in the patch attached to the bug. There > is also an APK attached to the bug > The conclusion of this work is that this behavior is not good from the user > point of view in all the pages. > > Please, take the time to read the comment, install the APK and load the > sample page to see that the behavior you want doesn't work on the sample > page. You have to follow the 3 steps to open a sub-menu ... Domivinc, I understand what you mean by it "doesn't work on the sample page". But understand that there is not going to be a single solution here that will solve the issue for "all the pages". While, I know that it's not perfect for this specific website, keeping this magnified UI open from a UX point of view, just gets in the way for everyone else. I would like to opt most users into a better experience, and not the other way around. Also, I do not see all the bugs unfortunately. Please CC me, or :kar, or :bbermes on them (I have already done so in most of these by now). > The current behavior close the zoomed view when the click occurs on a > "normal" link. It seems to cover the main user case. In all the other cases, > the user has the choice to keep it open or close it. I believe in user choice. But this about "getting out of the users' way". Due to the ambiguous nature of "just working" as one of the criteria for success here, I think we should lean towards a more conservative approach (at least initially). That being said, I think this UX still needs to dismiss the view once it has been used. If the user "needs it" again, they "tell us" by tapping anywhere. But we simply do not know if the user "needs it" and cannot assume they do by persisting this around. Regardless, the idea here is the same - to get out of the users way.
Flags: needinfo?(alam) → needinfo?(domivinc)
(In reply to Anthony Lam (:antlam) from comment #5) > > That being said, I think this UX still needs to dismiss the view once it has > been used. If the user "needs it" again, they "tell us" by tapping anywhere. > But we simply do not know if the user "needs it" and cannot assume they do > by persisting this around. The problem in your design is that the user cannot "tell us" by tapping anywhere to display again the zoomed view. Is this way to open the zoomed view has been implemented recently? On the first versions of the zoomed view, this action was a long press on an empty area. But it has been removed. Testing with the last nightly build the zoomed view is still displayed only after an ambiguous click/touch. The user cannot decide to display the zoomed view using a specific action. By definition, the user cannot know in advance if the touch will be ambiguous or not. In your design, after the automatic close, the user will have to try to make a second ambiguous click in order to re-open the zoomed view because he needs it. And if the user is lucky, the zoomed view will pop-up. And if the user is unlucky, an unwanted action will be done in the page. This is an annoying behavior for the users working in the zoomed view. And we will have to fix it. The iPad magnifying glass doesn't work like that. My guess is that iOS designers will never change that for the previous reason: they don't want to annoy their users! With the iPad, when the user decides that the magnifying glass is no more needed, the user can close it. The iPad doesn't take automatically a decision without the user point of view. It seems obvious to me that it's the best way. Another point you should take into account in your design, the zoomed view is not only "links" oriented but it's also used with form elements. For each radio buttons or check-boxes in a form the user will have to re-open the zoomed view after each automatic close? It won't be user friendly.
Flags: needinfo?(domivinc)
I think we're roughly looking at this from two different perspectives: 1) A tool to reactively deal with ambiguity, e.g. from fat-fingering 2) A tool for users' to proactively prevent ambiguity, e.g. as a user, I want to magnify this before I press it Initially displaying the zoomed view is inherently #1, but for continued actions, I think antlam supports #1 and Dominique is supporting #2. Perhaps we should have this discussion? Notes: * The tool was envisioned as #1 to create parity with Chrome but that isn't the way it has to be, particularly if iOS does something different (Anthony, have you seen this behavior?) * #2, at least for seeing-impaired users, can be fixed by the Android system zoom accessibility tool, so perhaps we don't want to step on their toes * If we have a method of displaying the zoomed view manually (e.g. better to solve #2), there would be more incentive to close it after clicking inside it once when it appears automatically (In reply to Anthony Lam (:antlam) from comment #5) > > Please, take the time to read the comment, install the APK and load the > > sample page to see that the behavior you want doesn't work on the sample > > page. You have to follow the 3 steps to open a sub-menu ... If we're solely solving fat fingering, each click may not be ambiguous and will not always bring up the zoomed view, but if we're trying to solve more than fat fingering, maybe the zoomed view will appear too frequently. > Due to the ambiguous nature of "just working" as one of the criteria for > success here, I think we should lean towards a more conservative approach > (at least initially). #1 assumes the tool should "just work", but #2 not as much. I would generally opt for the conservative side initially.
No longer blocks: 1198463
Agree, I think we should opt for a more conservative approach initially. We can revisit this desire to "leave it open" afterwards if it makes sense.
The 2 different perspectives in video with a vertical menu for instance [1]. It could help you to get a better idea of the 2 options. From my point of you, we cannot deliver the product with version B) to the end users. A) current behavior, no close: https://www.youtube.com/watch?v=b3i31Gm9u8I the zoomed view is not automatically closed after a click inside the zoomed view. The vertical sub menus can be easily open/closed to make the correct choice. B) automatic close: https://youtu.be/FqZsDEwg4wk The zoomed view is automatically closed after each action. The user cannot work easily with the vertical sub menus. Each time the zoomed view is automatically closed, the user has to re-open it in order to work on the sub menus. [1] http://www.worldclass.ro/en/personal-training-about.php
(In reply to Dominique Vincent [:domivinc] from comment #9) > The 2 different perspectives in video with a vertical menu for instance [1]. > It could help you to get a better idea of the 2 options. From my point of > you, we cannot deliver the product with version B) to the end users. > > > A) current behavior, no close: https://www.youtube.com/watch?v=b3i31Gm9u8I > the zoomed view is not automatically closed after a click inside the zoomed > view. > The vertical sub menus can be easily open/closed to make the correct choice. Domivinc, what if it's a different website and what launches are not drop-down options but rather, a pop-up in the middle of the screen? > B) automatic close: https://youtu.be/FqZsDEwg4wk > The zoomed view is automatically closed after each action. > The user cannot work easily with the vertical sub menus. Each time the > zoomed view is automatically closed, the user has to re-open it in order to > work on the sub menus. Triggering this "view" is a single press, but closing this "view" on the other hand, requires pressing on a specific location. Comparatively, it's more load on the user and we can't be certain what was triggered from the user's first press. That's why I think B) is the right way to go here.
(In reply to Anthony Lam (:antlam) from comment #10) > Domivinc, what if it's a different website and what launches are not > drop-down options but rather, a pop-up in the middle of the screen? > Two options here: If the text of the popup is "readable", the user will close the zoomed view. If the text of the popup is "unreadable", the user will move the zoomed view to read the text. > > Triggering this "view" is a single press, but closing this "view" on the > other hand, requires pressing on a specific location. Comparatively, it's > more load on the user and we can't be certain what was triggered from the > user's first press. That's why I think B) is the right way to go here. Comparatively, the number of clicks on the vertical menus is the double in version B). This is not really an argument in favor of version B). OK, let's move on the impact of the version B) design. We should also open 2 other bugs: - remove the "close" button of the zoomed view because this button will be totally useless in B) design. - remove also the tool bar you designed several months ago because nothing will be display inside the tool bar (when the close button will be removed). The differences with the Google Chrome magnifying glass will be limited. I cannot test it but I think it will be limited to the possibility to move the zoomed view. We could also remove it. In order to satisfy both respectable points of view, could I make a last design proposal? There is already a preference setting "ui.zoomedview.simplified". It's used to display only a limited number of controls in the zoomed view tool bar (no zoom buttons for instance). We could use this setting the following way: - when this preference is set to true: no zoom buttons, no close button, no tool bar, automatic close when an action occurs inside the zoomed view, no move if you want, ... ; a basic magnifying glass. - when this preference is set to false: tool bar with zoom buttons and close button, no automatic close and move possibility; a full magnifying glass with all the options. With this proposal, bug 1192075 should be revisited to give to the user 3 possibilities in the menu : "no magnifying glass", "simplify version" and "full version" for instance.
(In reply to Dominique Vincent [:domivinc] from comment #11) > (In reply to Anthony Lam (:antlam) from comment #10) > > Domivinc, what if it's a different website and what launches are not > > drop-down options but rather, a pop-up in the middle of the screen? > > > Two options here: > If the text of the popup is "readable", the user will close the zoomed view. > If the text of the popup is "unreadable", the user will move the zoomed view > to read the text. Correct me if I'm wrong but, isn't this impossible to tell? Unless we can reliably do this with no margin of error, I think we should opt for a more conservative approach initially. > > > > Triggering this "view" is a single press, but closing this "view" on the > > other hand, requires pressing on a specific location. Comparatively, it's > > more load on the user and we can't be certain what was triggered from the > > user's first press. That's why I think B) is the right way to go here. > > Comparatively, the number of clicks on the vertical menus is the double in > version B). This is not really an argument in favor of version B). Sorry, maybe you're misunderstanding my point. I don't think we should compare "the number of clicks on the vertical menu" for this site with our UI/UX. What if it's a different website in question? and it launches something other than drop-down options styled similar to this website? > OK, let's move on the impact of the version B) design. We should also open 2 > other bugs: > - remove the "close" button of the zoomed view because this button will be > totally useless in B) design. > - remove also the tool bar you designed several months ago because nothing > will be display inside the tool bar (when the close button will be removed). > > The differences with the Google Chrome magnifying glass will be limited. I > cannot test it but I think it will be limited to the possibility to move the > zoomed view. We could also remove it. Sorry I'm having trouble understanding here. Could you rephrase? > In order to satisfy both respectable points of view, could I make a last > design proposal? > > There is already a preference setting "ui.zoomedview.simplified". It's used > to display only a limited number of controls in the zoomed view tool bar (no > zoom buttons for instance). > > We could use this setting the following way: > > - when this preference is set to true: no zoom buttons, no close button, no > tool bar, automatic close when an action occurs inside the zoomed view, no > move if you want, ... ; a basic magnifying glass. > > - when this preference is set to false: tool bar with zoom buttons and close > button, no automatic close and move possibility; a full magnifying glass > with all the options. > > With this proposal, bug 1192075 should be revisited to give to the user 3 > possibilities in the menu : "no magnifying glass", "simplify version" and > "full version" for instance. I can see the value in adding additional settings and functionality. I'd be happy to take a look at future improvements and enhancements. But I wouldn't block shipping this for the initial version.
(In reply to Anthony Lam (:antlam) from comment #12) > Sorry I'm having trouble understanding here. Could you rephrase? > With your design, the zoomed view will be closed when the user clicks outside or inside the zoomed view. So the "close" button will be useless, we can remove it. If there is no button in the zoomed view toolbar, we can also remove the toolbar. At this point, the design of the zoomed view will be exactly the same of the current Google Chrome magnifying glass. The only difference is the fact that we can move the zoomed view on our implementation. I think that the Google Chrome magnifying glass cannot be moved. Do you also want to remove the move functionality of our zoomed view in order to get the exact same behavior we can see in Google Chrome for Android?
To try to clarify Anthony's perspective, fwict, he's afraid the zoomed view would be considered "annoying" or "bothersome" to users. > (In reply to Anthony Lam (:antlam) from comment #10) > > Domivinc, what if it's a different website and what launches are not > > drop-down options but rather, a pop-up in the middle of the screen? Given the drop-down use case, not closing the zoomed view sounds great! But... > Two options here: > If the text of the popup is "readable", the user will close the zoomed view. > If the text of the popup is "unreadable", the user will move the zoomed view > to read the text. If there is a popup showing instead, every user *must* take some action before they can interact with the content. Either they will explicitly close the view or explicitly move the view. However, if the zoomed view closes by itself, only a subset of users, those who find the popup unreadable, need to take some action (which is likely pinch-to-zoom, or to open the zoomed view manually if we provide that option). Anthony is going for the latter, more conservative approach as it is less likely to get in a user's way at the disadvantage of being less useful in some cases (e.g. a drop-down). As a v1, I wouldn't say parity is bad – Chrome's magnifying glass has helped me a few times and has never gotten in my way – no negatives, only positives. When we improve the algorithm to have intuition in what it should do in certain cases, we could try doing something more useful in v2, e.g. leaving the view open for drop downs. Alternatively, to revisit and clarify an idea from comment 7: > * If we have a method of displaying the zoomed view manually (e.g. better to solve #2), > there would be more incentive to close it after clicking inside it once when it appears > automatically And not close it when clicking inside it when displayed manually. That's another way we can differentiate from Chrome.
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.