Hello there, Telerik!
It would be great if this tool could grow to further establish Telerik amongst ASP.Net developers, who are looking around at alternative, free frameworks. So far, yours does almost what the jQuery UI Theme Builder does, with Silverlight (and I'm not sure requiring Silverlight is considered a feature to end-users just yet -- certainly to bored developers!).
Glad to see something like this come along. It was inevitable, especially given a certain other UI framework that Microsoft is getting -- perhaps uncomfortably -- close to by adopting their core library.
Anyway, my requirements for components we purchase are probably a little different than the majority of your clients. We need nearly everything we put into the guild sites people create from our site to be dynamically styled, based upon settings the user makes in their control panel (if you're interested in where we're going with the controls you already offer, go make a site, click Control Panel, and look at the link under the "In Beta" accordion section).
So, that being said, I was a little excited to see the words Telerik, Visual, Style, and Builder all together! My question is: what are your plans for the tool? If they are to keep it on your site as a way for people to generate skins, download a ZIP, and extract it to their site, then it will be a fantastic tool for intranet and public-facing sites that don't require personalization at the user level.
But jQuery UI does that with their tools, and it's free.
Might I suggest the following? Please forgive me if they're already in your plans:
- Release it as an ASP.Net control. Keep the requirement for Silverlight if you absolutely must, but release it so we can use it to let our users customize their sites, which, incidentally, would feature far more of your controls if skinning/styling could be handed over to the user more easily.
- Provide access to the output in a non-ZIP format. .GetCss() would be the bare minimum, but it would be much better if we could have strongly-typed access to the elements they've set vaues for, and the values they've set for those elements. That way, we can run it through some logical processing (say, if the user's on a mobile device) instead of parsing text. Helps even more for persisting the preferences in our database, too.
- (see 2): If you do it the OO way, of course, the same settings could be applied to XAML for silverlight versions of the controls.
- Whack the whole Hue/Saturation thing and get back to color pickers. Did you guys lock the human interactions guy in the closet while you did that? ;)
One last thing. I went through the Style Builder with the Mac. Do you folks there plan on testing with the Mac? If not, I'd be glad to list the current problems. But if you already know about them, I'll save my fingers for coding. =)
Oh and, one final note: if you can't release the source for this but you are willing to release it as a control, please, for the love of all that is holy, allow us to specify custom UI objects and what types of styling (text, background, etc.) can be applied to them. Then take those objects and runtime and dynamically include them and return the user-selected results to the developer. Sounds complicated -- probably better going the source route. =D