Google Tag Manager Updates (II): User Interface
In our previous post we talked about Workspaces, the main change introduced in the latest update (August 2016, to be precise) for Google Tag Manager. Now we’re going to have a look at the rest of the changes.
Specifically, the update included a complete redesign of the user interface, so that now, although the internal structure of GTM is more or less the same, the way in which we work will change a little. Hopefully for the better 🙂
1. New design: Goodbye colors, hello panels
The new design is a little more responsive (although not entirely: it degrades better, but only up to a point. It remains desktop (or, at most, tablet) oriented, and although it still sports an overall clean, “neat” look as expected from a product of its time, it’s now less about colors and blocks/bullets and more about movement and three-dimensionality.
Or in other words: sliding panels. Sliding panels everywhere.
Basically, the majority of actions that are likely to bring up a new window, screen or control panel (e.g. an editing interface, a list, a selector, etc.) now bring up a sliding panel on the right-hand side of the browser window, which superimposes itself over the content being displayed – but without making the content disappear or making the page reload.
As well as saving time in terms of loading and waiting (given that virtually no action generates complete page reloads; not even changing from one section to another), this change makes the editing process easier and more dynamic, because at any time we can choose to close the current panel and return to the one immediately prior, or alternatively open a new panel on top of the current one without closing it (and thereby needing to save/reject changes or reload information).
For example, it’s now much more convenient to create or edit a tag and its related triggers and/or variables all at once, in any order, because we can leave it half-edited and come back later. Nor do we have to save or reload at each step.
2. General interface and header
As soon as we begin a session in GTM we’ll see the updated header with its new logo and a design that aims to be more consistent with the rest of Google’s apps.
On the left we have the main menu with the four usual tabs. To the right is an app menu with links to Google Analytics and the other related tools, plus an account selector shared with other apps that will finally allow us to have several user sessions open at the same time and switch between them 🙂
Once we’ve selected a container, the Container tab will now change its name to Workspace, and instead of the old draft we’ll be taken to the current Workspace (if there are several, we’ll be asked to select one first; more on Workspaces here) and the new Overview page, which has also been redesigned.
This screen provides at-a-glance information about the currently open Workspace, the currently published version and the most recent version of the container, along with any notifications regarding updates, synchronization or conflicts between versions and Workspaces, plus the opportunity to select and manage them.
The change history, meanwhile, has been divided into two sections: we now have the usual chronological Activity History, plus a new Workspace Changes section, with a full and editable list (we can view, compare and/or undo any change individually) of differences between the Workspace and the corresponding version of the container.
This dual list is also displayed when we create, publish or view a version.
The rest of the tabs in the main menu (Accounts, Versions and Admin) remain more or less the same.
However, we should mention that in Versions, the information that’s displayed when we view any of the versions created is very complete, and even includes the dual Changes/History list we mentioned above:
Among the different options available, and apart from the usual suspects (Publish, Preview, Export, etc.), the Edit as New Version option has become Set as Latest Version, and the process is now slightly more complex…
…because a copy will now be made of the version that has been set as the new latest version, which in turn will require the corresponding update and synchronization operations with all of the existing Workspaces.
For this reason, GTM displays a confirmation dialogue that makes it very clear what will happen, in order to stop anyone from putting their foot in it accidentally! ;P
Let’s go back to the container-editing process. In the Tags panel in the Workspace, notice how the list of triggers is no longer categorized by color. Instead, the type of event is now identified using icons:
The use of icons for categorization, like the sliding panels we mentioned above, is across the board. For example, when we create a new tag, all of the available tag types (a list that keeps expanding, by the way!) are shown in a unified format in a single panel with a built-in search function:
The rest of the editing process is the same, except for trigger selection, which has also been revamped.
From here we can add (+) or remove (-) triggers and exceptions. The “Add Exception” link at the bottom will only appear when there is at least one trigger.
When choosing a trigger, the previous selection by event type has disappeared (and good riddance, in my opinion, as it was awkward and slow) and we are taken directly back to a full, filterable, informative list:
We can also edit any of the selected triggers directly by just clicking on it. This is done in a new panel, which is superimposed onto the other in order to prevent the changes from being lost.
Similar changes have been made to the Triggers and Variables panels, respectively.
When we create a trigger, we select the type from a full, ordered list, complete with icons:
The rest of the conditions are added as Filters within the trigger itself, along with the “Enable When” section for events corresponding to link clicks and forms.
It’s surprising that they haven’t taken the opportunity to rethink the way this is handled, because the fact that it’s not even filled in by default is still confusing, or at least inconvenient, for many users…
In the Variables panel the attractive pane of Built-In Variables has been replaced with a more conventional dual list. Once again, bye-bye colors…
Instead, if we click on Configure Built-In Variables, we get… yes, that’s right, a panel with a categorized, filterable list ;P
Interestingly, we can click on a built-in variable as if we were intending to edit it, in the same way that we can a custom one. Clicking on it doesn’t allow us to modify it, but it does tell us how it’s defined internally (i.e. type, associated data layer variable, etc.):
We’ve already seen the new advanced selection panel that’s accessed via the tag editor when we want to select a trigger.
One thing we haven’t mentioned yet is that we’re shown a similar panel whenever we want to select a variable to use in a field or condition.
In both cases, we’re not only able to select it, but also to view and edit any trigger or variable immediately (by clicking the Information button on the right), as well as create new ones (+), all without leaving the panel.
For variables, we also have the option of enabling or disabling built-in ones (by clicking on the Built-Ins link) immediately.
And that’s not all. In the same way that we can directly access any of the triggers or variables from within the corresponding tag, the same is also possible in the opposite direction.
When we access any trigger or tag, a list of all the tags (and/or triggers) that use it can be found in References at the bottom of the screen:
Likewise, each of these tags or triggers is also clickable and editable directly from this panel, meaning that everything is interlinked. And this is always done via new, superimposed panels, so at any time we can go back, forward or elsewhere during the editing process without losing our position.