Colas.Nahaboo.net - usability

Explicit Action Pattern keeps you in the flow

2026-04-05T00:00:00+00:00

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🔗

Explicit Action Pattern	Modal Design
Initial Search	All movie music ebook
Search results...	All movie music ebook

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:

Feature	Separate Dedicated Fields	Single Field + mode switches
Cognitive Load	Higher initial load (more to look at), unless you are already used to this UI.	Lower initial load (cleaner look), especially for novices.
Physical Effort	Lower (Click bar → Type → Enter).	Higher (Click radio → Click bar → Type → Enter).
Intent Clarity	Absolute from the moment you click.	Ambiguous until the modifier is set.
Screen Space	"Expensive"; requires more vertical/grid space.	Efficient; fits in a header.

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.

Usability issues on a payment form

2009-03-03T00:00:00+00:00

I know, I know, it is easy to nitpick on other people design, but this morning I tried to pay my phone bill online, and... failed. I had to retry many times, because I kept making mistakes on a simple, run-of-the-mill form to enter my credit card data. I was dumbfounded. How can, in 2009, people manage to make such a trivial and essential part of online business go so wrong? As I guess you are as curious as me, here is what I found out: (See the picture for the 3 main pain points)

1 the expiration date example is ambiguous: does 0903 here means 2009-03 or 2003-09 ? Why didnt they disambiguate it by also adding a specification (like MMYY, or, as it is a french dialog, MMAA ?)
2 but today, it was not only ambiguous but plainly misleading! As we were in March 2009, I assumed that the example was built from the current month and year. I said cool, so it is YYMM. Wrong! it was actually the reverse, MMYY, resulting in one failed attempt
3 ok, I filled the fields, and hit the OK button... and it just reset the page to empty fields! Grumbling, I re-typed the fields, re-clic, and... another blank page! After these two more failures, I tried to think (which is what you do not want your users to do, trust me). I then read the button label and discovered that this big, prominent button alone at the bottom of the page was not the Submit button but the Cancel one. I should have hit the middle one "Valider", but this button was not in the correct place on the flow of the form.

So,after 3 failed attempts, I managed to pay my bill. All this on a simple form with no fancy verification code or Captcha. Well done Telefact, I wonder if you can find a worse example still in use today.

What is good code?

2008-10-22T00:00:00+00:00

I stumbled upon the blog post "Is it important to write good code?" the other day, and became more and more ill at ease as I realized that I thought that I preferred the original code, that the author was trying to ridicule, over his new "improved" object-oriented version. At first I guessed this was another manifestation of the the "Worst is best" scenario - enhancements are often not worth the added complexity - but I realized that it was perhaps a more profound factor:

The original code is very good because it ... is small. It fits on a teminal screen, so an human being can read it at once and have less items to maintain in his short term memory and also understand it easily because it follows a natural way of thinking with sentences using IF. This becomes obvious by reading the body of the blog post surrounding the code samples, where you can see that the author is using phrases such as "if I need this I do that", showing that in plain english, the if statement is the best way to make people understand what you mean. And making code that people understand is the best way to make debuggable and maintainable code.

At this moment I noticed the citation in the blog header: "Good programmers write code that humans can understand"

Indeed :-)

PS: I know I am a bit exaggerating the issues there, and that I unfairly nitpick on Fredrik Normé, but it is that it seems to me from my personal experience that the two changes I see most in my coding efficiency as I grow older is a decrease of my short term memory capacity, and that I make more and more typos where I realize I mix up totally words with totally different meanings but that sound the same, for instance writing "never" instead of "nether", making me suspect that our natural way of thinking may be much more language-based that I imagined...