<a href=”http://psychlonex.dyndns.org/”>John</a> and I just submitted our skinned FScrollBars to <a href=”http://www.actionscripts.org”>ActionScripts.org</a>’s component contest. Skinning… what a pain in the arse! Last time I do that shiot, fer sure. Hopefully, some ideas I got from <a href=”http://www.peterjoel.com/blog/”>Peter Hall</a>, and others via my post on <a href=”https://www.jessewarden.com/archives/000104.html”>Hybrid Component Design</a> will help John and I do a better version in 1.1. I hope we win!
I’ll upload tomorrow, I promise… :: passes out ::
Hey Jesse,
Not that I want to add to your pain, but could you fill me in as to what made the process so painful? I’d like for us to make this better as well.
nig
SCREEN shot please!
awe man i was up at 1am and almost emailed you but figured you were alseep.. hehe
Well, first off, skinning itself is actually a misnomer on the process…. Your actually changing the graphics of a skin movie clip, not the component itself. This adds a level of complexity in that I must have a movie clip already and specified for a specific part of the component. While this rocks for globalStyleFormat, I just wanna change the graphic yo, and digging through folders within folders is overkill. It should be, “This component uses this graphics, have at it.”
Secondly, the crossovers between what is linked and why is confusing. Like, some are linked, yet they don’t have to be because they are on the first frame of the scrollbar. This causes problems with skinning two scrollbars becasue of naming conflicts. You cannot have FScrollBars exist with 2 different skins without renaming the scrollbars graphics. This is complicated by the linkageID name collisions.
Now, why the linkageID name thing might not seem big, it’s the most confusing frikin’ thing in the world when dragging a component from one movie to the next. I kept getting folders within folders, and I think because since one linkageID name was off, Flash considered not the same even though they were EXACTLY. Therefore, sometimes the OSX scrollbar wouldn’t bring all it’s assets. Now, granted, this is a library slam and not a skinning slam, but if you drag the folder, it drags all the other assets with it into a duplicate structure of the movie it came from. Since these grahpics are duplicates of what you may have already had, you can’t easily switch out those with the ones you already have in “Other Assets > Component Skins”. So, you delete, Control + A to select the destroyed component, and try again. Library management I think is the worst part of the whole process. Now, granted, I finally got 2 skins to work in the library, but I had to rename them all to do so. Why can’t I have multiple skins?
You might not think this is an issue, but Windows Media, beleive it or not, set a precendant with my company. It’s skin ability has convinced my design and marketing department that we can do the same with Flash.
…with Peter Hall’s budding infratstructure, sure, but not in a reasonable amount of time and affordable prozac for me utilizing the current skinning methods. Because it’s such a pain to get multiple skins for one component to work, no way dude.
From the standpoint of globalStyleFormat, your always gonna have a fan of me. I think it’s a good first step, but it’s time to think of a new way. Wish I had the answer.
Basically, there is no easy way to conflict check what your replacing, what your not, what you need, what you don’t… if you make the wrong choice, your Library is screwed.
My gripes/wishes in no particular order:
Library-based undo would be awesome. It seems that if you drag a component into your movie, and realize it isn’t what you want, using undo doesn’t remove it or it’s assets from the library. This makes sense if youo drag a component from the library to the stage, but seems to be incorrect behaviour if you drag from another movie’s library, or from the components panel. Thank god for “revert”!
Normally, skinning isn’t too bad as long as you take your time and pay attention to what it is you’re editing. Where it got tricky (as Jesse mentions above) was when we had to have 3 versions of the scrollbar in one library. We both had to make sure that we had renamed every asset we used before trying to combine the 2. Jesse went a bit overboard at about midnight renaming a lot of assets that we didn’t even need for the osx scrollbar, I’m guessing because they were brought in when the component was added to his movie, or because every time he tried to bring it in, it complained about duplicates.
Jesse’s last comment really sums it up… “..there is no easy way to conflict check what your replacing, what your not, what you need, what you don’t… if you make the wrong choice, your Library is screwed.”
All in all, I think the current state of skinning is about as best as can be (I haven’t seen more than a few snippets of what Peter Hall is working on..*hint hint* ) given that it has to work within the current limitations of the flash IDE/player. But, what I’d like to see in the future versions is for macromedia to retool the IDE/player, possibly adding 2 new core objects, Component and SkinSet. Basically these would be library-friendly objects. The Component would appear in the library as a single object. Select it in the library and either right-click or choose from a menu something like “Edit Assets”. This would present you with a list of this components skinSet and whatever other assets the component uses. The goal is to keep the library uncluttered, and to clearly seperate code & core-assets from skin elements. The key is that somehow this would allow you to have multiple duplicates of a given skin element in the same library, ie.. 2 scrollbars, with 2 different scrollTrack symbols living in the same library.
This is getting long but my point is this… why try and fit the component model into flash? We now know that components are a pretty good idea and are here to stay. Is it possible then to fit flash to the component model?
Jesse – Good job man! Lookin’ forward to fixing all the little things and getting v1.1 out the door! I started packing an mxp, it should be a bit smaller then the version you submitted. (doesn’t have all of the extra, un-needed symbols for the osx version). I’ll send it over or post it up somewhere.
Very good comments, and better said than I. I guess I was still a little irritated at all of our troubles, therefore, my comment was a little subjective.
You too brah! As soon as it appears on ActionScripts.org, let’s see how easy it is to update via their form. I have to update the preview.swf anyway.