The Evolution of The Banner Registration System:
A 6751 Group Project
by
Zongming Fei
Chad Jenkins
Harish Kotbagi
Table of Contents:
As stated previously in our evaluation, the purpose of the Banner
Registration System is to provide a means of automated student
registration for the Georgia Tech community. Students access the
Banner system through a capable WWW browser from any computer
connected to the Internet. Banner allows users to perform
various registration and administration tasks, such as schedule
modification and viewing.
General philosophy for new Banner design:
We will evolve the current Banner system by providing the user
with meaningful and helpful screen layouts, while keeping the
general structure of the current system.
Motivation:
The feedback from the survey questionnaire implied
that the participants were, in general, satisfied with their
ability to interact with Banner and perform tasks necessary to
their registration. However, we found that participants
unfamiliar with Banner performed significantly worse than
experienced users. These two facts imply that the functionality
of Banner is sufficient, but the system lacks a predictable,
intuitive feel for the novice user.
1) The evolution of Banner will be emphasized by furnishing an
easily accessible, inviting, and helpful entrance into the
system. The system entrance should remove the ambiguity between
entering Banner and Oscar. In addition, the Banner login-in will
equip the user will information necessary to correctly enter the
system.
Motivation:
Performance data from our evaluation suggested that
every Banner user has problems with the login-in screen.
Experienced users have trouble with the memorization and/or
retrieval of their PIN number, which can be expected to maintain
a degree of security. First-time users, however, were unsure
what they were supposed to enter into the ID and PIN fields.
This can be explained by users not utilizing the help option.
Furthermore, user have trouble accessing the login-in screen due
to the use of the term "Student Information Access" to indicate
Banner Registration. Most importantly, the entrance into the
Banner system will give the user their initial feeling about the
system. This initial feeling will remain with the user and has
an effect on how they will view the system as a whole.
2) Similar to the current Banner system, the general structure
of the system will have a Main Menu screen following user
login-in. The Main Menu contains two main submenus: the
Registration Menu, for general registration/scheduling tasks
relating to a specific term, and the Administrative Menu, for
tasks related to general student administration. Unlike the
current Banner, however, the Main Menu will clearly define of
services available under each menu to the user.
Motivation:
Inexperienced users often performed poorly or became
stuck during our evaluation when asked to perform tasks that
required navigation from the Registration Menu to the
Administrative Menu, and vice versa. In addition, the load
placed on the user's memory is decreased when the menu services
are provided in the Main Menu.
3) Every screen in the system will provide a noticeable help
option. The help option will give the user greater detail about
how to use the particular screen, including screen shots with
commentary.
Motivation:
Our evaluation of Banner revealed the common user's
belief that the on-line help is not beneficial in understanding
the system. This belief can be attributed to several factors.
First, the information provided is sparse and difficult to relate
to the actual screen functions. Second, users do not always
notice the help option. Third, users do not always realize the
option contains information useful to understanding the system.
4) Every screen will have a common look and feel with respect to
screen layout. Every screen will share the same background image
and a menu bar containing help, exit, and a subset of navigational
functions.
Motivation:
The driving factor behind this requirement is
predictability. A user should always know when they are in our
system because our unique screen background and layout. In
addition, by keeping a constant set of functions available, users
begin to feel comfortable with are system and can use those
functions as a stable building block, similar to the Minimize,
Maximize, and Close buttons in Windows95.
5) Our design will allow the normal use of navigational
functions provided in any front-end used by the system, such as a
WWW browser. Furthermore, our design will consistency provide
users with substantial navigational function within the system.
Motivation:
The current Banner system forces the user to
re-login, for security reasons, if they use any of the
navigational functions provided by the WWW browser. For most
users familiar with using WWW browsers, this security feature is
very bothersome and frustrating.
6) Wherever possible similar or complementary registration
functions will be merged to eliminate redundancy in the menu
structure.
Motivation:
The merging of complementary functions provides two
major benefits. First, merging provides a better grouping of
system functions. In several instances, the current Banner
system offers the same basic feature twice, each with a different
specific property. For instance, a user can view their schedule
by day and time or detail. The basic feature is viewing the
schedule and the specific properties is the format of the
schedule display. Second, merging concentrates and simplifies
the menu structure. By providing the general group instead of
specific features, the user's decision making load at a menu is
reduced. The only are concerned with the general functionality.
Once they have decided what general function they desire,
specific properties for that function will become available.
7) Our design will provide schedule creation and modification
functions that eliminate the use of the five-digit Course
Registration Number (CRN) for the more intuitive
Department/Number course specification.
Motivation:
The CRN provides less meaning when referring to a
class in the system is by its Department/Number code. The CRN is
a five-digit number that implies little about the type of class
being referred to. The Department/Number code gives the user
immediate feedback on general properties of the class, such as
subject matter and required student level. In addition, the
Department/Number code is commonly used to describe the class in
every other scenario, like graduation requirements, etc.
8) Our design must be compliant as feasibly possible to the
abilities of the WWW browsers.
Motivation:
By allowing access through a WWW browser, the
current Banner system provides a significant amount of
flexibility for students who need to access the system. The WWW
browser provides a platform independent front-end to Banner that
has an established and extensive position among the GT community.
After specifying a list of design criteria, the creation of a
storyboard detailing a typical user session was necessary.
Instead of generating this storyboard from scratch, one of the
members of our group performed their actual class registration
for the Spring Quarter 1997, printing every screen encountered
during the session. Not only did this yield a modifiable user
session hardcopy, but also gave our group first-hand insight into
using Banner. Changes were then applied to the user session hard
copy to reflect our new design. The following sections will
describe the our initial design changes and motivations.
Anything not discussed in during this Design Process discussion
was considered sufficient for our design and will probably remain
the same in the implementation of our design.
System-wide changes
One of the biggest complaints about the current Banner system is
the lack of help assistance provided. Therefore, our system will
have a help option for every function screen. This help option
will provide the user with a screen shot with descriptive
instructions for each screen feature. The help option will be
available through another feature present at every function
screen, a menu bar. The menu bar will consist of at least the
functions "Help", "Return to Parent Menu", and "Exit",
respectively, with each function displayed as a hyperlinked GIF
image. In addition, all system function screens, such as "Modify
Student Schedule", will have another menu bar of hyperlinked GIF
images to related system functions. The current Banner system
provides this menu; however, the menu items are small and at the
bottom of the page, making them difficult to detect. These
features have been added to the design in accordance with Design
Requirements #3, #4, and #5.
System Entrance
In order to satisfy Design Requirement #1, the Banner user
login-in will be combined with the Welcoming screen for the Web
Student Access System. The Web Student Access Welcoming screen
currently gives the user the choice of entering Banner or Oscar
and provides some general information about the status of the
system. This design removes the overhead of navigating through
several prelude screen and clearly distinguishes the Banner and
Oscar systems. Instead, our design will have the Banner user
login as the Web Student Access Welcome screen. The user will be
furnished with a choice of entering the Oscar system or entering
information to directly login to Banner. In addition, a
noticeable help option will dispense information about services
supported by Banner and Oscar, as well as the details of
correctly determining ID and PIN information. This screen should
be the first screen the user encounters with the specified system
background and screen layout.
Banner Main Menu
Similar to the current Banner system, the Main Menu is the
central point of access to all system functions. The system
functions are partitioned into two main submenus, the
Registration Menu and the Administrative Menu, as specified by
Design Requirement #2. A list of services provided by each
submenu will be provided underneath the submenu heading. The
list serves as a guide to the novice user, who is likely to have
trouble distinguishing between registration and administration
functions. The main difference between the Registration and
Administrative menus is that the Registration menu is associated
with one particular quarter. Thus, the user is required to
submit term to the system. The current Banner system handles
this with a screen that prompts the user for a term, with a
pop-up menu of available choices, after the Registration
hyperlink is selected. After the term is submitted, the
Registration menu screen is displayed. Our system, however, will
prompt the user with the same pop-up menu of available choices at
the Main Menu. When the Registration Menu is selected, the user
submits the term as well as navigates to the Registration Menu.
The final changes were made in respect to the menu bar. The
wording of "Return to Menu" was changed to "Start Over" and an
"Exit" function was added.
Registration Menu
The Registration Menu consists of six functions: "Select Term",
"Registration Status", "Modify Student Schedule", "Look-up
Classes", "View Student Schedule", and "View Fee Assessment".
Our design reduces the number of menu services from eight by
merging complementary services by using Design Requirement #6.
The "Add/Remove Classes" and "Change Class Options" services
merge into the service "Modify Student Schedule". This allows
our design to concentrate schedule modification functions into
one schedule interface, which will be discussed in the "Modify
Student Schedule" section.The other merger creates the menu
option "View Student Schedule" from the services "Student
Schedule by Day & Time" and "Student Detail Schedule". These two
functions serve the same basic service, except from different
perspectives. Thus, a pop-up menu is used to toggle the
perspective between "Detail" and "Day & Time" for one "View
Schedule" option. In addition to the mergers, our registration
design provides one line comments underneath each registration
function about the functions intended use.
Administrative Menu
By merging complementary functions, the Administrative Menu was
shortened from nine services to these six services: "View/Update
Address Information", "View Holds", "Display Term
Grades/Transcript", "Account Summary", "Request Transcript", and
"Change PIN". Six previous administrative functions were merged
into three function, each of which will be described in following
sections. Similar to the Registration Menu, administrative
services listings were given short function description.
Modify Student Schedule
Our evaluation of Banner revealed that users were dissatisfied
with the schedule modification interface, especially the use of
CRN's. One reason for this dissatisfaction is the fact that
different schedule modific functions are spread out
throughout the Registration menu sub-tree. Thus, our design
concentrates all schedule modifications into table to comply with
Design Requirement #7. The table consists of five class
description fields and one action field for a schedule of up to
10 courses. The six schedule fields are: Department, Course
Number, Section, Grade Mode, Credit Hours, and Action. All of
the course description fields use pop-up menus for selecting
values, except the Course Number Fields. The course description
fields will have no default values during the initial
registration for the term. This is to reduce errors by forcing
the user to at least enter values instead of accepting defaults.
The only default values are set by the current state of the
user's schedule. The Action field allows the user to specify how
to process the class entry through these available options:
"Add", "Delete", "Registered", and "No Action".
Merging of Six Administrative Menu Functions
As stated previously, our design merges three pairs of functions
in the current Banner system into three new functions. The main
reason for combining these functions is that each function of
each pair provides similar functionality to other function in the
pair. The merging provides greater concentration of the
Administrative Menu and is a better grouping of system functions.
However, each pair needs to be handled differently in the
interface.
The first of these functions, "View/Update Address
Information", is a combination of the functions "View Address
Information" and "Update Address Information" on the current
Banner system. The main difference between these options is
that "Update" provides editing fields in the same locations whereas
"View" provides only text. Our design, instead, provides the
option of viewing or updating from the "View/Update Address
Information" screen. Another difference between "View" and
"Update" on the current system is the set address that can be
viewed is different than the set of address than can be updated.
There appeared to be no reason for this design choice. Thus, our
design of "View/Update Address Information" has a pop-up menu
containing the one set of selectable address, which can be viewed
or updated depending on the button selected.
The second merged
function, "Display Grades/Transcript", is a combination of the
functions "Display Grades" and "Academic Transcript". Both of
these functions provide the same information. Although, the
"Academic Transcript" is the complete academic record, whereas
"Display Grades" is only for one selected term previous to the
current term. "Display Grades" does not belong on the
Registration Menu because the Registration Menu is only for the
current and following quarters. To handle the time distinction
between the merged functions, our "Display Grades/Transcript"
design provides two transcript viewing options "Entire
Transcript" and "Term Grades". Additionally, there are pop-up
menus with available choices for the selected term and graduate
versus undergraduate transcript.
The final merged function,
"Request Transcript", is a combination of "Request Transcript to
be Picked-up" and "Request Transcript to be Mailed". "Request
Transcript to be Picked-up" is the same as "Request Transcript to
be Mailed", except it does not require a sending address to be
entered. The design of the merged function simply has the layout
of "Request Transcript to be Mailed" with a radio button to
indicate "Pick-up" or "Mailed". A selection of "Pick-up"
invalidates the address fields.
For the implementation of our Banner design, we agreed upon the
WWW browser as our development platform. HTML was used to create
the front-end with interactive form controls, which were driven
by CGI scripts on the WWW server. The details of the screens are
illustrated by the help files we created. The help files include
screen shots with comments about the controls and their
functions.
As stated in the Final Design section, we chose to develop our
system with HTML and CGI. While this decision delivers great
flexibility for system access, the limitations of HTML and CGI
hampered many of the ideas created in our initial design. For
instance, the "Modify Student Schedule" or "Add/Remove/Change
Classes" screen requires 50 pop-up menus and 10 editing fields.
With CGI, these controls require a significant amount of
parameter passing and tedious administration. This however, results
in vastly greater ease for the users, as they don't have to move across
menus to do distinct actions like add/delete classes.
The design has resulted
in a significant decrease in the navigation between pages which
leads to faster access timings. This was a direct outcome of our
observation that users took a lot of time in getting to the necessary
pages. We have enabled the usage of the back button, as most users
had to relogin with the previous system when they used this option.
The basic structure of the registration system has been retained, so that
the user doesn`t have a significant learning work. The look and feel is
the same across different pages, to make it comfortable for the user.
Help menus have been provided for each screen, so that the user knows
the use of all the functions on the given page. The options to return to
menu are structured so that the user always returns to the page he came from.
The restriction on digital passwords has been removed, as most users found
this to be very annoying.