Crossing The Finish Line

After several months of effort, the first prototype for the Devcathlon system has been completed. I am actually rather proud at what I've been able to accomplish. I've learned quite a bit this semester about Java, Wicket, CSS and even non-programming lessons like conflict resolution! Probably the most important thing I learned was how to work well with others.

Future Improvements
Here are some ways Devcathlon can be improved in the future:

For the front page the matches panel and comments panel should either be paginated or use some other way to limit the amount that is displayed. The comment panel should at least display the user who made the comment. The event panel should display the name of the event. The dates in the event panel need to use a better display format. There are too many event scores with the explanation "No explanation for this score was provided". In the future these events needed to add explanations.

I don't understand why by default a user's e-mail is in brackets in the Profile page. For the Profile Browse page there's no hint that clicking on a person's picture will link to the person's profile page. Either have the picture change when a mouse hovers over it or place the link somewhere else.

In the main Match page when clicking on a "see details" link that is located past the first page of pagination on the Matches panel it will refresh the page and set the pagination back to the first page.

When creating a team there should be an option to pick and choose who's going be on a team rather than inviting everyone who's on a project. By doing this it will avoid a user accidentally accepting an invite to a team that he doesn't belong. Also when invites are created the person creating the team should be able to make a message that describes the purpose of the team invite.

When a match is created, the person creating the match should also be able to make a message that describes the purpose of the match invite. At the moment matches can be started when all team owners accept even if there are team members who still have to accept or decline invitations. This can cause scores to be skewed. Once team creation allows the ability to choose specific team members, as I suggested in the last paragraph, matches should not start until all members of each team have accepted team membership. As for whether or not a team member can be added or removed during a match, that is a grey area.

What Doesn't Work
The "Most Team Wins" and "Most Team Points" panels in the Hall of Fame page don't work at the moment. It's understandable for all developers in "Most Developer Points" to have 0 points since there aren't any User specific Events in the system. Those types of events should be created in the future.

Outside Feedback
In order to get a fresh pair of eyes, I asked my friend Vincent who is studying abroad in Japan to give me feedback on the system. He found to UI to be too bright. It might be a good idea to have custom UI styles for different users.
He said that the front page should have a statement stating the purpose of Devcathlon. He found the Events panel on the front page to be confusing with too much redundancy. He suggested that Events should have tooltips so that when a user hovers their cursor over them they get a short description. He also suggested that the "Most Team Wins", "Most Team Points", and "Most Popular Events" panels should be condensed to top 5. At the moment it displays all the teams and all the events in the system.
He noticed that "Records & Matches" panel in the User Profile page and the Team Profile Page needed links to their corresponding match detail pages. For the "Hall of Fame" page he suggest it will look better if all the panels were the same size and that each of them should contain only 10 items.

Top Five Lessons Learned from ICS 414

1. Communicate. With this project I realized how important it was to let everyone know what you're working on and to find out what others are working on. This doesn't stop when the meeting is over. While working on files that may affect other developer's work, it's prudent to give notice to that developer when doing so in order to prevent future conflicts.
   
2. Rise up to the occasion. When you see something that needs to be done you need to have the initiative to do it without anyone telling you to. I found myself throughout this project on multiple occasions having to take on additional work in order to make sure the project reached completion.
3. Patience. Sometimes I found it really difficult to wait for a developer to finish a component that I needed to rely on. Sometimes it was warranted and I had to take over and do it myself. Other times though the component was completed in a timely manner and I was worried over nothing.
4. Don't assume the worse. I'm going add a caveat to this one by saying that the individuals in the peer review who I don't want to work with in the future hasn't changed. For the other individuals though I would say that over time they have improved quite a bit.
5. Make use of each individual's skill set. Some people are good a Photoshop, others at CSS, and others at coding. The trick is to make sure that the amount of work they're given for their skill set is equivalent to others.

So It Begins...

This week was the start of real development on the Devcathlon system. We were divided up into 2 teams with my team being in charge of Matches and Scoreboard. We decided our goal for the milestone was the development some mockups. We had a meeting on Saturday where we divided up tasks. I was tasked with the Match main page and the Match's browse submenu since they were similar.

For both of those pages I created tables filled with some match info. I created Previous and Next links so that in the future a user can go through pages of matches. I implemented all the links and info in the tables in Wicket. This way I can have some idea of how I would implement additional features on the Wicket side.

