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.