Devcathlon Code Reviews

Premise:

In this blog entry I'll be reviewing three code bases (including my own) for the mock up implementation of our game project, called Devcathlon. In the following reviews, I will pin-point the good and the bad of each code base and hopefully that will give certain insight into future designs for this project. Although not all issues will be addressed, I will certainly mention ones from my experiences in building these mock ups and my understanding of the game.

The Reviews:

I will try to section off each review with the following outline:

Functionality and Features:

• Can the user login?
• Does the user have the ability to create or edit form elements, such as personal, team or team member information?
• Is there a way to create event matches between two or more teams?
• Is it possible to make record of or reputable proof of pair programming?
• Are the points properly assessed and clear?

Aesthetics:

• Did they embed useful technologies, such as Javascript, CSS or XML? (also including external widgets or libraries)
• Are the points nicely displayed and easy to the human eye?
• Does the user interface (UI) make effective use of screen real estate?
• Does the user interface provide a logical structure? Is the organization consistent from page to page, or do different pages have completely different layout.

Ease and seamless:

• Does the user interface enable the user to accomplish common Devcathlon tasks efficiently? How many "clicks" does it take to accomplish common tasks? Is the information you need to accomplish a task available on the screen?

• Do the data input mechanisms facilitate correct entry? For example, if a date is required, does the UI provide a calendar widget, or does it require the user to type the date in as text?

Overall summation:

• Does all the above information give the website cohesive enjoyment of a game? Also, does the website leave room for possibilities outside of its initial domain?

Mock up 4:

Mock up 4 was certainly a round up of many things experimental. It worked out like a sandbox for possible fun changes and re-works of existing features. I, along with two other members had a personal involvement in this implementation of Devcathlon's mock up 4. We based our implementation off of the unique design employed by one of our members' previous mock ups. This initial mock up had everything needed, including drop-down menus and an overall social network-like feel for design. In many aspects, the implementation in its "mock up" stages felt almost like a real world web 2.0 website.

Functionality and Features:

Mock up 4 has all the features expected for any website. It has a login and sign up page, home page for introductions, and help pages for hints and usages. It also strengthens its features by utilizing its fully expandable drop-down menus, making it easier to navigate through the site and finding its subsequent pages. Along with signing up for an account with the website, this mock up enables reusable forms for creating/editing a user's personal, team, project or match information. Upon logging into the site with proper authentication fields (login and password), the user is presented a welcome screen and their common functions, including links to the user's public/private profile, a team, match creation page, match invites, self-report requests, and site-wide announcements beneath it all. The public/private profile page provides an abundant set of information about a user and their involvements in teams, projects, and matches. This profile page is the center of every Devcathlon user's life. It provides information on the user's standing (system wide rank), recent achievements and matches, currently associated teams and ability to post/reply to comments underneath. To the right of all of that, the user is given email notifications in a personal inbox. This functionality of an inbox is still debatable amongst other designers, but it is a feature that has no bounds for possibilities. The only reason to include a personal inbox for Devcathlon is to provide convenience to the user, but hinders the fact that the information is repetitive and can sometimes be annoying if a person sees it both in their email and upon logging in. Also, beneath that is a list of the possible actions the user can take for interacting with Devcathlon (similar to the welcome page: create team, match, self report, etc.). The forms are in fact very reusable and encompasses the full gist of user interaction within Devcathlon. So it is important to get these forms to seem quick and convenient for the user. All the action links mentioned early will be representing in a form field-set fashion. For the team creation page, a user is able to search for existing teams, other members and projects. The parameters for the team creation page includes all relevant text to get the user started, including the team name, team type (appropriating members relations by organization, friends, etc.), team project definition, and an about section. Although this page needs more work in functionality, the intent is quite clear that we would want a dynamic page rendering both a search for existing teams, members and projects, and the ability to create a fresh new team on-the-fly. The match creation page also provides a comprehensive coverage of all required inputs for creating a match. It intelligently populates a drop-down of options including all your team and project involvements. There is a section to invite teams, but it doesn't follow the organizational structure of rendering a search for existing teams. In actuality it has a text area box for text input separating each team name with a semicolon. I feel that this is a bit ineffective and inconsistent with the team creation page which included the search. Other parameters for the match include the time period of the match (start and end dates), minimal score settings for commits, builds, and test coverage (which can be expanded for more customizable settings). Self-report request is another debatable matter that needs further nurturing for full acceptability in our game. However, in mock up 4, we dealt with this problem by asking the user to provide a brief description and picture for proof of the project being worked on. A neat product of this is that you can challenge other teams for self-reporting, as well as submit your own for pending assessments. This idea still needs valuable time to test in order to resolve issues involving point assignments and ethic values (the integrity of the feature to no be used to ones advantage through malicious means). The last action is for accepting or declining match offerings. This accept/decline match page provides a quick summary of the match for the team member who chooses to "accept" or "decline." Now, moving along the top navigation bar, a user is also able browse Devcathlon user profiles. This is another iteration of the technique in utilizing some kind of search for our persistent display of records. This will provide better "coverage" in linking our site together by means of relations and/or associations. Each page, including the gallery, match, team, or hall of fame features areas for knowledgeable information of awarded/deducted points of a team and its members.

