So, I was using the Ola web app recently and ran into something just… odd.
The map — arguably the most important part — was stuck in a tiny section of the screen.
- No fullscreen button
- No resize option
- No setting to change it
Just… a constrained map UI.
🤔 The Obvious Question
Why can’t I expand this?
And more importantly:
Why do I have to wait for the app to fix it?
đź’ˇ A Simple Hack
Instead of working around the UI, I decided to override it.
I wrote a small bookmarklet that:
- injects a button into the page
- expands the map to full usable size
- lets me toggle it back
No extensions. No installs. Just a click.
đź”– Why a Bookmarklet?
Because it’s the lowest-friction way to modify a live website:
- runs instantly in the browser
- no setup or permissions
- works directly on the DOM
It’s essentially a tiny user-side patch.
⚙️ What It Does
Nothing complex — just direct DOM manipulation.
👉 Repo: https://github.com/cinfinit/ola-web-bookmarklet
🧠But This Isn’t Really About the Bookmarklet
While building this, a more interesting question came up:
How do small UX gaps like this make it to production?
This isn’t a crash.
It’s not even a “bug” in the traditional sense.
It’s just… missing functionality.
⚙️ Why These Gaps Slip Through
From the outside, it’s easy to say:
- “frontend should’ve fixed this”
- “design missed it”
- “QA didn’t catch it”
But in reality, production systems are shaped by constraints:
- shipping deadlines > polish
- core flows > edge usability
- measurable metrics > subjective friction
If the map technically works, it ships.
Even if the experience isn’t great.
But should it be that way? We’ll get to that.
📉 The Problem with “Small” UX Issues
These issues are hard to catch because:
- they don’t break anything
- they don’t throw errors
- they don’t trigger alerts
- they rarely show up clearly in analytics
But they silently degrade the experience.
And over time, that adds up.
đź‘€ Who Owns This?
The uncomfortable answer:
No one fully owns these gaps.
They sit in between:
- design decisions
- frontend implementation
- product prioritization
Which makes them easy to overlook.
🛠️ How Do We Prevent This?
You can’t eliminate these issues completely — but you can reduce them.
1. Treat UX Friction as a First-Class Signal
Not everything important shows up in metrics.
- watch real user sessions
- collect qualitative feedback
- pay attention to “annoyances,” not just failures
2. Add “UX Sanity Checks” Before Shipping
Alongside QA, ask:
- “Is this actually comfortable to use?”
- “Are key interactions constrained unnecessarily?”
These are simple questions, but often skipped.
3. Build Small Internal Tools
Encourage engineers to:
- prototype quick fixes
- experiment with UI improvements
This bookmarklet is exactly that — a lightweight experiment.
4. Close the Gap Between Design and Reality
Sometimes designs look fine, but:
- screen constraints
- layout nesting
- real-world usage
…make them worse in practice.
Regularly test in real conditions, not just mockups.
5. Track “Minor” Issues Somewhere
Not everything deserves a sprint.
But having a place for:
- small UX gaps
- polish improvements
…prevents them from disappearing completely.
đź’ˇ A Different Mindset
This experience changed how I think about production apps:
The UI you see isn’t final — it’s just what shipped under constraints.
🧩 Takeaway
Not every missing feature needs a feature request.
Sometimes:
- the fix is small
- the impact is real
- and the fastest path is doing it yourself
In this case, it was just a bookmarklet.
But yes — a production fix is a production fix.
Here's how the fix looked
🚀 Try It
If you want to try the bookmarklet:
https://github.com/cinfinit/ola-web-bookmarklet
Takes less than a minute to set up.
Top comments (0)