Devcathlon Mockup Part 2

Premise:
In continuation of the previous two blog entries regarding Devcathlon, I will again review my experiences and concerns in this second part iteration of Devcathlon's mock up site. I will also briefly mention additions to our events list, the concept of "badges", and levels.

Designer <=> Developer:
This is my second iteration of mocking up the interface design for Devcathlon's site. I noticed that the first mock up proved to be a challenge since it used to be easier to just pass the design stuff over to a professional designer, and not have to worry about it. This kept the designing and coding schema separate and provided production boosts (through specialization) for the overall project. However, in these past two mock ups I was able to wear both hats of being a developer and designer. First and foremost, CSS is a prevalent skill. I say this with confidence, because any markup text in this day and age requires the usage of CSS. Do whatever you can to muster the basics of elements, tags, descendants, etc. CSS will be heavily used in your HTML and it's a proven to simplify a lot of styling out of your markup (keeping HTML basically what its good for, which is rendering text and links). I think the terms of a "developer" or "designer" can be interchanged and used similarly in certain situations. Considering the objective, problem or solution, either a designer or developer will look at it in terms that are not all that distinct. When a programmer programs, he or she technically has to "design" themes from real world entities that can be classified as classes (in OOP languages today). Even though when the programmer thinks that he's "programming," in fact, he's actually designing before even writing a single line of code. On the other side of the coin, designers are faced with the fact of creating something usable, appealing to a user, and seem less. So, designers simply create GUIs in the front-end of the spectrum, yet they transmit some work flow details of a user. The work flow of a user is the interesting part of being a designer. At the stage of getting the "look" down, a designer must also take into consideration for the "feel" of what they are building (eg: buttons, links, forms, etc.). These interactions are crucial and play a large part in the functionality and behavior of a site.

"Eventful" Additions:
My team and I came up with two other simple events regarding the basic units of building and coverage. A team member can build to success or failure depending on circumstances of frequency and trend relations. If a person builds frequently, and does so over a certain period of time without significant changes to the code, then that person gets penalized for "unnecessary building" (vice-versa). The other concept deals with the almighty relation between writing test code and coverage. Instead of just looking for an increase or decrease in the level or percent of coverage, we will also include the relational trend of the graph. Some relational dependencies to this event include: early test cases and incremental coverage gains. The trend (provided by Hackystat) should help in determining early built test cases for basic class or method functionality. From there on, we detect any fragments of change in coverage (gains or loss). If the user continues following the good practice of writing his tests before integrating the app any further (test driven development), then he'll benefit in the long run of the game. As for those who don't change much in coverage and remain stagnant throughout will suffer penalties.
The concept of "badges" is not a new topic, but it has been highly mentioned when dealing with determining valuable players in the game or team. Badges are awards (almost like mini trophies) given out to individual players who achieve certain number of plus points.
Another concept was the idea of "levels" for a player or team to achieve a certain number of points to advance. A player or team can advance to levels through a system of recognized achievements. Just to add some kicks and giggles, we followed the concept of human evolution with imposed implications of software engineering as the end point of the time line.

The code and other resource materials can be found here: http://code.google.com/p/hackystat-ui-devcathlon/