It's Never Over Till It's Over

No.... TeamMS, we will get you! We will make our comeback just you wait and see.

While I get worked up occasionally seeing the score between all of our matches in Devcathlon, I have to wonder what flaws are in the system. Does this score really reflect the difference between our teams? If it does, maybe there's a loophole I'm not aware of that allows me to cheat in favor of my team? Also how does system usage feel? All of us have been working on this so much, we haven't really stepped back to see what could be improved.

Flaws in the System.

Let it be noted, I was purely looking up such flaws to "improve" the system, not cheat to achieve my ultimate goal of winning. o.O

1. Teams are not locked to a set of members at start of match -- As pointed out by Zhou, a team can start a match even with pending member invites. This means that team members can join or quit a team at any point Got a crappy player? Ask him to resign. Got a potential strong player that hasn't accepted? Ask him to join immediately.

2. Event Score relation to User. -- From what I recall, the EventScores were never tied to a user. I question the scores, since there is no true way to trace which member triggered the award/penalty. I admit my team lost the NoMIAs event, no doubt. But PassTheBuild? I think there were a couple of individuals on the other team who may have triggered in a negative way.
But I don't have proof!

4. Not enough system messages. -- Creating a team/match with an identical name is not allowed. But no error message is ever displayed on the page. Only on the console. I think a console ouput panel for all pages would be a good idea. It will even applies when a match is started, or when events run.

5. Team Record not 100% working. -- This is mainly my fault. I only tested this with the initialized data. It seemed to be working with positive scores, not sure what the cause is. Weird that it's not working with negatives.

6. Score in scoreboard should be more apparent. -- It was difficult for me to know what the score was without screenscraping the page for that information. Typically scores are placed near the team logos on a traditional scoreboard.
User Evaluation

I showed the system to a friend. The good news was he was able to quickly grasp that the application was a game based on the way scores are presented. He liked the layout, describing it as clean and easy on the eyes. He liked the simplicity of the menus.

However, his main issues revolved around system messages not being obvious (e.g. user needs to login). He also thought display of information could be cleaner. He didn't like how long the list the list of match events/explanations was and suggested using a vertical scroll for that panel instead. He would like to see simple things like "see details" to be displayed in one line instead of wrapped in its panel when there's a long match name. He also wished there was slightly more graphics to sort of "wow" him.

He found it somewhat funny that teams could be in negatives. It was something different but logical in respect to this game.

Top 5 Lessons Learned from ICS 414

(In no particular order)

1. Communication is key.

2. Working with a large group can be difficult.

3. Working with others can be helpful.

4. Everyone has something different to bring to the table.

5. High dependency on others' can be dangerous. Things can slow down if one falls behind. (similar to the "coupling" concept).

Who's that guy I see in the mirror?

I think this course really strengthened me in terms of dealing with reality. When you fail, it isn't as simple as just getting a low grade. You should get bashed because a client expects something working. We may not be so fortunate to have second chance opportunities. As far as improvements, I think I am more open to working with people on a regular basis. I found myself asking for pair programming opportunities. I don't know how many times I was at Sinclair library pair programming with Robin or Phillip.

Honestly, I think my programming skills are still somewhat unpolished, but I definitely feel capable. As far as what aspect I want to work on next, it may be to take more of a leadership role.

Wow. OMG! Phew. Sighs....

Well, that sums it all up right there. It was pretty unbelievable the different things we encountered throughout this semester. I can't say it was a great roller coaster ride. It was filled with more valleys than peaks. But I don't regret being a part of the process. I think I learned something from each individual and made some friends along the way.

Spring Break!

What better way to start off spring break than with an assignment? Haha. Well to be truthful, developing on Devcathlon the Spring Break isn't too bad. I don't have to worry about limiting myself to a certain amount of time because I need to do other assignments.

What I did:

As I write this blog, I have 2 commits since we disbanded Wednesday. I probably should have broken it up into smaller commits. It's just kind of hard to stop sometimes. Time flies by when things are finally clicking, then you don't want to stop.

I was successful in adding a mockup of both Team Manage submenu and Team Invitations. I got much farther wicket wise with the Manage submenu. I spent a lot of time focusing on actually adding a team. I fiddled around with the TeamManager and successfully created a team with no members, and myself as the owner. Right now, I have a genericInit() method that adds a team through Java code. So I then retrieve the list of teams to dynamically populate the Manage submenu. I just need to apply that with a wicket form and I think I am close to having a fully functional "Create a Team".

Contributed to packages:

• org.hackystat.devcathlon.ui.page.teams.manage
• org.hackystat.devcathlon.ui.page.teams.invitations
• org.hackystat.devcathlon.ui.page.teams

