Prototype
Documentation on the state of the project (as of 10/22).
We are deploying our project as a Django application on Heroku at tiletothetop.herokuapp.com using PostgreSQL as our database management system. The app currently consists of a page that calls, through an AJAX request, a simple word fetching service. Our database contains a words table of 100 SAT words and definitions. Given n number of words to fetch, the word fetching service returns a list of n randomly selected words as a JSON object. These are rendered as a list of words and definitions, which, however, will not reflect the appearance or usage of the service in the final product. The service will eventually be used to initialize a game of randomly selected words and to check the user's answers for correctness. The service also serves as a good example of how the client and server will communicate in our project architecture.
We have settled on the technologies we plan to use and spent some time getting acquainted with them. Each member of the team has a development environment set up and is assigned a part of the technology stack that they will be an "expert" in, so we have a good idea of what our roles are. The loose coupling between our front end and back end subgroups allows each group to work fairly independently of each other (as long as we aren't altering any interfaces) when we cannot meet all at once.
As we've developed our preliminary documentation, we've made decisions on important features, UI functionalities, and user experience. Our use cases and UI mockups will good points to iterate upon as we go further into user flow specifics. As for the back end, we currently have a simple, but functional service, which is a good basis for what the rest of our services will look like. We have a good idea of what our priorities are as indicated in our features table and milestones schedule.
We will need to spend more time clarifying the user/game flow and design of the app on the front end. For our first milestone, much of the work is weighted toward developing the UI, so our team will need to partition the workload effectively and be flexible enough to take on roles as needed. We may also consider adding features throughout the development process, and if our architecture isn't prepared to accommodate certain features, these would be high-cost modifications that will probably not be implemented by the end of the quarter.
Meeting a good project metric, the total number of games played, will not be feasible within a limited development timeframe, especially since we don't have plans to work on user acquisition in particular. With an abundance of other word games across the web, this is a difficult problem that we probably will not address.