For developers
Sign in from the site, read pins, fix, and hand back to the client.
Sign in on the site
Two ways:
- In the dashboard, press Open site next to an address (project settings) or on a feedback item. It opens the page and asks you to sign in (once per browser on On addresses).
- On any address of the project, or any localhost address, add
#ekhanemarkto the URL, for examplehttp://localhost:3000/#ekhanemark. Press Sign in; an EkhaneMark window checks your account and signs this site in. On On addresses you stay signed in in that browser.
Reading pins
Each pin is numbered and coloured by status:
- Red: open. Amber: in progress. Blue: ready for the client to check. Resolved feedback is hidden; find it in the list.
- A dashed pin is a best guess: the element changed or the data on your copy is different. If it's on the wrong thing, open it and use Re-pin to another element (in the pin's ⋯ menu) to click the right element.
- If an element can't be found at all, the item is listed with “Element not found” and its screenshot shows what the client saw.
Click a pin to see who said what, with voice notes, images and attached files. Reply opens the conversation in place. The ⋯ menu has Details and screenshot: what the client saw, plus browser, OS and screen size; if the client's screen was much smaller than yours, it says so.
Fixing and handing back
- Optionally choose Working on it in the pin's ⋯ menu so the team knows.
- Make the change and deploy it where the client can see it.
- Press Mark done (or the check icon at the top of the pin). If the site has more than one address, choose where the client can check it (Staging or Live). The pin turns blue and the client is emailed a link to that address. When they press Looks good it closes and the pin leaves the page; if they say it's still broken, it comes back as open with their reply.
Asking the client
Not sure what they mean? Choose Ask a question in the pin's ⋯ menu (or on the feedback page in the dashboard) and write it. The item becomes Needs info (purple) and the client is emailed. Their answer moves it back to In progress.
Internal notes
Tick Internal note before replying to talk to your team without the client seeing it. Internal notes are never shown or emailed to clients.
Leaving your own feedback
Team members can pin things too (for QA or notes to each other). Feedback from a team member doesn't need client approval; it closes when you mark it resolved.
In the dashboard
Each project's Feedback page filters by status, page, site address and “Assigned to me”. The feedback page has the full conversation and history, priority and assignee, a button to open the page on any address, and Jira.
Everything updates by itself: a new pin, a client's reply, a status change or a screenshot shows up on the board, the feedback page and the widget within a moment, without reloading.
File and line
On Next.js and React (Vite) sites, add our build plugin and every pin records where the element is in your code: src/components/Hero.tsx:42, plus where that component is used. You see it on the feedback page and the board, and AI agents open the file straight away.
npm i -D https://ekhanemark.com/ekhanemark-source.tgz
// next.config.ts
import { withEkhaneMark } from "@ekhanemark/source/next";
export default withEkhaneMark({ /* your config */ });
// or vite.config.ts
import ekhanemark from "@ekhanemark/source/vite";
export default defineConfig({ plugins: [ekhanemark(), react()] });It adds a data-em-src attribute to the HTML your JSX renders. It's on in development. For staging, build with EKHANEMARK_SOURCE=1 so clients' pins there record it too. Live builds stay as they were unless you set it, so file names don't end up in your public HTML.
The component, without the plugin
Without the plugin, pins still learn which component they're in, from what development builds leave on the page: React (Next.js, Vite, Remix), Vue and Nuxt, Svelte and SvelteKit, Astro and Angular. A client pins something on the live site; the next time someone on the team opens that page on their localhost, signed in to the widget, each pin gets its component: PriceCard, inside PricingPage. Vue, Svelte, Astro and React on Vite also give the file. It shows where the file and line would, and agents open that component instead of searching the whole project.
Live builds shorten component names, so pins made there wait for that localhost visit. Custom elements and Angular components keep their tags everywhere (<app-hero>). Sites built on the server (PHP, WordPress, Laravel, Django) have no components on the page; their pins keep the selector and text, which agents search the code with.