Showing posts with label tridion. Show all posts
Showing posts with label tridion. Show all posts

STRI, DXA, Jumpstart, TBD Bootcamp

One of my earliest SDL bootcamps was for SiteEdit User Interface Update for SDL Tridion 2011 Experience Manager. The session was great and the product renames were also quite fun.

This week some of the team had a short two-day internal session covering the Standard Tridion Reference Implementation (STRI), also called the Digital Experience Accelerator (DXA), and possibly soon-to-be-called something-else-yet-to-be-determined. Check the now open SDL Documentation Center for the latest-and-greatest official name.

At a high-level, without giving away trade secrets on this open source project, we had a few familiar names and topics:
  • Peter Joles described the Customer Experience Cloud (and gathered the team together, much appreciated!).
  • Bart Koopman and Will Price went over STRI.
  • Eric Huiza explained SDL Mobile with STRI.
  • Angel Puntero and Jan Horsman covered some setups, examples, and code.
  • I also presented on a "jumpstart" guide that would help us use the guide.
Unfortunately, I had to catch a flight and missed most of the last presentation from our CXC Web team. I won't add too much to these topics so I won't take away anything else these sharers might share or have already shared (see below). These were internal sessions after all. In this post I will:
  • Comment on how TRI is different than past "in-a-box" implementations
  • Share some functional tidbits I noted during the workshops along with screens of how I made a diamond BluePrint (exciting I know), and
  • Give you 50 ways you might share about STRI.

This Time is Different

For long-time Tridionauts, you might recognize this as the latest incarnation of previous versions of the-One-implementation.


[Insert witty comment about past incarnations of The One Tridion Box Implementation]

Box-Making is Hard

The concept of an example implementation for Tridion or any other system is not new. I even came up with the idea before joining SDL in a class assignment. The challenge with any example is confirming what kind of box you really want.
  • Partial or full box? Is it (just) an example that others can learn from? Should it be feature-complete and include every possible example? Or maybe it should be familiar and accessible for those new to the box? Can you tell I'm suggested one approach is better and probably more practical than the other?
  • Alice-in-Wonderland, self-documented box? For a document or system that stores content, are the instructions in the system itself like WordPress's Hello World example starter page? To you put "open here" on the box or in the nice little guide that comes with it? Once you have an example, people will ask how to get rid of it. Though you should probably still have the example.
  • Box maker or box example? For something as simple as a Word Template, is it the actual Style Set and Word Template, or is it an example Word Document? Does everyone know what a Style Set is?
  • Instructions included with the box? Maybe you need both the template as well as a guide on how to use the template? Does such a style guide go in the box? And do you have a style guide on how to build and extend the box?
  • Free box? Do you sell the box? Or do you sell services on how to use the box? Or maybe the box is free when you buy the box parts? Do you license the box? To partners? Directly to customers?
  • Caveat emptor in-a-box. What's the warranty? What actions invalidate your warranty and need the label "no serviceable parts?" How can users extend the box? What if the box gets wet but customers try to hide the water indicator?
  • Partner-friendly box? If your services help people set up their own boxes, is your box an accelerator of sorts? Or maybe you'd call it a toolkit?
  • Engineered box. Who makes the box? Would you want Microsoft engineers making the ultimate Word template? Not that they're not qualified or have the skills, but engineers might not use Word in the same way, depth, or pace as typical users use Word.
  • Box personas? Who's the typical user? Power User? Word guru? Do you need box personas?

Omni-Box?

The One True Box needs to address all of the above. It needs to be familiar and accessible to new box owners while following "best practices." It can't be everything and you probably want the box out quickly, with the ability to reconfigure the box as fast as people start using the box.

As a customer circa 2008, I might have seen references to Editions and Foundations, but honestly there was so much to learn and implement with Tridion that checking these out was the last thing on my mind. I don't know exactly who was involved, but I'm sure the approaches and code live on in today's customers and now out in the community. Looking back, I'm partial to the names.

