Amusing JSON Details

I had a client practically teach me JSON in the middle of a functional design session yesterday. Yeah, you can't escape proper Tridion Content/Page Type analysis (a subset of Information Architecture or IA) without looking at markup, in this case it was in JSON rather than the typical XHTML, HTML, or XML (actually it will be HTML 5 escaped within a JSON string along with additional members).

Refreshingly familiar and easy-to-remember, I'm not sure why I didn't catch these amusing, memorable JSON details before:

• Objects have brackets, reminiscent of your first Hello World class in your favorite language.

  { }

• Arrays have straight brackets

  [ ]

• Members even have serial commas, the way I like (am accustomed to) them in prose. Though my Dutch colleagues might disagree.

Now, I'm curious if the team will produce XML that renders to JSON or use a (DWT) template building block for layout and the format. Luckily I'm just on the design side this round. :-)

Not always an Extension

Despite what you might find on Google, Tridion is not all about extensions. Consider implementing or configuring for the majority of your content management system functionality.

Update: Read an insightful follow-up from Robert Curlette on the history of Tridion extensions and their positive impact on projects.

Things I've seen customers or consultants wonder about:

• Default schema selection for components in a folder? Not an extension.
• Having such Linked Schema create the correct multimedia schema regardless of which component creation button is selected? Not an extension.
• Context menu show/hide dynamic changes according to security access controls? Not an extension.
• Filter author-entered rich text before component save? Not an extension.
• Change component markup to XML, (X)HTML, ASP.NET, JSP, PHP, Json, or some other text format? Not an extension.
• Have a component validate and update to its source schema? Not an extension, unless you want to automate this. :-)

You're Not Really a Tridionaut Until You've...

• experienced the 5 stages of Tridion.
• been schooled on StackOverflow or TridionWorld.
• extended the Content Manager. <cough>that's what she said!</cough>
• broken a Content Delivery install so badly you had to start over.
• added "check jars, dlls, jdbc, and configs" to your personal mantras.
• verified and logged a bug in the product (which, of course, rarely happens).
• been asked to train someone on a module you haven't had a chance to really use... tomorrow.
• started an intense exercise program such as triathlon training. Failing that, you likely earned and hopefully lost your "Tridion Ten/Twenty." (10kg or 20lbs) It's also called "consultant gut." :-(
• received Linked-In invites for contract/temporary/full-time employment for in a different state, region, or country for anything from half to twice your current income.
• lacked the time to really check Linked-In, think about your career, or even this blog. Quick, back to the ship, you've got websites/documentation/code/projects/tickets/random-Tridion work to create or break!

Safe travels as you launch from Tridion World into Tridion Space, fellow Tridionaut.

Other suggestions welcome, leave a comment and I'll add it to the list!

SDL Tridion Parent Publication Permissions Simplification

Here are some SDL Tridion patterns I like that fit a "don't overdo flexibility" mantra.

• Minimize content publications
• Minimize localization
• Make multiple schemas but reduce redundant work through embeddable schema
• Simplify selections by using Category and Keywords for text fields

Let's add one more: simplify permissions management. As promised, here's an implementation for a "brain-twisting requirement to manage permissions from a single parent publication." This can reduce the need to break inheritance or localize folders throughout the BluePrint and simplify your authorization model for the cost of some extra groups.

I really have to see and prove this out for more scenarios but so far this setup looks promising (i.e. test this out before going live).

1. Use default rights groups as parents (e.g. Author, Editor, Chief Editor)
2. Create subgroups for scope and permissions (e.g. Editor Global and Editor Local)
3. Set these as children of the default groups, with scope set to a specific publication (level)
• Editor Global is a member of Editor with 020 Content scope
• Editor Local is a member of Editor with 040 Website scope
4. Create "roll-up" groups such as All Authors and set these as children of the subgroups.

In your highest content publication, set folder permissions according to the following.

In this example, we want editors to see and edit components in this folder in 020 Content. Because the Editor Global membership scope to the Editor group is restricted to 020 Content,  both the Editor Global and its child group Editor All will have read and write permissions.

But we may not want editors write permissions in a lower publication. Because the Editor Local membership scope to the Editor group is restricted to 040 Createandbreak, both the Editor Local and its child group Editor All will have only read permissions.

For the "cost" of an additional roll-up group (and more subgroups, depending on how you handle scope versus permissions-based groups), you can:

• Manage most author permissions in fewer (a single publication if you create most folders in 020 Content) publications
• Set users to an "all" roll-up group and get combined publication scope and permissions--add a user to this group and they get the combined, yet separately managed, permissions, rights, and publication scope
• Have the flexibility to mix-and-match subgroups if needed

Reminder: only change the "All Publications" scope setting for the subgroup membership. Leave the user membership, the roll-up group membership, and the "available for setting permissions" set to "All Publications."
See update below.* Manage your unique changes, not everything. 

Now, anyone have some good tip on session and user management to test this all out?

Update: the full setup can include "ACL" groups for even read and write permissions across similar folders. Each time you set up a global folder, you could place it as part of (maybe a same-named) group for each. It's a bit extra work in the setup, but troubleshooting and managing this means you can add full sets of permissions just be adding/removing membership.

With an "ACL setup" you'd set "All Publications" for everything. But if only doing roll-up groups, you may need to adjust the scope membership settings as needed (e.g. the Editor All would belong to Editor Local with scope just set to the "Local" publication and so forth).

IS vs IT

The relationship between Information Systems and Information Technology (IT) depends on who you ask. In school we learn an Information System consists of people, process, and technology. So technology is only one component of Information Systems, right?

Academia versus Industry

Yes, but  in the industry we see IT departments that implement information systems. Let's clarify by adding some context and definitions.

• The generic academic text-book Information System (IS) manages information.
• IS consists of People + Process + Technology.
• People = users. If dealing with Content Management, be sure to include content authors, end users, and maybe IT.
• Process = manual and automated steps. If in TridionWorld, be wary of using the word workflow since its also a product feature.
• Technology = software + hardware (and sometimes IT personnel, depending on who you ask).

An IS handles information, sometimes in a business, possible for management, and at least in organizations often connected to to software that attached to a three-letter acronym (TLA) such as CRM, WCM, WFM, WFO, or CXM.

Data and Metrics

Tip: there's a distinction between levels of data.

• Data = raw observations
• Information = processed data
• Knowledge = actionable information (at least how I understand it)

I you like metrics you can map the above to:*

1. Level or given measurement at one point in time (data)
2. Trend of measured levels as seen in a graph (information)
3. Benchmarks or comparison (knowledge)
4. Actionable steps (or analysis)

*Thanks again to Lars and Kurt from a Gartner PPM Summit workshop for this explanation.

In the end, I like the IS definition because it allows for a variety of scenarios, jobs, and roles. Your company may name the IT department whatever it wants with whatever roles make sense, but in the end any computer information system includes people, processes, and technology.

Tips when dealing with either IS or IT

• Use "IS = People, Process, and Technology" to evaluate any IT project, situation, or problem. It forces a healthy perspective for the big picture.
• Not all people have the same skills, interest in the system, nor motivations.
• Not all process is manual, nor automated.
• Technology influences people and processes, ideally by allowing the same (people) to do/process more
• It's probably not a good idea to sell technology as a "do more with less" solution, especially if your presenting to the people that may be displaced by such technology

If people call IT by something else, get clarification but go with it. It's more important to help people improve their processes, possibly with technology, than to argue about differences in terminology.*

*Except for health insurance and wellness companies that deal both with CMS, the US Center for Medicare and Medicaid Services and a CMS as in content management systems. If that's the case, consider using WCM for Web Content Management. ;-)