Progressive Enhancements to Improve Content Editing and Reuse in Cascade Server: Blocks (part 1 of 3)

By Bryce Roberts, MS, MSPH
StoneRidge Corporation
Bryce@StoneRidge.net

© 2013 – StoneRidge Corporation

• Block Based Content – 3/5
• Configurable Layouts – 3/12
• In-context Editing – 3/19

These are technical presentations on advance
development for Cascade Server, let’s drive in …


Reusable Content


 To understand a comparison of methods for
content reuse

 To know the general benefits of block based
content

 To have a general idea about the differences and
considerations between structured and
unstructured content

 To know some of the limitation in structured
block based content


It’s all about the WSYIWYG


 Content is often all contained within WYSIWYG of
a particular page
◦ Great for basic pages
◦ Does not require significant customization or
development
 Structured data in a page with a data definition
◦ Great for complex pages with many parts
◦ Require development to implement

To include content from one page in another page
requires either an index block or a data definition


Page Level – WYSIWYG – All Content
Example of a page that contents its content in a WYSIWYG default region.


Page Level – Data Definition – All Content
Example of a page with an attached data definition


Reusable content containers


 References
◦ Easy and does not require additional development
◦ Limited to being a virtual copy of a page
 Data definitions with page pickers
◦ Fairly intuitive for end-users
◦ Requires additional development
◦ Can lead to chains of pages
 Block Based Content
◦ Most flexible implementation
◦ Separates content from display (That’s good!)
◦ Not as intuitive for most end-users


Multiple implementation methods

 Block types available for direct inclusions
◦ WYSIWYG/Data Definition Block
 Offers the most support for end users
 Can be form based
◦ XML Block
 Limited user support
◦ Text Block
 No user support


Data Definition = WYSIWYG =
Structured Content Unstructured Content
 More complex for  Easy to implement
implementation
 Directly include on
 Often requires a format page in a region
to be paired with the
content block  Limited for complex
data type
 Good for complex data
 No validation possible
 Can validate block


 Solution
◦ Block based content

◦ WYSIWYG block types with data definitions

◦ Validation (processes only known block types)

 Examples
◦ Faculty Page
◦ Explore Emory Stories
◦ Meta tag manager


 Blocks
◦ Tabs

◦ Image with Text

◦ Link List

◦ News Feed

◦ Social Media Set

http://www.emory.edu/
home/academics/faculty
/index.html


 Layout Choices

 Consistent Labels

 Limited WYSIWYG
fields

 Intuitive data
structures


One Block – Multiple Display Formats
This example show how a single block of data can be display in multiple
formats. On the Emory homepage, it is a synthetic popup story. On the Emory
About page, it is an inline story with alterative colors.

Block Content – Data Definition - View
Structure data that includes a type


Block Content – Data Definition - Edit
Support user entering data and limited access based on user role


Validation – Wrong Block Type Selected
This is an example of data definition of the wrong type being placed
in the meta tag processor region. Add logic to the format so that
cascade alerts the user when the wrong type is selected.


How do we get here?


 Unstructured content
◦ Just add a block to a system region
◦ Often WYSIWYG
◦ Limited editor support

 Structured Content
◦ Offers most support for the editor
◦ Can be validated
◦ Must be associated with a format


 Identify types of blocks needed
◦ Examples: Set of links, WYSIWYG, Calls to
Action, CSS files, JS files, RSS
feeds, Accordion, Tabs, etc.

 Create intuitive, supportive data definitions

 Include non-editable fields in the data
definition to identify the type of content

 Use consistent structures

<system-data-structure>
<text identifier="type"
label="Block Type"
restrict-to-groups="hidden"
default="link-set" required="true"/>
<text identifier="title" label="Title"/>
<group identifier="link" label="Link" multiple="true">
<text identifier="text" label="Link Text"/>
<asset type="page" identifier="page"
label="Internal Cascade Page or File"/>
<text identifier="url"
label="--or-- External URL"
default="http://" />
</group>
</system-data-structure>


 Check the block type
◦ Notify user of error in block type

 Build to process many types of block with one
format (or import if using XSLT)

 Output should reflect block content

 Can include semantic identification if
appropriate


 It is all about organization!
 Keep all unpublishable assets together
◦ We have a “_cms” folder with all blocks/formats
 Use good meaningful names (editor training)
 Inline regions are helpful!
 Associated formats at the
template/configuration set levels for the
editors
◦ Don’t make your users do all the work
 Choose a convention for organization that
makes sense to you and your editors.


 By page type

 By site root folders

 By type of block

 Use asset factories
to help enforce
organization


Eating your cake and having it too


 Easier to reuse content!

 Better support for the editors!

 Validation is possible!

 Easier to limit access to pages – editors only
need to touch structured content!


 More steps for users to create a page

 Not as intuitive for most contributors
◦ A block is not a page
◦ Cannot publish a block

 Requires more regions in templates

 More initial planning on site setup

 “Template creep”


I wouldn’t be here without you


 Emory University
◦ For being a great client whose challenging needs
and great ideas drive great solutions
 Hannon Hill
◦ For continuing to develop and add wonderful
features to Cascade Server
◦ For nurturing a wonderfully vibrant user community
 Kat, Holly, and John
◦ For making this presentation possible and for all
your support of the series


Bryce Roberts, MS, MSPH

StoneRidge Corporation
1050 E Piedmont Rd.
Suite E-222
Marietta GA, 30062

678-391-6173
Bryce@StoneRidge.net
www.StoneRidge.net


Progressive Enhancements to Improve Content Editing and Reuse in Cascade Server: Blocks (part 1 of 3)

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Progressive Enhancements to Improve Content Editing and Reuse in Cascade Server: Blocks (part 1 of 3)

Semelhante a Progressive Enhancements to Improve Content Editing and Reuse in Cascade Server: Blocks (part 1 of 3) (20)

Mais de hannonhill

Mais de hannonhill (20)

Último

Último (20)

Progressive Enhancements to Improve Content Editing and Reuse in Cascade Server: Blocks (part 1 of 3)