Note: this doesn't resolve situation when somebody is for example opening smth from Google results, but IMHO is step into good direction (saving resources and non-opening already opened pages).

hannahs@, can be it accepted?

Assigning to the product team to consider this request.

Hi Marcin, I reviewed this ticket and will share it with my UX partner to gather feedback on this proposed change. Thank you for suggesting the change and for attaching potential code changes. I look forward to seeing how this turns out. 

Hi,

Could I ask if we have any update here?

With kind regards,
Marcin

Hi Marcin, thank you for submitting this idea and attaching potential code changes. Your suggestions stimulated good conversations and feedback. I encourage you to review this feedback. Please consider incorporating it into your proposal. If you choose not to, I understand, and we will consider your idea again in its present form. 

Feedback:

- The phrase "open in next new tab" and "open in next incognito tab" do not adequately communicate that the webpage is already open in a tab and that opening it again will create a duplicate tab. Please consider phrases such as "open again in new tab", "open again in duplicate tab", "open in duplicate tab." Please think of these phrases as examples of how the user's options might be clarified and not as requirements you must adopt. 

- The design makes the user aware that the webpage is already open in a tab without providing an easy path to accessing that tab and webpage. When a user encounters the phrase "open in next new tab" the user has a choice to make: either open the webpage again in a new tab or find the already open webpage among the open tabs. In its present format, the design makes it easy to create a duplicate tab. A stronger design also make it easy to make the second choice, and seamlessly navigate to that already opened tab. Please think about adding an option to "go to currently open tab" as a suggestion and not as a requirement you must adopt. 

Please reach out if you have questions or comments about this feedback. I look forward to hearing your thoughts. Have an awesome day.

Hi,

Thank you very much for your analysis. I will answer shortly:

1. replacing "open in next new tab" / "open in next incognito tab" for example with "open again in new tab" / "open again in incognito tab" is very acceptable for me. I think, that we should keep these strings short and it doesn't make them very long. Good!

2. new menu option "switch to tab" / "switch to incognito tab" (visible only when tab is already opened) was dropped by SWE (they pointed that menu should be as short as possible and it has got some sense). I think, that decision about it is in your hands now - with this option we shouldn't change strings from menu option from point 1 (new strings = new bytes in APK)

WDYT? Could you share your next comments to it?

Thank you for very constructive discussion and I wish you perfect week!

 lzbylut@ - friendly ping here.

Hi Marcin, 

I'm glad that you're receptive to the first suggestion. Feel free to move forward with this change to the text strings.

As to the second suggestion, I agree that adding an additional row to the context menu would make it longer (perhaps too long).

Have a look at how the desktop team implemented the 'switch to tab' feature in a recent experiment. Notice that they used both text and an icon, and that when you resize the screen the text gets simplified and eventually disappears. 

Also have a look at how the most commonly used share app is listed in the overflow menu next to the 'share...' option. In the screenshot I'm adding, it's google hangouts.  

When I first thought about the second suggestion, I originally imagined that the 'open again in new tab' option could list the 'switch to tab' icon on the side to provide the user with the ability to switch to that tab. But then I realized it would be rather confusing to the user to have the option to 'reopen a tab' on the same row as the option to 'switch to that tab,' since they have to different functionalities. 

As such, I'm inclined to agree that the first suggestion can go forward without the second suggestion.

For my part, I would like this change to go through our experimentation pipeline. This text change, although mostly cosmetic, has the potential to decrease tab usage and page loads and increase usage of the tab switcher. I would like to know how much of a change we can expect by conducting % experiments in Canary and Dev at least, and potentially in Beta and Stable.

Would you mind checking in additional files. One to set up the experiment (you might not be able to write the whole finch config file, for example the experiment id seeds). And another one that instruments a new metric to measure how often the 'open in new tab' option is being tapped compare to the proposed 'open again in new tab.' The metric should record values only in cases when the text 'open in new tab' would have been eligible for replacement with the text 'open again in new tab'.


Please reach out if you need pointers on implementing finch configurations or metrics. The codebase should be full of examples, but we'd be happy to help if you need more pointers.

Deleted: Screenshot 2019-01-07 at 11.19.11 AM.png 82.9 KB

	Screenshot 2019-01-07 at 11.19.11 AM.png 82.9 KB View Download

Deleted: Screenshot (Jan 7, 2019 11_22_54 AM).png 416 KB

	Screenshot (Jan 7, 2019 11_22_54 AM).png 416 KB View Download

Lukasz, can you please send the full proposal through some sort of product/UX review before we continue with the engineering work (coding or reviews)? In particular, this has some overlap with the recent desktop feature to help users find open tabs via omnibox suggestions. It'd be good to flesh out whether we want to adopt that feature on mobile and how it might interact with this proposal.

Marcin, being an external contributor, won't be able to set up an A/B experiment so you'll need to assist with that or dedicate eng resources to assisting on this project.

Hi lzbylut@ and Theresa,

Thank you very much all help.

I updated https://chromium-review.googlesource.com/c/chromium/src/+/1215323 - it implements discussed feature in context menu in NTP and regular webpages.

Please help me with next steps:

1. formal paperwork and fulfilling all processes

2. checking if I correctly followed lzbylut@ specification especially with histograms

3. enabling feature for some channels like discussed in #13

Thank you once again.

Hi Marcin, 

I spoke with our design partners and they prefer that we postpone work on this feature until we make a product decision on a slightly different feature that affects the way tabs are opened. 

The new way of opening tabs might completely eliminate the need for this enhancement, and so we'd rather not spend time pursuing this change given that a new mechanism might be just around the corner. 

Thank you for your contributions and for your ideas for how to make the product better. Feel free to archive this ticket, and we can revive it if the other feature does not proceed to launch.