> 1) From a UX perspective, what kinds of things are we going to allow this
> add-on to put in the snippet/promo banner? The banner itself is going to be
> made in our native Java UI, so if we want to design a JS API that add-ons can
> use, we'll have to be explicit about what things that API can do. I was
> thinking that we would just let them provide an icon and some text, which
> matches this mock-up that ibarlow created: http://cl.ly/image/3j0i1w2x1s1x.
When I proposed splitting out this work, my motivation was to allow for
partners (and ourselves) to do things that are more useful than just
image+text+link (which was the original scope of dynamic snippets). That is to
say, we have two banners right now:
* Sync: checks to see if an account exists; launches an Android activity
* Marketplace: checks to see if you've accessed Marketplace, launches some
privileged page or activity
and precisely zero of those would be possible with Dynamic Snippets.
We should be able to build a promo banner as an add-on for the new about:home
(that is, it owns a region and can handle user interaction with it), and a
"dynamic snippets add-on" would be one such add-on that happens to grab its
driving content from the web to support the simple clickable "banner ad"
sub-use-case. We might use add-ons to allow partners or ourselves to support
other, richer, home-screen interactions.
My feeling is that if we scope this down to "build Dynamic Snippets but as an
add-on", and don't expose any richer capabilities, then we're building
something that meets our needs no better than the original project did. I'm
hoping that I'm just misunderstanding this thread in that regard :D
_______________________________________________
mobile-firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/mobile-firefox-dev
