New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define Badge Status #28

Closed
xmatthewx opened this Issue Dec 4, 2013 · 13 comments

Comments

Projects
None yet
6 participants
@xmatthewx
Member

xmatthewx commented Dec 4, 2013

tying together #14 #15 #16

A Badge can exist in a few states:

  • draft
  • template
  • live / active
  • archived (has been earned, but no longer available)

Are these the best terms? Are there any other states?

@threeqube

This comment has been minimized.

Show comment
Hide comment
@threeqube

threeqube Dec 5, 2013

What do you mean by archived?

threeqube commented Dec 5, 2013

What do you mean by archived?

@carlacasilli

This comment has been minimized.

Show comment
Hide comment
@carlacasilli

carlacasilli Dec 5, 2013

archived badges are possibly old badges that are no longer being issued, it's like cold storage. ❄️

carlacasilli commented Dec 5, 2013

archived badges are possibly old badges that are no longer being issued, it's like cold storage. ❄️

@threeqube

This comment has been minimized.

Show comment
Hide comment
@threeqube

threeqube Dec 5, 2013

That makes sense. Thanks! So "no longer available to earn".

threeqube commented Dec 5, 2013

That makes sense. Thanks! So "no longer available to earn".

@stenington

This comment has been minimized.

Show comment
Hide comment
@stenington

stenington Dec 6, 2013

Contributor

@christensenep I'm thinking from a technical perspective that:

  • templates
    • live in badgekit db
    • can be edited, duplicated as new draft
    • can not be made live/active
  • drafts
    • live in badgekit db
    • can be edited, made live/active
  • live/active
    • live in openbadger, maybe badgekit db too
    • can be issued, archived, duplicated as new draft
  • archived
    • live in badgekit db, maybe openbadger db too
    • can be duplicated as new draft

What do you think about the potential duplication of data between badgekit and openbadger for live/active and archived badges? I tend to think once badges are in openbadger then that should be the data source, so you're never accidentally issuing a badge different than what you saw in the interface if the two dbs were to get out of sync.

Is there a better way to deal with that though?

Contributor

stenington commented Dec 6, 2013

@christensenep I'm thinking from a technical perspective that:

  • templates
    • live in badgekit db
    • can be edited, duplicated as new draft
    • can not be made live/active
  • drafts
    • live in badgekit db
    • can be edited, made live/active
  • live/active
    • live in openbadger, maybe badgekit db too
    • can be issued, archived, duplicated as new draft
  • archived
    • live in badgekit db, maybe openbadger db too
    • can be duplicated as new draft

What do you think about the potential duplication of data between badgekit and openbadger for live/active and archived badges? I tend to think once badges are in openbadger then that should be the data source, so you're never accidentally issuing a badge different than what you saw in the interface if the two dbs were to get out of sync.

Is there a better way to deal with that though?

@christensenep

This comment has been minimized.

Show comment
Hide comment
@christensenep

christensenep Dec 6, 2013

Contributor

I was also thinking that it would be best if "active" badges were indeed just stored in the openbadger DB. I'm not sure if there will be any gotchas down the line with that, but it certainly seems like a good approach.

Now, we MAY want to keep "active" badges hanging around as drafts in the badgekit DB as well, so that someone could clone an active badge and be able to edit it as fully as possible (including editing/moving component images and such).

That said, there could be weird issues if the badge image was manually changed on the openbadger side. You'd clone the badge, and then suddenly the newly cloned badge would be built from the old images still stored in badgekit's DB. That would be gross, so maybe it's best if we don't do any of the fancy stuff I was just babbling about, and just abandon all our data about the badge-in-progress the moment it becomes active.

Contributor

christensenep commented Dec 6, 2013

I was also thinking that it would be best if "active" badges were indeed just stored in the openbadger DB. I'm not sure if there will be any gotchas down the line with that, but it certainly seems like a good approach.

Now, we MAY want to keep "active" badges hanging around as drafts in the badgekit DB as well, so that someone could clone an active badge and be able to edit it as fully as possible (including editing/moving component images and such).

That said, there could be weird issues if the badge image was manually changed on the openbadger side. You'd clone the badge, and then suddenly the newly cloned badge would be built from the old images still stored in badgekit's DB. That would be gross, so maybe it's best if we don't do any of the fancy stuff I was just babbling about, and just abandon all our data about the badge-in-progress the moment it becomes active.

@ghost ghost assigned iamjessklein Dec 6, 2013

@xmatthewx

This comment has been minimized.

Show comment
Hide comment
@xmatthewx

