Marking Occurrences

References and declarations in Flex Builder development

1. sascha/hdrs 04.26.07 / 5pm

   very nice! But this kind of embarrassing when rolling over their About SCPO:Benefits datagrid:
   TypeError: Error #1009: Cannot access a property or method of a null object reference.
   at com.scion.web.dev.managers::PinnableToolTipManager$/createToolTip()
   at com.scion.web.dev.common.widgets.scripts::WidgetSCPOBenefitsBase/::mouseHandlerEvent()
2. Phillip Kerman 04.26.07 / 5pm

   No offense, but that site’s got tons of runtime script errors. In fact, with all due respect to those producing solid Flex apps… the ones with no runtime script errors are in the minority.

   It’s my pet peeve maybe but I really wish I could offer something constructive. By pointing out such glowing issues I think I’m doing such devs a favor.

   In the case of Scion, I haven’t found such errors causing the whole thing to come crashing down… but I do see a lot of flashing that I don’t believe is intended.

   They might also look at whole-pixel locations for the fonts.
3. PNP 04.26.07 / 8pm

   There are many issues with this site. Where is the load management? Have you visited the 360 page? what is up with that loading screen with the random “stop” or “autoplay” text on the bottom? The odd styling of the top nav on the left side and the right side? And their loader animation between sections has odd flares that are cut off and make it look like it’s in a box. Minus the various runtime errors.

   It’s a good effort but vast room for improvement. Their last site was fantastic from design through experience, albeit older flash. The user experience on this site pales in comparison I feel.
4. Jason Hawryluk 04.27.07 / 2am

   Very nice effort, but 94% (main page) cpu on my pc. For a normal user I’m assuming not very usable.
5. Phillip Kerman 04.27.07 / 1pm

   yeah, it’s got some leaks too. Just sitting on the home page the browser took over 250 Megs of RAM. Plus, they must have extended that 15 second timer because it totally hanged for me.
6. James Polanco 04.27.07 / 3pm

   First off, I would like to thank everyone for both their positive and critical comments. Feedback on an application of this magnitude is very important to make a better experience for all users. I agree that it is unfortunate that there are runtime errors and we are actively tracking them down in our continued QA efforts. The ones that have been pointed out here have been fixed and will be included in the upcoming maintenance release in the following week.

   As Phillip pointed out, runtime issues tend to exist in Flex applications. Even with an extensive QA cycle and in-depth testing it is hard to track down every case. This is especially true when working within a fast application development cycle and multiple development partners such as this project. But at the same time, I feel there is even a bigger challenge with how exceptions are treated in the ECMA standard and the Flash Player.

   The first issue that Flex developers face is that a ‘throws’ keyword does not exist in the ECMA standard. This prevents the compiler from helping developers know what throws an error and when. Without having every developer scrub the docs it is easy to miss an error that could be thrown in a specific case. On top of the language issue there is also not a simple place to catch all errors, such as the main() method in Java. It’s easy for a Timer in a separate scope to throw an error and if the calling code is unaware it will quickly propagate up and out to the player.

   Because of these challenges it puts more pressure on both the development team and the QA team to try every case and to think of every situation that may throw an error. This becomes harder and harder to do on larger and larger projects. What is great though, is that as community sees the problems and posts about them it allows us as developers to look at different strategies to prevent them in the future (or at least fix them as they are pointed out)

   As Jason pointed out there are potentially performance challenges depending upon system speed. Some of these are caused by the fact that there were many different partners developing content for this application. All of our work was done in Flex 2 / ActionScript 3, but some of the creative work was done in Flash 8 / ActionScript 2 for various reasons. To give a little perspective of how the application was developed; it was my company’s responsibility to develop the underlying framework and core application functionality while Scion’s design partners made the application look as beautiful and as interactive as it is.

   This was a very large project with tight deadlines that involved multiple companies in different locales. Integration and QA of the facade/presentation movies was consequently compressed and our QA and development teams worked hard to overcome this. We would not have been able to execute the project at all without a custom development environment that was constructed for this project. We are now in a position to make optimizations and fixes, although experience in production so far suggests that problems are limited.
   With Flex’s growing adoption rate, there will undoubtedly be more groups undertaking Flex applications, with this there will undoubtedly be growing pains as the community adopts a new collaborative development environment, which this project helped create a model for. As this growth occurs, how teams work together to develop large Flex applications will evolve and help provide better solutions to manage performance and deployment challenges. Again, thank you for the honest feedback and opinions and we will continue to work on performance, usability and functionality.

   James Polanco
   Lead Production Developer
   DHAP Digital, Inc.

Powered by Hemingway flavored Wordpress.

Entries RSS Comments RSS