search

mozilla / openbadges-backpack

Mozilla Open Badges Backpack
https://backpack.openbadges.org/
Other
862 stars 263 forks source link

The need for formatting in the description text #1030

Open dbhouston opened 10 years ago

dbhouston commented 10 years ago

Now that I'm awarding badges, I can see an irritating shortcoming in the description field. I don't know of any way of formatting it, which makes is unreadable. I hope I'm wrong.

Here is what some badges look like:

https://backpack.openbadges.org/share/e99ac2a5e63a38603227af7c486a6a7f/

The description is "word salad" and very hard to read.

I needed to add in data required by the Texas State Board of Professional Engineers and it is almost unreadable.. Even a few things. like a
tag or a few other html tags would make this a lot more readable. Or just retain a return to mark a line in text would help.

Bill

andreasauwaerter commented 10 years ago

Hi Bill, We here at RadioActive101 Europe feel the same pain. We also hoped we were wrong but in our case the Moodle-Responsibles decided to change the Manual instead of finding a solution for the prroblem, which i am summarising: If we would like to have meaningful badge descriptions, there's a need to offer structural elements like ordered or unordered lists and paragraphs.

Unfortunately the discussion ended quickly in the restriction to prohibit html-tags completely.

I can share security doupts in this discussion. But i cannot share the meaning, well as cited: Mozilla doesn't explicitly allow it, so we should stop to support it. In fact - this is in my point of view completly away from the needs of practice.

Regards Andreas.
Am 31.07.2014 um 02:11 schrieb dbhouston notifications@github.com:

Now that I'm awarding badges, I can see an irritating shortcoming in the description field. I don't know of any way of formatting it, which makes is unreadable. I hope I'm wrong.

Here is what some badges look like:

https://backpack.openbadges.org/share/e99ac2a5e63a38603227af7c486a6a7f/

The description is "word salad" and very hard to read.

I needed to add in data required by the Texas State Board of Professional Engineers and it is almost unreadable.. Even a few things. like a tag or a few other html tags would make this a lot more readable. Or just retain a return to mark a line in text would help.

Bill

— Reply to this email directly or view it on GitHub.

erkorb commented 10 years ago

@Bill @andrea I believe what you trying to do is not working because the backpack is simply a quick view of the underlying data. I would suggest that the criteria page, which is likely produced with HTML would suit you better for formatting a long-description. Think of the description field in a badge more as a short-description. Also, could add your own custom nodes for a long-description, the consumer system (displayer) would have to look for it.

Eric @accreditrust On Jul 31, 2014 5:26 AM, "andreasauwaerter" notifications@github.com wrote:

Hi Bill, We here at RadioActive101 Europe feel the same pain. We also hoped we were wrong but in our case the Moodle-Responsibles decided to change the Manual instead of finding a solution for the prroblem, which i am summarising: If we would like to have meaningful badge descriptions, there's a need to offer structural elements like ordered or unordered lists and paragraphs.

Unfortunately the discussion ended quickly in the restriction to prohibit html-tags completely.

I can share security doupts in this discussion. But i cannot share the meaning, well as cited: Mozilla doesn't explicitly allow it, so we should stop to support it. In fact - this is in my point of view completly away from the needs of practice.

Regards Andreas. Am 31.07.2014 um 02:11 schrieb dbhouston notifications@github.com:

Now that I'm awarding badges, I can see an irritating shortcoming in the description field. I don't know of any way of formatting it, which makes is unreadable. I hope I'm wrong.

Here is what some badges look like:

https://backpack.openbadges.org/share/e99ac2a5e63a38603227af7c486a6a7f/

The description is "word salad" and very hard to read.

I needed to add in data required by the Texas State Board of Professional Engineers and it is almost unreadable.. Even a few things. like a tag or a few other html tags would make this a lot more readable. Or just retain a return to mark a line in text would help.

Bill

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/mozilla/openbadges/issues/1030#issuecomment-50736907.

dbhouston commented 10 years ago

Well, its just not necessary and its going to hold things up. Why not make this more readable? It would make the badge more self contained and would not compromise security.

The great unwashed masses out there, me included, are not going to understand why the text doesn't look good. They are going to conclude that badges are broken or too "geeky" for prime time.

Where are the "look and feel" people when we need them?

This is not too hard to fix.

Bill

ottonomy commented 10 years ago

I think I agree with @dbhouston on one point: the backpack should respect \n (or in his case the windows style "\r\n" newline information included in the badge JSON) instead of ignoring it. In most cases, badge descriptions should probably be short enough that there is no need for newlines.

On the other hand, as someone who wants to write software on the side of machine-processing badges, I agree with @erkorb that I don't think the description field is one that should be richly formatted. As it is text that will appear in many applications designed to read badges, control over the appearance of the text most cleanly lies within the environment that is interpreting it. I would find it much more challenging to write this kind of application if I had to handle even a limited set of HTML tags in the description field.

The criteria page is a perfect place, on the other hand, to show off the richest possible description of what the badge means and what it takes to earn it.

