Should be investigated.

+tedchoc

You can argue that very few users will edit URL suggestions (as opposed to query suggestions), therefore the arrow is unnecessary and potentially distracting. I'd argue, on the other hand, that the visual consistency of arrows next to all suggestion type is preferable.

tedchoc: was any experiment run on Android to measure the effects of these arrows? I seem to recall that at one point they were removed (or were under threat of removal) and then restored.

+tedchoc (Please see question in comment 4.)

I know I've never been able to remember/understand the purpose of the arrows, and I thought when we tested we found most users didn't know what they did either.  It would be interesting to know what data we have on all this, as personally I'd love to kill the arrows everywhere.

I think the larger issue and point is, why are they present on Chrome for Android but not Chrome for iPhone? There seems to be a communication issue here (small differences between Chrome for Android and Chrome for iPhone)

Someone gave the go ahead for these arrows on Android but no one thought to also add them to Chrome for iPhone? I filed another minor inconsistency that shows there needs to be something done about this https://bugs.chromium.org/p/chromium/issues/detail?id=677679

We did remove the arrows during the material design update of Chrome on Android:
crbug.com/375379

And then quickly added back to due to complaints (that have been lost to the ether): crbug.com/398254

If you look at the usage of MobileOmniboxRefineSuggestion, it has greater usage than Find in Page, Forward Navigation, Share, etc...  Also, I find the feature to be very useful for query building.  So, I am strongly against removing it.

Granted, I don't think the arrow really makes sense for URL suggestions and I suspect we could only show it for query suggestions w/ minimal impact.

It would be good to do some study to find out how people use this.  Perhaps something like Chips Ahoy solves the same use cases better (but perhaps not).

As you can see, it's quite help for me to check the various reddits I do, I just tap R, then the arrow and it saves me quite a few taps and a little bit of time. I think removing them in any way would be a mistake and if anything, they should be added to Chrome for iPhone right away because if something is in Chrome for Android stable, that should mean it's fine for Chrome for iPhone too

I'm not surprised you had to add the arrows back in.  When I looked at  usage, it was a non-trivial percent of users who used them.  (I didn't / couldn't slice by query versus URL though.)  See this message
https://groups.google.com/a/google.com/d/msg/gsa-suggest/I-v1hf1o5CA/ixq4w-cg_14J
and the whole thread in general.  (Numbers omitted here on this public bug.)

I'm shortening this title to make the issue and desired fix clearer.

I don't mean to harp or be annoying but, does anyone know why the arrows weren't  added to iOS around the same time they were added to Android? That's worth looking into. Chrome for iOS and Chrome for Android should be seen as the same: Chrome for Phones (or as much as possible because I understand there are significant differences)

I don't understand why Android has them but iOS does not

billdillensrevenge@,
I have three answers for you.
1. Sometimes the UIs on two the apps differ to respect platform-level UI conventions.  This is intentional.  (e.g., long-press versus swiping away)
2. Chrome for iOS and Chrome for Android have different teams.  Due to platform constraints, the UI layer in Chrome for iOS is written in objective C.  In Android it's Java.  This means that people need to code each UI separately for each platform.  Due to engineering constraints, this means that not all items can be implemented.  We don't have infinite numbers of engineers!
  - That said, I'll remind you that chromium is an open-source project.  If something bothers you, you're welcome to try to fix it yourself (or find a software engineering friend who you can convince to contribute). :-)
3. Sometimes things fall through the cracks, as likely happened here.

Please do continue reporting these platforms differences!  We appreciate them, and it sounds like these reports may actually point out things we never were consciously aware of.  And now they may actually get fixed.  Yay.

thanks,
mark

I'm more than happy to help and contribute in any way I can, I love Chrome.


But I do think the proper solution would be unifying the Chrome for Android and Chrome for iOS teams into a Chrome for Phones team. This would ensure nothing falls through the cracks and cross platform consistency. If I have found 3 so far, surely there are many more. 

The 3rd being: the menu opening animation feels a lot shorter/faster on Chrome for iPhone compared to Chrome for Android. If this is indeed the case, it's just another example of this problem. 

I believe The Verge wrote a little something about how the iOS versions of Google's apps are better than the Android versions, and that's a problem 

Just a note that I'm seeing arrows on my Chrome on iOS (v55), so I believe there is feature parity here. Not sure why they are not showing up for billdillensrevenge. I'm not sure I can help diagnose either - if others have suggestions, do weigh in.

rolfe@: you're seeing arrows for *URL suggestions* on iOS? jdonnelly@'s comment implied they weren't there for those.

Oh sorry - arrows for terms, not URL suggestions. Ignore my comment then.

To sum up:
- Everyone agrees Android and iOS should exhibit the same behavior. I can take care of this.
- There are three opinions on whether to have the arrows:
   - No
   - Yes, but only for query suggestions.
   - Yes, for both query suggestions and URL suggestions.

There is evidence that the refinement arrows enjoy substantial use on Android via MobileOmniboxRefineSuggestion. However, that metric doesn't currently distinguish between URL and query suggestions. I'll update it to do that so we can make an informed decision about whether to a) remove URL suggestion refinement arrows on Android or b) add URL suggestion refinement arrows on iOS.

Please don't remove the arrows for either! They are the touch-screen equivalent of the downward facing arrow on a real life laptop. If I didn't have the downward facing arrow on my laptop when entering in URL's, my experience using Chrome would be significantly worse! So it's the same story here. Those arrows are fantastic for both query suggestions as well as URL suggestions

Removing myself and adding +maxwalker as primary design contact for omnibox work

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

commit a773c51e18c77d4bd644b3267676e705d46c6025
Author: Justin Donnelly <jdonnelly@chromium.org>
Date: Mon Jul 10 20:47:28 2017

Record the refinement action separately for query and URL suggestions.

