Ourstories+Prototype

**Prototype** by **Payam Azadi** (azadi@umd.edu), **Brandon Britto** (britto.brandon@gmail.com), **Dan Sonthichartkul** (dsonthic@umd.edu), **Kevin Heiting** (kheiting@terpmail.umd.edu)
 * OurStories**

(draft) prototype for OurStories. Functioning home page, ability to tell stories, ability to view stories (and be given random stories).

Prototype
At the end of our mock up phase, we were very satisfied with our final design, and wanted to stick closely to that specification. We then set out to build a functioning prototype, which would comprise OurStories' three basic features: navigation, viewing stories, and telling stories. Although it was originally unintended to have persistent data backed by a database, we took this route and now have a live database from which we load stories and to which we store stories.

The details of our implementation approach focuses around modularity and consistency. Each page is comprised simply of blocks, and each block is its own dynamic unit. In this way, we can swipe out headers or sidebars dynamically, and "widgetize" things. In future stages this will make our interface extremely flexible and inexpensive to maintain as we can try multiple layout variations and see which one works the best.

The bulk of this stage was in creating the database schema and in setting up a functioning CSS template. We set a standard that will comprise of a header, sidebar, and footer, and so we needed an architecture that will maintain these simple pieces across the board with flexible yet consistent positioning. On the database side, we created a basic draft architecture which would handle stories, flagging, and comments. This proved to be necessary and sufficient for purposes of this prototype. Other features implemented include ability to view a random story, or individual stories, via parameter passing to the script.

There remains a lot of work to be done, for instance tagging/categories, a dynamic homepage, algorithms/logic in displaying content to users, making the tell-a-story form more simple/usable and less daunting at first sight, registration, and user account/preferences management. All of this will depend on a much more well thought out database schema, as well as in coding structure, as many features are inherently similar or identical and code redundancy will become a major obstacle to rapid progress and easy maintenance.

For purposes of user-testing, we are more or less happy with the setup we currently have, although there remains some design in the story form and in the home page that remains to be implemented or tweaked.