Easier Gamification with Badge-O-Matic
Posted in: Badges, BigDoor news, Blog, Gamification, UI on August 31, 2010 | No Comments
So you’ve already decided you want to reward your users for performing certain actions by giving them points and badges. Level up! But you’re stuck on the next step: “Now how do I make my stinkin’ badges?”
In our system, awarding the progressive badges as users hit different thresholds of activity used to require a little bit of tinkering. You would create URL objects for the badge images, and then you had to tie them to the different Level objects in a Level Collection, which was tied to a Currency, etc. It worked great and kept track of everything for you, but simply wasn’t very user friendly to set up.
With that difficult experience in mind, we’ve introduced the Badge-O-Matic to our account tools. This new quick start tool ties together the different objects in our system so that you can easily create and edit Badge levels without having to jump around in your Economy settings. It’s even got a few template badge level tracks that you can use directly in your own gamification experience, or that you can just feel free to play with to learn how things all work together.
Even if we don’t have a premade template that matches exactly what you want to do, remember that Badges in our system are entirely customizable with your own creative since you can always point URLs to your own image resources and define them any way you want. Want to create a badge set that awards 25 different levels of custom Unicorn Horn badges for users who add more and more virtual Glitter to their profile page? Badge-O-Matic can do that. But it may feel a little bit embarrassed and not talk about it at home.
Check it out now to get yourself some stinkin’ badges. Or watch the video below for more details.
- roy
Beginning UI Design
Posted in: Blog, Development, Technology, UI on December 17, 2009 | 2 Comments
And now another word from the developer side of the house:
With many years of experience in the Microsoft static development world with all their fancy programs and business models I have found it quite difficult to make the initial pivot into the dynamic world of Python and Javascript. That being said, it has been quite exciting to not have everything handed to you on a silver platter. This post describes the initial design and structure of the code behind a flexible UI.
Javascript
In the Javascript world, one of the big points I keep hearing is that Javascript needs to be written from the prototypical mindset. As I have learned in past experiences, it almost always less of a headache to not fight the design of the paradigm but instead learn it’s intricacies and use it to your advantage. Hence, I have slowly learned how to incorporate duck typing to accommodate a style of coding that enables other developers to plug-in to the same objects being passed around and extend the current system.
With this belief in mind, I have come to a point where I believe the best course of action is to use a classic OOP design. The hardest part of implementing inheritance is that I constantly wonder if there is a way to be just as efficient in the dynamic/prototype paradigm. For most developers this is quite hard to put aside due to curiosity and performance improvements but my first lesson of operating in a startup, has been to focus on glaring, rather than possible problems. A difficult task but there are more interesting problems to solve at this point.
Events and State
One of my favorite parts of Javascript and Python is the ability to pass functions around as variables. Growing up in the Microsoft world, this was quite difficult to do with type restrictions on delegates. It was still possible but not nearly as easy. (It will be much easier with their upcoming dynamic keyword.) Seeing as how we need a way to link the state of a control to a particular action which occurs on the page (not necessarily attached to the state of the dom), I needed a way to call multiple functions when one action occurred. Basically, I needed Javascript to support event-driven design.
At this point all the event manager does is use an associative array to store function signatures in an array and then sequentially call those functions when the event is raised.
var onrender1 = function() { alert('Render receiver 1'); }
var onrender2 = function() { alert('Render receiver 2'); }
var manager = {
events: {},
trigger: function(event) {
for(e in this.events[event]) { this.events[event][e](); }
}
}
manager.events.rendered = [onrender1];
manager.events.rendered.push(onrender2);
manager.trigger('rendered');
// Render receiver 1
// Render receiver 2
Download [zip]
Finally, the manager could be designed as a class to enable instances and attached to objects, allowing objects to enable events using duck typing if necessary.
This is only a basic implementation but works for are requirements quite well. It might be better to implement in the prototype model at a later time…but that’s for another time.
The entire purpose of enabling events is to call functions as soon as something happens This is extremely important when there are multiple controls/components whose visual state depends on a particular action (user initiated or not). A model similar to this is the UI state manager in Silverlight which handles events as well as supports dynamic transitions.
Personally, this is an exciting and interesting beginning to the UI development cycle.
- Collin