WebDAV is Fast. Upload Multimedia is Faster.

You may have followed the "standard" SDL Tridion content creation process:

1. Get media by saving image(s) to your computer
2. Upload media by creating Multimedia component(s) in Tridion, optionally using WebDAV to copy and paste or click-and-drag the media into Windows Explorer folders
3. Create content, using media by first creating your content component then linking to the above multimedia component as needed.

If you've been spoiled by how easy it is to use images in blogs, email, and social media, you might wonder if there's a faster way. Yes, there is.

Enter Upload Multimedia

Though this option might seem confusing to long-time Tridion authors, it's rather ingenious.

If WebDAV is the Windows user's answer to creating content in a familiar environment for Windows users, then Upload Multimedia is the CME user's answer to creating content in a familiar environment for Tridion users. In other words, why switch context to create a multimedia component when you can do it from the CME.

Upload Multimedia could have a sexier name like "Quick Create" or "Lazy Image Loader" because of the following features. From a folder in Tridion, a user can choose Upload Multimedia to:

• Select a binary, optionally entering a url in the open dialogue's filename box
• Tridion will then create a multimedia component in the current folder, matching the folder's linked schema or the Default Multimedia Schema (set in the publication's content configuration section)
• The new component's name will match the binary's file name, minus the extension, if it doesn't already exist in the folder

Like WebDAV, mandatory metadata fields prevent this from working smoothly. Unlike WebDAV, however, it won't override same-named files; Upload Multimedia creates copies with a suffixed number in brackets instead of updating same-named items (e.g. myimage[1]).

Similar to the Simple Content Update Instructions, use the Select Item pop-up as a "mini-CME" to create items you need, when you need them, as seen below.

Sometimes adding an image is an after-thought or a last-minute nice-to-have...

Select the Image option and we're ready to Browse to a multimedia component...

Hmm, I want something that's not in Tridion yet.
We can use Upload Multimedia Component to save time.

Select an image or even enter a url.
Either will create an uploaded multimedia component.

We end up right back to where we started.
Optionally set advanced settings and press Ok.

Creating items from the mini-CME works when you've minimized localization and have your authors create and link to content in the same publication.

All that's left is to optionally organize the images. This is where Where Used and the fact Tridion folders don't necessarily map to presentation server-side paths make it easy.

WebDAV is fast. Upload Multimedia is faster. External Content Libraries (ECL) will be fastest.

Still not fast enough for you? Check out Albert's Batch Image Uploader (includes a hidden drag-and-drop from desktop to browser option) for the PowerTools or wait for the ECL feature in Tridion 2013 (see the Community Webinar by Bart on ECL).

Can't Paste from VMWare Player to Windows 7

I occasionally "lose" the ability to copy and paste from my VMWare image to my host (laptop).

After some Google searches, I've found the following works at least with my setup.

Start > Run (Start + 'r' for the keyboard shortcut):

"C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" -n vmusr
C:\Program Files\VMware\VMware Tools\VMwareUser.exe

If it doesn't take, running them again in reverse order seems to work. Not sure if it's a timing issue or if one command doesn't really do anything.

Environment details:

• Windows 7 Professional, 64-bit 6.1.7601, Service Pack 1
• VMware® Player 4.0.4 build-744019, running Windows Server 2008 R2

Speaking of VM's, it's almost time to psych myself up and start an SDL Tridion 2013 instance and figure out the Virtual Machine and IDE details (will VMWare Player work? Is it time for Visual Studio 2012? etc). Ping me if you've been brave enough to start. Maybe we'll schedule a 2013 hack-a-thon.

Update: I'm hearing so far it looks like VMWare Player, Visual Studio 2012, and Windows 2008 R2 or Windows 2012 would be suitable for a test 2013 setup. As with all not-yet-released software, any information about SDL Tridion 2013 is unofficial and likely to change; refer to product documentation when available or contact Sales or Support for specific product questions.

Yet Another SDL Tridion Navigational Approach

If you've done Tridion implementations long enough, you'll recognize the three classic navigation approaches.

