Detecting language please wait for.......
As we get ready to finalize and release SDL Tridion Sites 9.5, we've been getting a lot of questions and perhaps some confusion over what the new editorial experience means for customers and their editors.
First, see my demo for the latest overview of the new experience. Then to help clarify when and how you should adopt SDL Tridion Sites 9.5 and its new user interface (UI), I'll address three points in this post:
For customers who adopt the new UI, many of their editors will be able to use the new UI on its own. Like the current, or soon-to-be "Classic" UI, this additional user interface is a web application, hosted by customers or SDL that connects to the same Content Manager backend, through a new RESTful API.
This overview slide shows how the new and old UIs will work side-by-side:
Editors in the new UI will be able to:
In practice, I would expect customers to fall into three categories:
For all customers, I highly recommend taking advantage of the new experience at least with some experienced and perhaps new editors. First of all, the installer options for on-premise customers will let you choose whether you want to deploy the new UI or not. I recommend at least installing it in some environments because:
Though we’re not doing any “forward” shortcuts from classic-to-new, the New UI will have a shortcut to the Classic UI under the user profile settings.
Some items will link or open the Classic UI as needed, such as Schemas and other technical item types. Purely technical screens will only accessible through the Classic UI for now.
Keep in mind that to focus on the main editorial experience, we did not include all of the product features and add-ons nor address technical screens for implementers in this additional UI yet. For example, activity lists and several queues will remain in the classic UI for now. Authorization settings, schemas, templates, and system settings will all continue in the Classic UI. This brings me to the topic of GUI Extensibility.
Unfortunately, I've heard some hesitancy when we mention there's no GUI extensibility yet for this new interface.
I think this is unfortunate, considering the time and effort we put to improve the editor's daily experience for finding related information, making updates, and working with rich or formatted text. We have adopted several popular community GUI extensions and ideas directly into the product while ensuring the classic UI GUI extensions and most other extensions continue to work. See Anton Minko and my presentation from the Tridion Developer Summit, summarized and referenced in this post.
The Classic UI will continue to work alongside the new, additional UI. Also, existing (non-UI) extensions will continue to work such as event system automation or custom resolver, deployer, or storage extensions.
Here are some out-of-the-box capabilities that possibly replace GUI extensions a customer might have.
Note: final features and details are subject to change. This list is based on the solution as of April 18, 2020, and may change as we finalize the release currently planned for mid-2020.
GUI extension for "publication search" (such as this one from Saurabh Gangwar) and Publication type filter buttons.
Improved, touch-friendly table list view with:
The list view moves the publish and "lock" icons into a new column for clearer visibility and to allow filtering on these statuses.
A new Schema column replaces the item type column, to let editors know the specific Schema set for a given item or folder.
The "from Publication" column now lets a user jump to the parent or "owning" Publication for that context, saving editors some time moving between Publications.
Also, Tridion Sites 9.5 introduces touch support for 9.7" iOS devices.
These updates would replace customizations for:
Though many of our expert users have grown used to the ribbon toolbar, we still regularly find users aren't aware of certain features, especially for the options to view more information or relationships for a given item.
To take advantage of increased screen resolutions (where we've seen at least one editor with a monitor width of 2560 pixels), we're introducing a third (collapsable) panel to offer insights into a selected item. This includes things like item information, version history, and where used relationships.
This simplifies the command bar and context menu to "actions" helping simplify where to find editorial actions versus the item viewers.
This improves on existing item viewers, removes the templating preview views, and replaces the need for GUI extensions offering more information on demand (such as "Peek" by Peter Kjaer, which was cited by UX leadership along with the challenge, "why can't we do the same?").
Though not all insights properly information is visible in the table list view columns, this "on-demand" information can help replace the need for GUI extensions that offer information such as:
Many customers often represent data in a table format with the need to control the structure of the table and manage accessibility features.
Though Tridion Sites has these features, the new table editor improves a bit on the experience and ease-of-use of managing tables in formatted rich-text
Browsers often handle markup in different ways. For example, the ENTER key might be interpreted as a paragraph mark, line break, or division (<p>, <br>, or <div>, respectively).
Though we've introduced functionality to help with these differences, the new interface does away with the XSLT filtering to instead handle markup more consistently across browsers.
As a security measure, browsers prevented programmatic access to the user clipboard. The new UI's rich text editor detects if it can paste when the user presses the button. Otherwise instructs the user to instead use the keyboard shortcut.
Though custom XSLT filtering will still apply when editing in the Classic UI, these are not needed and do not apply in the new rich text format area.
Existing ways to otherwise transform markup through the event system, templating or application logic will continue to work.
This likely replaces GUI extensions that address styling consistency or word markup.
Before editing content, users need to choose where to edit (globally or in a local copy). However, historically the edit action assumed the user wants to make edits on opened items.
To make the choices clearer, off "in-context" editing of content in pages, and defer the editing choice to when the editor wants to make a change (and drop the less relevant content manager "preview" feature), we moved the editing choice to within the Component form editor.
This editing flow also includes the prompts to start or take ownership of items in a workflow as well as finish basic workflow decisions within the same screen as the Component. Note that option to add items to a bundle will not yet be in the New UI for Sites 9.5.
This change will allow new and experienced users the ability to more freely explore and view content and pages, without needing to explicitly be careful to check items in.
I expect this along with improved icons for item status would reduce, but perhaps not quite eliminate, the need for customer reports and other mechanisms to track checked-out items.
Multi-lingual and multi-channel requirements often mean managing how and where you create and then publish content across Publications.
The publishing dialogue consolidates, clarifies, and simplifies the publishing options and introduces the ability to selectively publish to child Publications, with or without the current Publication.
The improved publishing dialogue will likely reduce the need for GUI extensions or customizations related to controlling how items are published across the BluePrint.
Tridion Sites offers the ability to manage simple-to-complex content models with constraints on the allowed text, numbers, selections, and values.
The New UI gives editors the ability to show/hide sets of embedded fields as well as an inline error message for invalid content entires and more information on what kinds of selections are allowed for a given selection.
These improvements should replace or reduce the need for customizations related to showing/hiding sets of fields and inline validation messages.
Thanks to the Tridion Sites implementer community and those who submitted ideas on SDL Community Ideas for Tridion Sites for inspiring and requesting many of these improvements. To be clear, we regularly review community ideas, though there isn't always a clear step-by-step process to move a given idea into the product (read more on product ideas). We did many things in parallel, from the inside-out when solving similar problems. But the context, examples, and validation from our community guide our view of our product and users.
The new UI will not show configured Custom URL pop-ups nor custom rich text format area extensions from the Classic UI. This means editors would need to either edit such fields in the Classic UI instead or manually input or change the content accordingly.
For example, if you have a GUI extension to insert a code from another system in a Custom URL pop-up (e.g. department ID, geo-coordinates, or some other "lookup" value), an editor could either manage the Component in the Classic UI to get the Custom URL pop-up or paste in the value in the New UI. Similarly, if you offer a custom button to insert a specific type of Component in a custom rich text format area button in the Classic UI, for now, editors would need to insert those specific Components themselves in the new UI.
This kind of extensibility is still interesting for us, but because we've introduced both new RESTful service and UI code in this first release, we want the flexibility to change either before exposing them as public APIs.
Though we started our investigation into new user experience and UI architecture with Experience Manager on the premise it would offer the most value in the least amount of time, we quickly learned and recognized that:
So mid-project we pivoted to apply everything we learned technically and from feedback on the new Experience Manager to a revamped Content Explorer. And though I'd love to have both a new Content Explorer and new Experience Manager, the timing of the release makes a new new XPM something for a follow-up release.
The key difference, however, is we will not introduce yet another separate UI for "new XPM." Tangibly this means when introduced, the in-context editing experience will:
Despite postponing this in-context editing feature, SDL Tridion Sites 9.5 will introduce a different "in-context" page editor that we'll save for a follow-up topic. :-)
We've kept our editor's needs as the guiding focus for the requirements, UX research, designs, and implementation of this additional new UI for Tridion Sites 9.5. I hope and encourage our customers and their implementers to do the same—to revisit what your editors are trying to accomplish as you consider how to adopt Tridion Sites 9.5.
I hope this clarifies the current scope of SDL Tridion Sites 9.5's additional UI and gives you some good reasons to check out what we've been cooking. If you're still looking for specific ingredients, be sure to follow updates on SDL Community, join SDL Ideas, and reach out to join our customer research program. I intentionally skipped a few improvements to give my colleagues something to share. Also, stay tuned for more information about SDL Tridion Sites 9.5 non-UI features such as delivery-side search, improved content manager performance, and the next steps for headless content management and delivery.
Stay safe, be well, and get ready for SDL Tridion Sites 9.5!
That is amazing!! Great post Alvin. Looking forward to the 9.5 release now
Thanks! And thanks for the support, examples, and feedback as we researched and built the new experience!
Great blog post, Alvin. I strongly believe that this new editorial experience will significantly help existing editors and be a big draw for new customers. Really looking forward to the 9.5 release now. Keep up the great work!
Thanks, I uploaded a new image and fixed a few more. Cheers.
Great post Alvin! The first image is not clear and distorts on zooming, please update if possible.