Facebook applications originally provided something with very good potential, but unfortunately, it isn’t really working in the way I would hope it should.

Usefulness vs triviality

It is extremely unfortunate that majority of the Facebook applications that “succeeded” (currently) are entirely useless ones such as SuperPoke, X Me, SuperWall, and Top Friends. It is not hard to see how they succeeded.

Slide and RockYou apparently has some sort of partnership with Facebook (correct me if I’m wrong in this); they were able to push out some applications since day 1 of releasing the Facebook apps platform. They created these useless little apps, and made ways of spreading them (mainly the “Invite your friends” page when you first add the app).

Of course, now that everybody knows what that is, everybody just skips that page entirely. But when it first started, people actually invite other people through that.

Normally, an app getting popular, no matter what ways it used to accomplish that, isn’t really a problem. The main problem here lies in the fact that these apps are mostly useless trivial apps — look at SuperPoke, X Me, Free Gifts — they do nothing more than posting a message or an image on a friend’s profile. Top Friends has a little more to it than that, but also doesn’t have much practical uses other than generating hate from your other friends who didn’t get in your Top Friends list. (did anyone actually think of that when they add people to their top friends? I can’t believe how many people actually think Top Friends is cool. It destroys a lot more friendship than improving any.)

All of this gave a really bad example for new developers starting at this stuff. Other programmers see the success of these useless little apps, and they go ahead and make some too. It easily became the norm, then, to make trivial apps on Facebook. This in turn leads regular Facebook users to get used to the fact that Facebook apps aren’t to be taken seriously. It’s just fancy little toys to be added to your profile with no practical uses. Now, the only difference between Facebook Apps and the trash you see on MySpace is that Facebook Apps are more secure and more difficult to program for — other than that, there is no practical difference.

This is really, really sad because Facebook apps would have so much potential otherwise. Facebook could’ve pulled the a great part of web 2.0 applications into their platform if Slide and RockYou didn’t set such bad examples! The possibilities would’ve been endless.

Before Facebook Apps

Did you know that a Facebook development platform existed before Facebook released Facebook applications? You could develop third-party web applications (or even desktop applications!) using Facebook’s social network data to back you up. They would be standalone web sites, only having a Facebook login. All “Facebook Apps” did was to allow you to integrate your application into people’s profile boxes and provide you with a canvas page (which is mostly just an individual web site, for the most part).

Take a look at this: MoochSpot. It lets you “keep track of debts and shared expenses with your friends”. Excellent idea, nicely done using the Facebook platform.

And you know what? That is what Facebook applications should have been like in the first place! Useful web 2.0 web apps integrated into Facebook. NOT trivial little toys to add to the Facebook profile.

Another way to see it

Perhaps, though, Facebook could help us partly solve this problem by fixing their Applications directory. Help those of us developers who actually invest development time into creating a serious application with practical uses, and help the users find out about these things.

Categorize Facebook Apps into two big categories — little toys and serious apps. Or better yet, just call little toys something different altogether, like “profile add-ons” or something. That is where stuff like SuperPoke, Top Friends belong. Facebook Apps should be where stuff like MoochSpot and GoInGifts belong. (That second one, by the way, is what my team has been developing in the past month. The Facebook app, not the standalone web site — that is just a temporary placeholder designed by some web designer.)

Conclusion

Of course, Facebook Apps are still young to really say anything about it significant at all. There could very well be major changes coming up within the year that makes it into something entirely different, maybe working like what I mentioned above. Even the Facebook platform itself isn’t in a stable state yet — changes are being made from their engineering team every week, stuff is getting added, removed, and updated all the time. Let’s hope for the best and hope that Facebook will eventually solve all this out, and not to make it like another MySpace.

Years ago, web designers simply design web sites. They aren’t very different from traditional print designers. Sure, some of them might not only do the design, but also code up their designs in HTML. But a lot of times, web designers are only responsible for the visual designs, and they pass on their work to web developers to convert the visuals into actual web pages. Back then, there wasn’t even much of a term as “web application developer” — what is a web application in 1998? A form mail script? A guestbook? Nobody would do that for a living. Let’s rephrase that — you won’t make a living doing that.

