Szymon Kaliski

Dialog in UI

Think of the way a new library user might interact with a reference librarian. A librarian who had a command-line interface would understand only a limited number of grammatically perfect queries, and the novice user would have to consult an obscure reference manual to learn which queries to write out. A reference librarian with a WIMP interface would have a set of menus on his or her desktop; the user would search the menus and point to the appropriate query. Neither interface seems very helpful. Instead, real reference librarians talk with the user for a while to negotiate the actual query. Similarly, we envision a computer interface that utilizes a thesaurus, spelling correction, displays of what is possible, and knowledge of the user and the task to take part in a negotiation of the user's command. We could imagine, for example, a dialog in which the user makes a free-form request, the computer responds with a list of possible tasks that seem to match the request, and both engage in a dialog to focus on the request the user actually intended.

— https://www.nngroup.com/articles/anti-mac-interface/ ↗

• the idea is to allow the system and the user to converse and figure out the question and answer together
• this reminds me of the idea that APIs should somehow figure out together the common protocol together (instead of relying on the programmer to do the mapping)
  • this is what happens in biology/evolution - animals learn that eating this other yellow-red bug leads to death, so they don't do it (well they don't really "learn" that, the ones that don't eat them have more chance of surviving over time)
• this seems related to CLI UX where the UX is not only useful in terms of seeing past commands, but also a way to issue new ones - a CLI that could feel less robotic, less like a single-line program, and more like a discussion with the computer
  • a history of operations could impact the next proposed subset of operations to the user

It would be great if the machine improvised more automatically with me, instead of me actively playing every chord.

— https://dcgross.com/autopilot-software ↗

• currently UIs require users to "play every chord", while "improvisation" would be like a conversation, similarly to how the open-ended "browsing" works like
• interestingly "dialog" is used as a concept for exchanging messages with the OS:

  This same dialogue concept can be found in Haskell 1.0 Stream-based I/O, where type Dialogue = [Response] -> [Request] is the model of interaction with the Operating System. [Response] is a stream (lazy potentially-infinite list, to be more accurate) of messages from the OS, and [Request] is a stream of messages to the OS.

  — https://cycle.js.org/dialogue.html#dialogue-abstraction ↗