Hacking and customizing your device should feel rewarding. But these rewards shouldn’t get in the way of experienced developers. Thus, we introduce Badges. Badges will be rewarded when the user either follows a path that we want them to experience at least once, or accomplish something meaningful. They are like achievements for using your mobile device. When a badge is awarded to the user, a toast will appear on the bottom of the screen, with an icon, title, and description.

We should be aligned with the format for badges data used by Mozilla Open Badges: https://github.com/mozilla/openbadges-specification/blob/master/Assertion/latest.md After chatting with people working with badges it looks like we can collect badges locally as a first step, and then if there's connectivity we should be able to attempt to "claim" the badges.

Some more context from the log: [13:55:55] <yzen> ottonomy would you be the right person to ask some of the questions :) ? [13:55:59] <abbycabs> ottonomy: hey :) atul mentioned you [13:56:07] <ottonomy> Give it a shot. [13:56:57] <yzen> ottonomy so we want to give some sort of badges (or unlock achievements) for some of the actions users perform in Firefox OS [13:57:00] <ottonomy> We can ping any necessary others. I've been working pretty broadly across the specification and infrastructure, so I might be able to at least point you in the right direction. [13:57:51] <ottonomy> Cool. Deciding what you want to recognize with badges is a good step. Will Mozilla/Firefox OS be the organization that you want recorded as the issuer of the badges? [13:57:58] thisandagain (sid39659@moz-nmimo7.ealing.irccloud.com) joined the channel [13:58:24] <yzen> it might be one of the issuers yes [13:58:31] <yzen> and initially it will [13:58:36] <yzen> so i guess my first question is, can we use badges without without actually having any account (e.g. firefox accounts) and store a collection of badges locally on the device ? [13:58:49] <yzen> imagine a phone with no connectivity [13:59:29] <ottonomy> Right -- Badges work _to_some_degree_ when not connected, but some aspects require a connection. Let's see if we can work through it. [13:59:48] <yzen> yeah i can give you a usecase for example [14:00:50] <yzen> a user wants to customize an app in Gaia and uses another app "Customizer" to create an addon for the former app that changes some CSS [14:01:09] <ottonomy> In order to create a badge that can be verifiable, you either need to sign it with a crypto key or host a copy of the details corresponding to that user's instance on the issuer's site. The signed approach would probably be better for the volume of badges you might be issuing, but you don't want to have your issuer's private key stored on devices, so you'll likely need to make a request to a web server to actually retrieve a valid [14:01:09] <ottonomy> badge. [14:01:34] <yzen> ah [14:02:05] <ottonomy> You might be able to figure out a workaround for this... [14:02:50] <ottonomy> the device can know when various criteria were met, and can display the badges to the user in a badges app, but then when the user gets back to an internet connection and wants to do anything with the badges, you could have a "claiming" process, where they are actually issued. [14:03:31] <yzen> interesting that's actually what i was looking for [14:03:51] <ottonomy> I wonder if you are wanting to collect any artifacts of evidence for these badges? [14:04:33] <yzen> ottonomy so a badge is a result of a setting (mozSettings api) flipped from one value to another [14:05:15] <ottonomy> I would be interested in talking with you further (and maybe bringing in some other people) if you are interested in pursuing a model where users "apply" for badges (perhaps based on evidence, or perhaps based on a 3rd party badge) and then are awarded them directly from an issuer. [14:05:47] <ottonomy> I'm not steeped in FxOS enough to parse that last comment all the way [14:06:31] <ottonomy> I imagine you could build a badging app that can make decisions about what badges should be issued, and then transmit that information back to an issuer's server in a standardized fashion in exchange for actual valid badges [14:07:32] <yzen> ottonomy yes, but in case there's no connectivity ever, would we be able to still display those badges locally though not claimed ? [14:07:40] <yzen> ^ if im using the term correctly [14:08:22] <ottonomy> Yeah, I think you should build it so that the badges app knows what the badges are and what it takes to earn them, and can display what achievements the user has earned even before they are actual verifiable signed/hosted badges. [14:08:59] <ottonomy> But I would recommend building UI that makes it clear to the user which badges are "claimed" etc. [14:09:23] <yzen> gotcha [14:10:18] <yzen> ottonomy is there a particular format I would need to store the 'unclaimed' badges ? [14:10:34] <yzen> in [14:10:36] <ottonomy> "claimed" is a bit of a complicated word thrown around too liberally in the badges space. In this case, we mean something like "has actually been generated as a valid Open Badge and delivered to the recipient". Sometimes folks refer to badges that have already been created but not delivered yet to the recipient as "unclaimed", where the delivery is the defining step. Here, signing/hosting & delivery occur together. [14:11:07] <ottonomy> The concept of an unclaimed badge doesn't exist in the Open Badges spec, so there's no particular requirement for how you should store them. [14:11:47] <yzen> ottonomy sorry brb [14:12:05] <ottonomy> I'd probably use the real "BadgeClass" and "Issuer" objects though (You're probably familiar with the idea of the three parts that make up a valid badge from the spec: https://github.com/mozilla/openbadges-specification/blob/master/Assertion/latest.md ) [14:12:33] <ottonomy> Sure, I'll be afk on and off for the next few hours. I think you have most of what you need to know to take the next step.

Most of the technical and visual proposals are in this document under Badges: https://docs.google.com/document/d/1hEYlSV8IWCxyD_fRvkU6MV7wOWXd81Enpcva6ciM3sk/edit#heading=h.dr29gokx4jem

NI'ing patryk to keep it on his radar. There are several dependencies for this bug that are specific to separate achievements UI's

The app requires several icons for things like: the app itself, default icon for the empty badge, as well as some actual badge icons that are going to be collected when using Sharing, Customizer etc. Not sure whom to ping here.

Patryk, copying the proposed icon list from the email: * Icon for achievement when user customizes an app (Customizer) * Icon for achievement when user enabled sharing (Sharing) * Icon for achievement when user install an add-on (Directory/Hackerplace) We also need a default (non-specific) achievement icon placeholder and an icon for an app itself.

Doug, Fabrice, notice that for some reason new Notification does not trigger a desktop notification though the permission is added. I checked the logging and permission for notification is set to 'default' and not 'granted'.

Comment on attachment 8599400 [details] PR for Sharing achievement. Generally looks good. I left a few comments on the PR. We should figure out what's wrong with the notifications before landing.

(In reply to Doug Sherk (:drs) (use needinfo?) from comment #9) > Comment on attachment 8599400 [details] > PR for Sharing achievement. > > Generally looks good. I left a few comments on the PR. We should figure out > what's wrong with the notifications before landing. Thanks updated.

(In reply to Yura Zenevich [:yzen] from comment #8) > Doug, Fabrice, notice that for some reason new Notification does not trigger > a desktop notification though the permission is added. I checked the logging > and permission for notification is set to 'default' and not 'granted'. Where did you see this "default"? In the settings app? How did you re-install the app with your changes?

(In reply to Fabrice Desré [:fabrice] from comment #11) > (In reply to Yura Zenevich [:yzen] from comment #8) > > Doug, Fabrice, notice that for some reason new Notification does not trigger > > a desktop notification though the permission is added. I checked the logging > > and permission for notification is set to 'default' and not 'granted'. > > Where did you see this "default"? In the settings app? How did you > re-install the app with your changes? Looks like indeed it was an invalid installation, works now.

Comment on attachment 8599988 [details] PR for lightsaber build. We will need to begin pushing a pre-built version of this to the achievement repo's gh-pages branch. Just a heads up.

(In reply to Doug Sherk (:drs) (use needinfo?) from comment #14) > Comment on attachment 8599988 [details] > PR for lightsaber build. > > We will need to begin pushing a pre-built version of this to the achievement > repo's gh-pages branch. Just a heads up. Yep did that for the latest master.

Comment on attachment 8604711 [details] [gaia] yzen:bug-1156786 > mozilla-b2g:master Migrating achievements to Settings app.

Hi Amy, ni? you here since we brought achievement's ui up during today's standup

Comment on attachment 8604734 [details] Github PR for lightsaber build Looks good, thanks.

Hey Yura, following the link in comment 3 I did not find any UX spec or visual regarding the feature, could you help upload it to the bug? And I was wondering should this be a separate app?

(In reply to Arthur Chen [:arthurcc] from comment #21) > Hey Yura, following the link in comment 3 I did not find any UX spec or > visual regarding the feature, could you help upload it to the bug? And I was > wondering should this be a separate app? Hi Arthur, yes I think Amy is/will look into UX spec for it in the near future. In terms of the separate app, that was initially the case but then the conversation shifted to adding it to settings. ni? Doug here for some more details.

Amy and Jacqueline decided that, since Achievements are read-only, there was no reason to have a separate app for them. I think that putting the panel in the Settings app will make it harder to expand in the future, but we could always break it out into a separate app again in the future, if necessary.

Comment on attachment 8604711 [details] [gaia] yzen:bug-1156786 > mozilla-b2g:master Thanks for the patch! Generally it looks good. Please check my comments in github.

Design spec

Comment on attachment 8604711 [details] [gaia] yzen:bug-1156786 > mozilla-b2g:master Fixed all comments. Will wait for graphics to update the PR, the rest should be good to go. See design spec attached as well.

Comment on attachment 8610146 [details] PR for Sharing with an update to design spec minus graphics. Good, thanks. I left one question on the PR.

Comment on attachment 8604711 [details] [gaia] yzen:bug-1156786 > mozilla-b2g:master There are a few comments need to be addressed before merging. Please check them in github, thanks.

Comment on attachment 8604711 [details] [gaia] yzen:bug-1156786 > mozilla-b2g:master Updated to comments

Comment on attachment 8610146 [details] PR for Sharing with an update to design spec minus graphics. I landed this since it was breaking the Sharing app. https://github.com/fxos/sharing/commit/adea7fd85e333fc2cab5927e3d7adbf80c72ab1b

Comment on attachment 8604711 [details] [gaia] yzen:bug-1156786 > mozilla-b2g:master r=me, thanks!

Hey Arthur, Doug was asking if we can land the settings PR without the icons to be able to get some feedback from dogfooders, do you think that's acceptable or should we wait for default icons?

I think we can use an existing gaia icon for this time being. http://gaia-components.github.io/gaia-icons/#star-empty and http://gaia-components.github.io/gaia-icons/#star-full seem good.

(In reply to Arthur Chen [:arthurcc] from comment #34) > I think we can use an existing gaia icon for this time being. > http://gaia-components.github.io/gaia-icons/#star-empty and > http://gaia-components.github.io/gaia-icons/#star-full seem good. I think we are getting pretty close to final texts/icons, so it makes sense to wait a little bit to land once with all things ready.

Hi, I'm attaching the badge graphics, settings icon, text, and screen-mockup for the Achievements app. The copy is 95% final, there might be some minor badge name changes in the next day or 2.

Badge graphics

Achievement app copy

Achievements settings icon for Aries

Achievements Settings icon svg version

Updated screen with final copy.

Updated final copy

Comment on attachment 8617385 [details] Final PR for sharing Looks good, thanks.

Gaia: https://github.com/mozilla-b2g/gaia/commit/60a4e92e23b5e2d4ef826524c0b3bdc1a0310d33

Sharing: https://github.com/fxos/sharing/commit/75e15c5318fae7b368dd1d90e5396dec2c31079c

Comment on attachment 8620487 [details] Bugzilla Lite PR I am fairly dedicated to having bugzilla lite be a web application, ie hosted, accessible from the web, updatedable and deleteable from the homescreen etc. Are there solutions in which we can keep this to be a non certified propietary application?

I respect Dale's decision and I think we should just avoid having achievements for the Bugzilla Lite app for now, especially since our existing API is so restrictive.

Comment on attachment 8617955 [details] Hackerplace PR Will add the second achievement before asking for review.

Comment on attachment 8617955 [details] Hackerplace PR Added both achievements.

Comment on attachment 8617955 [details] Hackerplace PR Looks good, thanks.

sharing: * master: https://github.com/fxos/directory/commit/09bca5c5a87fdb69279bfa641ca3e851e890ceb9 * gh-pages: https://github.com/fxos/sharing/commit/298ceec2a78584e464a42170f2a6a77e132c08a7

Comment on attachment 8620990 [details] Settings UX refinements PR r=me, thanks.

Comment on attachment 8620990 [details] Settings UX refinements PR https://github.com/mozilla-b2g/gaia/commit/d7dfdab49ec2346e61b221f85ce08726aabc3634

Comment on attachment 8620390 [details] Studio PR No problem with the code change, and it is pretty cool :) But I wonder if we should maybe trigger the achievement when a theme is enabled. Or maybe both (creation / enabling). You can plug the achievement here [1] if you want to update the PR with enabling. [1] https://github.com/fxos/studio/blob/635f9db7481e6411ac2e1cb19fbd680565f9bb94/js/details.js#L114

(In reply to Etienne Segonzac (:etienne) from comment #60) > Comment on attachment 8620390 [details] > Studio PR > > No problem with the code change, and it is pretty cool :) > But I wonder if we should maybe trigger the achievement when a theme is > enabled. Or maybe both (creation / enabling). > > You can plug the achievement here [1] if you want to update the PR with > enabling. > > [1] > https://github.com/fxos/studio/blob/635f9db7481e6411ac2e1cb19fbd680565f9bb94/ > js/details.js#L114 Hi Etienne, we will keep adding more achievements to unlock, this one in particular is for creating a theme (the wording for instance) so hopefully its ok to add the second one at a later time

studio https://github.com/fxos/studio/commit/c1613b1630c00e016d04a55ed05c9d3c40cd88dd

Comment on attachment 8621743 [details] Customizer launcher PR LGTM. Thanks!

Customizer launcher https://github.com/fxos/customizer-launcher/commit/b2dd5bb9af3d5a845ac5f7b3d2ce1273ef064756

Comment on attachment 8621135 [details] PR for customizer import addon achievement. Is there a reason to put achievements-service.js in shared folder? If yes, please test it in sharedtest app. If not, please consider to put it in system app and use the libraries in system app.

settings string update: https://github.com/mozilla-b2g/gaia/commit/7dda863fb006fd3cb77c8e92aec739b2f829115b

Hi, I was looking at the achievements screen and I think the disabled achievements should be set to greyscale. Let me know if you need graphics for these. Thanks!

(In reply to (inactive after 6/18) Alive Kuo [:alive] from comment #67) > Comment on attachment 8621135 [details] > PR for customizer import addon achievement. > > Is there a reason to put achievements-service.js in shared folder? There's a good chance that other apps will need to use achievements-service to reward achievements, so I am preemptively putting it in sharing. > If yes, please test it in sharedtest app. > If not, please consider to put it in system app and use the libraries in > system app.

system: https://github.com/mozilla-b2g/gaia/commit/6271f932e1e918a35ee89f54288bd13385143a71

Grayscale settings: https://github.com/mozilla-b2g/gaia/commit/da18c1c66d2d40bea565a7af1252eafbc5d2d483

Looks like all prs are merged in and dependencies resolved. Closing as fixed.

This patch makes a bad use of L10n API because it creates localized name/description early and stores them. Instead of: achievementsService.reward({ name: _('achievements-add-on-all-star-name'), description: _('achievements-add-on-all-star-description'), }); and then: AchievementsService.prototype.reward = function (_ref) { var name = _ref.name; var description = _ref.description; var notification = new Notification(name, { body: description, }); } it should be: achievementsService.reward({ nameL10n: 'achievements-add-on-all-star-name', description: 'achievements-add-on-all-star-description', }); and then: AchievementsService.prototype.reward = function (_ref) { var nameL10n = _ref.nameL10n; var descriptionL10n = _ref.descriptionL10n; NotificationHelper.send(nameL10n, { bodyL10n: descriptionL10n, }); } Please, read https://developer.mozilla.org/en-US/Firefox_OS/Developing_Gaia/localization_code_best_practices and in particular: - https://developer.mozilla.org/en-US/Firefox_OS/Developing_Gaia/localization_code_best_practices#Writing_APIs_that_operate_on_L10nIDs - https://developer.mozilla.org/en-US/Firefox_OS/Developing_Gaia/localization_code_best_practices#Notification_API

Yura, how do you want to fix that?

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #76) > Yura, how do you want to fix that? I'm going to update the way l10n is done for notifications so reopening this bug.

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #76) > Yura, how do you want to fix that? Hi Zibi, another question. This component is also used outside of Gaia for some of the spark apps. Is that ok to implement what NotificationHelper.send does internally within the AchievementsService?

(In reply to Yura Zenevich [:yzen] from comment #78) > (In reply to Zibi Braniecki [:gandalf][:zibi] from comment #76) > > Yura, how do you want to fix that? > > Hi Zibi, another question. This component is also used outside of Gaia for > some of the spark apps. Is that ok to implement what NotificationHelper.send > does internally within the AchievementsService? Yeah! Are you using l10n.js/l20n.js for them? If so, this should work! Please, notice that we recently updated NotificationHelper to use async API (bug 1179683).

Adding Stas here to track the l20n dependency for this bug.

Hey Yura, you should now be able to install l20n.js with bower install l20n#v3.x v3.x is the same as shared/js/l20n.js. v2.x is the same as shared/js/l10n.js.

Firefox OS is not being worked on