Q1 skins

76 posts, 0 answers
  1. Ivo
    Admin
    Ivo avatar
    689 posts

    Posted 15 Jun 2009 Link to this post

    Hi Paul,

    Please open up a support ticket and send us your project  -- we will fix it for you.
    If you have a list of any appearance-related issues in your application please send it as well and we will be happy to go over all of them.

    We are looking forward to helping you resolve any outstanding problems.

    Kind regards,
    Ivo
    the Telerik team

    Instantly find answers to your questions on the new Telerik Support Portal.
    Check out the tips for optimizing your support resource searches.
  2. Paul
    Paul avatar
    2 posts
    Member since:
    Jun 2008

    Posted 17 Jun 2009 Link to this post

    Hi Ivo

    Thanks for the reply.

    However, that's kind of not the point. I don't want to have to send you my project, for a start I don't think the company would allow it. You wouldn't be able to get it to run there as you'd need the database, all the supporting files etc. which we certainly wouldn't send to anyone as the data is confidential.

    The point is you released a new version which completely broke the look and feel of our website. I shouldn't have to worry that with each new release I am going to face hours of rework just to get back to where I was before. My confidence in Telerik has disappeared after this fiasco and I'm sure I'm not alone.

    Simple things are broken too, just run this code under 2008 Q3 and then try it under 2009 Q1. For me, the 2009 Q1 version has no color, it ignores the CSS.

    <%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Test.aspx.cs" Inherits="GPSOnline.Secure.Test" %>

    <%@ Register TagPrefix="telerik" Namespace="Telerik.Web.UI" Assembly="Telerik.Web.UI" %>
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head id="Head1" runat="server">
        <title>Q1 breaks my site example</title>
        <style type="text/css">
            .Warning
            {
                background-color: yellow;
            }
            .OK
            {
                background-color: green;
            }
            .Error
            {
                background-color: red;
            }
            .Neutral
            {   
                background-color: #FFF;
            }        
        </style>
        <telerik:RadCodeBlock runat="server">

            <script type="text/javascript">
                function pageLoad() {
                    var panelBar = $find("<%=RadPanelBar1.ClientID %>");
                    var items = panelBar.get_items();

                    var parentItem1 = new Telerik.Web.UI.RadPanelItem();
                    parentItem1.set_text("Parent1");
                    items.add(parentItem1);

                    var parentItem2 = new Telerik.Web.UI.RadPanelItem();
                    parentItem2.set_text("Parent1");
                    items.add(parentItem2);

                    var childItem = null;
                    
                    childItem = new Telerik.Web.UI.RadPanelItem();
                    childItem.set_text("Child1");
                    childItem.set_cssClass("Error");
                    parentItem1.get_items().add(childItem);

                    childItem = new Telerik.Web.UI.RadPanelItem();
                    childItem.set_text("Child2");
                    childItem.set_cssClass("Warning");
                    parentItem1.get_items().add(childItem);

                    childItem = new Telerik.Web.UI.RadPanelItem();
                    childItem.set_text("Child3");
                    childItem.set_cssClass("OK");
                    parentItem1.get_items().add(childItem);

                    childItem = new Telerik.Web.UI.RadPanelItem();
                    childItem.set_text("Child4");
                    childItem.set_cssClass("Neutral");
                    parentItem2.get_items().add(childItem);

                    childItem = new Telerik.Web.UI.RadPanelItem();
                    childItem.set_text("Child5");
                    childItem.set_cssClass("OK");
                    parentItem2.get_items().add(childItem);

                    childItem = new Telerik.Web.UI.RadPanelItem();
                    childItem.set_text("Child6");
                    childItem.set_cssClass("Error");
                    parentItem2.get_items().add(childItem);

                    childItem = new Telerik.Web.UI.RadPanelItem();
                    childItem.set_text("Child7");
                    childItem.set_cssClass("Warning");
                    parentItem2.get_items().add(childItem);
                    
                    parentItem1.set_expanded(true);
                    parentItem2.set_expanded(true);
                }
            </script>

        </telerik:RadCodeBlock>
    </head>
    <body>
        <form id="mainForm" method="post" runat="server">
        <asp:ScriptManager ID="ScriptManager1" runat="server" />
        <br />
        <br />
        <telerik:RadPanelBar runat="server" ID="RadPanelBar1">
        </telerik:RadPanelBar>
        <br />
        <br />
        <br />
        <br />
        </form>
    </body>
    </html>




  3. Vassil
    Admin
    Vassil avatar
    66 posts

    Posted 18 Jun 2009 Link to this post

    Hello Paul,

    I've been following this thread ever since it was started and I'd like to provide some commentary.

    In the very early days of the company we were introducing breaking changes and we did not see anything wrong in that because we lacked the customer perspective. This has changed a lot throughout the years and today we are very mindful about introducing breaking changes. We have numerous internal projects that utilize the RadControls, they are used across other product lines such as Sitefinity, our websites use them extensively and each breaking change affects our productivity. Add to that the customer frustration we need to deal with, the extra work involved (such as converting numerous projects to work with new controls, new skins to work with old controls, etc), increased support load and you can see that this decision has an expensive toll on our side too. The long story short  - it was not an easy decision to make. It was actually the second most difficult decision after the one to re-write completely our ASP.NET product line and base it on ASP.NET AJAX. The case is more or less the same -things did not work as we and customers wanted them to work and we had to make a choice - radically improve things and innovate, or get bogged down in making hack after hack to our previous skins.

    We would've liked to make everything backwards compatible but in some cases it was impossible. In others, it would've meant more baggage to render and this is not what we want and what customers want. I believe all of you guys want our controls to be as lean and clean as possible. We had to make a decision and to make compromises.

    While the process of upgrading a pre-Q1 app to Q1 and Q1 skins might not be as simple as all of us would've liked, the benefits from doing that are very significant - consistency, easier skinning, less CSS, proper naming conventions across all controls, ability to easily theme your applications with all of the skins we offer out of the box, and many more. Last but not least, these changes were needed for the Visual Style Builder. Our hope is that the VSB will allow you to change the look and feel of the controls so easily that we will be able to offset the time we've lost you in this upgrade. When we make decisions such as this one regarding skins, we are always looking at the long term benefits and implications.

    With regards to the problem in your case, the same CSS declaration will work with one of the following modifications:
     - add !important to the properties, e.g. background-color: !important;
     - change the selectors to more specific (http://htmldog.com/guides/cssadvanced/specificity/) ones, e.g. div.RadPanelBar .rpGroup .Warning
     - set the color through the BackColor property, e.g.
    PanelBar1.Items[0].Items[0].BackColor = System.Drawing.Color.Yellow;

    The approach that you were using is working for specific skins in the Q3 release - namely those who have no background-color set on root or child items (i.e. the Default skin). If you try it with the Vista skin, the same code won't work. In this line of thought, since all of the Q1 skins are consistent, you can use the same solutions (listed above) to achieve the same look across all skins.

    As we've mentioned numerous times in this thread and in other places - we are ready to help in any way we can to aid you in the transition to Q1 2009 and later controls and skins.

    I would like to apologize to everyone who feels aggravated by the need to spend time to upgrade to Q1 and later. However, I am sure that once you do it you will see the grand ideas behind this unpopular move. I hope you will see that it was motivated by sound reasons and executed as intelligently as possible and that it was not a reckless decision somebody at Telerik took. As I said, we were aware of the consequences, it was a decision that all of us took and we were ready to pay the price of it.

    Sincerely yours,
    Vassil Terziev
    Co-founder/CEO
    Telerik corp

    Instantly find answers to your questions on the new Telerik Support Portal.
    Check out the tips for optimizing your support resource searches.
  4. yceron
    yceron avatar
    22 posts
    Member since:
    Apr 2007

    Posted 18 Jun 2009 Link to this post

    It's been months since we've gotten a response from Telerink on this thread besides the usual "sends us your project" or "follow the steps outlined in this tutorial", it's a shame though that you as a company had to wait until a customer threatened to not renew their subscription in order to do so.

    As Paul and others on this forum, I was very dissapointed when I installed the Q1 2009 release of the ASP.NET controls since it broke all of my web applications.  While I appreciate that the CEO of the company took some time off his busy schedule to express his apologies on behalf of his company I must say that sadly it doesn't solve our problems, the same way it doesn't solve our customers problems when we say we're sorry to our own customers because their applications look different.

    As I've tried to express both on this forum and by support tickets, the best compromise for everyone I think would be for Telerik to release the old skins as new skins with new names, that way those of us with broken or weird looking applications could easily do a Find/Replace and have our applications looking as they did before by using new skins that correspond to the old ones.  I for one, don't feel comfortable having 5, 10 or so additional CSS files, the amount of work involved with this is not as easy as it sounds when you have a few very large projects and no spare time to do this.  Also, with your current approach it's impossible to have new and old skins working correctly, or at least, it didn't work for me.  I'm sorry, but the "solution" you provided to this problem is just as lazy as "deal with it".

    Remember Telerik, you're a software company too, time to market is very important in this business.  Please help us out with this one. 

  5. Vassil
    Admin
    Vassil avatar
    66 posts

    Posted 18 Jun 2009 Link to this post

    Yolanda, let me start by clarifying that my decision to personally get involved in the thread was not triggered simply by the fact that Paul threatened to stop his subscription. When a customer is at that point of frustration, a single post from me in the forums is unlikely to turn things around.  We were very well aware that with this decision we faced a risk to alienate some customers.

    As I said, this was not an easy decision to be made. But if we had to maintain and build on top of something that's broken, this would've had a negative impact on all customers and for a very long time. You would have seen much less great things from us as we would've spent our time on hacks and tweaks rather than on good products that add value to your work.

    Mainly for historic reasons, the old skins had several substantial deficiencies: different element sizes in different skins, inconsistent look when combining various RadControls, broken layouts when changing a skin, inconsistent naming conventions. The issues were not just visual glitches. This simply had to be addressed at one point.

    As I don't want to talk only high-level stuff, I would like to share some of our reasons why things were implemented the way they are. Most of our controls rely on two css files - a common (base) css and skin specific css. The Q1 release affected both sets of CSS files - many things were unified, removed from skin-specific CSS files to the core CSS, naming conventions changed, etc. Reintroducing just the older skins as embedded skins would not solve the problem. Using the newer base CSS with the older skin CSS will simply not work as they are not compatible. We would have to include the older base css files as well. Doing what you guys want (to have older skins available as embedded) would've led to even bigger CSS files and an assembly double the size it is today (90% of the assembly is due to embedded css and images). It would also require new set of properties to enable the older skins and base css files which would've introduced more bloat. On top of all the negatives and problems listed above, it would have required quite some time to develop and support. Basically this would have been legacy which we could never get rid of.

    I'd like to make a note that old skins are supported as external skins. You have the choice to use them, they are not gone. The skins are available at: http://www.telerik.com/community/forums/aspnet-ajax/general-discussions/all-radcontrols-q3-2008-skins-are-now-compatible-with-the-q1-2009-release.aspx. True, you need to register additional CSS files but there's no way to avoid it because of the above-mentioned reasons.

    We've tried to facilitate the process as much as we can by means of providing a converter, by making old skins works with new versions of the controls and by doing the migration on behalf of hundreds of customers thus sparing them all the effort.

    All the best,
    Vassil

    Instantly find answers to your questions on the new Telerik Support Portal.
    Check out the tips for optimizing your support resource searches.
  6. Stephen
    Stephen avatar
    70 posts
    Member since:
    Mar 2008

    Posted 18 Jun 2009 Link to this post

    With the ability to use the old skins as external skins... Is there a way to take these external skins and embed them in our own dll and then reference that in order to increase performance?  As I understand external skins perform slow and are not picked up by the SyleSheetManager telerik provides.


    Thanks,
    Stephen
  7. Peter Zolja
    Peter Zolja avatar
    119 posts
    Member since:
    Dec 2007

    Posted 18 Jun 2009 Link to this post

    "As I understand external skins perform slow and are not picked up by the SyleSheetManager telerik provides."

    Not sure where you got that impression, but if anything using external CSS files is faster not slower. With embedded sheets there's a light http handler that processes these requests. It's kind of like asking IIS to give you the file or asking a light ASPX file to give you the same file... less processing in the former.
  8. Stephen
    Stephen avatar
    70 posts
    Member since:
    Mar 2008

    Posted 18 Jun 2009 Link to this post

    What I meant by speed enhacement is that the StyleSheetManager would optimize the css files by only downloading the ones being used.  
  9. Levi
    Levi avatar
    134 posts
    Member since:
    Jul 2008

    Posted 18 Jun 2009 Link to this post

    Vassil,

    Despite your reasons for changing things, the reality is that none of the visual changes were good. But, like Microsoft you guys will keep insisting you know best. Microsoft made this mistake with WPF and Silverlight. Despite numerous complaints they insisted that the font rendering was not blurry and that everyone else was mistaken by saying so. Now finally several years later, they are finally fixing the issue after realizing that no one is using these technologies because of this problem. It's not that they were not made aware, just that they trusted their own judgement over that of their customers.

    The reality is that people can upgrade using the converted skins, which I already did. But, because I care about your company I would have to say as a designer and a usabilty specialist that the skin changes were very bad design choices. I honestly could not find a single positive change. Despite being ugly, the fonts are way too hard to read because there is no contrast between the fonts and the background colors. Awesome skins such as the Vista grid were ruined but using a "blue highlight color" for the column headers instead of the previous version which was "perfect" and matched the Vista look much better. Have you guys noticed that Vista only uses that blue color to "highlight" things. This is just poor usability and obnoxious to look at. Skins such as Office2007 were great before and now completely ruined. And I guess in some effort to make things more consistent, every skin looks exactly the same in scale, font choices, etc. I guess to accomodate the 1-1000 guy who allows the customer to change themes and wants things to be exactly the same size, you have created a cookie cutter group of skins with no variety.

    The BEST thing you could ever do for yourselves is to revert all the skins to the previous versions, but I know you guys will never humble yourselves to do this. I for one, would have not chosen you guys if I saw the new skins and not the old ones. I would not be surprised if your sales are not greatly affected by these poor design choices. The fact that most of the grids for example are unreadable should tell you guys that you are not thinking about the whole design picture.

    Just my two cents...
  10. Peter Zolja
    Peter Zolja avatar
    119 posts
    Member since:
    Dec 2007

    Posted 18 Jun 2009 Link to this post

    I'd have to agree with Levi, especially on the cookie-cutter aspect. I am just now converting a project to Q1 from Q3 08. I had to fight with some of the controls that absolutely need to look a certain way, like the menu. It was easier than with the Q3 version and I've been helped by Telerik with some issues.

    That's the good part, the bad is that controls that I just don't have the time to make pixel perfect look way worse than with the previous skins. If you guys would've done the CSS refactoring while keeping the same look far less people would've complained. Take the image editor for example (click on the image manager). Do we really need items that are 26 pixels in height which is how thick those tree items are in the left tree? The old version had 18 pixels in case you're wondering. I won't even go into how much space it's wasted. I picked on the image editor, but this is not limited to that. Maybe you guys run your monitors at a resolution that's way too high, and hence the tendency to make everything big. Now sure what it is, but everything is too thick, takes up too much space. Then there are the issues with contrast and usability that Levi pointed to. 

    Another example of a problem I that I came across yesterday is how dragging and dropping between nodes of a tree on the same level has changed from Q1 to Q3. I'm not talking about looking differently, it acts differently. In Q3 there was some space between nodes so rearranging an item was as simple as putting the source node between other nodes. This was simple and intuitive. In Q1 there's no space between nodes so the user has to move the mouse away from the node to the right until it hits some empty space. I trust it's pretty obvious how unfriendly this is. This was fixed by tweaking the CSS and making each item smaller, but I shouldn't have to do this...

    In conclusion, in my case the problem was not that the structure of CSS changed, but that the look and in some cases the functionality of the controls changed, for the worse.
  11. PureCode
    PureCode avatar
    97 posts
    Member since:
    Jul 2006

    Posted 19 Jun 2009 Link to this post

    I think Vassil is right on the money here. I, personally, threw quite a lot of words directed at the flawed 'old style' skinning. We, as a business, ran into the much the same issues, and a few much worse ones at that but that's related to our embedded code generators and not Telerik's mistake,  you guys did with stuff breaking in applications we made for customers that use Telerik controls (we use whatever they want us to use, they provide the required third party products and we use them, beats locking down on a single product by a mile or two). However, Vassil is STILL right on the money. I may have an opinion (somewhere in the depths of this thread) about the contrast between two colors in a skin, but i am not going to fault them for performing the changes to the skin system (especially since i was rather vocal about the NEED for these changes, fully understanding the extra work it would produce for my business).

    So, by wanting this change, i disadvantaged myself and my business, and knew it. Sounds like a rather stupid business decision right? I want changes that ultimately and inevitably going to cost me a large sum of money (as in the hours of work needed to fix broken applications, and most of my developers don't come cheap). I can't charge the customers for this either, so my business is literally loosing money.

    The reason is easy, every time we had to develop an application with Telerik controls, we had to run circles to support skin changes correctly. Our customers want to be able to pick a skin, preferably on an individual level. Think back to the old skins and what Vassil stated below, inconsistent sizing, crappy format, the works. So, on-the-fly changing of a skin with the old system was a nightmare to develop (as Telerik proved to itself quite nicely when it released the SkinManager, which is what probably pushed them into this change) as the layout would be totally different between most skins. Our applications use code generators to on-the-fly build over 60% of all pages used in the application, and this is where Q1 broke our applications, but is also where we had a LOT of code that wasn't exactly pretty.

    Despite the cost of fixing our applications, the new system made the application framework we develop and utilize leaner. We could get rid of a LOT of code in the existing applications, as well as clean up the code generators (a term that sounds easy, but, for fun, try generating 60% of an entire accounting application on-the-fly, with little more than a database structure to go by (the content matters not, the database is what 'shapes' our applications, in 'real-time') apart from some simple user preferences).

    So, in the end, it provided me a service as well. If i have to balance the issues we used to have and the changes to the skinning, it tips to the changes side real quick. We have a better application framework now, and we have to do a LOT less development to create an application with it now. So, after the initial loose of money, now it is making me money. Add in the fact that Telerik was so kind to create that nice skin builder as well as added the long-awaited integration with Visual Studio (at no extra charge) and i see a win-win situation, not in the shortest of terms, monetary-wise, of course, but eventually the development time savings, the cleaned up code generators (can we make it to 75%? Who knows, but we're trying.) and all that jazz (we don't use the skin builder, as we made our own before theirs was released, but most of Teleriks customers can factor that in as well) will be more than worth it.

    Considering my vocalness regarding the need for a change in the skinning before it actually happened, i had already thought about the above before becoming vocal about it. Sure, there are consequences, there always are. In the end, we get a better product from Telerik, and as thus allows not just my business but anyone here to reduce their development time as well as opening doors to a host of other advantages (no legacy, Vassil, i ow you a beer, for the longest time i thought i was the last person on Earth who understands the (often SEVERE) consequences of 'legacy' (synomyn to 'nightmare' in my book, in regards to computing in business (as well as privately)), nice to know that that is not the case).

    The only thing i am a little confused about is people talking about 'how different' the new skins are. I noticed an odd color combination in the Vista skin (see above, somewhere), but for the rest, i don't think it is all that much different from what the old skins looked like, apart from the differences in sizes here and there. Maybe someone can show the same UI using an old skin and its brother amongst the new skins? I haven't heard any complaints from customers after the 'surgeries' we performed on the applications regarding the look of the application, which is why the complaining here regarding that confuses me a little (my customers are top-of-the-line, state-of-the-art COMPLAINERS, they are the role models for b*tching and moaning).

    Many thanks for the insight Vassil, as well as the good business decisions. It is nice to see a company (besides mine) prioritize on a much needed, but breaking change to their product, whilst being well aware of the consequences (potential loose of customers, albeit few out of many, the extra expenditure on the work, etc). You made the right choice, not from a developer perspective (developers tend to be a little too 'short-term', no offense meant of course, comes with the territory) but from a business perspective. I doubt it was an easy decision to make though!

    Regards,

    Mike
  12. Ivo
    Admin
    Ivo avatar
    689 posts

    Posted 19 Jun 2009 Link to this post

    Hi guys,

    @Levi - we very seldom insist we know best. It has always been our belief that customers know best.

    We won't change the skins not because we have a problem to "humble ourselves". We've made mistakes, we've admitted them honestly and we've taken corrective action. But it's damn hard to say "guys, we made a mistake" when I don't think it's a mistake but a HUGE improvement. With design, it's all a matter of opinion - some people like one design, others do not. I myself participated in numerous meetings when we reviewed the old skins, discussed problems, then discussed new ideas and design changes. It was a long long effort and we took the time to look at every minor detail, to compare how every element of our controls is mapped to Vista/Office/Outlook elements. If you take a really close look and compare the controls to their counterparts in MS applications, you will see 95% resemblance. The new skins were the result of a collaborative effort by many experienced people, including designers who have won many awards for their web design work.

    And, no, our sales are not affected negatively by the new skins. Almost all customers like the new look of the skins much better than the old ones and many people shared their positive feedback.

    @ Peter - you are right about the treeview in the editor. That one is a bug and we'll fix it. By design, the height should be just a few pixels higher in order to have the same line height as the grid (looks better when you have a treeview and grid in the same form). Our bad here. With regards to the treeview functionality, we have already fixed the issue that you reported yesterday and the Q2 release will include it - thank you for reporting it.

    With regards to colors and styling - the Visual Style Builder will allow you to tweak those in seconds so I hope it will be a non-issue very soon.

    @ Mike - it feels good to see how a person who wasn't terribly excited about the skin changes sees the value. I am sure that most people will see that the skins odyssey was a necessary evil. Even for the guys that don't like the new skins - it's much easier to change the new skins than the older ones and you can fairly quickly implement the desired look and feel.

    Best wishes,
    Vassil

    Instantly find answers to your questions on the new Telerik Support Portal.
    Check out the tips for optimizing your support resource searches.
  13. Levi
    Levi avatar
    134 posts
    Member since:
    Jul 2008

    Posted 19 Jun 2009 Link to this post

    "Almost all customers" liked the skin changes? I guess none of them bothered to reply here. Have you read this thread in its entirety? I've seen almost all negative feedback and I've been following this thread since the beginning. Read this thread from start to finish; you will find that the changes are not so popular as you would imagine. Usability is not a matter of opinion. Either something is readable or it's not. Anyone that says all of your grids are easily readable is lacking good common sense. There are plenty of good designers who make bad design choices. Also numerous design awards go hand in hand with impractical, unusable designs that are pretty to look at but serve no purpose beyond that. Take a survey if you are so confident. I think you might be surprised with the results.

    Like I said, Microsoft syndrome.

    You guys rock, don't get me wrong, but just making something more consistent doesn't mean the cosmetic changes themselves were good. If you read the numerous posts here, you will see they are not to most people.

    Levi

  14. PureCode
    PureCode avatar
    97 posts
    Member since:
    Jul 2006

    Posted 19 Jun 2009 Link to this post

    Levi,

    The most vocal people are usually the ones who don't like something that changed, was added, removed, etc. These are the people who will post on these forums regarding what they see as wrong. People who have no issues with whatever was changed, be it simply by accepting the change or be it by liking the change, have no real reason to be vocal about it, unless it would be in defense of whomever made the change.

    Your poll idea is not a bad one, but probably a little late since we're already dealing with a beta of Q2 2009 by now. Either way, the skinning isn't going to change back. It truly is MUCH better than before, and was one of the weakest points of the ASP.NET AJAX product suite.

    All you can do is either accept the changes, work with them, fix any issues that popped up in your application(s), and move on, or not accept it and move on to another product from another company (keep in mind, you won't be fixing 'issues' anymore in your application(s) in that case, you'll be recoding a significant portion of your application(s) to support the new product suite).

    There is no use in going back and forth with Telerik regarding this, Vassil (the CEO, of all people), has made clear that the changes are to remain as they are, and rightfully so. Instead of wasting time on something that you won't be able to change, you could fix your application(s) instead, which is what most people did i think.

    Look at the amount of users on these forums, the amount of posts, the amount of new users per week, etc Telerik is not a small business by any means, and they have proven (and Vassil's statements proof this to me, but i am a business-man first, developer second) that usually they know what they are doing.

    Also, look at Q2 2009 beta, FOUR new controls plus a crapload of fixes, how can you fault that?

    Not attacking you of course, just stating that it is futile (in almost all cases, not just this) to try and talk a business of reasonable size out of something they have already implemented, especially considering that in the end the changes to the skin system are for the better of the product as a whole (and, inevitably, once all has been fixed, for the better of their customers, people like you, me, my customers, etc).

    Regards,

    Mike
  15. Carsten
    Carsten avatar
    1 posts
    Member since:
    Dec 2008

    Posted 11 Aug 2009 Link to this post

    Hi Guys,

    this is really a no-go! You except from me to change my customer applications to new skin changes to have the same look and feel like before the upgrade?  I'll will spend days to fix my applications! Who is paying me this efforts? Telerik?

    We'll have a internal discussion on this to decide whether it was really a good idea to use your controls!

    Unbelievable! This is unprofessional! Instead of creating !!!NEW!!! skins and leave the old skins for legacy and already existing customer applications!

  16. Ivo
    Admin
    Ivo avatar
    689 posts

    Posted 25 Aug 2009 Link to this post

    Hi Carsten,

    The "old" skins are still available and you can use them as explained in this forum thread:
    All RadControls Q3 2008 Skins Are Now Compatible with the Q1 2009 Release

    If you still decide to upgrade to the new skins (as they are much better and more consistent than the previous ones; and the majority of customers like them a lot) please do not hesitate to contact us in a support ticket and we will promptly help you with the conversion if needed.

    Best wishes,
    Ivo
    the Telerik team

    Instantly find answers to your questions on the new Telerik Support Portal.
    Check out the tips for optimizing your support resource searches.
Back to Top