A hands-on guide to designing interfaces that fail with dignity. Learn practical UI patterns and examples to make your interfaces resilient, handle network failures, API errors, and keep users in control

Elizabeth Efeelobari — Thu, 23 Apr 2026 21:09:10 +0000

Elizabeth Efeelobari

Apr 22

Resilient Interfaces: Designing UIs That Survive the Real Web

#javascript #frontend #googleappsscript #webdev

Comments

4 min read

Resilient Interfaces: Designing UIs That Survive the Real Web

Elizabeth Efeelobari — Wed, 22 Apr 2026 05:35:54 +0000

When you build in your local development environment, everything works perfectly. When you test your code on your own machine, your internet connection is flawless, and API endpoints respond in milliseconds.

The Google Apps Script backend executes without a hitch. In this pristine environment, it is incredibly easy to build a happy path user interface. Users clicks a button, the data sends, and a green "Success" message appears.

But to be honest, the real internet is a very chaotic, hostile environment.

Users access your site on trains going through tunnels with 3G connections. API gateways throttle requests. Cross-Origin Resource Sharing (CORS) policies fail. If you only design for the happy path, your application will break the moment it hits the real world scenario.

When I built the Contact and Ghost Network panels in my interactive portfolio, the most complex code wasn't the data transmission. It was the defensive engineering designed to handle failure.

Going forward, we'll dive into designing UI resilience, handling asynchronous network chaos, and ensuring that when your application fails, it fails gracefully.

Phase 1: The Illusion of Immediate Success (Optimistic UI)

When a user clicks "Send Message" on a contact form, the worst thing you can do is leave the button active while the browser waits for the server.

For instance, If the server takes three seconds to respond, a confused user will click the "Send" button five more times, firing off five duplicate network requests.

The first rule of resilience is State Lockdown. The moment a network request begins, the UI must immediately reflect a pending state.

const form = document.getElementById('contactForm');
const submitBtn = document.getElementById('submitBtn');
const feedbackMsg = document.getElementById('formMsg');

form.addEventListener('submit', function(e) {
  e.preventDefault(); 

  // 1. Clear any previous errors
  feedbackMsg.textContent = '';
  feedbackMsg.className = '';

  // 2. STATE LOCKDOWN: Disable the button and change the text
  submitBtn.disabled = true; 
  submitBtn.textContent = 'Sending...';

  // ... proceed to network request
});

By instantly disabling the button (submitBtn.disabled = true;), we physically prevent the user from spamming the server. By changing the text to "Sending...", we provide immediate psychological feedback that the machine is working on the request.

Phase 2: Taming Asynchronous Chaos (The Fetch Wrapper)

When we send data to a Google Apps Script backend using the fetch() API, we are entering the realm of asynchronous programming. We have asked the browser to go do a job on the internet, and we have to wait for the answer.

A junior developer handles a fetch request like this:

// The UI dead Path
fetch(WEB_APP_URL, { method: 'POST', body: payload })
  .then(response => response.json())
  .then(data => {
    // Assumed success and celebrate
    submitBtn.disabled = false;
    feedbackMsg.textContent = 'Message Sent!';
  });

This particular code is a time bomb, a disaster. What happens if the Google server returns a 500 Internal Server Error? What happens if the user's WiFi drops mid-request?

Simple, the .then() block will fail, the button will remain permanently disabled, and the user will be stuck staring at a "Sending..." message forever.

In essence, the UI is dead.

However, a resilient system uses strict Promise chaining and an ironclad .catch() block.

// THE RESILIENT PATH
fetch(WEB_APP_URL, { 
  method: 'POST', 
  body: JSON.stringify(payload) 
})
.then(response => {
  // 1. Check if the HTTP status is actually OK
  if (!response.ok) {
    throw new Error('Network response was not ok.');
  }
  return response.json();
})
.then(data => {
  // 2. The server responded, but did our specific logic succeed?
  if (data.success) {
    // THE HAPPY PATH
    submitBtn.disabled = false; 
    submitBtn.textContent = 'Send Message';
    feedbackMsg.style.color = currentAccent; 
    feedbackMsg.textContent = 'Secure message transmitted. Expect a reply shortly.';
    form.reset();
  } else {
    // The server replied, but the Apps Script logic failed
    throw new Error(data.error || 'Backend logic failed.');
  }
})
.catch(err => {
  // 3. THE SAFETY NET: Catch ALL errors (Network drops, CORS, Server crashes)
  submitBtn.disabled = false; 
  submitBtn.textContent = 'Send Message';

  feedbackMsg.style.color = 'red'; // indicator
  feedbackMsg.textContent = 'Connection failed. Please email directly: efeelobarie@gmail.com';

  console.error("Transmission Error:", err);
});

Phase 3: The Ultimate Fallback (Graceful Degradation)

The most important line of code in the entire sequence above is the error message itself: "Connection failed. Please email directly: efeelobarie@gmail.com"

This is the principle of Graceful Degradation.

If my custom Google Apps Script backend fails, or if a browser extension completely blocks the fetch request, the user's goal (which is contacting me) is not destroyed. The application admits failure, then releases the locked UI state, and immediately provides a low-tech, unbreakable alternative, which is a plain text email address (or directive)

The Empathy of Error Handling

This represents a shift in software design and user experience (UX) from purely technical, machine-oriented messaging to human-centric communication. It recognizes that error messages are not just functional interruptions but critical psychological events that can either build trust or cause anxiety (medium).

Writing defensive code is not just about preventing crashes. It is an exercise in user empathy.

Imagine an application breaks and leaves a user staring at a frozen screen. This creates frustration and erodes trust.

When an application encounters an error, the system should immediately inform the user and offer a clear alternative path. This approach builds professionalism and trust through prevention, rather than just reaction.

F A I L

Feedback : Always tell the user what happened

Actions : Give next step

Integrity : Don’t lose user data

Latency handling: Handle delays properly

We unknownly spend so much time building the perfect happy path, but a system's true quality is defined by how it behaves when everything goes wrong.

If a company’s web application is fragile, frustrating, and prone to silent failures, there is a need for a more resilient system.

Thank you for reading till the end. I hope you learnt something new and if you have any questions, feel free to reach out or drop them in the comments below.

How to Build a Code Visualizer in Google Apps Script

Elizabeth Efeelobari — Tue, 17 Mar 2026 16:50:28 +0000

Lately I am doing more of documentation and record keeping. Having fun teaching what I know.

Everyone is vibe coding and It is getting saturated to the point everyone feels like a creator, full-stack dev.
Until the bug hits, then prompt prompt prompt, prompt it away.
I miss the old days of research and actually trying to understand what is happening.

I write a lot, so I decided to just specialize as Apps Script developer. Build around the Google ecosystem. Have fun, document, teach, build.
I finally finished one.

Although, I kept debugging for the fun and emotional turbulence.
So I built something that shows me and records activities. A Code Visualizer that streams every operation to a live browser dashboard in real time. Just Apps Script doing what its good at.

I walk through monkey-patching, setting up the live logging dashboard, and visualizing exactly what your spreadsheet is doing as it happens.

If you have ever debugged a spreadsheet and felt completely in the dark, this one is for you.

Full article here:
How to Build a Code visualizer in Google Apps Script

DEV Community: Elizabeth Efeelobari

A hands-on guide to designing interfaces that fail with dignity. Learn practical UI patterns and examples to make your interfaces resilient, handle network failures, API errors, and keep users in control

Resilient Interfaces: Designing UIs That Survive the Real Web

Resilient Interfaces: Designing UIs That Survive the Real Web

Phase 1: The Illusion of Immediate Success (Optimistic UI)

Phase 2: Taming Asynchronous Chaos (The Fetch Wrapper)

Phase 3: The Ultimate Fallback (Graceful Degradation)

The Empathy of Error Handling

How to Build a Code Visualizer in Google Apps Script