This will be used to decide whether we should have refinement arrows in
the UI for URL suggestions (on both Android, which has them, and iOS,
which currently doesn't).

Bug:  679083 
Change-Id: I71ee24d703789fbd6631de9568793e04150e5160
Reviewed-on: https://chromium-review.googlesource.com/563882
Reviewed-by: Mark Pearson <mpearson@chromium.org>
Reviewed-by: Maria Khomenko <mariakhomenko@chromium.org>
Commit-Queue: Justin Donnelly <jdonnelly@chromium.org>
Cr-Commit-Position: refs/heads/master@{#485369}
[modify] https://crrev.com/a773c51e18c77d4bd644b3267676e705d46c6025/chrome/android/java/src/org/chromium/chrome/browser/omnibox/LocationBarLayout.java
[modify] https://crrev.com/a773c51e18c77d4bd644b3267676e705d46c6025/tools/metrics/actions/actions.xml

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

commit 52a0d5b95e2e400545d50ec7f1560a1dd9e68db1
Author: Justin Donnelly <jdonnelly@google.com>
Date: Tue Jul 11 15:42:49 2017

Record a user action for the omnibox refinement arrow (append button).

This is already recorded on Android but it would be helpful to compare
the usage on iOS.

Depends on http://crrev.com/c/563882.

Bug:  679083 
Change-Id: Id67f13dea3ab36bc1b2c7b541d9a000a1c27d1b8
Reviewed-on: https://chromium-review.googlesource.com/563592
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: Justin Donnelly <jdonnelly@chromium.org>
Cr-Commit-Position: refs/heads/master@{#485637}
[modify] https://crrev.com/52a0d5b95e2e400545d50ec7f1560a1dd9e68db1/ios/chrome/browser/ui/omnibox/omnibox_popup_material_view_controller.mm

These new metrics should point us in the right direction as to whether we should either a) remove the arrow from URL suggestions on Android or b) add the arrow to URL suggestions on iOS.

Like the original reporter, I prefer the latter outcome but if the use of the arrow on URL suggestions is much lower than on search suggestions, it'll make more sense to do the former.

To prevent cheating, I'll propose a decision threshold now: if the usage rate of the arrow on URL suggestions is less than 10% of the rate for search suggestions, do a). If greater than 10%, do b).

But there has to be an actual reason to remove the arrows from Android (if it turns out they aren't getting enough use). Does having the arrows on Android make anything more challenging or complex? Does it have an effect on performance? Do the arrows confuse users? If there's no downside to having them, it would be madness to remove them. Data in and of itself is not enough to make decisions 

Well, I suppose we'll just have to say that madness is in the eye of the beholder. :)

The arrows are taking up a very limited amount of space in the UI. If they're very rarely used, it would be better to give that space back the title and URL so that less of that text need be truncated.

I remember reading that the reason they added those arrows to Chrome for Android was because in Chrome for desktop, they saw high usage of the down arrow on the keyboard when people were typing in the URL bar, so the arrows are just the touchscreen version of the down arrow key. BUT that might have been a flawed decision too because, if people were just tapping the down arrow key and then pressing Enter, the arrows are unnecessary on Android because you can just tap any of the visible results.

So it would be interesting and helpful to know; on Chrome for desktop, when people use the down arrow in the URL bar, how often do they simply hit the enter key VS how often they actually type letters/numbers. Is there data on that? I suspect it's over 90% hitting the enter key and less than 10% of the time letters/numbers 

Note to future self: if we decide to show the refinement arrows on iOS, the implementation needs to be changed to use |fill_into_edit| (it's currently using |contents|).

Is it possible to get usage data on whether desktop users are simply hitting the Enter key or if they're actually adding to the URL before hitting the Enter key? If they are just hitting the Enter key, I think that means that adding these arrows to Android was a flawed decision

That strikes me as an analysis which would have been very useful before launching the mobile UI arrows. But now that the mobile UI arrows are available and have been for some time, the best thing to do is to measure their usage directly. Especially given that we have something of a natural experiment where the URL suggestion arrows are available on one platform (Android) but not another (iOS).

Returning this question (better late than never). On Android the refinement arrow next to URLs gets 21% of the usage (the arrow next to search suggestions gets the other 79%).

This seems to me to be plenty of usage to justify keeping it on Android and adding it on iOS, especially when you consider that URL suggestions are used less often than search suggestions (42% vs. 58%) so there are fewer opportunities to use the URL refinement arrow.

https://uma.googleplex.com/p/chrome/timeline_v2/?sid=eefb61cbd6cfc748a5381c551352450f

I plan to add the URL refinement arrow to iOS Chrome next week unless there are any objections.

That’s great news but I hope something can be done about coordination between the different versions of Chrome. Someone decided to add those arrows to Chrome for Android years ago but they were never added to Chrome for iOS, that’s a problem. Also, with ChromeOS tablets starting to come out, these arrows should probably be added there too

No objection to me about adding them to iOS.

And that's a good point about touch devices (ChromeOS or others)--they should probably have arrows for both queries and URLs too.

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

commit 63bc7b7aea1d225207ab7fdc2350f321a46a1730
Author: Justin Donnelly <jdonnelly@google.com>
Date: Mon Apr 30 15:38:30 2018

Enable omnibox suggestion refinement arrow for URL suggestions.

This will bring the iOS suggestion UI to parity with the Android UI.
Note that there is evidence that the refinement arrows next to URLs
see a significant amount of usage (though not as much as the query
refinement arrows). See the bug for more details.

Bug:  679083 
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I10aad6b630cdc7c598643a2ef35f4bd3d476ec01
Reviewed-on: https://chromium-review.googlesource.com/1033714
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: Justin Donnelly <jdonnelly@chromium.org>
Cr-Commit-Position: refs/heads/master@{#554760}
[modify] https://crrev.com/63bc7b7aea1d225207ab7fdc2350f321a46a1730/ios/chrome/browser/ui/omnibox/autocomplete_match_formatter.mm
[modify] https://crrev.com/63bc7b7aea1d225207ab7fdc2350f321a46a1730/ios/chrome/browser/ui/omnibox/autocomplete_suggestion.h
[modify] https://crrev.com/63bc7b7aea1d225207ab7fdc2350f321a46a1730/ios/chrome/browser/ui/omnibox/popup/omnibox_popup_view_ios.mm

Agreed that we need these arrows on desktop touchscreen devices. That feature is tracked at http://crbug.com/453823.

Issue verified 
Version: Chrome Canary 68.0.3416.0 
Device: iPhone 6
iOS: 11.2.6

Seeing arrows for *URL suggestions* on iOS. 
https://drive.google.com/open?id=1U6mRUtiXo5YfS2Otm-lxW5EUC4Aw2pVQ

I'm posting this loosely related bug here to get it fixed quicker, please take a look https://bugs.chromium.org/p/chromium/issues/detail?id=862404 Is it also an issue on Chrome for iOS?

I got to try this on a friends iPad today and it's quite buggy, it doesn't work as well as on Android. Is this already known and being worked on? 

>>>
I got to try this on a friends iPad today and it's quite buggy, it doesn't work as well as on Android. Is this already known and being worked on? 
>>>
I am not aware of any bugs on file about upward pointing arrows on iPad (except for your general requests about adding a space when used with query suggestions).  If you see an issue, please file a new bug.

just filed the bug https://bugs.chromium.org/p/chromium/issues/detail?id=870018