You spend time filling a profile, click Save and the button goes back to normal. Did it save? If the screen gives no answer, you may click again or leave and hope the work is there.
I want to avoid that kind of guessing in the things I build. A save button is small, but the person using it may have written a long description or entered details they do not want to repeat.
This is how I would plan the saving behaviour for a profile editor. It is a design example, not a report of a completed test.
The form and the saved record are different things
What somebody sees in a field may only exist in the browser. It does not become a saved record because the text changed or the button responded.
I want the interface to distinguish four situations: nothing has changed, there are unsaved changes, a save is in progress, and the server has confirmed the save. A failure needs its own message.
Those states should follow the actual operation. I should not show “Saved” immediately after starting a request and hope the request succeeds afterwards.
I keep track of what changed
For a simple editor, I can compare the current editable values with the last confirmed values. If the person changes their name and then puts it back exactly as it was, there may be nothing left to save.
The comparison needs sensible rules. A missing value, an empty string and a value containing spaces may mean different things in the product. I want to agree on that before deciding whether the form has changed.
I also keep unrelated loading changes out of this comparison. Fetching a list of countries should not make the profile appear edited.
Saving should not erase the next edit
Imagine somebody submits a description, then continues typing while the request is running. When the response arrives, replacing the whole form with the earlier submitted version could remove their newer words.
I need a deliberate choice here. I can temporarily prevent editing during a short save, or keep editing available and track which version was submitted. If newer changes exist, the form must still show that they are unsaved.
Neither choice should quietly discard input. The important part is knowing which values the server confirmed and which values are still only in the browser.
A failed request should keep the work
If the save fails, I want the description to stay in the field. The message can explain that the changes were not saved and offer a retry.
A network failure can also leave the outcome uncertain. The server may have completed the operation before the connection broke. For an important update, checking the stored record can be more useful than assuming failure means nothing happened.
I would test the normal response, a rejected value, a slow response and a lost connection. Then I would reopen the record and compare it with what I expected to store.
Leaving the page needs thought too
A warning can help when somebody navigates away with unsaved work. But I do not want a warning on every page visit, including when nothing changed.
A browser warning is also not a reliable backup system. MDN documents limitations of the beforeunload event, particularly on mobile. If drafts matter, I need to plan draft storage and recovery separately.
Saving drafts locally has its own questions: what data is suitable for the device, when should the draft expire, and what happens when another account signs in? I should not store private information casually just to make the form feel convenient.
My small verification checklist
- Edit a value and check that the form shows unsaved changes.
- Save and wait for the actual confirmation.
- Refresh or reopen the record to check persistence.
- Fail a save and confirm the input remains.
- Try editing during a slow request.
- Leave with and without unsaved changes.
I want the person to understand where their work stands. Clear saving behaviour gives them a reason to trust the form, beyond a button that changes colour when clicked.
Reference: MDN: beforeunload event and its limitations.
A JavaScript example you can adapt
For an artist profile, the biography in the form and the biography stored on the server must agree. Here is a small teaching example that makes the save states explicit. It assumes an authenticated PATCH endpoint which validates the input and returns the stored profile as JSON. It is not a claim that this exact code has been deployed on ArtistBio.
let saving = false;
async function saveProfile(form, status, button) {
if (saving) return;
const submitted = {
name: form.elements.name.value.trim(),
bio: form.elements.bio.value
};
if (!submitted.name) {
status.textContent = "Enter an artist name before saving.";
return;
}
saving = true;
button.disabled = true;
status.textContent = "Saving your profile…";
try {
const response = await fetch("/api/profile", {
method: "PATCH",
headers: { "Content-Type": "application/json" },
body: JSON.stringify(submitted)
});
if (!response.ok) throw new Error("Save rejected");
const stored = await response.json();
const confirmed = stored.name === submitted.name
&& stored.bio === submitted.bio;
if (!confirmed) throw new Error("Unexpected saved values");
const changedDuringSave =
form.elements.name.value.trim() !== submitted.name
|| form.elements.bio.value !== submitted.bio;
status.textContent = changedDuringSave
? "Earlier changes saved. Your latest edits still need saving."
: "Your profile has been saved.";
} catch (error) {
status.textContent = "Save could not be confirmed. Your text is still here. Check the stored profile before retrying.";
} finally {
saving = false;
button.disabled = false;
}
}Give the status element role="status" so assistive technology can announce the message. Call this function from the form submit handler after event.preventDefault(). The form needs fields named name and bio; the button should be a submit button.
The function captures the values before starting the request. It does not replace the fields when the response arrives, so words typed during a slow request remain in the editor. The disabled button and the in-flight guard prevent a second save from this form while the first request is running. They do not protect against another tab or another administrator editing the record; that requires server-side version checks.
What the server still needs to do
The endpoint must authenticate the caller, check permission to edit this particular profile, validate field lengths, and persist the update before returning success. Browser validation is useful feedback, but it is not an authorization rule. If the server trims or transforms fields, return those canonical values and define how the editor reconciles them rather than treating every transformation as a failed save.
A successful response is one piece of evidence. Reopening the profile with a fresh read checks persistence independently. For operations that trigger billing, notifications, or other side effects, retries need a server-side idempotency strategy. A disabled button alone cannot provide that guarantee.
Concrete cases to check before shipping
| Case | Expected result |
|---|---|
| Server returns a validation error | No saved message; entered text remains. |
| Response takes several seconds | Saving message remains visible and a second save is blocked. |
| Biography changes during the request | The newer text remains and is identified as unsaved. |
| Connection drops after submission | The outcome is uncertain; read the stored record before assuming nothing happened. |
| Profile is reopened after success | The submitted values appear in a fresh server read. |
These are expected behaviours to verify, not measured results from a completed test. Record the actual browser, response status, submitted values, and reopened values when testing your own implementation. That turns a reassuring message into evidence you can inspect.