{"slug":"save-and-teleport","meta":{"title":"Save and Teleport","slug":"save-and-teleport","kind":"anti-pattern","summary":"Saving throws the person somewhere else — a list, a dashboard, the top of the page — so they lose their place and cannot tell whether it worked.","problem":"You change one field on row forty, press save, and land on page one of an unfiltered list. The change may have worked. You cannot see it, you cannot see where you were, and the only way to check is to rebuild the view you had.","family":["edit","orient"],"principles":["orientation","friction"],"status":"stable","visibility":"public","related":[{"title":"Orientation","url":"/patterns/orientation","summary":"The principle — saving should answer \"did that work\", not take the answer away."},{"title":"Inline Editing","url":"/patterns/inline-editing","summary":"The fix at its strongest — never leave the screen in the first place."}]},"body":"## How you get here\n\nIt is the framework default. A create or update action that redirects to the\nindex is the generated scaffold in almost every web framework, and it survives\nbecause it is *correct in the narrow case* — the very first time someone creates\na thing, going to the list is reasonable.\n\nIt stops being reasonable the moment the person is working through something:\ncorrecting a filtered list, editing a record they will edit again, or making one\nchange among several.\n\n## How to recognise it\n\n- People ask \"did that save?\" — the definitive symptom.\n- Anyone editing several records rebuilds their filters between each one.\n- The scroll position resets after every save.\n- Someone's workflow includes opening the record in a second tab so they do not\n  lose the list.\n- A flash message appears at the top of a page whose save button was at the\n  bottom, so nobody ever reads it.\n\n## Why it fails\n\nIt destroys **context the person built and the system did not**. Filters, sort\norder, scroll position and the mental thread of \"I am halfway through these\ntwelve\" are all real work, and a redirect discards them for free.\n\nIt also breaks the feedback loop. Confirmation of a save is most useful *next to\nthe thing that changed*. Moving the person elsewhere and showing a banner\nreplaces \"I can see it worked\" with \"the software claims it worked\", which is a\nstrictly weaker signal and the reason people re-check.\n\n## The way out\n\nIn order of preference:\n\n1. **Do not leave.** Edit the value where it lives, so there is no navigation to\n   undo and the new value is visible in place.\n2. **Stay on the record.** If a form is warranted, save and remain, showing the\n   updated state.\n3. **Return to where they came from**, with the filters, sort and scroll\n   restored — carried in the URL, not in memory.\n4. **If you must move them**, say where they are going and why, and make the\n   thing they just changed visible on arrival.\n\nAnd put the confirmation **where the eye already is**, not at the top of a page\nthe person is not looking at.\n\n## The one legitimate case\n\nCreation of a brand-new object, by someone who has just arrived, with nothing to\nreturn to. Even then, landing on the *new record* is usually better than the\nlist — creation is the beginning of the work, not the end of it.\n"}