Number of Meetings:
1 face-to-face meeting at Holmes Building
2 Google Chat

DevTime:

Hehe... I had a little more time on the weekend than early in the week. o.O

My Issues:
Issue 44: Add mockup of Team Manage submenu. Status: Done.


Issue 49: Add mockup of Team Invitation submenu. Status: Done.

Issue 54: Implement Creating Team form. Status: Accepted.
Issue 55: Implement Team Invitation. Status: Accepted.

CSS - Confusing Stuff, Son

Alright, so the "son" was a cheap add-on to make the CSS acronym work. But hey, that's the best I can do. Anyways for the task this past week, we went back in time to rediscover our old friend (and enemy... sometimes), Wicket and start thinking of how to implement things for Devcathlon using it. Particularly this week, we worked on modifying a menu bar.

For now, our menu bars are not your fancy javascript drop-down menus, but it does it's job. Borrowing the CSS code from Kalsey (http://kalsey.com/2003/05/css_tabs_with_submenus/), we have menus bars with submenu's right below it. We needed to modify the bar so we address the following issues:

• support 10 submenus (wraps around screen, and overlaps content ?)
  
• realize the shortcomings of the submenus (due to its absolute positioning)

• indicate which page user is currently viewing (by making menu link bold)
  

Problems Encountered:

I was able to figure out the last two tasks, but not without some difficulty. The hardest one was indicating the page the user was viewing. From the beginning, I knew I wanted to add a class tag "selected" and just add a class property to the CSS making the font bold. After hours of slaying away trying to get it to work, I finally got it by adding this one line to each Menu's page (plus the CSS property in menu.css):

// from SubMenu14Page
// tags corresponding link with class, "selected" for CSS to make bold
get("SubMenu14Link").add(new SimpleAttributeModifier("class", "selected"));

My Shortcomings

The only task I was not able to finish was the 10 submenus. I assume the problem occurs when there are 10 submenus, the submenus wrap around the screen overlapping the page's content. I can only assume because 10 submenus displayed fine for me because I had my window maximized.

I tried adding padding & margins to the submenus creating whitespace between the submenu and content. Nothing. I tried adding margin & padding to the content with the same idea, but that was no good. Maybe the problem is the wrapping itself. I honestly wouldn't want my list of tabs wrapping around the screen if I purposely resized my window to be smaller.

Oh well... guess I'll find out from the others when this is all said and done. I gotta say though, FireBug (which Anthony Du pointed out to me in our last mockups) was extremely useful in this exercise. Because some of my css properties weren't refreshing when I modified the files, I just used FireBug to preview properties on the fly. Good stuff.

Distribution file: [Download Link]

Procrastination is Bad

Alright, this was my second event for Devcathlon and things were less scary and confusing. I wasn't completely lost, which felt pretty good because it meant I was making progress.

My event for this week was, "Don't Wait Until the Last Minute". Basically, the event calculates the average number of builds, commits, and development time (devTime) over the entire match. Within the last n days, if any two categories (builds, commits, devTime) exceeds their respective averages by over m percent, then the team will be penalized. The event is meant to discourage procrastination, so there won't be any last minute "rush-to-finish-up" moments.

Although the event specifications indicated to take the averages over the entire match, I opted for something a little different. If we were to continuously take the averages throughout the entire match, then the average may fluctuate if there is a lot of activity within the penalty period, making the policy a little more lenient (see below). To discourage this work around, I only took the average during the non-penalty period.


What I Learned

I feel through this exercise, I learned a bit more on where to look for data retrieval and retrieving different types of SensorData. I initially retrieved all data using DailyProjectDataClient. But after realizing that I need to retrieve data for an extensive period of time, it would take forever to loop through an entire match collecting 24 hours of data at a time. SensorBaseClient allowed me to retrieve data within a time period I specified.

During my earlier encounters, I had trouble retrieving commit data. But after a (long) look through some documentation, I was able to solve it by adding a property field that was missing. On a side note, I probably would have been deducted points for this event. While I did start early, I think I spent more time towards the end.

Trimming the fat

Just this week, we were assigned to starter events for Devcathlon (the Hackystat Game). Unfortunately, things didn't go as smoothly as planned so an extension was given so we would have a chance to improve our work.

My starter event, "Best Coverage", was done for the most part. But it did contain unnecessary parts of code (e.g. retrieving build data, when not really required) and could have been improved by adding static final to some of the instance variables.

I also broke one of our Coding Standards that was set back in ICS 413 (Software Engineering 1) when I used a while loop. I am ashamed. Other than this, the main issues I needed to address are as follows:

1. Build Data