Checkstyle complained about having whitespace after } when I was using for:
add(...) {
...
}.add(...);

so I made a change to it so it now looks like this:
add(...) {
...
}
.add(...);
It looks a bit more awkward and if a programmer in Eclipse used Source->Format it will revert back to the original format.

In the end I made 3 commits, added code to the org.hackystat.devcathlon.ui.page.matches.browse and org.hackystat.devcathlon.ui.page.matches packages. There must be something wrong with the sensor because even though I have spent time in Eclipse my current DevTime is N/A.

Going To The Bar

This week I had some practice working with Wicket and CSS. Specifically I was given an implementation of menu bars for Devcathlon and added improvements to it.

One of the first things I did was to add a menu along with 3 corresponding submenus. Then I implemented them into the Wicket code.





I made sure that the new menu corresponded to the body tag section-3 so that the bar will work correctly.



Then I created an additional 7 to showcase the limitations of the menu bar. At first I didn't notice anything wrong with the menu bar.



But if I reduced the browser size an issue popped up.



Clearly there was a problem in the CSS concerning browser resolution compatibility. Looking into menu.css I manage to narrow the problem down to either the subnav or content CSS code. After trying out using different positions and widths I managed to get a solution that worked.



Next in the test html files I changed h1 headers to h3 headers. This caused the submenus to misaligned. To fix this I went into the menu.css and changed the top value for the submenus from 84 px to 70 px.



The only problem that i couldn't solve was how to bold the menu item that corresponded to the currently displayed page. I couldn't figure out a Wicket solution but I did find this.

A file of the work I've done can be found here.

Up To The Minute

This week we started development on the next group of Devcathlon events. I was tasked with creating the Don't Wait Until The Last Minute event along with John Ly. For this event we had to penalize any team that did their work at the last minute.

To get the data at first we thought about using the ProjectDailyData but it turns out it would have have taken longer to process compared to just using ProjectSensorData. Another issue I encountered was how the makeBuildData, makeCommitData, makeDevTimeData worked with timestamps. It turns out that if they were all created with the same timestamp then only one of them would actually work. So we had to go in and make sure that each time we used them they would have a unique timestamp.

The event that we created will calculate the penalty for each day of the penalty duration but it won't calculate the cumulative penalty score. There was nothing in the event description that said we had to get the cumulative penalty score, just the day by day penalty.

There's still an issue of how penalties are calculated. For this event we used the BaseScoreWeight as a positive multiplier for the penalty since there was no way to gain points in this event.

On Your Mark

This week we began actually programming for the Devcathlon through Starter Events. The event that I worked on involved rewarding teams who build before they commit. They would be rewarded if they build locally before committing and penalized if they didn't. There are also bonus points that occur when a team is on a build-commit streak. More info on the events can be found here.

One of the problems I faced while programming was figuring out the scoring. Eventually I figured out that BaseScoreWeight was a multiplier for the score. But that lead to another problem with the scoring: deductions. Because of the use of the multiplier, point deductions was made much difficult. I would have gone into EventScore class and add the capability to hold deduction info. That way the points computation would be made much easier. Right now, probably the only way to get deductions to work correctly is convert them into fractional deductions, which is rather awkward. My event was later changed so that I wouldn't have to worry about deduction weight but I think this is still an issue that needs resolving.

Another problem that I had was making commit data for test cases. I made a makeCommitData method in DevcathlonTestHelper class to help me out.

Another challenge I faced was trying to figure out how the sensor data type worked. This page help me greatly but I'm still a little sketchy on some of it. Eventually I found that there were 2 different sensor data types, build and commit, that I had to make into separate indexes.

I had some difficulty with getting successful test cases. I found that it was mostly issues dealing with the timestamps of the build and commit data such as timestamps that were made that weren't in the time interval I was looking for or timestamps of builds that were after commits when they should be before.

The Devcathlon program can be found here.

Making Sense of Hackystat

Recently I started working with the Hackystat API. The goal was to learn how to retrieve sensor data from Hackystat and make use of that data. I spent some time watching a screencast for Hackystat which can be found here. One obstacle that I had was in figuring out how to retrieve data from a user. From watching the screencast I learned how to retrieve data from a specific project but not. By looking at the JavaDoc it didn't take me long to find the getSensorDataIndexLastMod method that fitted my need.

I also had to create another program to make use of sensor data by finding out the day of the month that had the most sensor data. To go through the days of the month at first I used a for loop but later I realized a while loop would be preferable because there were different number of days for each month.

I found the screencast to be very informative and helpful as I went along with my programming. I wouldn't mind having a mix of screencasting and supplemental notes.

The results of my work can be found here.

Devcathlon UI Recommendation

For my recommendation for the UI of Devcathlon I will use Mockup 5 as a base. If the Inbox is implemented I would add it to the home page. The Inbox will either be connected to an internal mail system or be linked to an offsite mail system.

For the My Profile I would use the layout of Mockup 4 but remove the sidebar with the Inbox and Actions. I would switch the My Teams table with the one in Mockup 5. I would also add the About Me box from Mockup 5. To be honest none of the leveling systems appeal to me. My idea for a leveling system is based on how much points a player earns through matches and events. I would like the rankings to be related to computer culture such as Hacker and Cyber Punk to match the theme of the Devcathlon. Information on how the system works can be found in the FAQ.

For the Achievement page I want to use the color scheme and layout from Mockup 6. I would prefer if the icons were bigger while the small version of those icons can be used on the gamer card.

For a details on a single match I want to use the page from Mockup 4 but I would add Recent Points and Recent Activities from Mockup 5 and 6.

Mockup 6 Review

Along with the other recent mockups, Mockup 6 doesn't change much from the design of Mockup 2. The registration page, password recovery page, and create team page should have been removed due to integration with Hackystat. Same goes with being able to change email and password.

The leveling system might be difficult for those with little knowledge of the military to understand. Also I seriously doubt it's possible to create 120 achievements that is needed to hit the highest levels. Like the other mockups, the information on how the leveling works should be found in the FAQ.

There should be a link to the Achievement page on the drop down menu. Some of the new achievements that they added are questionable. For example I don't think someone should be reward for being a slacker.

Like the other mockups, the team profile page still needs an example of what it will look like with more than 1 project.

The My Matches page allows some info at a glance on a match. Still the amount of information should be reduced assuming there will be a large number of matches. Also like the other mockups, there are 2 link to My Matches in the drop down menu.

One of their strong features is standardizing achievement icons and improving the color scheme for them. Having information at a glance for My Matches is useful but one has to be careful not to go overboard. Some weaker points include some questionable achievements. It will be difficult to figure out someone's level at a glance using their leveling system. Also the number of badges needed to level should definitely be brought down.

Mockup 5 Review

Mockup 5 doesn't change much from Mockup 2. The only real difference is some slight changes in layout and addition of pages. Also pages were removed due to the expected tight integration with Hackystat.

The My Profile needs to be better laid out. The tables are arranged awkwardly. There are tables that are misaligned and there is empty white space on the page where the tables could fill up. Information on the leveling system should be in the FAQ. It's slightly difficult to figure out that Level and Rank link to that information.

On the Achievement page the icons need to standardized. Right now they are different sizes and shapes making them difficult to use them for the gamer card. There also needs to be better achievement point distributions. Not all the achievements should have the same amount of points. The color scheme for achieved and unattained should probably use some work.

The team profile needs to show an example with more than 1 project. It's also a little awkward for the match details to be in both the team profile page and the match page. The details should probably be dropped from the team profile page leaving only a link to a match details page.

At the end of the My Matches page there is the text (see entire match list). That will probably be used to show/hide additional matches. Maybe if there are too much matches to be displayed a page system could be implemented that allows a user to browse through pages of matches. This can also be applied to other areas of the site that has too much info being listed. There are 2 redundant links to My Matches in the drop down menu.

One of the stronger feature of this build is the inclusion of personal info in the profile page. The My Matches page is nicely set up but there might be issues further down the road. The leveling system is easy to understand although there appears to be an number error between senior and graduate. One of the weaker parts of this mockup is the layout in the profile page. The location of match details need to be resolved. Also there needs to be more info for matches such as in mymatches3.html.

Mockup 4 Review

Like the other mockups in this review roundup, Mockup 4 doesn't stray too far from the design of Mockup 2. Due to the assumed tight integration with Hackystat, the registration page and password recovery page should have probably been removed. The same goes for the create team page since team data can be pulled from Hackystat. Being able to change email and password in the Edit My Profile page should be removed for the same reason.

