How do you see the room while you're presenting?

The moment you share your screen, you stop being able to see the people you are sharing it with. The faces go away. The chat goes away. A raised hand — the most time-sensitive signal in the room — goes away.

This is one of the most persistent complaints in every major platform's support forum, and the way people describe it is consistent. One presenter, asking Microsoft for the feature: "As a presenter it is critical to read the audience." A teacher on Zoom's forum: "if I want to interact with a specific student, I have no idea who is out there." Another, describing what they lose: "all of the things that I'd be able to do if we were in-person."

The complaint is not that a panel is missing. It is that presenting online puts you in a position no one would accept in a room: talking to a wall, guessing whether anyone is following.

Every fix trades one loss for another

What makes this stubborn is that the available answers do not remove the problem — they move it.

The overlay covers what you're showing. Put the participant gallery on top of the content and you get the room back, at the cost of the thing you are presenting. A host on Zoom's forum: "the only way I can find to do is to show the gallery overlaid over the PP, which blocks some of the image." Another user describing the same bind from both sides: "It obstructs the screen in full screen, and then takes up more real estate than I want when I am not." Occlusion or invisibility — pick one.

The second monitor doesn't reliably fix it either. This is the standard advice, and it is worth being precise about its limits. It assumes you have a second display, which rules out laptop-only and travel setups. But even with two, users report losing the roster the moment slides go full screen: "every time I put PPT into presentation mode, I lose my participant gallery. My choices are to have the shared screen on one monitor and presenter dashboard on the other, or have 2 screens mirroring each other… both showing the shared screen. Totally unacceptable for either a class or a meeting."

Window juggling is what people actually do. The real-world workaround is manual choreography — shrinking, dragging, re-opening. One Teams user: "As work around I opened the Teams screen and moved to the left, just the list of participants was visible, while diminishing the screen I shared."

The reason none of these settle the matter is structural. The meeting is a window. What you are presenting is a window. On one screen, windows compete — for space, and for focus.

There is a case where the trade-off stops being about comfort and starts blocking the work itself.

Most advice about screen sharing assumes you are presenting something finished. A deck. A dashboard. A recorded flow. But plenty of working meetings share the thing being changed — the spec getting a new paragraph, the sheet getting the corrected number, the project board getting the card everyone just agreed to move. As one person put it when asking how to keep seeing participants: "Not just PowerPoint or Excel, but anything."

Now the conflict is sharper. To edit the document, the document needs focus — it has to be the window you are typing into. So the meeting goes behind it, and with it goes the chat where someone is pasting the exact wording you should use, and the pointer you were using to show people which row you mean.

Keep the meeting in front and you are talking about the change instead of making it. Make the change and you are working blind. The work moves to "after the call," away from the room that just agreed to it.

What the platforms actually document

The vendors document three different answers, and they are worth reading precisely — because one of them is closer to a solution than the others, and it is not the one people assume.

Google documents picture-in-picture mode for Meet, stating you can "use picture-in-picture mode to concurrently present and find your audience," and unpinning a presentation so you "can now find more participants while you present" (checked August 2026). Both address seeing participants; Google's presenting page does not document a way to keep chat visible while presenting on a single screen.

Zoom documents dual-monitor mode, where "gallery or speaker view can be displayed on one monitor while the other monitor displays shared content" — with stated prerequisites including the desktop app and a CPU floor of an i5 with four or more cores (checked August 2026). It is the second-monitor answer, written down as a feature.

Microsoft goes furthest. Teams documents a presenter toolbar "only visible to the person presenting," and states: "Select Chat to view and participate in a compact view of the meeting chat while you're presenting content. Your audience won't see the chat window in your shared screen" (checked August 2026).

That last one matters for anyone comparing options: a private, non-captured chat panel for the presenter is not a gap in the market — Teams documents one today. The remaining difference is what the presenter's other window is doing. Meet's and Teams' presenter surfaces are parts of the meeting app's own window; the document you are editing is still a separate window competing for focus with it.

What changes when the meeting stops being a window

There is one surface in a browser that does not compete for focus with the page: the browser's own side panel.

Chrome documents the Side Panel API as a way for an extension to "host content in the browser's side panel alongside the main content of a webpage" (checked August 2026). The relevant property is structural. The panel is part of the browser frame, not part of the tab. It sits beside whatever tab is active, it stays put when you switch tabs, and typing into the page does not push it behind anything — because it was never in the stack the page is in.

That has a second consequence, and here we should be careful to separate what is documented from what we measured. Chrome's screen-capture documentation describes tab capture as capturing the visible area of a tab, and the W3C screen-capture specification leaves the exact boundary of browser UI implementation-dependent — neither states what happens to a side panel. So we tested it: when sharing a tab, the side panel does not appear in the captured stream. Participants see the tab you picked, not the panel beside it.

That result is share-mode specific, and the distinction is the whole point. Share your entire screen and everything on that screen is captured, panel included. The property we rely on holds for tab shares, which is the mode this workflow uses.

Put those two properties together and the trade-off dissolves rather than gets managed:

The document is the active tab. It has focus. You type in it, and it is the full width of your screen — not half of it, and with nothing overlaid on top of it.
The meeting lives in the panel beside it, in the app's narrow layout: the call, the chat, the participants, the pointer controls.
Your participants see the document. Not your call window, not the chat you are reading — the tab you picked, and the pointer you use on it.

This is what we built the InterMIND Chrome extension for. The call runs in the side panel; the tab you share stays yours to edit. In a working session on a project board it means the board is at full width and being edited, the pointer still shows the room where to look, and the chat is still readable beside it — at the same time, on one screen, with no second monitor and nothing covering the content.

Note what this does not claim to fix. The panel is narrow, so a large gallery of faces is not what fits there — this answers "keep the room and its chat reachable while I work," not "show me thirty video tiles at once."

The honest limits

Three things are worth stating plainly, because they set expectations correctly.

The share still starts with the normal picker. You click share, Chrome asks which surface you want, you pick the tab. There is no one-click "share the tab I'm on" from a side panel — Chrome does not grant extensions tab capture from the panel context, and a request to add that capability was closed by the Chromium team as won't-fix (checked August 2026). The picker is one click. It is the mechanism, not a workaround.

This is browser-specific. The side panel is a Chromium feature. The scenario described here is a Chrome and Edge scenario; on other browsers you are back to arranging windows.

It solves one problem. Sharing a tab while editing it, without losing the call UI. It does not make a small laptop screen bigger, and if what you need to share is a desktop application rather than a browser tab, the tab-capture property does not apply to it.

Where this matters most

The pattern shows up wherever the artifact is live rather than finished:

Working sessions on a doc or spec — editing wording as the room reacts to it, instead of writing down feedback to apply later.
Spreadsheets and planning models — changing an input and letting everyone watch the number move, which is the whole reason the sheet is on screen.
Project boards and backlogs — the reason we noticed this internally: moving cards and editing tickets during a planning call while still reading what people are typing about them.
Design and code review — making the small fix during the call, while the pointer marks what is being discussed.

What these have in common is that the value of the meeting is the change to the artifact, and any workflow that pushes the editing to "after the call" moves the work out of the meeting where the agreement happened.

FAQ

How do you see participants while presenting?

Each platform documents a different partial answer. Google documents picture-in-picture and unpinning the presentation to "find more participants while you present." Zoom documents dual-monitor mode, which needs a second display. Microsoft documents a presenter toolbar visible only to the presenter (all checked August 2026). The common limit is that these surfaces live inside the meeting app's own window, so they compete with whatever else you are doing — which is why users report losing the roster anyway the moment slides go full screen, even on two monitors.

Why do I lose the participant gallery when PowerPoint goes into presentation mode?

Because presentation mode takes over the display it is on, and the meeting window is a separate window that gets pushed behind it. This is why a second monitor does not automatically settle the problem: users with two displays report the same loss, since the choice becomes which display the slideshow claims. The alternatives people fall back on are overlaying the gallery on top of the content, or manually resizing windows.

How do you see chat while sharing your screen on one monitor?

It depends on the platform. Microsoft documents a compact meeting-chat view in Teams for the presenter, stating the audience will not see that chat window in the shared screen (checked August 2026). Zoom's documented answer is dual-monitor mode, which needs a second display (checked August 2026). Google's presenting documentation covers seeing participants via picture-in-picture, not chat (checked August 2026). What none of them changes is that the presenter surface belongs to the meeting app's window — so if you also need to edit the shared document, that document and the meeting are still two windows competing for one focus.

Can you edit a document while screen sharing it?

Yes — the limitation is not on editing, it is on what you can see while you do it. The document has to hold focus for you to type into it, which puts the meeting interface behind it on a single screen. The document keeps being shared the whole time; you just lose sight of chat, participants and the pointer while working in it.

Do you need two monitors to present and work at the same time?

Two monitors is the standard answer and it works. It is not the only one: a browser side panel gives you a second surface on a single screen, because the panel sits in the browser frame beside the page rather than competing with it for focus.

Does the side panel show up in your screen share?

Not when you share a tab — we tested this, and the panel does not appear in the captured stream. Chrome's documentation and the W3C screen-capture specification do not state the behavior either way (the spec leaves browser-UI boundaries implementation-dependent), so treat this as a measured result rather than a documented guarantee. If you share your entire screen instead, everything visible on that screen is captured, including the panel.

Is there a way to share the current tab in one click, without the picker?

Not from a side panel. Chrome does not grant extensions tab capture from the panel context, and the request to allow it was closed as won't-fix by the Chromium team (checked August 2026). The share starts from the standard Chrome picker, where you select the tab.

Which browsers does this work in?

The side panel is a Chromium feature, so this applies to Chrome and Edge. Other browsers do not have an equivalent surface, and the window trade-off described above applies there as normal.

Does this replace a second monitor?

For this specific case — sharing a browser tab while editing it and keeping the call UI visible — it removes the reason you needed the second monitor. It does not replace a second monitor for everything else a second monitor is good for.

Try it

Try the live demo — see how a translated call behaves before installing anything.
Read the translation benchmark — the quality numbers, with the full per-pair distribution and the method behind them.

Sources: Chrome for Developers — chrome.sidePanel API, Chrome for Developers — chrome.tabCapture API, W3C — Screen Capture, Chromium issue 40926394 — chrome.tabCapture from side panel, Google Meet — Present during a video meeting, Zoom — Using dual monitor mode, Microsoft — Present content in Microsoft Teams meetings. Vendors change their apps and documentation over time; check their pages for the current state. All facts checked August 2026.