WayBack Machine can find all sorts of interesting things. Two Editions of Tridion?

Ah, R5.3. I miss you. Mostly.
More recently, my peers worked on an accelerator package called Spark. Built by professional services, it reflected approaches and examples from several of my colleagues.

As we worked on it, I wondered if we could do two things with Spark:
  1. Could we maybe open source some aspect of the implementation? We couldn't at the time, but we started it internally and got a nice setup started rather quickly. I might ask Team Spark to "reinvest" some of that Spark goodness as Tridion Reference Implementation modules.
  2. Could we run a contest for the front-end design? Our technical specialties have historically been Content Manager and Web application code related to it (XML, XSLT, C#, Java, etc.). One of the selling points for "enterprise" content management is that the generated output is flexible: historially you can (should) bring your own HTML.
For those wondering (Paceaux), I did get approval for the contest, but we had changes in staff and the Standard Reference Implementation was released.

The challenge for a professional services organization is our main goal is services. So though we have the skills and motivation to make awesome boxes, it almost takes a different type of organization to make a widely adoptable box.

So with different past iterations of the One True Box, what makes the Standard Reference Implementation (4 Tridion) different?
  • Good defaults, with the option to change, including a Content Provider (the MVC setup piece that well, provides your content model) that has community parts (DD4T) to two options for Navigation (localizable titles or titles-from-item names). With the freedom to change or build upon parts you don't need, Will Price recommended keeping the original parts for reference. It's like modifying a toy or car, you probably want to keep the original parts or an example, just in case.
  • Current roadmap-friendly, practices. This reflects what Tridion will be like in 2015 and beyond. Even back at SDL Innovate 2013, Product and Technical Account management (and a few others) recognized a Web-developer-friendly, current-practices approach is needed. There was even a tech demo with a mutant Tridion cloud setup with no CD API, just a MongoDB backing an MVC application where templating was as easy as Article.Heading.
  • Sponsorship shift. You know "Knewknow?" Rather than building STRI, he leveraged his background, reputation, and current title to assemble the right team to build (hopefully) the right project, at the right time. 
    Credit to past "box sponsors" but organizational changes can bring a different perspective. 
  • The Cloud, I rarely mention the Cloud, but in this case, the cloud has some interesting implications for what you can do with STRI in terms of support and maintenance (see sponsorship).
  • Open Source*. STRI feedback and changes come at the speed of the Midas Rule. Like other Tridion open source projects, STRI can evolve as fast as customers and consultants need, rather than based on SDL Tridion releases or Professional Services availability.
*I've been following the community awhile now and I missed Foundations and Edition and we barely shared anything on Spark. The Open Source change is a big deal as I've had customers cite our community as a selling point (and was even stopped while waiting for a taxi at a customer's office). Compare the few 2012 bootcamp posts for Experience Manager with the dozen or so shares at the end of this post including blog posts, code, a screencast, and several announcements and impressions from internals and externals.
In my Tridion Sandbox post, I explored the shortcomings in my proposal, which likely echo any organization whose main charter is not Tridion-in-a-box-making:
Though maybe not in scope for a "Web Design" course, there was no plan for change management and socializing such a project. Something like [my school project] would have needed to be built "for fun" or come with an executive project sponsor. This would have been a better fit as an open source project (four years later in 2014).
I don't have delusions that my ideas for needing an open source example shaped STRI. The point is STRI validates some of my past suspicions and that STRI needed more than just code or a strong example (I would have loved to work with Editions and Foundations or share some of Spark's goodness)--it's the result of organizational changes and a process that's difficult to bring together, especially in a service-based organization like Professional Services.

So I think STRI has all the right things, but you can't guarantee success. As the inventor of the Midas Rule, I've found you can still have a say. :-)

Notes (to Self)

