Colin Moock wrote a nice, and very thorough, article about skinning a V2 Progress Bar component. These kinds of tutorials are very much needed. Chafic has written some really good ones too.
I think the big outpoint though, is that a tutorial on how to skin a single component should not have to be as long as a tutorial on how to create a component from scratch. Take this quote from Colin’s article:
Some components require advanced skinning techniques not discussed in this article. For example, the Button component’s skin, perhaps surprisingly, is primarily code-based. Skinning a Button component requires a thorough understanding of the Button skin code.
No knock to Colin, he’s merely reporting the facts. But am I the only one who sees that as a major outpoint? It’s a button for God’s sake! It shouldn’t require a throrough understanding of ANY code to make it look a little different.
Particularly when you think of it like this: who is most likely going to want to skin components? Designers or high end developers? Or better yet, who would you want to be handling that task in your company? Is a designer going to have a thorough understanding of the Button skin code? Probably not. Is an object oriented application developer going to make a really good component skin? Possibly, in his own mind. Probably not in the mind of the designer.
Even as a fairly experienced coder, I found it was actually easier to make my own components than to try to figure out all the intricacies an idiosyncracies of styling and skinning V2 components. I’m really hoping that Macromedia takes a whole new angle on the V3 components in regards to skinning and styling.
Wow. That article that Moock did was like a week late – i actually had someone msg me saying ” bet you could have used this a week ago?”. It was a great tutorial, one of the more thorough ones.
And they are needed because altho the docs do a good job of explaining the mechanics, they don’t necessarily do a great job of explaining the practical implementation.
I agree with the button statement. I felt the exact same way – a button – perhaps the most simplest of components, did in fact, take me the most amount of work to reskin in a project where I used quite a few of the components. And not to mention the way that its been built to implement the skin – using a clipevent OR writing to a prototype? Both seem strangely backwards to me.
I had decided to use the MM components for this one project so that I could learn the architecture – learn how to use them. But I am with you – altho they provide a wide range of functionality, I am more than likely to create my own rather than use the MM ones. Right now I am creating my own version of the datechooser, because out of all the components, that was the absolute worst.
Great point about the skinning — case in point. I’m working on a gig where I recommended the client use BitComponents for the UI (all dynamically generated by code). The artist who is responsible for the look of the application was a strong Photoshop/Illustrator person, but had almost no Flash expertise.
In less than an hour, she was able to skin the BitComponents to make the appearance of the UI screens conform to that of the rest of the application – no coding changes required
Very much agreed. These skinning tutorials should be included with product release. The components with Flash are fantastically simple to use, but if you want to skin, perhaps… the window component and scroller… … the process is near impossible.
I should be able to take the provided components, and understand how to adapt them to my vision.
v3? Hope MM hears you!
It seems like Flex is getting most of the attention for this kind of things. I love Flex but I think that if MM don’t update components to work better in the next version (maybe as you point, an v3 version) of the Flash tool they could make a serious mistake.