I originally imitated the KeepTheCoverageHigh class by reading in build data as well. What's continuous integration build data have to do with coverage? Nothing really. But I figured it was used because the event will be run once a day, the same interval Hudson runs. So if there hasn't been a build, then there should be no new coverage either. However, the event now ignores that, and just checks for the most recent coverage information. This is probably better since its independent from the continuous integration data.

2. Static Final Variables

This is definitely useful for other classes to use. It's hard to keep a track of string variables especially ones that are used for specific fields. It's also a pain in the butt to use the hardcoded string each time I need the field. Making static helps because I can just access it by something like BestCoverage.dayStreakKey in any classes outside of itself. Well final is simply because we don't want or need the string to ever change.

It's also nice to look in one place and never need to hunt for every occurance of the string when a change is in order.

Besides that, my event should be done. I do feel awful that I went M.I.A. yesterday and most of today. I had a slight fever and cold and decided to rest. At least I wasn't M.I.A. for 3 days, or else Daniel's event would dock some points from me. I do notice a lot of errors has been happening and I think I need to look over those errors now. That way, I learn and I know what to do if that were to happen to me.

Are You My Mountain?

"Beyond the Mountain is Another Mountain" - Haitian Proverb

Taking one out of Ronn's book, I thought I'd open up with a proverb. It's weird though. I always thought that was a Chinese proverb since I've always heard my parents say it. Anyways, it basically means there will always be challenges in life (at least from my interpretation) . There is always something bigger and better than you. You can't conquer them all.

I think the concept sort of applies here. There are always challenges in life, and there are definitely various challenges in Devcathlon. My starter event/challenge, "Best Coverage", is an example of that. The goal is to be the team with the higher coverage, but you anticipate the other team to constantly challenge and overcome your previous percentile.

For those new to the idea of Devcathlon, it is a continuous integration "game" based on Hackystat sensor data. Teams are formed and when a certain pattern of behavior is exhibited in the sensor data, the team is awarded points. At the end of the match, the team with the most points win.

Best Coverage Rules and Specifications

• Wakeup once every 1 day.
  
• Team with the highest coverage is awarded 10 points
• If the same team has the highest coverage for 5 days in a row, award 10 points.
  

Programming Process & Problems

I was fortunate that my event was similar to the example given. I simply read in the match, looped through all the teams and recovered any recent commit records. With those records, I would compare coverage and return the highest team with that data. If the team with the highest coverage is the one specified in the parameters, then award them points. Otherwise, do nothing.

Initially I had the program loop through all the teams and award the team with the highest percentage. But in the event of ties, only one team would be rewarded in my original code. So I modified it. It worked out well because its consistent with all the other compute scoring methods where you have to run the computeScore method once for each team. So I decided to only award the team with points if it has the highest coverage PLUS it is the team specified in the parameters.

Example Pseudocode:

