Program output interpretation

From LQWiki
Jump to navigation Jump to search

Here, some of the programs whose output are difficult to interpret for infrequent users are discussed. If possible , the underlying cognitive processes are identified and using tools,like vi, how we can overcome that.

These are programs that can be considered to provide statistical information like netstat, ps, last, lsof etc.

Typical format of the program output is rows of information. The meaning of each column is given by the first header row, that gives a kind of tag for each column.

User interface problems

Typical user interface problems encountered in dealing with these ouputs are.

1.Many times the length of a row exceeds 72 chars and wraps to the next line, distorting the column alignment and readability.

2.Inspite of the line filtering by grep, if the number of lines execeed the 23 lines of screen size, if the row of interest comes in second screen or later. Interpreting the columns becomes difficult.Because there is no header row in the visibility of the row of interest, to interpret its column values.

3.Even if the header line is visible, the column tag, is not sufficient to interpret the column value, more information regarding the column tag is needed.

For example consider

 netstat -apn | less
    or
 ps -aefl | less

Now let us see how a infrequent user tries to interpret the output with these U.I problems.

Process flow

This is how the typical process goes:-

The user has some key values like "Program names or port numbers" and he will be looking for rows that contain this.Let us call it "rows of interest".User has this key values at the start in his mind's working memory.

Implication of Wrapping:-

When the user scans for "rows of interest", if there is wrapping of rows, it increases the mental effort of "scanning" because each new line does not corresponding to a row, it may be wrapping of previous line.

Implication of header row getting scrolled.

when the user arrives at his row of interest, if it is in second page or more, the header row is not in visibility to interpret the columns. The user pages back to the first page to see the header row.Now the user is forced to remember that "2nd column" correspongs to "this" and "5th" column correspond to "this". Assuming the user needs to interpret 3 such columns. He starts to load his working memory with this info.Assuming he needs to interpret 3 such columns, that are not consecutive, it is a clear overload of his working memory.

Now when he scans down again to reach his row of interest(He may not have registered in which page his row of interest occurred). By the time he reaches his row of interest, he would have forgotten the association, he made. More precisely, the information would no longer be available in his working memory either because it is too much to hold or too long to hold.

The user may try to repeat this exercise and if he fails for second time, may feel frustrated and if there is GUI alternative, would switch to that and would inferr that "CLI sucks".

Process flow (frequent user)

Frequent user would have encountered the need to process the program's output in a variety of context with varying amount of output information. With single page of ouput, multiple page etc.This column association of "which column corresponds to what" would have got "registered" in his "long-term memory" because of frequent use. So he would retrieve this "column association" from his long-term memory and not over-load his working memory.Even if he gets into this exercise, he may be interested to find out for one column, rest of the needed ones would be fetch from his long-term memory.The user feels "he just knows or remembers".

Broader picture

We can see similar situation happens in other contexts too. CLI most of the times during it use, expects/forces the user to know/remember some information. Frequent users typically access this information from their long-term memory which because of the high frequency of use would have got registered in their long-term memory.

Infrequent users are forced to keep this information in their working-memory, after getting it from another source. Most the times, it over-loads the working memory.

GUI world

Let us see how this U.I problem is dealt in GUI world.

1. The rows will appear in a separate region. Horizontal scrolling takes care of lengthy rows and avoid wrapping.
2. During scrolling, only rows scroll and not the header line describing the columns .

Solution in CLI world

There might many solutions.But the author could just find this one and seems to apply in many contexts.

The solution is to use vim as PAGER, instead of less, more etc.

How to solve this in vim.

Invocation

 netstat -apn | vi - 
    or
 ps -aefl | vi - 

To avoid wrapping

:set nowrap

Horizontal scrolling

Use Horizontal scrolling feature of vi

To have Header row visible near row of interest

Fold rest of the lines between row of interest and header row
Mark start row as "a" and end row as "b"
:'a,'bfo 
will fold
To reduce visual clutter
set foldtext=none

To compare columns that are not consecutive

[[ VIM experts please add if there is a way to do column folding
like row folding]]

See also