Wednesday, May 13, 2009

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.