Closed Bug 741430 Opened 12 years ago Closed 12 years ago

On install of a web app, show a system notification

Categories

(Firefox for Android Graveyard :: Web Apps (PWAs), defect)

ARM
Android
defect
Not set
normal

Tracking

(blocking-kilimanjaro:+, firefox15 verified)

VERIFIED FIXED
Firefox 15
blocking-kilimanjaro +
Tracking Status
firefox15 --- verified

People

(Reporter: jsmith, Assigned: mfinkle)

References

Details

(Whiteboard: [Phase1])

Attachments

(4 files, 2 obsolete files)

Steps:

	1. Install the latest fennec native nightly
	2. Go to apps.mozillalabs.com/appdir
	3. Select an app to install
	4. Select ok

Expected:

A notification should indicate to the user where the app is installed (e.g. installed to "about:apps").

Actual:

The prompt closes. A user would have no sense of knowing what happens post clicking the install button. Did the install pass? Did the install fail? Where did it go?

Additional Notes:

This is a UX bug. This use case should follow gulf of evaluation principles (http://en.wikipedia.org/wiki/Gulf_of_evaluation) post install of an app.

Device: Samsung Galaxy Nexus
OS: Android 4.02
Build: Fennec Native Nightly
Whiteboard: [webapp]
Whiteboard: [webapp] → [WebRT]
What we do now is the same thing we do for Add-ons. We do not tell the user that the add-ons are visible in about:addons. We also do not switch to about:addons after installation.

Should we not be consistent?
Component: General → Web Apps
Assignee: nobody → bdils.mozilla
Whiteboard: [WebRT]
Blocks: 738546
QA Contact: general → web-apps
Implementation suggestion until we have install UX flows:

To mimic the native Android behavior, a sticky notification "App Name \n Installation successful" should be added to the Android notifications and launch the app when clicking it.

I also pitched this in the UX meetings. With this solution the user can a) launch the app right after install b) can continue installing other apps without interruption and c) does not need to find the icon on the homescreen after launch.

Thoughts?
Whiteboard: [marketplace-beta?]
Whiteboard: [marketplace-beta?]
Summary: On install of a web app, the user should be notified where the app is installed → On install of a web app, show a system notification
Attached patch WIP 1 (obsolete) — Splinter Review
This is basically done and works, but we need a specific icon for the system notification. Currently, I am using the add-on icon.
Assignee: bdils.mozilla → mark.finkle
Attachment #621427 - Flags: feedback?(wjohnston)
Ian - We need two sizes for the new icon, looking at the add-on icon as a template:
http://mxr.mozilla.org/mozilla-central/find?text=&string=alertaddons.png
Mark - We have icons for apps doorhangers on desktop on bug 735680. Would those icons work?
See Also: → 735680
(In reply to Jason Smith [:jsmith] from comment #5)
> Mark - We have icons for apps doorhangers on desktop on bug 735680. Would
> those icons work?

They don't fit the Android style for system notifications, but Ian can use the design for making ones for us.
Whiteboard: [Phase1]
Nominating for k9o for the same reason given in a separate bug for desktop - not telling the user what happens after an install already has shown to be a significant UX issue on desktop, as users did not understand what happened (gulf of evaluation problem).
blocking-kilimanjaro: --- → ?
Attached file Android Alert Icons
Attached are a set of alert icons styled for ICS, and a set for GB. Included are icons for:

- Apps
- Add-ons
- Downloads

I've updated the look of the icons to be consistent with GB and ICS design guidelines, so when we add the apps icon please replace the other images as well (add-ons, downloads).

Thanks!
blocking-kilimanjaro: ? → +
Comment on attachment 621427 [details] [diff] [review]
WIP 1

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

::: mobile/android/chrome/content/browser.js
@@ +4818,5 @@
> +      };
> +
> +      let message = Strings.browser.GetStringFromName("webapps.alertSuccess");
> +      let alerts = Cc["@mozilla.org/alerts-service;1"].getService(Ci.nsIAlertsService);
> +      alerts.showAlertNotification("drawable://alertaddons", manifest.name, message, true, "", observer, "webapp");

Is this one notification per app, or do we want to combine if there are multiple (looking at the "webapp" bit here, do we want to append something more unique?)
Attachment #621427 - Flags: feedback?(wjohnston) → feedback+
(In reply to Ian Barlow (:ibarlow) from comment #8)
> Created attachment 621980 [details]
> Android Alert Icons
> 
> Attached are a set of alert icons styled for ICS, and a set for GB. Included
> are icons for:
> 
> - Apps
> - Add-ons
> - Downloads
> 
> I've updated the look of the icons to be consistent with GB and ICS design
> guidelines, so when we add the apps icon please replace the other images as
> well (add-ons, downloads).

Ian - I added these and tested them out. The icons seem to be a bit too big (the visual, not the image itself) compared to other status icons. Attaching a screenshot.
No longer blocks: 738546
Attached image screenshot of status icons (obsolete) —
This screenshot shows the download and app icons. They seem too big compared to the other icons.
Why was bug 738546 removed as blocking the phase 1 install flow? I thought this bug was part of that implementation.
(In reply to Wesley Johnston (:wesj) from comment #9)

> > +      let message = Strings.browser.GetStringFromName("webapps.alertSuccess");
> > +      let alerts = Cc["@mozilla.org/alerts-service;1"].getService(Ci.nsIAlertsService);
> > +      alerts.showAlertNotification("drawable://alertaddons", manifest.name, message, true, "", observer, "webapp");
> 
> Is this one notification per app, or do we want to combine if there are
> multiple (looking at the "webapp" bit here, do we want to append something
> more unique?)

We don't need to worry about uniqueness yet. Each app will make a different notification. Each notification is tied to a JS callback. Each callback knows which webapp to launch.

This is also how we do downloads, even though we pass a unique file cookie to the notification.

I should note that this requires Fennec to be running when the notification is tapped by the user. This is also how downloads works. We can file a follow to handle that differently, as it will require changes to the NotificationHandler.java file.
Flags: in-moztrap?(aaron.train)
Blocks: 738546
Updated alert icons can be downloaded here: 

The GB ones should be the correct size now http://cl.ly/23183o2n2K380K3I1J1C
This patch only changes the alert icons. The patch includes:
* simple name change for the image files to "alert_*"
* stop using the branding build-time hooks for the alert images. we should be putting the images in the right drawable folders now.
* updates the JS files that use named drawables to use the new names.

I tested the patch on gingerbread, froyo and ICS. The alert images look good and the right ones are used.
Attachment #626801 - Flags: review?(sriram)
this patch uses the new icons to show a system status notification when the app is installed. the patch waits for the "webapp-sync-install" notification to make sure we have a good webapp install before adding the system notification.
Attachment #621427 - Attachment is obsolete: true
Attachment #626808 - Flags: review?(wjohnston)
Attachment #625428 - Attachment is obsolete: true
that's more like it :)
Attachment #626808 - Flags: review?(wjohnston) → review+
Comment on attachment 626801 [details] [diff] [review]
use new alert icons

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

This looks good to me.
We don't need drawable-mdpi-v11/ and drawable-hdpi-v11/ versions, unless they are different from drawable/ and drawable-hdpi/
Please remove them if its the same. r+ with that change.
Attachment #626801 - Flags: review?(sriram) → review+
(In reply to Sriram Ramasubramanian [:sriram] from comment #19)
> Comment on attachment 626801 [details] [diff] [review]
> use new alert icons
> 
> Review of attachment 626801 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> This looks good to me.
> We don't need drawable-mdpi-v11/ and drawable-hdpi-v11/ versions, unless
> they are different from drawable/ and drawable-hdpi/
> Please remove them if its the same. r+ with that change.

The images are different
Blocks: k9o-webrt
https://hg.mozilla.org/mozilla-central/rev/7d34bf171096
https://hg.mozilla.org/mozilla-central/rev/760e8dcf3ed1
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 15
Whiteboard: [Phase1] → [Phase1], [qa+'
Whiteboard: [Phase1], [qa+' → [Phase1], [qa+]
MozTrap: https://moztrap.mozilla.org/manage/case/277/

--
Tested via:
Nightly (05/28)
Samsung Galaxy Nexus (Android 4.0.4)
Status: RESOLVED → VERIFIED
Flags: in-moztrap?(aaron.train) → in-moztrap+
Whiteboard: [Phase1], [qa+] → [Phase1]
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: