Labels

accessibility (2) ADF (1) archiver (3) cmu (1) contributor (13) cookie (1) DAM (3) date (3) download (3) dynamic list (4) ephox (5) fatwire (1) fck (1) filters (1) folders (4) headers (2) IBR (3) ImageAlchemy (3) java (4) javascript (2) layout/template (4) link (6) locale (2) multilingual (1) rendition (3) replicator (4) rules (1) schema (1) search (11) sites (1) sitestudio (24) ssp/sspu (5) SSUrlFieldName (2) stellent (4) timezone (1) urm (1) weblogic (1) workflow (2)

Friday 30 January 2009

Better SiteStudio "Best Practices" - Generating Navigation

Continuing my theme of scalable best-practice for SiteStudio, it's time to turn our attention to the elephant in the room - generating navigation. SiteStudio comes with dozens of "navigation" fragments that harness the power of dynamically assembling navigation from the site sections. There's plenty of fragments to choose from, they do nifty stuff... but the question nobody seems to ask is "why the hell would you build navigation out of your site sections?"

Building site navigation from site sections might make sense to a content-management developer or even a clueless contributor, but as a web developer it smacks me as fair dinkum madness. Nesting sections (directories) just for a drop-down nav? Thinks of all the redundant jumbled-up URLs, yuck. If you wanna change your nav, you gotta move around site sections, mucking up external links to your site... I could go on, but you know the issues, right?

But you were thinking "dynamically assemble nav, that sounds hi-tech and easier to manager, right?" Wrong. To add a link to your navigation, you need to create a new section with a URL, assign a layout, assign content to the regions, set the section as "include in navigation" plus any other custom section properties. Phew... not so dynamic now, eh? The dynamic bit is the fact that every time someone visits the page it needs to recalculate and reassemble the navigation based on the site hierarchy. Strewth. The nav probably changes once a blue moon yet you're wasting valuable processing power regenerating it on every single page visit. On a site with thousands of sections that's gonna be a significant slowdown! The Oracle dudes will tell you to cache it but that means whenever you do change your nav you won't see nuthin' until the cache expires. Site hierarchy as navigation is horribly impractical.

1. Generate navigation from a content item, not from site sections.
Why bother "generating" navigation when we can just use a content item? It's a CMS, remember! Create a region in your layout for navigation content. The contributor simply edits the assigned content and adds a list of links, links to whatever content or sections or URLs they feel like. Easy! Use a staticlist fragment to offer tighter control over the items, the new 10gR4 SiteStudio uses region templates to finitely control the appearance further. Standard workflow & security can be used to control the nav, it's fast and reusable, and it doesn't expose the project file (site structure) to non-designers.

2. Auto-reuse your navigation content across multiple sections.
Worried about the arduous task of assigning the nav content item to each section's layout? Simply hard-code into your layout that the nav region uses a specific content item. Better still, use a Custom Section Property (CSP) to define a starting section. Then code the layout so that all child sections use the same nav content item as the CSP parent. A site footer is also an ideal use for this approach.

Friday 2 January 2009

Better SiteStudio "Best Practices" - Secondary Pages

I've read a few blogs, webcasts and discussions about "best practice" for SiteStudio. They all seem to talk about the same obvious ideas. What I've been thinking about are some real-world issues and solutions, especially for scalability. Here's two I'm playing with now regarding secondary pages.

1. Use Primary Pages sparingly - rely on Secondary Pages
Forgive me for starting with a simple one... but I'm seeing websites where every page is generated from a primary layout. Yuck. This means every new page will need a new section. Every section in the entire site is stored in a single project file which quickly becomes stupidly massive. Only designers can edit sections. Sections need all sorts of settings done right or your site could become corrupted, even vanish. The content workflow processes are useless because sections can't be workflowed, you'll get a site full of sections with blank pages. Avoid this mess by using secondary pages.

What's the difference between primary and secondary? Well, let's start by understanding website sections. A section is the equivalent of a directory on a filesystem. The section however is a "virtual" directory - it's not a physical directory on any filesystem, it doesn't actually exist anywhere, the section is "generated" on demand. Anyway, if I go to a real directory in a normal website, I'll see a directory listing. Actually most websites are set up so that instead of seeing the listing, I'll see a default page, usually called index.htm - sounds familiar? In UCM terms this "default" page is your primary page, assembled using your primary layout. (Example: http://www.mydomian.com/mysite/mysection/index.htm)

But just as a directory can contain any number of files, a section can display any number of web pages. The primary layout can only display the one assigned content item as index.htm - so the secondary layout is used to display any other content item requested as a web page. The region in the secondary layout is not assigned to a particular content item, it is assigned as "replaceable." To see any content item in this section, simply append the ContentID to the section's URL and presto! there it is. Any item whatsoever can appear as a web page in this section (depending on security, conversion settings and so on) so you'll never need to modify any sections ever again! Woohoo! (Example: http://www.mydomian.com/mysite/mysection/ID000001) One final tip on this issue - you can (and usually should) use the same layout as the primary and the secondary, no probs.

2. Generate SEO-friendly filenames using SSUrlFieldName
The problem with secondary layouts is that the filename is just the ContentID, typically just a number with no file extension. Yuck! That's going to ruin your Google ranking and cause all sorts of confusement. (Example: http://www.mydomian.com/mysite/mysection/ID000001)

Give yourself real file names with the config value SSUrlFieldName. Create a metadata field (let's call it Bob) and then append your config.cfg file with SSUrlFieldName=Bob and presto! your web pages now use whatever filename Bob says. There is a catch - old mate Bob must know a unique filename for every content item, regardless of where it gets used. Bob can't talk about two items called about.htm (he gets confused) and expecting your contributors to give Bob the unique filename is delusional. The solution is to auto-generate it using the ContentTitle, the ContentID and a file extension. Replace spaces with dashes, truncate and then remove the leading zeros. (Example: http://www.mydomian.com/mysite/mysection/about-1.htm) Set this up as a global rule (newcheckin onsubmit) on your contribution instance - or as a archiver import rule on your consumption instance.

*****
I'll write a few more of these...