The SDL Tridion Reference Implementation uses a Structure Group-based main navigation approach, but it also has Tridion pages that are added as includes on pages for things like the footer (in Structure Group  _System\include).

Rather than just links in Components, we have Component Presentations, which is a nice fit for today's navigation approaches.

The white label STRI design reflects a familiar-looking footer. In STRI, each list is a Component Presentation, editable in Experience Manager.

Bart mentioned some of the configuration strings in the Page Template metadata could be selected using a picker instead of a string. One other idea I've suggested in implementations are Keywords so that selections are managed, but there are plenty of ways to accomplish the same thing.

There are some pages with an Alice-in-Wonderland naming convention (like the bottles that say "Drink Me"). These are:
  • Publish HTML Design
  • Publish Settings
Security tip: because the website is cached, there's an admin/refresh "web page" you can visit to refresh the site. Bart explained you probably want to remove access to this page on Production environments. It's currently a setting in global.ascx in STRI 1.0, but Bart is moving it to a configuration in the next version.

Notes on Navigation

The reference implementation includes pre-built navigation elements such as Top, Left, Breadcrumb, Sitemap, Google sitemap. Publish _Navigation. Since the navigation title fields are configurable, when you change schemas be sure to update the Navigation details in 100 Master > Building Blocks > Settings > Core > Site Manager.

For example, if you use a different embedded schema or change headline, you'll want to revisit these settings:

"standardMeta/name"
"headline"

The title, if using the "Localizable" Navigation option will come from the first Component on each page, looking for the fields configured above. 

Fun moment: When the Huizard Googled for one of his posts in his presentation.

Thank Google. Eric's blog is SEO friendly.

Alvin's Exercise: Make a Diamond BluePrint

This was a "trivial" exercise if you've done it before, though the actual Publication settings will appear backwards to how you draw a diamond BluePrint. In my bootcamp presentation I described the basic BluePrinting designs which matched the ones in training, but simplified for a business audience to make it easier for organizations to find a good fit. So by Midas Rule, my exercise was to make one of the BluePrint diagrams. 

You could skip the configuration if you wanted to use a script instead.
I like the context menu. We start a New Publication. The hardest part will be the name.
I've pondered BluePrinting naming conventions before. STRI uses 010 Schemas and Categories for the Publication that stores definitions. Schemas and Categories are explicit Tridion-specific terms rather than concepts. So should a diamond BluePrint for STRI have names like thse?
  • 020 Components
  • 020 Component Templates and Page Templates
It's philosophical questions like these that make me glad I wasn't part of the STRI build to slow down the process. ;-)

For the sake of time and to respect some familiar conventions, I used Global Content and Global Design.

Though we design a BluePrint top-down, we configure a Publication by adding parents. Here's the final step where we add Global Content and Design as well as remove 010 Schemas and Categories. What would happen if we tried to remove 010 first? ;-) Answer: It's like rock climbing. You can't let go of a Publication until you grab onto another one (plus some other constraints with items in use, but hopefully you get the idea and can remember the metaphor).

By adding Global Content and Design between Schemas and the example website, we get the "classic" Tridion diamond BluePrint. This was the easy part.

I ran out of time at the bootcamp, but the next part is to review the pieces to "split." You could start in the Modules or System folder...

But a more practical approach is to do a Where Used on the pages.
Each page will references content and design elements based on their Component Presentations. Manually (or programmatically) the next step is to make a copy of these elements in the correct Publication and then use the copies in the pages (or copies of the pages).

If you want to leave the originals untouched as recommended, just be sure to rename items otherwise you will have duplicates in certain lists like the Schema or Component Template drop-down selections.

One technical tip: I had a quick moment to add a new Publication Type so non-developers could hide the developer-specific Design publication.

