Closed Bug 1007770 Opened 5 years ago Closed 5 years ago

WebApp update prompt looks scary - update icon

Categories

(Firefox for Android :: Web Apps, defect, P2)

x86
macOS
defect

Tracking

()

VERIFIED FIXED
Firefox 32
Tracking Status
firefox30 --- verified
firefox31 --- verified
firefox32 --- verified
fennec 30+ ---

People

(Reporter: blassey, Assigned: myk)

References

Details

(Whiteboard: [WebRuntime])

Attachments

(2 files)

I got this notification in my notification bar and immediately thought that I had some sort of malware on my device.
tracking-fennec: --- → 32+
tracking-fennec: 32+ → ?
Was it the visual design of the notification, the title/message text, or some other aspect of the notification that made you think it was malicious?
For the Twitter app, it just looks totally generic. The use of the download icon, especially. If we could use the app's own icon or the rocket ship it would go a long way.
Priority: -- → P2
Whiteboard: [WebRuntime]
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #2)
> For the Twitter app, it just looks totally generic. The use of the download
> icon, especially. If we could use the app's own icon or the rocket ship it
> would go a long way.

It'd be simple to show the rocket ship icon.

Using the app's own icon would be harder, because we currently show a single notification for all apps that have an update, and we'd need to switch to showing individual notifications for each app.  And that would probably entrain checking for updates only for running apps, to avoid the situation where you start Firefox for the first time in a while and get a ton of notifications.

(We might want to do that anyway, to more closely tie updates with apps.  But it's a bigger change and should involve Fennec UX, whose general guidance has been to make the feature look and feel as native as possible; hence the comparison to Google Play.)
Assignee: nobody → myk
Status: NEW → ASSIGNED
(In reply to Myk Melez [:myk] [@mykmelez] from comment #3)
> Using the app's own icon would be harder, because we currently show a single
> notification for all apps that have an update, and we'd need to switch to
> showing individual notifications for each app.  And that would probably
> entrain checking for updates only for running apps, to avoid the situation
> where you start Firefox for the first time in a while and get a ton of
> notifications.

So what happens when you click a notification where there are multiple updates? You can only launch the APK installer for one, no? Do you listen for the PACKAGE_CHANGED intent and fire the next one?

> 
> (We might want to do that anyway, to more closely tie updates with apps. 
> But it's a bigger change and should involve Fennec UX, whose general
> guidance has been to make the feature look and feel as native as possible;
> hence the comparison to Google Play.)

Yeah it definitely does not feel native right now.
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #4)
> So what happens when you click a notification where there are multiple
> updates? You can only launch the APK installer for one, no? Do you listen
> for the PACKAGE_CHANGED intent and fire the next one?

We can (and do) actually launch the APK installer multiple times for multiple apps, and the installer layers the "confirm install" views, such that dismissing one by pressing its "Done" button causes the next one to appear.

This is problematic, because it's too easy to lose track of the multi-app installation process (especially if you "Open" an app from its "confirm install" view while other apps are still waiting to be installed) and then get surprised by the next "confirm install" view (when returning to Fennec) or never see it (if Fennec gets killed before you return to it).  So I'm eager to improve it.  But that seems orthogonal, or at least it isn't the issue identified by the description of this bug.


> > (We might want to do that anyway, to more closely tie updates with apps. 
> > But it's a bigger change and should involve Fennec UX, whose general
> > guidance has been to make the feature look and feel as native as possible;
> > hence the comparison to Google Play.)
> 
> Yeah it definitely does not feel native right now.

Erm, my point was that the current design is *more* native than one that would prompt users to update each app individually, since it's closer to the way Google Play prompts users to update multiple apps.

Regardless, it isn't identical to the native flow.  And I'm sure we can improve it (even if we can't make it perfectly identical due to platform limitations).  Or we can intentionally make it feel less native by prompting users to update each app individually, if we think that would nevertheless be a better experience.
(In reply to Myk Melez [:myk] [@mykmelez] from comment #5)
> (In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #4)
> > So what happens when you click a notification where there are multiple
> > updates? You can only launch the APK installer for one, no? Do you listen
> > for the PACKAGE_CHANGED intent and fire the next one?
> 
> We can (and do) actually launch the APK installer multiple times for
> multiple apps, and the installer layers the "confirm install" views, such
> that dismissing one by pressing its "Done" button causes the next one to
> appear.
> 
> This is problematic, because it's too easy to lose track of the multi-app
> installation process (especially if you "Open" an app from its "confirm
> install" view while other apps are still waiting to be installed) and then
> get surprised by the next "confirm install" view (when returning to Fennec)
> or never see it (if Fennec gets killed before you return to it).  So I'm
> eager to improve it.  But that seems orthogonal, or at least it isn't the
> issue identified by the description of this bug.

Yeah, this is kind of terrible, IMHO, but hard to avoid if you do this multi-app update thing.

> 
> 
> > > (We might want to do that anyway, to more closely tie updates with apps. 
> > > But it's a bigger change and should involve Fennec UX, whose general
> > > guidance has been to make the feature look and feel as native as possible;
> > > hence the comparison to Google Play.)
> > 
> > Yeah it definitely does not feel native right now.
> 
> Erm, my point was that the current design is *more* native than one that
> would prompt users to update each app individually, since it's closer to the
> way Google Play prompts users to update multiple apps.
> 
> Regardless, it isn't identical to the native flow.  And I'm sure we can
> improve it (even if we can't make it perfectly identical due to platform
> limitations).  Or we can intentionally make it feel less native by prompting
> users to update each app individually, if we think that would nevertheless
> be a better experience.

Ah, I see what you mean. IMHO (and we should definitely get Design involved here), when there are multiple updates, it should take you to a UI listing the updates where you can then update them. And it should do it serially, if possible.

I'm sure ibarlow will have an opinion :)
Flags: needinfo?(ibarlow)
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #6)
> I'm sure ibarlow will have an opinion :)

Indeed!  Ian gave us general guidance on the webapp flows but didn't review them in detail.  And I'd very much like to get his input on this one.

Nevertheless, that's a generalization of the specific issue reported in this bug, and I want to make sure we address that specific issue, if it's possible to do so given our current implementation, while we also go about designing and building a better mousetrap.
After discussion in triage, let's update the icon in this bug and get that up to 30. Will clone this to a new bug to wordsmith the notificaton
tracking-fennec: ? → 30+
Summary: WebApp update prompt looks scary → WebApp update prompt looks scary - update icon
Here's a change to use the app (i.e. rocket ship) icon, which someone (blassey? dria?) suggested in last week's triage.  I'd still like to hear from ibarlow, but since the Beta uplift window is narrow, I figured it'd help to at least have a patch to mull over.  I'll also attach a screenshot of the icon in action.
Attachment #8426577 - Flags: review?(blassey.bugs)
Comment on attachment 8426577 [details] [diff] [review]
patch v1: use the "app" (i.e. rocket ship) icon

Review of attachment 8426577 [details] [diff] [review]:
-----------------------------------------------------------------

The code is right. Asking Ian for review (why isn't the ui-review flag available here??)
Attachment #8426577 - Flags: review?(ibarlow)
Attachment #8426577 - Flags: review?(blassey.bugs)
Attachment #8426577 - Flags: review+
Sorry for the delayed response here -- using the rocket makes sense to me. Ship it! :)
Flags: needinfo?(ibarlow)
Attachment #8426577 - Flags: review?(ibarlow) → review+
https://hg.mozilla.org/mozilla-central/rev/6c437fc1b14f
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 32
Comment on attachment 8426577 [details] [diff] [review]
patch v1: use the "app" (i.e. rocket ship) icon

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
  Bug 934760

User impact if declined: 
  Users will see a scary icon in their notification bar.

Testing completed (on m-c, etc.): 
  This landed on Central last week.

Risk to taking this patch (and alternatives if risky): 
  No risk, this is a simple, obvious icon replacement.

String or IDL/UUID changes made by this patch:
  None.
Attachment #8426577 - Flags: approval-mozilla-beta?
Attachment #8426577 - Flags: approval-mozilla-aurora?
Attachment #8426577 - Flags: approval-mozilla-beta?
Attachment #8426577 - Flags: approval-mozilla-beta+
Attachment #8426577 - Flags: approval-mozilla-aurora?
Attachment #8426577 - Flags: approval-mozilla-aurora+
The fix accidentally got reverted in this merge from Central to Inbound <https://hg.mozilla.org/mozilla-central/rev/3078d2486cab>, so it needs to be relanded:

https://hg.mozilla.org/integration/fx-team/rev/efe59836ffc3
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
https://hg.mozilla.org/mozilla-central/rev/efe59836ffc3
Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
Verified fixed on Firefox 30 Beta 10
Verified fixed on:
Device: Samsung Galaxy Nexus
OS: Android 4.2.1
Build: Firefox for Android 32 Beta 1
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.