computeScore(match, team, event) {
 if(hasHighestCoverage(match, team) {
   awardPoints();
 }
 else {
   awardNothing();
 }
}

To award all teams,

for( Team team : match.getTeams()) {
 computeScore(match, team, event);
}

Testing

While that went well, testing wasn't so smooth at times. Because the wakeup period (or frequency of event) is 1 day, I tried to add build data and commit data with Timestamps 1 day apart from the previous. For some weird reason, that would throw an error. I noticed the example didn't require such, so I ignored it myself.

At first, I was only testing with one team in a match, which is not practical with such an event. I also realized the TestHelper class only included a simpleMatch method that included only one team. So I took the method and modified it slightly to add an additional team. It would throw an error when I tried to use the same project for both teams. So I created two separate projects to go along with the two teams to avoid the problem .

Final Thoughts

I don't know if it was a good or bad thing for my task. On the one hand, I was able to finish my task and did have to implement additional things that other events didn't require, such as the additional test method. However, my task was similar to the example so I don't really have experience retrieving data outside of coverage. I have noticed in my inbox, some of the discussion questions. I haven't been able to really answer most of them.

Hopefully that knowledge others are gaining will eventually be passed on to me. It feels like there's still so much to learn. I would definitely keep the screencasts. I have a very short memory sometimes and it's nice to know I can walkthrough the lecture and examples again.

Sensor this, Sensor that

Hackystat Data Retrieval

Wow, so this past week, we've finally gotten to see what it is generally like retrieving data from Hackystat's DailyProjectData records. This is to prepare us for the Devcathlon, which is based on Hackystat data. This was not terribly bad (thanks to the screencasts, see below). I just need some more time with the system. I guess these things will come more natural when I do this more and more.

There were a couple of new classes and libraries that were introduced. We mainly worked with the SensorDataClient where it processes the request and retrieves it.

I originally had problems because when I retrieved my sensor data instances. It did not match what I saw in my project browser, momentarily. I was not sure what caused the discrepency. I even looked into the ProjectSummary class to further look into what caused the discrepency by printing the tool and owner of each event. But it eventually went back to normal.

Otherwise, everything went smoothly.

Screencasts

A lot of information was introduced. As I mentioned earlier, this wasn't as difficult as it could have been because of screencasting. Professor Johnson had just began something new with our class this past week. He would record his screen (a.k.a. screencasting) and do basic exercises relating to Hackystat with us. When the lecture was over, he was kind enough to upload it (as .mov files) to the Hackystat project page.

I think the screencasts are pretty cool to watch. The camera zooms in enough so the viewers can tell make out everything. We have a good shot of the exact activity that is taking place. I typically enjoy learning by watching so I hope the screencasts continues. I don't have any particular concerns right now, since I can probably find my answer in the JavaDocs too.

The screencast are (most importantly) useful. There are times where I feel like, "Oh, I forgot something he shown us in class." Also, if someone is sick, they can easily catch up on what was shown in class. Overall, I think this is pretty cool. More teachers should do things as such. Then again, it'll be hard to motivate attendance otherwise.


Download Link: [LINK]

Devcathlon Proposal

After completing my reviews in my previous three posts, I think I see a lot of things I like from all mockups. I think if I had to choose, I would use mockup4 as the basis. Then inject a little bit of everything from the other mockups. Some memorable ideas and I remember are...

1. Create a Match

a. Data Facilitation Sliders, Calendar Wickets, Drop-down Boxes, and Text-Boxes

I definitely think one of the other groups had a great idea for the "Create a Match" page. It was John Ancheta's vision where he used Sliders to help set the scoring values of each event. Also on his page was the option to use preset scoring settings such as Beginner, Normal, and Advanced.
They could use the presets as templates and then use the sliders to customize any category they choose. Automatically the preset status would switch to "Custom".

I think this is definitely a useful thing that many would use instead of setting everything themselves. I personally wouldn't care to set all those scoring values myself, especially my first time. It'd be great to use the preset ones by the developers.

When I'm filling out a form, I prefer to click on things rather than typing if possible. So a calendar wicket would be nice for the user to input start and end dates. Drop down boxes help show the options for settings that need to be within a certain range. Otherwise, text boxes for everything else.

b. Match Commissioner

This is really a spin-off to Mockup6's GameMaster idea. But each match should designate one participant to be the Match Comissioner. The match comissioner would be the one who has control of the settings to their individual match. When editing match settings, basically he/she will have a screen similar to that of a "Create A Match" PLUS an additional section where he/she
can reward or rescind point events.

I think this is good because it helps reduce the responsbility of the GameMaster. Otherwise, the GameMaster will have hundreds of matches to manage, and when will he find time to do anything else? Let people worry about their own matches and the GameMaster can override other things and individual matches if he so chooses.

2. Compare Badges

This is a must if we're going with the badges idea. It's always fun to see where one stands next to someone you admire and think highly of. It's also fun to see how far you've come compared to that person. Hopefully people will use this as additional motivation to collect all the badges.

3. Expand/Collapse

Anthony's expand/collapse using the SpryCollapseablePanel is nice. We have two versions of collapsing on our pages and this definitely needs to changed to have only one. Otherwise our page looks like it was created by more than one team different teams (which it is but we don't want it to appear so).

4. Team Cards

My group talked about this if we decide to go with team badges. There was a whole problem of preventing freeloaders from getting the badges onto their developer's card. Our solution was to let those teams have their own card. Any team badge would be awarded to the team and not help your individual status. Teams could also level up, but we haven't exactly talked about a level system for teams. Maybe something low would be "School of Fish". Something high would be "Software Giants".

5. My Profile additions

a. Add a Friend

The feature has already been shown. Users clearly can associate themselves with friends. We just have to implement a way similar to how social networks handle these operations.

b. Trophy Wall

Maybe someone doesn't have the time to attempt collecting trophies but still helps contribute to a lot of the team's scoring total. This is an additional way of showing off past victories. Just like one would have in their child's bedroom to look at their trophies, each user would have a section on their page with a shelf-like table of trophies [see below for example of Yahoo's Fantasy Profile Card]. Sorry people, nothing lower than third place here. We don't want to award mediocrity.

It doesn't add toward your profile points but its still recognition. Clicking on the trophy would bring you to the details of the finished event.


6. Friends Leaderboard

In addition to the hall of fame, users might want to see how they simply compare to their list of friends. A simple table with each person's profile points and recent achievements would be nice.