Here's the small change. See Tridion Stack Exchange for what to restart.
    <publicationTypes>
      <add id="1" name="Content" titleResource="lblContentPublicationType" />
      <add id="2" name="Web" titleResource="lblWebPublicationType" />
      <add id="3" name="Email" titleResource="lblOutboundEmailPublicationType" />
      <add id="4" name="Mobile" titleResource="lblMobilePublicationType" />
 <add id="5" name="Design (Developer)" titleResource="" />
    </publicationTypes>

I covered Tridion in-a-box history, how STRI is different, and some shared my notes from the bootcamp, The last part is for you.

Share More

The top three objections to sharing are:
  1. I have no time.
  2. I have no topic.
  3. I'm not ready.
As long is it's "I am not interested," here are some ways past these objections:
  1. Save time. Did you take notes? Did you present? Can you copy/paste and/or edit something? Did you ask a question? Did you have an answer?

    Note: Your circumstances are probably different, but I wrote most of this on the way home. ;-)
  2. Brain storm or note topics as they come up. Or see below.
  3. You're never ready. Trust me. I was a little nervous on my first few Tridion-related posts (like this one on a BluePrinting use case that actually helped my interview with SDL). 
Sharing for the first time can be a big deal but it's like any other change. You're never ready for the first day of school, that first date, moving away from home, having a child, or buying something really expensive. But it works out, there are people to support you, and most of the time you're better off just going for it. You'll learn some good lessons and get better at it either way.
So for #2, here's what others have done:
Was this enough sharing? No. Because we still needed a bootcamp to explain it.

If you're still not how you might share, consider one of these.
  1. What did you learn at the Bootcamp?
  2. What did you already know? What did you not know?
  3. When did you first hear about STRI?
  4. What surprised you?
  5. What was missing?
  6. How long have you been doing Tridion?
  7. How many Tridion-in-a-box implementations have you seen?
  8. How does Tridion compare to your last-favorite-CMS?
  9. How does STRI compare?
  10. Thoughts on its name? What would you call it?
  11. Observations on STRI
  12. Observations on the team?
  13. What did you like about the SDL office ("omg, an SDL frog!")
  14. Did you meet anyone new?
  15. What did you like about Wakefield?
  16. Were you able to find a drink after 11:00?
  17. What's a Content Provider?
  18. What's Content Delivery?
  19. What's DD4T? Why does STRI use it?
  20. How can I extend it?
  21. How can I help?
  22. How did you extend it (see this is a different topic)?
  23. What will be easy for customers using STRI?
  24. What will be hard?
  25. What will projects be like?
  26. Tell us the pros and cons of a reference implementation.
  27. STRI and the Midas Rule
  28. Why doesn't my colleague(s) wear a thicker jacket in freezing weather?
  29. Draw a diagram of STRI.
  30. Using three boxes.
  31. Or just two.
  32. One line?
  33. Make a demonstration video on something else.
  34. Make a podcast.
  35. Make an STRI meme.
  36. Start a contest...
  37. ...Between the SDL offices.
  38. ...with the community.
  39. Host an STRI hack-a-thon.
  40. Show it to a colleague and write about how explaining it helped you
  41. Show it to a customer. What was the reaction?
  42. Ask a question about it on Tridion Stack Exchange.
  43. Ask a functional question about it on Tridion Stack Exchange.
  44. Ask a technical question about it on Tridion Stack Exchange.
  45. Ask an architectural question about it on Tridion Stack Exchange.
  46. Answer the above questions about it on Tridion Stack Exchange.
  47. Design or make a Schema for the first time.
  48. Try Experience Manager.
  49. Describe STRI with ten points.
  50. Or come up with 50 ways for others to share about it.
Got thoughts, memories, or recommendations on any of the Tridion-in-a-box setups? Questions or comments about the bootcamp? Care to share what gets you to share? Leave a comment or better yet, make a follow-up post.
Shared by: on 1 comment:
Keywords: , , , ,

Three Tridion Years

It's been three years since I joined SDL (seven since my first Tridion project). Here are some of the highlights since my start in SDL.

