Devcathlon site mockup

Overview:
This past week my group and I were tasked with mocking up the general features of our game, called Devcathlon. To learn more about Devcathlon, please read the blog post prior to this one or head on over to http://code.google.com/p/hackystat-ui-devcathlon/.

Planning:
Generally, I approached the mock up of Devcathlon like any other website. The parts that go into a website are apparent and can be easily modeled by notable ones like Google, Blogger, or Facebook. It seems to be a must, in today's standards of Web 2.0 to have Ajax functionality and dynamic webpage access and retrieval. Unfortunately, our mockup didn't express those characteristics physically, but the idea is still quite enforced. I thought of the application as more of a social website. So the basis of this application is very much that, it had to be socially adept and capable of growing. Users should be able to communicate with others in a personal or public matter depending on what the situation calls for. Designing the structure of the site wasn't very specific, but it had to be standardized. We simply broke the site into two parts, the public and private domains. The public section of our site is a simple "tour" for any outside user who is willing or just curious to explore our site without a direct account. Of course, for any alien who comes near our site, we restrict them access to certain elements or retract any links that only should be seen by registered users.

Site work flow:

* Public user enters site's home page. He or she is prompted for a login/password.
* User enters a valid login/password, then gets redirected to his or her's profile page.
* The logged in user is able to edit their profile as they please, add/remove/update teams and matches.
* Registered user could also search and associate with existing teams or matches.
* Every user is provided a personal and public profile.
* When a match is declared then it is marked as a user event and should message the user under their recent activities.
* When a user gets prompted by an administrator, then that information is displayed under notifications.

Besides dealing with site administrative tasks, such as creating a user account and modifying profile settings, we also focused on important questions dealing with how the game should work. One idea that I posed (as mentioned in my previous entry) is to possess every user/player the ability to create stories/tasks for themselves as the project/game progresses to a goal/objective. Creating these special “stories” is another way of saying a developer creates an issue on an issue tracking system (Google Project Hosting). Upon generating these stories, other players can either interact or discuss (Google’s issue discussion groups) about a particular subject and trade off ideas through post entries. This way players will interact with other players and thus resolve some obtainable “mini” goals. Mini goals can also be known as a milestones or phases in a project development (stages or levels in games) that give players awarded advances and points for their achievement. All of these aspects are simply ideas, but we have yet to encounter the facts of reality in creating such a world for them to exist in. Hopefully in our next increment of this project, we will dive into those concerns in more detail.

Conclusion:

Mocking an entire website from scratch is particularly difficult since website designers need to anticipate every move. Every form built was either doodled out or envisioned multiple times before getting it right. Most likely changes will be made after the mock up, so I wouldn’t be surprise that we would keep or discard certain elements from the current design. Unfortunately, the only regret I had during this process of mocking was the lack of “mock tools.” I wish we had more open source mock-supported development tools for web development. Maybe they won’t reach the same standards such as high competing tools from Adobe’s Creative Suite, but we need to start somewhere to ease the process.