Thank you for showing an interest in Schedule Maker! Here, you'll find plenty of information about the creation and operation of this simple, though incredibly useful program.
Schedule Maker ideally operates in a web browser with full compliance to the W3C's specifications and recommendations for HTML 4.01, Cascading Style Sheets, Level 1, and the Document Object Model, Level 1, along with the ECMA-262, the ECMAScript Scripting Language (aka JavaScript, roughly). Such browsers include Mozilla and Microsoft Internet Explorer. Lacking either of these, or a similarly compliant browser, you may still be able to produce useful output with Schedule Maker, though it will not be optimal.
If you're looking for a bulleted list:
The precedence order of these recommendations is roughly the order listed. Schedule Maker's backend produces strict HTML 4.01, so a compliant browser will render it most correctly. Cascading Style Sheets (CSS1) are used to give your schedules liveliness and personality, though they are not strictly required for correct tabular output. If you lack CSS support, or are using a broken implementation (like Netscape 4), you may want to select the ``Simple output'' option. The Document Object Model (DOM1) and JavaScript simply make the form easier to fill in, by entering the appropriate #RRGGBB code into the color text boxes when you select a named color from the corresponding drop-down box, and by inserting the appropriate Schedule Maker input into the ``Classes'' text area when you click the ``Add this class'' button. If your browser of choice doesn't support DOM or JavaScript, you'll have to fill in colors by hand, and familiarize yourself with the file format to add classes.
Schedule Maker actually dates back to late fall/early spring of the 2000-2001 school year, but I didn't get around to finishing it until late summer 2001. It has a long and celebrated history and tradition, spanning many volumes and passed down through several generations. Okay, no, it doesn't. It's actually rather boring . . .
[ insert wavy backflash effect (low budget) ]
Back when we were doing advance registration for the Spring 2001 semester here at Penn, I was delighted by the fact that Penn In Touch gave you a nice HTML table-ified schedule, right there under ``Schedule''. See, I enjoyed looking at the layout of my schedule, so I could easily see when I had blocks of class and when I had blocks of free time. (I'm a visual learner (actually, I tend to learn by writing things down (and I'm told from the way I speak and describe things, I'm really an auditory person, so all of this is probably bunk anyway)).) After about 12 and a half seconds of amazement, I realized the true suck of Penn In Touch's HTML schedule -- it only showed class start times, not ending times, so really it didn't give you any sense of time blocks at all! Needless to say, i was disappointed.
So i set out to create my own HTML schedule, using my vast and extensive knowledge of HTML tables. It was a relatively large undertaking (compared with, say, sleeping), and i had to learn some subtleties about table data, but in no time at all, i had a decent-looking schedule. Well, that's a lie -- it actually took a fair amount of time, although it was mostly a mechanical process. These two factors struck me with the distinct impression that this was a task better suited for machine than man. Plus, i mean, hey... i didn't want to have to make six more of these before i graduated.
Being that my primary motivations were laziness and impatience, i decided on Perl as the language of choice. Besides, it's what Perl's good at -- text processing! (And text processing really proves to be more fun than one might think, but that's another story for a slightly different day, in the words of the immortal, Dr. Mintz.)
In no time at all (well, a couple hours, maybe), i had a working prototype, written in glorious Perl 5. It took a simple, elegantly structured input file and produced good, clean HTML and well-laid out if not exactly `aestheticly pleasing' schedules. I felt like a god. After all, the third cardinal virtue of a great programmer is hubris, isn't it? I immediately started making great plans with lofty goals -- a web interface, color, etc.! It was all a matter of details at this point. (It's always the details that get you in the end, isn't it?) Details like the exact semantics of the web interface, whether i'd have to learn JavaScript or not, how to specify color elegantly in the file format. . . wait, how to specify color elegantly in the file format? hmm. . . how to specify color elegantly in the file format. . . well, i'll sleep on it; it'll come to me. . .
And thusly was Schedule Maker first forgotten. See, it was a very simple input file format back then (and it still is, pretty much), and i didn't want to over-complicate things just to add colorability to the classes. Cyrus, Java programmer extraordinaire, suggested that i just use Cascading Style Sheets, and let the user enter the styles in a big text box. That's rather close to what i ended up doing, in the end, but at the time, it sounded like way overkill and too complicated. (I was attempting to cater to the masses, not the elite modern web designers.) So i just forgot about it for a long time.
Enter summer, with its backwards days (going to bed in the morning, waking up at night) and moments of extreme boredom. After spending my time learning several obscure programming languages like O'Caml, SmallTalk, and Ruby, I decided to learn something useful. Hey, i thought, why not learn JavaScript? That could be useful. . . and I could finish Schedule Maker! And thusly was Schedule Maker remembered again.
The rest, as they say, is history. I came up with a brilliant way of adding colors without overcomplicating the file format (see file format), learned a bit about web design (a very, very small bit), and ran with it. I also learned a bit of PHP along the way, but that's relatively minor.
As stated in the system requirements, the frontend employs a combination of HTML 4.01 (Transitional) and JavaScript with DOM. The JavaScript/DOM combination serves only as a convenience, to make the form easier to fill in.
The frontend also utilizes PHP to create the style widgets and the color and time selectors inline. This saved me a lot of typing. Thanks, PHP!
The backend is written in Perl, despite my newfound PHP knowledge. It was actually easier to do in Perl, i think, because it has to call the actual Schedule Maker program, which is, of course, a Perl script itself. That script produces HTML 4.01 (Strict) output, with Cascading Style Sheets, Level 1.
Schedule Maker uses a very simple input file format. It's parsed with
plain old Perl, using nothing more complex than split, so
it had to be pretty simple. Besides, what do i know about writing
parsers? (Answer: not a whole lot, just yet — but once i take
CSE 262 and CSE 341, i'll be more powerful than you can possibly
imagine.) Consequently, i won't be providing a complete BNF grammar for
it, because i don't know how, and because if i did, you wouldn't want it
anyway. But, i digress...
Schedule Maker's input file in line-based. Aside from the fact that records are separated by newlines, the file is essentially whitespace independent. That is, where fields are separated by whitespace, any type and any amount will serve. Keywords are case insensitive.
The first thing that has to be in the input file is global style data. The syntax for a global style line is:
style <selector> <style data>
<selector> represents the class of data this
style should pertain to, and <style data> is the raw
CSS1 style data: what goes inside the { curly braces }. Under the hood,
this simply give the document a style sheet directive of:
<selector> { <style data> }
table and td and
the internal classes .day for days of the week (along the
top) and .time for times (along the left). Similarly,
the style data needs to be valid style data. (Didn't i say this was
easy?) An example:
style .day,.time background: #FFFAF0
Following global style data are the title and class declarations. The syntax for a title declaration is very simple:
title <schedule title>
<schedule title> is (duh) the schedule title.
This is not rocket science, really. (Why am i wasting time writing this
in such ridiculous detail...) A class declaration looks something like
this:
<days> <start time>-<end time> <class description>
<days> is a string of characters from the set
{M, T, W, R, F}, representing, respectively, Monday, Tuesday, Wednesday,
Thursday, and Friday; <start time> and
<end time> are given in 24-hour (`military') time; and
<class description> is— oh, bah. Do i really
need to be so patronizing? A subtlety to note: the times will be
rounded down to the nearest 30-minute increment, if necessary.
(Schedule Maker's granularity is 30 minutes — it has to have some
kind of granularity, and 30 minutes seems to be the best compromise
between compactness of schedule and versatility of expression. Want
something finer? Bitch, and i'll consider it.)
(Update! Someone bitched, and i considered it. Schedmaker now supports arbitrary granularities, and granularity is autodetected via a brilliant application of the Euclidean algorithm (and you thought it had no practical use! hah!). Unfortunately, i'm still too lazy to properly update the web interface. You can use the new backend by visiting the beta version, though.)
Title and class declarations may optionally be followed by local style declarations. The syntax for a local style declaration is very similar to the syntax for a global style declaration:
style <style data>
MWF 11-12 CSE 120
style color: white; background: blue
And that's about it. Simple, innit?
Well, i can't really remember why i dedicated a whole section to styles. Maybe because that was such a huge revelation, and allowed me to continue work on this project. Or maybe because styles are such a fundamental aspect of this program's operation. Or maybe ... i'm bad at writing documentation :) (my money's on the last one...) Whatever.
Anyways... styles exist in style declarations. You can check the file format section for all the gory details, but just to sum up, a style declaration looks like this:
style [selector] <style data>
So to sum up, an example:
MWF 10-11 PHYS 170
style background: green; color: white;
style background: mediumspringgreen; color: black;
M 14-15 PHYS 170
PHYS-170.
Oh, by the way, if you haven't noticed, style data is
basically any data that could go in { braces } in a CSS1
style declaration. (I already said that, didn't i.) The CSS standard
doesn't allow for named colors,
but they are supported in most modern web browsers. YMMV.
(For what it's worth, schedmaker's web frontend always produces
#RRGGBB color values, even though you may select them by
name in the style widgets.)
So, you're happy with schedmaker, and would like to comment on it? You're disappointed with schedmaker, and would like to lambaste me? You have a really interesting schedule, and want to tell me about it? (Incidentally, this semester, my schedule takes place only on Monday, Wednesday, and Friday -- interesting, no?) You'd like to see the code, or contribute some changes? You've broken something, and have a bug to report? You're confused, and think this documentation really sucks?
If you answered `yes' to any of the above, you may be eligible to contact me! Send any questions, comments, or other feedback you may have to wlovas@stwing.upenn.edu. I'd love to hear from you! (Probably, anyway...)
Congratulations! You are one of the elite few who has actually read this documentation. You are now a member of a small and (n)ever growing group of bored people.