How to have iOS version use notifications not widgets

[scottjenson]

Our current version of the Physical Web on iOS was forced to use a widget because we

a) wanted a simpler way to scan for beacons (only when the widget is shown) b) Had issues getting things to work properly with notifications

It's clear that the UX for the our iOS is less than idea as most people just don't use widgets in the TodayView. We'd like feedback from any iOS developers out there on ways we could get this to work without a widget. Here is what we need:

1) a way to scan for beacons that doesn't use much power. We'd like to only scan when the screen is first turned on. We think scanning constantly while in the pocket would just waste battery.

2) Show a notification when a beacon is found. We need to remove the notification if the beacon goes away.

• Imagine waking up the phone at 1:00pm and finding a beacon and posting a notification.
• Assume the user does nothing and puts the phone to sleep
• at 2:00pm the user wakes the phone and no beacons are found
• Clear the old beacon as it is no longer valid

Curious if anyone has any suggestions on best ways to do this.

[kanodia]

Why the implementation of physical web in chrome not possible in iOS for chrome just like in chrome for Android.

[scottjenson]

They have different operating systems so different constraints

[russellmorton]

I am not an iOS developer so please excuse me if I make any assumptions that are unfounded.

Looking at how iOS handles lock screen notifications there is a time since the arrival of the notification. Is it not fair to give users some credit to know that if the notification says 1hr and given that they will know that they have moved that the notification may not be valid?

Let's assume anyway that they still click on the notification and it opens Chrome to a Physical Web scan page, a rescan should be initiated to show the latest information from the beacon anyway, so if they have moved out of range nothing will show up. Would it be possible then to show a message for old notification clicks to say that the Physical Web object is no longer in range?

On Wed, Feb 17, 2016 at 8:26 AM scottjenson notifications@github.com wrote:

They have different operating systems so different constraints

— Reply to this email directly or view it on GitHub https://github.com/google/physical-web/issues/592#issuecomment-185046494 .

Regards,

Russell M Morton

[itsMattShull]

Currently the BeaconSage app in the app store has lockscreen notifications. When a new beacon comes within range it will update the notifications. There are 2 notifications: 1 for what's closest to you (when you swipe it takes you to the beaconsage app and takes you to that page), the other is telling you how many beacons are currently around you (when you swipe it takes you to the beaconsage app and shows you a list of beacons based on proximity).

We also included the ability to favorite beacons to view them later and a no-follow meta tag that developers can use to not allow people to favorite a particular page.

It's not perfect by any means but we wanted an easy UX to see immediately what's around us.

[rochforp]

So, i'm thinking that if you were to have a beacon broadcasting Eddystone-URL with either a UID or iBeacon frame intermingling somewhere amongst the intervals, you would then be able to have a either the Chrome app or Physical Web app wake up, either if the app is closed and phone is sleeping or just on the lock screen, and generate a notification similar to what is seen in the BeaconSage app. Or, what I think to be the better approach, just put a small physical web icon in the lower left corner indicating the presence of beacons in the area which is achievable through the inclusion of the interweaving of the additional protocol type. The user swipes up on the lower left corner icon on their lock screen, thereby unlocking the device and opening the app where they are taken directly to a physical web scanner which is populating all nearby beacons. I'm wondering if this could be triggered by the Eddy-URL alone but I'm unsure as to the ability to generate this specific type of notification based on this alone. I feel this is a good approach as it's still providing the passive experience, while allowing users to get some sort of visual lock screen indication of the existence of beacons. Something like this but physical web logo, of course

[Jerren34]

Great to see the physical web team considering user experience that will help physical web adoption grow rather than just be a cool concept. The digital marketer inside me is excited to see what solution you guys come up with.

[sebblanc]

I think that to have stuff that work as expected on iOs, it's often necessary to go the Apple way. So I agree with @rochforp on the fact that it could work with an intermittent iBeacon signal (I don't recommand Eddystone-UID there, as from my knowledges they can't wake up an iOs app in background yet).

More precisely, Chrome or any Physical Web app would monitor a specific iBeacon region (that needs to be decided in specifications). Then, whenever an iBeacon of this region will be detected, the app will wake up, scan and detect that there are one or many Eddystone-URL beacons in range and could then show a notification.

The constraint of this approach is that it would requires beacons emitting both iBeacon / Eddystone-URL signals (therefore forcing manufacturers to have firmware updates for existing beacons), or to set up some iBeacons emitting the specified iBeacon region next to Eddystone-URL beacons. But if it allows to have a good user experience on iOs, it's worth it.

[scottjenson]

Unfortunately that's not a practical option as it would mean that every Eddystone-URL beacon in the world would ALSO need to broadcast an iBeacon frame. That has a huge impact on battery performance.

What we were hoping to do was do a low power scan using the ServiceIDList (which is a standard BLE parameter) in the ad packet. Apple does actually support this.

