Aral Balkan

I was just looking at the new Ghostwire components, the Sliding Panel and the Tree component and was delighted to see that the tree component implements an automatic horizontal scrollbar. It weighs in at 18kb and performs beautifully in the online sample application.

It is interesting to note, regarding the automatic horizontal scrollbar, that in response to my criticism in my Ultrashock tutorial on the lack of automatic horizontal scrolling in the Macromedia tree component, the issue was labeled a "fact of life", with the suggestion that an acceptable workaround was to hard-code a horizontal scrollbar of a given ratio.

To quote the highlights of the ensuing debate:

Nigel:

myList.maxHPosition = 200; // or whatever"

Aral:

"Regarding horizontal scrolling: We actually figured out that you could hard-code a horizontal scrollbar by setting the maxHPosition (thanks Tanja) but did not include that in the tutorial initially for two reasons: #1 The tutorial was already in production and #2 It is a *partial* workaround / hack. We will update the tutorial with a note alerting readers to this workaround, however, the original issue remains:

By hard-coding the maxHPosition, you are create an inconsistent interface for the component by having an automatic vertical scrollbar that adjusts its thumb-size to the actual height of its content and an always-present horizontal scrollbar that does *not* adjust its thumb-size to the width of the available content. If I absolutely had to use the component, I would, of course, use it with the workaround to ensure at least the most basic usability but if I could possibly avoid using the component, I would do so until this issue is resolved in a consistent manner (i.e., I wouldn't use the component in its current form in a real-world application that required horizontal scrolling of the component.)"

Nigel:

"Re: the maxHPosition "hack", I guess there's not much I can say... It's not a hack. It's certainly a compromise, because there isn't really any way to resolve the issue you describe simply."

I'm glad to see that Ghostwire has found a way to solve the problem and I hope that Macromedia takes their example to heart.

If we want Flash to be a serious contender in the rich-client web application field, we really can't settle for second best any longer. Components are the cornerstone of a componentware approach to RIA development and they are, currently, one of the weakest features in Flash. Before the Version 2 components can be seriously considered for RIA work, we need, among other things, buttons that can resize automatically to fit the size of their icons, buttons and menus that can easily handle icons with different states (up, down, over, disabled) without resorting to skinning the component and, of course, having a tree component with an automatic horizontal scrollbar as well as a vertical one.

No one can deny the enormity of Macromedia's undertaking in forging Flash into an RIA tool from its humble beginnings as a tool for simple web animations. The Version 2 components, in many regards, are a step in the right direction but, for reasons widely known in the community (a few of which are mentioned here), their adoption rate for real-world projects is terribly low. It cannot be good when you have the leaders of large web application companies such as MSG at.NET warning developers not to use components in real-world projects (see slide 24).

At Bits And Pixels, we have had to build our own components to achieve better performance, lower file size and, in some cases, better usability and to streamline the development workflow. Not every company, however, has the resources to devote to custom component development. Component developers are a rare (not to mention, expensive) species and our goal should be to make it possible to create a majority of enterprise RIAs with teams lacking a component developer.