More Wrinkles

After submitting our project proposals at the end of last week, this week was all about listening to the feedback on our proposals and modifying them accordingly.

I received helpful, interesting, and wrinkle-inducing feedback on my badges proposal. Thus, the remainder of the week was spent re-thinking (for hopefully close to the final time!) the badges structure.

The questions:

1. Does my design communicate to the user the order in which they should fulfill the badges?
2. Should the badges design be based around constructs? What would badges look like if it were based off of a curriculum or storytelling structure? (the animate character badge, the interacting character badge)? What would badges look like if they were based around levels (all novice skills, all intermediate skills)?
3. Can my design easily grow?
4. How does each badge contribute to the larger whole? (i.e. How does getting a badge help me build a cooler world?)
5. Can my design represent the different levels of learning? (remix, tutorial, doing it on your own)
6. How does my design change as the user progresses from beginner to intermediate to advanced?
7. What are all of the badges?

With these questions in mind, I went back into the IDE and tried to tease out what (if not nested constructs) we would want badges to be. I also took a look at some previous work on a tentative curriculum for badges.

The (attempted) answers:

1. I agree with this feedback. While the original design does have a system of suggesting which badge the user should pursue next (based on what they have accomplished or who they are following), I realize that the visualization may be a little confusing. As I continue to design, I will have to keep in mind that, unlike me, our users probably will not have spent the last three weeks thinking about badges and their levels. I think the remedy to this problem lies with changing/clarifying the visualization and/or using the suggestion system more. (e.g. when the user hovers over a gear on her page, only the cog that we think she should pursue next appears)

2. Answering (or beginning to answer) this question is where I spend most of my time this week. There are pros and cons (see below) for all the systems of badges. The crux of the problem lies in what purpose you want the badges to fulfill.

Curriculum system of badges

• This would group skills together according to a lesson plan, or storytelling goal. (e.g. the “animating characters badge” would have getting a body part, and do togethers; the “groups of character badge” would have for each in and each in together)
• Pros:
• Achieving each badge directly relates to a cool animation
• Easily scalable since you can just insert lessons in whenever you create the tests for them without affecting the already existing badges
• Easy to see what to do next (especially if the lessons were ranked by difficulty, or had a progression)
• Cons:
• It leaves a lot out. There are many cool things that you can do in Looking Glass that don’t have a consistent purpose. For instance, a Do Together with a nested While is advanced, will probably make a cooler animation, but won’t directly and consistently contribute to a storytelling goal. Does that have a place in the curriculum?
• It is very rigid. It feels like a language course in which the teacher asks you to use grammar points x,y, and z in a sentence. The teacher may have had a sentence in mind, but that order may not be apparent to the student. The student may spend more time trying to artificially make x, y, and z work together in the same sentence rather than learning the grammar points themselves.
• It doesn’t allow the user as much room to be creative and explore the concepts on their own in the order in which they find them.

Construct:

• The badges would be based on construct. The action order boxes would be nested inside of each other, and the procedures/functions would be separate. (This is essentially the system in my proposal)
• Pros:
• It allows us to reward the users for everything they do.
• It scales well since it is based off of concepts.
• Cons:
• Without the right suggestion system, it may be confusing to figure out where to go next
• Doesn’t account for some advanced skills that play between the action order boxes and the functions (e.g. having and if with multiple conditionals)
• Without some tweaking or help, it doesn’t lead directly into the larger goal of making cooler worlds
• It doesn’t really distinguish between the “things that are cool because you can” (e.g. Do Together with a nested For Each In) and “things that are directly related to some larger concept” (Having a Do Together with a nested Do In Order)

Neither system is perfect, no system will be perfect. Thus, I set about thinking of ways in which I could increase the “pros” and decrease the “cons.” After some intense brainstorming sessions with Jordana.... I am down to two different ways of thinking about badges.

1. Construct-based badges with storytelling goals.
    In this system, all the badges would be based on construct (so that way the users can be awarded for all the cool and different ways they build worlds). On top of this base system of badges would be a system of storytelling goals. Instead of setting an individual badge as your goal, a goal would be a cool way to combine badges. For instance, having a Get A Body Part badge and a Do Together with a nested Do In Order Badge may be the “animation goal.” Having a For Each with a nested Count and Locally declared Array Badge would be another goal. Alternatively, lessons or levels would be built around achieving certain badges. Each badge would be a stepping stone to a different lesson.
    This does imply, that “Goals”( or Lessons or Levels) become something else entirely that the user could potentially display on their page.

2. Badges with levels
    In this system, each badge would have different levels (bronze, silver, gold). These levels wouldn’t be specifically based on the nesting of Action Order Boxes, but instead on the particular skills that think are interesting for each badge specifically.

For instance:

• While
• bronze
• locally declared boolean
• while loop in response to a user given parameter. (potentially gold)
• silver
• NOT a conditional
• conditional that changes during the course of the while (thus breaking the loop)
• gold
• comparing conditionals (<, >, !=, etc)
• multiple conditional (or, and)

• For each
• bronze
• using a locally declared array
• silver
• nesting count, while, for each, if, do together, each in together
• gold
• passing variables to while, if, count,

Currently, this is the system that Jordana and I are leaning toward. As always, there are more questions than answers :D. I will continue to mull over these questions tomorrow and in the coming weeks. However, my hope (and goal!) is to have a base system of badges in place by the end of tomorrow so that I can progress into building.