rajathtirumangalam

Author: rajathtirumangalam

  • The 34,900 Problem: How to Bulk Clean Your Gmail Without Losing the Emails That Matter

    We’ve all been there. You look at that little number next to your Inbox—maybe it’s 500, maybe it’s 35,000—and you feel that spark of “digital dread.” As a professional, that number isn’t just clutter; it’s a wall between you and the work that actually matters.

    Manual cleaning is a nightmare. Gmail’s UI often lags when you try to select thousands of threads, and the fear of accidentally trashing a critical project update is real.

    As someone deep in UX and Accessibility, I view a cluttered inbox as a design failure. It creates unnecessary cognitive load and acts as a barrier to focus. If our tools don’t make it easy to maintain a clean environment, we have to build our own solutions. I decided to treat my inbox like an accessibility problem: Remove the noise, keep the signal.

    The “Safety-First” Cleanup Script

    This Google Apps Script acts as a surgical tool. It targets high-volume “noise” categories but strictly ignores any domain you deem “Safe.” Copy and paste the following into your Google Apps Script editor:

    
/**
 * Safe Inbox Purge Script
 * Author: Rajath Tirumangalam (rajathtirumangalam.com)
 * Strategy: Target high-volume categories while protecting critical domains.
 */

function mySafeInboxCleanup() {
  
  // 1. YOUR SAFE LIST (The "Never Delete" list)
  // PLACEHOLDER: Replace these with the domains you want to protect.
  var safeDomains = [
    "your-work-domain.com",  // Your professional email
    "your-bank.in",          // Critical financial alerts
    "school-alerts.edu",     // Family/Education
    "gmail.com"              // Keep personal Gmail-to-Gmail threads
  ];

  // 2. TARGET CATEGORIES
  var categories = "(category:promotions OR category:social OR category:updates)";
  
  // 3. BUILDING THE SEARCH
  var exclusions = "-from:(" + safeDomains.join(" OR ") + ")";
  var finalQuery = "label:inbox " + exclusions + " " + categories;
  
  Logger.log("Searching for: " + finalQuery);

  // 4. BATCH PROCESSING
  for (var i = 0; i < 10; i++) {
    var threads = GmailApp.search(finalQuery, 0, 100);
    
    if (threads.length > 0) {
      Logger.log("Batch " + (i+1) + ": Moving " + threads.length + " noisy threads to trash...");
      GmailApp.moveThreadsToTrash(threads);
    } else {
      Logger.log("Inbox is clean! No more matching threads found.");
      break; 
    }
  }
}

    How to Make This Script Your Own

    • Update your “Safe List”: Replace the placeholders in the safeDomains array with domains like your bank or employer. Ensure each is in quotes and separated by a comma.
    • Why the “Batch” of 100? Google limits how many threads can be trashed in one call. This ensures the script runs smoothly without errors.
    • The Safety Net: This script moves mail to the Trash, giving you a 30-day window to recover anything accidentally caught.

    The UX Takeaway

    Digital inclusion isn’t just about how we build software; it’s about how we manage our own digital environments so they don’t overwhelm us. Good design should foster focus. Until our email providers give us a “Surgical Delete” button, a few lines of code can be the bridge to a calmer workday.

    #TheInvisibleUser #DigitalAccessibility #UXDesign #Productivity #GmailAutomation #TechLeadership

  • When success messages don’t confirm success

    I submit a form.

    The button is activated.
    Something happens.

    But I don’t know if it worked.

    There’s no confirmation.
    Or worse, there is—but I never hear it.

    Maybe a message appeared visually.
    Maybe it was placed somewhere I’m not focused on.
    Maybe it disappeared too quickly.

    So I’m left wondering:

    Did it go through?
    Should I try again?
    Did I just submit this twice?

    Technically, the system is fine.
    The form works.
    The message exists.

    But accessibility isn’t about whether feedback exists.
    It’s about whether feedback is perceived.

    A success message should do one thing clearly:

    Remove uncertainty.

    If the user is still unsure, the system hasn’t finished its job.

    So users adapt.

    They refresh the page.
    They check emails.
    They resubmit forms just to be sure.

    Not because they want to.
    Because they have to.

    This is the gap.

    The system responds.
    But the user is left uncertain.

    And uncertainty is friction.

  • State changed. Nobody told the user.

    State changed. Nobody told the user.

    I activate something.

    Nothing happens.

    Or at least, nothing that I can perceive.

    Maybe the page updated.
    Maybe a panel opened.
    Maybe something important changed somewhere on the screen.

    But I don’t know that.

    Because nothing told me.

    Technically, the system did everything right.
    The state changed.
    The UI updated.

    But accessibility isn’t just about what changes.
    It’s about whether the user knows it changed.

    If a filter is applied, the user should know.
    If content updates, the user should know.
    If something expands, collapses, loads, or completes—the user should know.

    Without that, interaction becomes guesswork.

    So users adapt.

    They start re-reading the page.
    They move focus around.
    They try to find what changed.

    Not because they want to.
    Because they have to.

    This is the gap.

    The system responds.
    The state changes.

    But the change is silent.

    And silence, in accessibility, is failure.

  • Button. Button. Button. That’s not accessibility.

    I open an app and start navigating.

    “Button.”
    “Button.”
    “Button.”

    That’s all I hear.

    No context.
    No purpose.
    No indication of what each one does.

    Just… button.

    Technically, everything is there.
    The elements are accessible.
    The screen reader is reading them.

    It would probably pass an audit.

    But in real use, this isn’t usable.

    Because accessibility isn’t just about whether something is exposed to a screen reader.
    It’s about whether a user understands what’s happening.

    Every button should answer a simple question:

    **What will happen if I activate this?**

    If it doesn’t, the user is left guessing.

    And guessing is expensive:

    • it slows people down
    • it creates hesitation
    • it breaks trust

    So users adapt.

    They start exploring blindly.
    They activate things just to see what happens.
    They backtrack.
    They try again.

    Not because they want to.
    Because they have to.

    This is the gap.

    The interface responds.
    The system is technically accessible.
    But the interaction still fails.

    Because the system speaks…
    but it doesn’t communicate.

    That’s not accessibility.

    That’s noise.

  • Accessibility Is Not a Feature — It’s a Relationship

    The first thing a blind user meets in your app is not your brand.

    Not your color palette.
    Not your animation system.
    Not your typography.

    They meet sound.

    And inside that sound, a decision happens:

    “Can I trust this product?”

    I once opened an app and tapped what looked — visually — like an obvious Send icon.

    My screen reader said:

    “Button.”

    Nothing else.

    No hint of consequence.
    No sense of purpose.
    Just a generic control floating in uncertainty.

    It didn’t feel like a bug.

    It felt like someone forgot I exist.

    Not cruelly.
    Not intentionally.

    Quietly.

    And that quiet is where a lot of accessibility failures live.

    The Developer Voice (We’ve All Heard It)

    “It’s just an icon.”
    “Everyone knows what that does.”
    “The designer already made it obvious.”
    “I’ll come back and label it later.”

    None of these thoughts sound unreasonable.

    That’s the dangerous part.