One idea I had was to add hint text (something like "Where did my stuff go?") to the overflow menu (like the "Powered by Chrome" footer in custom tabs). Attached a rough draft but I think this would help users get accustomed to the new location for Bookmarks etc. - copy FPO still needs to be reviewed by Shimi.

This would either link to the half state of Chrome Home with our current IPH or lead to a full screen Material onboarding flow (rough mock attached) -again the copy is FPO):

Let me know what you think!

Deleted: overflow menu.png 156 KB

	overflow menu.png 156 KB View Download

Deleted: Screen Shot 2017-08-18 at 15.49.25.png 299 KB

	Screen Shot 2017-08-18 at 15.49.25.png 299 KB View Download

Adding this for posterity: some cases where the IPH overlaps with other UI. https://bugs.chromium.org/p/chromium/issues/detail?id=728265

What's the timeline for this bug? (so we can plan for how to fix issues like the above in the interim).

+ Eng

If we don't do the data saver update in M62, and just add "Where did my stuff go?" in the overflow menu in the same style as the custom tab text saying "Powered by Chrome" do you think we'd be able to get this change in my M62?

Tapping on it would trigger the IPH bubble we currently have and I've cc'd Shimi to take a look at the string.

Thanks!

Should the menu item disappear after it's been tapped once or is it permanently available?

Adding the data saver menu item at a fixed position was relatively easy because we already have most of the code, we would just have to plumb through a couple of extra things and plop it in. This doesn't look too challenging, but would be completely new code. With less than a week until branch, it feels a bit rushed. It's also hard to make the argument that this is "polish" and not a new feature and we are a week past feature freeze.

It will be permanent for possibly a few milestones. Agreed that this isn't polish, but was a feature proposal to address a "bug" that users might not know where their bookmarks when per results of the dev/beta experiment that just came in...

The menu item would be permanently available. Here's an updated set of mocks showing that it'd just present the existing IPH tooltip: https://folio.googleplex.com/bijou-cleer/170824-Onboarding

I understand the timeframe feels really rushed. We should have raised this issue earlier. Does this seem basically not feasible for M62 at this point, or is there any possibility? The reason we're considering it despite the rush is that it could have some affect on our M62 experiment results.

I agree that users not knowing where their items are is probably an issue, and we can definitely get this in for 63.. it just feels late for 62. I'll prototype this afternoon to get a better estimate of work/risk.

+shaktisahu@ to comment on tying into IPH back end

The prototype was pretty easy, so I think we have a shot at getting this into 62. See attached video.

A couple of other questions:

 - Hannah/Chris, in the unlikely case the IPH bubble hasn't been shown before, should we count this as the 1 show (e.g. it wouldn't show again unless the user tapped the menu item)?
 - For Shakti, if we're showing the IPH bubble in response to a click on a menu item, should we tie into the IPH system somehow or can we just show the view directly?

Deleted: chrome_home_iph_menu_item_prototype.mp4 737 KB

	chrome_home_iph_menu_item_prototype.mp4 737 KB View Download

"In the unlikely case the IPH bubble hasn't been shown before, should we count this as the 1 show (e.g. it wouldn't show again unless the user tapped the menu item)?"

Yes, I think we should count it as the first show and not show it automatically.

Sounds good! Another UX question, should the string be allowed to overflow 1-line if it needs to wrap?

+ktam - any metrics for this? Maybe a user action when the item is clicked?

Yes, text should overflow. Here's a detailed spec: https://folio.googleplex.com/bijou-cleer/170824-Onboarding/spec#%3Ff=hidden

Theresa - I think we would have to directly show the IPH. We still have to call shouldTriggerHelpUI() on the IPH backend in order to avoid overlapping text bubbles.
This is what I am thinking. 
1- From ChromeTabbedActivity#onMenuOrKeyboardAction, we can call getBottomSheet().showHelpBubbleIfNecessary()
2- Since we use the IPH Tracker, it will take care of not showing the bubble next time, i.e. shouldTriggerHelpUI() would return false.
3- We can probably use Tracker#getTriggerState(feature) inside AppMenu in order to prevent the menu item from showing next time onwards.

