Custom descriptions for views

[seefeldb]

Right now we say things like "recommendation from list of Products (Minecraft and 3 more)", when it would be nice to say "recommendations from Claire's wishlist (Minecraft and 3 more).

Unpacking this, there are actually two requests: 1) A way for the view itself to have a name that is used in descriptions, replacing "list of Products" with "wishlist" 2) A modifier describing where that view came from, i.e. "Claire's". Right now the frontend does that, but in the future I'd imagine a strategy doing that.

[mariakleiner]

1. is already supported - view can have its own description: https://github.com/PolymerLabs/arcs/blob/master/runtime/browser/demo/recipes.manifest#L76 (and in the arcs browser demo the suggestion does say "Claire's wishlist"

re - 2: if the view was provided by a particle (that fetches wishlists from a certain service or smth) and that particle has description configured for its output view, this description would carry over to the next suggestions using this view.

[seefeldb]

1: Excellent, seems that this got lost in the recipe shuffle. I'll add it back.

2: It's being extracted from the other arc and inserted into the context by the frontend code. So the original particle isn't running, but the frontend code could probably play the same role? @noelutz?

[mariakleiner]

2. if the view in the original arc has the description, maybe we can just bring it into the arc together with the view itself? or is it not there in the original view?

[seefeldb]

(re 2.: it seems that should work! we'll try that tomorrow. the tests you wrote are also very helpful to understand how that all works!)

I tried

  create #wishlist as wishlist
    description `wishlist`

But that didn't work. This is an example of using a few generic particles in a new meaning that only emerges at the recipe level, so this would be quite useful. Should we add that or am I misunderstanding the concept?

The full recipe is:

recipe
  map WishlistCandidates as candidates
  create #wishlist as wishlist
  Chooser
    resultList = wishlist
    choices <- candidates
  ShowProducts
    list <- wishlist

[mariakleiner]

there is no support for the description in a recipe view (like the example you gave). the description now is only supported for particle view connections (and manifest views).

let me know if you think i should add descriptions to recipe views as well. ideally the recipe aren't hand-crafted and good descriptions are derived from properly-ranked particles, but until we get there, it is probably a good workaround - WDYT?

[seefeldb]

Yes, ideally they aren't handcrafted, so we should have an idea of where this could come from in the future, before we depend too much on it. But this is a good example for where the user would naturally add this, when somehow naming the arc or the arc's contents: It is a combination of particles that together now have a new meaning, the individual particles didn't have. So FTR, I could see these options:

1. User labels arc and while the view isn't labeled, we'd get something like "the product list from your wishlist arc", which isn't too boad.
2. User can label something they can point at, e.g. the product list particle can express that if a user points at it in the context of selecting data, that they mean the list. That way a view (or sometimes a couple of views together) get labeled
3. Users don't add descriptions, but the description comes from a future use: Somehow (TBD) the user connects this arc to a particle in another arc that describes it as "wishlist". That then back propagates. That is, the system just learned that this view is useful in that more specific context.

In the meantime, I think I can hack this by copying an empty list instead of creating one. Does the description get copied as well?

[mariakleiner]

I like option 3 the most (the less we depend on users to label stuff, the better the system is).

yes, if the manifest view has description and the recipe copies this view - the description will be copied too (if it isn't, this is a bug and i'll fix it:).

[mariakleiner]

@seefeldb now that we do have recipe descriptions, so probably adding descriptions to stores via recipe handle is reasonable and consistent. shall i add it, wdyt?

[shaper]

@seefeldb to comment on above.