Problem
IB should optimize the user’s actual goal, not assume that the goal of browsing is to render and inspect a webpage.
A concrete example: I already know what Larry Wall looks like. I search for a picture of him in a bright/loud 1970s-style button-up because I want to send that image to a friend who does not know what he looks like.
The visible object — an image search result — is only an intermediate object. The real task is closer to:
find representative Larry Wall image → send it to friend
A conventional browser/search flow instead tends to become:
search → Images → inspect result → open/visit source → wait → select/share → choose Messages → choose thread → send
That is several user actions and several independent waits for a task that should plausibly take a few seconds.
The architectural mistake is treating:
URL → rendered page
as the terminal success condition when the page may only be the thing that points toward the thing the user actually wants to do.
User stories
Direct action instead of forced navigation
As a user looking for something in order to do something else, I want IB to expose likely next actions directly from the result so I do not have to open the source page merely to reach the object I already found.
For an image result, useful immediate actions may include:
- share image
- copy image
- copy image URL
- send to a recent contact
- save
- open source
Open source is one possible action, not the privileged action.
Preserve the “thing behind the thing”
As a user, I want IB to represent that the object currently on screen may be an intermediate object inside a larger task.
For example, distinguish at least conceptually between:
- searching for Larry Wall images;
- wanting to look at Larry Wall images;
- finding an image in order to communicate who Larry Wall is to someone else.
IB does not need perfect intent inference. It should avoid baking in the assumption that every task is URL → webpage → read webpage.
Measure complete tasks
As an IB developer, I want performance tests to measure representative user tasks end-to-end rather than only DOM/page-load milestones.
For a task trace, record where practical:
- elapsed wall-clock time;
- number of user actions;
- number of network waits/round trips;
- bytes transferred;
- peak RAM;
- time until the first useful action is available;
- time until the actual user goal can be completed.
For this example, the important benchmark is not:
time until the source page finishes rendering
but:
time from beginning the Larry Wall search until the chosen image can be sent
Small tasks should stay small
As an impatient user, I want ordinary browser tasks to take a few seconds rather than tens of seconds.
Useful initial human-facing latency targets to test against:
< 2 s: something actionable is visible;< 5 s: ordinary small task can often be completed;10–20 s: already irritating for a trivial task;- around
45 s: effectively broken for a task of this size.
These are latency budgets and regression targets, not claims that every network operation can always meet them.
Weak hardware as a design instrument
As an IB developer, I want routine testing on deliberately weak/old hardware so expensive design decisions remain visible instead of being hidden by a high-end development machine.
Use low-end Android and, where practical, old browser-capable hardware as reference targets for:
- excessive JavaScript;
- oversized CSS/layout work;
- unnecessary image decoding;
- redundant network requests;
- framework/runtime startup cost;
- excess memory use;
- unnecessary intermediate screens.
If the interaction becomes tolerable on weak hardware, it should be very fast on current high-end hardware.
Performance regressions are UI regressions
Treat an unnecessary click, page transition, network round trip, or additional second in a common task as a real interface regression, not merely a backend implementation detail.
IB should therefore support benchmark traces shaped like:
query → useful image → share/send
rather than only:
URL → DOM loaded
Acceptance criteria
Problem
IB should optimize the user’s actual goal, not assume that the goal of browsing is to render and inspect a webpage.
A concrete example: I already know what Larry Wall looks like. I search for a picture of him in a bright/loud 1970s-style button-up because I want to send that image to a friend who does not know what he looks like.
The visible object — an image search result — is only an intermediate object. The real task is closer to:
find representative Larry Wall image → send it to friendA conventional browser/search flow instead tends to become:
search → Images → inspect result → open/visit source → wait → select/share → choose Messages → choose thread → sendThat is several user actions and several independent waits for a task that should plausibly take a few seconds.
The architectural mistake is treating:
URL → rendered pageas the terminal success condition when the page may only be the thing that points toward the thing the user actually wants to do.
User stories
Direct action instead of forced navigation
As a user looking for something in order to do something else, I want IB to expose likely next actions directly from the result so I do not have to open the source page merely to reach the object I already found.
For an image result, useful immediate actions may include:
Open sourceis one possible action, not the privileged action.Preserve the “thing behind the thing”
As a user, I want IB to represent that the object currently on screen may be an intermediate object inside a larger task.
For example, distinguish at least conceptually between:
IB does not need perfect intent inference. It should avoid baking in the assumption that every task is
URL → webpage → read webpage.Measure complete tasks
As an IB developer, I want performance tests to measure representative user tasks end-to-end rather than only DOM/page-load milestones.
For a task trace, record where practical:
For this example, the important benchmark is not:
time until the source page finishes renderingbut:
time from beginning the Larry Wall search until the chosen image can be sentSmall tasks should stay small
As an impatient user, I want ordinary browser tasks to take a few seconds rather than tens of seconds.
Useful initial human-facing latency targets to test against:
< 2 s: something actionable is visible;< 5 s: ordinary small task can often be completed;10–20 s: already irritating for a trivial task;45 s: effectively broken for a task of this size.These are latency budgets and regression targets, not claims that every network operation can always meet them.
Weak hardware as a design instrument
As an IB developer, I want routine testing on deliberately weak/old hardware so expensive design decisions remain visible instead of being hidden by a high-end development machine.
Use low-end Android and, where practical, old browser-capable hardware as reference targets for:
If the interaction becomes tolerable on weak hardware, it should be very fast on current high-end hardware.
Performance regressions are UI regressions
Treat an unnecessary click, page transition, network round trip, or additional second in a common task as a real interface regression, not merely a backend implementation detail.
IB should therefore support benchmark traces shaped like:
query → useful image → share/sendrather than only:
URL → DOM loadedAcceptance criteria
search/find object → act on objectwithout requiring source-page navigation.open sourceavailable while allowing direct actions on already-discovered objects.