[{"data":1,"prerenderedAt":171},["ShallowReactive",2],{"post-en-redesign-recovery-mode":3},{"id":4,"title":5,"body":6,"category":152,"cover":153,"coverAlt":154,"date":155,"description":156,"extension":157,"locale":158,"meta":159,"navigation":160,"path":161,"published":160,"readingMinutes":162,"seo":163,"slug":164,"stem":165,"tags":166,"__hash__":170},"posts\u002Fen\u002Fposts\u002Fredesign-recovery-mode.md","The redesign removed the sidebar, and with it the only way to fix a broken page",{"type":7,"value":8,"toc":144},"minimark",[9,13,16,19,22,27,30,33,36,39,42,46,49,52,63,66,69,72,75,79,82,85,89,92,95,98,108,111,115,118,132,135],[10,11,12],"p",{},"The inSales visual site editor is where merchants change their store's design and manage its widgets. inSales is an e-commerce platform with 60,000+ merchants, and this editor is one of its core tools. The storefront page opens in an iframe inside the admin panel, and the editor lets you work with the widgets on that page.",[10,14,15],{},"The old editor had a large permanent sidebar next to the preview, and it was doing four jobs at once: global design settings, page sections, widget lists and the settings of the selected widget. Adding, editing and deleting widgets also worked through buttons inside the preview. So there were two ways to do the same thing, and neither was obviously the main one.",[10,17,18],{},"The redesign I was given fixed that. The top menu took over global settings and page navigation. Widget actions moved into the preview: select a widget, click Edit, and a floating panel opens over the storefront with that widget's settings. The permanent sidebar was gone. I got the mockups and spent about eight weeks implementing the frontend.",[10,20,21],{},"It's a better interface. It also had a hole that no mockup showed, because mockups show pages that work.",[23,24,26],"h2",{"id":25},"what-the-sidebar-was-quietly-doing","What the sidebar was quietly doing",[10,28,29],{},"Merchants and their developers can put their own HTML, CSS, JavaScript and Liquid into widgets. A critical mistake in that code can stop the storefront page from loading or make it return a server error.",[10,31,32],{},"In the old editor that was unpleasant but recoverable. The preview was broken, but the sidebar wasn't part of the preview. You could open the widget list, find the widget that broke the page, and fix its code or delete it.",[10,34,35],{},"In the redesign, the main way to reach a widget is the buttons inside the iframe. If the page doesn't load, those buttons don't exist. The merchant loses access to exactly the widget that broke the page, and the editor that's supposed to help shows an error with nothing to click.",[10,37,38],{},"Without a dedicated path, recovery meant going to another section of the admin panel and looking for the widget there, or downloading the template, editing it and uploading it back. That's hard enough for someone who knows what went wrong. A merchant who doesn't know which widget caused the error is stuck. Support has the same problem: they can't just open the page and fix it from the editor.",[10,40,41],{},"I found this while implementing the new structure, before any merchant could hit it. The sidebar had never been designed as a recovery tool. It just happened to be one, because it didn't depend on the page it was editing.",[23,43,45],{"id":44},"recovery-mode","Recovery mode",[10,47,48],{},"I proposed a technical mode that works without the iframe, and then built it.",[10,50,51],{},"When the editor opens, it checks whether the page actually loaded and whether the expected content appeared. If the page failed to load or returned an error, the merchant sees a message offering to open the technical mode. The idea, simplified:",[53,54,60],"pre",{"className":55,"code":57,"language":58,"meta":59},[56],"language-js","\u002F** Reports a broken preview when the page never shows the content the editor expects. *\u002F\nfunction watchPreview({ iframe, timeout, onBroken }) {\n  const timer = setTimeout(onBroken, timeout)\n\n  iframe.addEventListener('load', () => {\n    clearTimeout(timer)\n    if (!hasExpectedContent(iframe.contentDocument)) onBroken()\n  }, { once: true })\n}\n","js","",[61,62,57],"code",{"__ignoreMap":59},[10,64,65],{},"The mode itself is a separate window that lists every widget on the current page with its name, ID and available actions. From there you can open the widget's settings, go to its code, or delete it. The list doesn't depend on what's inside the iframe, so a dead preview can't take it down.",[10,67,68],{},"Two decisions mattered more than the code.",[10,70,71],{},"First, the mode is also available when the page loads fine. Then it's simply another way to see the full widget list and jump to the right block. I didn't want an escape hatch that only shows up during an emergency, because then nobody has seen it before they need it.",[10,73,74],{},"Second, it's built for support as much as for merchants. When a merchant doesn't know which widget caused the error, a support engineer can open the page, switch to technical mode, find the problem block, fix or delete its code, and then reopen the page in the normal mode. That's how it's used in production.",[23,76,78],{"id":77},"the-same-gap-in-a-quieter-form","The same gap, in a quieter form",[10,80,81],{},"The broken page wasn't the only job the sidebar had been doing silently. Some widgets aren't visible in the normal page content at all: a pre-order form that appears only after a shopper clicks \"Pre-order\", a feedback form, panels in the bottom area. In the old editor you reached them through the sidebar. In the new one you can't hover over something that isn't on the page yet.",[10,83,84],{},"So the top menu got a separate section for these widgets, where merchants can still find, add and configure them. Different symptom, same cause. The redesign removed an interface, and everything that interface made possible had to be moved somewhere on purpose.",[23,86,88],{"id":87},"what-shipped","What shipped",[10,90,91],{},"The redesigned editor is the standard version for current-generation inSales templates and is used by more than 90% of stores. The old editor with the permanent sidebar remains only for the template generation from before 2020, with a few hundred users.",[10,93,94],{},"The new structure also made a proper eight-step onboarding tour possible, where each step points to one stable part of the interface instead of a sidebar that keeps switching its contents.",[10,96,97],{},"These numbers describe the redesign as a whole, not the recovery mode on its own:",[99,100,101,105],"ul",{},[102,103,104],"li",{},"With the top menu and the settings panel closed, the preview is about 17% wider on a 1920 px screen, because the sidebar no longer takes a fixed slice of it.",[102,106,107],{},"Among new users, the share who changed a template or widget setting and successfully saved the result on their own during the first session went from 60% to 80%. That's a change of 20 percentage points (from three in five new users to four in five), not a 20% increase.",[10,109,110],{},"The recovery mode doesn't have a number of its own. Its result is that a broken page became something you fix from the editor, and support uses it for exactly that.",[23,112,114],{"id":113},"before-you-delete-a-panel","Before you delete a panel",[10,116,117],{},"This is the checklist I now run whenever a redesign removes or merges a piece of interface:",[99,119,120,123,126,129],{},[102,121,122],{},"List every job the old element does, including the ones nobody drew: error states, empty states, items that stay invisible until some action, and support workflows.",[102,124,125],{},"For each job, find where it lives in the new design. If the answer is \"nowhere\", say it out loud before release instead of letting support discover it.",[102,127,128],{},"Look at the new design in the state where its main surface fails. If the controls live inside the thing being edited, what happens when that thing doesn't render?",[102,130,131],{},"Keep the escape hatch reachable during normal work, so people know it exists before they need it.",[10,133,134],{},"Design reviews usually look at working pages, which is fair, because that's what users see most of the time. The engineer implementing the design is the one who keeps running into the broken states, so that's where these gaps are most likely to be caught.",[10,136,137,138,143],{},"More about the project is in the ",[139,140,142],"a",{"href":141},"\u002Fwork\u002Fvisual-storefront\u002F","visual editor case",".",{"title":59,"searchDepth":145,"depth":145,"links":146},2,[147,148,149,150,151],{"id":25,"depth":145,"text":26},{"id":44,"depth":145,"text":45},{"id":77,"depth":145,"text":78},{"id":87,"depth":145,"text":88},{"id":113,"depth":145,"text":114},"Product UX","\u002Fimages\u002Fblog\u002Fredesign-recovery-mode.svg","Three diagrams showing the old sidebar, the redesign where a broken preview hides all widget controls, and a recovery mode that lists widgets without the preview","2026-10-21","A cleaner visual editor moved widget controls into the storefront preview. When custom code breaks that preview, the controls disappear with it. This is how I found that gap and the recovery mode I built for it.","md","en",{},true,"\u002Fen\u002Fposts\u002Fredesign-recovery-mode",6,{"title":5,"description":156},"redesign-recovery-mode","en\u002Fposts\u002Fredesign-recovery-mode",[152,167,168,169],"Redesign","iframe","Error recovery","XaPTC6H51AbiyWSBWlE6OQnezun4b41rrYeGl8XvfXI",1793195986412]