Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
I am the chief technical officer at InVision App, Inc - a prototyping and collaboration platform for designers, built by designers. I also rock out in JavaScript and ColdFusion 24x7.
Meanwhile on Twitter
Loading latest tweet...
Ben Nadel at Scotch On The Rocks (SOTR) 2011 (Edinburgh) with:

Exercise List: Initial Thoughts Before We Code

By Ben Nadel on

Before I start coding the Exercise List project, I need to get a clear idea what needs to be done. As I have stated before, the project is a hands-on learning experience to familiarize me with Object Oriented Programming in ColdFusion. But, at a more general level, it is an application that will maintain a list of fitness exercises. To help learn the basic principles of Object Oriented Programming, I am keeping this application purposefully simple; there will always be time to complicate it later.

The basic interfaces required for this application are:

  • Add / Edit Exercise
  • View Exercise
  • Search / List Exercise

The only data we will be keeping track of is the list of exercises. There will be no login or users. Here is what I am thinking for the exercise data:

  • Name
  • Description
  • Contraindications
  • Joint Actions
  • Alternate Names (also known as...)
  • Date Created
  • Date Updated

Exercise data could be kept in one table, but that wouldn't help me with OOP (object oriented programming) as much as it could. As such, I am breaking down each exercise as it relates to joints and the actions that need to be done on them. Each exercise can act on one or more joints (ex. Bicep curl acts on the elbow by flexing it). As part of this "joint relationship", the action can be:

  • Flexion, Extension, Rotation, Adduction, Abduction, Plantarflexion, Dorsiflexion (if applicable)
  • Performed in a particular plane of movement: frontal, sagittal, transverse (if applicable)

Not all joints can move in a particular plane or have all joint actions applied to them. There will be a relationship in the database that joins Joints to Joint Actions so that the wrong actions don't get associated with the wrong joints (same for planes of movement). The action performed is also related to the plane of movement (hip rotation in the transverse plane vs. hip extensions in the sagittal plane), but I am NOT going to build in the logic to maintain these constraints; I don't want things to get too complicated right off the bat.

So that's the data that needs to be captured and an overview of the way the data interrelates. As a reminder, I am going to be first building this application (hopefully fast) in my standard procedural style code just to get it done. Then, I am going to go back and do a data model analysis and move to an object oriented approach and hopefully, awesome learning will ensue.




Reader Comments

I am gonna make mockups of the interface first before I even worry about the database structure ala the likes of Clark Valberg and Hal Helms; I am going to be following an interface driven design where the prototype dictates the data model that will be required (and discovered).

The mockups will be posted shortly. I am not going to create a full fledged prototype since I think this is so few pages that the designs will suffice.

Reply to this Comment

Post A Comment

You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.