@andreasauwaerter, You could consider writing lists roughly in something like Markdown, where a set of *'s at the beginning of new lines translates into an unordered list. (But if the Backpack ignores newline characters, this won't help at all at present for badges that are displayed in this venue. In general, you should keep in mind when writing badge descriptions, that you won't have control over how those descriptions are displayed.).

dbhouston commented 10 years ago

Ottonomy,

I only focus on the description because, at least in Moodle, it is the only portion of the badge human readable content CARRIED WITH THE BADGE. That means every displayer will show it without jumping to another webpage. Like it or not, the Mozilla Backpack is the default displayer for most applications and they need to do a halfway decent job of showing immediate content.

Hey, Mozilla, I think you are really on to something. So, why not do this right? Or, at least, better than this?

Bill

ingodahn commented 10 years ago

In our application context (RadioActive Europe project) badge usage is confined by the following boundary conditions:

  1. A large curriculum with many potential achievements that are to be confirmed by badges. Consequence: In order to keep the number of badges manageable, achievements are grouped and badges are issued for groups of achievements. This leads to badge descriptions which consist of a list af confirmed achievements.
  2. Moodle as a badge issueing tool: Consequences: As mentioned by dbhouston, only one description which is displayed inside Moodle as HTML (ignoring line breaks) and on the backpack server as plain text.
  3. Learners use badges for demonstrating their achievements to potential employers. Consequence: Badge holders have a high interest in professionally looking badge descriptions. But this is impossible to achieve with a single line of text.

As the Moodle folks agreed to abandon html in badge descriptions (regrettably), they will hopefully at least respect newlines and a working, though less than perfect, solution could be as proposed by ottonomy (plain text with line breaks). Ingo

dbhouston commented 10 years ago

I think the Moodle people followed the lead of Mozilla in their implementation. Are they not in the lead? I'm told that the description was spec'd out as text only.

This is an easy fix of just respecting a few optional tags for better formatting.. It's a few lines of code at their next "Summer of Fun" codefest.

Bill

On Mon, Aug 4, 2014 at 2:05 AM, ingodahn notifications@github.com wrote:

In our application context (RadioActive Europe project) badge usage is confined by the following boundary conditions:

  1. A large curriculum with many potential achievements that are to be confirmed by badges. Consequence: In order to keep the number of badges manageable, achievements are grouped and badges are issued for groups of achievements. This leads to badge descriptions which consist of a list af confirmed achievements.
  2. Moodle as a badge issueing tool: Consequences: As mentioned by dbhouston, only one description which is displayed inside Moodle as HTML (ignoring line breaks) and on the backpack server as plain text.
  3. Learners use badges for demonstrating their achievements to potential employers. Consequence: Badge holders have a high interest in professionally looking badge descriptions. But this is impossible to achieve with a single line of text.

As the Moodle folks agreed to abandon html in badge descriptions (regrettably), they will hopefully at least respect newlines and a working, though less than perfect, solution could be as proposed by ottonomy (plain text with line breaks). Ingo

— Reply to this email directly or view it on GitHub https://github.com/mozilla/openbadges/issues/1030#issuecomment-51024277.

ottonomy commented 10 years ago

Bill,

You're right that this field is "spec'd" as plain text. What that means is that the OBI standard, as stewarded by the Badge Alliance, instructs all implementations that any HTML tags issuers put into that field should not be respected.

Displaying applications have purview over how this line of text appears, not issuers, because the OBI standard is designed for portability of data, separated from concerns of presentation. Even line breaks are stretching this portability.

Changing this is not simply a matter of writing a little code in one application. There are a lot of portability advantages gained by displayers being able to treat that field as plain text. If it were allowed to contain HTML tags, every application that displays this field would need to build hundreds of tests to ensure that the formatting input by the issuer doesn't break the layout of the display application, and hundreds of stopgaps to fix the possible display bugs you might encounter. This is difficult and expensive code to write, requiring front end and back end engineering expertise.

If you took this proposal to the Standard WG, you likely would make no headway there either, but since this is on the backpack repo, the only think that might get through would be a newline filter on this field. But you must then understand, you wouldn't be able to depend on those being respected in other applications. The criteria page is well under your control display-wise, and it is by far a more appropriate place for detailed information about the badge description.

Ingo, sounds like Moodle would be where to pursue code changes. How does it handle criteria pages? Abstractly, within an issuer's context, you can show how your badges work together in a much richer way than the backpack allows. On Aug 4, 2014 7:52 AM, "William G Beazley" notifications@github.com wrote:

I think the Moodle people followed the lead of Mozilla in their implementation. Are they not in the lead? I'm told that the description was spec'd out as text only.

This is an easy fix of just respecting a few optional tags for better formatting.. It's a few lines of code at their next "Summer of Fun" codefest.

Bill

On Mon, Aug 4, 2014 at 2:05 AM, ingodahn notifications@github.com wrote:

In our application context (RadioActive Europe project) badge usage is confined by the following boundary conditions:

  1. A large curriculum with many potential achievements that are to be confirmed by badges. Consequence: In order to keep the number of badges manageable, achievements are grouped and badges are issued for groups of achievements. This leads to badge descriptions which consist of a list af confirmed achievements.
  2. Moodle as a badge issueing tool: Consequences: As mentioned by dbhouston, only one description which is displayed inside Moodle as HTML (ignoring line breaks) and on the backpack server as plain text.
  3. Learners use badges for demonstrating their achievements to potential employers. Consequence: Badge holders have a high interest in professionally looking badge descriptions. But this is impossible to achieve with a single line of text.

As the Moodle folks agreed to abandon html in badge descriptions (regrettably), they will hopefully at least respect newlines and a working, though less than perfect, solution could be as proposed by ottonomy (plain text with line breaks). Ingo

— Reply to this email directly or view it on GitHub https://github.com/mozilla/openbadges/issues/1030#issuecomment-51024277.

— Reply to this email directly or view it on GitHub https://github.com/mozilla/openbadges/issues/1030#issuecomment-51070321.

dbhouston commented 10 years ago

Otto,

I think badges are far advanced from what is convenient to the implementations. I get the part about lines of code but a formatted text box is part of every programming GUI kit. There has to be a subset that is doable. Even this email app I am writing to you with understands newlines.

This is what success looks like: People want the badge to be readable and don't and won't understand why it can't be. I'm afraid that badges must turn into an appliance technology, whether it wants to or not.

I don't know how my cell phone works but I know it need to be usable when I'm in a hurry.

I am not one to parse wording but I don't think you are saying that newline tags are DIS-allowed. Implementors are just not REQUIRED to support them to get blessed by the alliance. If they were included in the word salad and a displayer CHOSE to make use of them, they wouldn't be kicked off the island.

Am I hearing this correctly?

Bill

On Mon, Aug 4, 2014 at 10:20 AM, Nate Otto notifications@github.com wrote:

Bill,

You're right that this field is "spec'd" as plain text. What that means is that the OBI standard, as stewarded by the Badge Alliance, instructs all implementations that any HTML tags issuers put into that field should not be respected.

Displaying applications have purview over how this line of text appears, not issuers, because the OBI standard is designed for portability of data, separated from concerns of presentation. Even line breaks are stretching this portability.

Changing this is not simply a matter of writing a little code in one application. There are a lot of portability advantages gained by displayers being able to treat that field as plain text. If it were allowed to contain HTML tags, every application that displays this field would need to build hundreds of tests to ensure that the formatting input by the issuer doesn't break the layout of the display application, and hundreds of stopgaps to fix the possible display bugs you might encounter. This is difficult and expensive code to write, requiring front end and back end engineering expertise.

If you took this proposal to the Standard WG, you likely would make no headway there either, but since this is on the backpack repo, the only think that might get through would be a newline filter on this field. But you must then understand, you wouldn't be able to depend on those being respected in other applications. The criteria page is well under your control display-wise, and it is by far a more appropriate place for detailed information about the badge description.

Ingo, sounds like Moodle would be where to pursue code changes. How does it handle criteria pages? Abstractly, within an issuer's context, you can show how your badges work together in a much richer way than the backpack allows. On Aug 4, 2014 7:52 AM, "William G Beazley" notifications@github.com wrote:

I think the Moodle people followed the lead of Mozilla in their implementation. Are they not in the lead? I'm told that the description was spec'd out as text only.

This is an easy fix of just respecting a few optional tags for better formatting.. It's a few lines of code at their next "Summer of Fun" codefest.

Bill

On Mon, Aug 4, 2014 at 2:05 AM, ingodahn notifications@github.com wrote:

In our application context (RadioActive Europe project) badge usage is confined by the following boundary conditions:

  1. A large curriculum with many potential achievements that are to be confirmed by badges. Consequence: In order to keep the number of badges manageable, achievements are grouped and badges are issued for groups of achievements. This leads to badge descriptions which consist of a list af confirmed achievements.
  2. Moodle as a badge issueing tool: Consequences: As mentioned by dbhouston, only one description which is displayed inside Moodle as HTML (ignoring line breaks) and on the backpack server as plain text.
  3. Learners use badges for demonstrating their achievements to potential employers. Consequence: Badge holders have a high interest in professionally looking badge descriptions. But this is impossible to achieve with a single line of text.

As the Moodle folks agreed to abandon html in badge descriptions (regrettably), they will hopefully at least respect newlines and a working, though less than perfect, solution could be as proposed by ottonomy (plain text with line breaks). Ingo

— Reply to this email directly or view it on GitHub < https://github.com/mozilla/openbadges/issues/1030#issuecomment-51024277>.

— Reply to this email directly or view it on GitHub https://github.com/mozilla/openbadges/issues/1030#issuecomment-51070321.

— Reply to this email directly or view it on GitHub https://github.com/mozilla/openbadges/issues/1030#issuecomment-51074325.

ottonomy commented 10 years ago

Bill,

Thanks for working to move badges toward that "appliance" level. I'd love to see them get there too!

By default, HTML treats newlines in source as any other whitespace (turns it into a single space whitespace character). If displayer implementations chose to do something else with the newline character(s), they could, and this would not be disallowed by the standard. Changing one of the core OBI fields to force implementations to understand embedded HTML tags is a difference of kind above that, I think, and breaks backwards compatibility. Embedding HTML tags in JSON (which is more intended to have raw data) isn't pretty for a couple other reasons, so there are challenges.

That said, we are close to approving an extensions syntax, where you and other interested parties could try out offering an alternate rich_description property that interested displayers could individually build support for.

Nate

On Mon, Aug 4, 2014 at 11:40 AM, William G Beazley <notifications@github.com

wrote:

Otto,

I think badges are far advanced from what is convenient to the implementations. I get the part about lines of code but a formatted text box is part of every programming GUI kit. There has to be a subset that is doable. Even this email app I am writing to you with understands newlines.

This is what success looks like: People want the badge to be readable and don't and won't understand why it can't be. I'm afraid that badges must turn into an appliance technology, whether it wants to or not.

I don't know how my cell phone works but I know it need to be usable when I'm in a hurry.

I am not one to parse wording but I don't think you are saying that newline tags are DIS-allowed. Implementors are just not REQUIRED to support them to get blessed by the alliance. If they were included in the word salad and a displayer CHOSE to make use of them, they wouldn't be kicked off the island.

Am I hearing this correctly?

Bill

On Mon, Aug 4, 2014 at 10:20 AM, Nate Otto notifications@github.com wrote:

Bill,

You're right that this field is "spec'd" as plain text. What that means is that the OBI standard, as stewarded by the Badge Alliance, instructs all implementations that any HTML tags issuers put into that field should not be respected.

Displaying applications have purview over how this line of text appears, not issuers, because the OBI standard is designed for portability of data, separated from concerns of presentation. Even line breaks are stretching this portability.

Changing this is not simply a matter of writing a little code in one application. There are a lot of portability advantages gained by displayers being able to treat that field as plain text. If it were allowed to contain HTML tags, every application that displays this field would need to build hundreds of tests to ensure that the formatting input by the issuer doesn't break the layout of the display application, and hundreds of stopgaps to fix the possible display bugs you might encounter. This is difficult and expensive code to write, requiring front end and back end engineering expertise.

If you took this proposal to the Standard WG, you likely would make no headway there either, but since this is on the backpack repo, the only think that might get through would be a newline filter on this field. But you must then understand, you wouldn't be able to depend on those being respected in other applications. The criteria page is well under your control display-wise, and it is by far a more appropriate place for detailed information about the badge description.

Ingo, sounds like Moodle would be where to pursue code changes. How does it handle criteria pages? Abstractly, within an issuer's context, you can show how your badges work together in a much richer way than the backpack allows. On Aug 4, 2014 7:52 AM, "William G Beazley" notifications@github.com wrote:

I think the Moodle people followed the lead of Mozilla in their implementation. Are they not in the lead? I'm told that the description was spec'd out as text only.

This is an easy fix of just respecting a few optional tags for better formatting.. It's a few lines of code at their next "Summer of Fun" codefest.

Bill

On Mon, Aug 4, 2014 at 2:05 AM, ingodahn notifications@github.com wrote:

In our application context (RadioActive Europe project) badge usage is confined by the following boundary conditions:

  1. A large curriculum with many potential achievements that are to be confirmed by badges. Consequence: In order to keep the number of badges manageable, achievements are grouped and badges are issued for groups of achievements. This leads to badge descriptions which consist of a list af confirmed achievements.
  2. Moodle as a badge issueing tool: Consequences: As mentioned by dbhouston, only one description which is displayed inside Moodle as HTML (ignoring line breaks) and on the backpack server as plain text.
  3. Learners use badges for demonstrating their achievements to potential employers. Consequence: Badge holders have a high interest in professionally looking badge descriptions. But this is impossible to achieve with a single line of text.

As the Moodle folks agreed to abandon html in badge descriptions (regrettably), they will hopefully at least respect newlines and a working, though less than perfect, solution could be as proposed by ottonomy (plain text with line breaks). Ingo

— Reply to this email directly or view it on GitHub < https://github.com/mozilla/openbadges/issues/1030#issuecomment-51024277>.

— Reply to this email directly or view it on GitHub < https://github.com/mozilla/openbadges/issues/1030#issuecomment-51070321>.

— Reply to this email directly or view it on GitHub https://github.com/mozilla/openbadges/issues/1030#issuecomment-51074325.

— Reply to this email directly or view it on GitHub https://github.com/mozilla/openbadges/issues/1030#issuecomment-51099730.

andreasauwaerter commented 10 years ago

