York Course Selections System
Phase One: Envisioning
York University Class Scheduling Process
Benchmark Study
Step 1 - Selecting a Term
This page is shown at the beginning of the process of adding classes. It asks for the sections.
Two of those selections don’t make any sense to
me though. “Fall 2010-Graduate Students or Osgood Students” and “Winter 2011-Graduate Students or Osgood Students”. The actual selection
we make is “Fall/Winter 2010-2011 undergraduate
students”. Seems that it should probably know
what kind of student is signing in.
The Overview
Logged in and showing all selected courses. Buttons along the bottom give clear access to the four
available actions that can be taken, with explanations for each underneath.
The warnings which appear to be quite critical are
shown at the bottom of the page, rather than at
the top.
Course Details
A tabular version of the timetable view; this lists
everything that is shown on the calendar view, but
in this less-clear table. Strange.
Selecting Courses
At present, the course-selection process requires
that two windows be left open and that the student navigate between them both to complete a
number of common tasks.
Because the course-adding and course-browsing
pages are actually separate sites that do not communicate their states to each other, it is actually
not possible to see whether or not the student is
enrolled in a class already, or even if they *can* be
enrolled. This is shown on a course-details page
later on.
Advanced Search
Allows for searching by faculty, subject, course
number, year level, and session.
Course List
This page lists courses for possible selection.
There are some bits of information that might be
desirable at a glance, namely whether or not the
class is available, and the description (without
needing to click away and wait for another page
to load).
Course Description
Essentially “more info” about a selected course.
Includes the name, code, description, language,
and lists any prerequisite courses. This page is
reached via a link from the course list page (described above) and requires yet another click to
see its schedule.
Course Schedule
Lists the various sections of the course, and then
breaks them down into “categories”, or basically
the available time-slots that can be chosen.
There is no explanation given for the various
codes on the page, including “LAB”, “PRAC”, the
date codes (“M, T, W, R, F”), and Cat #’s.
There is no way to make the selection of a course
from this page.
The description of the class is not shown on this
page, and is linked multiple times besides each
section head, requiring opening another window
or navigating away to learn more about the class
itself beyond its schedule.
Reports on available are vague where they could
be more definite: “Remaining seats may be restricted” means neither full nor empty, but the
suspicion is that saying “full” is avoided because
exceptions can be made. This is not communicated, and is just an assumption.
Plot My Timetable — Select Session
The process of adding and removing classes is
communicated entirely through lists and plain
text. If the student wishes to see how their schedule actually looks on a calendar, they need to select “Plot My Timetable” from the menu on the
left. Doing so brings them to this page, asking the
student to select which session they’d like to plot
the schedule of, again not bothering to make any
intelligent assumptions about the program(s) in
which the student may be enrolled.
The Timetable
This page draws the student’s schedule onto a calendar of a single week.
•
Class names are not shown in full; only course
codes, sections, location, and “type” are shown.
•
To access a course’s name, description, professor, etc., the student must click the course code
and navigate to that information through one
of the other pages discussed above.
•
The calendar shows only one week, and therefore does not communicate holidays, due
dates, or any other time-based information
that is attached to the courses.
•
This page also entirely static; changes cannot
be made to the schedule from here.
Summary
The existing process is functional enough (obviously) but there are
many annoyances and actual problems that crop up when it comes
time to use it every year. One of those is the frustration that arises
when classes must be shuffled to accommodate external commitments, or even just desires such as wanting to have Fridays off. The
work involved to plot such a schedule is much greater than what
would be needed in a system that took advantage of more modern patterns for interaction in web applications. At present, the
York Class Scheduler is just a series of pages that must be shuffled
through dozens or even hundreds of times before a schedule can
be completed, often resulting in varying degrees of user frustration
which is then typically expressed to faculty and higher-ups.
Our goal is to improve the system and give students as many of the
tools as possible to resolve scheduling conflicts on their own and to
minimize the frustrations felt each year or semester when it comes
time to select classes.
Digg.com Interface Analysis
Benchmark Study
Step 1 - The Initial Interface
Digg separates the navigational scheme into a
well-defined structure: the key categories are easily acessible to the left, while secondary forms of
filtering, searching and organization can be found
above.
The interface functions around the articles and
links themselves; they consequently become the
key focus of attention; in fact, clicking a link leads
straight to the article page, and not the digg page
for that story.
The simplicity of the interface, with only three
main sections for navigation helps make digg an
easy site to navigate. Furthermore, clearly separating navigational controls by function and category
is another reason why the inteface is so functional.
Object Manipulation
The detail view for each story has a few features
that are significant: commentary, and a rating system. This type of functionality could be considered
for the York course selection system, since a both
would give valuable advice in course selections.
Additionally, this page also offers an easy way to
continue further exploration of the site through
its category menu along the top. Evidently, digg
does not function as an interface that has a linear
approach: so a back button is not as useful as a
category selector.
Summary
The Digg.com site has some parallels to the York course selections
app in its interface. Although it is very simple in heirarchy, it makes
up in efffective UI. Digg therefore, is a perfect example of interface
practices that we can adopt in the York course selections system.
The second key aspect to Digg, is their considered use of navigational tools: never offering too much unneeded functionality; they don’t
offer a complete menu system, but a tailored one to each screen—
based on what users really need to do at each stage of their interaction. This is a powerful approach that we can use in our contruction
of our interface, effectively simplifying the complex.
Trent University’s Course Scheduling Interface
Benchmark Study
The Dashboard
A very unpolished dashboard presents a categorized list of links. To begin browsing for courses
(which is the first step, though this isn’t communicated) the student clicks on “Search/Register for
Courses”.
Search for Courses
This “Advanced Search” actually comes up after
going down an erroneous path first. The normal
view is made up only of the term option and the
five drop-down menu rows in the table. This view,
however, better conveys the full toolset available
(if you can dig) of their application.
Some interesting criteria are “Sections Meeting
After” and “Ending Before”, which let the student
select times which lets them control whether or
not they end up with late or early classes in the
results.
Students can also search for classes by instructor,
which is possible in the York interface, but not in
this way; the instructor’s name must be clicked
and then their classes are shown.
Classes can also be searched for based on their
meeting days, which is also not as apparent in the
York application.
Express Registration
Actually used for searching by course code, I believe? Either way, this interface is disturbingly uncommunicative of its purpose.
The Result
The resulting of the operations gives you this tabled layout.
Summary
This university’s approach is decidedly worse than York’s. Still, it
does offer a (very) few number of features that could be beneficial,
even if those features require serious digging to unearth. While
only one case, this shows that other universities could benefit from
a solid course scheduling model on which to base their own improvements. Our solutions should, wherever possible, try to resolve
the issues experienced by students in general, and perhaps not only
those who attend York.
Zoho Creator Interface Analysis
Benchmark Study
Step 1 - The Initial Interface
The overall structure of the web app revolves
around two specific areas: the tool menu on
the left, and the ‘canvas’ on the right. Additional
tabs and dropdowns are found above. The latter
present too many options, making the interface
somewhat daunting. What may have been helpful
would be to categorize the seven tabs into three
or four general tabs, with descriptions to them
(fig.1), or possibly introduce some other organizational scheme—such as separating by function—
and separating ‘settings’ and ‘share’ from the other
tabs.
fig.1
Object Editing / Selective complexity
The systems proves very functional in its treatment of object editing. You can simply modify additional parameters or delete an object through
context-sensitive hover menus. This approach to
selectively exposing levels of complexity in an application is perfect for making an interface more
inviting to a first user. This is something that can
be directly transferred into the York course selection system.
Object Manipulation
Another key feature of this interface is the drag
and drop functionality: it easily allows users to rearrange and organize elements in the order they
see fit. Likewise, adding a new element is a similar
action (fig. 1).
This type of responsive, feedback-rich, and simple
interaction would be a key asset to rearranging
and organizing courses.
fig. 1
Modal Boxes
Modal elements provide access to additional functions, allowing for the application to exist in only
one window, and without the need for switching
between multiple windows.
The modal boxes are fast, and easily comprehended by the user in their similarity to OS windows.
Additionally, since they allow for the main application to show through in the background, they provide the user with a spacial reference as to where
they are situated—confirming that their mental
map of the application is indeed correct—a crucial feature of good web applications.
Summary
The overall user experience of the Zoho Creator app somewhat caters to returning, power-users. The top tabs are too numerous, and
their similarity of form is confusing, since some of them are unrelated: such as settings alongside schedules.
Where the interface excels is in its approach is the drag and drop
approach to rearranging elements, as well as the context-sensitive
tooltips that do not overwhelm the user with a cumbersome interface.
Possibly, some of the interface’s downfalls can be solved with a simple introductory screen, outlining the key steps to completing the
task, or possibly a step-by-step approach to the interface that separates the task of creating a schedule (or form, as in the case of Zoho)
into a few easy to understand, and manageable sections (see fig. 1).
fig. 1
York Course-Selection Process
Activity Analysis
Mode
Activity
User Functions
System Functions
Exploring Classes
Browse
•
•
•
•
Filter by category (Any course property)
Star potential courses.
Remove a course from bookmarks.
Inspect details of course: timetables, description,
etc.
•
•
•
Display whether course prerequisites are met.
Sort course by categories.
Display secondary information for courses: description, professor, fees, required texts, etc.
Search
•
User enters one or more of any criteria for finding a
class
• Any course property
•
Parse through catalog of courses, according to
search terms
Display results
Identify, and mark unavailable courses.
Click any column header in the list of classes
•
Sort
•
•
•
•
Make an asynchronous request to refetch the results, sorted by the selected column
Return to Page 1 of results
Star
•
Initiate the “Star” command by clicking the star
button beside the class name
•
•
The class is added to the list of starred classes
The star icon is illuminated to show its status
Add Class
•
Initiate the “Add Class” command
•
Add the class itself to the timetable, independent of
section
Re-run the timetable-suggestion algorithm to generate updated schedule possibilities
•
Add Section
Manage Classes
Drop
•
•
•
Browse available sections
Select a desireable section
Initiate the “Add Section” command
•
•
•
Select a class in the timetable
Initiate a “Drop” command via its action menu
•
•
•
•
•
•
Transfer
•
•
•
Reposition the class block on the timetable
Re-run the timetable-suggestion algorithm to generate updated schedule possibilities
•
Hover over a selected class
Choose from the revealed alternative locations on
the timetable
Drag the class block into the desired location
Select Alternative
Schedule
•
•
Browse the list of suggested alternative schedules
Select one from the list of thumbnails
•
Update the timetable view to reflect chosen section
configuration
Commit
•
•
Enroll in all courses in the final timetable.
Enroll in the selected course only.
•
Enroll into a course; update the number of students
in the class, and if the class is full, disable it for
further enrollment by others.
Ability to enroll in each course in the final timetable
layout.
Ability to enroll in only the highlighted course. That
course can no longer be dragged and has tool-tips
for transfer and drop.
•
•
•
•
•
Properties of a Course
•
•
•
•
•
•
•
•
•
•
•
•
•
Prompt user for confirmation of action
Remove record from timetable, remove space in
enrollment count.
Course disappears from the timetable view.
Logs action (“undo” supported)
Re-run the timetable-suggestion algorithm to generate updated schedule possibilities
Select a class in the timetable
Initiate a “Transfer” command via its action menu
Select the target course (to transfer into); either a
“Starred” class, or by browsing/searching for another in Explore Classes mode
Shuffle
•
•
•
Add the class section to the timetable, pinning it to
the selected section
Re-run the timetable-suggestion algorithm to generate updated schedule possibilities
Faculty
Year (1/2/3/4/Graduate)
Term
• Fall
• Winter
• Spring
• Summer
• Year
Name
Description
Credit
• 3
• 6
• 9
Course Director & contact information
Prerequisites
• Exceptions allowed?
Sections
• Professor
• # of students enrolled
• Maximum class size
• Lecture schedule
• Day
• Time
• Length
• Tutorial schedule
• Day
• Time
• Length
Hours Per Week (a sum of the lengths of both lecture and tutorial)
Textbooks
• Required or optional?
Fees
• Amount
• Required?
• Due date?
Language of instruction
Enroll in “target” course, and upon success, deenroll from the first. Else, do nothing and inform the
user of the failure, with reasons.
Re-run the timetable-suggestion algorithm to generate updated schedule possibilities
York Course Selections
Log In
System Flowchart
Show Timetable
YES
Happy with
selected
classes?
NO
Is it empty?
NO
YES
Have
enough
classes?
NO
Generate
Variations
Re-arrange
manually
Let the
system
suggest
alternatives?
YES
NO
Happy with
schedule?
How do you
want to find
classes?
YES
View Starred Classes
YES
Transfer or Drop
Commit Current
Schedule
Search
Browse by Category
NO
Show Results
Happy with
Results?
Back to Start
NO
Where do
you want to
go back to?
Enroll in Courses
Back to Results
Want this
class?
NO
How do you
want to add
it?
Add Class
YES
Is it
available
for
enrollment?
YES
MAYBE
Add Section of Class
Star Class
Add To Timetable
Select a Result to View
Class in Detail