Optimizer: A Platform for Performance
As I had explained in the blog post “The Importance of Performance – A Direction to Consider“, I had explained a possible direction in which I would head for the case study of my master thesis. In the week since that post, I have given it quite a bit of thought, trying to see how I can make the elements I had distilled using the “Game Mechanics and Dynamics” approach meaningful. As may have become apparent from my blog post on the subject of the Meaningful Framework, I am fully intent on trying to accomplish something that has a long term benefit, through gamification. As is likely to be expected, this is easier said than done. Finding examples of such meaningful gamification is difficult, so it often involves just thinking about your own reactions to these ideas. By definition, meaningful gamification is user-centered, so what I have worked out so far needs to already be subjected to feedback by people who may well be possible users of the application. So, without further delay, I will attempt to explain in greater detail, the elements I am planning on adding to the application. In the coming week, I will also attempt to create some paper prototypes of possible UIs, which I will post in a separate blog entry. Until then, I’m afraid text will be your only guide.
My proposed application will tackle the complicated issue of working towards a performant process. Because it is my own field of study, it is easy for me to use Computer Science, and more precisely, programming algorithms, as an example to explain the workings of the tool. It is important, however, to understand that the application can be used for any problem that requires a performant solution. I will try my best to keep examples, terms and names generic, but this may not always be possible, or there may be some oversights. With that out of the way, what do I mean by “posting solutions“?
Users will be tackling a certain problem that requires a solution. For example, the quickest path through a graph. Perhaps they wish to develop a solution themselves, or perhaps they base themselves on established algorithms such as Dijkstra’s famous solution. Regardless, they post the fruits of their labor onto the application. A post will require the following information to be filled out:
- Name/Title of the Problem: Self-explanatory, really. The user will add a name, title or description to his post, allowing others to know at a glance what problem he/she is tackling.
- Description of the Problem: Users can also write, in the form of extra comments, the details of the problem they chose to tackle, in the case of the previous example, this would be the shortest path through a graph.
- Description of the Solution: If their solution is in fact code, in some form or another, or perhaps other non-explanatory solutions, users would do well to also include a description of how they chose to tackle the problem, how they solved it and why they believe it works. In the case of a performance problem such as transporting a certain amount of goods from one location to another within a warehouse, this part of the post is unnecessary as the actual solution would already detail this. However, they can still use it for additional information, or a summary.
- The Solution: In the case of code, it would be pasted with the proper formatting, but in general, the text stipulating the solution will be posted in a large textbox, allowing for all the formatting and text manipulation options that we are accustomed to. Users will also have the possibility to split their solution up into one or more tabs, allowing for more structure, especially in the case of programming code where users may want to keep the file structure they used in their chosen IDE.
- Tags: Users will also need to add relevant tags to the post, allowing other users to quickly track down related problems. In the case of the previous example, this could be graph, among others.
- Results of the Solution: These results are posted given a certain input. In other words, the user must describe the platform on which he/she ran the solution, as well as what input it was given and how quickly a result was produced. Again in the case of the previous example, this could be a graph of a given size and structure that had its shortest path determined in a certain amount of time, with a certain amount of operations. This is mainly text-based, like many of the other details.
- Miscellaneous Information: This would contain simple checkboxes to make the post public or private upon release, in case it is simply to serve as a draft and other such possibilities.
- Attachments: These can include, among other elements, archived source code that can be used by others to verify the claims of the solution.
When all of this information has been supplied (some elements are optional, of course), the post is created and revealed to the other users, who can then proceed to interact with it, and its writer, in various ways.
Responding to Solutions
Other users can do the following things in response to a given post:
- Rate the Solution: The solution can be rated with a number between -5 and 5. It is a simple system which would need the backing of comments to be meaningful, but it gives the poster a basic idea of how good his/her solution has been received. What this rating means is also very personal and context-based, but in general it will begin low and increase in subsequent iterations, provided the next iteration is an improvement.
- Post a Comment: Users can post comments containing, preferably, useful and valuable feedback for the person that posted the solution. Naturally, it can also become a back-and-forth between the writer and one or more commenters, as long as the end result is beneficial to all involved. Comments can also be “liked” by other users, which would be to the benefit of those who posted them. If a comment violates basic rules of conduct (harrassment, spam, …), they can be reported like with many such interactive platforms. Links to other posts/problems/solutions and content on the application itself can be attached instead of copy-pasted as urls, making them more accessible as buttons and the like below the comment.
- Create a Challenge: What challenges are, in detail, I will go over in another section, but users will be able to auto-generate one for themselves, which copies some basic information from the post they have been reading. In short, this would challenge them to attempt to implement a solution to the same problem, or perhaps improve the solution presented by the other person to achieve a better output with the same (or another) input.
- Issue a Personal Challenge: Users can also issue personal challenges for the poster to respond to. These personal challenges can have a variety of goals, but will always attempt to urge the other to improve their work in another iteration, or to perhaps challenge them to try out their solution with a different input supplied by the challenger.
Challenges are one of the less common elements I intend on adding to this application. A challenge, in its most elemental form, is nothing more than a verbal “calling out” to a certain end. Users will challenge each other to beat a certain input/output combination, or to implement a certain solution to a given problem. How challenges are written up is completely up to the challenger, giving him full reign in what it entails. Naturally, some elements need to be present and certain rules are involved in their creation (game elements need rules, naturally, or they can be abused or subjected to user-generated “cheating”)
- Challenges are issued from one person, to another, but can be issued to yourself, as in the case of auto-generating one from someone’s post.
- Posts can be tagged as being related to certain, accepted challenges. The issuers of these challenges will then be alerted wheneve solutions or iterations of solutions are posted.
- Challenges are deemed completed as long as a solution that has been tagged as a response to a challenge receives more positive scores than negative ones (there would be a minimum score required, such as +15). In other words, it is up to a variety of other users to decide whether the person that accepted the challenges has succeeded or not, resulting in more impartiality than if it was only up to the challenger.
- Users can never fail a challenge. They can continue to post iterations until they have the score they need to pass it, and even then, it is only removed from the list of active challenges if they choose it to be. Challenges can be dropped whenever the user wishes, with no negative effects.
- Users can choose to refuse a challenge right away, with no need to give any reasons, again, with no negative effects except the possible loss of a learning experience.
- Challenges can be formulated poorly, with no further explanations from its issuers, or can simply demand unexpectedly high results from the challenged. Perhaps the challenge is simply impossible. In those cases, they can received dislikes, just like any comment, and be dismissed in this way. This would be to stimulate challengers to think about what they ask, thereby making them beneficial for the issuer as well.
The use of challenges is very clear. They create compition for some, or simply the urge to continually improve for others. These challenges can also be issued back and forth, creating a competition between two or more users as incentive to think about how to create a performant solution. In the context of programming, this could result in discover small habits they had in writing code that resulted in unnecessary operations that they never noticed or thought about before. Because answers to challenges come in the form of posts or iterations, any other users can still post comments and feedback as normal, keeping the loop going. Naturally, these are not only for the competitive, as I stipulated in previous posts that not everyone reacts positively to these. While a “challenge” implies competition, it is meant more as a source of a sense of achievement for the parties involved. A last element of challenges are challenge tracks. The framework for meaningful gamification also showed that user-generated content can prove to serve as a thoroughly engaging element of games and thus, gamified applications. To that end, users can create their own challenge tracks. But what are they?
Challenge tracks allow users to create a set of milestones, each with an achievement and/or badge attached to them. Users would supply a name for the track, a certain subject and the various milestones. A good example could be the one I gave before, about the shortest path through a graph. A simple track could be that a basic, working implementation would be the first milestone, a performant version the second and the third being one that beats a certain, difficult, input. As with normal challenges, these milestones are context-bound and success is evaluated by other users. Tracks are also not meant solely for those who created them. Other users can check challenge tracks and decide to tackle one or more of them, giving good feedback for its creator if they are well-designed and thought-out. This will allow like-minded individual to get achievements, challenges and badges that are actually meaningful and helpful to them, making them want to perform the activity and then show off their results, instead of being stuck with a heap of generic, pointless badges that few people will care about.
I have more to discuss on this idea, but for now, I will leave it at this. In my next blog post I will cover what I have done with the points system, badges and personal profiles, as well as why I believe these game elements will provide meaningful gamification for the proposed application, which is, after all, the whole purpose. I hope this post has given some insight into what I’ve been doing and there is more to follow.