Hi ottoman and all. This sounds better than your mail/post before. Yes there's a need to create shiny badges for people who deserve it and this includes also the appearance of the description. Ppl deserve this equal if they are young or adults.

I feel also the pain with HTML markup in general as this only one possible solution. It also includes risk potentials. Nobody here would like to issue badges including big data collectors etched. Maybe some standardised language like wiki or general markup would be enough. But -and that's the core: it should help issuing people to express more than letters chained.

So far the challenge is to empower beyond potential meaningless short description restrictions.

My2cents Andreas Von meinem iPhone gesendet

Am 04.08.2014 um 20:49 schrieb Nate Otto notifications@github.com:

Bill,

Thanks for working to move badges toward that "appliance" level. I'd love to see them get there too!

By default, HTML treats newlines in source as any other whitespace (turns it into a single space whitespace character). If displayer implementations chose to do something else with the newline character(s), they could, and this would not be disallowed by the standard. Changing one of the core OBI fields to force implementations to understand embedded HTML tags is a difference of kind above that, I think, and breaks backwards compatibility. Embedding HTML tags in JSON (which is more intended to have raw data) isn't pretty for a couple other reasons, so there are challenges.

That said, we are close to approving an extensions syntax, where you and other interested parties could try out offering an alternate rich_description property that interested displayers could individually build support for.

Nate

On Mon, Aug 4, 2014 at 11:40 AM, William G Beazley <notifications@github.com

wrote:

Otto,

I think badges are far advanced from what is convenient to the implementations. I get the part about lines of code but a formatted text box is part of every programming GUI kit. There has to be a subset that is doable. Even this email app I am writing to you with understands newlines.

This is what success looks like: People want the badge to be readable and don't and won't understand why it can't be. I'm afraid that badges must turn into an appliance technology, whether it wants to or not.

I don't know how my cell phone works but I know it need to be usable when I'm in a hurry.

I am not one to parse wording but I don't think you are saying that newline tags are DIS-allowed. Implementors are just not REQUIRED to support them to get blessed by the alliance. If they were included in the word salad and a displayer CHOSE to make use of them, they wouldn't be kicked off the island.

Am I hearing this correctly?

Bill

On Mon, Aug 4, 2014 at 10:20 AM, Nate Otto notifications@github.com wrote:

Bill,

You're right that this field is "spec'd" as plain text. What that means is that the OBI standard, as stewarded by the Badge Alliance, instructs all implementations that any HTML tags issuers put into that field should not be respected.

Displaying applications have purview over how this line of text appears, not issuers, because the OBI standard is designed for portability of data, separated from concerns of presentation. Even line breaks are stretching this portability.

Changing this is not simply a matter of writing a little code in one application. There are a lot of portability advantages gained by displayers being able to treat that field as plain text. If it were allowed to contain HTML tags, every application that displays this field would need to build hundreds of tests to ensure that the formatting input by the issuer doesn't break the layout of the display application, and hundreds of stopgaps to fix the possible display bugs you might encounter. This is difficult and expensive code to write, requiring front end and back end engineering expertise.

If you took this proposal to the Standard WG, you likely would make no headway there either, but since this is on the backpack repo, the only think that might get through would be a newline filter on this field. But you must then understand, you wouldn't be able to depend on those being respected in other applications. The criteria page is well under your control display-wise, and it is by far a more appropriate place for detailed information about the badge description.

Ingo, sounds like Moodle would be where to pursue code changes. How does it handle criteria pages? Abstractly, within an issuer's context, you can show how your badges work together in a much richer way than the backpack allows. On Aug 4, 2014 7:52 AM, "William G Beazley" notifications@github.com wrote:

I think the Moodle people followed the lead of Mozilla in their implementation. Are they not in the lead? I'm told that the description was spec'd out as text only.

This is an easy fix of just respecting a few optional tags for better formatting.. It's a few lines of code at their next "Summer of Fun" codefest.

Bill

On Mon, Aug 4, 2014 at 2:05 AM, ingodahn notifications@github.com wrote:

In our application context (RadioActive Europe project) badge usage is confined by the following boundary conditions:

  1. A large curriculum with many potential achievements that are to be confirmed by badges. Consequence: In order to keep the number of badges manageable, achievements are grouped and badges are issued for groups of achievements. This leads to badge descriptions which consist of a list af confirmed achievements.
  2. Moodle as a badge issueing tool: Consequences: As mentioned by dbhouston, only one description which is displayed inside Moodle as HTML (ignoring line breaks) and on the backpack server as plain text.
  3. Learners use badges for demonstrating their achievements to potential employers. Consequence: Badge holders have a high interest in professionally looking badge descriptions. But this is impossible to achieve with a single line of text.

As the Moodle folks agreed to abandon html in badge descriptions (regrettably), they will hopefully at least respect newlines and a working, though less than perfect, solution could be as proposed by ottonomy (plain text with line breaks). Ingo

— Reply to this email directly or view it on GitHub < https://github.com/mozilla/openbadges/issues/1030#issuecomment-51024277>.

