Best Practices Building Sites in Kentico ROI, Performance, Simplify CSS, Speed of Delivery & Pitfalls

1. Best Practices Building Sites in KenticoROI, Performance, Simplify CSS, Speed of Delivery & Pitfalls 5/25/2012 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.Filedocuments 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 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 Database based – depends on settings Good Performance :: up to 3 DB queries to fetch content Easier for Editors Virtually no setup

11. Content Best Practices What are some of the best practices of when to use these? Media Libraries App_Themes Content Tree Attachments Used for various assets that you want to protect away from the content editors High performance Large amounts of files Video files Common assets to many editors Image Gallery 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… Easily 1 • Look at your final design, Really look at it and see if you can narrowdown 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

15. Photoshop to Content… Easily 2 • Now that you have the Design, you need to carve it up into somethingKentico 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 minimumusing a firm to do the dirty work is far less costly than one might think

16. Photoshop to Content… Easily 3 • Now that you have the raw parts in a manageable formbreak 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… Easily 4 • 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 (www.stylizerapp.com) is simply amazing.

19. Questions ?

20. Sources Documents: DEV Guide - http://devnet.kentico.com/docs/devguide/index.html PSD Chop – http://www.xhtmlchop.com Stylizer 5 – http://www.stylizerapp.com/

21. Contact Neil Powers e-mail: neilp@kentico.com consulting: http://www.kentico.com/Support/Consulting/Overview