Now we enter the web 2.0 boom. Full-fledged web applications are being developed. Meebo is my favorite example. And there’s Google Docs & Spreadsheets, etc. How are applications developed? By programming, obviously. Just like desktop applications, web applications also have a backend programming element to it, as well as a frontend interface programming element. These are huge applications we are talking about — they are as large as or even larger on scale than desktop applications in the past!

Web applications backend programming is really not much different from traditional programming people have been doing since the beginning of time. (except maybe working with different languages — like PHP, Ruby on Rails now. But people still use Java and C++ too!) When we get to frontend, things get a bit different. We have new technologies like DOM scripting and AJAX. These technologies are still in sort of an infant stage. It really takes a tech-savvy person to bend them at will and do what you need to do. Heck, even writing standard XHTML and CSS and making sure they work across browsers is a challenge!

Needless to say, frontend development work has to be done by programmers as well. Here’s where the problem comes in. As we all know very well, programmers aren’t good designers. What this translates into is a whole bunch of web applications with badly designed interface. You could hire a designer to make things look good, but if an application has a bad interface, that makes it a bad application.

It takes a usability expert and/or a great UI designer to do this frontend work. Very often, the frontend programmer is not this person. Currently, the only solution to fix this problem is to hire somebody who is both a great UI designer and a programmer to do the frontend work. It certainly is a big challenge! There aren’t that many of them out there.

And we come back to the question. Where do you draw the line between designer and developer? I am a web application developer. A lot of times, however, I find myself having to take care of some aspects of the frontend design. So should I be considered a designer in addition? The designer at my company needs to learn some web apps programming in order to improve on her work. She needs to understand how AJAX works, how the DOM elements on the page work, in order to make her designs work. So is she a developer now?

Frontend applications development is an interesting job. It takes both good design knowledge and technical knowledge to do the job — an unusual duo. Frontend developers should really be more valuable than backend programmers, since old-school programmers are a dime a dozen. Why aren’t we getting paid more?

It started from a time when one of my clients was using (are you ready for this) Firefox 1.0. If you are one of the unlucky souls who don’t understand the meaning of this — Firefox 1.5 had been the “standard” Firefox for about a year or more, and Firefox 2.0 has been out for at least a month or two (or more; and I’m not even the type who keeps myself that updated). He told me that the page didn’t look right and he was using Firefox, so I wondered for a while before finding out that he was on Firefox 1.0.

So I figured there is actually a need to install multiple versions of Firefox for testing. Surprise! There are actually ways to install multiple versions of Firefox as well as IE on your computer, without having multiple computers or doing any sorts of virtualization. Oh, and this guide is for Windows users. If you’re doing any sort of frontend design, Windows testing is your main target, no matter how much you like Mac or Linux yourself.

Installing Multiple Versions of Firefox

I will try to make this your one-stop guide to doing this, so I will include every link you’ll need here. First of all, to give credit where it deserves, I first got my information from dojotoolkit.org.

If you attempt to simply install all 3 versions of Firefox separately and run them normally, you will always only open the latest version you have installed, no matter which executable you run. By following these steps below, you can run Firefoxes 1.0, 1.5 and 2.0 side-by-side.

1. First, to get old versions of Firefox, you should go to this oldversion.com link. Firefox versions older than 1.5 are not available on the official web site, so you will have to get 1.0 on third party archive sites. I recommend 1.0.7, that’s the one with the “latest” bug fixes from the 1.0 series. Note: As far as I know, rendering engines have no differences between subversions of 1.0 (or that of 1.5, or 2.0). So you only need to get the latest 1.0.
2. As for Firefox 1.5, at the time of this writing, it is still available on the official Firefox site. I recommend getting it from there, since they have the latest 1.5.0.12, versus the 1.5.0.7 on oldversion.com.
3. Run the installations for Firefox 1.5 and Firefox 1.0. Do not install them at C:\Program Files\Mozilla Firefox. Instead, rename the installation folder to Mozilla Firefox 1.5 (and 1.0). At the end of the installations, when asked if you want to launch the program, click No.
4. Go to the two respective installation folders, and rename the firefox.exe file in there to firefox1.5.exe and firefox1.0.exe correspondingly. This is not a required step, but I recommend it because you’ll able to tell their differences in Task Manager.
5. Then you need to create a .bat file for both of these versions. Make a new file called firefox1.5.bat (and firefox1.0.bat for the second one), and paste these lines in it. Of course, for the 1.0 version, change all the “1.5″ occurrences below to “1.0″.

   set MOZ_NO_REMOTE=1
   start "Firefox" "C:\\Program Files\\Mozilla Firefox 1.5\\firefox1.5.exe" -P "Firefox1.5"
   set MOZ_NO_REMOTE=0