Tridion Technical Community

The community is so active I can't even keep up with everything. I had to automate much of my Tridion-in-30 Seconds video (and double it to 60 seconds!).


I also joined the Tridion MVP selection panel awhile back when we lost someone in PS (and gained a Product Manager).
With great verbosity comes great responsibility. Remember, I don't choose nominees. Someone else nominates you for sharing, and I put in a yes or no vote if it was enough for the past year. If you'd like, I could vote if you shared as much as I did. :-P
I recently became a pro tem Tridion Stack Exchange moderator.


I've also had some great experiences beyond the community.

Industry

I presented at SDL Innovate this year! I blew up the event's Twitter feed as part of the selfie contest, which was kind of scary for some reason. The typo on the website was awesome.
Promotion to Training Manager? Nah, I just filled in for the real deal.

I also improved my SEO skills and connected with the bigger picture and SDL's larger audience. As of today, I show up high for non-personal Google search results for "Creepy CXM." The blog also broke 200,000 page views (though Yet Another Tridionaut beat me to 100k first).
I connected with, or otherwise engaged, honest-to-goodness Content Strategists on Twitter and in blog posts such as Tridion Can Poop or Training Your Tridion CMS.
Despite fun and growth in the community and industry, I've had a blast in the main thing.

Career as "Just a Functional"

Knowledge Shared. Helping our internal knowledge sharing days was also awesome, having the chance to make ice breaker games to explain Customer Experience Management and getting to design this (it's even Carbon 2.0 complaint).


Don't tell anyone, but we had just enough publicity to get a jealous remark ("hey, what's that? Who gets to go?").

Travel Everywhere. I still had travel across the US but also more international trips including Bucharest, Amsterdam (again), Gothenburg (Sweden), and Lyon (France). I fly for Paris next week.

Learning languages and about cultures in school didn't help me with work and business directly, it's helped me connect with the people at work and business.

Customers Everywhere. Related to the travel for clients, I also see our customers' products in banking, insurance, retail, and entertainment everywhere and not just because the Web knows I'm visiting their websites. I have to double check if an email is from my bank or work for my bank or if the special is for the local amusement park or the one I have to travel to work for. ;-) 

Here are some images that may or may not remind you of projects we may or may not have done together.

Images aren't just images when they're licensed IP (intellectual property). Picture: Barcroft Media via The Telegraph.
Dimmer or dimer? I can't pronounce certain types of light switches anymore.
3-D flowers were cutting edge... in 2012. The hardest thing to do in a consultancy of Tridion Professionals? Taking them off projects to update content. :-) 

Forget Tridionaut Consultants, Furbysultants FTW!
Not project related, but some of my former colleagues and I get excited over Minions. We'll share pics from Minion knitted caps to "look what I bought" moments.

The best part of it all isn't Tridion, but (new) friends and (new) family. Since I've started this latest career, we've moved three times, we saw Allana grow up into a First Grader, and were joined by Caden. I've said Allana looks like me, but pretty like her mom. Allana's also quite sharp, but Caden worries me with that brain and smile of his. There's something about a baby/now Toddler, that can make the guys go, "hey what's up little guy?"

The family's also joined me on two out-of-town trips (San Antonio and Orlando) and we'll have other opportunities for us to travel together. As one of my colleagues might say about these first three years: "it was awesome."

I'm looking forward to the next three.

Here's a recap of previous recaps::
Shared by: on 1 comment:
Keywords: ,

You Should Share More

As of now, I have 47 blog posts on this blog, 3 posts on TridionDeveloper, 3 videos, 1772 points on Tridion Stack Exchange from 27 questions and 44 answers for 2014.

When I first started sharing about Tridion, it was on a private forum with no blog posts. I doubted I had anything worth sharing.