Aesthetics:

Admittedly, this is the most acceptable looking Devcathlon mock up from our first initial mock ups. It is evidently so, since the mock ups here on after utilize this very same CSS and navigation bar. Initially, the first thing they will see is the site's initial home page (public view). This page provides information regarding the motivation of our site and link to forms for account authentication (log in) or sign up. At this stage, the public view is quite elementary and not very elaborate in design. The layout simply has a header, a logo area, navigation bar, main content, and footer for notes. The public view also limits the information and access to certain pages of the site.

When the user signs into the website, the first thing they will notice as they hover their mouse over the navigation bar is the very responsive drop-down menus and sub-menus. The chromed-like tabs have a significant depth as you hover over it, and makes for a fairly readable and fun user interaction. The font settings are also readable and it makes some use of titling, large or small text, and bullet-points. Links are also distinguishable by underlining the link text as you hover your mouse over it. The color scheme somewhat conforms to the Hackystat look with a few tid-bits here and there. Each page uses up the real estate fairly well, by populating information where it is needed or centering the content through divs. When you navigate over to the "My Team" page, you'll notice the compactness of all teams related to the logged in user. As you hover over a team, the element is highlighted, indicating some user interaction and implying a click-able object on the page. When the user clicks on the tab it expands out listing quick information about the team and team members. The magic behind this features lies in the classes written in Javascript by Adobe's Spry Framework. This JS includes the timed effects for the collapse and expansion of each tabbed panel. The motivation behind this is to increase user focus in interaction, save real estate, and to minimize users from scrolling up and down a page too excessively.

As you navigate further, following the clickable links you will notice again the usage of this collapse and expand feature for displaying multi-formed information that's nested per person, team, and match. You might think, what if the tab panels get to be too long and excessive themselves? Yes this could happen, thus we will propose a simple anchor system for referencing page content elements (like chapters in a book). This will enable users to jump back and forth between sections of a page.

On the match page, there is a nice fight-card line-up for players to easily compare teams in a match. The only flaw behind this is the possibility of having lots and lots of teams per match. Because of this, the real estate of our page will grow out of the scope of the content and will most likely make it harder for users to navigate or compare.

Also, the rows of each table have hover interactions indicated by color changes as the user passes over the top of it.

Ease and seamless:

The overall navigation is fairly self-explanatory. Links are easily distinguishable with underlines, borders, and color highlights as the mouse hovers over the text/object. The effectiveness of each page is quite seamless and comforting for any first-time user visiting the page. Information is linked wherever the sub-pages are needed and can be previewed using the collapse/expand feature of the tabbed panels. When the user commits to viewing a certain page (eg: team or match) then there is a separate page for it as well, thus giving the content of each page enough air to breath within its subject matter.

