[sugar-sur] Fwd: El envio a sugar-sur de yannick.warnier en beeznest.com precisa de aprobacion
Yannick Warnier
yannick.warnier en beeznest.com
Dom Nov 20 13:46:21 EST 2016
Hi Laura,
Well, designing the badge structure, you have to think about a few
things. I'm giving you a detailed list here because I think it will save
you time later on in the designing process (there is no official manual
on how to do this, but I find these are relevant items to consider early
on):
* Think about the official authority who will be confirming the
assignment of these badges. It could be decentralized (with IPv6 URLs
for example) but somehow a badge only has value if some kind of superior
"authority" (or group of people) confirms it. Otherwise anyone could
auto-assign him/herself as many badges as they want. Each OpenBadge
comes with a URI to confirm its authenticity. At the moment it's very
dependent on some kind of authority and a permanent URI (no blockchain
or other kind of decentralized recognition has crossed the OpenBadges
path yet, I think).
* OpenBadges currently do not offer a possibility for "hierarchical"
badges, so there's no use in thinking about several badges generating a
"super-badge" or something like that. If you want to represent
hierarchies, your OpenBadges-issuing application will have to deal with
that, as the OpenBadges standard itself won't.
* (linked to the previous one): Think about the structure you want to
use. Some badges will fall into an easy category (one specific
application, for example), but other badges might be about contributing
to a forum or helping others. In this case, you might want to also keep
a way to group together all badges about contributing on a forum for
different applications. Tags should help better than a strict tree
categorization, in this case.
* (again linked to the previous point): Before anything else, you should
think about what type of achievements you want to represent with badges.
Is it "learning this stuff" or is it "contributing to this thing", etc?
This will give you achievement "types" (like you described below about
Fedora) and help you avoid mixing everything. In particular when
designing the badges visually, you want to use the same color, for
example, for the same type of achievement
* Think whether you want badges to be eternal or have an expiry date.
For example, "Answering more than 100 posts" on a forum is permanent (in
most cases). However "Having the skills to administer a Linux server" is
a changing target. You can either decide that the badge is valid for
only 2 years since achieving it, or say that it works only for "Ubuntu
16.04", so that it automatically becomes worthless as time and versions
live and die.
* It's good to try and find a library of icons that you will use for all
the (visual) badges. It ensures a coherent collection of badges in the
end. The Mozilla OpenBadges-badgekit uses 2 different libraries (don't
remember which): https://github.com/mozilla/openbadges-badgekit. You can
also use https://www.openbadges.me, although I find the fact that it's
not Open Source (or not clearly so) a bit of an obstacle for me. A few
good free icons libraries are glyphicon and font-awesome.
* If an achievement will be part of a sub-collection (like, I don't
know, all the achievements linked to one sugar app), then you should
also think about a common design for that specific sub-collection. In
our case, we've modified a bit the badgekit to allow us to build badges
with a different "tab" attached to the border of the tag, representing
the logo of Chamilo. This is great because the badge's background
represents the app, while the badge's central icon represents the
achievement itself - in this case, however, the badgekit depended on an
SVG background which is a bit difficult to modify (in the end we edited
the badge background's SVG source manually because editing it through
Inkscape modified the ID of the element and the badgekit's JavaScript
code got lost).
* Mozilla provides an open source badges "backpack" repository, which I
believe is written in Python (good for you, I suppose). They also
provide a central repository which you can use freely. It uses Mozilla's
"Persona" for authentication, which is to be abandonned on the 30th of
November (in a few days), but I'm sure you'll be able to enter with
normal credentials after that. By "Central" repository I mean anyone can
store all the OpenBadges he gets from different sources there (SL,
Chamilo, etc) and maintain their personal badges repository there (and
then link them from LinkedIn, for example, although LinkedIn's support
for OpenBadges is inexistent).
* Finally, know that OpenBadges files (images) can also *store* metadata
in the PNG file. This is a property of PNG which comes in beautifully in
OpenBadges, because you can actually "save the image" of a PNG badge and
that image contains the verification URI, the issueing authority, etc.
So you can depend on that to ensure transportability of the badges in a
disconnected environment (these PNG can later be read by an OpenBadges
reader and show you the data). In this case, you design a "template" PNG
file which is later modified by your OpenBadges-compatible application
to add the "achiever's data". So a badge is just an image until it is
"issued" to someone. Then it becomes an image with metadata.
In general, Stack Overflow's strategy to reward contribution is a good
example of what you could do for a forum. At some point, Ubuntu had also
launched an achievements strategy in its forums and on launchpad, which
somehow died or stopped progressing. I think maybe Fedora's inspiration
came from there... not sure. In light of these projects, it really make
sense to not only think about a library of badges, but also of an open
standard to exchange them, so it can survive the test of time.
Regards and blessings from locked-down Lima (because of the APEC),
Yannick
Le 19/11/16 à 14:50, Laura Vargas a écrit :
> Thank you Yannick!
>
> I guess that us (SL) working on *designing the badges structure *will
> be the next step.
>
> Any specific instruction on this?
>
> Regards and blessings from the Amazon :D
>
> Laura V
>
>
> ---------- Mensaje reenviado ----------
> From: Yannick Warnier <yannick.warnier en beeznest.com
> <mailto:yannick.warnier en beeznest.com>>
> To: sugar-sur en lists.sugarlabs.org <mailto:sugar-sur en lists.sugarlabs.org>
> Cc:
> Date: Sat, 19 Nov 2016 10:03:55 -0500
> Subject: Re: [sugar-sur] [IAEP] Open Badges
> Hi folks,
>
> Just so you know (I'm not engaging my team in any way through this)
> Chamilo is an GPL (PHP/MySQL) e-learning platform that implements
> badges in a relatively easy way and allows you to design your badges
> (with an embedded widget developed by Mozilla) very easily.
>
> I am available to explain one (or several) of you guys and girls how
> to build courses or specific items that will let you earn badges. I'm
> just not sure Chamilo will be what you need (I haven't read the whole
> thread).
>
> In my experience, the most challenging part is designing the badges
> structure, but the tool is there to manage them afterwards, in the
> long run. Chamilo can serve as a central point where those badges are
> generated and can be verified (OpenBadges can use a unique URI to
> verify the origin of the badge issue).
>
> --
>
> Regards,
>
> Yannick Warnier
> Founder & Leader
> Chamilo
>
>
> Le 19/11/16 à 09:29, Laura Vargas a écrit :
>
> Hello and thanks to everyone interested on the subject,
>
> I wasn't aware of this efforts in progress of the Rochester
> Institute of
> Technology and the Teaching Open Source. I will read in detail.
>
> Still, with the Fedora example my idea was to submit to community
> consideration an strategic implementation of open badges for community
> building, like Fedora.
>
> For example, Fedora uses:
>
> - Content Badges: For contributions made in the form of documentation
>
> - Development Badges: For contributions made to the code(s)
>
> - Quality Badge: Equivalent could be a *Sugar Testing Badge*... (we
> could start with this one?)
>
>
> Of course this is a larger project and would require strong
> support from
> Sugar Labs.
>
>
> If the Fedora folks could do it, I feel almost ashamed we
> haven't... :D
>
> Regards
>
> 2016-11-19 7:54 GMT-05:00 Stephen Jacobs <sj en magic.rit.edu
> <mailto:sj en magic.rit.edu>
> <mailto:sj en magic.rit.edu <mailto:sj en magic.rit.edu>>>:
>
> We've got a small group in the class this coming semester. If the
> skill set isn't in the class we can look at other avenues as well.
>
> Class, etc won't start til end of January. SL community should
> certainly dive in to the previous work to figure out what's
> needed.
> Might be enough has been done in the past it can be moved forward
> before classes start. If not, they should at least generate a
> wish
> list for what needs to be done
>
> Sent from my iPhone
>
> On Nov 19, 2016, at 2:26 AM, Remy DeCausemaker
> <decause en gmail.com <mailto:decause en gmail.com>
> <mailto:decause en gmail.com <mailto:decause en gmail.com>>> wrote:
>
> /me emerges from a long lurking state
>
> Once upon a time, the folks in the RIT HFOSS program built an
> activity for viewing open badges locally on the XO called
> Sash:
>
> GitHub.com/fossrit/sash <http://GitHub.com/fossrit/sash
> <http://GitHub.com/fossrit/sash>>
>
> They also built open badges into 2 games, lemonade stand
> and skytime:
>
> GitHub.com/fossrit/lemonade-stand
> <http://GitHub.com/fossrit/lemonade-stand
> <http://GitHub.com/fossrit/lemonade-stand>>
> https://github.com/FOSSRIT/SkyTime
> <https://github.com/FOSSRIT/SkyTime>
> <https://github.com/FOSSRIT/SkyTime
> <https://github.com/FOSSRIT/SkyTime>>
>
> dzho is the current professor, but it's been a few years since
> those code paths were run.
>
> The Fedora badges dashboard is called tahrir, and source
> can be
> found here:
>
> GitHub.com/Fedora-infra/tahrir
> <http://GitHub.com/Fedora-infra/tahrir
> <http://GitHub.com/Fedora-infra/tahrir>>
>
> Hope this helps,
> --RemyD.
>
> On Nov 19, 2016 02:06, "Samson Goddy"
> <samsongoddy en sugarlabs.org <mailto:samsongoddy en sugarlabs.org>
> <mailto:samsongoddy en sugarlabs.org
> <mailto:samsongoddy en sugarlabs.org>>> wrote:
>
> sounds like a good idea!
>
>
> Samson Goddy
>
> On Sat, Nov 19, 2016 at 4:23 AM, Laura Vargas
> <laura en somosazucar.org <mailto:laura en somosazucar.org>
> <mailto:laura en somosazucar.org <mailto:laura en somosazucar.org>>>
> wrote:
>
>
> Here is a link to Fedora's Open Badge dashboard:
>
> https://badges.fedoraproject.org/
> <https://badges.fedoraproject.org/>
> <https://badges.fedoraproject.org/
> <https://badges.fedoraproject.org/>>
>
> Should SL consider to adopt a similar strategy?
>
>
> --
> Laura V.
> I&D SomosAZUCAR.Org <http://SomosAZUCAR.Org>
>
> Happy Learning!
>
>
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop
> project!)
> IAEP en lists.sugarlabs.org <mailto:IAEP en lists.sugarlabs.org>
> <mailto:IAEP en lists.sugarlabs.org
> <mailto:IAEP en lists.sugarlabs.org>>
> http://lists.sugarlabs.org/listinfo/iaep
> <http://lists.sugarlabs.org/listinfo/iaep>
> <http://lists.sugarlabs.org/listinfo/iaep
> <http://lists.sugarlabs.org/listinfo/iaep>>
>
>
>
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP en lists.sugarlabs.org <mailto:IAEP en lists.sugarlabs.org>
> <mailto:IAEP en lists.sugarlabs.org
> <mailto:IAEP en lists.sugarlabs.org>>
> http://lists.sugarlabs.org/listinfo/iaep
> <http://lists.sugarlabs.org/listinfo/iaep>
> <http://lists.sugarlabs.org/listinfo/iaep
> <http://lists.sugarlabs.org/listinfo/iaep>>
>
>
>
>
> --
> Laura V.
> I&D SomosAZUCAR.Org
>
> Identi.ca/Skype acaire
> IRC kaametza
>
> Happy Learning!
>
>
>
> _______________________________________________
> sugar-sur mailing list
> sugar-sur en lists.sugarlabs.org <mailto:sugar-sur en lists.sugarlabs.org>
> http://lists.sugarlabs.org/listinfo/sugar-sur
> <http://lists.sugarlabs.org/listinfo/sugar-sur>
>
>
>
> ---------- Mensaje reenviado ----------
> From: sugar-sur-request en lists.sugarlabs.org
> <mailto:sugar-sur-request en lists.sugarlabs.org>
> To:
> Cc:
> Date: Sat, 19 Nov 2016 10:05:28 -0500
> Subject: confirm 9399489e2999893ef531a7b249a3d37c7c8895a6
> Si responde a este mensaje manteniendo la cabecera Subject: (Asunto)
> intacta, Mailman descartará el mensaje retenido. Haga esto si el
> mensaje es spam. Si responde a este mensaje incluyendo una cabecera
> Approved: con la contraseña de la lista en ella, se aprobará el
> mensaje para que se entregue a la lista. La cabecera Approved: puede
> aparecer también en la primera línea del cuerpo de la respuesta.
>
>
>
> --
> Laura V.
> I&D SomosAZUCAR.Org
>
> Identi.ca/Skype acaire
> IRC kaametza
>
> Happy Learning!
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://lists.sugarlabs.org/archive/sugar-sur/attachments/20161120/2ff406a0/attachment-0001.html>
Más información sobre la lista de distribución sugar-sur