Posterous theme by Cory Watilo

YACS

Commentary about the creation of a usable online course scheduler.

Minimum Core

Status update!

As of now, the core feature-set is functional which includes:

  • All the database schemas to store the course data.
  • Reading & parsing the SIS xml feed into the database.
  • Creating all possible schedules from a given set of courses.

Now the UIs need to be work upon. But there is an API available (thank's to the easy-to-use django-piston). The current documentation is here, until it's finalized to some point and to transfer it to the wiki.

And since there isn't any user interface yet, there's no screenshots. I'm currently evaluating various frameworks and techniques: ranging from complete JS-based frameworks to progressive enhancement techniques.

Another current issue is web hosting. I still need some location to run the server from, but the requirement of needing a constant background job to raises the cost from traditional variants.

If you like to see a more realtime view of progress and ideas, check out the Trello board.

And So It Begins...

This semester, I'm taking RCOS when involves creating or improving an open source project for the benefit of society. But part of the requirement of RCOS is to post, at least, a weekly blog post so that the professor can keep up-to-date with the latest happenings of the project. 

The Project

The project I'm working on is a generic, web-based course scheduler. Yes, I'm familiar with web development, but it would be good introduction to creating mobile user interfaces, which I have not extensively done since the iPhone was released upon the world - thus, changing the mobile web space forever.

Existing Solutions

Back on topic, my school is in a transitionary period. The widely popular java desktop application, RPI Scheduler, is currently not working at the time of this writing because of RPI's switch from a text-only course output to an XML variant.

This change was implemented to support the new ROCS scheduler. ROCS is a fork of the former, RPI Scheduler, and converted to be a web application. This is more tightly integrated with RPI's other systems, most notable is SIS, or Banner. Right now, the only difference, besides being web-based, between ROCS and the project it forks is the ability to display the number of seats left for a particular section (as part of the new XML course data).

ROCS is designed to support a set of goals motivated by RPI's DotCIO.

  • To integrate with a Java-based portal system (conforming to JSR-168 specification).
  • To have tighter integration with SIS system, including registering courses through the course scheduler interface (sounds sweet to me).
  • To place the code under an open source foundation to accept contributions by other universities.

While nice goals, there is little concern to the users of the software.

 

Besides the less than great design (which is known a problem), it has many goals motivated by DotCIO. Yes, call be a selfish ignorant lazy bum, but Java web dev isn't my cup of tea. And it isn't for many.

Although the possibility of helping a bunch of schools with scheduler is very inticing.

The Alternative

My project would be a python / django based web app for course scheduling. Because of my familiarity of Django, this removes the hurdles of learning a web framework and UI framework while attempting to learn about designing good user interfaces and creating mobile versions.

Because of the poor design of ROCS, many students have avoided using it in preference of the older RPI Scheduler. Of the students that know about ROCS, many avoid it because of the interface alone.

Both RPI Scheduler and ROCS also are void of any sharing of schedulers created in them. Students commonly take screenshots of RPI Scheduler; crop the image; then finally upload it to facebook. A web scheduler should provide this feature for easily sharing schedules to friends. Also providing calendar feeds will make it a snap to add the courses to one's calendar.

The Future

But since this project wouldn't have quite the backing or reach as ROCS does, it would be best to work on ROCS. Hopefully, I could merge the user interface design and feedback back into ROCS. Ideally, this project is a rapid prototype, in user interfaces before possibly integrating it back to ROCS.

 

​