If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[Rocketbar] Add local app search to rocketbar

RESOLVED FIXED in 1.3 C1/1.4 S1(20dec)

Status

Firefox OS
Gaia
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: kgrandon, Assigned: kgrandon)

Tracking

unspecified
1.3 C1/1.4 S1(20dec)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [c= p=3 s=2013.12.20 u=])

Attachments

(1 attachment)

(Assignee)

Description

4 years ago
Rocketbar should be able to search local applications.
(Assignee)

Comment 1

4 years ago
Created attachment 8342759 [details] [review]
Pull request - Search local apps in rocketbar

This is a fairly rough implementation of local app search. I'm just doing some prototyping here to see what it would be like to have multiple providers.
Attachment #8342759 - Flags: review?(21)
Comment on attachment 8342759 [details] [review]
Pull request - Search local apps in rocketbar

r+ with nits. It also seems to me that each provider creating their own set of results is bad, we want something that get all them and filter, format them the way it likes.

Do you know if Kyle has finished the bookmarks to datastore code? That would be nice to start using it to provide also bookmarks results.
Attachment #8342759 - Flags: review?(21) → review+
Kyle hasn't finished the bookmarks to Datastore code yet, no. We need to figure out how the whole of the Places database (places, visits, bookmarks, icons) in the system app is going to be shared between all the apps that need to access it in different forms. I have an early proposal here https://etherpad.mozilla.org/system-browser but we're still working out the details.

Homescreen needs a list of bookmarks and access to icons. The system app needs to record new places, visits and icons. The search app needs to query a list of places sorted by frecency and access icons and possibly know whether a place is bookmarked. It's not yet clear which app will be responsible for listing browser history.

We also need to think about how we will go about ranking local results against each other. If we have a separate search implementation for each data source (apps API, contacts API, browser history DataStore etc.) then this could be tricky.

When we discussed the possibility of a Search API back in March [1][2] a hot topic was "what's the web-like way to do this?" rather than just copying how other proprietary mobile platforms work.

One possibility I wondered about recently was that rather than use the Apps API to search for app names, we could record visits to apps in the places database like we do with web sites, storing the URL and title. Then we could keep track of the frecency of app use vs. site use and rank the results accordingly. The system app would keep a browser history of app access as well as web site access.

If you take this idea to the extreme, if the contacts app was implemented in such a way that every contact had its own URI, say contacts.gaiamobile.org/#contact001 then we could actually record the frecency of individual contacts by their URI. We wouldn't need to query the contacts database at all, just treat it like any other URI.

That's a very simplistic model and we'd probably need to be a bit smarter than that with other heuristics to weight certain results over others given different circumstances but I think it's worth bearing in mind.

Another alternative to implementing different search providers using different APIs is to have a standard DataStore schema and expose all the data sources through a DataStore maintained by a corresponding app (Homescreen for apps, Contacts for contacts etc.)

For example:

{
 title:
 url:
 iconUrl:
 score:
}

This is more exstensible and could be made available to third party apps in future but it doesn't solve the problem of how to have a consistent scoring system between data sources.

1. https://groups.google.com/forum/#!searchin/mozilla.dev.webapi/search$20api/mozilla.dev.webapi/PWU72mpNhBk/XzPRNsEosvsJ
2. https://groups.google.com/forum/#!searchin/mozilla.dev.webapi/search$20api/mozilla.dev.webapi/Rirh6xGPzDk/OouZD65mJyoJ
Also note Gordon's work on Accumulators, with a view to combining results from different sources asynchronously https://gist.github.com/gordonbrander/6969015

We've been working on this for some time.
(In reply to Ben Francis [:benfrancis] from comment #3)
> we could
> keep track of the frecency of app use vs. site use and rank the results
> accordingly. The system app would keep a browser history of app access as
> well as web site access.

A bit like this https://github.com/vingtetun/gaia/commit/a6ea86389f7a9b7db75f7262a2af0170102a68ce
(Assignee)

Comment 6

4 years ago
I think some kind of unified datastore is the appropriate way to do this. I also think we should build this in a way that allows for the search results app to not be aware of new applications, but be able to display results from them if we want to add them.

I think we may be able to do something fairly elegant if we have multiple apps publishing results to some shared datastore. I'll work on a prototype if I have time.
(Assignee)

Comment 7

4 years ago
Landed in rocketbar branch: https://github.com/mozilla-b2g/gaia/commit/6afd64ef4e756c045e06b8613a0c857b1a296fec
(Assignee)

Updated

4 years ago
Summary: Add local app search to rocketbar → [Rocketbar] Add local app search to rocketbar
(In reply to Kevin Grandon :kgrandon from comment #6)
> I think we may be able to do something fairly elegant if we have multiple
> apps publishing results to some shared datastore. I'll work on a prototype
> if I have time.

The problem with that approach is that we'd need to be able to trust all apps to write to the DataStore and figure out how to rank results against each other.

As we agreed in the meeting yesterday, I'm starting work on creating the Places database for the system app which can expose places data to the search app via a DataStore including frecency which we can use for ranking. This can include entries for both apps and other web pages which are all we care about for 1.4.

The places DataStore can act as our unified DataStore, with the system app being the only app trusted to write to it. The search app may wish to create an index of this DataStore in IndexedDB in order to get a cursor over search results ordered by frecency.

I think this solution has scope to solve the other use cases like contacts as well in future by using URLs, but if that doesn't work then we can discuss other solutions at a later date. That might include each app exposing its search data via DataStores with a standard schema which the search app can aggregate into a single index, but we'd still need to figure out search ranking.
(In reply to Ben Francis [:benfrancis] from comment #8)
> I'm starting work on creating the
> Places database for the system app which can expose places data to the
> search app via a DataStore

That's bug 946778
We may want to make this a duplicate of bug 948310 if we use the Places DataStore for local app search.
See also bug 948312
(Assignee)

Comment 12

4 years ago
Resolving bugs which have landed in the rocketbar branch to clean up the dependency tree. All commits in the branch have been reviewed, and we can merge it into master at any point.
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
(Assignee)

Updated

4 years ago
Whiteboard: [c= p=3 s= u=] → [c= p=3 s=2013.12.20 u=]

Updated

4 years ago
Target Milestone: --- → 1.3 C1/1.4 S1(20dec)
I assume this has now landed on master?

The spec asks for app results and bookmark results to be displayed together, but I assume this patch only searches apps? If we're not using the Places database for app search, how will we also display bookmark results and sort them against app results? Do we have a bug tracking that requirement?
Flags: needinfo?(kgrandon)
(Assignee)

Comment 14

4 years ago
(In reply to Ben Francis [:benfrancis] from comment #13)
> I assume this has now landed on master?
> 
> The spec asks for app results and bookmark results to be displayed together,
> but I assume this patch only searches apps? If we're not using the Places
> database for app search, how will we also display bookmark results and sort
> them against app results? Do we have a bug tracking that requirement?

We are searching local apps, and I assumed that bookmarks would be searched as part of places, but maybe my understanding of that is old/outdated. Let's open a new bug for bookmarks though.
Flags: needinfo?(kgrandon)
(In reply to Kevin Grandon :kgrandon from comment #14)
> We are searching local apps, and I assumed that bookmarks would be searched
> as part of places, but maybe my understanding of that is old/outdated. Let's
> open a new bug for bookmarks though.

Please see page 33 of the UX spec.

The point that I was trying to make was that this implementation of app search may make it difficult to combine app and bookmark results. Maybe we should re-consider a unified datastore as you said above.
(Assignee)

Comment 16

4 years ago
(In reply to Ben Francis [:benfrancis] from comment #15)
> (In reply to Kevin Grandon :kgrandon from comment #14)
> > We are searching local apps, and I assumed that bookmarks would be searched
> > as part of places, but maybe my understanding of that is old/outdated. Let's
> > open a new bug for bookmarks though.
> 
> Please see page 33 of the UX spec.
> 
> The point that I was trying to make was that this implementation of app
> search may make it difficult to combine app and bookmark results. Maybe we
> should re-consider a unified datastore as you said above.

This is definitely something I would love to consider - and possibly do a prototype of. We had a long discussion of this in paris - and decided that for 1.4 there would be no inter-mixing of results. It would just be too difficult to do well in the 1.4. timeframe. For 1.4 each search source will need to have it's own results container. 

With the current implementation I think we can very easily group them together, but not easily sort them. E.g., 

<div class="local-apps"></div>
<div class="bookmarks"></div>
You need to log in before you can comment on or make changes to this bug.