Devcathlon 1st Milestone: Mockups

Premise:
I'll be expressing my feelings for this first increment of Devcathlon and the status of the project. The difference between this entry and my past entries regarding Devcathlon is that this time we are really going full speed on this application. My colleagues and I only have a span of 6 weeks left to accomplish what would seem like a prototype for Devcathlon 1.0. Here, I will also list my workings on the profile management section and my experiences being a co-coordinator for this project.

Devcathlon Project Hierarchy:
Each section consists of 4 members, including a designated team leader.
User & Team Management - user profile and team management sections.
Matches & Scoreboard - team matches and scoreboard management sections.

TeamUT - User and Team Management:
Since Wednesday, I was assigned as project leader of the user profile and team management sections for our web application. The profile management section will be responsible for providing personal and account details of a user. This section contains the user's home page, when they first sign in, easy links to edit personal and profile information, upload an image (avatar) and ways to manage teams and view related matches.
Planning and accomplishments...
Since we were placed in groups of four, I decided to split my team in half and assign each to either the user or team management section. Scheller Sanchez and I were responsible for the user profile management section. While John Ly and Philip Lau were assigned to the team management portion. I devised a shared Google doc that serves as a task summary of all involving elements for our user and team management. Of course our tasks and issues will be managed through Google's issue tracker, but this gives a hard copy evidence of our work. It's also backed with version control and makes for a very beneficial asset to our team collaboration.
Here's a quick summary of each individual's tasks taken from Google's issue tracker:

Profile Management (../hackystat/devcathlon/ui/page/profile)
Anthony Du:
Profile menu (started) ~mockup completed in r399
Profile submenu links (done) ~ completed in r391
Profile submenus: manage and browse (started)
Scheller Sanchez:
Added wicket ids for profile menu page (started)
Profile submenu: commentary (accepted)

Team Management (../hackstat/devcathlon/ui/page/team)
Phillip Lau:
Initial Team Main menu (done)
Initial Team Browse page (done)
Populate Team Main (new)
Populate Team Browse (new)
John Ly:
Add mockup of manage team submenu (done)
add mockup of teams invitations submenu (done)
implement creating team form (accepted)
implement team invitation (accepted)

We met up twice within the first week, the first day and eventually once on Friday. We also met online on several occasions and had two official group chat sessions involving everyone. This proved to be quite beneficial for keeping team members in check, draw new ideas, express opinions, concerns and debug issues. Conducting these meetings weren't difficult and everyone was very willing to cooperate from the start. I gave my team members lots of flexibility, due to everyone's personal schedules in order to work on their parts. I also sent out frequent reminders of opened issues and chat sessions going on. This team from the start seemed to be very self-motivated and easy going. I had a great time contributing all I can to my team members, as well as reciprocating that relationship through this learning process.

ICU does not see me...
One of my team members notified me that Hackystat wasn't picking up on my data telemetry through sensorbase. This is quite unfortunate and I needed to attend to the matter quickly, except it seemed that Eclipse's Preference menu had gotten rid of the Hackystat Sensor. This totally got me confused. So I attempted to reinstall the plugin by copying the jar from the hackystat.sensor.eclipse folder to the eclipse/plugins directory, but nothing worked. Hopefully I'll resolve this before our next increment. As of right now, I'm coding anonymously for Devcathlon...

Loose design process...
I know that we've all been here before with designing a mockup for a website on a text editor, or paper and pencil. This process should indeed be very quick and fast with all sketches being simple and straight to the point. What I've noticed so far in this project is that we've been stressing too much about the placement of things, rather than the functional aspects of our web application. Of course a web application's looks are 90% of the user's experience, but we haven't had a decent amount of time spent on the class design itself. I might be a bit harsh, since this is our "first milestone," but some people are really missing the point on what needs to get done. Generally stated, sometimes "less is more." So I think in our first increment, we should follow a semi-"loose" design in our mockups. Since a lot of these form elements are dynamic and can be changed ever so often, they need not to be overworked into our mockups. For example, a simple div tag can serve as a placeholder for an image or any other element. As for those elements that contain multiples, they can be done once and left alone. We don't need to exercise the fact that we can copy and paste with our mouse, instead seeing that one row is working is quite sufficient enough.

Concerns...
Wicket is still fairly new to most people and I don't know how much REAL experience anyone has had with it yet, but it shows very much in this application that we really need to start reading up on the basics of building a Wicket application. I'm pretty sure that we can code in Java, but can we code in Wicket? Wicket has only received 3 books published and they all have great introductions. I would recommend "Wicket In Action" as a great resource to building and deploying Wicket applications. The first and foremost understanding of Wicket's framework would be highly beneficial. We must understand the MVC structure and how Wicket distinguishes itself from other frameworks through separation of views and code. This separation greatly helps us focus on our programming without having to deal with heavy html markup. I would like to see that we plan out a class design of what needs to be implemented without Wicket first. For example, the UserProfile.java and not the UserProfilePage.java/html. Next we can focus on attaching these abstractions to our page components.

Conclusion:
In this first increment, we were mostly concerned about the markup html of Devcathlon. I hope this experience has given us all sufficient time in experimenting with the possibilities of using CSS in html and incorporating simple label elements through Wicket. There will be more interesting things to come when our team starts to dive into the workings of Devcathlon. Hopefully all of our previous preparations will help this applicaion flourish into success.