On the My Profile page in the gamer card Chimp should have been the rank and the level should have been a number. There also needs to be more information on how the leveling works and a link to that information should be in the FAQ. In my opinion the only time that a Show/Hide scheme should be used is when data is cluttering up the page. For example rather than using Show/Hide for My Teams on the My Profile page it should have instead been used for My Comments. If a sidebar for Inbox and Action is used, it calls into question what will be on the Home Page since both of them share much of the same function. It probably should be either one or the other and not both. The My Teams table shows only 1 project even though a team can easily have more than 1.

A link to the Achievements page should be in the dropdown menu. I disagree with their approach of having uncompleted achievements be hidden. It would either drive a player insane trying to figure out how to complete them or diminish the role of achievements to such an extent that players will barely know they exist.

On the Team profile page I want to see how it would look if a team was working on more than 1 project. In such a situation a show/hide for the project description or a link to another page with the project description would be a good idea. There should be a link from a team member's name to his profile. They could also add some sort of banner to the team page.

On the My Matches page a link to the corresponding team page should be in there. The capability to show/hide the number of points each member earned for each event is a good idea. It prevents the stats from cluttering the page. There are 2 links to My Matches in the drop down menu. One of them should be removed.

The Gallery page is another place where either show/hide or a link to another page describing the match should be implemented. In the Hall of Fame a link should be made to the corresponding profile pages.

The strongest feature of this mockup is the implementation of show/hide. The Inbox is a interesting feature and the messages could be located on site or point to another location. The sidebar for it along with Actions might be useful. The weakest part of this mockup is redundant links. Another weakness are links that should exist but don't. Their achievement implementation also has issues.

Mockup: Take 2

In the second round of creating mockups we were tasked with expanding on ideas inspired from the previous mockup.

I added some additions to achievements such as comparisons, added some flavor text to the profile. In a way I think we would have done something differently if we started from scratch. Much of our work was based on the previous mockup.

In my opinion it's easier to make up an achievement than it is to make up an event. With events one has to consider how that event will help the development of the software. With achievements it's a bit more fun thinking up of interesting accomplishments that a person might want to achieve. This is probably a good reason why a player's level should be based on only one of these attributes and not both.

Here is a link to my group's mockup.

Marking Up A Mockup

For the Devcathlon project my group was tasked with creating a UI mockup consisting of HTML files. It's been a while since I've done anything advance with HTML so it took me some time to get off the ground. At first we decided to make some webpage designs and pick the one that we will use. Our final design became an amalgam of our design ideas. Some of our ideas included creating a gamer card that a player could use in places such as forums. Others included achievements which were unique goals that a player could attempt to reach. Most of our ideas had a Web 2.0 slant to them, giving the game a community aspect. We started off a little late on working on the actual mockup. We each gave ourselves specific tasks to work on. Most of our work was done on the last day.
One of my tasks was to create the achievements page. We had some ideas about how it was going to be implemented. We thought about having team achievements but we sidelined that in order to focus on individual achievements. We also thought about specific achievements for matches but for now we focused on global achievements.
I forgot to invite myself into the Hackystat project until after the all the work was done. This has happened on more than one occasion and now when I think about it, it would have been very helpful if there was an email reminder. It probably wouldn't have matter anyway since the Hackystat sensors were only for Eclipse and i spent my time working with Dreamweaver.
If this was a match, commit-related events would probably work for this project. Code-related events definitely wouldn't apply to this project. We probably wouldn't have won but who knows, the jury is still out. Point allocation in this and most other matches should be a mixture of team and individual efforts.

Developing Software By Playing Games

My project for this coming semester involves developing a game for software development. It is called Devcathlon and it is focused on using game mechanics to improve the health of a project and to motivate programmers.

Through my research on game design I found this informative lecture on game design by Will Wright. In it he incorporates ideas from the fields of psychology, biology, computer science, and physics into his idea of good game design. A game designer needs to understand the mind of a player, giving him many possibilities of success. A designer should avoid having an optimum path to success and instead allow players to use different, viable strategies to reach their goals. Playing a game is very much a learning process so a designer should use successes and failures to teach players how to play. Each learning tier should build up on the one before. In games where players have to interact with each other, players can find themselves grouping together in order to achieve goals that they couldn't accomplish individually. In these groups specialization usually occurs, with some individuals more skilled than others at certain tasks. A designer usually must find a balance between competition and cooperation. He must give the player reasons for cooperating and reasons for doing their best.