UX issue brought up during hallway usability testing of open web apps. When a user uninstalls a web application from their native machine, it should correspondingly remove the application from the user's firefox profile. This promotes consistency across the applications stored in the profile (viewable and modifiable from the web) and on the native desktop. In this hallway usability testing, the user brought up that he expected that the application should have been removed from their profile when they removed from their machine. However, confusion arose when they discovered that firefox and the marketplace still thought the app was installed.

I think it's unwise to try to manipulate a Firefox profile from the webapp uninstaller. I discussed this with Myk and Felipe in #openwebapps; we're thinking that Firefox can detect whether apps are natively installed (using the Windows registry or possibly file location on mac?) and update the profile-based installations to match. Anant, will this cause any issues for AitC?

(In reply to Tim Abraldes from comment #2) > I think it's unwise to try to manipulate a Firefox profile from the webapp > uninstaller. > > I discussed this with Myk and Felipe in #openwebapps; we're thinking that > Firefox can detect whether apps are natively installed (using the Windows > registry or possibly file location on mac?) and update the profile-based > installations to match. Makes sense to me. The one thing to watch out for is that you are finding the "right" native app, not just that the app exists. There's been bugs that have been logged in regards to this issue (e.g. Reinstall in Mac causes duplicate apps).

So if I've installed an app on two desktop machines and uninstall it from one, it'll end up uninstalling from both?

(In reply to Tim Abraldes from comment #2) > Anant, will this cause any issues for AitC? It might. I think that could result in a case like the following: 1. I start my sync using BID against AITC 2. I pull my apps into my profile 3. Close Firefox 4. Restart Firefox My apps I just synced are gone. Anant - Could this scenario happen?

(In reply to Edward Lee :Mardak from comment #4) > So if I've installed an app on two desktop machines and uninstall it from > one, it'll end up uninstalling from both? My understanding is that installing the app on one machine would cause it to natively-install on every machine you log in to from that point forward. Then, uninstalling it from any of those machines would cause it to uninstall from all of them?

(In reply to Tim Abraldes from comment #6) > My understanding is that installing the app on one machine would cause it to > natively-install on every machine you log in to from that point forward. That seems odd because an app I use on the desktop I might not want taking up space on the phone. So even if it does appear natively on my phone and I remove it, it sounds like it would disappear from my desktop?

My understanding is that natively installing an app should cause Firefox to sync the app record to the cloud and thence to all your other devices, but it should not cause Firefox to natively install the app on any other device. And natively uninstalling an app should not cause Firefox to natively uninstall the app on any other device. So app records remain synced across all devices. But native installation is device-specific and must be user-specified. Once a user acquires an app, all devices receive its app record, so they all know it has been acquired. But the app is only installed natively on those devices on which the user explicitly requests native installation. Anant should confirm this, as should Diane, who is designing improvements to the UX for acquisition and native installation.

(In reply to Myk Melez [:myk] [@mykmelez] from comment #8) This is my understanding as well.

(In reply to Myk Melez [:myk] [@mykmelez] from comment #8) > My understanding is that natively installing an app should cause Firefox to > sync the app record to the cloud and thence to all your other devices, but > it should not cause Firefox to natively install the app on any other device. > And natively uninstalling an app should not cause Firefox to natively > uninstall the app on any other device. > > So app records remain synced across all devices. But native installation is > device-specific and must be user-specified. Once a user acquires an app, > all devices receive its app record, so they all know it has been acquired. > But the app is only installed natively on those devices on which the user > explicitly requests native installation. > > Anant should confirm this, as should Diane, who is designing improvements to > the UX for acquisition and native installation. Ah I remember this from the UX discussion from Tuesday. The difference between "acquring an app" vs. "installing an app," as we needed to distinguish between the two. Maybe what AITC refers to is apps acquired or not acquired, where as our interactions outside the scope of AITC refers to installs. It makes AITC then sound like almost like a history of your apps you've used in the past then (which is useful to have).

(In reply to Asa Dotzler [:asa] from comment #9) > (In reply to Myk Melez [:myk] [@mykmelez] from comment #8) > > This is my understanding as well. this is correct. the user will explicitly tell us which device they want to install an app to. the UI for this is ready and Jen will attach it to the appropriate bug.

So it sounds like we have the following possibilities for apps: Unacquired Acquired, but not natively installed on this device Acquired and natively installed on this device This bug, it seems, is really about being able to differentiate between the 2nd and 3rd states.

(In reply to Tim Abraldes from comment #12) > So it sounds like we have the following possibilities for apps: > Unacquired > Acquired, but not natively installed on this device > Acquired and natively installed on this device > > This bug, it seems, is really about being able to differentiate between the > 2nd and 3rd states. Sounds right to me. For AitC, it is important to to be able to programatically put an app into either 2 or 3. Currently, there is no way to put an app in state 2, the "install" method in DOMApplicationRegistry always implies state 3. A simple boolean flag to indicate this should be enough for AitC to be compliant with the proposed user experience. We can create a separate bug to make that change to the DOMApplicationRegistry.

(In reply to Diane Loviglio [:diane] from comment #11) > this is correct. the user will explicitly tell us which device they want to > install an app to. the UI for this is ready and Jen will attach it to the > appropriate bug. Will this UI belong in the dashboard? (In reply to Anant Narayanan [:anant] from comment #13) > A simple boolean flag to indicate this should be enough for AitC to be > compliant with the proposed user experience. We can create a separate bug to > make that change to the DOMApplicationRegistry. Filed Bug 752251.

Can someone answer my dumb question? I do not understand what is the user experience of keeping or deleting the data in the user's Firefox profile. Here's a sample use case to help me understand. 1. I'm on my Windows 7 machine using a Fx that supports apps and I have Twitter web app installed 2. I go to Control Panel -> Programs and Uninstall the Twitter web app 3. The shortcut on my desktop, twitter icon on my task bar, and Twitter in my Programs folder disappears correct? If the app is NOT removed from my Firefox profile what do I see? If the app is removed from my Firefox profile what do I see?

(In reply to Jennifer Arguello :ticachica from comment #16) > Can someone answer my dumb question? I do not understand what is the user > experience of keeping or deleting the data in the user's Firefox profile. > > Here's a sample use case to help me understand. > > 1. I'm on my Windows 7 machine using a Fx that supports apps and I have > Twitter web app installed > 2. I go to Control Panel -> Programs and Uninstall the Twitter web app > 3. The shortcut on my desktop, twitter icon on my task bar, and Twitter in > my Programs folder disappears correct? Yes. > > If the app is NOT removed from my Firefox profile what do I see? On marketplace for example, you would still see the app installed (http://screencast.com/t/ozvST7t0So9K). Krupa brought up a concern about this on Monday - This will likely create a lot of confusion for users on marketplace, since they will never realize that they can install the app again (the state of the profile at this point still says - "Yes the app is in my profile," so marketplace reflects it's UI in that direction). > > If the app is removed from my Firefox profile what do I see? You would see the install button again on marketplace. This would indicate to the user that they can install the app again.

jsmith: thanks for the explanation. Are there any other repercussions from removing the app from the user's Firefox profile? The profile is local correct and not synced? Let's say I have the Twitter web app on my work desktop and my home desktop. I uninstall it from my work desktop, the app will still be on my home desktop correct? I want to make sure we keep the characteristic that an uninstall is local and does not uninstall the same app on other devices. Thanks.

(In reply to Jennifer Arguello :ticachica from comment #18) > jsmith: thanks for the explanation. Are there any other repercussions from > removing the app from the user's Firefox profile? The profile is local > correct and not synced? Let's say I have the Twitter web app on my work > desktop and my home desktop. I uninstall it from my work desktop, the app > will still be on my home desktop correct? The repercussions of removing it from the local profile would be that it is removed on all your devics, but only because AITC behaves this way. > I want to make sure we keep the characteristic that an uninstall is local > and does not uninstall the same app on other devices. Thanks. As mentioned in comment #13, we can achieve this behavior by making a few tweaks to both the local profile code as well as AITC. The answer may simply be to mark the app in the local profile as being "uninstalled" instead of removing it entirely, and making it so that getInstalled() always returns apps that don't have the "uninstalled" bit set -- thus making the install button on the marketplace appear again. We won't synchronize this bit across AITC, and will remain fully local. Reinstalling the app after uninstall it would mean recreating the native app and resetting the "uninstalled" bit if one was found in the local profile. Myk, Tim, thoughts on this approach?

To elaborate a little more on comment #19, when we implement "Device API" support for AITC (which is coming soon™) the uninstall bit will be sent to the cloud as well, but only associated with that particular device. This unlocks two more pieces of functionality: a) Make a mirror image of your old phone on your new phone (backup/restore), b) Look at all the apps you have installed on your desktop. Ignoring whether or not these are useful features to have in the first place, I prefer the local uninstall bit technique simply because of this added flexibility ;) Additionally, removing an app from a local profile is currently interpreted as "remove this app from all my devices", which I presume is also a piece of functionality we'd like to expose to users at some point.

(In reply to Anant Narayanan [:anant] from comment #20) > b) Look at all the apps you have installed on your desktop. I really meant to say "look at all the apps you have installed on your desktop, from your phone".

Corrected the title based on the on-going discussion. Reword if it's incorrect.

(In reply to Anant Narayanan [:anant] from comment #20) > Additionally, removing an app from a local profile is currently interpreted > as "remove this app from all my devices", which I presume is also a piece of > functionality we'd like to expose to users at some point. You got that right. At this point we have just looked at app management on the current device, not app management across all devices. But we will at some point.

(In reply to Anant Narayanan [:anant] from comment #19) > Myk, Tim, thoughts on this approach? Sounds reasonable to me!

(In reply to Anant Narayanan [:anant] from comment #19) > (In reply to Jennifer Arguello :ticachica from comment #18) > The answer may simply be to mark the app in the local profile as being > "uninstalled" instead of removing it entirely, and making it so that > getInstalled() always returns apps that don't have the "uninstalled" bit set > -- thus making the install button on the marketplace appear again. We won't > synchronize this bit across AITC, and will remain fully local. Reinstalling > the app after uninstall it would mean recreating the native app and > resetting the "uninstalled" bit if one was found in the local profile. > > Myk, Tim, thoughts on this approach? Sounds good to me. Will the marketplace be able to tell the difference between a purchased app that happens to not be installed on the local device and an app that has not yet been purchased? Ideally it would have a different UI for "you already own this app, reinstall?" versus "buy this app!"

(In reply to Tim Abraldes from comment #25) > Sounds good to me. Will the marketplace be able to tell the difference > between a purchased app that happens to not be installed on the local device > and an app that has not yet been purchased? Ideally it would have a > different UI for "you already own this app, reinstall?" versus "buy this > app!" Good point! If we don't return apps marked as uninstalled via getInstalled() then the Marketplace will have to peek into the user's purchase history in order to determine what button to show. I think it is reasonable for the Marketplace to execute this kind of logic, but we should get somebody from the Marketplace team to verify this. On a slight tangent, this remind me of the problem of the same app being listed in more than one marketplace. If the user bought an app from store A, there is no way for store B to know that they did. We're not worsening that problem with the resolution of this bug though, so we should discuss possible mitigations for that separately.

(In reply to Anant Narayanan [:anant] from comment #26) > (In reply to Tim Abraldes from comment #25) > > Sounds good to me. Will the marketplace be able to tell the difference > > between a purchased app that happens to not be installed on the local device > > and an app that has not yet been purchased? Ideally it would have a > > different UI for "you already own this app, reinstall?" versus "buy this > > app!" > > Good point! If we don't return apps marked as uninstalled via getInstalled() > then the Marketplace will have to peek into the user's purchase history in > order to determine what button to show. I think it is reasonable for the > Marketplace to execute this kind of logic, but we should get somebody from > the Marketplace team to verify this. Wil: is this reasonable?

Krupa - Thoughts on comment 28?

(In reply to Tim Abraldes from comment #25) > Sounds good to me. Will the marketplace be able to tell the difference > between a purchased app that happens to not be installed on the local device > and an app that has not yet been purchased? Ideally it would have a > different UI for "you already own this app, reinstall?" versus "buy this > app!" Fortunately, this is in fact what happens. I open up a detail page from within the Marketplace on my desktop. I purchase an app. The button's life cycle is like this: $0.99 -> Purchasing -> Purchased -> Installed. http://i.imgur.com/6C7TK.png I open up the same detail page on my phone. Marketplace already knows that you purchased the app. The button begins life at Install (with a Purchased indicator below). http://i.imgur.com/h6ks0.png

The marketplace pieces seem to be in place already, and the AitC pieces are being worked on separately. Updating the title of this bug to reflect what I think is the remaining desktop piece that needs to be addressed. Since this is OS-specific, I'll file separate bugs for Linux, Windows, and Mac that will block this bug. Do we also need bugs for mobile and/or B2G?

(In reply to Tim Abraldes from comment #31) > The marketplace pieces seem to be in place already, and the AitC pieces are > being worked on separately. Updating the title of this bug to reflect what > I think is the remaining desktop piece that needs to be addressed. > > Since this is OS-specific, I'll file separate bugs for Linux, Windows, and > Mac that will block this bug. Do we also need bugs for mobile and/or B2G? Mark and Fabrice - Can you address Tim's question for Fennec Native & B2G respectively?

We don't need anything for b2g, since the web is native there.

(In reply to Tim Abraldes from comment #12) > So it sounds like we have the following possibilities for apps: > Unacquired > Acquired, but not natively installed on this device > Acquired and natively installed on this device Just to clarify. On Android, #3 does not exist. Instead, the situation is: Acquired and a shortcut to open the app exists on the homescreen Android does not seem to expose a way to programatically check to see what homescreen shortcuts exist. Nor do we have a way to be notified of when a shortcut icon is removed by the user. This might make it more difficult to achieve some of the desired goals. A separate bug might be needed.

Having the [blocking-webrtdesktop1+] flag on this meta-bug incorrectly suggests that all its dependencies are blockers, whereas in fact only the Windows and Mac ones are blockers; the Linux one is not. And the Windows and Mac dependencies are already flagged as blockers individually, so flagging this bug doesn't add much value. Thus I'm removing the flag from this bug.

(In reply to Myk Melez [:myk] [@mykmelez] from comment #35) > Having the [blocking-webrtdesktop1+] flag on this meta-bug incorrectly > suggests that all its dependencies are blockers, whereas in fact only the > Windows and Mac ones are blockers; the Linux one is not. And the Windows > and Mac dependencies are already flagged as blockers individually, so > flagging this bug doesn't add much value. Thus I'm removing the flag from > this bug. Makes sense. Given that this bug has now been broken up into three distinct pieces by each operating system, how should we utilize this meta bug (or better question is there value to keep it)? Just wondering cause we have a priority and milestone set on it, but the distinct pieces better define the true priority and milestone per piece (Windows & Mac are top priority in other words). My opinion - I'd be fine getting rid of this meta bug and just moving tracking to each OS implementation bug. We could do a see also to this bug on each OS-related bug to look at history of discussions on this bug.

Per Sheila, there is no need to track blocking k9o work for a specific Firefox release at this point.

So there's evident disagreement that the proposed title in this bug and approach right now is the way to go. I'll advertise on dev-webapps to continue the discussion on this bug to resolve what the best approach is. Note - this is blocking the 1st release of the desktop runtime, so we need to resolve this problem. I'll include my opinion shortly.

To backup to understand the stakeholder needs: - Marketplace team needs a way to detect if the app is natively installed through a JS-based API - WebRT team for desktop needs to solve the problem to distinguish whether an app is natively installed vs. acquired - AITC desktop in the same fashion defines apps as "acquired" when they pull apps locally - Firefox later will have apps integration directly into desktop firefox In short, we need a way to effectively handle these requirements above. The original proposal in this bug was to modify getInstalled() in mozapps to return the native apps installed, but there's disagreement here on that. We need to propose a solution that solves the requirements above. Thoughts?