1. 5/25/2012 Neil Powers, Sr. Solution Architect
Best Practices Building Sites in Kentico ROI, Performance, Simplify CSS, Speed of Delivery & Pitfalls
5/25/ Neil Powers, Sr. Solution Architect

2. 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

3. 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

4. Kentico Development Methods
What are the differences? Why use one over another? Which is faster development?
Portal Engine
ASPX Templates
ASPX+Portal

5. 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)

6. Kentico Development Methods
What are the differences? Why use one over another? Which is faster development?
Portal Engine Development Typically Faster
ASPX Template Development Typically Slower
ASPX+Portal Development 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

7. 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

8. 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

9. 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 :: Media Libraries
Content Tree :: CMS.File documents
App_Themes :: Unmanaged files
Attachments :: Document attachments
It seems like more, but these are it
From a performance point of view review them…

10. Content Best Practices
Media Libraries App_Themes
Content Tree Attachments
What are some of the best practices to use these?
Pseudo File based – SQL still called for access
Better Performance
Can be Staged, but file level changes are not tracked
Can be used as content or set public
No queries
Best Performance
Difficult for non-technical types
Accessible in some cases via the UI
Database based – depends on settings
Good Performance :: up to 3 DB
queries to fetch content
Easier for Editors
Virtually no setup
Attachments are File Based but rely in the database
Good Performance
Stored in /files, or /metafiles
Not obvious file location sometimes
Accessible via the UI for ease

11. Content Best Practices
What are some of the best practices of when to use these?
Media Libraries App_Themes
Content Tree Attachments
Large amounts of files
Video files
Common assets to many editors
Image Gallery
Used for various assets that you want to protect away from the content editors
High performance
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

12. 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

13. 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

14. Photoshop to Content… Easily1
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 ::
Demo 2 ::

15. Photoshop to Content… Easily2
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 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

16. Photoshop to Content… Easily3
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

17. Photoshop to Content… Easily4
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

18. 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 ( is simply amazing.

19. Questions ?

20. Sources Documents: PSD Chop – http://www.xhtmlchop.com
DEV Guide -
PSD Chop –
Stylizer 5 –

21. Contact Neil Powers e-mail: neilp@kentico.com
consulting: