warrior-scheduler

View on GitHub

About Warrior Scheduler
Developer Guide
Application design
Development history

About Warrior Scheduler

Warrior Scheduler is a Meteor scheduling application that allows students and faculty to keep track of how busy the gym will be at any given time. A user will simply input the time they wish to go to the gym and it will appear on a calendar for everyone to see. Users will also be able to keep track of the amount of weights they use for each machine.

Home Page

User Guide

A working version of this app can be found here warrior-scheduler app

To log in you must use your UH login.

After logging in, the services will become available.

Use the calendar to add in gym events and workouts.

Fill out your personal information by clicking on the Personal tab.

Your contacts will appear on this page.

Initial User Study

This Application was tested by 5 different students/alumni of the University of Hawaii at Manoa: The testers were given access to the warrior-scheduler.meteorapp.com link and were told to provide feedback based on their experience

User 1 (Major: Public Health):

“Calendar works fine, didn’t see anything wrong with it, color coding would be nice. The personal pages don’t seem to work out, maybe make the height and weight optional.”

User 2 (Major: Bio, Pre-Med)

“Events seem to disappear when clicked on and this could be flustering for the user, maybe make an option to delete instead of deleting as soon as it’s clicked. As for the Personal Page, I don’t think the Height and Weight options are a good choice to have. Some people might not want to give that info away because it might be sensitive for them.”

User 3 (Major: Bio, Pre-Nursing)

“Making the app mobile friendly is a must. The webpage didn’t resize to my phone so I found it hard to use on mobile.”

User 4 (Major: Electrical Engineering)

“I liked the calendar, being able to see my planned workouts is a plus. The Personal page could be a bit better, but I can see the potential if more work is put into it.”

User 5 (Major: ICS)

“The calendar seemed pretty well done, I would have liked an option to delete rather than just cliking to delete. The personal page could be improved. An option to edit a contact once it’s up should be implemented, and a delete option.”

Developer Guide

First, install Meteor.

Second, download a copy of warrior-scheduler, or clone it using git.

Third, cd into the app/ directory and install libraries with:

$ meteor npm install
$ meteor npm install autoprefixer

Fourth, run the system with:

$ meteor --settings ../config/settings.development.json

If all goes well, the application will appear at http://localhost:3000. If you have an account on the UH test CAS server, you can login.

Application Design

Directory structure

The top-level directory structure contains:

app/        # holds the Meteor application sources
config/     # holds configuration files, such as settings.development.json
.gitignore  # don't commit IntelliJ project files, node_modules, and settings.production.json

This structure separates configuration files (such as the settings files) in the config/ directory from the actual Meteor application in the app/ directory.

The app/ directory has this top-level structure:

client/
  lib/           # holds Semantic UI files.
  head.html      # the <head>
  main.js        # import all the client-side html and js files. 

imports/
  api/           # Define collection processing code (client + server side)
    base/
    interest/
    profile/
  startup/       # Define code to run when system starts up (client-only, server-only)
    client/        
    server/        
  ui/
    components/  # templates that appear inside a page template.
    layouts/     # Layouts contain common elements to all pages (i.e. menubar and footer)
    pages/       # Pages are navigated to by FlowRouter routes.
    stylesheets/ # CSS customizations, if any.

node_modules/    # managed by Meteor

private/
  database/      # holds the JSON file used to initialize the database on startup.

public/          
  images/        # holds static images for landing page and predefined sample users.
  
server/
   main.js       # import all the server-side js files.

Import conventions

This system adheres to the Meteor 1.4 guideline of putting all application code in the imports/ directory, and using client/main.js and server/main.js to import the code appropriate for the client and server in an appropriate order.

This system accomplishes client and server-side importing in a different manner than most Meteor sample applications. In this system, every imports/ subdirectory containing any Javascript or HTML files has a top-level index.js file that is responsible for importing all files in its associated directory.

Then, client/main.js and server/main.js are responsible for importing all the directories containing code they need. For example, here is the contents of client/main.js:

put directory here

Apart from the last line that imports style.css directly, the other lines all invoke the index.js file in the specified directory.

We use this approach to make it more simple to understand what code is loaded and in what order, and to simplify debugging when some code or templates do not appear to be loaded. In our approach, there are only two places to look for top-level imports: the main.js files in client/ and server/, and the index.js files in import subdirectories.

Note that this two-level import structure ensures that all code and templates are loaded, but does not ensure that the symbols needed in a given file are accessible. So, for example, a symbol bound to a collection still needs to be imported into any file that references it.