Truly container-specific essentials (based on current container, not workspace default container)

[nataliepineapple]

TL;DR: It would be great if essentials could be specific to the container of the current tab. The current "container-specific essentials" option is really just "workspace-default-container-specific essentials" and that doesn't suit all workflows.

Long-winded rationale:

At the moment, "container-specific essentials" sets the essentials of the current workspace based on its default container. This behaviour makes a lot of sense in a scenario where workspaces tend to be associated with a specific container, like if you have a "Work" container and a "Personal" container and your workspaces are either related to "Work" or "Personal" activities.

However, containers and workspaces are really versatile and this many-workspaces-to-one-container model doesn't suit all the ways they can be used. For instance, I have a different workspace for each task that I'm working on. In the course of working on a single task (and therefore using a single workspace) I sometimes have to log into AWS, Anypoint Platform, Salesforce, etc. with multiple accounts, which I do using containers. It would be so useful to be able to have the essentials change depending on which container I'm in right now.

As an example, I could have a workspace for an investigation into a specific bug related to integrations. While in that one workspace, I could be in an "Integration A" container tab and the essentials would be things like documentation about that integration, a service health dashboard, and the GitLab project for that integration - all right there on speed dial anytime I'm in an "Integration A" container. Then I switch to an "Integration B" container tab, and suddenly none of the Integration A essentials are really relevant. Now I want quick access to different pages because of the different context of this container. But the workspace isn't changing because I'm still investigating the same bug.

[nasserd]

It seems there's a fundamental misunderstanding of how Workspaces and Containers are different.

Workspaces allow for your set of Essentials and Pinned Tabs (and active tabs) to be separated based on your workflow.
Containers are security-proofed sandboxes within which functions/tracking/cookies are isolated from all other browser functions.

Your Workspace can be a no-containers space, a default container setting (for new tabs always open in this defined container), and a multi-containers space (so even every tab is isolated from each other... as isolated as you have configured containers).

You can also force that every new tab must have its security container determined before actually opening that tab (to maintain its isolated sandbox). Because a container is inherently an isolated sandbox from the rest of your browsing experience (kind of like Private Mode which is really a pre-defined "forgetful" container), changing various elements of the UX in this manner would be very confusing with the Workspace paradigm finally becoming mainstream across all OSes.

The power user scenario described does sound like something a Firefox Extension might be better suited for (the activation of a container could trigger additional UX customizations as defined by the power user but it's beyond the scope of a standard user browser).

[nataliepineapple]

Yeah I definitely take your point about UX. I figured that a potential pushback to my idea would be the way that tabs could appear to "jump" when switched to, because the number of essentials had now changed and pushed the regular tabs up or down accordingly.

I think the paradigm shift you're concerned about has already been implemented though. Under the default model, workspaces are sets of visible tabs, pins are per-workspace, and essentials are like enhanced pins that aren't tied to workspaces. Simple, and an improvement over standard Firefox/Chromium. But the "container-specific essentials" option upsets the applecart, because under that model your essentials now vary based on context. It's definitely a power user feature, not just because it changes the paradigm but also because in order to make it "do" anything, you need to have enabled containers, set the default container of a workspace, and enabled container-specific essentials. All three of those steps alter the way you use the browser, so a level of intentionality can be inferred.

I'm just proposing a tweak to the context-based model that users can choose to opt into. Instead of "essentials are tied to the default container of the current workspace", it's "essentials are tied to the container of the current tab". A user choosing between either of these two options has already opted to change the model considerably, so I don't think it would hurt to offer them the choice of how they'd like it changed.

If Zen doesn't want to offer this functionality - either as an option in the UI or an about:config flag to modify the behaviour of the existing "container-specific essentials" option - then yes, an extension is probably the way forward. (In that case though it makes sense to have the current option renamed, because it's called "container-specific essentials" but it doesn't make essentials specific to containers.)

[nasserd]

100% agree that there's an issue with needing to disambiguate what Container-specific Essentials actually means! It is indeed a little messy with the phrasing although there's logic in there that meets your use-case!

The current setting should probably read, Workspace-specific Essentials (Workspace must have a defined Container)

Hmm, I wonder if there is a hook upon tab selection (besides just changing the aesthetic of the active tab) that exposes the container details that could then trigger the Pins to change accordingly -- and this would result in the desired container-specific UX changes. (There's already logic to swap workspaces when a tab is 'changed' so there's logic to make some changes...)

As for the paradigm shift, I'm not referring to programming but actual Users uptake! Gradually as new persons are getting into a field they're acclimated to a different workflow structure (i.e. multiple workspaces, multiple desktops, multiple work areas) -- but older persons take more time to adapt, or simply move along in their ways (i.e. single-window, few-tabs, no containers/workspaces, single desktop, 1 email account). We're at a point where "everybody" (a seeming majority in my experience) can easily wrap their heads around a multiple workspaces/desktops/workflows environment but the sandboxing of containers is still an elusive jump.

In this vein, and after sleeping on it, I agree that the disambiguation is important now - so it lays the groundwork for more powerful use-cases without necessarily forcing yet-another-extension upon the users :)

[nataliepineapple]

At the risk of going off-topic: I wonder if the way to make all this more intuitive to the average user, and to give users more control over how essentials interact with containers/workspaces, is to rebrand the association as "tagging". Tagging is a familiar concept to lots of people, it's used a lot on social media etc, and its whole purpose is to let the user say "this thing is conceptually linked to other things that have a matching tag."

So what if you could assign tags to workspaces, containers, and essentials? When you're on a tagged workspace you only see the essentials that have matching tags. The same would be true in a tagged container, so if you're on a workspace with the #work tag and in a container with the #clientname tag, you see essentials that have either the #work or #clientname tag. It would be easy enough (from a UX point of view) to extend this to tab groups once they arrive, so you can tag a tab group for even more control over which essentials are displayed in which contexts. And the best thing about that approach would be that it doesn't burden users who don't want to interact with it; if you don't tag things, then you just see all your essentials all the time, which is the default behaviour now anyway. Meanwhile tagging is a discoverable and intuitive concept for those users who do want to tweak their experience, and Zen can cater to those users' specific requirements without needing to have built-in support for several distinct paradigms.

[nasserd]

Not off-topic at all. In fact, it would align with how workspaces/containers/essentials are currently managed! I took the liberty of digging into the code (forked the repo) and found a lot of the logic in src/zen/workspaces/ZenWorkspaces.mjs

The current method is to filter the appropriate Essentials from the collection of tabs based on the Workspace and Container identifiers. Throughout the code, container identifiers are children properties to a workspace property (or object, not entirely clear yet).

By adding the tagging property to Essentials, and activating a new "Filter Essentials by Tag" flag/setting, the logic could bypass the current Workspace+Container filter and simply return a set of Essentials. During the rendering process, it would sort them based on their existing ordinal position and/or container ID (and each would be colored to their respective default container). In this way, a Workspace could have several containers (due to the tagging filter).

The only sticking point is how to define and select the tags.

Would it be a knockoff of the "Add/Move/Send/Change Tab to " workflow (context menu + child options) which currently drives the Container properties of existing Tabs (whereby their Workspace is the parent property), but it gets messy and uses a clunky Settings panel to manage workspaces and containers currently (and tab groups are too ephemeral at the moment also)? Or should it be a refactored/unified multi-purpose floating configurator for these things? Or a snazzy side panel variety that's just the Tabs Management configurator?

Hmm, so many options! Any ideas? 😃