Commit 14a68768 authored by Daniel W Bond's avatar Daniel W Bond
Browse files

finished the readme documentation! ... except of course the database setup

parent 9286755c
......@@ -64,27 +64,61 @@ up when you did the `syncdb` command.
### Models
*Courses*
Model fields are pretty well commented up, but here's a high-level view on how
everything comes together.
Each course has basic information (name, department, credits), but more
#### Courses
Each Course has basic information (name, department, credits), but more
importantly has prerequisites and corequisites. Prereqs and Coreqs can accept
null values or
null values or lists of other courses. This is how we know whether a student may
take a class.
#### CourseCollections
A CourseCollection is a section of required courses in a program. Usually,
programs require that a student must take some of these courses and some of
those. CourseCollections are a list of all possible courses and the number of
which are required, from all to just one.
#### Programs
A Program is list of CourseCollections, representing a major, minor, or general
education requirements. All majors take a gened course.
#### Students
Students have the standard user fields, their well as all of their planned
trajectories, and a big ol' list of all of the courses they have completed.
#### Trajectories
*CourseCollections*
Trajectories represent a student's paths to graduation, represented structurally
as a tree. A student's existing courses (or if null, their anticipated first
semester of classes) represents the root of the tree, and a student's potential
paths towards graduation with different majors representing different branches
out. Each subsequent trajectory represents a subsequent semester. This makes it
simple to represent students' changes to their trajectories and their different
pathways out to different major options. Each takes a trajectory
"previousCourses", which represents the node's immediate predecessor.
*Programs*
Already completed courses are kept in a bulk list with each student, and
potential courses are adjusted accordingly.
*Students*
What users save and see as "trajectories" on their home page are each discrete
path to each end node on the branches, e.g. Art History Path I, Art History Path
II. Modification is therefore as simple as addition of a few new pointers. Each
trajectory is also associated with a specific list of programs.
*Trajectories*
Trajectories also track their distance from the root, providing the user with
the number of semesters until graduation.
### Templates
#### index
This is where students can create a new trajectory. If students haven't yet
already selected the classes they've taken, they can select those classes
here
already selected the classes they've taken, they can select those classes here.
#### create
......@@ -137,23 +171,23 @@ might talk about some of the features and such.
#### Matters of Functionality
* how do you make coreqs work? right now it assumes that a coreq has to come
first, but that's obviously not how they work
* there are going to be some issues if you can name a trajectory, but each
semester is actually a trajectory...
* Display when the student is going to graduate, and accept the semester number
for trajectories
* coreqs are listed with each model already, but there must be javascript on the
page preventing students from selecting a course without selecting another in
order for that to mean anything
* Add support for APs, and fix the "login required" stuff
* Javascript to count the number of credits selected
#### Forms and Views
* some sort of javascript on the comparison page
* Forms on the index and create pages need to submit information
* JavaScript on the comparison page so that selected trajectories are loaded
immediately
* Analytic functions for comparing trajectories and some corresponding d3
visualization
* Forms on the index and create pages need to submit **actually** information
* Forms on index and create pages also need to expand to an additional fields;
also needs to take into consideration the max available, show alerts
* does the create page need to reload in between submissions? ajax or a new
page? **different page for now, that might actually be "better"**
* Create page requires AJAX, allowing for continual reloading until program(s)
are completed, then redirect to a student's main page.
* LDAP auth/login
* comparison page needs some lovely analytics on the compared trajectories for
the user
......@@ -181,8 +215,5 @@ on social and messaging sites.
getting professor information, CRNs, and what have you.
* An integrated "schedulizer"-type app for the classes that you've selected you
want for that semester.
* Make sure that the loginrequired works as initially intended, that you only
need to sign in in order to save or compare trajectories... this way prospective
students can put their potential trajectories together
## About GMU SRCT
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment