Forem: Snowball

Our Attention Span Is Now Shorter Than a Goldfish's. So I Built a Chrome Extension

Snowball — Tue, 28 Apr 2026 12:10:05 +0000

Every Site Blocker Uses a Static List. So I Built One That Doesn't.

Every site blocker on the Chrome Web Store works the same way: you create a blocklist upfront, and it blocks those sites. I tried several — they all hit the same wall.

So I built Dynamic Site Blocker, a session-based blocker that asks you "Block or Allow?" the first time you visit each site during a session. No pre-made lists. No configuration. Just a decision in the moment.

👉 Chrome Web Store
👉 GitHub

The Problem: Distraction Is Structural

Getting sidetracked during work — opening a random site during an idle moment like waiting for an AI response, then losing 10-20 minutes — is something most developers have experienced.

This isn't a willpower problem. It's an environment problem.

Research by Gloria Mark at UC Irvine shows that the average time a person focuses on a single screen dropped from 150 seconds in 2004 to 47 seconds in 2024 (Mark, 2023). On top of that, it takes an average of 23 minutes and 15 seconds to get back to a task after an interruption (Mark et al., CHI 2008).

Trying not to get distracted is unrealistic. Building an environment that makes distraction harder is the practical approach.

The Static List Dilemma

Existing blockers — StayFocusd, BlockSite, Cold Turkey, LeechBlock, you name it — all rely on static lists. You decide what to block before you start working. This creates a fundamental dilemma:

❌ Too strict → blocks what you need. YouTube has tech talks. Twitter has industry news. What counts as "distraction" changes with every task.

❌ Too loose → useless. You can't predict where you'll end up. A link from Hacker News leads to a blog post, and 20 minutes vanish. If it's not on the list, the blocker can't help.

❌ Per-task presets → management overhead. Creating and maintaining presets for different work contexts becomes a task in itself.

The problem wasn't which sites to block. The problem was deciding upfront at all.

The Solution: Decide on the Spot

Dynamic Site Blocker takes a different approach:

1. Start a session — Click "Start Session" from the extension popup.

2. Decide per site — The first time you visit any domain during the session, a Block/Allow overlay appears. That's it — just one question: "Do you need this site right now?"

3. Blocked sites stay blocked — Blocked domains redirect to a custom block page with randomized humor messages (14 variations) and an attempt counter.

4. Session end = full reset — Hit "End Session" and all decisions are cleared. Next session starts fresh.

Static list:    Pre-build list → Block → List management becomes work
Dynamic:        Start session → Decide on the spot → Reset on session end

Accidentally blocked something? Unblock it from the popup. Let something through that you shouldn't have? Block it retroactively. Both directions work.

Competitive Landscape

Before building this, I searched the Chrome Web Store thoroughly. Every blocker I found used static lists, timers, schedules, or some combination.

A session-based blocker that prompts you interactively on first access did not exist. (As of April 2026)

Unexpected Benefit: Metacognitive Training

Something I didn't anticipate: being asked "Do you need this site right now?" on every first visit turns unconscious browsing into conscious decisions.

That one-second prompt is surprisingly effective. Sometimes you don't even need to click Block — you realize you have no reason to be there and close the tab yourself. The blocker didn't stop you. You stopped yourself.

This makes it less of a blocker and more of a self-awareness tool. The ideal outcome is not needing it at all.

Technical Notes

The entire extension is 13KB. Here's what's under the hood:

Manifest V3

Built on Manifest V3 with a Service Worker backend. No persistent background page.

declarativeNetRequest (redirect)

Blocking uses chrome.declarativeNetRequest session rules — processed natively by the browser with zero JavaScript overhead. Blocked domains redirect to a custom block page.

chrome.declarativeNetRequest.updateSessionRules({
  addRules: [{
    id: ruleId,
    priority: 1,
    action: {
      type: "redirect",
      redirect: { extensionPath: "/blocked.html" }
    },
    condition: {
      urlFilter: `||${domain}`,
      resourceTypes: ["main_frame"]
    }
  }]
});

Session rules auto-clear when the browser closes — a natural fit for session-based blocking.

chrome.storage.session

Session state (blocked/allowed domain lists, session flag) persists across Service Worker restarts via chrome.storage.session.

Block/Allow Overlay Injection

First-visit detection combines chrome.webNavigation.onCompleted and chrome.tabs.onActivated. The overlay is injected via chrome.scripting.executeScript.

Wrapping Up

If the problem is defined correctly, the solution can be simple.

If the issue is "deciding upfront," the fix is "decide on the spot." ~200 lines of code solved a problem that no existing blocker addressed.

👉 Dynamic Site Blocker - Chrome Web Store
👉 GitHub

Feedback, feature requests, and issues are all welcome.

References

Mark, G. (2023). Attention Span: A Groundbreaking Way to Restore Balance, Happiness and Productivity. Hanover Square Press.
Mark, G., Gudith, D., & Klocke, U. (2008). "The Cost of Interrupted Work: More Speed and Stress." Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '08), pp.107-110.

Why "USED" Condition Fails in eBay Inventory API (Action Figure Category)

Snowball — Sat, 19 Jul 2025 04:59:53 +0000

Background

In the Action Figure category on eBay, the listing UI only provides two condition options:

NEW and USED.

However, when creating a SKU using the eBay Inventory API, specifying "USED" directly causes an error.

Root Cause

According to eBay's API specification, the enum value "USED" does not exist.

UI Label → "USED"
API Expected Value → "USED_EXCELLENT" (Condition ID: 3000)

So, to reproduce the UI’s “USED” condition in the API, you need to use "USED_EXCELLENT" instead.

References

❌ Example: Fails with `"USED"`

curl -X PUT 'https://api.ebay.com/sell/inventory/v1/inventory_item/test-sku-001' \
  -H "Authorization: Bearer DUMMY_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "condition": "USED",
    "product": {
      "title": "Dummy Action Figure",
      "description": "Dummy description for an action figure item.",
      "imageUrls": ["https://dummyurl.com/dummy-image.jpg"]
    },
    "availability": {
      "shipToLocationAvailability": {
        "quantity": 1
      }
    }
  }'
\```
{% endraw %}



### Error Response

\
{% raw %}
```json
{
  "errors": [
    {
      "message": "Could not serialize field [condition]"
    }
  ]
}
\```
{% endraw %}


## ✅ Example: Success with {% raw %}`"USED_EXCELLENT"`

\
{% raw %}
```bash
curl -X PUT 'https://api.ebay.com/sell/inventory/v1/inventory_item/test-sku-001' \
  -H "Authorization: Bearer DUMMY_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "condition": "USED_EXCELLENT",
    "product": {
      "title": "Dummy Action Figure",
      "description": "Dummy description for an action figure item.",
      "imageUrls": ["https://dummyurl.com/dummy-image.jpg"]
    },
    "availability": {
      "shipToLocationAvailability": {
        "quantity": 1
      }
    }
  }'
\```
{% endraw %}


Now the **USED** listing works correctly via API.

## Summary

- In the Action Figure category (and similar), the **UI only shows "New" and "Used"**, but...
- The eBay Inventory API **does not accept {% raw %}`"USED"`{% endraw %}**.
- Instead, use {% raw %}`"USED_EXCELLENT"`{% endraw %} (Condition ID {% raw %}`3000`{% endraw %}) when listing as used.
- Therefore:
  - New item → {% raw %}`"condition": "NEW"`{% endraw %}
  - Used item → {% raw %}`"condition": "USED_EXCELLENT"`{% endraw %}
- This mismatch stems from eBay’s internal {% raw %}`ConditionEnum`{% endraw %} design and is **not clearly documented**, making it a common source of confusion for developers.

Why PDCA Often Fails — And How GP-PDCA Can Fix It

Snowball — Sat, 19 Jul 2025 04:56:09 +0000

Introduction

Have you ever followed the PDCA cycle (Plan-Do-Check-Act) and still ended up with no tangible results?

You’re not alone.

The truth is: PDCA is a powerful framework — but only when used in the right context, with the right starting point.

Too often, people jump into the "Do" phase without clarifying what they're really trying to achieve or solve.

That’s where my original framework GP-PDCA comes in.

What's Wrong with PDCA?

PDCA is popular because it provides a simple loop for continuous improvement.

However, many teams run into the following issues:

❓ Unclear what the real problem is
🎯 No alignment with the ultimate goal
🌀 Endless cycles of "doing something" without meaningful impact
📉 False sense of progress

The root cause: PDCA assumes the problem and goal are already clear — which is rarely the case in the real world.

Introducing: GP-PDCA

To make PDCA effective, you need two steps before Plan:

Goal and Problem.

🥅 Goal

What are we really trying to achieve?
What is the ideal future state?
Why does it matter — and to whom?

🔍 Problem

What’s preventing us from reaching the goal?
What are the bottlenecks or pain points?
What is the root cause?

Then finally: the original PDCA loop

Plan: Hypothesize and design solutions
Do: Execute a small-scale trial
Check: Measure and evaluate
Act: Standardize or iterate

GP-PDCA Flow

G (Goal) → Define your ideal target or outcome (KGI)
P (Problem) → Identify obstacles or root causes
P (Plan) → Create hypotheses and KPIs
D (Do) → Take action
C (Check) → Evaluate performance
A (Act) → Reflect, standardize, or retry

Real-World Example: Improving a Dev Team's Output

Goal: Double the team’s release frequency
Problem: PR reviews are slow, test automation is lacking, rework is frequent
Plan: Improve CI pipeline, enforce WIP limits, clarify review guidelines
Do: Pilot these changes for 1 sprint
Check: Measure PR turnaround time, number of weekly releases
Act: Adopt successful practices across the team

Why “G → P” Before PDCA Is So Powerful

Starting with Problem is better than jumping into “Do”.

But starting with Goal is even better.

Without a clear goal, you're just solving problems — not driving toward anything meaningful.

GP-PDCA forces you to answer:

“Where are we going?”
“Why does it matter?”
“What’s standing in our way?”

Only then is it worth asking, “What should we do?”

Summary

PDCA is not broken — but it’s incomplete when used in isolation.

The GP-PDCA model adds two crucial layers: purpose and problem clarity.

This simple mental model has helped me dramatically improve how I approach product development, team processes, and even personal projects.

Final Thoughts

If PDCA has ever felt like busywork or a corporate ritual, you're not alone.

GP-PDCA gives it teeth again — by anchoring it to purpose and clarity.

If this model resonates with you, feel free to comment or share your own use cases.

Let’s upgrade our thinking — one cycle at a time.

Written by [Your Name]

Inspired by real-world frustration with shallow PDCA loops.