Thanks for the quick response!

For #3, the app menu item is permanently visible (at least for now).

Since we want to show the help bubble in direct response to the user clicking a button, is it possible to dismiss all other help bubbles and then force the Chrome Home IPH to show? Will calling #shouldTriggerHelpUi() dismiss the other bubbles?

All the bubbles get dismissed on touch interaction. So by the time we select this menu item, we would have automatically dismissed everything else. 
#shouldTriggerHelpUi() returns false if any other bubble is showing, so noone else can show their bubbles while chrome home bubble is still showing.

Also in #showHelpBubbleIfNecessary(), we cant use tracker.addOnInitializedCallback, since we aren't showing on initialization any more (rather in response to menu selection). So we will use its contents directly instead.

Also, does it mean every time we click the menu item, we would show the bubble?
Do we want to stop after the user has opened the bottom sheet at least once?
These all counts are finch configurable, so I guess we are fine.

At least for now, I think it's preferable to make the menu item reliably present and functional, showing the tooltip every time it's tapped, even after they've opened the sheet. This accounts for the user gradually learning where features have been relocated; they may have previously accidentally opened the sheet or may have forgotten how to use it.

Sorry catching up with my threads but thanks for looking into this!

> +ktam - any metrics for this? Maybe a user action when the item is clicked?

Yes, a user action for getting clicked sounds good thanks!

btw, Shimi, do you have any opinions on the string we place here? One potential concern I see is "What happened to my stuff?" might be a bit broad so users looking for something like History may not realize stuff refers to that as well.

Screenshots from in-flight CL.

I'm going to send this out for review momentarily. I'll wait to land until srahim@ confirms the menu item wording.

Deleted: Screenshot_20170828-093050.png 109 KB

	Screenshot_20170828-093050.png 109 KB View Download

Deleted: Screenshot_20170828-092932.png 416 KB

	Screenshot_20170828-092932.png 416 KB View Download

Deleted: Screenshot_20170828-093246.png 418 KB

	Screenshot_20170828-093246.png 418 KB View Download

Deleted: Screenshot_20170828-093034.png 408 KB

	Screenshot_20170828-093034.png 408 KB View Download

Deleted: Screenshot_20170828-092959.png 131 KB

	Screenshot_20170828-092959.png 131 KB View Download

Tonally, we don't use "stuff" much in Chrome. This would be a bit of a departure from our current style. 

Some other ideas with the "Stuff" language:
-"Where's my stuff?" > Has a bit more longevity than "where did...go", which assumes a user has switched and is comparing old Chrome to Chrome Home.

-"Find your stuff" > A bit more action-oriented

Some ideas to make this more like a menu item:

-"Bookmarks & more" > Aligns more with product tone, rest of menu items, but might feel repetitive w/the IPH. It could be "Downloads & more" or "History & more", too. 
 
-"Bookmarks, downloads..." > Not great in terms of length, but most descriptive.

-"History, downloads..." > same. 

Per discussion with srahim@, we'll go with the string: "Where are bookmarks, downloads, and history?"

https://docs.google.com/a/google.com/document/d/1Mwy7yBwATvxppKrwJHpvDy33xj0ySga3i9iQotPdyT8/edit?usp=sharing

Thanks for the quick decision!

Screenshot with updated string

Deleted: Screenshot_20170828-153645.png 407 KB

	Screenshot_20170828-153645.png 407 KB View Download

Updated text size

Deleted: Screenshot_20170828-162337.png 405 KB

	Screenshot_20170828-162337.png 405 KB View Download

Deleted: Screenshot_20170828-162324.png 410 KB

	Screenshot_20170828-162324.png 410 KB View Download

Theresa, you are an eng god for getting this out to fast!!!! Owe you one!!!!

Just have one nice to have design polish (doesn't have to be for M62): but can we vertically center the "?" icon with in the grey row? (just to be consistent with our list styles). 

Thanks again for your wizardry here. I am just AMAZE.

Thank you Hannah :)

