Monday, May 28, 2012

htmlburger & 99designs

Hands for Science is a non-profit helping teachers do hands-on science activities more easily. I programmed the web site www.handsforscience.org, visual design was outsourced to 99designs.com, and web coding was outsourced to htmlburger.com.

As expected, 99designs.com was a cost-effective way to get several concepts. Many of the designers don't understand CSS so they suggest unrealizable designs such as a paginated float & colored auto-numbering. Don't expect one designer to excel at everything. The logo and page templates were done in separate contests. Be sure to point out that the logo must look pleasing in the global nav. One template is for the description of the hands-on science activity. Unfortunately, the designers did not seem to excel at printed page design.

It took some doing to adapt the htmlburger.com coding of the 99designs.com PSDs. The client needs to give htmlburger specific instructions or the code will be too specific to specific pages instead of being reusable style/html frags/templates. Insist that all directory, file, & style names be prefixed w/ hb- or the like. This makes it easy to distinguish their stuff. They improved my jquery slideshow. They even wrote JS to shrink a long caption's font-size.

On the marketing pages, I wrote custom tags (rails view helpers) which alternate sides for the graphics.

HandsForScience CMS Uses mongodb

HandsForScience is a non-profit which helps teachers do hands-on, science activities more easily. I'm using mongodb for the HandsForScience CMS: http://www.handsforscience.org/activities

The stack is rails 3, mongoid, cancan, & jquery hosted via Heroku, mongolab, S3 (for attachments).

Any CMS will have User, Article, Link, & Attachment classes--in our case, Activity takes the place of Article. Our schema adds:
  • Standard: A curriculum standard which the activity cross-references. So far we include the California K-5 standards.
  • Material: An activity includes materials. The list is crowdsourced.
  • Term: An activity includes vocabulary terms. The vocab is crowdsourced.
Instead of a Grade class, an activity's grades are an array-valued field. Instead of a Subject class, an activity's subject has a string-valued field validated as an enum: life, earth, physical sciences.

The most interesting tradeoff is the Activity/Material relationship. There must be enough material for each activity. The quantities are classroom, small group, student. Instead of creating a join class ActivityMaterialQty, there are three many-many relationships.

Another tradeoff is object creator fields are string-valued instead of many-many-User relationships. I should probably switch to BSON::ObjectId.

It would be nice if mongodb supported case-insensitive sorting. I'm working around this by sorting in memory. I should switch to denormalized, lowercase fields.