— Reply to this email directly or view it on GitHub < https://github.com/mozilla/openbadges/issues/1030#issuecomment-51070321>.

— Reply to this email directly or view it on GitHub https://github.com/mozilla/openbadges/issues/1030#issuecomment-51074325.

— Reply to this email directly or view it on GitHub https://github.com/mozilla/openbadges/issues/1030#issuecomment-51099730.

— Reply to this email directly or view it on GitHub.

dbhouston commented 10 years ago

I will do everything in my power to try out an improved syntax, including including newline characters. I'll have to enlist the cooperation of the Moodle developers but I think I can get it. I'm not hung up on HTML: I just know about it. ASCII already includes a LF, CR and TAB. This is not rocket science.

Implementors can write pre-processors to make conversions before baking. There is always an answer.

Bill

On Mon, Aug 4, 2014 at 2:02 PM, andreasauwaerter notifications@github.com wrote:

Hi ottoman and all. This sounds better than your mail/post before. Yes there's a need to create shiny badges for people who deserve it and this includes also the appearance of the description. Ppl deserve this equal if they are young or adults.

I feel also the pain with HTML markup in general as this only one possible solution. It also includes risk potentials. Nobody here would like to issue badges including big data collectors etched. Maybe some standardised language like wiki or general markup would be enough. But -and that's the core: it should help issuing people to express more than letters chained.

So far the challenge is to empower beyond potential meaningless short description restrictions.

My2cents Andreas Von meinem iPhone gesendet

Am 04.08.2014 um 20:49 schrieb Nate Otto notifications@github.com:

Bill,

Thanks for working to move badges toward that "appliance" level. I'd love to see them get there too!

By default, HTML treats newlines in source as any other whitespace (turns it into a single space whitespace character). If displayer implementations chose to do something else with the newline character(s), they could, and this would not be disallowed by the standard. Changing one of the core OBI fields to force implementations to understand embedded HTML tags is a difference of kind above that, I think, and breaks backwards compatibility. Embedding HTML tags in JSON (which is more intended to have raw data) isn't pretty for a couple other reasons, so there are challenges.

That said, we are close to approving an extensions syntax, where you and other interested parties could try out offering an alternate rich_description property that interested displayers could individually build support for.

Nate

On Mon, Aug 4, 2014 at 11:40 AM, William G Beazley < notifications@github.com

wrote:

Otto,

I think badges are far advanced from what is convenient to the implementations. I get the part about lines of code but a formatted text box is part of every programming GUI kit. There has to be a subset that is doable. Even this email app I am writing to you with understands newlines.

This is what success looks like: People want the badge to be readable and don't and won't understand why it can't be. I'm afraid that badges must turn into an appliance technology, whether it wants to or not.

I don't know how my cell phone works but I know it need to be usable when I'm in a hurry.

I am not one to parse wording but I don't think you are saying that newline tags are DIS-allowed. Implementors are just not REQUIRED to support them to get blessed by the alliance. If they were included in the word salad and a displayer CHOSE to make use of them, they wouldn't be kicked off the island.

Am I hearing this correctly?

Bill

On Mon, Aug 4, 2014 at 10:20 AM, Nate Otto notifications@github.com wrote:

Bill,

You're right that this field is "spec'd" as plain text. What that means is that the OBI standard, as stewarded by the Badge Alliance, instructs all implementations that any HTML tags issuers put into that field should not be respected.

Displaying applications have purview over how this line of text appears, not issuers, because the OBI standard is designed for portability of data, separated from concerns of presentation. Even line breaks are stretching this portability.

Changing this is not simply a matter of writing a little code in one application. There are a lot of portability advantages gained by displayers being able to treat that field as plain text. If it were allowed to contain HTML tags, every application that displays this field would need to build hundreds of tests to ensure that the formatting input by the issuer doesn't break the layout of the display application, and hundreds of stopgaps to fix the possible display bugs you might encounter. This is difficult and expensive code to write, requiring front end and back end engineering expertise.

If you took this proposal to the Standard WG, you likely would make no headway there either, but since this is on the backpack repo, the only think that might get through would be a newline filter on this field. But you must then understand, you wouldn't be able to depend on those being respected in other applications. The criteria page is well under your control display-wise, and it is by far a more appropriate place for detailed information about the badge description.

Ingo, sounds like Moodle would be where to pursue code changes. How does it handle criteria pages? Abstractly, within an issuer's context, you can show how your badges work together in a much richer way than the backpack allows. On Aug 4, 2014 7:52 AM, "William G Beazley" < notifications@github.com> wrote:

I think the Moodle people followed the lead of Mozilla in their implementation. Are they not in the lead? I'm told that the description was spec'd out as text only.

This is an easy fix of just respecting a few optional tags for better formatting.. It's a few lines of code at their next "Summer of Fun" codefest.

Bill

On Mon, Aug 4, 2014 at 2:05 AM, ingodahn notifications@github.com

wrote:

