Separate console input field?

Question

When creating a console like window, what are the advantages of:

1. having user input in the same control as the output

2. having separate controls for input and output windows?

As I see it having separate controls is much cleaner. Countless times has it happened to me that i receive new lines mid-command and my command gets split up, resulting in me not being sure what will happen on my next keystroke (This happens to me in Win and Linux). Having a separate input box can rid the user of that problem.

For readability sake, once executed, commands can be copied to the main console window.

The only advantage of the single control approach appears to be that users are used to it.

What am I missing?

Answer 1

Advantages of single text box

As I see it, the main advantage of a single text box design is to give the user one thing to look at. With two boxes, the user has to constantly shift his/her eyes back and forth between their command text box and the main text box (between typing their entry and reading the response, or checking something they inputted previously). I personally find all the eye-shifting tiring.

A secondary advantage of a single text box is just to provide a more cohesive and direct feel to the user. By typing an input directly below a response, the users feel they’re providing direct input, and therefore having a “conversation,” (literally, if it’s a chat box) rather than working through an intermediary. It’s sort of like the difference between modifying a field by edit-in-place versus a separate “edit” dialog box (but not quite as bad).

Solving the splitting of commands

The problem you cite with a single text box is a serious one, but relatively easy to solve with smarter coding: Don’t put incoming text where the cursor is. Always insert a new line and put it there. When a user enters a character, the prompt line “freezes.” Any incoming text appears in a newly inserted line above prompt line, pushing previous lines up.

I’m guessing the main reason you don’t see this solution is due to the programmer’s over-enthusiastic emulation. Old dumb terminals, like VT100s, had the same problem, although it didn’t come up often because I/O was rarely asynchronous. However, if it were, users typically had to just live with split commands because it was difficult to put any input anywhere but where the cursor is. Doing so would require terminal-specific escape sequences, and (I think) some terminals simply lacked the capability. We don’t have such limitations today.

Another (minor) issue

Another disadvantage of the single text box design is that if users scroll up to see pervious part of the conversation, they may have to then scroll down to see their prompt before typing. However, it should be easy to code the UI so that once the user types a key, the text box snaps back to show the prompt line automatically.