Using pre-Q1 2009 skins with Q1 2009!

As I wrote in the following much commented post when the Q1 2009 beta was released - RadControls for ASP.NET AJAX did receive a major face-lift!

 

Despite the major improvements in a number of important areas, this change has caused turmoil as well (somewhat regrettably for both sides - customers and Telerik developers - involved).

After the release, two major requests came from customers: 1) to help them keep an "old-style" skin in their applications as they liked it more than the new version, as well as 2) help them update their existing custom skins.

I spent the last couple of days implementing a tool that can do just that. It is this very tool that was used to convert the 14 "old" skins and update them to work with the "new" release. These 14 skins are ready for you to download - and can be found here:

Download Q3 Skins - link 1

Download Updated Q3 Skins - link 2 (requires login)

 

I would like to throw in a couple of extras here as well:

1) The current version of the skin conversion tool (it is a simple web-based application that should be run locally) is available for download from here:

2) In case you only skinned a couple of products, I have prepared a web-based version of the tool, available at the following URL: http://converter.telerik.com/skinconverter/
Please note that the web-based version has a couple of limitations compared to the full-blown version above, but will work well in 95% of the scenarios and is a very fast option to try out.

 

 

    As promised in the original blog post, and in various forum threads, in case you would like to keep using an existing older skin, and you face problems updating it (manually or using these tools) - send it over to us, and we will fix it for you. All you need to do is open a support ticket and send us a working application with the skin, the way it worked with earlier Telerik.Web.UI release.

  I would also like to take one more chance and share some additional details about the reasoning behind the skin changes. Hopefully this information, which is not present in the original blog post will shed more light on the situation

 

 The skin changes are aimed at increased productivity for the developer, appeal for the end user, and greater consistency across the products. These are not PR words. Here is exactly how the new release (and the next one) delivers and eases both your work and improve the user experience:

- Skin chooser control. This control, released recently allows your users to change the look and feel of the application in an instant (it is featured in both the QuickStart online demos and the WebMail demo).
- RadFormDecorator  - this control, unique to Telerik, which styles browser controls and elements has been further enhanced to provide smoother decoration and even more decoration features. Adding it to the page will take care more or less of everything that was not skinned - such as buttons, radiobuttons, checkboxes, textareas, textboxes and page background (for selected skins).
- Skin improvements (the 'problem' being discussed here) - the changes made ensure consistent sizes and consistent look of common elements across controls. This is a must if end-users are to be given the option to change the skin of their application.
- SkinBuilder application (under development, will be released next Q)

The SkinBuilder application was already mentioned in my blog post. Here are two additional screenshots - the first one features a  RadFormDecorator demo, and the second features the Web Mail demo application's main page.





 Hopefully it is now becoming clearer how the RadSkinManager, RadFormDecorator, skin improvements and SkinBuilder  are coming together and form a greater vision. It is this vision that has brought about the changes to the skins. Changes in the CSS naming conventions were necessary for the unification of all products so that in the future their skins can be made more easily or with a visual tool (such as the StyleBuilder). Failing to do go through this process now - at the time when the skins themselves were changed - would spell more trouble in the future. Same argument applies to changing sizes of certain control's inner elements - one could argue whether an older skin looked better than its 'updated' counterpart, but one thing is clear - prior to this release it was practically impossible to "just" change the skin of the application. Different sizes in different skins would cause all kinds of visual problems - such as broken layout and lots of scrollbars. This won't be the case anymore - and the WebMail demo is the proof. Furthermore, failing to address the issue on cross-control UI consistency would prevent (or produce less than optimal) results when building complex UI interfaces.

To summarize, the current enhancements and out-of-the-box improvements are meant to further streamline the development process and allow you, the developer, to produce great-looking skinnable applications with minimum efforts - and certainly with less effort compared to now.