> ## Documentation Index > Fetch the complete documentation index at: https://docs.avocadostudio.dev/llms.txt > Use this file to discover all available pages before exploring further. # A tour of the editor > What is on screen when you open Avocado Studio, what each control does, and the one button that makes the page clickable. This is the page for the person who *uses* Avocado Studio rather than the person who installed it. No environment variables, no code. If your site is already wired up and someone has sent you a link to the editor, start here. The editor is one screen with three regions: a **header** across the top, a **panel** on one side, and a **live preview** of your real site filling the rest. The preview is your actual page — the same components, the same styles, the same content — not a picture of it. ## The header | Control | What it does | | ------------------- | -------------------------------------------------------------------------------------------------------------------- | | **All sites** | Back to the site list, if you have more than one | | **Page** | Switch which page you are editing. Every page the site declares is in here | | **Language** | On a multilingual site, switch which language version you are editing | | **Site settings** | Name, logo, hosting, media, and the [editorial brief](/editing/brief) | | **Pull from site** | Re-read the published content from the site, discarding nothing — see [pages and drafts](/editing/pages-and-drafts) | | **Site health** | Run [checks](/features/site-health) over the site and list what is wrong | | **Version history** | Every change, in order, with a way back — see [review and undo](/editing/review-and-undo) | | **Publish** | Push your draft to the live site. It shows a count of unpublished changes first — see [publishing](/editing/publish) | Two badges appear in the header only when something is off, and both are worth knowing by sight: * **Limited** — the site is not telling the editor what its blocks are, so you get a read-only preview or text-only edits. That is an integration problem; send it to whoever wired the site up, along with [coverage checks](/integration/coverage). * **Add an API key** — chat is running without a model behind it. Simple, literal edits still work; anything phrased your own way will ask for a key. Also a job for whoever set the site up. ## The panel Two tabs: **Chat** and **Properties**. **Chat** is the main surface. You describe a change, it happens. The composer at the bottom says *Ask anything*, and around it sit four controls: * **Select an element** — the cursor button. This is the important one; see below. * **Attach file** — images and PDFs. Useful for *"use the photo attached"* or *"take the copy from this PDF"*. See [chat attachments](/features/chat-attachments). * **Start voice input** — dictate instead of typing, where a key supports it. * **Send**, which becomes **Stop generation** while a change is being made. **Properties** is the other way to edit. With a block selected it lists that block's real fields — text, rich text, images, links, list items, SEO title and description — and writes real values as you type. No model is involved, so it costs nothing and never surprises you. Use chat for *"rewrite this section to sound warmer"*; use the panel for *"this price is 49, not 47"*. ## Click-to-select is off until you turn it on The single thing most worth knowing about this editor: **clicking the preview does nothing until you switch the picker on.** Press the cursor button in the composer — its tooltip reads **Select an element** — and then clicking a heading, an image or a card highlights that block and tells the chat what you mean. Escape turns it back off. It defaults to off on purpose. The preview is a live site, so links, tabs and carousels have to keep working while you read; a picker that swallowed every click would make the page impossible to browse. But it does mean a perfectly healthy editor looks inert on first contact. With something selected, the composer shows **Editing: *block***, and your next sentence is scoped to it. *"Make this shorter"* is unambiguous once the editor knows what *this* is. ## What happens when you send a message A thinking indicator appears and then collapses into **Thought for \_n\_s**, which you can expand if you want to see the reasoning. Operations apply to the page as they arrive, so you watch the page change rather than waiting for a result. A readable summary — *Applied to your draft* — with the affected block named. **Undo** sits on the message that produced the change, and a global undo and redo sit above the composer (Ctrl+Z and Ctrl+Y). Undo is recorded on the server, not a browser trick, so it survives a reload. Anything destructive — deleting a page, removing a block — does not apply and then offer an undo. It stops and asks, with **Apply changes** and **Discard** buttons and a description of what it is about to do. ## Nothing you do here touches the code Every edit is one of a fixed set of typed operations against your content. There is no operation for "change a file", so no sentence you type — however it is phrased, however confident the model is — can alter a component, a route or a dependency. The boundary is the shape of the system, not a rule someone remembered to apply. The practical version: **you cannot break the website from this screen.** The worst you can do is publish something you did not mean to, and [version history](/editing/review-and-undo) undoes that too. ## Where to go next What to say, what not to bother saying, and which requests cost real money. Where your unpublished work lives, and why the live site looks unchanged. Every way back: undo, revert, version history, and discarding one change from last week. The review dialog, publishing only some pages, and how to tell it worked.