|
Student Affairs Daniel Salter Penn State University Editor Stuart
Brown Fall 2001 Vol. 2, No. 3 |
|
|
|
||||||||||||||||||||||
|
Join our mailing list!
|
|
|||||||||||||||||||||
|
University Operations |
Command Line Interface Systems |
|
All policies and forms must be unambiguous. |
All programs must be bug free. |
|
Collect and collate policies into manuals. |
Collect and collate multiple commands into operating systems. |
|
Individual offices write their own forms, policies and procedures and make them work within the university. |
Individual programmers write programs and make it work within the context of other programs. |
|
Occasional meetings are held to discuss procedural standards. |
Occasional meetings are held to discuss programming standards. |
|
University ombudsperson helps to solve problems with forms, policies and procedures. |
Bug fixes are well documented and available on-line. |
|
Without a complete form, policy or procedure, no action is taken. |
Without a proper command, nothing happens. |
|
Student or user is sometimes notified when forms are incomplete, but is rarely told what to do. |
User knows when things don't work, but often doesn't know why. |
|
User required to learn campus operating procedures in the catalog, policy manual and handbook. |
User is required to learn huge and mind-numbing commands and procedures. |
|
Every action requires a unique form or procedure. |
Every action requires a unique command or program. |
What would a GUI campus be like? Work processes would be integrated and have multiple entry points. Many offices can perform the same task, enter the same data and achieve the same action. As with Windows/MacOS operating systems and applications, there should be one menu bar for all activities designed with the student in mind.
Command line interface operating systems have the computer in mind as the primary stakeholder for all commands. Many universities have their processes in mind as the primary stakeholder for all forms, procedures and processes. GUI was designed as a more appropriate user oriented operating system. Some universities are putting the student first when redesigning forms, procedures and processes, but this means that the university will have a new operating system. Since most of us have experience upgrading operating systems, we know what a challenge this can be.
By reinforcing the discrete character of each of our work units on campus the CLI mentality, one special form for one special action, keeps us from integrating our interactions with students. Students need to go from office to office on campus to accomplish work, and at each office having a specific form (command line) handed in during a specific time. Classic stories abound about students being sent from office to office to accomplish one simple task, because several offices had a part in an overall task but no office was responsible for more than their single command line.
I am not sure what a GUI campus would specifically look like, be like, or work like, but different operating systems have different appearances and different ways of working. To continue the computer metaphor, LINUX is one of the latest things in CLI, but some people have made a GUI interface for LINUX. The user is presented with the familiar cursor/icon interface and it is transparent to the casual user that command lines are being enacted as they click on icons. Campus networks make it possible to enter data, or submit command lines, or submit forms, from nearly any location on or off campus. Since the networks don't close at 4:30 students can submit command lines or forms during hours that are convenient for them.
This material was inspired in part by reading Neal Stephenson's In the beginning was the command line. (1999, Avon Press)