After helping customers these past three years, seeing what others struggle with, and re-learning much of what I thought I knew, I realize a few things:
  1. I have more to share, more to contribute, and maybe more chances to inspire others to share than my official role or title.
  2. The more I explain, the easier it is to explain. Practice makes permanent.
  3. No one will read it all, I'm not that special, and "few people that need my posts actually read them. But the ones that need them when they find them appreciate it."
But enough about me and my blah blah blogging.

You should share.
You are or can be a thought leader.
If you answer the same questions and keep getting the same questions, it's a sign. It means your answer isn't out there. Give it away. Or a small taste of it.

 At least save yourself time and write it down... so you can reference yourself when you're next asked. Wait. If you answered it already, copy, paste, and revise it instead. If not answers, then share code, ask questions, make a podcast, or record a demo.

Educate. Share. Leave a legacy.

Don't wait for perfection. Share so small, you can't get it wrong.
Or aim so big that you can't possibly achieve your goal, but you'll make something epic anyway.

Recycle. Re-use. Good ideas need to be expressed, vetted, and revised. Bad ideas need to be expressed, vetted, and revised. Bad ideas transform into good ideas by being expressed, vetted, and revised.

Share what didn't work. Share the mistakes. The community doesn't want perfection. Parts of it want to know you and what you've done. Parts want to know what works and doesn't. Much of it just wants to get its job done.

Choice words at the right time make a difference. Encourage someone. Mentor someone. Mentor everyone or be a student of the World.

I'll say it again, as a past/current/future thought leader in your industry, you should share (more).

Edit: why do I care if you share? Because others shared when I needed help and sharing shaped my own career. Especially with my corner of the Web--Content Management Systems--I find knowing and engaging the Web is important to being a "Web" professional.
Shared by: on No comments:
Keywords: , ,

SDL Tridion XSLT Variables for Linked (Multimedia) Component

While Cleaning My Desktop... Tidbit #1

I share a lot, but surprisingly, I still have too many tidbits and side projects that I'd like to get out to the community. Here's another long-overview due (and marginally relavant) post on XSLT. Dominic Cronin might call these types of blog posts "notes to self" and I've posted about this kind of Secondary Memory.

So here's some starter XSLT variables I've used when transforming source Tridion Component XML and referencing a linked Component. With modular templating you'd normally use something like the Get Extension (DGX) to be able to reference related Components. Otherwise you would add these Components to the package.

But with the older style XSLT templates, or anytime you had access to the content model while using XSLT, we used the document() function against the other component's namespace. This is one of the places where you'd be glad you always gave a Schema a good namespace.

XSLT referencing another Component

<xsl:for-each select="//namespace:link_to_multimediacomponent">
<xsl:variable name="COMP" select="document(@xlink:href)/tcm:Component"/>
<xsl:variable name="DATA" select="$COMP/tcm:Data"/>
<xsl:variable name="CONTENT" select="$DATA/tcm:Content"/>
<xsl:variable name="META" select="$DATA/tcm:Metadata"/>
<xsl:for-each>


You could also use the same approach when referencing the Component that's being rendered by the XSLT template. You can see an example in my "Inspect Component Details" post:

<xsl:variable name="Content" select="/tcm:Component/tcm:Data/tcm:Content" />

You could then reference Xpaths starting from $Content. 

<xsl:apply-templates select="$Content/*" />

With a few variables, you've made selecting something as easy as remembering its path based on the source XML. But then this isn't Tridion per se, but just XSLT's variables.

Thanks for letting me reminisce. XSLT + Tridion brings me back to the "old days" on the forum, where I feared the likes of power forum users like +Dominic Cronin or +Jeremy Grand-Scrutton. Maybe Dom will forgive me for referencing W3School. :-P
Shared by: on No comments:
Keywords: , ,

Min, Max, and Everything in between

You can better understand a content model using two numbers for quantity: minimum and maximum. Data modeling might refer to the cardinal relationships between data tables, but in terms of an enterprise CMS we're mostly interested in how many elements can exist (this content type or text in this location, on this page, etc):