Layout wise, I think we're pretty set. White and a chrome-like blue is a nice way to work around. There are some aesthetics that we could improve on such as the look and feel of the developer's card, but the overall concept is what was important. I think we have a pretty good foundation.

Review of Mockup4

The final review of the Devcathlon is my group, Mockup6.

How many "clicks" does it take to get to the center of what you're looking for?

I think our group tried to present so much information on one page. So the price we had to pay was that it requires users to click a lot of things to show everything. Of course, this can be solved with an "expand all" type link. Once users get used where things are, then the selective collapse and expand concept will be useful.

This design can be good and bad. We need to be careful on where and when to use this. Anthony took the time to understand how to get expanding and collapsing to work with AJAX and JavaScript. However, we didn't have time to see the final product and discuss it's effectiveness. In the end, it was cool but there was concerns if the use is suited for its purpose in class.

I think we used it best in our "Team" page. It fulfilled multiple purposes. First it presents all members in a simple list. But what if I wanted to look at who the strongest member is? Instead of navigating through each member's page, we can now expand their card by clicking the member's name and comparing two or more at a time.

Forms

We didn't get the chance to redo a lot of the forms. So we have the same problems as I've mentioned in my previous mockup reviews. The forms need to be reconstructed in a way where it doesn't seem overwhelming but still cover a lot of aspects. White space helps this.

Also as mentioned before in the other review, we could use some extra components like a calendar widget to help facilitate input. I saw some really interesting ideas in another mockup and think we can use a combination of everything in my proposal for Devcathlon.

Layout and Organization

I must admit, things varied on a page by page basis. We have two different expanding and collapsing features. One that actually shows the animation of collapsing (using SpryCollapseablePanels), while the other is an instantaneous collapse and expand. I credit both of my teammates for exploring these options. If we all finsihed the same time, we probably would have went with the SpryCollapseablePanel to maintain consistency.

But everyone's pages still maintained a nice level of readability. Anthony's team page used well placed white spaces in the expanding cells. Nicely centered with good padding all around. It really made it readable despite all the information it held.

Strengths:

1. Expand/Collapse --- This is definitely something useful that will help. This helps reduce the amount of information shown unless requested for by the user.

2. Badges/Achievement --- I like our achievement page mainly because I think unattained badges are shown in a nullified way. It is grayed out.

Weaknesses:

1. Inconsistent Tools --- We should have used the same collapse/expand throughout all our pages.

2. My Profile --- Too much content horizontally. Needs to be redesigned to neatly arrange the Inbox and Actions menu.

3. Redundancy --- Inbox and Actions appears on both the home page and the profile page. Although not a major issue, it's probably better to commit to only one place so users don't get confused. Initially we were going to take out the home page. But we forgot to relink the logged in page and remove the home page.

Review of Mockup6

Continuing from the previous post, I turn my attention to Mockup6.

Mockup6's also signs into the same home page. There wasn't much difference from the original. So basically their ways of performing actions is the same as that of Mockup5. All actions can be found on that one home page.

Navigation

A lot of the pages are easily reached within 2-3 clicks, especially with the menu bar at the top.
The way to get to the ranks & level explanation page was nicely incorporated into the developer's card. Instead of simply stating the level, the group Mockup6 used a miniaturized thumbnail/icon of the level and abbreviation. I think this is great idea.

First, pictures are more interesting than text. Experienced users would be able to tell immediately what the rank is. New and inexperienced users will likely wonder what the level system is. I can't say this for everyone, but the first place I would try to click is the rank itself.

I do have an recommendation though. If the rank and level mean the same thing, then perhaps the label should be omitted. Perhaps a tooltip (text balloon that displays when mouse hovers) would make sense here.

Layout and Organization

It seems everyone has a good grasp of properly using white space, because almost everything in this group looked evenly spread out. I didn't have to strain my eye looking for content between bodies of text.

There is one page that has weird spacing. I am not sure whether it was intentional or if its my browser that's displaying it improperly, but the gamemaster page has weird formatting. The form could use an additional space after each section. It would serve as an extremely quick, small area for your eyes to take a breath before continuing on.



Overall Feel

The layouts on each page all feel the same. They look consistent from page to page, with similar table designs and color scheme. One page does stand out and that's the achievement page. I like the achievements page. The alternating shades for each row typically helps viewers to easily trace a row's details. I thought it was something to interesting to see. Personally I think the achievement table doesn't need it since there isn't a lot of text in the description column. There is only about one line each. Plus the badge icons helps create more padding between each row.

But the idea is something that I would definitely keep in the back of our minds. In one of my later blogs about Devcathlon recommendations, I plan on incorporating the alternating row shades in a boxscore that contains only text and barely any spacing between rows.

Strengths:

