I'm working with Senior Technical Writer Julie Landman to introduce the Data Integration Service* to a future version of the SDL Tridion/Web overview diagram.
*The Data Integration Service (DIS) is the tentative name to a new microservice we're developing as part of the next SDL Web/Tridion release. Scope, details, and feature names subject to change.
So far we've come up with this draft.
See the current diagram for reference. We're trying to keep the same breadth and depth of information, balancing completeness with detail. Though we needed a small change for DIS, we have an opportunity to apply more P.A.R.C. design principles to a familiar diagram.
As I describe changes to the current documentation, I want to be clear that I have the utmost respect and admiration for our technical writers' ability to translate developer notes across the years and teams into consistent and clear documentation. Personally, I used to keep the printed Tridion R5.3 manuals in a binder and later on in a digital format on a Kindle. By the time I was a functional consultant, I was applying the same styles and writing conventions to my own deliverables and blog posts.
You may notice the use of proximity, alignment, repetition, and contrast (P.A.R.C. or C.R.A.P. design principles, if you prefer) in the following adjustments.
The original diagram showed how a capability like templating was related to Content Management and the TOM.NET API through lines. But I asked if similar or related items could be grouped and listed together. Could proximity help replace the numerous lines in the original diagram?
Julie came up with this arrangement to show, for example, that capabilities like Templating and Event Handlers use the Tridion Object Model (TOM.NET) API.
Though you can see the same elements in the original diagram, it might be hard to list elements that are related to each other. Julie grouped Building Blocks according to purpose and persona and aligned related APIs.
Elements in a given group are ordered by size, importance, or frequency of use.
APIs are listed under CM and CD sides within the same dashed border. Capabilities (e.g. "GUI extension") are shown in grey, shaded boxes.
In terms of contrast you might notice:
You might notice the resulting fewer lines as well as some recycled ideas from some of my old blog posts :-)
In a previous blog post, I described the Functional Design process and how CM features relate to CD functionality using this diagram.
We didn't create an exact mapping between CM and CD in the proposed overview diagram. But note how TOM.NET and the Content Service are listed first as essential APIs you might work with in CM and CD respectively. There's also a parallel between the external-related APIs of ECL in the CM and DIS in delivery.
Because Tridion separates content from classification and pages for modular re-use, translation, and localization, it has different types of "folders" for various types of items. I shared this relationship between building blocks with Julie using my Tridion icons post and this cheat sheet of sorts.
I've also described the hierarchy and dependencies between Tridion items in a post about Top-Down vs. Bottom-up CMS Design.
Though I was quite proud by my geeked-out two-dimensional relationship matrix and animated gifs, they're probably overkill (and wouldn't really fit) in the overview diagram. Julie worked out something flatter and easier to read, which seemed like a better fit.
Note how the Tridion items are grouped into Organization & Classification, Editorial Items, Design & Development, and Administration.
In terms of ordering items related to Organization & Classification, you might know that:
This order is reflected in the diagram. Similarly, we tried to group the other items by relationships or size.
Editorial items are ordered by size and relationship where:
The organizational and editorial items are the most important for editors and likely the most visible when first working with a Tridion system. Next Julie noted the items related to design, development, and administration.
For Design and Development items, you might understand that:
For the last grouping Julie we use the term "administration" to describe items related to the administering a CMS, rather than the administration part of the UI. Note that as of SDL Web Cloud and SDL Web 8.5, you don't have to be an actual Admin to manage system lists such as Multimedia Types or the Workflow Approval list (see my posts on Privileges).
I hope the new diagram better reflects:
Like any sophisticated system, Tridion has a lot of parts. But this kind of complexity doesn't necessarily mean it has to be difficult to explain or understand (see Complex is not difficult by Bart Koopman
It's been great acting as a subject matter expert as Julie re-imagined the overview diagram, working with several stakeholders to create better and clearer ways to describe these familiar concepts.
What do you think of the proposed overview diagram? How have you used the current diagram and its past iterations? Do you have your own favorite diagram to introduce SDL Tridion/Web? Leave a comment below! Join the discussion!
Let's continue the discussion here: community.sdl.com/.../14517
Now for a second comment on #4 regarding where/how Blueprinting should be represented. I am not certain how it ended up in D&D, but agree this may not be the best place. I do think it needs to be included though, even if it is a logical structure. As I am considering it again now, I think that it should be an organizational item. In fact, this is where the options/ribbon for it is located in the Explorer toolbar. Furthermore, the label should be "BluePrint Hierarchy" to match what is is in the user interface. Thoughts?
Hi Ron. Julie here. Thanks for your feedback! I have a few thoughts to add to Alvin's.
We are all totally in agreement on #1 (obvious) and on #2.
On #3, I'm not quite certain we are thinking about this from the same perspective. Indeed, schemas are selected by Editors when working with pages and components, but I think the reasons they were put in the Development and Design category is that they do not themselves represent content. Basically, I saw the Editorial Items category as including the things that the Editor role has primary responsibility for as an author/creator/editor. Would Editors be the creators of the schemas? I thought that schemas are pre-existing from an Editors point of view, and that someone else, someone more technical, would have created them as part of the D&D role/phase of implementation, but perhaps I am wrong about that.
Good catch and nice suggestions. I'm wondering why we had BluePrinting in the original diagram. Perhaps it was to let new users learn about this very important concept even if it didn't have an actual "item" in the system? We might want to keep it somewhere in the diagram.
Schemas definitely relate to Editorial Items, especially since editors select them and they define fields for Components and Pages. But editors also select templates so I'm thinking Schemas are still a development "thing."
My initial feedback:
1. Rename "DreamWeaver Templating" to "Dreamweaver Templating"
2. Move "Publications" into "Organization & Classification"
3. Move "Schemas" to "Editorial Items"
4. Remove "BluePrinting" from "Design & Development"