Let's look at:
  • Min
  • Max
I have these in the example "mobile-first" page type breakdown from my last post. But it could also apply to any managed elements such as fields, images, regions, selectable options, or websites (think Tridion BluePrinting).

Read More »
Shared by: on No comments:
Keywords: , ,

Let CRUD Guide your Tridion Integration

Bart Koopman describes ways to tackle SDL Tridion integrations in this SDL Tridion World article and a follow-up podcast with Robert Curlette on TridionTalk.

So now you know the how and where, but let's look at the why, when, and which to choose.

Let's revisit some terminology you might have heard: Baking versus Frying.
  • Baking is the idea of placing data, content, or multimedia into a system for retrieval "as is" at a later time. You can bake in the CMS or during publish. These items may be managed but the individual details, are stored in the format they're requested.
  • Frying is the idea of retrieving, querying, or assembling these in content delivery
We apply these approaches generally in three spots:
But how do you know what to choose since any approach would work (the first time)? Whether you put an image in SDL Tridion, add it in publishing, retrieve it from your content delivery network, or add it with some client-side script, you can add an image to a page.

So let's look at some older lingo you should have heard: (S)CRUD, the basic "functions of persistent storage:"

  • Search
  • Create
  • Read
  • Update
  • Delete

Add the fact that someone, it might not be authors, has to manage your integration then you have your answer on where and how to do the integration especially since an information system includes people, process, and technology.

Search

How many items are you connecting to SDL Tridion? Would authors know how to identify these from memory or is there a list of items? Can you automate an association to the things you're integrating with?

A few items imply your integration might be in "key-value" configuration components or Application Data (hidden fields or data for items). Make links or paths to Tridion items and add an external identifier.

A few dozen items might require placing components nested in folders or as keywords optionally in a taxonomy tree. Authors would be able to find, select, and then update these "external" items easily. Each component has a field that represents the external item.

Thousands of items in a product catalog or digital system suggest searching in the Content Manager isn't as easy as looking at a list. Consider placing the items outside of Tridion, but not necessarily outside the interface.

SDL Tridion's External Content Library (ECL) is a good fit for multimedia integration. If you're considering options for multimedia (along with translations, analytics, encoding, and more), consider SDL Media Manager which comes with its own ECL Connector to SDL Tridion.

Create

Where does the data, content, or multimedia live? Will authors create this in SDL Tridion or is there a better tool or system? Even if SDL Tridion might be "better," is there an existing tool or system that's not ready to be changed or needed for other things? Look for a best fit, but take your time confirming any changes (mind the people in the process).

From an authoring side you can extend SDL Tridion to show some of these creation options in the Content Manager, even though the items still live in another system.

Read

When do authors need to make the association and when does the data need to be read? This will help confirm whether to bake or fry.

Knowing the content or data model, especially in terms of cardinality, will help here. Do you have a one-to-one (1:1) relationship? A one-to-many? Or many-to-many? In content management terms we refer to direct and indirect relationships, which roughly translate to links/embedded items and taxonomy, respectively.

A one-to-one relationship might mean page metadata or components.
A one-to-many or many-to-many need, where one external item is used in multiple place in Tridion could mean a keyword or component that acts as the external item.

Update

Where and how often do updates happen? Will it happen as part of the publishing process, or should it happen automatically without publishing (update externally, but retrieve presentation or even client-side?).

Will the approach change often? Is the configuration something that should be in Tridion? Do parameters change frequently?

Will data in the external system be accurate? Do authors need to change it and if so, should the changes be reflected back in the other system?

Delete

Finally, how often do you need to delete or remove something?

This can be overlooked, but is important because SDL Tridion can easily unpublish items, but it will restrict you from deleting things without first removing the dependencies.


Shared by: on No comments:
Keywords: , ,
Subscribe to: Posts (Atom)