748955 - Store installed apps in places so awesomebar and new tab can include apps

Status: RESOLVED INCOMPLETE

(Toolkit :: Places, defect)

Description

[Asa Dotzler [:asa]]

We need to create a places entry for installed apps so that we can integrate app launching into the Awesomebar and/or the New Tab Page. Ideally we'd be able to also track app loads like we do page loads so we can raise or lower visibility based on "frecency" or something similar. Also, we might want to give these entries their own type so we can boost or demote appropriately.

Comment 1

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Needs clarifications on what we consider a "visit" of an app. Is opening the app from the desktop considered a "visit", for example? (not sure how to detect that though, since the firefox profile may not be open). Is the app being open in Firefox or standalone?

Adding data to the locationbar results is easy, in a certain position, right now we have:
1. unstorable switch-to-tab entries
2. adaptive results ordered by ratio
3. common results ordered by frecency

Properly generate a frecency out of artificial data is quite dangerous and may bring unexpected ordering (the frecency algo is quite complicated and mostly based on visits), so either we add apps into a certain position in the results, or we try to mixup them to adaptive results, so that typing a certain token may suggest an app or a page based on how often the user selected that app typing that token.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

I was thinking of two ways we could do something like this:
- add synthetic webapp://<appname> history entries for installed apps that trigger a protocol handler that just launches the web app, and let them participate in the normal autocomplete/newtab behavior (perhaps with somehow increased weighting?)
- a variant of switch-to-tab (switch-to-app). This wouldn't have any impact on the newtab page, but it might be simpler?

Comment 3

[Dietrich Ayala (:dietrich)]

The switch-to-tab approach doesn't get us benefits like frecency and adaptive matching. Adaptive matching in particular is pretty important IMO, since it lets users' app usage directly control how visible the apps are, much sooner than frecency will.

The webapp://<appname> approach allows Apps to be mostly baked-in to a lot of features, with the question then being where we restrict them (eg: New Tab Page) or visually differentiate them.

Comment 4

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

yeah, the webapp stuff sounds interesting, it introduces still something to evaluate:
- these should likely not appear in any UI view, like the History menu? Or we expect them to just appear as common visits?
- Should the entries expires naturally if the app is not used for lot of time, and should the user be able to "forget this site"?
- Sync should probably not sync them cause the app may not yet be synced, and would bring zombie entries elsewhere
- We must ensure that the entry for an app is removed when the app is uninstalled

Comment 5

[Ed Lee :Mardak]

Anant is implementing apps-in-the-cloud which uses the existing installed-app storage mechanism and adds in knowledge of remotely acquired apps.

How should the existing storage interact with this places storage of installed apps?

An app can be acquired and installed where the user can launch the app from, say, /Applications folder on OS X. The user can delete that file and the app is effectively no longer installed but still acquired. Similarly with apps-in-the-cloud, remotely acquired apps aren't necessarily installed.

I would assume awesomebar/new tab would only be able to launch apps that are natively installed?

Comment 6

[Jason Smith [:jsmith]]

Could implementing this feature create confusion to the user? What added value does this provide over having native-installed apps already existing? Why does an additional "dashboard" outside of a user's native machine provide more value?

Comment 7

[Jason Smith [:jsmith]]

See https://bugzilla.mozilla.org/show_bug.cgi?id=748962#c3. We need to evaluate the value of including this is firefox or not. If it ends up being a true nice to have, then I question if this is part of k9o.

Comment 8

[Tan Wei Lin Jason [:Ryuji]]

isn't About:apps supposed to be the place to house the apps? Randomly placing apps everywhere has the potential chance of confusing users. Wouldn't making awesome bar be able to search about:apps a much easier approach than re-creating a page for apps?

Comment 9

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

not happening.