You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Design

Implementation

The TeamTimer application consists of an html5 client written using jade, coffee-script and less that communicates with an API server written in python with flask that exposes a mongodb database. The modular separation of the client and server allowed us too quickly mock and test the front-end design with our test users before investing the time to developing the backend.

Models

Two models, Timer and User, represent all of the data in the application, and allow a users information to be persisted in mongodb. Having only two models greatly simplifies the implementation of the app. Each User can have many timers and each Timer can have many users. To prevent unwanted edits to a Timer, each timer has one special user, denoted as "owner", that is the only person who can edit it. One down side of this architecture is that it is difficult to capture relationships between Users, for simplicities sake we solved this problem by automatically populating a user's contacts. 

Authentication

When a user registers with an email and password, they are automatically accepted and logged in, the down side of this is that we don't verify the user's email. We use our own authentication service that stores passwords securely using bcrypt. The original idea was to use Google's GitKit to allow users to login using their gmail account, but this proved to difficult to implement. This would have made registration much simpler and would have removed the need to verify a user's email.

Front-End

The client uses responsive css media queries to dynamically restructure the document to account for different sized displays. We started with a multi column layout for the desktop experience, that stacks to a thin single column layout for the mobile site. The app is updated in realtime using web-sockets, or suitable fallbacks from the socket.io library, to allow a user to see new invitations and contact requests as they occur, with no page reload.  

Evaluation

Reflection

  • No labels