Archive for February, 2004

Ghostwire achieves the Macromedia “Impossible”

Published on February 25, 2004 in Flash. 0 Comments

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:

"Also, to make a List or Tree scroll horizontally, try the following :
myList.hScrollPolicy = "on";
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.

The importance of components becomes even more pronounced as Macromedia moves to embrace the presentation server model for Flash development with Flex. One can only assume that some of the outstanding issues with the Version 2 components have to be resolved before the promise of Flex can be fulfilled. Hopefully, these improvements, if indeed they are being made, will lead to a much stronger and usable Version 2 component framework for the benefit of all.

Download Flash Player for Pocket PC link

Published on February 23, 2004 in General. 11 Comments

I was recently trying to download the Flash player for Pocket PC (for an Ipaq 5550 running Windows Mobile 2003) and had a terribly hard time finding the link to download it.

Here, for the restless (or frustrated) among you, is a direct link to the correct download page for the Flash 6 Player for Pocket PC.

And here's the rest of the story:

The download page for the Flash player for Pocket PC sends you to a page on HP's site, which redirects you to yet another page, on which there is no information whatsoever on the Flash player. Searching for variants of "Flash Player" on the HP site does not reveal a useful link either.

I was finally able to find the link in a newsgroup post after lots of Googling around. It appears that others have also been having problems (Aug 2003), , Oct 2003, Jan 2004.

On a related note, setting the PocketPC up to connect to our WiFi network was confusing too, thanks to the very poor usability of the "Connections" function.

All in all, connecting your Pocket PC to the Internet and browsing a flash site or using a Flash application should not take hours of sweat and tears. I hope that Macromedia will update its website to allow easier access to the Flash Player for Pocket PC and that Microsoft will improve the usability of its Connections feature in Windows Mobile 2003.

The possibilities for pervasive computing through Flash on devices is endless but we do need to improve end user access to the player.

MX Europe call for proposals

Published on February 20, 2004 in MX Europe. 0 Comments

I am very happy to announce that we are now accepting proposal submissions for the MX Europe conference to be held in September.

Currently confirmed speakers, apart from myself, include, among others, Allen Manning from Prismix and Ben Forta, Nigel Pegg, Tim Buntel and Waldo Smeets from Macromedia.

MX Europe is the off-shoot of last year's hugely successful CF-Europe event. The change in name this year underscores our firm commitment and focus on all MX technologies (including Flex). Last year's event was not solely on CF either but the name did (understandably) lead to many people assuming that it was. This year, make no mistake, we will be covering everything from animation and motion graphics with Flash, to hardcore RIA development with Flex, CF and J2EE.

See the MX Europe web site for more information.

Tim O’Reilly Update

Published on February 20, 2004 in London MMUG. 0 Comments

Tim held a wonderful session at the joint London MMUG and UK CFUG meeting last night on the Open Source Paradigm Shift.

It was a great honor to get to meet and talk with one of the great minds in our field and, based on audience comments following the event, everyone loved the event. Some very interesting issues were raised in the Q&A session at the end, on topics ranging from the future of Central to his thoughts on emerging Socialware applications.

Pictures from the event are now up on the MMUG web site, courtesy of Emilie Wood.

Tim O’Reilly

Published on February 15, 2004 in London MMUG. 0 Comments

We have a very interesting joint London MMUG and UK CFUG meeting planned for this Thursday (February 19th). The champion of Open Source Software and publishing legend Tim O'Reilly is going to be coming down to talk to us about The Open Source Paradigm Shift.

Here's a brief introduction to the session he will be presenting:

"The computer industry has gone through a sea change in the past few years. The killer applications of the web era turned out not to be PC-based software packages like the web browser, but web hosted applications like google, mapquest and amazon.com. These applications are built on top of Linux and Apache, yet they are themselves fiercely proprietary.

But what would most developers do with their source code? These massive systems are valuable for their data as much as for their programs. And by opening up XML web services APIs to that data, the most innovative of these sites are creating new opportunities for hackers to "scratch their own itch." One of the greatest challenges for open source in the next few years is to understand and adapt to the paradigm shift implicit in network computing, and to shed the legacy thinking of the desktop era."

After the talk, he will answer questions as well as talk about Macromedia Rich Internet Applications, wireless and cell phones.

If you're in London and would like to attend, please sign up online to reserve your place as we are quickly approaching our capacity for the meeting.

Last month we had a very well attended meeting with Ben Forta presenting on Flex and in next month's meeting we will return to our roots with some interesting technical sessions (as well as a few neat prizes from the box we just received from Macromedia!)

On using OS-styled themes in Web Applications (or “In support of Halo”)

Published on February 11, 2004 in Usability Design. 0 Comments

In our RIA consulting work, we often get requests to skin an application's components to fit the "look and feel" of a specific operating system (can you guess which one?) Yes, you guessed it, Windows XP.

The issue with this is that supporting a WinXP theme brings along with it WinXP OS expectations with regards to how the components should function. i.e., If it looks like WinXP, it better work like WinXP.

As you know there are certain limitations that WUI (Web User Interface) clients have when compared to GUI (Graphical User Interface) applications. The most prominent of these stem from the fact that a WUI application runs within a GUI application (the browser) as opposed to being a standalone OS application. The standard user expectation here is that the WUI application is a document or screen within an application. This alone affects the range of what can be achieved with regards to the behavior of certain components with a WUI. (It is also easier to lose the user due to this additional layer that does not exist in standard GUI applications.)

I cannot, for example, have a window within my WUI be dragged outside of the application bounds, although I can do this with a GUI interface. Also, certain V2 components behave differently from their WinXP and OS X counterparts. For example, the scrollbar is a hybrid Win/Mac scrollbar that hides the scroll buttons when not needed like the Mac yet places the scroll buttons on the extreme edges of the track like Windows. Imagine what would happen if you were to skin the scrollbar to be indistinguishable from the WinXP scrollbar: The scroll buttons would disappear when there is no content to scroll, leading to calls to your support center: "I broke the scrollbar -- the buttons disappeared!".

Having a theme that resembles what a user would perceive as belonging to a modern UI without having it resemble the theme of any particular OS to the point that it could be confused with it (and thus carry along OS expectations that the components cannot meet) is A Very Good Idea (tm). That is what Halo does. (And, not surprisingly, the look and feel of Opal is also based on this principle.)

For related information, read through the second part of our Opal RIA case study on Flash Ant: Design decisions and emerging usability patterns. This issue, for example, falls neatly into the "Don't Sell What You Can't Deliver" patternette.

The Problem with View Helpers

Published on February 2, 2004 in Design Patterns. 0 Comments

In my post on the Ariaware RIA Platform (ARP), I mentioned that while working on the first release of Opal, we had implemented View Helpers as part of our pattern-based framework for that project. Although this seemed like a good idea at the time, as the application grew, I noticed that it was partly responsible for much of the code duplication we started to experience. This led, among other things, to us not incorporating View Helpers into Bits and Pixels' own, AS2-based framework, ARP. (ARP also differs markedly from the Opal framework in our implementation of the various patterns, including the event broadcasting and handling model as well as the behavior of the controller and commands.)

Working with Telrock Communications, we are currently refactoring the Opal framework to bring it in line with the best practices pattern implementations we developed for ARP. These include, among other things, removing the View Helper classes (and encapsulating View Helper methods as public methods within the various forms/screens themselves) and adding view references to broadcasted application events (to be used by the Command classes). But why are we undertaking such a large-scale (and thus risky) refactoring of the base code in the run up to a second release? The answer, as always in refactoring, is to remove duplication.

A Command pattern implementation that does not allow the commands to receive view references leads to a very unhealthy duplication of Command and View Helper classes. As we all know, duplication is bad and refactoring is the answer. We actually noticed this issue late in the game in the run up to the first release of Opal and though we should have refactored it there and then, we decided that we couldn't afford the project risk at that point in time. Whether or not that was the right decision can be debated. Personally, I believe that Kent Beck couldn't be more correct when he states that the right time to refactor is the moment you notice duplication. This is related to one of the most important tenets of eXtreme Programming: Courage. (The courage to refactor when necessary.)

The removal of View Helpers is necessary to achieve better encapsulation and reduce code duplication. With the View Helper functionality neatly encapsulated within the various forms/screens themselves, we remove the need for code duplication (through the duplication of View Helpers) when composing new, aggregate screens or extending existing screens. With Commands receiving view references, we remove the need to duplicate Command classes when extending screens or composing new screens from one or more existing ones.

With these refactorings in place, the Opal framework should behave in a functionally equivalent manner to the Ariaware RIA Platform. Among other things, this is expected to result in a considerable file-size reduction in the application and aid in its scalability and maintainability.

I know that Lindsay has undertaken certain refactorings on the Java side of things (and quite possibly has plans for some more). Perhaps we'll be lucky enough to get an update from him in the coming days! :)

Bad Behavior has blocked 0 access attempts in the last 7 days.