Skip to Content, Navigation, or Footer.

Zachary Townsend '09: Banner implementation prizes convenience over usability

I can think of few businesses in the world other than our University that could require their customers to go through the flogging that is using the Banner system and not go out of business. I am not merely being rhetorical. I have no idea how the Banner team sat down and decided that all questions of usability were to be ignored. Last year, several students in CG116 (or is that COGS1160?), a course on system design for human use, studied the usability of Banner for their final project. As Ian Spector '09, one of the students involved, wrote, "Upon viewing the finalized list of initial features to be included on launch, it becomes immediately clear that at no point is there any discussion of user interface modifications."

According to Don Thibault, a usability consultant for SunGard (the software company that created Banner) and a member of Brown's implementation team, it was decided from the start to work with the "baseline" or standard-issue implementation whenever possible. If the off-the-shelf Banner code could not be easily modified to meet the University's needs, it was decided to modify our operational policies to match those of the baseline system. In other words, if the system could not be changed to reflect Brown's values, then Brown's values were compromised. As Spector correctly notes, though, "You don't have to work on Madison Avenue to know that regardless of the project, it's generally bad practice to be willfully ignorant of the needs and abilities of a system's users." With $23 million in the bank to spend and even more features to implement, the project developers under Associate Provost Nancy Dunbar's leadership found that it was necessary at all costs to prioritize system functionality over its usability.

Dunbar has said making changes would require such widespread modifications to the software that it just wouldn't be possible for our campus team to implement them all by itself in a short time - leading to the question of why over 500 colleges and universities have adopted a system with such a poor end-user interface. However, the University was completely shown up when a group of computer science students created Mocha over one winter, destroying any faith people had in Brown's ability to correctly size up programming problems.

Dunbar also wrote a letter to The Herald ("Nancy Dunbar: Approaching Banner," April 3) in an attempt to provide some sort of hope to the community that rightfully didn't see all that much in what was offered to them. In regards to going live with the user interface (referred to as "customization") that was decided upon, Dunbar said the following: "There are lots of reasons for this approach, not the least of which pertain to maintaining a schedule and budget. But the more important conceptual rationale is that such an approach requires us to thoroughly learn a new system before we evaluate and change it." This second sentence is a lie. Dunbar and other members of the implementation team had already stated the primary rationale for the current interface - the decision was not about testing the system but rather about the aforementioned emphasis on pragmatics before institutional values. In her article, Dunbar attempts to deflect the blame from her and her team's choice to de-emphasize usability.

Let's start with the most simple problem: course descriptions, meeting times, and instructors' names aren't available on one screen. Course listing information is split up in Banner between two databases: Catalog and Schedule. What is a student supposed to do first? Which database should users rely upon? The sheer amount of crucial information available through Schedule makes it more useful (meeting times, professor, course capacity, restrictions and final exam information). But what if a user does not know which course to take? Browsing through Catalog, which has course descriptions, would be ideal, but it wouldn't provide the user with the remainder of the course information, which can be of equal or greater importance.

There are many additional problems with Banner. Among other issues, the subject menu shows only four subjects at a time (and could be replaced instead by a drop-down menu to view everything at once). The back button does not work. Cross-listings are placed very obscurely and hence very hard to find. There is no confirmation page to indicate that registration has been successfully completed. There was no transition period wherein students could use either Banner or the old system.

Banner made fundamental changes to academic rules (for example, prioritizing seniority in deciding who gets into limited enrollment classes) without any deliberate discussion or decision that Brown wanted that change - they were changed just because it would have been "more work" to edit the program. The decision to get rid of the printed catalog, especially in light of the awful Banner interface, is ridiculous.

It seems as though the campus could have waited an additional length of time until enhanced usability features were added, developed and properly tested. There may have been plenty of protests to end the Banner project, but it is doubtful that there would have been any to speed it up.

Zachary Townsend '09 longs not so much to change things as to overturn them.


ADVERTISEMENT


Powered by SNworks Solutions by The State News
All Content © 2026 The Brown Daily Herald, Inc.