Closed Bug 738546 Opened 12 years ago Closed 12 years ago

[meta] Native Install Basic App - Phase 1

Categories

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

ARM
Android
defect
Not set
normal

Tracking

(blocking-kilimanjaro:+, blocking-fennec1.0 -)

RESOLVED FIXED
Firefox 15
blocking-kilimanjaro +
Tracking Status
blocking-fennec1.0 --- -

People

(Reporter: jarguello, Unassigned)

References

Details

(Keywords: meta, Whiteboard: [k9o:p1:fx15?], [Phase1], [qa-])

Attachments

(1 file, 3 obsolete files)

      No description provided.
OS: Mac OS X → Android
Hardware: x86 → ARM
blocking-fennec1.0: --- → ?
Whiteboard: WebRT Phase 1 → [WebRT:Phase1]
blocking-fennec1.0: ? → -
Adding a bit more information. UX will supply the interactive flow to this bug.

Requirements:
* At purchase time, whether free or paid, the user's receipt must be updated 
* Native installation means a launcher for the app is put on the user's home screen

First time marketplace and install of basic free app:
* User found an app on the web
* User goes through the install process for the marketplace
* User logs in to marketplace
* Post marketplace install - the details page of the app is shown
* User taps to install
* the free basic app is installed on the home screen


First time marketplace and install of premium basic app:
* User found an app on the web
* User goes through the install process for the marketplace
* User logs in to marketplace
* Post marketplace install - the details page of the app is shown
* User taps to buy
* User goes through paypal flow
* the premium basic app is installed on the home screen

Install of basic free app:
* User finds an app on the marketplace
* User goes to the details page of the app 
* User taps to install
* The free basic app is installed on the home screen

Install of basic free app:
* User finds an app on the marketplace
* User goes to the details page of the app 
* User taps to install
* The free basic app is installed on the home screen

First time marketplace and install of premium basic app:
* User finds an app on the web
* User goes to the details page of the app 
* User taps to buy
* User goes through the Paypal flow
* The premium basic app is installed on the home screen


Non-goal for Phase 1: An updated permissioning model for advanced apps. 

Questions:
1. Are their any notifications that need to occur during install? Post install?
2. Will installing app data locally for caching, be supported in Phase 1?
(In reply to Jennifer Arguello :ticachica from comment #1)
> Adding a bit more information. UX will supply the interactive flow to this
> bug.
> 
> Requirements:
> * At purchase time, whether free or paid, the user's receipt must be updated 

Where is the user's receipt updated?

> * Native installation means a launcher for the app is put on the user's home
> screen
> 
> First time marketplace and install of basic free app:
> * User found an app on the web
> * User goes through the install process for the marketplace
> * User logs in to marketplace
> * Post marketplace install - the details page of the app is shown
> * User taps to install
> * the free basic app is installed on the home screen
> 
Questions:

1. What about the case when a user installs an app from a website hosting the app?
2. What about error conditions during this use case? Say installation fails (e.g. internet connection goes out). What would a user expect to see?
3. Originally Soup I remember would launch the app post install. Are we still doing that? Or not? Or is it out of scope for this first release?

> 
> First time marketplace and install of premium basic app:
> * User found an app on the web
> * User goes through the install process for the marketplace
> * User logs in to marketplace
> * Post marketplace install - the details page of the app is shown
> * User taps to buy
> * User goes through paypal flow
> * the premium basic app is installed on the home screen
1. Behind the scenes, what is the difference between installing a paid app and a free app? As in, where's the receipt going for the application bought?
2. What are the error conditions to this use case to handle? For example, lets say the internet goes out during a paypal purchase flow. How does that affect the install process of a paid app?
Depends on: 741608
Depends on: 741609
Depends on: 741621
Component: General → Web Apps
Depends on: 741466
Keywords: meta
Whiteboard: [WebRT:Phase1] → [Phase1]
Summary: Native Install Basic App → [meta] Native Install Basic App
Note this is a tracking bug for the first phase of the web apps integration into fennec native.
Summary: [meta] Native Install Basic App → [meta] Native Install Basic App - Phase 1
QA Contact: general → web-apps
Whiteboard: [Phase1]
Depends on: 741472
Depends on: 741471
Depends on: 741468
Depends on: 741464
Depends on: 741439
Depends on: 741436
Depends on: 741435
Depends on: 741432
Depends on: 741431
Depends on: 741430
Whiteboard: [Phase1]
Whiteboard: [Phase1]
No longer depends on: 741432
No longer depends on: 741436
No longer depends on: 741439
No longer depends on: 741464
No longer depends on: 741466
No longer depends on: 741435
No longer depends on: 741471, 741472
No longer depends on: 741621, 741609
Whiteboard: [marketplace-beta?]
Target Milestone: --- → Firefox 14
First draft to answer the UX bugs blocking this ticket. Please give feedback, so we can clarify.
Feedback questions below:

1. Launcher UI shown - The UI looks like it allows you to have a launch button to directly launch it. What UI is this linked to (e.g. would this fall under about:apps, is this a special UI only shown post install)?
2. How does about:apps tie into this process?
3. Clicking the notification that the app was successfully installed - Does that launch the app?
4. "App already installed" message - What happens if they want to reinstall intentionally? Would it be better to still prompt the user for install, but with a reinstall message instead?
5. What happens if the installation involves upgrading an existing app installation?
6. "Initialization/Installed Failed" - How? We'll want to define what error messages to throw to clearly provide direction to the user. If there's error messages the mozApps API throws that could be useful to show to the user, then we may want to show it here.
7. What happens if an app is reinstalled in a different type state (before: installed as free, after: reinstall as paid)?
8. How does localization and internationalization concerns addressed in this UX flow? For example, what happens if the app is not allowed in a certain country? Also, are there different UX flows to consider based on country locale?
9. What happens if I install an app that is blacklisted by the marketplace as an "unsafe" app to install?
10. What are the differences in the UX flow with paid apps? How do error cases with paid apps affect the UX flow (e.g. corrupt/invalid receipts)?
To add to the list:

i) What happens if users dont respond to notifications built-up in the Android notification tray, and a corresponding connection to an application is lost should one uninstall the app or the package entirety?
Thanks for the detailed feedback Jason and Aaron. It's has a lot of things we need to keep in mind for the coming phases.

1. The UI shown is the Marketplace. It doesn't have to change from "Install" to "Launch" button, but that's the experience in the Android Store. As launch doesn't even work in Windows, as we heard in yesterdays meeting, we might just switch to "Installed". But that's Marketplace UX.
2. The install flow triggered from about:apps should be the same flow. Other than that, about:apps is not involved in the install flow for Phase 1.
3. Yes, clicking the notification will launch the app and dismiss the notification. This mimics the native Android install.
4. Following yesterdays meeting, we should trigger a Re-install flow. But as its unclear, I added the note. TBD
5. Upgrade would not be Phase 1; but as we would update the shortcut on Re-install, that would be no issue if we follow this path.
6. "Invalid manifest content-type" might not help the user, but it might be helpful for feedback during Beta. Error messages TBD.
7. I don't know if paid/free apps would be the same origin. TBD, but not for Phase 1
8. Strings should be localized. I can't imagine reasons about changing the flow based on locale, could be after Phase 1. As for country-restrictions, not Phase 1.
9. Blacklist feature TBD, not Phase 1.
10. Correct me if I'm wrong,: Receipt validation is done in-app, WebRT UI should not be involved.

i) The notification is sticky and can be only removed manually (ICS swipe left) or by clearing all notifications. if the user does not click the notification, she can still launch the shortcut. We did not discuss the launch behavior should change when the launch process is corrupted wasn't considered for install. If Fennec is missing, Android will show "Application not available". And so far we did not add restrictions to the Fennec WEBAPP Intent that limits launch behavior to "installed" apps only. We might consider that for security.
Are we using Persona.org accounts to sign into the marketplace?  If so, what happens if the user has multiple personas, where the accounts contains different apps in those?   Would they then log into the dashboard and see a merged set of Apps displayed, or it would only show the Apps available for that particular account?

My guess is this would be phase 2 work -- handling multiple accounts.
Login to Marketplace and Dashboard are separate until we add "Sign in to the Browser" or an intermediate solution (Sign in once to Marketplace & AITC. I understand that this is a weird flow, being logged in as 2 different users and buying an app in the Marketplace that would get synced into another AITC account.

Tracked in bug 738546.
Depends on: 744457
Added some detail to clarify questions and modified Re-install flow.
Just a note: Fennec uses a prompt, not doorhanger, for the install flow - which is consistent with the spec - but we don't really support custom icons in either doorhangers or prompts.
That should be ok Phase 1. When the prompt supports icons, the implementation should follow decisions made in bug 735680 and bug 740957; which currently means not showing the app icon, but a generic app icon.
Whiteboard: [marketplace-beta?]
Attached image Updated wireframes (obsolete) —
Incorporated comments from other bugs.
Incorporated comments from this and other bugs.
Attachment #613812 - Attachment is obsolete: true
Attachment #614065 - Attachment is obsolete: true
Attachment #616673 - Attachment is obsolete: true
Feedback:

- Are we going to incorporate the app rocket icon that desktop uses?
Blocks: k9o-webrt
blocking-kilimanjaro: --- → +
Whiteboard: [k9o:p1:fx15?]
Is bug 744457 really part of this meta bug? It almost sounds like a separate feature (although the separate feature is part k9o and phase 1. I just question if it belongs here).
Removing bug 744457 from this meta bug, as that is not part of this user flow for installing an application.
No longer depends on: 744457
Depends on: 749618
Whiteboard: [k9o:p1:fx15?] → [k9o:p1:fx15?], [Phase1]
Depends on: 740588
(In reply to Jason Smith [:jsmith] from comment #15)
> Feedback:
> 
> - Are we going to incorporate the app rocket icon that desktop uses?

Ian who works with Mark is looking into this. The current UX attached here looks good to me.
Attachment #616674 - Flags: feedback+
No longer depends on: 741430
Depends on: 741430
Target Milestone: Firefox 14 → Firefox 15
Closing this bug, as the installation flow feature implementation is done. Meta bug tracking will be done in bug 766259.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [k9o:p1:fx15?], [Phase1] → [k9o:p1:fx15?], [Phase1], [qa-]
No longer depends on: 749618
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: