This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
User Interfaces have been growing for years to keep pace with diverse technologies that effect human computer interaction (HCI). Formal techniques for dynamic menu-based and command line interfaces are evidence of this growth. Graphical user interfaces (GUI) and command line interfaces (CLI) provide users with a medium to interact with an application or system to perform operational tasks. CLIs provide input to a textual interface while GUIs provide a richer interface that may contain a range of features such as drop-down menus, windows, and graphical icons. This paper will examine a brief history of both interfaces while discussing usability, performance, resource management, user control, appearance, multitasking, and the benefits of hybrid interfaces.
The initial CLIs were a concept adopted from 1950-1960 teletype machines and advanced to text user interface screens. Currently they provide colorful informative text displays and still in use alongside their respective GUIs. One of the first GUI's, Ivan Sutherland's Sketchpad
introduced a windowing system and the light-pen, pre-cursor to the modern day mouse. The Sketchpad concept still shapes modern day computing interfaces. The first WIMP (window, icon, menu, pointer) GUI that included icons, pop-up menus, and overlapping windows that can be controlled easily using point-and-click techniques came from Xerox PARC in 1975. The development of GUIs stemmed from the desire to alleviate the learning curve that was required to use a command line interface. Post-WIMP interfaces were developed for smaller handheld devices such as PDA's and smartphone's that needed a touch-screen interface due to their smaller screen size. Today's market provides CLI and GUI access with much of the emphasis being on the advancement and development of the latter.
First WIMP Interface
The term usability can also refer to methods to improve ease-of-use of an application. CLI input is driven by the user's ability to memorize commands and syntax. The CLI allows multiple commands to customize information output into a format that is easily analyzed by the user. Even with the customization some CLIs provide, the advantages can be hampered by users that forget the syntax of a command. GUIs tend provide a menu and window driven interface which can decrease the learning curve required by the user. By allowing users to view command
prompts through menu interfaces the "memory requirement from a process of command recall to one of command recognition" (Westerman 183) is lowered. Graphical interfaces also lower the chance of syntax error and prevent the input of illegal commands. Although in some areas such as network security monitoring CLIs are often the preferred method to gather security event data for auditing purposes. (Thompson 1205) The usability advantage is not always set in stone but is acknowledged to be shaped by many variables including goals, difficulty, and user experience.
An example of usability differences can be seen within the Cisco ASA firewall CLI and ASDM GUI (Java Web Start). To add an access control list (ACL) through the CLI you must type something similar to the following "access-list some_name line 4 extended permit tcp 184.108.40.206 255.255.0.0 220.127.116.11 255.255.255.255 eq 1111 log disable." The ASDM requires that you following these steps "click add access rule -> choose interface -> choose action -> choose source and destination address -> choose service -> choose logging -> click OK." The CLI method requires much more memorization and may be daunting to a first time user while the GUI route is done through a friendly visual interface and provides error checking that is lacking in command line.
Performance in reference to user interfaces is the time it takes to execute a task. CLIs can allow a single line of input to perform complex tasks by combining several commands. In most cases user will spend less time on a text interface because more information is made readily
available and with increased efficiency through less commands. Today's CLI's allow you to combine multiple commands through the use of " | " or " include" depending upon the vendor which greatly increases performance querying data. On the other hand a GUI may be easier to use due to the mouse although navigation through the interface may delay the execution of a task. It has been noted that "free recall is associated with higher performance accuracy" when compared against recognizing menu or icons with a pointing device (Thompson 599). An experienced user on the command line would normally be much faster than a similar experienced user utilizing a GUI. Visual interfaces force the user to go through multiple steps to query a specific set of data while a CLI achieves the same result in a single command. Audience groups ranging from users to administrators found command line to be faster and more likeable when compared to GUIs (Takayama 1393).
One example of a performance difference is with the Juniper Netscreen CLI and its respective web UI. If you want to run a simple task such as adding a static route to the firewall, in most it requires a single command"set route 10.10.10.0/24 gateway 192.168.1.1". The graphical interface on the other hand requires 4 mouse clicks to get a point where route information could be added. To get to the same endpoint as the CLI the user would have to follow this path through the web UI, "click network -> click routing -> click routing entries -> click new -> enter route information -> click gateway -> enter gateway information -> click OK." The CLI in this particular example is clearly more efficient and reduces time to execute the task greatly when held up against a GUI.
Resource management tends to favor command line in absolutely every aspect. CLIs require minimal resources because there is no requirement to leverage any extra software libraries like Java and rely on a text based interface. For example running "ps aux" on a Linux based system supporting Bourne-again Shell (BASH) shows that memory usage never registers above 1MB during usage. This small memory footprint is dwarfed by the needs of GUI counterparts such as KDE or GNOME.
Bash Memory Usage
Graphical interfaces can be very intensive due to the additional demand of drivers/software (video, etc) and processes to provide a rich interface for the user. When starting the GNOME interface there are over 20 processes that are running ranging from GNOME specific applications like Nautilus and gnome-panel which are part of the desktop core. Each process had a memory footprint ranging from a couple of KB to well over 10MB.
Gnome Memory Usage
Also a majority of web applications use Java or Flash to produce user interfaces. The extra processing load is passed on to the end user's machine through a static file that resides on the
web server and parsed by the brower.
Multitasking features in relation to a user interface is the ability to view and process multiple things at once. Some CLI's are able to provide this functionality at a rudimentary level by back-grounding displays or processes. To move between the displays it requires a combination of keyboard keys to jump back and forth. The information you are looking for may not be readily available which can be tedious moving back and forth. GUI's are able to display multiple windows and applications simultaneously for the user. It allows the user manipulate, edit, and control several windows with mouse clicks.
FreeBSD provides both a CLI and GUI (Gnome or KDE) for the end user. If you choose to run a command that will encompass one of your displays you must type Shift F1-F5 to move to a different display to perform other functions. If you are using Gnome or KDE you can have
multiple screens open simultaneously of the CLI. The GUI user will have a much easier time navigating through the displays.
The appearance of a CLI is relatively tame when seen alongside a GUI. In most cases it consists of a text based interfaces with a cursor. Some modern day CLI's leverage the text based
graphical libraries such as Ncurses to provide very rudimentary graphical interface which still maintains control through the keyboard.
Some CLI's will color code the textual interface based on file type and other characteristics which make it easier for a user to comprehend the data. GUIs on the other hand are meant to be dynamic and informative for the user. The users expect to discover and comprehend vast amounts of information through the user interface. Although it can be cumbersome at times to navigate, the layout of information tends to be easily readable and will sometimes have the functionality to export data to other formats such as CSV or PDF which is clearly lacking in the CLI. One drawback with a graphical interface is that the developers tend to change the appearance dramatically with each major release while command line tends to stay static with each new release. (Thompson 1206)
One example of a CLI that color codes the shell is the Bourne-again Shell (BASH). It will color a shell based upon an objects characteristics, therefore a directory would have a different color from an executable file. The application Wireshark is a graphical interface that is built on top of libpcap packet library to capture and decode network data for troubleshooting.
When compared to its command line counterpart, Tcpdump, it has all the same functionality with some extra features including being able to display network data in a very dynamic and friendly interface. The extra features related directly to appearance include protocol color coding and using windows to split the data across multiple sectors in the display.
BASH Color Coding
We have discussed the multiple postive and negative aspects of command lines and graphical interfaces. To create a better interface we should combine the positives and exclude the negatives to design a hybrid interface for the user. Following this approach can leverage the strength of each aspect while reducing their respective weaknesses. We can start out by using a graphical interface that can lean on the command line from basic to complex commands. The two interfaces should be tightly integrated that as any change done through either medium is immediately alerted to the user. It should also allow any graphical changes be displayed in its command line equivalent especially for novice users. It should also visualize data in an easy to read fashion that can be easily exported to other mediums. The hybrid interface should also allows users of different levels of experience to manipulate the information as they see fit. The user should essentially be able to use and customize the interface on their own terms.
Juniper NSM and Cisco ASDM are good examples of hybrid-like interfaces because they do provide a lot of the strengths of a good interface yet do lack a few key features such as in
depth multitasking and lowered resource usage. They both provide near complete access to the command line to perform system tasks through the graphical interface although some commands that require live logging such as debugging is limited in functionality. Unlike the Juniper NSM which does not have dynamic alerting, the Cisco ASDM is constantly scanning for changes by any other user or medium to provide a pop-up alert. This alert allows you to merge the latest changes into the graphical interface and displays the CLI equivalent from the modification. When performing an update with the Juniper NSM on a managed device, the interface provides an in depth description of each command line task that was completed and sent to the device. Both vendor interfaces provide a dedicated area to log data that is easily available, readable, and configurable.
Juniper NSM Cisco ASDM
Although not on the level of an operating system, both of the interfaces allow the user background jobs to be alerted when they are completed at a later time which provides a lower level of multitasking.
Developing and choosing an interface is very difficult task in which developers must know their audience and users have to relay on their experience. In this paper we have examined
a brief history of two types of interfaces, graphical and command line. We also looked at their characteristics including usability, performance, resource management, user control, appearance, multitasking, and the benefit of hybrid interfaces. We also provided real world examples of commercial and open-source products to further explanations of both positive and negative aspects of each interface. Based on the information discovered there appears to be no clear victor in the everlasting discussion of GUI vs CLI when observing from the outside in but it is a different story when you put yourself in the users shoes.
The user will always have their personal preference regardless of what is deemed best by a majority. If you take the best aspects of both interfaces and created a hybrid interface it would more than likely deemed usable to any level of user. By taking this approach we can create user interfaces that can be easily accepted by the user community.