Menusystem Demo

Although the initial thrust behind the menusystem database design was sufficient flexibility to enable multiple type of information, such as dining hall hours and payment options to be centralized, this demo restricts itself to displaying the menu-centric capabilities. A sample end-user (student) and administrative (CDS) views are included.

Scroll down this page to read a short tutorial on how to use the system. The interface was designed with the idea that users, both students and CDS, would use the system regularly; while the initial learning cost might be a little high, the goal is for typical-day usability to be at its lowest. Also, I was testing out AJAX for the first time, so there many be compatibility issues that arise, which would be eradicated were this system ever to enter reality, which it might.

A caveat: I want to present to a working interface, so pressing a button that says "delete everything" will actually delete everything; cleaning old things is a necessary feature.

Detailed Overview

Administrative

1. Main screen

Here, you can enter a date, and a number. This is very similar to the current way to entering menus, and it seems to work naturally: typically, menus would be entered 4 days to a week ahead, starting with a proximate day. Date fields are initialized to today. Click 'Add Menus!' to more on to the next screen (discussed in (2) below).

In addition, there are these two giant, beckoning buttons for deleting everything.

2. Entering Menus

This is a very overwhelming screen. However, it is also very powerful, and much easier to use than the current interface, which, too, can this table structure of halls to days. Again, the fact that the idea is familiarity is important motivated me to adopt the existing table paradigm i nthe interface.

What stuff means:

And here is some stuff I added for your previewing for Tuesday and Wednesday:

Viewing

What kind of things can the viewer do?

Final Thoughts

This application demos only a small part of what the database has, or can have. For example, though payment types and meal schedules exist and are used, they are not accessible for viewing or editing in this application. This was, in part, deliberate: the current menusystem only deals with menus, too. By the way, here is what was made a while ago for CDS that is used today by many students on a regular basis. It is the most frequented part of the site. While cleaner that what I have, it is less informative on the surface, and substantially less informative as a database thingy.

I used a ton of JavaScript/AJAX/etc in this application. It was very cool; I learned a ton. The JS debugging took more time than expected, while explains why my favorite part of the database - the times meals in halls happen - is nowhere to be found.

Nonetheless, I am quite proud of the administrative view, and I think the fisheye is pretty darn swanky.

My Code

Here is what is happening in the code: