In the past we have seen the development of software according to new concepts in computer science. From the end of the 1960s/beginning of the 1970s when computers became available till now, we can distinguish several phases. In the beginning we had non-interactive, batch oriented software packages, e.g. SAS and SPSS. The idea of incremental programming and interaction lead to systems like PRIM-9 ([29], [30]) or programming languages like BASIC. Another paradigm was that the notation used should be compact, like in languages as in APL or C. The availability of personal computers with window systems introduced graphical user interface (GUI) in contrast to command line interfaces (CLI) also to statistical software packages. As mentioned in the interview with J.E. Gentle ([10]) statistical software packages nowadays should come with both interfaces. During the last fifteen years we saw that team programming, reusability of software, network/internet computing and access to databases had their impact on programming languages (ADA, C++, Java, SQL) as well as on statistical software packages like S/S-Plus, R, XploRe, Jasp, etc.
Before we start to develop a statistical software package and a user interface (GUI or CLI), we should think about the kind of problems a user may have:
The first problem can not be solved with a better interface design, but so can the latter three ([8]). We have two ways to solve them: either we make a better user interface or the user has to spend a lot of time for learning about the interface. One of the most time consuming design error is a subtle inconsistency, for example if the parameter orders for nearly identical actions, either in formulas for GUIs or commands in CLIs, are different. The user will always loose time to look up these subtle differences.
Obviously we can not develop one user interface for all users. The slogan Know your user ([9]) in detail (statistical background knowledge, cultural background, etc.) is an important building block to the success of a (statistical) software package. We can distinguish three types of users: novice users who need to execute a small set of simple exercises and need an informative feedback from the software package. Periodic users who need support for forgotten execution sequences and need to know how to extend the current software package. But they usually need only a short feedback to an executed task. A power user is mainly interested in fast answers and needs only very limited feedback. Some statistical software packages, XploRe and R offer even multiple GUIs for different types of users.
However, basic guidelines for all user types are:
![\includegraphics[width=12.3cm]{text/2-12/fig.1.eps}](img3167.gif) |
For novice users it is clear that they prefer software with GUIs (see Temple, Barker and Sloane, Inc., [26]), but for power users this is not quite clear, see [31]. There are some general drawbacks of GUIs:
A look at Fig. 12.1 shows the entry screens of different statistical software packages. Here we find all elements forming a modern GUI: menu bar, toolbar(s) and multiple windows. Note that a statistical user interface is more than a GUI: design of the programming language, help system, basically every aspect in the interface between a user and a statistical software package.
Some packages try to help a novice user with his next task. SPSS opens, after starting the program, a dialogue box to load a dataset (see Fig. 12.1b). For R, which can load all data objects from previous sessions automatically, such feature is not necessary.
Although toolbars play a more and more important role in software nowadays, we immediately notice the sparse toolbars (see Fig. 12.2), due to the fact that we have no common set of icons. For example GGobi and DataDesk do not offer any toolbar, XploRe, SPSS and R offer only toolbars related to standard tasks, like opening, saving and printing programs, images etc. and specialized software functions. Among the considered programs only SYSTAT offers toolbars for standard statistical graphics (histogram, pie chart, boxplot, scatterplot and scatterplot matrices) and tasks (descriptive statistics, two-way-tables, two-sample t-test, ANOVA, correlations, linear regression, clustering and non-linear modeling). But to learn the meaning of the icons may take some time.
![\includegraphics[width=11.2cm]{text/2-12/fig.2.eps}](img3168.gif)
|
The first parts of a software package we use are the menu bar, the
menus and the menu items. Menus can give a clear structure to the
methods/actions of a software package. [13] have found
that a proper organization of the menu reduces the error rate to about
. Most statistical software packages have a very clear
separation of the tasks in the menu bar (see Fig. 12.2).
It might be distracting if the position of the menu items changes ([18]). For unused menu items (not applicable tasks in the current situation) it is preferable if they are grayed out and do not vanish from the menu. Statistical software packages behave very differently. The menu bar in XploRe and R changes heavily depending on the active window which can be very disturbing to the user. It would have been better to attach an appropriate menu to each window. Also in GGobi the menu changes depending on the active window: compare Fig. 12.4a to Fig. 12.2a. Nevertheless this is less disturbing to the user because additional menus appear only once in the menu bar and heavy changes take place in the items of the Display menu which are invisible to the user. The menu Display is empty after starting GGobi, but filled when a dataset is loaded.
If we create a menu hierarchy we basically have two possibilities to organize them: a small, deep hierarchy or a broad, flat hierarchy. [19] found that broad, flat hierarchies lead to a better user performance. Most software packages follow this concept intuitively, none of the software packages has a menu depth larger than four.
Several orders of menu items within menus are possible: by time, by numbering, by alphabet, by importance or by function. [2] found that an alphabetical order of menu items is better than a functional order. [16] showed that the advantage of the alphabetical order is lost if each menu item consists of a one line definition rather than of one meaningful known word. Nowadays all statistical software packages prefer a functional order by separating the menu items with horizontal lines into menu item groups. But within a menu item group the order is unclear.
To achieve consistency within a menu system, the same terms should be used. If we use one word items then they should be clearly separable, like ''insert'' and ''delete''. The exact difference between ''change'' and ''correct'' is unclear. Cyclic menus, which means we can achieve the same task by different ways through the menu hierarchy, should be avoided. Users become unsure where to find a specific action; the same problem is well known from the World Wide Web.
The approach to put the most used menu items at the top and suppress the others, may irritate the user. The irritation occurs not with the most used items, but with the items which are used less often. Their position appears to be more or less randomly. Thus, [22] found that bringing only the most used items to the top of the menu is an effective technique.
For power users shortcuts, e.g. through keyboard sequences or toolbars, are very important. Often used menu items should get short shortcuts, e.g. Ctrl+O for open a data set, whereas rarely used shortcuts can have longer keyboard sequences. Most statistical software packages offer only the standard shortcuts coming from the Windows operating system; only GGobi offers shortcuts for different view modes. Unfortunately, we have no common sets of shortcuts for a (statistical) task. We have not even a common naming convention for menus, e.g. the statistical tasks are in the Calc menu in DataDesk, in the Statistics menu in SPSS and in the Analyze menu in SYSTAT.
For an effective menu system design it is helpful to log the user choices and to analyze them for improvements.
The use of menus leads to another form of interaction with the user: forms and dialog boxes. Basically they should
Here, a very good example is SPSS. See as example in Fig. 12.3 four out of six steps for reading ASCII data into SPSS. The six dialog boxes are grouped in information about:
![\includegraphics[width=12.5cm]{text/2-12/fig.3.eps}](img3170.gif) |
The forms always provide default values, show the consequence of changing a value in the bottom and allow easy navigation between forms forward and backward. We can cancel the whole operation or finish it at any time. The last form gives a clear signal when we are finished. The SPSS developers have designed all these forms and dialogs very carefully.
However, we have to keep in mind that pure statistical programming languages, like R or XploRe, will have to incorporate forms and dialog boxes in their programming language. This turns out to be a difficult task.
Usually statistical software packages use different windows to visualize data and output. Figure 12.4 shows a scatterplot of the variables ''percentage of lower status people'' and ''median houseprice'' of the Boston Housing data ([11]). We easily find that the software packages have different methods to handle output. SPSS and SYSTAT have a special independent output window for text and graphic output. DataDesk, R (by default) and XploRe use the multiple document interface (MDI) coming with the Windows operating system. Actually R allows to switch between different types of handling windows (MDI/SDI). GGobi creates a complete set of independent windows.
![\includegraphics[width=12.1cm]{text/2-12/fig.4.eps}](img3171.gif) |
In GGobi and DataDesk the data in the windows is linked (see Fig. 12.5a). Thus interactive brushing is very easy.
A problem of some statistical software packages is that the user can easily create a lot of windows, see in Fig. 12.4 and even worse in Fig. 12.5 for DataDesk. But a large number of windows can easily irritate the user. Statistical software packages have tried to overcome this problem with different approaches: having separate graphic types, for example the scatterplotmatrix in SPSS or trellis displays in R; XploRe has a datatype for a graphical display which consists of single plots. The idea is always the same: statistical information that belongs together should be in one window. Another strategy is a virtual desktops (see the software package VanGogh in Keller, [12]) as we find them under Linux GUIs.
Power users prefer full-screen views (see Bury et al., [1]). Note that in Fig. 12.5 we tried to maximize the size of the graphics in R, SPSS and XploRe. SPSS and SYSTAT follow partially such a strategy with separating clearly between spreadsheet presentation of data and variables and output results. But [25] has shown that users work faster with compact information on one screen rather than to scroll.
The grouping of information in a window plays an important role in GUI
design. [7]
developed an effective forecasting model for the time 
for
a movement over a distance 
to an object with width 
 |
and 
.
Maybe approaches like ''The CAVE'' ([5]), a virtual reality environment, will lead to more screen space.
The question of the contents of the windows is related to showing windows. Tufte ([27], [28]) has shown proper and improper use of statistical graphics (see also Chap. II.11). Modern statistical techniques, like data mining, but also exploratory data analysis, has lead to principles of analysis like get an overview, zoom, select and look to details.
The productivity
of a user depends heavily on the response time of a software package
to a user action. To achieve a good productivity we have to balance
between the speed of working and the error rate. Fast response times
(
sec) lead to faster user work. Fast working increases the error
rate because the user does not think much about the current action
since he is concentrated on the responses from the software
package. Slow response times (
sec) lead to slower user
work. Slow working decreases the error rate because the user has time
to think about the next action. But if he makes a mistake he will
loose time.
The right amount of the response time depends also on user
experiences, e.g. if he sees that one software package reads a large
dataset in 
seconds whereas another software package needs
minutes for the same dataset then he will assume something has
gone wrong. A power user is generally more impatient than a novice
user. A partial solution to the problem of slow response times is
a progress bar
which shows how much time it will take till the end of the action.
Generally a user expects that simple actions, e.g. reading a small
dataset, are done fast and complex actions, e.g. building a model from
a large dataset, can take much longer time. The study of
[15] found that the response time for a complex statistical
task does not matter much for productivity, whereas the response time
for a simple task (entering data) is linearly related to
productivity. A variation in response times (
) does
not matter much. In a set of mixed tasks the user balances out: he
thinks about the task when the response time is slow and works fast if
the response time is fast.
In Fig. 12.4d we see that in SYSTAT the data editor stays on top, although we just created a scatterplot in the underlying output window. But the user attention is still directed to the data editor. Similar problems can be observed in other software.
Another point in GUI design we should consider is the way how we catch the attention of the user. In statistical graphics Tufte ([27], [28]) has shown how the user's attention can be redirected from the data. In the same manner a too colorful GUI may distract the user. [32] analyzed how to catch the users attention and gave some hints:
different fonts
with 
different sizes in 
intensities
standard colors,
more colors have to be used with care
Nowadays operating systems offer a large variety of true-type fonts, nevertheless most people use only a few fonts in their documents.
Especially the use of colors may create special problems. First,
different user may combine different reactions to the same color
(cultural background); second, it is known that in Europe and North
America 
of the population have problems in recognizing
a color correctly. The largest problem here is the red-green
blindness,
both colors appear grey to such people.
The use of sound should only be an additional option. During teaching or when working in PC-Pools it will distract other users.
In the beginning of the computer age all programs only had CLIs. One of the largest statistical software packages which has survived from these times, SPSS, still has a CLI. But it is hidden by a GUI and we can reach it via SPSS syntax editor. Statistical programming languages, like R and XploRe, are more like CLIs embedded in a GUI. Only statistical software packages like GGobi and DataDesk are real GUI software, but even DataDesk has a (visual) programming language.
In the recent past we observed that statistical packages like R or XploRe have a tendency to be split up between a GUI and a CLI. In fact on the R-Project page we find more than one GUI for R.
CLI provides some advantages compared to a pure GUI. Some manipulations, for example arithmetic transformation of data, can be done much faster with the keyboard than with the mouse.
With a programming language we can achieve a precise and compact way to manipulate and analyze data. We should be able to easily learn, read and write the programming language. Some problems that can arise are
Modern statistical programming languages implement matrix algebra
since we can easily transfer expressions, e.g. for computing the
coefficients of a multiple linear regression, like
into a program (in XploRe:
inv(x'*x)*(x'*y)). This allows for fast error correction and
fast learning.
[3] found that hierarchical (verb-object-qualifier) and symmetric command sequences, like in Table 12.3 for linear regression, lead to the best user performance and can be easily learned and remembered. The reality in software packages is shown in the Table 12.2.
Again power users prefer rather short names whereas novice users can find actions with long names more informative. It is the best to have both available, like DoLinearRegression and DoLinReg or even dlr. [6] suggest rules to make (automatic) abbreviations and [21] proposes possible abbreviation methods:
Modern editors, e.g. the Visual Basic editor in Microsoft Office, support the writing of programs with semi-automatic command completion.
| Software | Example | Error message |
| XploRe | proc()=test(x) | Syntax Error |
| if(x=1) | in test line: 2 | |
| "true" | Parse Error | |
| else | on position 5 in line 2 | |
| "false" | ||
| endif | ||
| endp | ||
| test(0) | ||
| R | if (x=1) "true" else "false" | Error: syntax error |
| SPSS | as in Table 12.2, just /DEPENDENT changed to /INDEPENDENT | |
| Warning | ||
| Unrecognized text appears on the REGRESSION command. The only | ||
| recognized subcommands are: Global options: DESCRIPTIVES MATRIX | ||
| MISSING WIDTH; Case selection/weight: REGWGT SELECT; | ||
| Variable list: VARIABLES; Equation options: CRITERIA NOORIGIN | ||
| ORIGIN STATISTICS; Dependent variable(s): DEPENDENT; | ||
| Equ. methods: METHOD BACKWARD ENTER FORWARD REMOVE | ||
| STEPWISE TEST; Residuals: RESIDUAL CASEWISE PARTIALPLOT | ||
| SAVE SCATTERPLOT OUTFILE. Text found: INDEPENDENT | ||
| This command is not executed | ||
| *WARNING* REGRESSION syntax scan continues. Further | ||
| diagnostics from this command may be misleading - interpret | ||
| with care Misplaced REGRESSION METHOD subcommand - The | ||
| METHOD subcommand must follow a DEPENDENT subcommand | ||
| or another METHOD subcommand. It cannot follow any other | ||
| subcommand. Check for a missing DEPENDENT subcommand. | ||
| Text found: METHOD | ||
A future dream is that (statistical) software understands natural language. What has proven to be valuable to the user is the generation of a report of results in natural language.
![\includegraphics[width=12.1cm]{text/2-12/fig.6.eps}](img3181.gif) |
The most crucial response for a user is an error or warning message from the system. Error messages can be not very helpful, e.g. in XploRe or R syntax error in Table 12.4. A better solution would be to tell the user what the problem exactly was (use x==1 instead x=1). But SPSS tells the user too much and the problem disappears behind the text. However, the ability of SPSS for abbreviating is impressive. From the linear regression example in Table 12.2 the parameter /NOORIGIN can be shortened to /NOO. Further shortening to /NO produces an error message.
![\includegraphics[width=12.1cm]{text/2-12/fig.7.eps}](img3182.gif) |
The language in an error message and warning should be positive,
constructive, meaningful and precise. [23] found
in a study that the error rate could be reduced by 
with
well constructed error messages.
Again it is a good idea to log the error message to see which ones are needed to be improved and which parts of the software package has to be improved.
Nowadays software is always accompanied with online help systems and tutorials, mostly HTML-based. A help system should give the user quick access to the information he needs. Depending on the type of users, they have different approaches to use a help system. Reference or alphabetical guides are useful for power users, but novice users learn most from a lot of examples. Consequently the help system of modern statistical software is mostly composed of several parts: reference/alphabetical guide, introductory tutorials, indices and a search engine.
In Fig. 12.6 we see the entry page of help systems. The variation in the software packages is large, from very sparse help systems upto detailed explanations how to use the help system.
Finding information in the help system is a crucial task. Thus good navigation, indices and search are essential for any help system. Help systems based on the windows help system, e.g. used by DataDesk, bring already the capabilities for an index and searching. Creating a good index, for a book or a help system is not easy. Especially since the developers of statistical algorithms mostly do not care much about the documentation. The quality of the help system depends heavily on the contributors to it. Maybe automated ways of analyzing tutorials and descriptions to create a hierarchy and an index can improve the help system quality.
One of useful help systems that we have seen is the help system of Mathematica which is an inherent part of it. At the top of Fig. 12.7d we see the detailed navigation, we know always where we are. Mathematica separates the information well: red background for Mathematica commands and programs and their descriptions, white background for explanations.
Generally, help systems and tutorials should have a simple language, short sentences ([20]) and a consistent terminology. This has been proven more helpful to the users and most help systems follow that suggestion. It is even more important since most help systems and tutorials are written in English and the majority of the statisticians do not speak English as native language.
![\includegraphics[width=12.1cm]{text/2-12/fig.5.eps}](img3175.gif)
lstat)