1. Levels & Rank --- The ranks & levels page was nicely incorporated into the developer's card. Also instead of simply providing the text, the users provided a miniature thumbnail of the rank. To me it says a lot more than just putting the text. Those who know the system won't have to look it up. Those who are unfamiliar will click and learn.

2. GameMaster --- In class, we mentioned that there will almost definitely need an overseer of all matches and override controls. But in my previous two groups, we have been totally focused on a typical registered user's view that we forgot all about this. It's good to see a group thought of it. They have some good ideas on the gamemaster page as well such as the adding of badges and the changing of preset match definitions (such as beginner's, normal, advanced).

3. Slider bars --- Although not functional, but I think the concept is good. It gives users a visual idea of how difficult they are setting things by seeing the scale. This also helps facilitate input.

Weaknesses:

1. Integration --- There are negative to tight integration. Because it will be part of one big project browser, we would be forced to use HackyStat's layout and appearance as discussed in class.

2. Level Up System --- Don't get me wrong. I think the rank system they came up with is logical and interesting. But the level up system has some minor flaws. Because badges have different point values, it would be sort of cheat to level up for those humorous badges. For example, I could have 5 slacker type badges and level up. But someone with 2 true badges like 100% coverage and commiting regularly doesn't. Is that really fair?

3. Lack of true programming badges --- It's nice to have humor, but the true purpose of the badges is to award good programming practices.

Review of Mockup5

Well after 2 weeks of mockups for Devcathlon, its time to look at what we got. The benefit of having three different versions is we can take what we like from each and fuse it into one.

To not forget any one page, I'll think I'll just quickly put my thoughts about some of the pages I come across and then summarize the site's overall issues toward the end.

The Home Page: (Command Central)

The user interface is similar to what there was in the first round of mockups. The first page you see when you login is the home page. The home page consist of a lot of the links to perform the basic actions as well as new events that prompt your attention. Actions include:

• My Profile
• Create a Match
• Accept/Decline Match
• My/Others' Pending Requests

I think this idea isn't a bad one depending on the official layout of "My Profile" page. Because the home page is the first page you'll see each time you login, users would more likely remember some of the content on the home page (assuming it won't be congested with text and other content). At the cost of one additional click to the home page, all major actions (CREATE, ACCEPT/DENY, etc) can be found in one "stored-in-the-back-of-your-mind" page. The page is simple and somewhat empty, which is good because we don't want anything to take attention away from new activities. It forces you to be aware of new events.

I mentioned that this would be good depending on the "My Profile" page layout. If the My Profile page is cleanly presented and doesn't have too much content to divert your attention away, then the home page can be done away with. Basically, if the content can be presented in a way where it doesn't get lost with everything else on a page, then it's a perfectly fine solution.

Filling out the Forms

The forms consist of mostly simple text-boxes and dropped down boxes which don't appear confusing. It's practically impossible to screw up the dropped-down boxes to become invalid field parameters. So I can understand why there are no explicit explanations on the page. The text boxes are slight concern I suppose. But almost all the text boxes are fields such as descriptions, which are completely variable for each object.

The only text box that may cause an error is the "Team(s) to invite" box, if a specified team does not exist. But frankly, users experience similar procedures when registering their HackyStat projects, or even when sending emails. If a team does not exist, then I assume the page will just return an error message specifying the problem.

There is one unique field so far, and that is the "File Path" for the self-report photo proof. I like the way it is now. Users are only allowed to specify the file by using the Web Browser's file dialog box thing-a-ma-jig, so no problems should arise. I would hate to allow users to manually type in the file path and getting an error. Is it "\" or is it "/"? Or is it ":" for Macs? Let the web browser (or OS) figure it out.

Achievements

This group was definitely creative with coming up with good programming related achievements. The use of cat icons was funny but I think adding in different themed icons would help spice things up even more. I didn't quite get the relation between some of them.

Overall Screen Spacing (White Space and content)

The current layout of most pages is good. The use of white space in between most items are well used so contents are easily readable. The only form I think could use a little more white space is the "Edit Profile" page. The type of information collected is fun and interesting. But it seemed packed tightly together one after another. White space will give users a little breathing room with their eyes.

The page is also the longest of all pages, requiring users to scroll down. Personally, I don't like my forms to be too long. I prefer forms that breaks up into smaller parts with intermediate save points. I hate having to refill input values, especially on long pages, if something went wrong. I think MySpace has a pretty good concept where profile information is broken up into tabbed categories.


Organization

Most of the pages follow the same consistent layout. They all follow a 3-color scheme: white, light blue and moderate dark blue color. When there are pictures, they are the same uniform size (with the exception of the "achievement" page) aligned neatly in what I assume is a table.

I think the achievement page feels a little different. The varying widths of the images makes the page looks unbalanced. The black stands out a little too much. It feels like the rest of the page subtlely ties together and then BAM! Black! Like an octopus squirted ink on the screen.

Strengths

1. Compare Achievements -- Cool concept which brings out the individual competitive side. I think it could use a row that shows the total achievement points at the bottom/top to compare.

2. My Matches -- I definitely like the simplicity of the My Matches page. I think too much detail on that page makes it hard to manuever through. If the user wanted details, then he/she could easily go to that page.

3. Match Details -- The Match Details page has the feel of an official sport box score. The competitors main scoreboard is at the top. Play-by-play at the bottom. The only thing missing is a box score where it shows who contributed to what.

Weaknesses

1. My Profile --- The layout has changed, where the tables are no longer in-line but instead on a new line per table. This is most likely accidental though and can be corrected.

2. Achievement Layout --- The usage of black on that page stands out too much. Different sized images makes it look uneven.

3. File a Self-Report Even --- This is really my initial problem from mockup2, but it hasn't been addressed. I think this action would be common and might as well be on the Home Page instead of the Team Page. In the form, the user can select which match he wants to request that point award with a drop down box.

Badges, Badges, Badges

This week, we were assigned into new groups to continue building mockups of Devcathlon (the Hackystat game). My group consisted of Robin Raqueno and Anthony Du. I thought we did well as a group. We didn't start early but we still kept a reasonable schedule considering it was Super Bowl weekend and everyone just wanted to spend time with their families and friends.

So the focus for this mockup was to (1) create three new award events, (2) create three new badges, and (3) come up with a level system when a user accumulates so many badges.

As a group, we were able to quickly reflect on our bad habits and use that to our advantage. We all sort of just went "oh yea!" or "that's right." So between the three of us, we came up with the following:

1. New Events
• Falling Coverage Trend (DEDUCT) -- Often times we found ourselves writing code without test cases. We normally just bring our coverage back at the end. If the falling trend continues over n days, we felt a deduction is warranted here.
• Team Communication (AWARD/DEDUCT) -- Communication is key. Although hard to keep track, perhaps all involved users need to file once a week "Self-Report Event" with topics discussed. If no type of reports has been on file for 7-14 days, then it definitely indicates that no communication has been established. DEDUCT for no communication, AWARD for consistent. Awarded on a 1 or 2 week basis
2. New Badges
   
• First Time for Everything -- If the user successfully wins a match, this badge is acquired. It's encouraging to have a simple badge to start off your profile. (unless you're constantly stuck on bad teams) . That is why this badge is worth less points towards leveling up.
  
• Master of Building -- Successfully committed 25 consecutive times without breaking the build. How many times have we heard stories or experienced first hand where someone forgets to verify and the build is broken? We thought 25 times was a hard number to reach and if someone can reach that number, then he/she probably already developed a good habit of verifying before commit.
  
• Most Valuable Player -- The high scorer in a match regardless of win or lose. This is a tricky one. Because if the other opponents are crappy, then this badge can be easily attained. We can possibly have further restrictions, such as MVP of match where the "match point total" exceeded n points.
3. Levels system
• Human Evolution -- This just came up as a silly comment and we decided to roll with the idea. The evolving from chimp to man is an indication of intelligence. Just as we begin as crappy programmers to more experienced. No one wants to be called a chimp, so that should be extra motivation to gain badges and level up.

As a group, we came up with some pretty good ideas. I thought our team meetings were very productive. And that should be an additional rule to Team Meetings to get the points. I've been to meetings where it's just okay, "you do this, you do this." No in-depth discussion if my perception is the same as others. Is it better or worse?

Robin and Anthony both introduced different ways of expanding and collapsing content through AJAX and Javascript. I thought it was really cool and I think I definitely walked away with some new material. I definitely think we probably would have scored in the high 100's or even mid-200's. Good stuff, good stuff.

It's Not Fun to Mock Someone

In my previous post, I mentioned that we were going to be working on a game called Devcathlon, based on Hackystat sensor data. Well this past week, I got first taste of what the game is like.

Our task was to create a mockup of the site and walk through the typical activity a user would experience if the game were to be played today. I tried to apply my background in games to Devcathlon. I play fantasy basketball and I thought it would be clever to model it after it. It made sense since fantasy basketball (or any sport) basically compares statistics just like Devcathlon would. What came out of that was:

• A week-by-week scoreboard -- Shows who was in the lead, who has made progress, who has fallen, etc.
• Breakdown of events -- Who contributed to what categories.
• Community Approval of Self-Reported Events -- Let the participants as a whole approve/deny self-reports. Minimum of half of the remaining participants must approve.

Other noteworthy things that came out of our mockup included a drop down type menu bar (that Phillip found) and a developer's card with achievement or badges if you will. The achievements server as a marker for individual excellence. It's fun to collect and used as bragging rights.

As a participant in the game, I think we violated a lot of the events. I didn't start or commit early. DEDUCT POINTS. It felt like we waited towards the last minute. DEDUCT POINTS. The only real positive I felt was commiting often... but only within the last 72 hours. It's hard to apply events such as "Build OK" since we only worked on HTML pages. But overall, I felt we didn't deserve any score higher than a 50, which hopefully isn't high enough to win any match.

Unfortunately, all of us did not know the proper way to set up the project on Hackystat since this is unusual with no Hudson and actual build files to configure the sensors with. So I can't provide a valid screenshot of our projects health. But judging from the log messages, the bulk of our commits were on the weekend. DevTime seems to be the only working sensor and that mostly took place during the weekend too. DevTime could be misleading though since Phillip and myself used Dreamweaver a lot to help create the pages with tables, outside the reaches of Hackystat.


So how did we score? Again I would say 0-50. It could have been in the hundreds had we spaced things out properly. Would we have won that event? Score-wise, no.... I sure hope not. But did our pages turn out alright? I would say so. I know this may contradict the encouragement of good practices. But if the final product is somehow better regardless of method/practices, I think that should be a bonus. Afterall, we don't want to encourage crappy programs either.

Games.... not all fun and games?

When I first heard that our project, Devcathlon, this semester for Software Engineering was going to be a game, I was extremely excited. This is the reason I first went into ICS. I didn't anticipate any jaw-dropping graphics or excellent music to be involved. But I've played games lacking one or even both, and still be fun and enjoyable. Can Devcathlon succeed as one of those as well? Hopefully.

What is Devcathlon?

Thankfully not a marathon or decathlon, because Wii Fit classified myself as "overweight" so I don't think I would have the endurance to participate. But Devcathlon is a game whose goals are to promote good software development practices. Software developers face off individually/collaboratively and attempt to accumulate the most points for a set period. Players are awarded points for positive practices, and lose points for poor practices. A scoreboard will be available to see where each player/team stands.

Events have already been determined and the rationale is based on the rules we try to follow in our Software Engineering course. Examples are commiting early and maintaining high test coverage. A more complete list can be found in the Events Wiki of the project.

Qualities of a Good Game

After looking over the weekly readings provided by Professor Johnson, it seems opinions vary. But there are certain traits that are commonly mentioned. Challenges/Goals, Rewards, and Story/Character Development are some that I recall.

Challenges/Goals

Games that are too easy tend to be short or cannot hold someone's interest for an extensive period. Games that are too difficult can frustrate a player and also lose the player's interest. So a balance of the two is needed. There also has to be an objective for the game to end. If the goal doesn't seem worth it, people may not play the game.

Rewards

A game can be very boring or difficult if the story progressed and no apparent growth or upgrade occurs. Tasks will get harder and your character remains the same. That seems dull. Rewards in the form of powerups, weapons, or new techniques can help reduce the feel of repetition and same-ness.

My Personal Findings

Googling "What Makes a Good Game?" leads to a bunch of hits. Besides the ones already mentioned, most articles refer to graphics, gameplay, and sound. Lot of these seem hard to incorporate at the same level as those at the commercial level.

Replay Value

In an article titled "What Makes a Good Video Game?", replay value was mentioned also mentioned. I think this is debatable depending on the game. Some games with rich storylines don't have replay value but are still considered a good game. I think since our game Devcathlon lacks a strong (or any) storyline, we definitely should try to strive for good replay value.

Other articles with similar ideas discussed:
The Other Eighty Percent: What makes a video game good?

Open Issues (edited 1/19)

Initially I thought it would be cool to somehow incorporate the points toward a more interactive game. But after reading feedback in Professor Johnson's email, it seems to be a whole different thing and direction we want to go in. So here are some thoughts building on what Professor Johnson mentioned in his email...

• Developer's Card
• Building on someone's idea of "bragging rights", it would be cool if we implemented something similar to the Xbox Gamer Card concept. (see below for example)
  
• Determine a list of achievements that a good software developer would accomplish. When a user accomplishes a task, it will appear on a card for individual bragging rights.
• Generate HTML code so you can show off the card on any web site.
  
• Examples: "Committed 25 times without breaking the build.", "Coverage has reached a 100% (minimum 1000 lines) ."
  

• Incorporate Story/Character Development (edit)
  
• At some point, it would be cool to see this "game" be more than just points and texts.
• I originally had an idea of a boxing game and using team stats toward the boxer attributes.