Workspaces
- Overview
- Available workspaces
- Starting the editor with a workspace
- Switching workspaces
- Workspace callbacks
- Use cases
Overview
In user interfaces, a workspace is a parameter that changes the appearance, settings, and widgets available in an editor, to help the user to focus on what matters.
In BEE Plugin, workspaces are an optional parameter that can be used to provide an experience focused on context and purpose, and to facilitate the outcome of an editing session.
You can load the editor with a certain workspace, but workspaces can also be changed by the user when editing, on-the-fly.
Switching between workspaces might change:
- content visibility on the stage
- tiles availabilty in the content tab
- available previews
- outputs when saving a content
- …and more!
Available workspaces
If no workspace is loaded at launch, BEE starts in its “Default” workspace.
We currently offer 3 additional workspaces, and we are planning to launch more as we evolve BEE and its capabilities.
These 3 workspaces revolve around the use of AMP content in BEE, and are provided so that you can tailor the experience of creating AMP emails in BEE.
Here is an overview of the different workspaces and their differences. Please refer to this page for more information on using AMP in BEE.
default | mixed | amp_only | html_only | |
---|---|---|---|---|
Stage message | HTML content | HTML & AMP content | HTML & AMP content | HTML content |
Content tiles | HTML content tiles | HTML & AMP content tiles | HTML & AMP content tiles | HTML content |
AMP sidebar properties | No | Yes | Yes | No |
Available in preview | HTML content | HTML & AMP content | HTML & AMP content | HTML content |
onSave callback files | HTML | HTML & AMP | HTML & AMP | HTML |
Loading a template with AMP content | The onWarning is triggered | Template loads | Template loads | Template loads |
Loading a template with HTML content only | Template loads | Template loads | Template loads | Template loads |
Availability of the hide on AMP/HTML property | Not available | Yes | Yes | Yes |
Behavior for hidden for HTML/AMP content | The onWarning is triggered | Both are visible | Only “hidden for HTML” content is visible | Only “hidden for AMP” content is visible |
Starting the editor with a workspace
Here is an example of loading BEE Plugin with a “mixed” workspace:
type ClientConfig = {
workspace?: {
type:'default'|'mixed'|'amp_only'|'html_only'
}
// ....
}
const beeConfig: ClientConfig = {
workspace:{
type:'mixed'
}
// ....
}
//Create the instance
function BeePlugin.create(token, beeConfig, (beePluginInstance) => {
//....
}
Switching workspaces
You can implement a workspace selector within your application, so that users can switch between workspaces, by using the loadWorkspace(type)
method.
First, you need to define template files for the workspaces you want to propose, as JSONs:
{
"type":"mixed"
}
Then, you can load those workspaces at runtime:
type Workspace = 'default'|'mixed'|'amp_only'|'html_only'
const req = url => fetch(url).then(r => r.json())
const loadWorkspace = async (workspace:Workspace) => {
const { type } = await req(`https://example.com/workspaces/${workspace}.json`)
beePluginInstance.loadWorkspace(type)
}
And here is how to create a simple select to switch workspace:
<select id="workspace" onchange="loadWorkspace(this.value)">
<option selected="selected" value="">WORKSPACE</option>
<option value="default">DEFAULT</option>
<option value="mixed">MIXED</option>
<option value="amp_only">AMP_ONLY</option>
<option value="html_only">HTML_ONLY</option>
</select>
Workspace callbacks
After you load a workspace, BEE will trigger one of these three callbacks:
Success
//SUCCESS
onLoadWorkspace: function (workspace) {
console.log(`workspace: ${workspace} has been loaded`);
},
Failure
//FAILURE
onError: function (error) {
console.error('error: ', error);
},
Invalid workspace
{
code: 1400,
name: "Invalid workspace type",
message: "RANDOM : is not a valid workspace",
details: "Available workspaces are: [ default,mixed,amp_only,html_only ]"
}
Use cases
The additional workspaces for AMP (AMP-only and HTML-only) can become helpful if you want to tailor the user experience of creating AMP emails, by adding:
- a workflow where users decides if they want to create a standard message or an AMP-powered message (in the first case, AMP components will be hidden in the editor);
- an option to switch between the HTML and the AMP editing of a message.
In addition, omitting the workspace, or loading the “default” workspace for certain users, has the effect of disabling AMP for those users, even when AMP content is enabled in the developer portal. This way, you can decide to make the feature available to customers of your application:
- depending on the subscription plan that they are on (i.e. you could push users to a higher plan based on the ability to use AMP);
- depending on the purchase of an optional feature (same);
- only if they are “beta” customers, so they see it while keeping it hidden from the rest of your users.