The Basics

• Pages and Prefixes. Pages in a Structure Group with a prefix naming convention (e.g. 010 Summary, 020 Detail Page) could create your navigational relationship. This is typical for global navigation and can be published in a single file (e.g. .xml or .sitemap) for server-side rendering. This has been mentioned on StackOverflow and discussed/debated about here, here, here, and here.
• Link Lists. A container component links to other components. Simple and ultimate flexibility with some extra work for authors.
• Taxonomy. Categories and Keywords create a relationship that presentation-side code could query or otherwise "transform." Chris Summers presented on this in a community webinar.

But Now...

Let's add one more to the list:

• In-Page Navigation via Component Presentations!

SDL Tridion. Bottom-Up or Top-Down?

A few customers have asked me about the trade-offs between SDL Tridion implementation approaches.

Typically you design SDL Tridion implementation top-down but build bottom-up. Sometimes it makes sense to reverse the process.

Implementing SDL Tridion is rarely an either/or situation. I've typically seen a mix of approaches depending on the circumstances. Let's review the typical approach then consider the opposite: a top-down build followed by a bottom-up design.

We Define Top-Down

The SDL Tridion functional design typically starts with the client's business and website requirements. Using Information Architecture, we review website specs (e.g. wire frames, comps, or mock-ups) and analyze them for Page and Content Types (i.e. Component Presentations).

We then define a Functional Design that includes, among other things:

1. Presentations: Page and Component Templates as well as Template Building Blocks (TBBs)
2. Definitions: Schemas and Keywords
3. Organization: Folders and Structure Group as well as Categories

We Can Build Bottom-Up

Given a Functional Design, we can build a SDL Tridion implementation from the Bottom-Up. We reverse the list above and create the following.

1. Organization: Folders, Structure Groups, and Categories
2. Definitions: Schemas, Keywords, and optionally Components
3. Presentations: Page and Component Templates as well as TBBs

Though these lists simplify reality a bit, the order matters because of Building Block dependencies. Though you could do things out-of-order by creating Component without Categories or making pages without Component Presentations, the point is to understand the impact of such dependencies on your implementation, design, and code.

...Or You Can Build Top-Down

Why Page Types Are a Very Good Thing (TM)

Update: It seems Experience Manager only allows System Administrators the ability to create Page Types (confirmed at least with XPM on SDL Tridion SP1-HR1). My sentiments are the same--we shouldn't hesitate at using Page Types in implementations--luckily you've already defined at least the IA version of these in your functional designs, right?

An SDL Tridion Page Type creates a predetermined set of:

• optional "dummy" content (place holders) you're meant to change
• content that should be left "as-is" from the Page Type (i.e. "template") -- if this ever gets updated, your version should probably get updated as well

Experience Manager (XM), the in-context UI that replaces SiteEdit 2009, allows authors the ability to set pages as Page Types by simply setting a check box.

A user A System Administrator sets "Use this Page as a Page Type" for a given page, then sets:

• Page Type Description
• Page Type URL
• Component Presentation settings for either:
• Include this Component Presentation OR
• Include a Component Presentation that contains a copy of this Component, which then offers two more settings for:
• Folder (where to save such copies)
• Format string (on how to name these copies)

Authorized users now have the ability to create page in XM based on this Page Type. See SDL Live Content for the full details.

I was impressed when we first saw this feature in February, 2012. One concern was how customers might feel about giving regular page editors this ability. Shouldn't giving authors the ability to create pages and such "prototypes," be up to IT or the Content Management Office?

So far, I have heard one client ask about controlling the option. And the "good" news is only Admins have the ability. I take back any reservations--at least some authors should be able to create page types--for the following reasons.

1. An author that can set such a setting already has the ability to create and edit such a page manually.
2. An author that can set such a setting already has the ability to create and edit such a page simply by copying and pasting the page (and then components.)
3. An author that can set such a setting already has enough to do, making their life easier is a Good Thing™.

Restricting this ability is equivalent to wanting the following.