Chris, do you concur? The current spec (linked in #13) has the "?" icon at a fixed distance from the top of the menu regardless of how many lines of text there are (which equates to total row height).

Yep, I'm happy to change to vertical centering if that's easily doable.

Vertical centering is easy, screenshot attached.

It turns out we do need to tie into the IPH backend to prevent a different bubble from showing up while ours is displayed. For example, if the user starts loading a slow page, then taps the menu item triggering the Chrome Home IPH, it's possible for another bubble to show up when the page finishes loading. See attached video.

For M62, if we can't get the tie-in with the backend system before branch is that OK?



As an aside, I turned on the IPH demos and noticed that the downloads IPH now points to Chrome Home. I think showing the user both the Chrome Home IPH and downloads IPH may be unnecessary. Maybe we shouldn't show the Chrome Home IPH if the downloads IPH has already been shown? Screenshot attached of the downloads IPH.

Deleted: Screenshot_20170829-093333.png 219 KB

	Screenshot_20170829-093333.png 219 KB View Download

Deleted: Screenshot_20170829-093453.png 429 KB

	Screenshot_20170829-093453.png 429 KB View Download

Deleted: chrome_home_iph_overlap.mp4 5.4 MB

	chrome_home_iph_overlap.mp4 5.4 MB View Download

Ah that's unfortunate. Is there any way to suppress other IPH from being shown while we have an IPH up?

Not without tying into the IPH backend. It shouldn't be hard to add a new IPH feature and write the finch config. I'm going to try and get that in today. The question was a "worst case scenario, is this okay?" sort of question given how close we are to branch point.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5c0c6f1ec64ecf9b132ea30892ab9dd1b4e27afe

commit 5c0c6f1ec64ecf9b132ea30892ab9dd1b4e27afe
Author: Theresa Wellington <twellington@google.com>
Date: Wed Aug 30 17:23:08 2017

[Home] Add header to menu that triggers in-product help

BUG= 756473 

Change-Id: Ifc9eb7064cfc926ec65dc85806e793d65510c792
Reviewed-on: https://chromium-review.googlesource.com/638691
Commit-Queue: Theresa <twellington@chromium.org>
Reviewed-by: Steven Holte <holte@chromium.org>
Reviewed-by: Shakti Sahu <shaktisahu@chromium.org>
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Reviewed-by: Matthew Jones <mdjones@chromium.org>
Cr-Commit-Position: refs/heads/master@{#498517}
[add] https://crrev.com/5c0c6f1ec64ecf9b132ea30892ab9dd1b4e27afe/chrome/android/java/res/layout/chrome_home_iph_header.xml
[modify] https://crrev.com/5c0c6f1ec64ecf9b132ea30892ab9dd1b4e27afe/chrome/android/java/src/org/chromium/chrome/browser/ChromeTabbedActivity.java
[modify] https://crrev.com/5c0c6f1ec64ecf9b132ea30892ab9dd1b4e27afe/chrome/android/java/src/org/chromium/chrome/browser/appmenu/AppMenu.java
[modify] https://crrev.com/5c0c6f1ec64ecf9b132ea30892ab9dd1b4e27afe/chrome/android/java/src/org/chromium/chrome/browser/appmenu/AppMenuHandler.java
[modify] https://crrev.com/5c0c6f1ec64ecf9b132ea30892ab9dd1b4e27afe/chrome/android/java/src/org/chromium/chrome/browser/appmenu/AppMenuPropertiesDelegate.java
[modify] https://crrev.com/5c0c6f1ec64ecf9b132ea30892ab9dd1b4e27afe/chrome/android/java/src/org/chromium/chrome/browser/widget/bottomsheet/BottomSheet.java
[modify] https://crrev.com/5c0c6f1ec64ecf9b132ea30892ab9dd1b4e27afe/chrome/android/java/src/org/chromium/chrome/browser/widget/bottomsheet/BottomSheetMetrics.java
[modify] https://crrev.com/5c0c6f1ec64ecf9b132ea30892ab9dd1b4e27afe/chrome/android/java/strings/android_chrome_strings.grd
[modify] https://crrev.com/5c0c6f1ec64ecf9b132ea30892ab9dd1b4e27afe/tools/metrics/actions/actions.xml

The M62 work is done. I filed issue 760700 to track the backend changes needed for M63 and will leave this bug open for the additional changes needed in BottomSheet.java to tie into the IPH system once it's ready.

hannahs@/other UXers on the thread -- I'm working on connecting the menu header to the in-product help backend and wanted to call out some expected behavior. The IPH backend prevents more than one in-product help from showing at a time. That means that if a bubble is showing (e.g. for downloads home), when the user taps on the menu button the Chrome Home header won't show. There aren't very many in-product help bubbles, so this will be encountered very infrequently in the wild.

I'm also working on fixing another bug (issue 767794) related to the hardware menu key. On devices with a hardware menu key, we need to guard against showing the IPH header when the toolbar isn't visible (e.g. because it's covered up by contextual search). If the user has the toolbar scrolled off screen or contextual search is scrolling and they trigger the app menu via the hardware menu button, then we will not show the IPH menu header.

CL out for review: https://chromium-review.googlesource.com/c/chromium/src/+/690447

Corresponding finch config: https://critique.corp.google.com/#review/170368798

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/572430a155e67a0ffd41beb4fa4d85aa26022781

commit 572430a155e67a0ffd41beb4fa4d85aa26022781
Author: Theresa Wellington <twellington@google.com>
Date: Mon Oct 02 22:31:48 2017

[Home] Connect IPH menu header to feature engagement backend

Also refines the client-side criteria for when the menu header is
showing. If the toolbar is not showing, the menu header shouldn't show
since there is nothing to for the IPH bubble to point to.

BUG= 756473 ,767794

Change-Id: I3343dcf768611133753a0a38badef46863765086
Reviewed-on: https://chromium-review.googlesource.com/690447
Commit-Queue: Theresa <twellington@chromium.org>
Reviewed-by: Tommy Nyquist <nyquist@chromium.org>
Reviewed-by: Steven Holte <holte@chromium.org>
Reviewed-by: Matthew Jones <mdjones@chromium.org>
Cr-Commit-Position: refs/heads/master@{#505816}
[modify] https://crrev.com/572430a155e67a0ffd41beb4fa4d85aa26022781/chrome/android/java/src/org/chromium/chrome/browser/ChromeTabbedActivity.java
[modify] https://crrev.com/572430a155e67a0ffd41beb4fa4d85aa26022781/chrome/android/java/src/org/chromium/chrome/browser/appmenu/AppMenu.java
[modify] https://crrev.com/572430a155e67a0ffd41beb4fa4d85aa26022781/chrome/android/java/src/org/chromium/chrome/browser/widget/bottomsheet/BottomSheet.java
[modify] https://crrev.com/572430a155e67a0ffd41beb4fa4d85aa26022781/components/feature_engagement/public/android/java/src/org/chromium/components/feature_engagement/EventConstants.java
[modify] https://crrev.com/572430a155e67a0ffd41beb4fa4d85aa26022781/components/feature_engagement/public/android/java/src/org/chromium/components/feature_engagement/FeatureConstants.java
[modify] https://crrev.com/572430a155e67a0ffd41beb4fa4d85aa26022781/components/feature_engagement/public/feature_constants.cc
[modify] https://crrev.com/572430a155e67a0ffd41beb4fa4d85aa26022781/components/feature_engagement/public/feature_constants.h
[modify] https://crrev.com/572430a155e67a0ffd41beb4fa4d85aa26022781/components/feature_engagement/public/feature_list.cc
[modify] https://crrev.com/572430a155e67a0ffd41beb4fa4d85aa26022781/components/feature_engagement/public/feature_list.h
[modify] https://crrev.com/572430a155e67a0ffd41beb4fa4d85aa26022781/testing/variations/fieldtrial_testing_config.json
[modify] https://crrev.com/572430a155e67a0ffd41beb4fa4d85aa26022781/tools/metrics/actions/actions.xml
[modify] https://crrev.com/572430a155e67a0ffd41beb4fa4d85aa26022781/tools/metrics/histograms/histograms.xml