Reviewing with comments

Document sections can collect review feedback. Turn on Allow comments, pick Who can comment, and editors plus the signed-in viewers of the audiences you picked can leave comments on the file. A comment can be pinned to an element of an HTML page or a spot on a PDF page, or be about the whole document. Feedback stays attached to the section across revisions, so the “comment, revise, check” loop keeps its history.

Comments are separate from your content. They are never part of a save or a publish, and nothing you do in the editor’s version history touches them.

Turning comments on

Open the Document section’s settings (the gear) and go to the Display tab.
Tick Allow comments.
Under Who can comment, pick the audiences whose viewers should comment. The list offers the audiences that can open the section. Pick none and only editors comment.
For a responsive HTML prototype, also tick Breakpoints (see Breakpoints below).
Save. Comments start working for editors when you save. Viewers see them once you publish, because viewers only ever see the published site.

Allow comments is off by default, so finished deliverables never start collecting comments by accident. If you don’t see the setting at all, comments aren’t set up for this portal. Ask your developer.

Turning it off hides the threads; it never deletes them. Turn it back on and every thread comes back as it was. Archiving or deleting the section does the same: its threads stay stored and are shown nowhere, to editors included. Unarchive the section and they come back.

Who can comment

Editors can comment on any comment-enabled document, including drafts that aren’t published yet. Use that to review internally before a client sees anything. An editor signed in with the site’s shared editor password, rather than their own account, sees no comment controls.
Viewers signed in with their own username and password can comment on a published document when their audience is picked under Who can comment and can open the document.
Nobody else. Visitors to public pages, and viewers on a portal that uses shared audience passwords, see no comment controls, because a comment needs a name to be attributed to.

Names appear the way people know them: a viewer by their sign-in’s label (or username if it has no label), an editor by the first part of their email address with an Editor badge. Each comment keeps the name it was posted under, even if the sign-in is later renamed or deleted.

Who sees which threads

Access is set per document, never per thread. Every audience picked under Who can comment sees every thread on that document: its own, other picked audiences’, and editors’. So two clients picked on the same document see each other’s feedback and names. Give each client its own document if that matters.

Editors’ comments are always seen by the picked audiences. For internal notes, review before you pick anyone, or keep them somewhere else.
An audience that can open the document but isn’t picked sees no comments, no pins and no comment controls.
With no audience picked, the document’s comments are editors only.

The comments panel says who a document’s comments are shared with, for example “Shared with Client, Farmer’s Union”, or “Editors only”. Viewers go by the published site, so a change to Who can comment reaches them when you publish.

Threads follow access too. If a picked audience loses access to the document, or the document’s page, its threads disappear from their view.

Leaving a comment

Open the document. The comments panel sits on the right and lists its threads: open ones first, pinned threads in pin order, then whole-document threads, with resolved threads collapsed at the bottom. The speech-bubble button in the top bar shows or hides the panel.

About the whole document: type in the box at the bottom of the panel and click Comment.
Pinned to a spot: click the Comment mode button (the speech bubble with a plus) or press C. The element under your pointer is outlined. Click to drop a numbered pin exactly where you clicked, write your comment in the box that opens beside it, and click Comment. Press C again to go back to browsing.

In comment mode, a click places a pin and doesn’t press the button or follow the link under it. Switch back to browse mode to use a prototype’s links, tabs and menus normally. Pin numbers match the numbers in the panel, and clicking a thread scrolls to its pin. A pin keeps its number for good: delete pin 2 of three and the others stay 1 and 3, and the next pin is 4. Next to the number, the panel shows the text of what the pin points at. In an HTML document the pins move with their elements as the page scrolls and reflows. In a PDF they stay on the same spot at any zoom.

Comments are plain text, with line breaks. Replies are a flat list under the thread.

Resolving, editing and deleting

Resolve a thread once its feedback is dealt with. It collapses to one line under the open threads, and its pin dims. Reopen brings it back. The person who started a thread, and any editor, can resolve or reopen it. A resolved thread takes no replies until it’s reopened.
Edit and delete your own comments with the icons beside them. Editors can delete anyone’s comment, for example one posted by mistake, but can only edit their own.
A deleted comment shows as Comment deleted so the conversation still reads in order. A thread whose comments are all deleted disappears.

Breakpoints

Breakpoints is for responsive HTML prototypes. It adds Desktop (1440px), Tablet (768px) and Mobile (390px) buttons, each with a monitor, tablet or phone icon, to the document’s top bar, which show the page at that width. Click the active one again to go back to the full width of the window. It isn’t offered for PDFs.

Every pin in an HTML document records the width it was made at, shown as the same device icon at the right of its thread’s top row. Hover it to see the width, such as Mobile · 390px. The name comes from the width: below 768px is Mobile, 768 to 1023px is Tablet, 1024px and up is Desktop. With Breakpoints on, clicking the icon switches to that preset so you see what the commenter saw; it’s greyed out while you’re already at that width.

The width is context, never a filter: a pin shows at every width where its element is visible.

When a pin can’t be shown

Not visible in this state. The element is in the document but hidden right now: a closed modal, an inactive tab, or something hidden at this width. With Breakpoints on, a Show at … link switches to the width the pin was made at.
Outdated. The element is gone from the current file, usually after a re-upload. The thread stays listed and readable, with the text of what it was pinned to, such as “Shop now”.

Re-uploading a revised file

Threads belong to the Document section, not to the file. When you upload a revised version and choose it in the section’s File setting, the existing threads carry over:

Each pin is found again in the new file, even if its element moved, its surroundings changed or its text was edited.
A pin whose element can’t be found any more is marked Outdated, never dropped.
Threads started on a previous file are marked From an earlier version, since they may refer to something that has changed.

Editors see the file in the latest save, viewers the published one, so the two can show different labels until you publish.

HTML files and the comment loader

Every HTML file uploaded to the portal gets a small comment loader added to it. That’s how comments work inside the file, and it’s added whatever the comments setting is, so you can turn comments on later without re-uploading. PDFs are never changed.

The loader starts with a note explaining what it is. A downloaded copy includes it but behaves exactly like the original when opened on its own. Shown inside another page’s frame, the loader only acts when that page asks, and then loads one script from that page’s own site, never from anywhere else. Re-uploading a downloaded file doesn’t add a second copy.

An HTML file uploaded before comments existed, or added to the site some other way, has no loader. The panel then reads Re-upload this file to enable comments: upload the same file again and pins will work. Whole-document comments work either way. If a file’s own security settings block the loader, or the portal can’t read the file to check for it, the panel reads Comments aren’t available for this file instead, since re-uploading wouldn’t help.

Finding feedback across the site

The Comments icon in the row at the bottom of the sidebar, beside Audience details, opens a list of every thread you can see. It shows when the site has at least one comment-enabled document you can open, with your unresolved count in a badge on the icon. Each Document section row also shows its own unresolved count.

The list groups threads by document, open ones first, with resolved ones behind a “resolved” toggle. Threads with activity since you last opened the list are marked New. Click a thread to go to its page, open the document and highlight the pin, switching to the pin’s width when Breakpoints is on. An Outdated thread opens with the thread selected in the panel.

Phones and live updates

On screens narrower than 1024px, you can read and reply to threads but can’t place new pins. PDFs open in the phone’s own viewer there, so their threads expand inside the Comments list instead, where you can read and reply.
In the editor, threads and counts update live as people comment, so you can respond while a client is reviewing. Viewers see new comments when they open a document or the Comments list, or come back to the tab.

Leaving comments on documents is written for your reviewers. Send them the link along with their sign-in.