Overall summation:

I think it is safe to say that this, and all the other mock ups have intentional room for expansion. The difficulty in saying that is in the consequence of not knowing exactly which path to take for expansion. There are multiple routes to consider and they might not all lead to extraordinary UI's.

**Please note that a lot of the analysis in the first mock up will carry similar descriptions in both mock ups 5 and 6. Thus they will be shorter, and will only expresses dissimilar features from the first.

Mock up 5:

Functionality and Features:

When browsing over to the "My Matches" page under "My Profile" there is a clear list of all matches associated to the user. The listing also indicated which match is currently marked "active" or "complete." After clicking on a match for extended details, you'll also notice a nifty table showing all recent points. On the same page, if you click on "see details" then it will display a history of all points between each team in the match. It also gives a time stamp of each event and its corresponding points gained or deducted.
Aesthetics:

All lot of the CSS and page layouts were fairly similar to the previous mock up.

Ease and seamless:

The links were very clear and simple to follow.
Overall summation:

The history of points received for each match and team is a great feature and must be incorporated in a similar fashion for our future Devcathlon game.

Mock up 6:
Functionality and Features:

Mock up 6 employs a very strict set of levels for player achievements. The level definitions follow a military standard of badge ranks.

Another unique feature lies in the "My Matches" page. This page includes history listings with weekly reports of team accumulated points. This could prove to be a better way than simply listing a full history and time stamp of each consecutive event in one long table. We could break things up in the weeks and months depending on the elapse of the project and its total project life span.

Overall summation:

Mock up 6 also made an attempt to explore the possibilities of integrating Devcathlon with Hackystat. This idea seems great, yet it takes away the pure independence of this game. By placing Devcathlon as just a tab in Hackystat, then we are confined within the territories of Hackystat. On the flip side, the concept of using the data records of Hackystat should be supported for our application. I think that by reusing the account information supplied in Hackystat, we can possibly pre-populate the team and project definitions automatically for our Devcathlon players.

UI Suggestions:
Provided the three mock ups, I will make some recommendations regarding the design and function of Devcathlon. I will base my design off of my own Mock up 4. All of my previous comments will still apply. The only thing that still bothers me is the fact that pair programming is in all difficult to track due to consequent ethics of the game. To solve this issue of pair programming, I would like to implement a system of discussions per code event or issue. This will be recorded by our google discussion board (created for Devcathlon projects or teams) and assessed either amongst group members or members of another team. So by following good programming practices, every programmer is required to code on part of a particular issue or task. If the user confines to those guidelines as they are assigned to them by the team, then the user is considered "on task," otherwise "not on task" (for point deductions). Other than the issue raised about pair programming, the design patterns in Mock up 4 makes for a good starting point for our future implementations regarding UI's. One thing that lacked from Mock up 4 was a system for levels. We had an idea of using human evolution as a way to advance or mature a player, but it has hidden implications that might offend a few people. Because of this concern, I would consider Mock up 6's standard for leveling a player through military ranks. It sounds more formal, yet it gets to the point and seems to feel more natural. Another neat detail given in Mock up 6 is the way of sectioning timed events by months, weeks, and days. This way, we can store and retrieve our data records more easily in these timed archives. The idea is very similar to how Blogger organizes each blog post by month, year and/or by subject.

Conclusion:

I'm still tempted to say that the overall enjoyment of the game is still up in the air, since there are still little interactions between players and possibly gameplay. Plus, this observation is only from my perspective of creating these mock ups. Perhaps, getting into the game and actually experiencing the behavior of each functional feature will give better rise to the actual game as oppose to just pure speculation.

--

Resources:

Mock up code bases: http://code.google.com/p/hackystat-ui-devcathlon/

Monitor code changes: http://code.google.com/p/hackystat-ui-devcathlon/source/list