BluePrinting Naming Conventions. More Questions than Answers.

I wish I could explain the history behind various names I've seen in BluePrint design diagrams. But I have more questions than answers. Feel free to leave comments and/or explanations on your favorite BluePrint naming conventions.

000 Empty Parent vs 000 Scalability Parent

• Form?
• Function?
• Habit? Was this diagram from a template or a copy of an existing BluePrint diagram?
• I've also seen the layer called " Scalability  " but the publication in it called Empty Parent.

010 Functionality vs 010 Schemas and Categories

• Does the name tell you what it's for or what to put in it?

020 Design vs 020 Layout

• Does either capture functionality as well?
• Is design a more sophisticated term?

040 www.createandbreak.net vs 040 Alvin's Blog

• www. because it's the publishing website?
• Or the function it serves?
• Does it matter? It's easy enough to rename, right?

Master, Standard, Global

• The word "Master" might make sense technologically (ever set the jumper settings on an old hard drive?), but can have strong negative connotations in the US
• There's also the genealogy metaphor with "Parent"
• I saw Standard on Manuel Garrido's post on BluePrinting and translation. "Standard Design" has a nice sound to it. 

100 vs 010 vs 10a and 10b

• I'm used to 010, but realize exactly how many layers do we want to be able to scale to?)
• SDL WCMS Senior Consultant Robert Mathieu pointed out the useful side affect of using suffixes in the naming convention--though theoretically at the same level, we can group Content Publications and Design publications in order alphabetically. I've also seen this achieved by prepending something like "Site - " before the publication name.
• I've also seen prefixing the numbers with letters.

I really don't mind what you use as long as it's easy to use, easy to maintain, and consistent within an organization if at all possible.

As long as you have some semblance of the classic BluePrint diagram, we're speaking the same language.

Tridion and Technical Debt

When updating Web content management (WCM) systems, the implementation team has an opportunity of paying off technical debt.

How?

There are a few ways to improve an existing WCM, either by offering more structure, flexibility, or paradoxically a little of both. For example you can:

• Separate code from content
• Improve the author experience
• Improve the design experience
• Simplify maintenance
• Improve the user experience
• Improve scalability
• Offer more options while simplifying the default choices*

*For an excellent treatment on improving the user/human experience, see Nudge: Improving Decisions about Health, Wealth, and Hapiness. 

Technological debt refers to design or implementation choices that have a relatively low cost up front, but cause significant issues in the future.

Tridion as a Culprit?

Could Tridion itself cause such debt? Sure. It depends on the design choices and trade-offs.

For example, implementing a mismatched BluePrint, creating confusing schema, or skipping training can wreak all sorts of short and long-term havoc with a Tridion implementation. Also, upgrading too soon or too late with any system vendor has its own trade-offs. Btw, Tridion's complex because of customer's sophisticated needs. No, I'm not being sarcastic, stop grinning. Really.

Avoiding Technological Debt

As developers we refactor code, review approach, and evaluate better implementation methods. When working on business and system requirements we balance business wants with system needs and include both user and IT perspectives. At its core, we reduce debt by planning for, anticipating, and designing for the likely-to-change  parts of our systems. Though you might smell best practices, I see practical patterns.

Easy != Simple.

Just because something has a GUI doesn't mean you don't have to perform the same due diligence. For example, although schema creation is "easy," we should apply the same rigor to avoid technological debt.  Before creating schema, be sure to understand linking propagation, the importance of author-friendly schema names, what types of fields to use, how field order impacts authors, how to properly use Categories and Keywords, BluePrinting, templates, and the difference between page metadata and page-related components.

Organizational change is so hard, some call it change leadership. But while you're investing in Tridion or any other significant implementation, it's a good opportunity to pay down technical debt. If you choose to take on technical debt, do so conscientiously in a way your team can live with.

SDL Tridion CME Authorization

Any discussion for authorization or access to your Tridion setup should include rights, permissions, and scope otherwise you're missing part of the picture. Balance flexibility, security, and maintenance by understanding the basics, learning about patterns, and understanding how the rules combine.

Basics

SDL Tridion separates authorization into rights, permissions, and scope.

Rights = what you can do such as manage components or publish
Permissions = where you can do it (organizational item context including folders, structure groups, categories, but also target types) as well as how (read, write, delete, or localize)
Scope = which publications you can do it

I may have the right to walk where I want, but I may not have permission to enter your front door.

Too bad scope doesn't fit in that clever metaphor. Maybe think scope as jurisdictions where publications are local governments or localities... oh, never mind.

PowerTools 2011 Robot Pics

The SDL Tridion Community went live with our first release this week.

I already presented on the exciting progress, our next tasks, and my appreciation for everyone's contributions in Julian's last Tridion Community Webinar.

http://webinars.julianwraith.com/2012/05/10/june-2012-webinar/

But I also designed and ordered a 3-D Robot from MyRobotNation in anticipation. Enjoy some pics while I ponder what open source _object design_ will mean in a few short years as Moore's Law visits the physical world.