Vivaldi workspaces: how to decide what you need
Vivaldi Workspaces are easy enough to create that most setups are built without any decision behind them. Six months later the sidebar holds nine of them and the work all happens in the same two. The fix is not a better naming scheme. It is deciding three things up front: what the boundary is drawn on, how many workspaces stay in daily rotation, and what order they sit in. Each of those has a practical answer that comes from how often you switch, not from taste.
Pick one basis for the boundary and hold to it
There are three ways to split work into workspaces, and in practice everyone uses one of them.
By counterparty. Client A, client B, internal. Everything connected to one relationship lives together, regardless of what kind of work it is.
By kind of work. Writing, research, invoicing, hiring. The type of activity decides the home, and the same client appears in several places.
By time. Morning routine, afternoon deep work, weekend personal.
None is better than the others. Mixing them is what fails. A setup with a client A workspace and an invoicing workspace raises the same question every month, which is where client A's invoice goes. Any split that produces a judgment call on every item is not organization, it is an extra decision repeated forever.
The way to pick is to look at what interrupts the day. If work changes because someone else asks for something, a counterparty split matches reality. If work changes when attention runs out on one task and moves to another, a split by kind of work matches better. Watching one ordinary day is usually enough to tell which one is driving the switches.
Let the keyboard decide how many
Vivaldi lists seven ways to switch workspaces: the Workspaces menu, Quick Commands by name or with Next Workspace and Previous Workspace, hovering the button and scrolling the mouse wheel, keyboard shortcuts, mouse gestures, double clicking in the Window Panel, and the main menu under Window. Only one of those is fast enough to use dozens of times a day.
Use Keyboard Shortcuts. If you know the order of the workspaces, use Ctrl+Shift / ⌘ ⇧ and the number of the workspace, for example, Ctrl+Shift+3. Source: help.vivaldi.com
The phrase that sets the limit is "if you know the order". Past four or five workspaces, the hand stops knowing and the mind has to look it up. At that moment the keyboard advantage is gone and the menu would have been just as quick.
So the working number is three to five workspaces in daily rotation. Anything that gets opened a few times a month does not belong in that set. Save it as a Session instead, where it can be recalled by name without occupying a slot in the switching order. Anything opened twice a year belongs in a bookmark folder.
The tab count shown in the Workspaces menu is a good pruning tool. A workspace holding one or two tabs almost never earns a switch. The Window Panel shows tab counts and Tab Stack counts for every workspace at once, which makes the whole inventory visible in a single pass.
Fix the order before the numbers start moving
New workspaces are added at the bottom of the list and can be dragged to reorder. The consequence that catches people is that the keyboard shortcut number follows the position, not the name. Insert a new workspace at position two and every number after it shifts by one. A shortcut the hand has used for months now opens something else.
There are two ways out, and both work as long as the choice is deliberate.
The first is to decide the order once and only ever append. Put the place where the most hours are spent at position one, and let frequency decide the rest of the sequence. Once order carries meaning, the number stops needing to be memorized because it can be derived.
The second is to ignore numbers entirely and use only Next Workspace and Previous Workspace. In that mode the order becomes distance rather than address, so related workspaces should sit next to each other. Reordering is then free, which suits people whose projects turn over quickly.
What does not work is using numbered shortcuts while continuously inserting workspaces in the middle. That combination guarantees that the fastest switching method is also the least reliable one.
Name and icon are for recognition, not reading
Each workspace gets a name and an icon at creation time, and a custom emoji can be used in place of the built in icons. A long descriptive name defeats the purpose, because every switch then requires reading.
Three rules cover most of it. Keep first characters distinct, so two names never have to be read to the end to be told apart. Choose icons with different shapes rather than different shades of the same shape, since color alone fails at a glance and fails harder for anyone with limited color vision. Check whether the current workspace can be identified from the button itself without opening the menu, because that saves an entire interaction on every switch.
Placement matters for the same reason. The Workspaces button can sit in the Tab Bar, the Address Bar, a Panel, or the Status Bar. Putting it where the eyes already rest shortens the loop. On a vertical tab bar the button appears at the top of the list, which is worth knowing before deciding that the horizontal layout is required.
Decide what will never be a workspace
Half of a good setup is the exclusion list. Three categories belong on it.
Anything that needs a separate login. Workspaces share the cookie store of their profile, so two workspaces cannot hold two accounts of the same service at once. That job belongs to User Profiles, or to a tool that makes the window the unit of identity.
Anything whose notifications must never be missed. Switching workspaces changes which tabs are shown, and whether a hidden tab keeps running depends on hibernation settings and on how the service itself behaves. A service that must interrupt reliably should not be buried behind a switch.
Anything temporary. Creating a workspace for an afternoon of research means cleaning it up afterward, and cleanup is the step that gets skipped. A Tab Stack closed in one action fits that case better.
One more rule covers a specific failure. Workspaces created in a private window are removed when that private window closes, while ordinary workspaces are saved automatically when the browser closes. A set of tabs that needs to survive should not be assembled in a private window in the first place.
Two ways to create one, and when each fits
A workspace can be created empty or from what is already open, and the right choice depends on the current state of the tab bar.
Creating from scratch goes through the Workspaces button, New Workspace, then a choice between an empty workspace and moving the current window's tabs into it, then a name and an icon. The same action is available by typing Create New Workspace in Quick Commands, and it can be bound to a keyboard shortcut or a mouse gesture.
Creating from existing tabs starts with selection. Select the tabs, right click one of them, then Move, Workspace, Create Workspace with Selected Tabs. This is the better path when starting from a mess, because the boundary gets drawn around what is actually there instead of around a guess.
A useful signal comes out of that second method. After the obvious groups are carved off, whatever is left over says something. A handful of leftovers is normal. A large pile that fits nowhere means the chosen basis for the split does not match how the work actually runs, and it is cheaper to change the basis now than after three months of sorting.
Know how to move things before committing
A first arrangement is never quite right, and knowing the repair steps in advance is what keeps a wrong guess from becoming permanent.
Renaming is done from the Workspaces menu by right clicking the workspace and choosing Rename Workspace. The same thing can be done in the Window Panel, either with two slow clicks on the name or through the right click menu. Changing the icon works the same way: open the menu, click the icon, and pick a new one.
Moving tabs between workspaces has two routes. The Window Panel route expands both the source and the destination workspace and moves tabs by dragging them from one to the other, with multiple selection supported. The context menu route starts on the tab itself, then goes through Move, Workspace, and the destination. Selecting several tabs first makes redrawing a boundary a single operation rather than a dozen.
Creating a workspace directly out of a selection uses the same menu path, ending at Create Workspace with Selected Tabs, which is worth remembering because it turns an unplanned pile into a named group without an intermediate step.
The practical effect of knowing these is psychological rather than technical. A setup that feels expensive to change tends to stay wrong, because every correction looks like a rebuild. A setup where a boundary can be redrawn in two minutes gets corrected as soon as the mismatch is noticed, which is how it ends up fitting the work rather than fitting the plan that was made before the work started.
Test the decision for a week
The setup is a hypothesis. One week of light attention turns it into something measured, and three numbers are enough.
How many times a day the switch happened. How often a switch was followed by hunting for a tab. How much work got done without switching at all.
A high third number means the boundary was unnecessary: those two workspaces could be one. A high second number means the opposite, that a workspace has grown large enough to need Tab Stacks inside it. A low first number across the board means the whole structure is doing less than the effort of maintaining it.
The measurement also surfaces the limit that no arrangement of workspaces can fix. A workspace switch happens inside one window, so the macOS application switcher still lands on the browser rather than on a specific context. From there the workspace still has to be chosen and the tab still has to be found. For someone switching between two accounts of the same service every few minutes, those extra steps accumulate into the largest cost in the setup, and they are structural rather than a matter of configuration.
Where the answer starts to point outside tab organization, the question becomes which services deserve to be always running rather than which tabs deserve to be grouped. The set of services that typically sit in that category is listed under Supported apps, and a side by side view of how another tool draws the same boundary is on Compared with Wavebox.
What to change first
Write down the basis for the split, prune the daily rotation to five, and fix the order so the numbered shortcuts stop moving. If a week of use shows the real cost is switching between two accounts of the same service, the unit needs to move from the tab to the window, which is the model SpaceDeck is built on.
Frequently asked questions
How many Vivaldi Workspaces are worth keeping?
Three to five in daily rotation. The fast switching method is the keyboard shortcut, which is tied to the workspace position, and past four or five the position has to be looked up rather than recalled. Sets of tabs used a few times a month are better saved as Sessions, which can be recalled by name without taking a slot in the switching order.
Should workspaces be split by client or by type of work?
Follow whatever causes work to change during the day. If interruptions come from other people, splitting by client matches reality. If work changes when attention moves from one kind of task to another, split by type. The important part is not mixing the two, because a mixed setup forces a fresh decision about where each item belongs.
Does reordering workspaces break anything?
Reordering itself is a drag and drop, but the numbered keyboard shortcuts follow position rather than name. Inserting a workspace in the middle shifts every number after it, so a familiar shortcut starts opening something else. Either decide the order once and only append at the end, or switch to using Next Workspace and Previous Workspace and stop relying on numbers.
Do workspaces created in a private window persist?
No. Ordinary workspaces are saved automatically when the browser closes, but workspaces created in a private window are removed as soon as that private window is closed. Any grouping that needs to survive a restart should be created outside a private window.