Types of User Interfaces: Choose for the Task
Graphical, command-line, touch and voice interfaces are ways of expressing interaction, not a ranking from old to new.
- Author
- absequ
- Published
- Updated
- Category
- UI and UX
- types of user interfaces
- ui and ux
- practical guide
Graphical, command-line, touch and voice interfaces are ways of expressing interaction, not a ranking from old to new. A system may offer several at once. A developer might automate a task through a command line and inspect its result in a graphical dashboard. Good design chooses the interaction model that fits the task and the user's context.
On this page
The mental model
Graphical interfaces make available choices visible through controls and spatial relationships. Command interfaces can make repetitive work reproducible and composable, but demand clear syntax, discoverability and error messages. Touch is an input capability used with many graphical interfaces, not proof that a device lacks a keyboard or pointer.
Voice interaction can reduce the need for visual attention but creates challenges for privacy, recognition errors and confirmation. Do not move an irreversible action into a speech command without a reliable way to review the intended result. Multimodal interfaces should preserve task meaning as people switch input methods.
A practical workflow
Start with task frequency, complexity and error cost. A one-off enquiry usually benefits from a labeled graphical form, while a repeated file-processing task may benefit from an automation-friendly command. Offer a safe preview or confirmation where the consequence is significant.
Define the same underlying operation independently of its presentation. If a web page and command-line client both create a record, they should call a service with the same authorization and validation rules. Duplicating business logic in each interface creates inconsistent outcomes and can create a weaker security path.
Worked example
Task: submit a deployment request
Graphical path: choose environment → review diff → confirm
Command path: deploy-request --environment staging --dry-run
Shared server contract: authenticate → authorize → validate → record request
Result: a request identifier and a truthful status, not an assumed deployment
The command illustrates interface design; it is not an installed tool.This sketch separates intention from execution. A dry-run mode needs a precise contract: does it merely validate input, or also inspect remote state? A command should return a useful exit status, and a graphical interface should make success and failure equally understandable. Both should expose a stable request identifier for authorized troubleshooting.
Accessibility depends on behavior, not the interface label. A graphical page can work well with a screen reader and keyboard. A command interface can be difficult if output has poor structure or relies on color alone. Test the actual tasks using the tools and capabilities your users rely on.
Failure modes and security
Do not assume that a voice, touch or terminal interface is automatically easier or safer. Consider noisy environments, shared screens, limited dexterity and intermittent connectivity. Provide a recoverable path when an input method fails, and do not require one modality where an equivalent accessible alternative is practical.
Avoid embedding secrets in command arguments or visible interface histories. Masking a password on a form does not address how it is transmitted, logged or stored. Review information disclosure and authorization for every supported client rather than assuming an internal-looking interface is trusted.
Practice and verification
Choose a common task and outline graphical and command-based versions. Identify which validation and authorization belongs in the shared service, and which feedback belongs in each interface. Try both with a new user and an experienced user. Explain the tradeoffs using the observed task, not stereotypes about users. Preserve a clear confirmation for consequential actions and a machine-readable result for automation where it is appropriate.
References
WAI interaction patterns — W3C
Command Line Interface Guidelines — Command Line Interface Guidelines
MDN input elements — MDN