Best Practices Building Sites in Kentico
ROI, Performance, Simplify CSS, Speed of Delivery & Pitfalls
5/25/2012
Neil Powers, Sr. Solution Architect
Best Practices Agenda
ROI :: Kentico Developer Styles
Performance :: Content Best Practices
Simplify :: Best Practices for easier upgrades
ROI :: Photoshop to Content in 4 steps
Simplify :: CSS headaches
Feedback :: Q&A
Common Portal or ASPX Question
One of the top questions I get in consulting is
related to the Kentico Development Process
What is Portal Development?
Kentico is .NET, can we use ASPX?
Where is my design tab?!?
Lets examine these, briefly
Kentico Development Methods
What are the differences? Why use one over another? Which is faster development?
Portal Engine
ASPX Templates
ASPX+Portal
Kentico Development Methods
What are the differences? Why use one over another? Which is faster development?
Portal Engine Development – Used the most, Why?
•
•
•
•
•
•
Sites where the end-user will maintain everything after Go-Live
Site maintenance is geared for Non-Technical end-users
Code customizations via the UI/Custom Webparts etc…
Faster site delivery using an out of box “common“ experience
Learning how Kentico “works” non-technically
Can still be complex and as technical as ASPX builds
ASPX Template Development – Used as case by case, Why?
•
•
•
•
•
•
Slower Delivery time, unless the team “knows” the API and components
Completely Flexible as most of the Kentico code is accessible
Complex situations that can’t be done as custom Webparts/modules
You love to writing your code by yourselves
Page templates = physical files and completely implemented by you,
including controls, web part usage etc…
Design, Data Structure changes are mostly done in VS Studio vs. UI
ASPX+Portal Development – Flexibility for Editors, Why?
•
•
•
•
•
•
Combines the standard architecture and development process of ASPX
templates with the flexibility and user-friendliness of the portal engine
Allows Design Tab Access to end-users, but limited to exposed controls
Edit the page or web part design via the UI vs. code changes
More complex than Portal alone
Must maintain file system based page templates
Must maintain up to 2 master pages (CMS root and File based)
Kentico Development Methods
What are the differences? Why use one over another? Which is faster development?
Portal Engine Development
ASPX Template Development
ASPX+Portal Development
Typically Faster
Typically Slower
More Flexible
Think about the Client and Project goals
:: Consider the technical ability of the end user to make simple changes
:: Every project and client is different, it’s why Kentico is extremely flexible
:: There really are no limits to any of the development processes
:: You may work several Kentico projects, the client may have only one
DEMO: Development Methods
Content Best Practices
Three of the most asked questions are
How do I increase performance?
Where do I store Content?
How do I enable versioning?
Lets examine these, briefly
Content Best Practices
Overlooked Content Storage Settings for Performance
@ Site Manager -> Settings -> System -> Files
Store files in the File System
•
•
•
Best performance
Requires ASP.NET User Modify Rights
Does not full-text search index uploaded files
Store files in the Database
•
•
•
Worst performance
Does not require ASP.NET User Modify Rights
Full-text search indexes uploaded files
Redirect to Disk
•
•
Additional performance
Requests for files are redirected to the
corresponding physical file
Demo: Performance Settings
Using Both File and Database storage
• Combines the advantages of both options
• Same performance as the file system-only
option
• Full-text search is available
Content Best Practices
Where should I store content, Which is faster?
There are 4 main ways to store content/assets in Kentico CMS
Media Libraries
::
Content Tree
::
App_Themes
::
Attachments
::
Media Libraries
CMS.File documents
Unmanaged files
Document attachments
It seems like more, but these are it
From a performance point of view review them…
Content Best Practices
Media Libraries
App_Themes
Pseudo File based – SQL still called
for access
No queries
Best Performance
Better Performance
Difficult for non-technical types
Can be Staged, but file level changes
are not tracked
Accessible in some cases via the UI
Can be used as content or set public
Content Tree
Attachments
Database based – depends on
settings
Attachments are File Based but rely
in the database
Good Performance :: up to 3 DB
queries to fetch content
Good Performance
Easier for Editors
Virtually no setup
Stored in /files, or /metafiles
Not obvious file location sometimes
Accessible via the UI for ease
What are some of the best practices to use these?
Content Best Practices
What are some of the best practices of when to use these?
Media Libraries
App_Themes
Video files
Used for various assets that you
want to protect away from the
content editors
Common assets to many editors
High performance
Large amounts of files
Image Gallery
Content Tree
Attachments
Used for various assets that you
want the editors to have easy access
to
Maintained by any role with access
to edit the content tree
Greatly simplifies the way you work
with files
Used when an attachment needs to
work with the workflow lifecycle of
a document
Content Best Practices
Ever change something only to have affected many other pages?
Simple Solution: Versioning without Workflow
•
•
•
•
Easy ability to roll-back during the development stage
Easy for end user to roll back or compare in production
Has a small performance hit
Allows you to store/restore/compare all versions of a
document
Demo: Enabling versioning without workflow
Easier Upgrades and Patching
• Store Page Templates, Custom Webparts and Doctypes safely
•
•
•
Create Categories for your Sites Page Templates
Clone Webparts before modifying in VS Studio
Store transformations in a DocType holder
• When to Ad-Hoc or Not, Understanding Template Inheritance
•
•
Got a new page, want to change the template web parts, then Ad-Hoc it
Determine what docs are about to be affected by a design change
• Why storing content as a DocType is so appealing
•
•
•
•
Once it’s stored as Data, you can re-use it almost everywhere
Forces validation rules on save
Consistent look and feel
Transformations / Dynamic Transformations
Site Imports, Patching, Upgrading all change your system and if not properly
setup can overwrite parts of your functional site.
Demo: Content Storage Best Practices
Photoshop to Content… Easily
Look at your final design, Really look at it and see if you can narrow
down the number of page templates buy using
•
•
•
•
•
Separate the Header/Footer and keep for the Master Page
Can you use settings on Webparts (Show for Roles, Where clauses, etc)
Dynamic Transformations (Using K# to Alter the look based on Data)
Doctypes (List/Detail)
K# / Macros (One of the best secrets in the UI)
As an example we took 60+ page templates down to 7 and a Master Page using
the methods above to manipulate the design or data returned to the end user
Demo 1 :: http://screencast.com/t/wdgaGIJX
Demo 2 :: http://screencast.com/t/uh0x9qehY9xl
Photoshop to Content… Easily
Now that you have the Design, you need to carve it up into something
Kentico can use for its various sections, Here’s a Tip… Offload it
• Send the finalized PSD or Template to a PSD Chop Shop
• Like www.xhtmlchop.com as one example
• Get next day perfect slices, Layout, Content, CSS and more
• Extremely Low cost
• Allows your team to focus on Design & Development
Since we previously narrowed down the templates to a minimum
using a firm to do the dirty work is far less costly than one might think
Photoshop to Content… Easily
Now that you have the raw parts in a manageable form
break it down a little further into these parts:
•
•
•
•
•
Master (Header / Footer) Layout with no content
Home Page Body Layout, with no content
Other Page Templates, with no content
Place the Design images/assets into proper areas
Copy the Design CSS into Kentico
Most of this work is Copy/Paste and Uploads
Photoshop to Content… Easily
Now to work on getting the content into Kentico
•
•
•
•
Create any doctypes to store Structured content
Possibly Import Existing Data using Kentico Import Tool, API or Manually
Add Webparts onto Page Templates to present the content
Add actual content, adjust any transformations and CSS as needed
This process has been used to convert into Kentico or build new sites
In as little as 2-3 weeks
With a final design, ready servers, no other staff, following best practices
CSS can be a pain, make it easy again
Kentico stores CSS in a few places:
–
–
–
–
–
–
File system, if using ASPX Page Templates
Database as one file
Transformations
Web part Layouts / Containers
Shared Page Layouts
Custom Page Layouts
It still serves it via http right? Lets save time and effort…
A tool a client ran across makes maintaining these CSS extremely easy, even
if you don’t understand CSS… While you can use Firebug, Developer Tools,
Dreamweaver etc. Stylizer 5 (www.stylizerapp.com) is simply amazing.
Questions
?
Sources
Documents:
DEV Guide - http://devnet.kentico.com/docs/devguide/index.html
PSD Chop – http://www.xhtmlchop.com
Stylizer 5 – http://www.stylizerapp.com/
Contact
Neil Powers
• e-mail: neilp@kentico.com
• consulting: http://www.kentico.com/Support/Consulting/Overview