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

A mockup of two windows with a command line, each with a few example commands, showcasing the two approaches

What are the trade-offs?

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
    Commented Feb 24, 2018 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
    Commented Feb 24, 2018 at 1:51
  • Oh, and all ascii art will be upside down. ;) Commented Feb 24, 2018 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
    Commented Feb 24, 2018 at 7:30
  • 1
    @insertusernamehere Are you suggesting that multiline additions are also reversed? :-D
    – user109724
    Commented Aug 4, 2018 at 11:37

2 Answers 2


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
    Commented Dec 3, 2018 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
Prelude> let x = 42 in x / 9

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
Type "help", "copyright", "credits" or "license" for more information.
>>> list(map(lambda x: x*2, [1,2]))
[2, 4]

Other examples is the Firefox console:

enter image description here

Here's a image of an early Lisp Machine: enter image description here

  • 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
    Commented Feb 24, 2018 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
    Commented Feb 24, 2018 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
    Commented Feb 24, 2018 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
    Commented Feb 24, 2018 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
    Commented Feb 25, 2018 at 7:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.