6. Run the .bat file. The first time you run it, Profile Manager will come up and ask you which profile to run with. Create a new profile with the respective name (”Firefox1.5″ for version 1.5, and “Firefox1.0″ for version 1.0, as it shows in the .bat file lines above).
7. When Firefox runs, you will have all new bookmarks and everything, and the About window tells you that you are on the right version. By using the .bat file, you can run all versions of Firefox at the same time. After running for the first time, you will not get the Profile Manager that asks you for profile anymore.
8. Lastly, I recommend creating a .bat file even for your latest (2.0) Firefox, for maximum clarification. Use the same file content shown above, but take out the “1.5″ occurrences. For the profile name, use -P “default” instead.

That’s it!

Installing Multiple Versions of IE

Doing this with IE is way simpler than with the Firefoxes, thanks to some kind folks who developed a program called MultipleIE.

1. Install IE7. Yes, you may feel free to overwrite your IE6. You will get it back later, so don’t worry about it.
2. Go to Tredosoft and download the Multiple IE software. Follow all instructions on the web site and on the setup program.
3. You’re done. Did you expect more steps?

Simple enough?

Conclusion

Now, you have on your Windows PC Firefox 1.0, Firefox 1.5, Firefox 2.0 as well as IE versions from 3.0 to 7.0. As a good web developer (especially a frontend one), you should be testing for as many browsers as possible and make your code work for as many of them as you can. Safari and Opera are other browsers you should consider supporting. (You no longer need a Mac to test for Safari! )

There is also Camino, but it uses the same rendering engine as Firefox, so you can assume your site will work with it as long as it works with Firefox. As a bit more information: Safari and Opera use their own rendering engines which are different from Firefox. However, both follow web standards (defined by the W3C) pretty well, so most of the time you won’t get too frustrated with them. Internet Explorer is really the only one that likes to stray away from standards (even now in IE7), but it’s also the most commonly-used one. What can you do, right?

This is strictly an application-design topic. I’m not introducing any new fancy functions or features in PHP. It’s about how you design your web app, for better usability. (I happen to be pretty serious about web app usability, which, IMO, all software developers should be, for any software they are working on. This is why so many of my articles focus on what you could do to improve usability — it’s something too many programmers neglect.)

The history of HTTP’s POST and GET requests

I’m sure almost anyone who does web development know what POST and GET requests are. GET requests include form parameters in the query string of the request; they can get cached; they can be sent to a friend through email/IM, and so on. POST requests send parameters as part of the header in the request, and are not visible. However, when you come down to the basic technical operations, they work almost the same way: you can do just about anything you could in either method in the other one as well. (multi-part form data are a bit harder on GET, but it could be do-able)

The most important difference, actually, lies in the definitions — when these HTTP requests were first invented. A POST request is defined to be a request to the server that changes the state of the server. This means, for example, posting a message on a forum, uploading a file, or anything at all that changes (inserts/deletes/updates) the database, the file system, or anything else. A GET request, on the other hand, is defined as a way to retrieve information from the server without making any changes, or a “query” as they call it.

Why does it all matter?

Knowing the history of POST and GET requests, you should also be aware that browsers like Firefox and IE are designed with this in mind. When you attempt to Refresh a page (or going Back/Forward to it) that you got from POSTing a form, you get a warning box telling you that POST data will be sent again to the server. This is because a POST request is expected to make a change, and repeating the same request just to view the resulting page is usually not what the users intend to do, or what the developers intend for the users to do.

Unfortunately, on the users point-of-view, this creates a very user-unfriendly situation when web apps aren’t designed with this in mind. The average internet user does not know the difference between POST and GET requests (many won’t even be able to tell what an HTML form is), but web developers assume people know what they are doing. Your job, as a web developer, is to make it as less painful as an experience for web users as possible. Back and Forward buttons are the most commonly used features by web users, and you want to design something that works with them, not against them. This is why I’m an advocate of separating POST and GET requests in PHP.

What do you mean by separating POST and GET requests?

It might not be the best way to phrase it. What I mean is to make only GET requests display anything at all, and POST requests results should always redirect to another page in the form of a GET request. In other words, POST requests always only get sent to “Controller” scripts, while GET requests always only get sent to “View” scripts.

To make this easier to understand, I will take the example of a project I have done a few years ago, designed in this method. It is a web-based file manager that lets you upload, delete, rename, move files as well as folders.

No AJAX was used in this application (it wasn’t popular in 2003). All actions are sent as a new POST request to a PHP script on the server. However, there really is only one script file for the “view”, called main.php. A handful of other PHP scripts handle all the different actions. When you upload a file, a request is sent to upload.php, and this script will redirect back to main.php in the end, using a Location header.

To handle error messages (or success messages), I use cookies. Back to the uploading example again — before redirecting to main.php, I set a cookie with the status and message. In main.php, if a cookie is found with this information, a dialogue box displays with the message, and then the cookie gets cleared.

Designed this way, Back and Forward buttons may be used freely without actually corrupting the state of the server. It is true that, for example, if a page was cached, hitting Back may lead you to an old page — but at least the POST request wouldn’t be sent again (as POST is what makes changes to the server). Most of the time, implementing some sort of cache-stopping mechanism can stop this from happening. In my file manager example, even dialogue boxes work correctly (would not re-display after showing once), due to the use of cookies.

Some final notes

If you are interested in some additional reading, you can look at the official HTTP/1.1 method definitions. An interesting part of it is this:

The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.

If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header (see section 14.30).

It looks like that you should be returning a status code of 201 if you are going to redirect to another page using a GET request, after doing your processing in your POST request. I’m actually not entirely sure what benefits do you get from doing that other than being politically correct about definitions. If anyone knows the answer to this, feel free to post a reply and enlighten me.

They are easy to explain, but sometimes the concept is a little abstract and it’s hard to grasp for someone who doesn’t know what MVC is to begin with. To be honest, all my years in web development I never really understood exactly what MVC is, until recently when I started doing development in Ruby on Rails. In this article, I hope to explain MVC architecture development in PHP terms, so the average web apps programmer may benefit from understanding this powerful architecture.

MVC and PHP development

The reason I mentioned Ruby on Rails is because you really have to understand how to develop an application with the MVC architecture to do anything at all on RoR. (Next time, I will write another article on RoR — but this time, I’ll talk about PHP development.)

The Model-View-Controller separation actually makes a lot of sense, it is actually natural for a developer to divide his/her code that way when working on a reasonably large application. Java has classes, JSP and struts; Ruby on Rails has a built-in MVC structure; but even when PHP doesn’t have anything like that, it doesn’t mean you can’t do it.

The Model

The MVC structure is meant for reasonably-sized applications, using object-oriented coding. The Model part, in a PHP app, would usually be a class (or multiple classes). Fairly often, the class is a representation of a table you store in the database — member variables are the data columns, and member methods are operations that can be done. As an example, you might have a User class, having variables such as username, password, email address, and other things. Some of its methods might be a new user creation function, a login function, an authentication function, and a logout function.

Later on, we will see how User objects will be used in the Controller part of your application. The Model, in essence, tells you what methods are available — what can you do to the data in the database. I thought I should just clarify (if it wasn’t clear already) — this should be all PHP code, just as what you should do in OO-programming even without MVC. There should be no HTML or any kinds of outputs (redirection, etc.) here. If doing an action means that a redirection is needed or some output is needed, pass it as an argument or a return value. (It’s fairly basic programming practices, but you’d be surprised how many web apps programmers didn’t graduate with a CS degree..)

Here’s an example of the Model part of your code. Of course, there will be many more classes in a real application. This is just the code is the simplest form, without a lot of the details.

class User
{
   var $username;
   var $password;
   var $email;
   function User($u, $p, $e) // constructor
   {
      $this->username = $u;
      $this->password = $p;
      $this->email = $e;
   }
   function create()
   {
      // creates user in the db
   }
   function login()
   {
      // checks against db, does login procedures
   }
   static function authenticate($u, $p)
   {
      // checks against db
   }
   function logout()
   {
      // does logout procedures
   }
}

The View

The View, in the simplest words, is the user interface. However, it doesn’t mean it would be just straight HTML. Minimal PHP logic will need to be used in your application’s interface a lot of times. For example, if you were to have the main logged-in page say, “Hello, [username]!” You would certainly need some PHP code to handle that, right? That is all part of the View. Of course, all the CSS, Javascript would be part of this too.

It is important that whatever PHP code in here is only what needs to be used to display the interface correctly. No additional “action” code belongs to the View — that is the Controller’s job, which we’ll see next.

This was easy to understand, but for clarification’s sake, let’s see an example anyway. Of course, the following isn’t even valid XHTML 1.0 (it lacks a DOCTYPE, for instance), but this is just an example.

<?php
require_once('User.php');
// makes sure user isn't already logged in
if (User::authenticate($_COOKIE['username'], $_COOKIE['password']))
{
   header(”Location:/main.php”);
   exit();
}
?>
<html>
<head><title>Please login</title></head>
<body>
<h1>Login</h1>
<?
if ($_GET['error'] == 1)
{
   echo ‘Login incorrect. Please try again.<br />’;
}
?>
<form action=”login_action.php” method=”post”>
User: <input type=”text” name=”username” /><br />
Pass: <input type=”password” name=”password” /><br />
<input type=”submit” value=”Login” />
</form>
</body>
</html>

The Controller

Sometimes it is confusing to understand what the Controller needs to do, if you weren’t working on an actual application and just reading a book/an article. It would seem like the Model and the View are all you need. So let’s go back to a concrete PHP example.

Now imagine you have a login page setup. The login HTML form has to submit to somewhere, right? (Even if you’re using AJAX) You don’t submit directly to the Model class file (say, User.php), because that file only contains the class code, and no actual procedural code is there, so it won’t do anything. You certainly don’t submit directly back to the View file (say, login.php), even if it ends with a .php extension! Because its job is only to display the interface.

This is what the Controller is. Your form will submit to a file, say, login_action.php. In this file, you create an instance of the User class, running whatever initialization you need, and calling the appropriate methods that need to be run (login).

Some developers fall into the temptation to display outputs from the Controller, because it’s convenient. Imagine, if you had a login form, how easy is it to just print “Login incorrect” directly from the Controller PHP code? (assuming you aren’t using AJAX, for this particular example) It is an option, and I will tell you that many scripts do just that. However, to truly utilize a MVC structure’s advantage, the Controller (like the Model) should not display any HTML outputs, but rather use redirection. You may use cookies/sessions, database storage, flat file caching, or query string to the View file to store the states of your application; and then you should always let the View take care of displaying outputs, using these stored states.

Now let’s see an example of a Controller code.

<?php
require_once('User.php');
// in reality, a lot more error checking needs to be done.
$currentuser = new User($_POST['username'], $_POST['password'], ”);
if ($currentuser->login())
{
   // set cookies for login info
   header(”Location:/main.php”);
   exit();
}
else
{
   header(”Location:/login.php?error=1″);
   exit();
}
?>

Conclusion

Using the MVC structure, code becomes a lot easier to understand. For other developers to join in to understand your code, as well as for yourself in the future when you come back to it after a while. Development is also a lot easier because you know exactly where to look for what piece of code. If you were going to change some message displaying in the interface, you only need to go to the View. If your database structure sees a change, such as passwords now encrypting in a different way, you only need to change your Model. The MVC architecture is very powerful and makes your object-oriented web apps development a lot more efficient.

Next-gen web applications really need innovation. If there is one thing I hate about the world wide web and web technologies, it’s bandwagon-jumpers who only learn the surface of things. There are more than enough web developers (or so-called developers) who only learn the latest tricks and start abusing them. JavaScript tricks and Flash were such things back then.

With AJAX and DOM scripting, you get those guys too. There are plenty of “Web 2.0″ companies/web sites out there, and many are simply unnecessary and useless. With small web sites, you can afford to simply ignore their existences. Unfortunately, such lack of innovation also exists in large corporations.

I really hate to say it, but to give you an idea of what I mean: Yahoo falls under this category, especially in comparison with Google.

First of all, I just want to say that I like Yahoo as a company. Yahoo Games are some wonderful stuff that no other sites can replace even today. As for other services like Mail, Maps, and other things, I appreciate their effort to make them better every day.

Let’s look at Yahoo Mail now. And for comparison’s sake, we’ll also be looking at Google’s Gmail. If you still don’t know what Yahoo Mail is like today (you probably don’t use it then?), here’s a screenshot:

(Click to enlarge picture)

Looks familiar? That’s right, because it is familiar. That’s just like Outlook/Outlook Express! It is a great design, and it looks very pretty, I’ll give you that. If you were shown this UI 5 years ago, you would even think this is a desktop application and wouldn’t believe it if I told you it was web-based. It’s basically Outlook Express, with ads.

There is only one thing it lacks — innovation. You can argue that from a usability point-of-view, this is a good design because it brings familiarity. Users tend to use their old knowledge to judge a new interface they come across. Being able to bring the desktop application experience entirely to a web application is a good thing. However, is that really all you can do? There are certainly more. So let’s look at how Google takes its approach at emails.

First, I should tell you (if you don’t already know) that Gmail came out way before Yahoo Mail released their new AJAX interface — so you can’t say that Gmail is better because it came late. Now, let’s look at a screenshot:

(Click to enlarge picture)

Gmail chose not to “duplicate” an all-too-familiar desktop email program look-and-feel. Instead, they just sticked with a regular web-based email design. However, a few things distinguish Gmail from the rest of the world’s email services.

1. Threaded conversation. It’s one of those things where you say, “Why was email never done this way before?” or “How could I ever live without that before?” Just like Apple says — the best design is one that goes unnoticed in users. It’s something that should be that way. Apple’s done it with iPhone and voicemails. (Why did nobody think of checking voicemails with a GUI and choosing which one to listen to? Why would you have to listen to the first 5 messages from friends before you get to the most important one from your boss?)

Why are there still no other email services that do it this way, after Gmail has done it for so long? If you have ever planned trips with friends, using Reply-All on every response, and getting people’s replies on the subject and leading to 100-message threads, you will not want anything but Gmail.

This wasn’t even something that would require the use of AJAX and DOM scripting. Using them just made it all a lot smoother. It’s just a general new idea, and Google was the one who made it.

2. Labels and searching. Personally, I don’t use labels as much as I should. Labels are better than folders in all kinds of ways, but I have to admit that many users just don’t “get it” — they don’t see how it can be used in place of folders. As for searching, it’s Google’s thing. You really can’t beat Google at searching, and they incorporated it into email, so I don’t have much to say about that.

3. Instant messaging within email. Yahoo has finally incorporated it now too (yeah, finally). As we all know, though, it’s coming up with the idea that is the hardest. It’s only half the work if you just say, “Hey, those guys did that. Let’s make that in our product too.”

All the same thing can be said with Google Maps. Interactive dragging, zooming were all done at Google first. Why did Mapquest, Yahoo Maps, etc. not think of them before? They have been in the mapping business for so much longer. Everybody switched over to Google Maps once it was released. Why? Innovation.

Conclusion

True, it would be unreasonable to require everyone to be innovated geniuses. And Google is certainly not the only one who has made good stuff from technology. Meebo has done something incredible, and so has many other companies. (By the way, I have read an article before saying how Meebo is what’s wrong with today’s web technologies. I happen to disagree with it, but that’s topic for another day.) If you don’t try, you’ll never succeed, right?