xmatthewx Dec 7, 2013

Member

Your outline looks great @stenington

Regarding duplicated storage: When a draft badge is published, we could ask issuers if they wanted to also start a new draft or save a template (big publish button, small option checkbox). That way, you can avoid db sync issues, but before you dispose of the data, keep some of the flexibility that @christensenep describes. We can delete our cake and eat it too. 🍰

Member

xmatthewx commented Dec 7, 2013

Your outline looks great @stenington

Regarding duplicated storage: When a draft badge is published, we could ask issuers if they wanted to also start a new draft or save a template (big publish button, small option checkbox). That way, you can avoid db sync issues, but before you dispose of the data, keep some of the flexibility that @christensenep describes. We can delete our cake and eat it too. 🍰

@xmatthewx

This comment has been minimized.

Show comment
Hide comment
@xmatthewx

xmatthewx Dec 7, 2013

Member

For terminology on the frontend, I would likely say Copy for new drafts from live or archived badges. I would say Use or Open for new drafts from templates. Technically, it's all duplication on the backend. But, an issuer might think they were duplicating a template to create a new template rather than a sparkling new draft.

Member

xmatthewx commented Dec 7, 2013

For terminology on the frontend, I would likely say Copy for new drafts from live or archived badges. I would say Use or Open for new drafts from templates. Technically, it's all duplication on the backend. But, an issuer might think they were duplicating a template to create a new template rather than a sparkling new draft.

@iamjessklein

This comment has been minimized.

Show comment
Hide comment
@iamjessklein

iamjessklein Dec 9, 2013

Contributor

+1 @xmatthewx and @stenington great points here. For the sake of adding to the terminology conversation - we have been using these three words synonymously: live, active and published. Do we feel that there is any distinction between the three proposed states? If not, my preference is published - since it shows : a) that it it actively in use b) that it is in fact being "published" on a site outside of badgekit and c) that it can be duped etc. and possibly d) that in it's current iteration, cannot be edited. Thoughts?

Contributor

iamjessklein commented Dec 9, 2013

+1 @xmatthewx and @stenington great points here. For the sake of adding to the terminology conversation - we have been using these three words synonymously: live, active and published. Do we feel that there is any distinction between the three proposed states? If not, my preference is published - since it shows : a) that it it actively in use b) that it is in fact being "published" on a site outside of badgekit and c) that it can be duped etc. and possibly d) that in it's current iteration, cannot be edited. Thoughts?

@xmatthewx

This comment has been minimized.

Show comment
Hide comment
@xmatthewx

xmatthewx Dec 9, 2013

Member

I like Published. Familiar to many b/c of Wordpress. Is that a good thing? You be the judge.

Here's a breakdown of each status and the actions available to an admin.

badgedirectory-wireframes-05

Member

xmatthewx commented Dec 9, 2013

I like Published. Familiar to many b/c of Wordpress. Is that a good thing? You be the judge.

Here's a breakdown of each status and the actions available to an admin.

badgedirectory-wireframes-05

@threeqube

This comment has been minimized.

Show comment
Hide comment
@threeqube

threeqube Dec 9, 2013

Will all Badges require 3 forms of issuing?

Not require but made optional perhaps?

threeqube commented Dec 9, 2013

Will all Badges require 3 forms of issuing?

Not require but made optional perhaps?

@iamjessklein

This comment has been minimized.

Show comment
Hide comment
@iamjessklein

iamjessklein Dec 9, 2013

Contributor

Nice work consolidating here, @xmatthewx
I agree, @threeqube - I suspect that there are 3 available states and whatever state the badge is available will display.

Additionally, I suspect that when you are in a state (for example Draft) there should be some option to convert of save to another state.

Contributor

iamjessklein commented Dec 9, 2013

Nice work consolidating here, @xmatthewx
I agree, @threeqube - I suspect that there are 3 available states and whatever state the badge is available will display.

Additionally, I suspect that when you are in a state (for example Draft) there should be some option to convert of save to another state.

@xmatthewx xmatthewx closed this Dec 13, 2013

@xmatthewx

This comment has been minimized.

Show comment
Hide comment
@xmatthewx

xmatthewx Dec 13, 2013

Member

Closing. Some of the language will be refined later. But the idea/structure seems to sync well with everyone.

Member

xmatthewx commented Dec 13, 2013

Closing. Some of the language will be refined later. But the idea/structure seems to sync well with everyone.

@threeqube

This comment has been minimized.

Show comment
Hide comment
@threeqube

threeqube commented Dec 14, 2013

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment