In good fashion, before registration starts, I delievered YACS 1.0. And as the author of a version 1.0 product, it suffers the same product-embarrassment. Ironically, that's a good thing. A couple features I could name off the top of my head as good milestones for version 2.0:

• Time filtering - To exclude schedules that have sections in specific times (e.g. "I don't want morning classes")
• Improved Scheduling View - Viewing schedules one at a time is definitely not optimal.

Those would be the two primary features for 2.0, everything else would be secondary. Also, I intend to create screencasts (or a series of written tutorials) about how I designed, developed, and created YACS. It would cover a variety of topics around programming that aren't normally covered in classes: version control, development tools and environments, deploying, design, usability, and programming tricks. It will provide a great insight to how and why code was written. 

It's a bright future. I'll see you at version 2.0

Yesterday (Friday, Oct 21st), I presented and talked about my project for the first time. Here's the slides, but it probably won't be as useful without the video.

I felt the presentation could be improved a lot (e.g. don't use an apple remote and practice even more), but the reception great, but there's still a lot left to do!

Not much to say, but designing takes awhile. I'm using 320-and-up for responsive design, which requires many designs for the same page. Here's some screenshot to illustrate it.

That's just one page, and that's only 3 of 8 stylesheets. I'll probably have to restrict it to only three stylesheets if I am to complete version 1 before course registration (Nov 7th).

Similarly, here's the schedule listing:

I wasted too much time doing premature optimizations. The computation of schedules takes a small, but noticable amount of time. So I thought I would cache the schedules in the database. But there are two problems after developing initial prototypes:

• There is no good method of storing schedules as normalized data (since they need to store the list of sections and courses they use.
• Large number of insertions into the database is slow.

So after wasting a week of time on this optimization feature, which turned out to be slower than the original naive implementation, I reverted back to the schedule generation on the fly. I'm punting the generating until it becomes a problem. I need to focus on the design.

I have some sketches made of some ideas about the UI. But to scope it down, I need to focus entirely on the web UI. But I've attached them here for reference. I've been working on the design and have developed a new colorscheme I'm much more comfortable with.

All the mockups were done on the ipad.

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.