Vincent 4.0: User Flow in Vincent 3

Vincent has been in use in the CS department in it's current form for over a year-and-a-half. There are inconsistancies in Vincent's operation that make some operations unreliable (roster update), and other features that are undesireable to some users (the web interface in general). As such, describing and diagramming Vincent's user and data flow as it currently exists is a waste of time.

Describing Vincent's current user flow in practice is of value.

The difference is critical: while there is a theoretical flow that existed (an ad-hoc design implicit in the code), this is of secondary importance in light of how Vincent is used now. Much of current practice involves working around flaws in the existing system; identifying these flaws, and fixing them in the next iteration is of primary importance in a Vincent update from a user's point of view.

What follows is a description of the current practice regarding course management, broken into the largest behaviors instructors, assistants, and students engage in with Vincent. It is largely a discussion of problems with the current flow, such that it exists.

Course setup is a tedious process in Vincent 3. Because nothing can safely be kept between one Vincent installation and another (because of inconsistancies in the way Vincent stores and accesses data in the filesystem), a clean installation must be provided every semester.

Documentation is provided for course setup; this documentation is generally adhered to by users, for fear that Vincent might misbehave. It is known that failing to follow the course setup procedures can result in ugliness in the Vincent filesystem, and as such, most users (it seems) have adapted to the fact that they must use the documentation when it comes to setting up Vincent.

Known problems are as follows.

• Roster Import: Vincent imports rosters fairly well, but there are problems with handling line endings. Rosters come through email, are copied into a text editing program of some sort, and then submitted via the web. At some point, either
  1. We corrected Vincent's import behavior to handle Windows line endings, or
  2. People submit their rosters from UNIX boxen, and there are no problems.

  Because we have had no (known) problems lately with sumissions of rosters from Windows machines, it is assumed that this problem was dealt with.

• Roster Update: When an instructor submits a roster, students are either
  1. New: Vincent adds them to the correct section.
  2. Withdrawn: Vincent removes them.

  The logic for importing students who are already in the system (in Vincent 3) is broken; students who should be switched from one section to another are removed entirely if they show up withdrawn after their section change in the roster file. Of course, there is no controlling the roster files, so Vincent needs to be smarter. Vincent 4 handles this by allowing for students to be in multiple sections; withdrawls are handled within the appropriate section, and they are added to the new section. This will, invariably, introduce a new kind of error that is as of yet unforseen.

  Roster update currently is not used by instructors, because they know it to be untrustworthy. The whole point of the roster update process is to save instructors from manually changing student status.

• Assignments: Currently, assignments must be input afresh every semester. Ideally, instructors would be able to download the current configuration, make minor changes (due-dates, for example), and then resubmit the configuration (in-semester) or afresh (at the start of the semester).

• Student Record Update: Student records are a dumping ground for information in Vincent 3. As a result, they are a nightmare to work with. The information in a student record is often formatted in particular ways, and instructors can do serious damage to a student record in Vincent's current incarnation. The interface for managing information pertaining to a single student (enrollment status, etc.) is simply unfortunate.

  Instructors typically want to be able to modify the student's enrollment status, if anything. Indeed, very little about a student record in Vincent 4 should need direct editing by instructors. Students occasionally change usernames, which is the most disasterous change that can happen in a semester (usernames are primary keys, and cannot be avoided--they interact with the Kerberos security mechanism).

  In the end, almost all (direct) interaction with student records should be unnecessary from an instructor's point of view. Roster updates should handle the bulk of the work that currently is done on a student-by-student basis.

• Assignment update: Assignments need to be modified from time-to-time. The due date is shifted, etc. As such, it should be easy to modify an assignment, and the effects should be immediate. For example, if an assignment was due on January 1st, and later shifted to January 5th, then all assignments that were submitted after the 1st but before the 5th should no longer be considered ``late.''

  Currently, it is difficult to update assignments and have this kind of common-sense behavior take place. Because the underlying representation is a filesystem, it may be difficult to implement this correctly without incurring too much run-time overhead. This is yet to be seen.

• Student submission modifications: A student may get hit by a bus; this happens infrequently, which is surprising. If a student were to get hit by a bus, they would likely get a one or two day extention on a homework submission. Ideally, we could indicate an ``over-ride'' due-date for a student's assignment. More likely, it should be easy (in practice) to take a late submission and make it on-time. This is currently very difficult in Vincent, and involves navigating a ponderous student record, and modifying a datestamp in a cryptic syntactic format. Instead, a simple ``late'' flag should be removed from a student's assignment, and it will now be viewed as ``on-time.''

  (Depending on how assignment update and such is handled, implementation may actually involve the overriding of the system-wide assignment due date.)

• Assignment download: Currently, the interface for downloading assignments is through the web only. A command-line interface is highly desired.

  Currently, the interface for retrieving only the most recent version of an assignment is ponderous (at best). Due to the way assignment submissions are represented, it is difficult to get the most recent version of an assignment with multiple files (which may all be sumitted multiple times). The metadata for file storage in Vincent 3 is lacking, making tracking the ``most recent version of 5 different files for assignment 8'' a tricky proposition. New metadata makes this problem significantly less difficult. (It is estimated that Vincent currently employs an O(n²) process to find the most recent version of an assignment and all the associated files... this should be reduced to less than O(n) time with a new data representation).

In finishing the semester, there are currently no practices in place with Vincent. If it was possible to export and import assignments (saving a large amount of work from one semester to the next), then this would probably be a common practice. Currently, nothing happens; because tape backup happens automagically in the CS department (automagically meaning ``our excellent system staff makes sure it happens''), any information from a Vincent installation can be retrieved later from tape. Most administrators do not do any backups or cleanup of their own at the end of the semester.