Outputting Their Full Potential: Using Outputs for Site Redesigns andDevelopment Code Repositories

Outputting Their Full Potential:Using Outputs for Site Redesigns and

Development Code Repositories

Justin KlingmanManager, Web Software Development

@JustinVT99 @beacontec #csuc14

Sorry, IE Enthusiasts


What We’ll Talk About

Using Outputs for more than just repurposing content

• How Outputs work– What all can they do?

• Redesigns– In a Test instance or the Live instance?– Our preferred method & setup

• Development Code Repository– Purpose– Benefits– Setup


Outputs Overview

• Repurposing Content: COPECreate Once Publish Everywhere

• Examples:– HTML (Desktop / Responsive)– Mobile– PDF– XML/RSS– Print– Include– Multiple Languages

Cascade Page

Publish

Site Redesign Output


Redesigns

Where: Within New Cascade Site

• Set up “redesign” website (e.g. http://redesign.my.edu/)

• Develop!– Create all assets: Templates, Formats, Blocks, etc.– Create sample folder structure & content

• Implementation– Freeze publishing of current site– Manually copy all Cascade & web assets to existing site– Site architecture changes, if needed– Publish to “redesign” site and fully test– Push live


Redesigns

Where: Within Cascade Test Instance


• Copy Production Cascade database to Test instance

• Develop!

• Implementation– Freeze publishing of current site– Manually copy all new/edited Cascade & web assets to Production

instance– Site architecture changes, if needed– Publish to “redesign” site and fully test– Push live


Redesigns

Where: Within Current Cascade Site


• Create “Redesign” output in all Configuration Sets

• Develop!

• Implementation– Freeze publishing of current site– Manually copy all new/edited Cascade & web assets to live outputs– Site architecture changes, if needed– Publish site to current test site and fully test– Push live


Redesigns

Where: Pros & ConsSolution Pros Cons

Within New Cascade Site

• Cannot interfere with current site

• Allows for a fresh start

• Don’t have current site’s architecture and content to develop/test with

• Lengthy setup – starting from scratch

• Users cannot populate new content until redesign is implemented in current site

Within Cascade Test Instance

• Cannot interfere with current site

• Have current site’s architecture and content to develop/test with (but is not constantly updated)

• Quick setup

• As development/testing goes on, site’s architecture and content get stale

• Production implementation: Have to manually copy all Cascade & web assets from Test to Prod Cascade instance

• Users cannot populate new content until redesign is implemented in current site

Within Current Site“Redesign” Output

• Have current site’s architecture and content to develop/test with, which is constantly updated

• Users can populate new content during development process to save time

• Depending on number of Configuration Sets, can be a lengthy setup

• Users can see redesign in progress(is this really a con?)


Redesigns

“Redesign” Output: Setup

Cascade Page

“HTML”Output

“Redesign” Output

Publish

Publish

www.my.edutest.my.edu

redesign.my.edu

Current Site

Redesign Site


Redesigns


• Set up a dedicated Test website (http://redesign.my.edu/)– Visible to outside in order to test with mobile devices

• Create new “Redesign” Destination– Will publish the redesign to the above Test website– Set permissions to only allow developers/testers access to publish

• Set up “redesign” folder for all Cascade and template-level web assets (CSS, JavaScript, images, etc.) to be redesigned


Redesigns


• Copy all Cascade and web assets to “redesign” folder and edit:– Templates: Change all paths (HTML and Blocks/Formats) to “redesign”

folder– XHTML Blocks & Formats: Change all paths to “redesign” folder

• Edit each Configuration Set and add “Redesign” Output– One per layout (e.g. “HTML-Redesign”, “Mobile-Redesign”)– Settings:

• Template: Same as current Output, but in “redesign” folder• Publishable: No• Default Output: No• Region Blocks and Formats: All point to “redesign” folder• All other settings should match current Output(s)


Redesigns


• Data Definitions– Back up!

• Content Types– Change each Output to “Select Destinations”

• HTML (Current): Current Destinations• Redesign: “Redesign” Destination(s)

• Edit each Configuration Set– In “Redesign” output, enable publishing

• Publish site to “Redesign” & test


Redesigns

“Redesign” Output: Development

• Data Definitions– Do you have a backup?– Add new groups/fields

• Begin label with “REDESIGN”• Use “Restrict to groups” field to

hide from end users– Do NOT rename or change nesting

of any existing fields– When populated on pages, data will

only display in “Redesign” output


Redesigns

“Redesign” Output: Development

• Metadata Sets– Add new fields

• Begin label with “REDESIGN”• Make “Visible” (not “Inline”) to hide from end users

– When populated on pages, data will only display in “Redesign” output

• Develop!– Keep good release notes!


Redesigns

“Redesign” Output: Implementation

• “Freeze” publishing for current site

• Copy & replace Cascade and web assets from “redesign” folders to live folders– Change paths in Template regions and HTML, XHTML Blocks, Formats

• Data Definitions– Remove “REDESIGN” labels and “Restrict to Groups” values– Delete old fields (if applicable)


Redesigns

“Redesign” Output: Implementation

• Metadata Sets– Make fields “Inline” (if applicable)

• Destinations– Disable publishing for “Redesign” Destinations

• PUBLISH & TEST!

• Change site architecture (if applicable) & make content updates


Redesign

“Redesign” Output: Go Live!

• Content Types– Change “HTML” (current) publishing to original settings

• Configuration Sets– Delete “Redesign” output – or not???

• Asset Cleanup

• Publish it live!

• Party!


Redesign

“Redesign” Output

Example

Development Code Repository



Challenge #1: Cascade Template-level Asset Changes

Problem

• Changes to Templates, Blocks, and Formats could be published by end users before they are ready to go live

Possible Solutions• Make changes in sandbox or

Test instance• Disable publishing = Angry user base• “Dev” Output = Blissfully ignorant

user base




Solution: “Dev” Output

• Same concept and setup as “Redesign” Output

• Copy all Cascade Template-level assets to new “_internal-dev” folder– Development on Templates, Blocks, and Formats will take place here– Initially will be an exact duplicate of current “_internal” folder





• Code and other changes will then be released from "_internal-dev" to "_internal“– Similar to releasing files outside of Cascade from Dev to Production– Unless under development, all code between "_internal-dev" and

"_internal" should match exactly

• Publishing– "Dev" Outputs: Will publish to Development destinations only

• Set permissions to only allow developers/testers access to publish– Existing Outputs (e.g. "HTML"): Will publish to Production

destinations only





• Good Release Notes are critical_internal-dev/formats/analytics

» Copy new format to _internal/formats/analytics

_internal-dev/templates/interior» Copy code to _internal/templates/interior» “ANALYTICS” region

• Block: _internal/blocks/no-block• Format: _internal/formats/analytics

– Is this a pain? Yeah, but…all in the name of quality!




Example



Challenge #2: Template-level Web Asset Changes

Problem

• Changes to Template-level web assets (CSS, JS, images) could be published by users before they are ready to go live– Even if end users don’t have read or write permissions

• Example: Update header logo with 125th anniversary logo– Requires new image, CSS layout changes to accommodate larger logo– Changes made, end user publishes the homepage too soon– Header is hosed, President is mad, developer was framed!




Possible Solutions

• Make changes in Test instance or sandbox• Disable publishing on assets• Separate “Global” site

Solution: Separate “Global” Site

• Set up new Cascade site that will house these assets– Assets won’t publish when a page is published– Only developers have access





• Update all Templates, XHTML Blocks, and Formats to point to new site’s assets<link href="site://www.my.edu-Global/css/main.css" rel="stylesheet" />

• Site publishes back into main website– Destination settings

• Directory: Same as main site, but add on “global”• Transport: Same as main site

<link href="/global/css/main.css" rel="stylesheet" />





• Folder structure– Requires that all files be within the same top-level folder

(e.g. “global”)– Same as main site, but do not include top-level folder– Site URL: top level folder name: “/global”




Example


Questions?

Justin [email protected]@JustinVT99

mailto:[email protected]

Outputting Their Full Potential: Using Outputs for Site Redesigns andDevelopment Code Repositories

Software

Transcript of Outputting Their Full Potential: Using Outputs for Site Redesigns andDevelopment Code Repositories