hmm... Getting JS Error in IE6.

I often calls javascript functions from my actionscript program, and let js to do ajax. This way I avoid recompiling the actionscript for changed functions. And if the requirements are fixed, I normally call services directly from actionscript.

XULRunner is for apps that DON'T run in the browser, right? So that's why I didn't include it for comparison.

In general, anything that won't run in IE without a plugin (except for Flash, which is a special case due to the fact that most people already have it) is a non-starter in my book. This is the case with XUL, right?

What about XULrunner as an option to compare with?

Cool!

My main point is that Flash isn’t '99% bad', as Jakob Neilson once said. It's not even a little bad. It’s just not the lingua franca of the web, so it's sometimes inappropriate.

It can be a secret weapon that lets you do things that just aren’t possible any other way.

But it should only be used where it can add real value.

Due to the specialization, finding devs who are conversant in both Flash and AJAX is really hard work.

In particular, finding good developers who are willing to work on Flash can be very difficult. There’s a cultural perception that Flash is not something real developers use: similar to the perception 5 years ago that javascript was not a real programming language.

But if you’re using the Flash nuggets model I propose, you need developers who can do bothl: what you don’t want is for your devs to specialize at a lower level than front end / back end. Otherwise, you’ll start adding Flash unnecessarily just to keep the “Flash guy” occupied.

Solution: build ‘em yourself. Takes years to start up. After a while it becomes a machine, a culture.

The AJAX/Flash crossover artist is in extremely high demand nowadays. So once you build a team like this, take good care of them! And if you have these kinds of skills, then you should have no problem finding cool, high-paying projects to work on.

There’s lots of stuff that Flash developers think are pretty cool, but that for whatever reason doesn’t seem to have a lot of momentum behind it.

One such thing is Sockets. Flash lets you have a persistant connection between the server and the client. In a traditional web application, the client always asks for stuff, and the server responds with whatever the client asked for. There’s no way for the server to send a message to the client, something that is necessary for building, say, a web-based IM client.

The thing is, all of the big IM clients don’t seem to use Flash Sockets! Instead they use something called COMET, which is basically a hack that keeps an http connection alive until the server has a message to send to the client. I think the main reason for this is that the ports that Flash Sockets use are often blocked by corporate firewalls. So Flash Sockets don’t seem to be as useful as they sound like they would be.

Flash also lets you save HUGE amounts of data on the clients hard drive. And Local data objects (the Flash equivalent of cookies) are much less likely to be turned off or deleted, because users don’t even know they exist. The ethical implications of taking advantage of this are left as an exercise to the reader.

But we don’t use them, and I haven’t heard of a lot of developers in the consumer internet space using them. So this sounds very useful, but it hasn’t proven to be a big draw.

Finally, there is FLEX. Flex is Adobe’s developer-friendly authoring environment for Flash. It’s declarative XML, similar to html really. It’s seems optimized for authoring full-screen desktop-like apps that work in the browser. This is cool technology, and it seems like it would be really good for corporations that are porting desktop enterprise apps to the internet. But like I said at the beginning, the last thing we want is a full screen of Flash content. It just doesn’t look or feel webby. Also, hello world weighs in at 120K right now, so it’s too heavy for use in the consumer space.

If the programming model of FLEX appeals to you, but you don’t like the fact that it outputs flash, then check out Laszlo. They have a similar technology that outputs AJAX code. My take is that the look of the applications output by these systems doesn’t look very webby.

Finally, Flash is the best front end for editing multimedia files online. This isn’t too surprising, given that it’s the best way to play the files, and you need to play the files in order to edit them.

Widgets (flash nuggets that other sites use) can work really well in Flash.
A chunk of flash code it totally self-contained. It’s guaranteed not to conflict or interact weirdly with the web page.
Multiple widgets can be easily embedded into a page. And it’s usually not that important that the content of a widget be picked up by a search engine.
A lot of times, the motivation for adding widgets to a blog or other page is to give it some “bling”. So the fact that the widgets don’t look like html is actually a bit of a plus. They’re like a decorative element on an otherwise plain outfit. They’re fashion accessories.

