Let Your Customer Love Kentico Administration

Whenever you develop web site with Kentico CMS you should keep in mind that it is content management system and there will be stuff working on site content, updating and managing it. So you are responsible for providing not only end users with great experience, but editors either.
There are several features, those will sygnificantly improve an experience of content editors and anybody, who is going to work within Kentico administration. Are you ready? Let's go!
 

All we know that Kentico introduces Modules feature in 8th version. It allows us to build advanced data structures along with different types of releations between them. but it also allows to build light and obvious user interface for managing that data. And sweet part here, for us, developers, is that Kentico already contains prebuilt templates for module managment pages (UI elements), those cover most of the standard scenarious, so no need to implement something, Kentico did it instead of you! Also, I should admit, that permissions arealso applicable to modules, so you might allow someone to view only data, but another one to readd and modify. Modules allows you to organize domain data and keep it separately from anything else, so user does not need to switch back and forth between different section to find needed data. 
 

All we know, that Ketico has veriety of different features as well as reach user interface in administration section. This is fine for developers, but might be confusing for non technical users. So I'd recommend to limit user possibilies along with user interface and provide only those features and elemeent that particular user or role needs.
I suggest to start from the simplest: configuration of user dashboard. Placing application, those user is going to use in the future on the dashboard, so user does  not need to use applications pane on the left. This significantly improves experience of the user, who is new to Kentico admin section. 
Next important thing is to limit access to modules, document types, custom tables, etc. using permissions. First of all this helps you to protect your administration from unnecessary changes. Limiting the list of available page types hepls to avoid confusion for content editor with selection of necessary type for content, he is going to add. Talking about page types there are other useful options to limit the appearance of pages within content tree: parent and child types settings as well as scopes. This, for example, allows you to deny placing anything underneith News, or allow creation Task type only under Project type - this reduces unnecessary confusion either.
Another handy option is UI Personalization: it allows you hide any unnecessary UI Elements, like buttons, tabs, icons, for particular user or role, like Kentico hides Design tab in Pages application from content editors. This approach is applicable to almost all UI elements within administration area.
 

There are situations when you have to provide content editor with placeholder for title and text, text and date stamp, etc. The easiest way to achive the goal is to add editable text web part to the page and allow editor to place there watever he needs. This aproach works great unless editor is not technical person and has no idea of how to deal with HTML, or there are more than one editor and each of them use different formating. I'd recommend quit using this approach if you want web site looks professional. Use page (document) type when there is repeating content or area with some special formation and even if there is no... With this uproach your customer will be trully responsible for content and does not need to take care and even thing about HTML or formating. Additional positive side of this aproach is the fact that it is  much easier to maintain/manage shown collection: reorder items, remove, add... 
 

Sometimes customer wants more control over the pages, than we would like to provide him with. For exmple there is a listing of News on the page, but customer might want to be able to update a header for that listing. If you think about adding an editable text web part above the list, I'm going conveince you, that this is not the best solution, as editor might add some formating to the heading, or, when you'll be asked to move this list to another section of the page, you'll have take care about two controls instead one. So my suggestion here is to wrap list with web part container and create a widget based on that web part and make container title field as a widget field. That's it, now content editor is capable to update listing title. In similar manner you might allow editors to select a transformation for the content, path, or whatever else you might think of.
 

Do not overload non-technical Kentico users, editors with cool features and possibilities they will never use, but provide them with a least capabilities they really need. This will make live easier for the customers and their editors, and make them happy consumers of Kentico, as well as your live, as you wil not need to fix the system after they screw it.