When designing interfaces for tools for my personal use, I have been using what I call an Explicit Action Pattern, the opposite of modal design. Due to the general trend towards minimalism of modern UI practice, it is not used a lot, but I think it should, and here is why.

Examples

As you can see in the top row, for searching an ebook, I will "flow" through the form from left to right, filling the relevant field and hitting the return key, or pressing the "Search EBook" button. But with the traditional modal design, choosing the radio button "ebook" breaks my flow of entry.

On the second row, you can see how I use this design for providing a "search again" form, where I can choose to enter a new search, or edit the previous one by selecting the relevant search box. It treats the search interface like a REPL (Read-Eval-Print Loop) rather than a static webpage. Whereas in the traditional way, I would have to break my flow to go hit the "Clear" button to empty the field.

Interaction flow

So, rather than breaking the flow of the interactions to set modes, you just flow seamlessly into branches of the decision tree. If we take a car driving analogy, you just choose a direction when encountering a fork in the road, rather than having to get out of the car to move a barrier before resuming your ride.

  

graph TD;
    User((User Interaction));

    %% LEFT SIDE: Explicit Pattern (Parallel)
    subgraph Explicit ["Explicit Action Pattern (Parallel)"];
        FormB[Dedicated Form: Search Books];
        InputB[/Input Field: Books/];
        FormM[Dedicated Form: Search Movies];
        InputM[/Input Field: Movies/];
    end;

    %% RIGHT SIDE: Modal Pattern (Sequential)
    subgraph Modal ["Modal     Design (Sequential)"];
        FormS[Single Search Form];
        %% The Vertical Spine (invisible link to keep things straight)
        FormS ~~~ InputS[/Generic Input Field/];
        %% The "Hook" - Positioned to the side
        Mode{{Mode Selection: Books vs Movies}};
    end;

    %% Explicit Connections (Direct Flow)
    User --> FormB;
    User --> FormM;
    FormB --> InputB;
    FormM --> InputM;
    InputB --> Submit((Submit));
    InputM --> Submit;

    %% Modal Connections (The Hook Flow)
    User --> FormS;
    FormS --> Mode;
    Mode --> InputS;
    InputS --> Submit;

    %% Styling from original source
    style FormB fill:#f9f,stroke:#333;
    style FormM fill:#f9f,stroke:#333;
    style InputB fill:#ccf,stroke:#333;
    style InputM fill:#ccf,stroke:#333;
    style Modal fill:#f5f5f5,stroke:#999,stroke-dasharray: 5 5;
    style FormS fill:#eee,stroke:#999;
    style Mode fill:#fff,stroke:#333,stroke-width:2px;

Benefits

This Explicit Action Pattern has many benefits for power users:

• Distributed Entry: Breaking one complex task into multiple simple, dedicated entry points.
• Parallel UI: Presenting all options simultaneously rather than hiding them behind a selection step.
• Non-Modal Interaction: Avoiding the "mode" where you have to set a state (e.g., clicking a radio button) before you can perform the actual action.

For the examples above:

This is essentially applying Functional Programming and CLI philosophy to a GUI.

• Immutability: The pre-filled field is the "original state."
• Pure Functions: Each input field has a single, predictable output.
• No Side Effects: Clearing one field doesn't break your ability to see the other.

In a nutshell, Directness over Modality.

For power users

If you are used to CLI environments, or using mostly keyboards shortcuts in interfaces, or editors like Emacs or vi, your brain likely functions on "Command-Action" pairs. And Explicit Action Patterns offers you:

• Muscle Memory: You can bind a specific field to a specific mental "slot." You don't have to check the state of a radio button before hitting enter; you know which field you are in. It transforms a two-click "hunt and peck" task into a single-click muscle memory task. You don't have to wait for an animation or look for a label; you just hit the coordinate on the screen you already know.
• No "Context Switch" Tax: Selecting a radio button is a "mode switch." It requires you to stop thinking about your search query for a second to handle the UI mechanics. Separate fields eliminate that tax.
• Visual Affordance: The label "Search Movies" is context-free, an immediate call to action. A generic "Search" box is a mystery until you look at the surrounding buttons.

In the real world

While interfaces have moved toward the "Google-style" of Modal Design to flatten the learning curve for the general public, many expert-level interfaces still rely on the Explicit Action Pattern. You can find it in library catalogs, Bloomberg or Reuters terminals, and high-end enterprise software.

You can also see this approach in media editing software. Instead of a single "Save..." dialog that asks for a format later, you often have explicit menu entries: "Save," "Export as PNG," "Export as JPG," or "Export as MP3."

And one can consider that the Unix philosophy of having one tool per function, instead of mega-commands with tons of options is also an embodiment of the Explicit Action Pattern.

Dive deeper

This approach is highly "discoverable." You don't need to learn "how the search bar works"; the interface tells you exactly what it can do by simply existing. This is what ihas been advocated by many Usability experts, that I consider mandatory reads:

• The boss: Alan Cooper books, especially About Face: The Essentials of Interaction Design.
• The enjoyable Don't make me think by Steve Krug.
• Direct Manipulation by Ben Shneiderman
• Data Density the examples above being described by him as "Parallel Input".
• The human Interface by Jef Raskin, especially his "Monotonicity": the idea that a specific goal should always be achieved by a specific, unchanging set of actions.