We're not worried about scanning for the packet, I think we have some good ideas around that. Our biggest issues are: 1) Being able to use notifications (adding/removing them as needed) 2) Waking up at clever times to scan and not use too much power.

If we can use the Apple beacon scanning library in a way that makes this easier, great.

Scott

[stopsatgreen]

Quick question about this:

most people just don't use widgets in the TodayView

Is that general usage, or specifically from the implementation of PW in Chrome? That is, is it generally something that users don’t do at all, or a question of educating / demonstrating how to do it for Chrome?

[patrickkeane]

From my own personal experience, the only reason I enabled Today View (or frankly installed Chrome on iOS) was for physical web support.

My own opinion is that the infrastructure in both platforms is fairly sufficient as is for a LOT of use cases. I'm not sure that a lot of changes need to be made (or any) until some early wins occur that drive adoption forward.

Consider that when device manufacturers (whether IOT or otherwise) begin shipping devices with no meaningful UI and/or documentation, instead relying on _inbuilt beacons advertising their interface, Android will support this nicely out of the box with what is in Chrome Beta today.

Mass -> in-built <- adoption from manufacturers and not post-shipment external beacon placement is likely what will eventually draw all mobile platforms into the physical web camp. The idea of having a highly mobile battery-backed physical web beacon seems like a novelty with far fewer practical use cases by comparison to this big elephant.

So, in short I think retail/marketing will eventually get the experience they want from the UI/responsiveness, but there's not going to be as big a clamor to get there as there would likely be if driven from other angles.

On Thu, Feb 18, 2016 at 9:28 AM, Peter Gasston notifications@github.com wrote:

Quick question about this:

most people just don't use widgets in the TodayView

Is that general usage, or specifically from the implementation of PW in Chrome? That is, is it generally something that users don’t do at all, or a question of educating / demonstrating how to do it for Chrome?

— Reply to this email directly or view it on GitHub https://github.com/google/physical-web/issues/592#issuecomment-185744873 .

[ferencbrachmann]

I've demoed the physical web to at least 200 iPhone users live in the past few months, my experience is:

• about 50-60% have Chrome installed (this was a surprise)
• hardly anyone knows what widgets are and how to use them
• whenever I mention Chrome everyone instantly launches it (before I get to the part about widgets)

Because a lot of corporate executives are iPhone users, improving the current onboarding would be big help to companies like us as we have several major corporate prospects that are not seriously looking into this because of the complicated onboarding on iOS (at least compared to Android).

[scottjenson]

We are aware of this issue ;-) What would you suggest?

[ferencbrachmann]

@scottjenson I'm no developer.

1. Consistency in behavour: how beacons are discovered (you're going to do that with filtering out HTTP on iOS for example)
2. If you can't have the same kind of notification-based experience as you have in Android (because of OS limitations), try to have it directly in the App (Like the Opera Dev build)

[scottjenson]

1. Our next release of Chrome for iOS uses the same filtering as Android so the same beacons will show up in both.
2. Not every iOS user uses Chrome
3. We are moving to a more in app experience for iOS
4. We hope the new iOS10 widget experience improves the experience

[syoder]

I believe you can cancel a local notification via UIApplication cancelLocalNotification:. The hard part is knowing when the user has left the area where the PW beacon is so that you can cancel the notifications appropriately. You could use a background task and before it expires remove notifications if the beacons aren't detected anymore. But you only get 3 minutes, and that may not be long enough for the user to physically leave the area.

Instead of firing a local notification for each beacon, you could fire a notification that says something like "PhysicalWeb object(s) detected". Selecting this notification would take you into a table view in Chrome that shows the list. If you aren't able to remove that notification when the beacon goes away, at least you've only added one notification. IMHO, this would be preferable to the current setup where very few people are able to use PW on iOS because they don't know about the widget.

[scottjenson]

There are battery concerns about scanning on the background. Given the improvements with Widgets in iOS10 we hope that our current widget approach will be easier to setup and use (it is not very easy to setup to be honest)

We're also realizing that while notifications are universal and easy to launch, they do have a downside: the can be very easily dismissed. They also can just not scan at the right time and not show the user the right beacon in front of them. The huge advantage of a widget is that it is inherent in it a 'scan now' request. Every time you open it, it WILL scan which has strong benefits.

We're trying to figure out ways making this happen on android. There is a 'nearby' quick setup icon for Android N that will help (but it's possible many won't find it) There are other things we're experimenting with as well. It's a tricky problem.

[lediya-developer]

Hi scottjenson,

without chrome i could not able to notify url to customer in ios. There is no alternative like safari to push eddystone url

[scottjenson]

The only app that we offer is Chrome. It is not supported by Safari (yet) If you want, you can install other physical Web scanners on ios. THere is Beacon Sage and BKON. Both are excellent