# Command line activity output scroll direction

When developing a command line applications, one could choose between two designs:

• put the command prompt at the bottom, and the output window above it, where responses and command history are appended at the end and which is autoscrolling down
• put the command prompt at the top, and the output window below it, new items appearing under the prompt and autoscrolling upwards

The first choice would be the traditional approach. It resembles a log file, which as a document is written from the top to the bottom, and is easier to implement (e.g. not requiring the itemisation even for multiline outputs - it just appends line after line). Often the prompt is integrated right into the same textfield that shows the output, it's not even a separate element. It's easy (mentally and implementationwise) to switch to document editing mode.

The second choice would have the most important elements - the input prompt and the most recent outputs - at the top, where they can be styled visually distinctive. This approach kinda resembles a news feed or activity stream. Each command-response pair would be an individual element appearing at the top, amidst other messages generated by the application. Twitter or Facebook - always longing for out input - work similar to this, even though they don't have commands but just can create feed items.

The only recommendation on the topic I found was to keep direction internally consistent. What else do I need to consider? Is the second approach a good idea? Has it ever been tried out for a command prompt interface?

• This question asks about "positioning a prompt", but is more about status or error notifications. – Bergi Feb 24 '18 at 1:42
• I've also tried googling whether log files should be displayed with the most recent entries at the top or at the bottom. Found a few people who had the same idea and asked how to prepend lines to a log file, but no ux evaluation. This question is mostly concerned with ASCII formatting of log lines, but not their order. – Bergi Feb 24 '18 at 1:51
• Oh, and all ascii art will be upside down. ;) – insertusernamehere Feb 24 '18 at 7:25
• @insertusernamehere I'm not aiming for just reversing lines of a traditional prompt, I wouldn't even use a fixed font. Multiline messages, including ASCII graphics, would be displayed as one item, without mirroring. – Bergi Feb 24 '18 at 7:30
• @insertusernamehere Are you suggesting that multiline additions are also reversed? :-D – gerstemout Aug 4 '18 at 11:37

If reading back and considering content in chronological order is important

Then put it at the bottom. Reading from bottom to top is awkward, at least for languages that are written from top to bottom.

If chronology is less important, like ‘recent’ or relevance-ordered content

Then put it at the top and don’t let it scroll with the content.

In my opinion.

• +1 And I would say command-line activity very definitely falls in the first category: all the way from printing-terminals, through DOS-prompts to today's Command Prompt, the convention is to read downwards to the most recent entry. OP shouldn't change that without a very good reason. – TripeHound Dec 3 '18 at 16:32

All log files that I have ever come across have the most recent entry at the bottom, it's a simple case of text processing you almost always append to a file rather than preprend. So by default text files are always ordered in a specific direction, so to keep things familiar it would make sense to always have the most recent log at the bottom for a log viewing application.

Seeing as you're using stack, for things like GHCi, the output comes after the command, but the next command is always below the output:

Prelude> 1+2
3
Prelude> let x = 42 in x / 9
4.666666666666667
Prelude>


This is similar in most of the other console style applications I've seen, e.g. Python:

Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1900 64 bit (AMD64)] on win32
>>> list(map(lambda x: x*2, [1,2]))
[2, 4]
>>>


Other examples is the Firefox console:

Here's a image of an early Lisp Machine:

• It's not supposed to be a log viewing application, it's something interactive with also a command prompt. It might not even be text-only :-) Stack etc were just examples for the generic approaches – Bergi Feb 24 '18 at 16:54
• @Bergi Yes, you can possibly ignore the log part - that was just an initial comment I started writing that got too long. The three examples I gave, GHCi, Python and the Firefox console, are all interactive prompts. Pretty much any prompt works this way, bash, dos, powershell. Perhaps I'm just not fully understanding what you're after – icc97 Feb 24 '18 at 18:06
• I know that's the established way to represent a REPL in the user interface. What I'm asking for are the UX factors that led to this convention. Is it arbitrary? Would top-prompts work just as well (or even better) and why? Having the most important, most recent items always at the top could make them easier to identify for example. – Bergi Feb 24 '18 at 18:18
• Ah, ok. You want to find reasons to challenge the existing standard. Basically you're going to have to find very good reasons to challenge is just by the simple weight of other examples on the other side. I can't think of a single example for a command prompt which has the prompt at the top. The history of this is so deep that perhaps you'll find the reasons back in the 60s when the UNIX prompt was first designed. But as a first challenge, in your reversed prompt, if someone wanted to display a list of the history of commands would you expect that list to be in reverse order? – icc97 Feb 24 '18 at 19:06
• Not necessarily find reasons to challenge it, I first want to understand what reasons led to the original design. I can come up with lots of technical reasons for implementing it like that, but what are the UX factors involved in the scrolling direction? – Bergi Feb 25 '18 at 7:49