Archive for the 'Slashdotter High' Category

Flash Myths and Misinformation

Published on August 13, 2007 in Flash and Slashdotter High. 25 Comments

There have always been myths and misinformation about Flash. Five years ago, when we were at the height of the age of the Skip Intro, this was perhaps understandable. But it is discouraging to hear the same misinformation being regurgitated over and over even today and it's difficult to find the time to keep writing the same responses to the same tired myths. (For an example, see this uninformed comment on a recent post at WASP, and read my response to it.)

So let's do something about it, shall we?

Here's a simple template:

<strong>Myth:</strong> Text.

<strong>Fact:</strong> Text.

Copy this into the comments and dispel a Flash myth today.

Let's make this post into a comprehensive list of Flash myths and facts that we can simply point people to in the future. Let the myth-bustin' begin! :)

A bad implementation does not a bad technology make

Published on July 8, 2006 in Flash and Slashdotter High. 7 Comments

This week, Robert Scoble hits a badly implemented Flash site (without alternative content) and generalizes from this one experience that he will not use Flash: Why I don't use Flash.

This is akin to watching Battlefield Earth and concluding that film is a terrible medium because you just sat through a really, really, really crappy one.

Of course this is a non sequitur; a classic example of a post-hoc fallacy: "This implementation of a certain technology is bad, therefore this technology is bad." It is a common error that the intellectually lazy are prone to commit and Flash has historically been at the receiving end of such arguments. Part of the attraction of making such statements, where the conclusion does not follow from the premise, is that they are very easy to make. Mike Chambers demonstrates this in his retort, Why I don't use Windows Media Video, wherein he purposefully generates a similar non sequitur regarding Windows Media Video before concluding:

Lesson: always recognize poor implementations of technology, before you make sweeping generalizations about a technology based on that implementation. (This applies to pretty much any technology).

I also aired my thoughts on Robert's post in this comment on his blog so I won't repeat what I said there, here. (It was cool to see that another commenter on the post had mentioned my interview on the Boagworld podcast from a few weeks ago -- nice to see that people are finding it useful!)

In conclusion, making sweeping statements about a certain technology -- be it Flash, Ajax or plain old HTML -- based on a single bad implementation does not hold any value and adds nothing to the knowledge pool apart from noise. I hope we can all move beyond such lazy thinking and realize that, regardless of the technologies we use, most of us share the desire to create web sites and applications that are easy (dare I say, fun) to develop, easy (dare I say, fun) to use, and successful. Although certain technologies may make the process easier or harder (I strongly believe that Flash falls into the easier category for most things, like the creation of cross-platform applications, especially with the release of Flex 2 and Flex Builder 2), and although certain things may not be possible with every technology (for example, Flash has alpha channel video, which Ajax doesn't), there will ultimately be implementations in any technology that run the gamut from absolutely horrible to awe-inspiring, with many shades of gray in between.

Why do people who are clueless about Flash feel a driving need to write about it?

Published on January 12, 2005 in Slashdotter High. 17 Comments

This must be some sort of hidden epidemic: It appears that people who are clueless about Flash feel the need to write articles bashing it. Excuse me but I thought that was our job! Personally, I feel offended when someone who knows nothing but XML and Java feels the need to encroach on the turf of hard-working Flashers by criticizing Flash using myths and misinformation when we can do a much better job of bitching about things using actual facts! :)

The article I'm talking about is the one that JD blogged about called SVG: Imaging`s[sic] Pot of Gold? (It seems that someone has to teach the editors at DevArticles the difference between an apostrophe and a single opening quote.)

In it you will find such nuggets of misinformation like:

"Flash might be wonderful for many graphics tasks, but SVG can do everything Flash can do and more."

One can only wonder whether Ted Long, the article's author, has ever so much as launched the trial version of Flash when he makes such a brazenly incorrect statement with the literary equivalent of a straight face. Ted, sorry, but you're wrong, wrong, wrong!

You are comparing apples to oranges (and heck, you don't even have the common decency to do it on Slashdot, where such things are accepted!)

Debunking Ted

To start with, let me answer the "SVG can do everything Flash can do and more" claim:

Flash has video, SVG does not. (SVG 1.2 will support it but there are no final players that currently do and SVG 1.2 is currently a working draft. Adobe's next player should, based on the technology demo.)

Flash supports sound (SVG 1.2)

Flash allows socket communications, SVG does not. (Again, the SVG 1.2 spec does propose an implementation for this.)

Flash maintains state on the client, SVG does not.

Note: Flash supports all these now, not sometime in the future based on a draft proposal.

"The real bonus comes on the disk scale, however. Vector graphics weigh in for less than high-quality raster (pixel) images."

Wrong: Although I've never heard of the "disk scale" before, as Flash developers who have been working with vector graphics since the earliest days of Flash, we know that the size of vector graphics can mushroom based on their complexity and that this can also have a real affect on processing and playback performance. This, coupled with how much (and what type of) compression is used in the bitmap image can mean that bitmap images come out smaller than vector graphics. This sweeping statement, thus, is inaccurate.

To prove this, take a look at the GIF of this Tiger illustration (71kb) and compare it to the size of the SVG file (95kb). (Of course, we could debate until the cows come how as to what constitutes a "high quality" raster image – 0% compression? Subjectively the GIF of the Tiger illustration is "high quality" through it may not be fit for large-scale print. Then again, we're talking about web-based applications here.)

Now let's move on to answer the inaccurate claims on the "taking aim at Flash" page:

"Both require browser plug-in; SVG will get built-in browser support (e.g. Mozilla)"

It may well be that SVG gets built-in browser support but right now, that's not the case and the Flash player is ubiquitous. How long should developers have to wait until this happens? Should we put our project on hold for a month, year, two years? I'm running the latest FireFox right now and I can't view SVG content.

"Easy-readable plain-text vs. binary format"

Easily-readable if you're the type of person who hacks Linux kernel code, maybe. Have you ever tried to "read" through a complex SVG file? Here's a part of the SVG from a tiger image:

<g style="fill: #ffffff; stroke:#000000">
<path d="M-129.83 103.065C-129.327 109.113 -128.339 115.682 -126.6 118.801C-126.6 118.801 -130.2 131.201 -121.4 144.401C-121.4 144.401 -121.8 151.601 -120.2 154.801C-120.2 154.801 -116.2 163.201 -111.4 164.001C-107.516 164.648 -98.793 167.717 -88.932 169.121C-88.932 169.121 -71.8 183.201 -75 196.001C-75 196.001 -75.4 212.401 -79 214.001C-79 214.001 -67.4 202.801 -77 219.601L-81.4 238.401C-81.4 238.401 -55.8 216.801 -71.4 235.201L-81.4 261.201C-81.4 261.201 -61.8 242.801 -69 251.201L-72.2 260.001C-72.2 260.001 -29 232.801 -59.8 262.401C-59.8 262.401 -51.8 258.801 -47.4 261.601C-47.4 261.601 -40.6 260.401 -41.4 262.001C-41.4 262.001 -62.2 272.401 -65.8 290.801C-65.8 290.801 -57.4 280.801 -60.6 291.601L-60.2 303.201C-60.2 303.201 -56.2 281.601 -56.6 319.201C-56.6 319.201 -37.4 301.201 -49 322.001L-49 338.801C-49 338.801 -33.8 322.401 -40.2 335.201C-40.2 335.201 -30.2 326.401 -34.2 341.601C-34.2 341.601 -35 352.001 -30.6 340.801C-30.6 340.801 -14.6 310.201 -20.6 336.401C-20.6 336.401 -21.4 355.601 -16.6 340.801C-16.6 340.801 -16.2 351.201 -7 358.401C-7 358.401 -8.2 307.601 4.6 343.601L8.6 360.001C8.6 360.001 11.4 350.801 11 345.601C11 345.601 25.8 329.201 19 353.601C19 353.601 34.2 330.801 31 344.001C31 344.001 23.4 360.001 25 364.801C25 364.801 41.8 330.001 43 328.401C43 328.401 41 370.802 51.8 334.801C51.8 334.801 57.4 346.801 54.6 351.201C54.6 351.201 62.6 343.201 61.8 340.001C61.8 340.001 66.4 331.801 69.2 345.401C69.2 345.401 71 354.801 72.6 351.601C72.6 351.601 76.6 375.602 77.8 352.801C77.8 352.801 79.4 339.201 72.2 327.601C72.2 327.601 73 324.401 70.2 320.401C70.2 320.401 83.8 342.001 76.6 313.201C76.6 313.201 87.801 321.201 89.001 321.201C89.001 321.201 75.4 298.001 84.2 302.801C84.2 302.801 79 292.401 97.001 304.401C97.001 304.401 81 288.401 98.601 298.001C98.601 298.001 106.601 304.401 99.001 294.401C99.001 294.401 84.6 278.401 106.601 296.401C106.601 296.401 118.201 312.801 119.001 315.601C119.001 315.601 109.001 286.401 104.601 283.601C104.601 283.601 113.001 247.201 154.201 262.801C154.201 262.801 161.001 280.001 165.401 261.601C165.401 261.601 178.201 255.201 189.401 282.801C189.401 282.801 193.401 269.201 192.601 266.401C192.601 266.401 199.401 267.601 198.601 266.401C198.601 266.401 211.801 270.801 213.001 270.001C213.001 270.001 219.801 276.801 220.201 273.201C220.201 273.201 229.401 276.001 227.401 272.401C227.401 272.401 236.201 288.001 236.601 291.601L239.001 277.601L241.001 280.401C241.001 280.401 242.601 272.801 241.801 271.601C241.001 270.401 261.801 278.401 266.601 299.201L268.601 307.601C268.601 307.601 274.601 292.801 273.001 288.801C273.001 288.801 278.201 289.601 278.601 294.001C278.601 294.001 282.601 270.801 277.801 264.801C277.801 264.801 282.201 264.001 283.401 267.601L283.401 260.401C283.401 260.401 290.601 261.201 290.601 258.801C290.601 258.801 295.001 254.801 297.001 259.601C297.001 259.601 284.601 224.401 303.001 243.601C303.001 243.601 310.201 254.401 306.601 235.601C303.001 216.801 299.001 215.201 303.801 214.801C303.801 214.801 304.601 211.201 302.601 209.601C300.601 208.001 303.801 209.601 303.801 209.601C303.801 209.601 308.601 213.601 303.401 191.601C303.401 191.601 309.801 193.201 297.801 164.001C297.801 164.001 300.601 161.601 296.601 153.201C296.601 153.201 304.601 157.601 307.401 156.001C307.401 156.001 307.001 154.401 303.801 150.401C303.801 150.401 282.201 95.6 302.601 117.601C302.601 117.601 314.451 131.151 308.051 108.351C308.051 108.351 298.94 84.341 299.717 80.045L-129.83 103.065z"/<
</g>

Ten points to Ted, if he can "easily read" and let me know which part of the tiger that code draws.

"$50,000 Flash Generator license for creating large-scale dynamic graphics vs. inexpensive packages such as PHP, XSLT, JSP and others"

Where have you been the last few years, Ted? Generator has been discontinued and you can do nearly everything Generator could in the Flash client these days. Oh yes, and those weird things you see out on the street are called au-to-mo-biles!

"Both allow embedding of typefaces (fonts); SVG allows multiple SVG documents to reference same SVG font file"

Flash allows the same thing using Shared Fonts.

"SVG supports Photoshop-like filter effects on vector graphics; Flash doesn't support filter effects"

True, Flash doesn't currently support filter effects but, according to Kevin Lynch's demo in Tokyo, the next version will. Could this be the one true statement in the whole article?

"SVG is a truly open and extensible format; anyone is welcome to add functionality; Flash is controlled by Macromedia; you can't extend the format without violating their patents/copyright"

Again, you are wrong. The SWF file format is open. The FLA isn't, the Flash IDE isn't and the Flash Player isn't but last I checked neither was Adobe SVG Viewer or Adobe Illustrator. I want my open-source Adobe Illustrator now, you hear?! Darn that closed SVG format!

Where Flash and SVG differ markedly is that we have not one but two professional IDEs (Flash and Flex) that make it simple to create Flash applications. Show me a comparable IDE for SVG. And no, Notepad just doesn't cut it!

The tools that do exist for SVG development don't even register on the features scale when compared to Flash MX 2004 or Flex Builder. Let's take a look at Adobe Illustrator, the self-professed "premier tool for generating SVG content." Its SVG Interactivity palette, for example, would have any Flash developer begging to use Flash 4 instead!

Another tool, Jasc WebDraw from Corel boasts: "Standard illustration tools", "Gradients" and "Bitmap images" as three big features on the first page of its features section. For some reason, that just doesn't get me excited! Could it be because we've had those primitive features in an easy-to-use IDE for the longest time and have moved on to things like Flash Remoting, Flash Communication Server and pattern-based Rich Internet Application development using ActionScript 2?

Ted's article would have been timely and perhaps even somewhat accurate if it had been written in the Flash 3 days (if we had had SVG back in those days, of course.) Today, it is antiquated, inaccurate and, quite frankly, a waste of good bandwidth.

I hope the next article I read that criticizes Flash is at least written by someone who has a clue as to what Flash really does. I criticize Flash all the time but for a different reason: I love Flash and want to see it improve. It's tough love, I admit, but the truth of the matter is that currently there's nothing out there for building rich-client web applications that is as powerful, easy-to-use or just downright as much fun to work with than Flash.

Dreamweaver 101 for Slashdotters

Published on January 9, 2005 in Slashdotter High. 2 Comments

I sometimes drift over to Slashdot to see what my fellow geeks are debating at the waterhole. Being a self-professed geek myself, you'd think I would find it a pleasurable gathering of high intellects and yet, for the most part, I keep finding myself disappointed at the myths and misinformation that Slashdotters appear to take great pride in perpetuating, especially when it comes to matters concerned with Flash and, quite possibly, anything that isn't Open Source.

I love Open Source. I also believe that I've contributed my share to Open Source, with the Ariaware RIA Platform, FLP Maker, FlashAnt, etc., and hope to continue to do so. However, this doesn't mean that I take every opportunity to badmouth closed-source applications. The mantra at Slashdot appears to be: Closed Source Sucks (CSS?.. Is this a conspiracy? :))

This is why I've started a new catagory on FlashAnt called Slashdotter High, to help Slashdotters get at least a high-school education in things-not-Open Source so they don't end up sounding so clueless when they post. Therein, I'll occasionally be highlighting Slashdot threads where the Flash "facts" being spouted by our so-called "experts" date from the Internet equivalent of the Bronze Age.

It's funny enough that what prompted this post wasn't a thread on Flash (that evil tool for creating huge animations and taking candid pictures of you with your webcam when you're not looking) but Dreamweaver. Specifically, on Dreamweaver templates.

I've always found the templating feature in Dreamweaver to be very useful when working in teams for HTML-based sites. They give you the ability to demarcate parts of a web page as editable and leave others locked so developers cannot accidentally alter them. In this way, you can somewhat consider templates in Dreamweaver as a step towards the Contribute model. (Contribute gets mentioned just once in the thread, by a poster defending Dreamweaver templates.)

What I found interesting about the thread was that the article that sparked it doesn't really offer an alternative to Dreamweaver's templates. It suggests that people instead use a PERL-based command-line template processor called ttree.

Let's see how it compares to Dreamweaver:

Dreamweaver templates:

  • Visual: Select an area visually in Design mode, set it as an editable region.

  • No programming experience/language necessary: Click in an editable area and change the content

  • No separate "template processing" or "page generation" stage

Verdict: Visual, intuitive, easy-to-use

ttree:

  • Text-only/command line: Must use special template tags (after learning them)

  • You need to know PERL to some degree

  • Templates must be processed to create the final pages (whenever content changes)

Verdict: Non-visual, requires PERL and command-line interface (CLI) usage knowledge, must process templates on each update

Here's a sample config file for ttree and the required command-line syntax, taken from the Getting Started with the Perl Template Toolkit article on DevShed:


$ ttree -f /home/dent/web/ttree.cfg

src = /home/dent/web/templates
dest = /home/dent/web/html
lib = /home/dent/web/lib

pre_process = header
post_process = footer

verbose

$ ttree -s templates -d output -v

Something tells me that seeing that didn't just make every designer reading this dump Dreamweaver and start clicking wildly away to download the latest version of PERL and its templating toolkit.

Having established that the Perl Template Toolkit and ttree are not viable alternatives to Dreamweaver templates let's examine why the article's author, Mark Stosberg, made such a claim. To see the reason, you don't have to search too far beyond how he describes himself on the Slashdot thread: "I'm the author, and I'm a professional Perl programmer. I prefer Perl because I know Perl better."

In other words, a classic example of having a hammer and everything you see mysteriously resembling a nail. In this case, it has led the author to compare apples with oranges and declare oranges the winner, to loving applause by the Slashdot crowd.

To give the thread credit, a poster did suggest another alternative, the open-source HTML editor Nvu (pronounced "N-View".) Again, however, I fail to see how Nvu can be compared to Dreamweaver. In this case, it's not so much apples and oranges but comparing a Sinclair Spectrum to a dual-processor Xeon box -- sure, they're both computers, but...

I installed Nvu to take it for a spin and immediately hit a couple of snags: In the site definition dialog box, I couldn't find any way of setting up a local site. (Apparently you can only work on remote files.) Undeterred by this huge lack of functionality, I then tried unsuccessfully to open a PHP file, only to be reminded by Nvu that it was "Not an HTML file." Oops! Strike two! Then I tried to hand code a little PHP in the source code view and Nvu corrupted it by removing part of my code and adding an import statement for a CSS file in its place. At this point, I decided to label it under the "Not Quite Ready for PrimeTime" bin with a note to look over version 1.0 when it becomes available.

Is Nvu an alternative to Dreamweaver? Not by a long-shot.

Conclusion: There doesn't appear currently to be an open-source alternative to Macromedia Dreamweaver. If you are looking for a complimentary product to aid in team development of HTML-based sites, take a look at Contribute.

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