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?

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.

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.

(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.