In our application context (RadioActive Europe project) badge usage is confined by the following boundary conditions:

  1. A large curriculum with many potential achievements that are to be confirmed by badges. Consequence: In order to keep the number of badges manageable, achievements are grouped and badges are issued for groups of achievements. This leads to badge descriptions which consist of a list af confirmed achievements.
  2. Moodle as a badge issueing tool: Consequences: As mentioned by dbhouston, only one description which is displayed inside Moodle as HTML (ignoring line breaks) and on the backpack server as plain text.
  3. Learners use badges for demonstrating their achievements to potential employers. Consequence: Badge holders have a high interest in professionally looking badge descriptions. But this is impossible to achieve with a single line of text.

As the Moodle folks agreed to abandon html in badge descriptions (regrettably), they will hopefully at least respect newlines and a working, though less than perfect, solution could be as proposed by ottonomy (plain text with line breaks). Ingo

— Reply to this email directly or view it on GitHub <

https://github.com/mozilla/openbadges/issues/1030#issuecomment-51024277>.

— Reply to this email directly or view it on GitHub <

https://github.com/mozilla/openbadges/issues/1030#issuecomment-51070321>.

— Reply to this email directly or view it on GitHub < https://github.com/mozilla/openbadges/issues/1030#issuecomment-51074325>.

— Reply to this email directly or view it on GitHub < https://github.com/mozilla/openbadges/issues/1030#issuecomment-51099730>.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/mozilla/openbadges/issues/1030#issuecomment-51102586.

ingodahn commented 10 years ago

Though I can live with newlines, I'd prefer some simple HTML, as it is most easy to embed into web pages. It would be a nice feature if the backpack server could provide an embed code for embedding badges into arbitrary web pages. Ingo

2014-08-04 22:38 GMT+02:00 William G Beazley notifications@github.com:

I will do everything in my power to try out an improved syntax, including including newline characters. I'll have to enlist the cooperation of the Moodle developers but I think I can get it. I'm not hung up on HTML: I just know about it. ASCII already includes a LF, CR and TAB. This is not rocket science.

Implementors can write pre-processors to make conversions before baking. There is always an answer.

Bill

On Mon, Aug 4, 2014 at 2:02 PM, andreasauwaerter notifications@github.com

wrote:

Hi ottoman and all. This sounds better than your mail/post before. Yes there's a need to create shiny badges for people who deserve it and this includes also the appearance of the description. Ppl deserve this equal if they are young or adults.

I feel also the pain with HTML markup in general as this only one possible solution. It also includes risk potentials. Nobody here would like to issue badges including big data collectors etched. Maybe some standardised language like wiki or general markup would be enough. But -and that's the core: it should help issuing people to express more than letters chained.

So far the challenge is to empower beyond potential meaningless short description restrictions.

My2cents Andreas Von meinem iPhone gesendet

Am 04.08.2014 um 20:49 schrieb Nate Otto notifications@github.com:

Bill,

Thanks for working to move badges toward that "appliance" level. I'd love to see them get there too!

By default, HTML treats newlines in source as any other whitespace (turns it into a single space whitespace character). If displayer implementations chose to do something else with the newline character(s), they could, and this would not be disallowed by the standard. Changing one of the core OBI fields to force implementations to understand embedded HTML tags is a difference of kind above that, I think, and breaks backwards compatibility. Embedding HTML tags in JSON (which is more intended to have raw data) isn't pretty for a couple other reasons, so there are challenges.

That said, we are close to approving an extensions syntax, where you and other interested parties could try out offering an alternate rich_description property that interested displayers could individually build support for.

Nate

On Mon, Aug 4, 2014 at 11:40 AM, William G Beazley < notifications@github.com

wrote:

Otto,

I think badges are far advanced from what is convenient to the implementations. I get the part about lines of code but a formatted text box is part of every programming GUI kit. There has to be a subset that is doable. Even this email app I am writing to you with understands newlines.

This is what success looks like: People want the badge to be readable and don't and won't understand why it can't be. I'm afraid that badges must turn into an appliance technology, whether it wants to or not.

I don't know how my cell phone works but I know it need to be usable when I'm in a hurry.

I am not one to parse wording but I don't think you are saying that newline tags are DIS-allowed. Implementors are just not REQUIRED to support them to get blessed by the alliance. If they were included in the word salad and a displayer CHOSE to make use of them, they wouldn't be kicked off the island.

Am I hearing this correctly?

Bill

On Mon, Aug 4, 2014 at 10:20 AM, Nate Otto notifications@github.com

wrote:

Bill,

You're right that this field is "spec'd" as plain text. What that means is that the OBI standard, as stewarded by the Badge Alliance, instructs all implementations that any HTML tags issuers put into that field should not be respected.

Displaying applications have purview over how this line of text appears, not issuers, because the OBI standard is designed for portability of data, separated from concerns of presentation. Even line breaks are stretching this portability.

Changing this is not simply a matter of writing a little code in one application. There are a lot of portability advantages gained by displayers being able to treat that field as plain text. If it were allowed to contain HTML tags, every application that displays this field would need to build hundreds of tests to ensure that the formatting input by the issuer doesn't break the layout of the display application, and hundreds of stopgaps to fix the possible display bugs you might encounter. This is difficult and expensive code to write, requiring front end and back end engineering expertise.

If you took this proposal to the Standard WG, you likely would make no headway there either, but since this is on the backpack repo, the only think that might get through would be a newline filter on this field. But you must then understand, you wouldn't be able to depend on those being respected in other applications. The criteria page is well under your control display-wise, and it is by far a more appropriate place for detailed information about the badge description.

Ingo, sounds like Moodle would be where to pursue code changes. How does it handle criteria pages? Abstractly, within an issuer's context, you can show how your badges work together in a much richer way than the backpack allows. On Aug 4, 2014 7:52 AM, "William G Beazley" < notifications@github.com> wrote:

I think the Moodle people followed the lead of Mozilla in their implementation. Are they not in the lead? I'm told that the description was spec'd out as text only.

This is an easy fix of just respecting a few optional tags for better formatting.. It's a few lines of code at their next "Summer of Fun" codefest.

Bill

On Mon, Aug 4, 2014 at 2:05 AM, ingodahn < notifications@github.com>

wrote:

In our application context (RadioActive Europe project) badge usage is confined by the following boundary conditions:

  1. A large curriculum with many potential achievements that are to be confirmed by badges. Consequence: In order to keep the number of badges manageable, achievements are grouped and badges are issued for groups of achievements. This leads to badge descriptions which consist of a list af confirmed achievements.
  2. Moodle as a badge issueing tool: Consequences: As mentioned by dbhouston, only one description which is displayed inside Moodle as HTML (ignoring line breaks) and on the backpack server as plain text.
  3. Learners use badges for demonstrating their achievements to potential employers. Consequence: Badge holders have a high interest in professionally looking badge descriptions. But this is impossible to achieve with a single line of text.

As the Moodle folks agreed to abandon html in badge descriptions (regrettably), they will hopefully at least respect newlines and a working, though less than perfect, solution could be as proposed by ottonomy (plain text with line breaks). Ingo

— Reply to this email directly or view it on GitHub <

https://github.com/mozilla/openbadges/issues/1030#issuecomment-51024277>.

— Reply to this email directly or view it on GitHub <

https://github.com/mozilla/openbadges/issues/1030#issuecomment-51070321>.

— Reply to this email directly or view it on GitHub < https://github.com/mozilla/openbadges/issues/1030#issuecomment-51074325>.

— Reply to this email directly or view it on GitHub < https://github.com/mozilla/openbadges/issues/1030#issuecomment-51099730>.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/mozilla/openbadges/issues/1030#issuecomment-51102586.

— Reply to this email directly or view it on GitHub https://github.com/mozilla/openbadges/issues/1030#issuecomment-51114097.

canweriotnow commented 10 years ago

Markdown seems like an obvious solution, no? Parsers are available for every platform, can be parsed on the client or server, whatever.

HTML presents sanitization issues... Although I'd love to inject <script> tags into badges to see what happens :feelsgood:

ottonomy commented 10 years ago

I didn't get a chance to bring this into the conversation at today's Standard WG meeting, but I'll make a mailing list post about it and try to get a few of the relevant implementers to comment on the implications. Thanks, @ingodahn, @canweriotnow, @dbhouston, @andreasauwaerter & @erkorb.

ghost commented 10 years ago

Just my 5 cents :) As one of the developers for Moodle badges who had to make a call and strip off any HTML from description I get a lot of complains about it now >.< I want to add my +1 to Markdown or any kind of formatting to the description field as our users would like to have their badges looking reasonably nice both in Moodle and in Backpack...

ingodahn commented 10 years ago

Maybe a practical example can illustrate the need for formatting. The current description of the RadioActive101 bronze badge "Creating Radio Content" reads

"The badge holder has shown the following competencies: Take an active interest in local, regional, global issues which are relevant to the style and branding of your show AND Know and list different types of content and their uses AND Identify issues which may be of interest to your audience AND Form ideas for potential features and present your ideas to the editorial team AND Explain copyright issues and license requirements relating to your particular case AND Source evaluate and choose suitable music and sound files to be edited to make jingles loops and stings"

Imagine a potential employer having to ingest this... Compare this with the formatted presentation in http://radioactive101.eu/podcasts/radioactiveproject/ActivitiesForBadges_en.html .

2014-08-05 22:06 GMT+02:00 Yuliya Bozhko notifications@github.com:

Just my 5 cents :) As one of the developers for Moodle badges who had to make a call and strip off any HTML from description I get a lot of complains about it now

.< I want to add my +1 to Markdown or any kind of formatting to the description field as our users would like to have their badges looking reasonably nice both in Moodle and in Backpack...

— Reply to this email directly or view it on GitHub https://github.com/mozilla/openbadges/issues/1030#issuecomment-51251927.