A project window-group name should tell you which result the windows belong to before you inspect them. “Chrome,” “Work,” and “Project 2” describe containers or vague categories; they do not distinguish the outcome you want to resume.
Build the name from an outcome
Start with the deliverable or decision, then add one detail only when it separates similar work. A compact pattern is object + outcome + stage.
| Weak name | More recognizable name |
|---|---|
| Client work | Acme homepage revision |
| Research | Window-switching source review |
| Website | Wallo article library launch |
| April | April invoice approval |
The stronger names do not need to contain every property. They expose the clue you will search for later.
Run the same-app recognition test
Imagine two browser windows, two documents, and two Finder windows from different projects. Hide their contents and look only at your project names. Can you select the right group without opening both? If not, add the missing distinction: client, deliverable, environment, or stage.
Avoid using an application name as the project name. The application is already visible elsewhere, and the same application may serve several groups. Also avoid status-only labels such as “Urgent” or “In progress”; status changes faster than identity.
Keep names short and stable
Put volatile details in tasks rather than the group name. “Acme homepage revision” can remain stable while the next action changes from collecting feedback to exporting assets. A date belongs in the name only when it is part of the identity, such as a monthly close, not merely today’s date.
Review names when two groups become hard to distinguish, not on a fixed renaming schedule. Wallo lets you name a goal, but it does not rename the windows inside other apps. If a browser or terminal also supports its own window title, use that title as a second clue rather than assuming one label propagates everywhere.