1. Although a content editor has the ability to create pages similar to an existing page, we don't want it to be easy for them in XM (which defeats the purpose of XM, yeah?).
2. Although the easiest way to make a page and update content in the CME mimics XM Page Types, we want to remove such "Copy & Paste" functionality from XM.
3. Although this prototyping pattern is familiar to anyone that's seen "templates" (real ".dotx" templates or even just copies of .docx) in Microsoft Word, we want to make this a Power User or IT-only function.

You've been doing "Page Types" in a non-CMS context for years now. Anytime you've heard, "oh yeah, get the template from the shared file/SharePoint/Wiki and make a copy," someone has saved time and effort in creating something based on a predetermined set of:

• dummy content that's meant to be changed
• content that should be left "as-is" from the "template" -- if it ever gets updated, all versions should probably get updated as well

Since only admins can create page types, I'm withdrawing my rant below. Can't argue for giving authors the page type ability if you can't currently give authors the ability. ;-)

The biggest challenges with Page Types will likely be explaining some terms and making sure your authorization model allows your editors to actually make the pages and content they define in Page Types. If they can create pages, it's likely you already let them create content.

Understand what Page Types really do, trust your editors, and be pragmatic in your implementation. Realize this type of approach isn't new, nor unique to SDL Tridion, and that Page Types are more administration than administrator type functionality.

Any other features you wish more authors had more (or less) access to? Leave a comment below.

The Vendor-Client Dance Partnership

Long before my life in IT consulting, I've entertained the idea of a career in Ballroom Dance.

At Champion Ballroom in San Diego, I learned a simple, elegant answer to the following question about dancing with a lady.

Q: Assuming you're the dance lead, how do you get your partner to take a step with a specific foot?

....

When Near-Duplicate SDL Tridion Schemas Makes Sense

This question came up in a recent Content Modeling workshop. The customer was wondering why you'd want separate "Press Release" and "Article" schemas. Why not conslidate them into a single schema? Excellent question. Here's my view.

You'll often see nearly identical SDL Tridion schemas (content definition items--think "xsd" not "database") with fields like:

• heading
• subheading
• image
• description or summary
• repeatable paragraph or section, an embedded schema with the following:
• subheading
• body

An "article," "blog post," "press release," or even "biography" schema may have very similar or even the exact same fields. The inclination might be to consolidate these, which is okay sometimes. Here's where it makes sense to have similar, but distinct schemas.

1. More control over permissions -- separate schemas lets different sets of authors create only certain types of content.
2. Simplify page template logic -- separating schemas gives you better control over how content displays on a page.
3. Reduce template-selection options -- templates associate to schemas and authors only see the templates that relate to that schema. No need to show templates that authors won't use most of the time. This also impacts the Content Delivery API--imagine selecting all press releases... except these that really aren't press releases, but  are using the same schema. Authors would need a redundant "type" selection.
4. Simplify author experience -- fellow Tridionaut, Asier Fernández also prefers that schemas have only the fields that apply to a given scenario, content authors can get confused by unclear fields they should ignore in certain contexts.
5. Improve organization and default schema selections -- by setting linked schemas in folder properties, new components in that folder automatically have the right schema and fields. Authors don't even need to select New Multimedia Component if this is set to a specific Multimedia Schema.
6. Reduce broker database size (minor point) -- we get a dynamic component presentation per template x component. This isn't such a big deal IMO because this is a linear change (nx2 or x3 rather than n^2)
7. Flexibility and independent development -- changes affect all components. If you suspect some content will get different types of fields or keyword options, consider separate schemas.

You can optionally use the same embeddable schema to consolidate the actual fields, but still get the benefits from above. Use embeddables when:

• Your rich text and keyword options are the same across authors and content. Changes to the embeddable fields affect all schemas that use them. 
• You need to allow repetition for a set of fields.
• You want to use the same set of fields, but give the entire set a different description name.

Happy designing. I'd love to hear your thoughts on what's worked for you and how you approach schema design, feel free to leave a comment.