Blog

Latest entries from the YAY! blog...

August 25, 2005

Flash vs DHTML: Round 2

Writing about web page http://www.hive-brain.com/archives/000043.php#more

There are two main types of applications where I think Flash is a big lose compared to HTML:
1. Anything with a fair amount of textual content
2. Anything with heavy use of forms/ standard UI controls. My initial post mentioned a couple of missing HTML tags whose absence cause me problems, but those individual examples are not the point. The bigger point is, Flash (as a vector animation tool) is never going to be nearly as good at presenting text as a real browser.
I’ve come up with clever (and bandwidth-heavy) solutions for things like sub- and superscripts. I’ve embedded symbol fonts so I can present the quivalent of HTML entities. But isn’t it a waste of my development time to be solving problems like the presentation of subscripts, when there already exists an environment that can handle that easily? And if I’m presenting lots of textual content to a client, wouldn’t it be better if the experience they had with that content was like their experience on every other site they visit (Things like “select all”, scrolling, resizing, etc.)
Another big issue with presenting text in Flash (and one I’m grappling with right now) ha to do with accessibility and exposure to crawlers. Sure there are things you can do, and I’m sure Macromedia has some spiffy ideas on their site somewhere, but again, isn’t that a big waste of a developer’s time?

I’m with you, Charlie :-)

August 22, 2005

Mobile device development realities

Writing about web page http://news.com.com/Write+once%2C+run+anywhere+not+working+for+phones/2100-1037_3-5788766.html

Though the cell phone industry has made tremendous strides in the last two years, it’s becoming clear to engineers at Sun that the ultimate goal of “write once, run anywhere” may never be fully realized because the cell phone market is simply too diverse, said Eric Chu, a Sun senior director who played a role in much of the early MIDP development.

Via Flash Devices:
Interesting article on CNET, about fragmentation of Sun’s Java Mobile Information Device Profile (MIDP). The article attributes the problem to the diversity and growth of mobile platforms, and the resulting difficulties that Sun is having in maintaining the core ‘write-once, run anywhere’ strength of Java.

August 18, 2005

Flash Influences: Tokyoplastic

Writing about web page http://www.tokyoplastic.com

The first in my series of ‘inspirational and aspirational’ uses of Flash, or as I prefer to think of it, ‘Flash stuff that I think ROCKS‘. The quality and fluidity of the animation, the wonderful artwork style, and in particular the use of sound by the Tokyoplastic team had my jaw open all the way through. Turn up the volume (especially if you have big speakers) and try Drum Machine or Music Box.

Apparently this stuff is created using something called a timeline . Never seen one myself…

August 11, 2005

FPAD Day 4

Lots more on creating effective OO-based Flash today, including the development of custom behaviours that can be re-used easily and lots more practice on creating and extending class files linked to Flash elements – screens, components, objects etc. However, scope is a real problem when coding classes, because the scope of function literals, timeline and movie paths can really confuse unless you have a clear idea of how the framework operates. The problem is that Flash has several added complications to the conventional inheritance tree – the timeline, nested movie clips, _root, function literals, screens and several interpretations of the this keyword means that you have to be very careful about what relates to what.

Tip re the Zoomify app – AS1 uses prototypes, so one way to list all methods attached to the prototype is to trace back a for/in/typeof command that will list everything in the prototype. Also, after a brief dig in Livedocs, it would appear that the reason why the app in IE isn’t resizing the components is down to an ActiveX-based timing problem; after checking, the Stage.width property is always passed as 0, which is why the resize never occurs – I can recreate this easily using the debugger, so I need to force a delay onto the object size calculations.