I'm back from SDL Connect (Palo Alto) with lots of notes to process. I'll have more impressions, observations, and news to share but let me start with questions from customers about GUI extensions and backwards compatibility.

Getting Started with SDL Web GUI Extensions

One customer asked about GUI extensions in terms of examples and best practices. They've made some extensions and would like to validate some of their thoughts and approaches.

Starting and Disposing of the Client

Let's start with a point about the Core Service, our typed WCF client for interacting with the Content Manager. Both Peter Kjaer and Eric Huiza point out that though familiar to C# development, "using," isn't quite the right approach. Definitely read Peter's Core Service clients and the "using" statement, which is confirmed in Eric's post and maybe follow-up with a comments or questions on Tridion Stack Exchange.

Core Service Examples

Like a few others in the community, I sometimes find myself searching for SDL Web related information and end up on my own blog. :-) In terms of GUI extensions, I previously gathered this list in 2013:

• Coding Guidelines for the SDL Tridion 2011 PowerTools with some Anguilla examples
• Snippets on the Tridion Cookbook
• Intellisense with JavaScript and the Core dlls
• Some JavaScript development tips on PowerTools

The Latest in GUI Extensions

Within the last year or so since I shared that list, Alchemy, a GUI extension framework that accelerates GUI extension development as well as a free "extensions store" of sorts, is proving popular among implementers. I'm quite excited at seeing the types of extensions that are being requested and developed. I would love to hear from editors that have had a chance to use such extensions.

Community member Dominic Cronin created a Cookbook of examples and practices for Tridion practitioners a few years back. Having seen Tridion Stack Exchange do very well, I wonder if someone would kick off something on Stack Overflow Documentation to continue the spirit of collaboration. Hint: some of the most successful community initiatives have been created and developed within the community and embraced by SDL, which means I won't start something like that but you'll see me there if you do. Of course we'll continue to improve our official documentation, which has evolved from PDFs to a closed online format to the open format you find today on SDL Docs. 

Beyond GUI Extensions

One of the SDL Connect announcements was our work on a Unified Delivery stack between SDL Web and SDL Knowledge Center. We've long had the ability to integrate SDL Web with other systems, but it's exciting to see what this means explicitly to our content management customers for both structured content for documentation and Web for marketing/website material.

Also interesting is a use case from a life sciences customer for Web and how they described their GUI work. To bring different systems together and take advantage of the latest development in .NET, they've been working on an internal (back-office) interface that combines external fields alongside SDL Web fields. This includes:

• NET Core, so they can run this setup on anything for cost savings
• WCF Connected Service

Related to their setup was interest in future APIs as well as a concern about us changing the existing Core Service, which brings me to my second topic about backwards compatibility.

Backwards Compatibility

Let me point our our Web Product Lifecycle on the support page:

"When a Product evolves new functionality may be added or removed. When functionality is removed, a deprecation notice is provided at least one major release upfront prior to removal, ensuring that customers can react and adapt to the changing functionality."

In addition to this we have a four-year support policy that includes fully, limited, and extended support stages before reaching retired (level 4). To achieve this this predictability while keeping the flexibility to fix issues on a supported version, we state:

"SDL customers must upgrade to the latest Service Patch as soon as it becomes available to retain access to future security updates, Service Patches and Hot Fixes."

See SDL Docs for how versioning and backwards compatibility works with the Core Service, including a tip on how to make your extension a bit more future-proof. Indeed, this was one of our first APIs to support this versioning strategy where we maintain the service contract but are free to evolve the data contract. 

Another reassurance is the fact that we use the same APIs you do, meaning that though we may introduce new functionality and APIs, we will to do so in a practical way with ways to go forward. One quick way to know support for a given approach, API, or feature is to see where a given product is in terms of support.

In my user group/developer day kick-off presentation I explained three scenarios:

1. New Functionality - I admitted an early mistake I made as a new Product Manager where I pointed out to our UI lead: "But Tridion doesn't work like that." He of course corrected me and said, "Well, we could build that."
2. (Sometimes) No Changes - I pointed out that for some changes, we can be explicit to "Make it backwards compatible... No rework."
3. Changes with a Way Forward - I wrapped up the presentation with a point that we can change an old approach if the new one is easier or it's clear on how to change from old-to-new.

The Future

That's it for backwards compatibility. Let me end with a point on the future. If you want to see what's coming see the SDL Web Cloud documentation, which includes functionality that will eventually end up in a future on-premise release. Also follow this group and the wider Tridion/Web 8 group on SDL Community. If you want to influence the future of the product, be active and engaged with user groups (congrats to the launch of the SDL Web West Coast user group) or submit your idea on SDL Web Ideas.

Update (2016-11-22): I didn't realize that at least two people described how to best create and close a Core Service client. I added both for proper credit, which goes to both posts and of course to the MSDN articles (like this one) and posts that explained the same. Though some information is "known," in say the .NET community, it's still useful to share in the context of SDL Web because it may be new to our own community.