We’ve had really good experience with the slideshare widget being in Flash. But of course it is possible to make widgets in html as well. In fact, the single most popular widget that I can think of are google ads, and they are in javascript. So a good rule of thumb is, if it’s something that needs to blend in and look like part of the site, then maybe it should be in dhtml. If it’s ok for it to stand out and look a little flashy, then flash is Ok.

What a lot of people don’t know is that Flash is the only decent way to get access to the media production parts of your computer. Your web app can get access to the microphone and the webcam of the client PC, and can stream that content up to a server. This is pretty star-trek type capabilities, and it hasn’t really been exploited by a lot of people yet.

Some cool applications are starting to pop up. For example, youtube lets your record video directly using the site. And sites like bubbleshare allow you to annotate your photos with audio that you record using the site, to tell a story with voice and images.

I think that these kinds of sites are just the tip of the iceberg. I think over the next few years, we’ll see stuff like real-time video chat built into social networking applications. We’ll see completely web-based VOIP clients trying to eat into skype’s business. And all kinds of other cool stuff. If I wasn’t working on slideshare right now, this would be the technology that I would focus on, because the gap between the potential and the current use is massive.

The first thing that we used Flash for was as an output format for our presentations.

The reason that we used it was that Flash has a lot of graphical capabilities that web standard technologies don’t.

One is that it is very easy to embed fonts using flash. An problem we faced with slideshare is that PowerPoint presentations can come in about a million different fonts. And people are really anal about their presentations: they want it to look exactly the way they uploaded it.

You can embed fonts using css, but on some browsers it causes security warnings. Flash lets you embed whatever font you want. So for user-generated multimedia like slideshows, Flash is a pretty good choice.

Vector graphics are another big plus point for flash. If you have a source of vector graphic data like maps or charts, then flash is absolutely the best way to display it.

Animation is something we’ll be adding to future versions of slideshare. A lot of powerpoint files have animation, and being able to replicate that will be really cool. But I’ve got a caveat here: I think that the animation capabilities of AJAX are perfectly fine for navigation-oriented animations like I was showing earlier. Flash animations should be used when there’s something that is truly a multimedia object, not as part of the user interface. For user interactions it’s too heavy, and it’s not necessary. Remember, our mantra is to only use Flash where we have to, NOT everywhere that we can.

Attention Control a really easy win!
This is the famous “yellow fade” technique. The concept is that when the user makes a change to the system, you briefly highlight the area where there change has been made. Since the entire page isn’t refreshing, if you don’t do this, the might think that nothing happened, or that their change wasn’t saved.

I’m on record as being really sceptical about this, and thinking that it was totally a fad. But the user testing we’ve done revealed a big positive reaction to this particular interaction style. People feel more oriented and confident, and they also like the fact that their action caused this mildly attractive visual event to happen on the screen. So the effect has both practical and emotional appeal.

One place where flash really ends up being necessary is in dealing with multimedia. By multimedia I mean audio and video.

The story about video is pretty clear now: two years ago nobody knew about Flash video. But that was before youtube went from being 3 guys in a garage to a multi-billion dollar buyout by google in 15 months.

At this point, it’s pretty much undisputed that Flash is the best way to display video in a web browser.

It also seems to be the best way to play audio in the browser.

One example of something that’s easy to do is expand in place. This is one of my favorite things about AJAX applications. Here’s a quick example from slideshare.

(go to slideview page: save to favorites)

This is how you save a slideshow as a favorite. As you can see, the widget starts out in read-only mode. You can see your data, but you can’t edit it directly. This keeps the interface nice and clean-looking, and doesn’t overwhelm the user with options.

A user interaction
(click on edit)
animates the opening of a widget in a section right where they clicked: so their attention is not being dragged back and forth across the screen. This should open up instantly: you don’t want to make the user wait while the html is fetched from the server for this. This was a mistake that we made: it should be fixed in a week or so!

After saving your data, the screen returns to it's original state.

Messaging to user: you can have a dialog with users to let them know about the state change. After they have seen the message, you can “clean it up” so the screen is back to normal.

There are a lot of cheap tricks that you can do with AJAX.

Many things that you can do that are really easy, but that will impress users and make your application more addictive. GoogleMaps caught everyone’s eye with the rocket science. But AJAX is only rocket science if you are building rockets. A lot of stuff is actually really simple.

We took an explicit approach with slideshare of focussing on dhtml magic when it was convenient.

Most of the javascript libraries that are available make simple dhtml magic very easy. We use scriptaculous and prototype for SlideShare, but a lot of other libraries, like dojo or mochikit or YUI also seem to do the same stuff.

Flash is _Not the norm for the web_.

The #1 rule of usability is “don’t surprise your users”. If your entire page is made in Flash, it will be obvious to your users. Lots of subtle and not-so-subtle things will be different.

For example, you can’t cut and paste text from UI.
You can’t set font size using the browser settings.
Form controls (like dropdowns, checkboxes, etc) all look slightly different (they look kind of raytraced and pimped out) and they work slightly differently.
Right Click does something completely different!

The biggest problem is that all these factors together make a Flash webapp evoke the metaphor of an application, rather than the metaphor of a page.

(to here, it is 6 minutes)

Another reason to not have your entire website be written in flash is that flash content isn’t indexed by search engines. Google doesn’t extract the text from Flash. So you can’t have your content be in flash if you’re building a site that you hope will be indexed by google.

Funny story … some of the first search traffic we got was actually people querying for error messages. Google was indexing the phrase “to see this slideshow, you need Flash player 7 or above”.

Initial load time
-Flash streams over the network less well than html does, and tends to be heavier than html is. It’s possible to make it light and to chop it into parts that download independently. But it’s tricky! So if the whole page is Flash, then users end up getting stuck looking at a preloader. This sucks.

Many of the advantages of Flash are feature-specific.
Accessing Flash via Javascript is no big deal

So obvious solution is : embed any nuggets of flash you need into an html harness.
-the “nuggets” of Flash download AFTER the html. Gives it a snappy feel. The _perceived_ initial load time is a lot less.
-Default assumption should be that most of the page is html, and most interactions are done with AJAX. Only use it where it’s needed.
Because …

My biggest learning has been that there’s a place for BOTH Flash and AJAX in most consumer web applications.

It’s a pretty simple and obvious idea. Developers should use the right tool for the right job. A carpenter doesn’t restrict herself to only using hammers. You have a hammer and a saw, and you use them for different things, and they are both in your toolbox.

Why do people always think we have to choose? Why do discussions about Flash and AJAX so often devolve into shouting matches?
I think that it’s because a lot of the time, when you’re making decisions about technology, you often DO have to choose. A lot of the time it’s really a choice between different types of hammers. So when people say “use the right tool for the right job” they mean don’t use a mallet when you need a sledgehammer.
You can’t run two different operating systems on one computer.
It’s silly to write a program using .Net AND J2EE
We’re used to being forced to choose.

But for code running inside the web browser, you absolutely don’t have to choose, and you’re shooting yourself in the foot if you get yourself into an “either-or” mentality. Flash and AJAX have totally different capibility, and work pretty well together. There is synergy betweeen the two technologies.

And the environment of the browser is really so impoverished in terms of it’s capabilities, relative to desktop or server environments, that you have to use every tool in the toolbox if you want to make something cool.

So your website should be 50% AJAX and 50% flash, right? Well not really…

Your milage may vary. My contraints are those of the consumer internet, and they color my perspective. In my world, it's worth it to make the UI really good, because the goal is to have a lot of users, and the users are the buyers (unlike with enterprise software, for example).

As a result, I care about the absolute potential of a UI technology, rather than what is easy to code, what kind of developers are easy to hire, or even conventional engineering constraints like code maintainability!

I'm a developer turned entrepreneur.

Both products my team has built (MindCanvas and SlideShare) couldn't have been built without using both Flash and Javascript.

With our first product (MindCanvas), significant chunks of code were written in Flash and had to be rewritten in JavaScript! So I've got strong opinions about where each technology should be used...

I'm here today to talk about a simple idea: the idea that in order to build kick-ass consumer web applications, we need to be able to use the capabilities of both AJAX and Flash.