Stop and Send Were Never the Same Job

Three paragraphs into an answer about two pricing models, I already had the next question. Also list the risks. Four words, ready in my hands, while the tokens were still arriving on the screen.

I typed them into the box and pressed Enter. Nothing happened. The arrow at the end of the composer had turned into a square, and the square meant Stop. The only instruction the interface would take from me was to cancel the answer I was still reading. That left two options. Sit on the question and hope I still had it in five hundred words' time. Or destroy the reply I had asked for, in order to ask what it had made me think of.

This September we gave the second question somewhere to go. In Presto Assistant, pressing Enter while a reply is in flight now puts that question in line. A queued question is the next prompt, frozen at the moment you press Enter. Frozen is the part that matters. What goes in line is a snapshot: the words, the images already attached, the sources, the model, the mode, the passage you had quoted. Edit the box afterwards and the waiting question does not change, because the ticket was issued the moment you pressed Enter. When a real answer lands, the line arms and the first ticket sends itself. Press Stop and the line pauses. So does an error, a limit, or an assistant that comes back asking you something instead of answering.

Stop and Send were never the same job. One control cannot honestly mean cancel this and send that. The cost of pretending it can falls on the person whose thinking runs ahead of the stream.

Send Became Stop Because That Was Cheaper to Build

One control is less work than two. It is also the textbook setup for a mode error. Sellen, Kurtenbach and Buxton put the condition plainly in Human-Computer Interaction in 1992. Mode errors arise when a given user's action can have very different effects depending on the state of the system. sellen-kurtenbach-buxton-1992 Press the arrow while the box is idle and you send a question. Press the same arrow two seconds later and you destroy an answer. The gesture did not change. Only the machine did. Donald Norman had already listed the fixes in Communications of the ACM in 1983, and there are only three. norman-design-rules-1983 Remove the mode, mark it distinctively, or require different commands for different modes.

Chat composers took none of them, and neither did we, for longer than I would like. The job panels in our own product still ship the old combined control, because the only composer anyone argued about was the one people think in. That is the cheap answer to the loudest question a first release faces, which is what this thing does while it is thinking. It answers nothing the person reading has asked. So the second question has to go somewhere, and there is nowhere. It waits in your head while you keep reading, which is exactly when you are least able to hold it. Or it goes into the box, where Enter swallows it. Do that three or four times and you learn the lesson the interface is teaching: stop having ideas until the machine has finished.

Waiting Your Turn and Talking Over Someone Are Different Acts

Both behaviours are defensible and the product now does both. Queuing says the answer in flight is worth protecting. You asked for it, it is still arriving, and your next thought should not cost you the one you are reading. Interrupting says something else, and it is often right. The new sentence is usually a correction, and finishing the old answer wastes your time and the model's. What turned out to be interesting was not the list. Drawing a list is an afternoon. The design question is when the line may move without being asked, and the answer is narrower than it looks: only after a reply that actually completed.

Holding the next sentence is not a discipline anyone had to learn. Levinson and Torreira, in Frontiers in Psychology in 2015, put the gap between turns at around two hundred milliseconds and the time needed to build an utterance at over six hundred. levinson-torreira-2015 The arithmetic only works if you start before the other person stops. Bögels, Magyari and Levinson caught it happening, in Scientific Reports in 2015. Planning a response begins within about half a second of hearing the part that matters, sometimes several seconds before the question ends. bogels-magyari-levinson-2015 That is what you were doing three paragraphs into the answer. It is also what the box I helped build was treating as a misclick. Fight the Line, Not the Thread was about which line you meant when you asked a follow-up. This is about when it is allowed to fire.

What the Line Cost to Build

The first plan was one sentence long: queue while streaming, send on success. Almost all of the work sat inside the word success. Clarifying questions stop the spinner without being an answer. So does a card offering to switch modes. Arm on a stopped spinner and you fire the waiting questions over a card nobody has filled in. The first message in a conversation creates the conversation, so a follow-up sent without the new thread identifier opens a second chat and splits the exchange in half. A send that fails puts the question back at the front and stops the line. Limits are checked again at the moment of sending, not only when you queue. And a waiting question is never played back into the composer, because you are probably typing question three in there.

None of that is why the bar sits above the box rather than out of sight. Altmann and Trafton, in Cognitive Science in 2002, showed that getting a suspended intention back depends on a retrieval cue that was attached to it before it was suspended. altmann-trafton-2002 A question you are only remembering has no cue attached. A question sitting in a line has one, in the place you are already looking. So the line is visible, and one preference that changes what it does is not: Queue against Interrupt lives in Settings, then Preferences, then New messages. A preference that good, buried that deep, is the same move as a one time tooltip. The work is done, the credit is claimed, and most people never meet it. There are events in the code that count queued questions and flushes. I have not looked at them, so I will not tell you what people do.

You Hold the Floor or You Don't

Enter is a speech act, and the room you are in is a conversation. When someone is mid sentence and you have something to add, you have two honest choices. You wait, holding the thought until the floor comes back to you. Or you talk over them, which is rude but clear, and sometimes necessary. Both are real acts. Both leave a mark on the room.

There is a third thing you can do, and nobody does it in a room. You can open your mouth, shape the sentence, and have nothing come out. Nobody hears it. There is no record that you tried. That is what Enter was doing while the answer streamed.

Just Interrupt It. The Queue Is Cargo Cult.

Anyone typing while tokens are still arriving has already decided the current answer is wrong, or too slow to finish. What they want is to stop it and say the better thing. A queue does not help that person; it gives them a list to manage. It brings a Review sheet, a cap of ten, pause copy, a Send next button and a bar above the box. All so someone can do what one press of Stop already did. It lies about cost as well: the second of five waiting questions can meet a limit that did not exist when it was queued. And after a cancellation, a line that restarted on its own would send the plan you had just decided against. Every one of those is a real failure mode of the thing I built. None of them is a failure mode of stop and replace.

Two things narrow it. The first is that first in, first out is a fairness rule, and fairness needs a rival. Richard Larson, writing in Operations Research in 1987, defined social injustice in a queue as violation of first in, first out, which is why skipping one enrages strangers. larson-queues-1987 A line of your own questions has no strangers in it. Nobody is disadvantaged when you send the correction first, so the product lets you. Type a question when nothing is running and it goes first, ahead of everything waiting, and the line re-arms behind it. The second is that queuing is not a habit anyone had to be taught. Stivers and her co-authors looked across ten languages for the Proceedings of the National Academy of Sciences in 2009. Every one showed the same avoidance of overlapping talk and the same short silences between turns. stivers-turn-taking-2009 People hold their next sentence constantly. They have never needed a button for it, because a human speaker telegraphs the end of a turn and an assistant telegraphs nothing.

Also List the Risks

Stop and Send were two jobs behind one control, and separating them turned the next question into something you can see waiting. An assistant that fires a queued prompt over its own question, or replays one into the box you are typing in, still taxes your turn. The test is the person three paragraphs in who types also list the risks, and gets a waiting question instead of a thought they cannot get back.