You’ve surely heard of the term “Web 2.0″. However, not everybody seems to have the same definition for Web 2.0 — especially when it was just conceptualized. As time progresses, people have gotten more educated. Still, there seems to be many common misconceptions. Let’s look at them…

Web developers, especially front-end interface developers, often feel that any web applications/web sites that uses AJAX and DOM scripting would be considered Web 2.0. This was particularly true a year or two ago when the term Web 2.0 first became popular in the public. It has a lot to do with the fact that around that timeframe, Google came out with Google Maps and Gmail, both of which implemented a very interactive interface never seen before in other mapping and email services; and they were called Web 2.0. Yes, I was part of the group that fell for this — before I read more about it, I was convinced that Web 2.0 meant this.

Web site producers (for the lack of a better term; it means people in charge of creating web sites but not the ones doing the technical work) and businesses consider user-based web sites and community-focused networks to be Web 2.0. They consider the earliest instances of Web 2.0 companies to be sites like Amazon (among some others as well), where content is fed to you based on information gathered from others. Wikipedia (user-contributed content) and Friendster (all the social networking sites) are then also considered to be Web 2.0, even though at that time they did not have anything like an AJAX interface.

So why was Google Maps considered to be Web 2.0? From the surface, we see that the most revolutionary thing about Google Maps was the interface, as the interactive dragging and zooming were never seen before at that time. (MSN later on came out with Windows Live Local, soon to be followed by Yahoo Maps and MapQuest as well who also updated their interface to something similar.)

However, Google integrated their normal search to Google Maps, effectively creating a “mashup”. You can go to any area on the map, and run a search for any businesses, or even a generic search. Searching for “pizza” in San Francisco will yield results of where you can buy pizza. Searching for “Star Bucks” in the city can tell you all the store locations of Star Bucks. In addition to this, the Google Maps API let other users make custom applications based on Google Maps. Trulia is an excellent (and also one of the earliest) example of that.

Pulling information from various sources, creating a mashup and producing a useful application, define it as a Web 2.0 site.

Emil at friendlybit.com wrote a really good article about the definition of Web 2.0. It basically means that it takes a combination of these things to be considered Web 2.0.

So, “Next-gen Web App”?

What do I mean by “Next-gen Web App” now? In short, any web applications that make use of an AJAX and DOM scripting interface is a next-gen web app.

Not every web application can take advantage of information mashup and community-focusing. There are applications that are made possible with AJAX and DOM scripting but do not qualify as Web 2.0 because of the above definitions, and I feel that they deserve a special name (for now at least — before they become commonplace). It’s something that wasn’t possible before xmlHttpRequest and DOM scripting were invented, and it’s revolutionary.

With the power of these two things, software that could only be desktop applications in the past are suddenly possible to make as web applications. Google Docs & Spreadsheets is a good example. DOM scripting provides a way for developers to do almost any kind of manipulation on elements on a web page displayed by a browser. AJAX provides a way to connect to the server for any processing work needed at any time, without interfering with the interface (with page reloads). Comet lets you do the opposite — allowing the server to talk to the client when an update is necessary. The entire Office suite is now possible as a web application.

The possibilities are endless because now, almost anything that could be done as a desktop application, can also be done as a web application. Meebo implements an IM software as a web app. Some companies are bringing internal applications to web apps. Now, installations, updates, and patches on mass machines are no longer necessary. Simply point your browser to an intranet page to run these apps, they will be the latest and greatest. And thanks to the speed of LAN, these apps run as smooth as if they were a desktop app.

As the average home user’s internet speed becomes faster and faster, any performance issues due to connection speed will be gone. W3C, along with browser makers like Microsoft, Mozilla and Apple, will be working together to create a stronger implementation of AJAX capabilities (something more robust and defined than relying on just xmlHttpRequest). In the near future, web apps can replace many traditional desktop apps. In my opinion, this is a huge leap in technology; and calling it the “Next-Gen Web App” isn’t too much of an overhype.

Web applications engineers are hot in the coming few years!