Where is the Real Ajax/Flex Revolution Happening? 89
andzik writes "Even with all of the buzz around Rich Internet Applications these days, using toolsets like Ajax and Flex, most sites that utilize these technologies seem to be incremental improvements, not revolutionary interface changes. Where does the Slashdot community feel the best opportunities are to substantially create different/better user experiences using RIA tools? What will be the killer app? Are we just not seeing them because the best improvements are being made to web based applications and not in the public space?"
On a related note, Vertigo asks: "Not so long ago everybody believed that it was a good thing to have the freedom to modify your software to suit your needs or to mangle your data in any way. But now that users are flocking to non-modifiable, one-size-fits-all web 2.0 apps like Gmail or Flickr, are we moving away from our open source ideals? Those services do provide many important benefits, but in the process of their enthusiastic adoption did we not loose sight of the most important issues?"
it's the cloud! (Score:5, Interesting)
One key question in this Ask is
Just my opinion, but I think the killer app may be out there already but in stealth form. It's mostly a question of discovery and trust, and I think both lurk right around the corner.
Just my anecdotal internet experience, but I'm migrating virtually all of my work into cyberspace and allowing internet services to manage my data and backup. I'm not completely there yet, but I've been a heavy gmail user for over a year now, and have almost forgotten how to use local pop clients (though I still do for peace of mind pop/download the e-mails for local storage -- I haven't gotten that far with my trust). And the sheer convenience of being able to "do e-mail" from any browser has been more beneficial than I'd predicted. I now have complete threads at my disposal whereas I used to find myself re-constructing threads dispersed across multiple machines (typically laptops "on the road").
Lately I've tried some of the on-line word processors and calendars, and yes even some of the spreadsheets (some of the on-line spreadsheets are very responsive and offer functionality 99% of excel users typically tap). They're not all there and ready for prime time yet, but they're getting close.
The word processors for my general use are already good enough that I'm willing to do my word processing on line and let "them" do the management. I wouldn't even consider (not that I did anyway -- I'm an OpenOffice user) any of the pricey Microsoft Word Processing/Spreadsheet options. Again, the side benefit, almost unexpected, is the universal access to my work with NO effort, just a reasonably current browser.
So, from my perspective, that's the "killer app"...: the security; the ease-of-use; the convenience; the cost; the true benefits reaped from a net where your data is created and managed in the internet "cloud" (sorry about all of the "quotes").
(As for the one-size-fits-all, I think the eventual internet app winners will be those who provide the functionality with the flexibility. And if you shop around you'll find these on-line versions seem to providing reasonable (maybe not complete, but reasonable) flexibility)
What about printing? (Score:1)
One of the things I see holding back all these web-based applications is printing...how do you format envelopes and labels, insert page breaks and format pages etc. when you are at the mercy of the printing capabilities of the user's browser? Online is great but sometimes you just want a hard copy.
Re:What about printing? (Score:2)
Flex gives you a good deal of control over printed output.
A smattering of the API provided: http://livedocs.macromedia.com/labs/1/flex/langre
Re:What about printing? (Score:2)
But in a nutshell, what's flex?
Is it like.. flash or something?
Re:What about printing? (Score:2)
Re:What about printing? (Score:1)
PDF! (Score:2)
Re:it's the cloud! (Score:1)
untapped market (Score:3, Insightful)
Re:untapped market (Score:3, Interesting)
Web apps non-modifiable? (Score:2)
Since when? Web applications are built on a foundation of HTML, which is simply a way of marking up information. How user-agents interpret that information is up to them. UserJS/Greasemonkey can modify web applications on the fly too. It's a bit of a stretch to claim that web applications aren't modifiable.
Re:Web apps non-modifiable? (Score:4, Interesting)
Web apps non-modifiable?
The source code that generated that HTML might not be modifiable. The php scripts of a GPL'd website can be modified by someone else and not have to redistribute the source because they aren't distributing the modified source. they have it sitting on some server somewhere not copying itself. Most web-apps don't even release their source code.. see digg.com, del.icio.us, gmail, etc. That's why there are open source equivalents of these.. respectively: pligg [pligg.com], scuttle [scuttle.org], and the Hula Project [hula-project.org]
Brett Smith of the FSF just email me today to notify me of the Affero General Public License [affero.org], which requires the source code of the site to be available to anyone who receives content generated by the site.
And the problem is? (Score:5, Insightful)
I like the idea of AJAX being used to enhance applications, not completely rebuild them.
If I wanted to do something like change the menus/site navigation I could already hose up the browser's controls with a flash based site.
If i want to do a quick validation in a form against a remote database, I'll use AJAX
If I want to add a quick way to change a record(ex. disable a user) in a table, I'll add a link that makes an AJAX call.
If I want a text box to do a spellcheck without posting a complete form, I'll use AJAX
Re:And the problem is? (Score:2)
That's another good one(as long as you're sure AJAX is supported). You remeber what it was like before that? You had to either cache a huge javascript array, or do a page refresh on the change.
But do not use it to replace the normal HTML request/response page-to-page flow.
I agree with you 100% here.
Luckily I haven't seen too much of this yet, though I have heard plenty of "AJAX breaks the back button" FUD sprea
Re:And the problem is? (Score:3, Interesting)
For a major web-based intranet app I helped support, dealing with the Back button was a *MAJOR* headache (J2EE session objects, etc). So having something that makes the Back button do nothing is bad? No, I think a lot of developers would say it's probably a good thing...
Re:And the problem is? (Score:2)
Re:And the problem is? (Score:3, Insightful)
Re:And the problem is? (Score:2)
I've developed a lot of data management web applications over the years (primarily training services management of one type or another). Remember, DB apps really are the bread and butter of computer software.
They tend to use technically simple, menu-based interfaces, because they make logical sense to the users.
There are definitely places where the back button isn't the most useful thing (like after you've just added a new database record) but, most of the time, the back button is entirely sensib
Re:And the problem is? (Score:3, Insightful)
Re:And the problem is? (Score:1)
Yup, GETs to change data. Good thinking. No one's already run into that problem en masse and pushed emphatically for that not to be the way to do things. Oh, crap, except for the whole Google Web Accelerator fiasco.
Re:And the problem is? (Score:2)
Wrong.
Google's Web Accelerator won't handle a link that does a javascript:void(0) and calls a function to create an xmlhttprequest with an onclick event.
Google only precaches valid href elements on anchors, it won't parse javascript for you. There is nothing fundamentally wrong with doing an
Re:And the problem is? (Score:2)
If a browser or proxy server is ignoring those, it is broken.
Re:And the problem is? (Score:1)
http://www.w3.org/2001/tag/doc/whenToUseGet.html [w3.org]
From the site...
1.3 Quick Checklist for Choosing HTTP GET or POST
* Use GET if:
o The interaction is more like a question (i.e., it
Re:And the problem is? (Score:1)
Wait (Score:1, Flamebait)
Re:Wait (Score:2)
Excuse me? (Score:2, Informative)
JavaScript is flexible, simple, and already has the features needed for web development (like DOM).
C is NOT the answer to everything.
Re:Excuse me? (Score:1)
true. now tell me a problem javascript is *the* solution for.
Re:Excuse me? (Score:1)
Maybe so. How about using C to write internet apps, and ditch the web?
http://www.newio.org/ [newio.org]
Re:Wait (Score:2)
How about ECMAScript4?
You can have that now (in the form of ActionScript 3, Adobe's confusingly-named implementation) with Flex.
(Overview at http://labs.macromedia.com/wiki/index.php/ActionS
Re:Wait (Score:1)
Hate to sound like a luddite but... (Score:1, Insightful)
BTW: Flex is a popular lexer based on Yacc and not some web2 buzzword.
I don't think you sound like a luddite. (Score:2, Insightful)
I see some really nice web designs out there, but when it takes a minute (or more!) to load a page with a DSL line, then I get a little testy. And many times, I absolutely agree with you. I just want the information, the graphics/Flash/whatever do not add anything. And many times, it makes site navigation difficult because the page becomes so cluttered, it's hard to make out what you're looking for.
Re:Hate to sound like a luddite but... (Score:1, Insightful)
So says the guy that just used a form to post to slashdot.
Re:Hate to sound like a luddite but... (Score:2)
Used properly, Javascript and Asynchronous JavaScript can improve the user experience.
Don't use javascript-only validation (Score:4, Insightful)
Using asynchronous javascript to send the data to the server and get the response is a way of saving time by drawing less of the page. But you still need to server-validate.
Re:Don't use javascript-only validation (Score:2)
Re:Don't use javascript-only validation (Score:2)
After that, I follow-up with a "Contact Us" email about their website being broken. I've had some success in getting people to fix the problem. I usually recommend they do the same thing with email addresses as passwords -- have users type it twice. Sl
Re:Hate to sound like a luddite but... (Score:1)
Re:Hate to sound like a luddite but... (Score:5, Insightful)
I don't think I ever experience the internet before all this was possible. The internet very quickly became a way of manipulating data as well as just reading it. It was just done in a very crude way using CGI programs. AJAX is just the next step allowing us to make the process of updating and manipulating data much more transparent to the user. It allows us to converge things that used to be done by external applications into a single application, the web browser. This is a good thing. You no longer have to download Yet Another Application just to remotely manage Yet Another Data Set. Gmail and Google Talk are perfect examples of this. I can chat to my friends without having to install yet another IM application. It's all done through the web browser.
Granted that at the moment AJAX is currently undergoing it's overhyped bubble effect, but once it bursts and settles down to a more reasonable level I can guarantee you that you will probably be using it without even realising it. Just as you are currently using current web applications without even realising it.
Re:Hate to sound like a luddite but... (Score:2)
All AJAX uses is javascript, a bit of xml, the http protocol, and a CGI script. Nothing more. So yes, google talk can use http. If you log into gmail you have the option to chat to your google talk contacts through the web browser. It's a new feature, so you may not
Re:Hate to sound like a luddite but... (Score:3, Insightful)
Well, yeah, by definition. But that's like saying "computers are good for calculating projectile motion, they have no business being communication devices"... it's a robust technology with multiple uses.
Flex is a popular lexer based on Yacc and not some web2 buzzword
I presume you're being deliberately obtuse here, but just in case, let me help you out: Adobe Flex 2.0 [macromedia.com]
Re:Hate to sound like a luddite but... (Score:1)
Hear Hear! (Score:1)
For instances where you really can't run an executable on the client, and all you have is the browser, it's obviously the only solution. I think these situations are the minority, however, and users can be much better served by
You lost me. (Score:2, Interesting)
What users are you talking about? Those who use OSS or your typical Internet user?
Bare in mind that the internet, aside from the technical sites, has become a huge b
Killer app (Score:3, Funny)
The killer app is one that automatically fixes "lose" misspellings?
"we not loose sight?" (Score:2)
Re:"we not loose sight?" (Score:2)
User privacy.
User control over upgrades/downgrades/UI changes.
Ability to switch applications while preserving data.
etc.
Some Apps kill allready (Score:1)
Re:Not here... (Score:2)
The controls do all the work server side sherlock. We did extensive testing to make sure it works properly on a variety of browsers including Firefox, Netscape, IE and foreign language browsers. Ironically in this case, our application works seemlessly with alot of browsers that don't even support xmlhttprequest calls or support them through hacks (IE 6 and below activex objects???).
Re:Not here... (Score:2)
Semi OT: OpenLaszlo (Score:5, Informative)
I think the original point to my post was that AJAX is nice but I don't think that the standards are there yet.
Re:Semi OT: OpenLaszlo (Score:2)
First, you're not really building your application in flash. You're building it in (mostly) xml and Laszlo is currently compiling into Flash 6/7/8. They explicitly say that they designed it so that if someone else comes along that's as-good/better that they'll try to support that as well. It's just that flash really has few RIA competitors, so they're using it now.
Seco
Re:Semi OT: OpenLaszlo (Score:2)
Re:Semi OT: OpenLaszlo (Score:1)
And we're demoing a pre-alpha DHTML runtime now:
labs.openlaszlo.org [openlaszlo.org]
(I work for Laszlo Systems.)
Forum software (Score:2)
VBulletin also uses AJAX in its latest version, specially when you edit a typo in one of your posts.
But I think the real revolution will happen in intranet apps, where there are TONS and TONS and TONS of forms!
Forms software (Score:1)
A lot of things will change when anyone can start making and using business quality electronic forms the same way they use word processing and e-mail today. All you'll need for taxes is this year's ODF/XForm. 80% of "business app" software will go away. Standards committees like HL7 and X12 will become un-necessary.
We're getting closer. (see: freebxml.org, PDF, OpenOffice, XForms, Mozilla) It just isn't quite there yet. Who knows, some revolutionary forms client may use asy
I almost want to... (Score:2)
It is sort of a picture trading site, I suppose you could say. Free users get credit for uploading pictures, and for using a webapp to enter metadata about those already uploaded. All pictures thusly cataloged are searchable (and no, it isn't just tags). Wish I could show some of the applets, but they're not really SFW.
Standardisation is the killer app (Score:4, Informative)
AJAX is a transition point in the web's evolution beyond the browser. The real killer app is what happens when these applications' communication protocols standardise. It's not so long ago that when you wanted to run a blog, you either hand-coded HTML or had to have a server running slashcode. Now you can choose between dozens of free and non-free web apps or hosted services, and it doesn't really matter which you choose because your audience can aggregate from any of these via RSS, and view your content in whatever client they choose. I'm sure Blogger.com is still a viable business, but it's increasingly irrelevant.
Similarly, it's rapidly becoming possible to share calendaring information with others via CalDAV without caring which client and server options you and your collaborators prefer.
Whenever I do a Drupal site for an organisation I like to encourage them to set up an LDAP directory, so that they can use the same authoritative data source for authenticating to Drupal and other systems, internal address books (usable from a multitude of clients), and finely-grained control over sharing personnel data with affilliated organisations. The ability to do all this is very cool, and not at all dependant on my choice of OpenLDAP (which is, frankly, a bastard to get working), as the critical element is the LDAP open standards.
These are pretty simple examples, but I don't think it's too much to expect that open standards for interacting with applications like Flikr and Del.icio.us will emerge, along with increased choice over back-ends and interfaces and effective commoditisation of the services. Value moves up the chain, innovators move on to the next big thing, and it all starts over again.
At least that's how it should work.
Matthew.
Re:Standardisation is the killer app (Score:2)
However
I'm sure Blogger.com is still a viable business, but it's increasingly irrelevant.
Consider the "side effects" of such a business, for google. With the increasing services Google has been playing with, tying a better Blogger into it could be a very nice step forward. If, for example, blog entries and comments are immediately available in Google search results, they may have something of value to both searchers and advertisers, as well as authors. For e
We just started with Ajax on our Intranet... (Score:2, Interesting)
To answer your question (Score:2)
Perhaps there needs to be a distinction between "we"s here. We, as in the open source believers/advocates/etc, may indeed be partially giving away our open source freedoms in exchange for convenience in using new web-based apps like these. We, as in the mainstream, are doing exactly what could have been predicted we'd do: going for convenience as we alway
I think... (Score:1)
What will be the killer app? (Score:2)
Okay, so I'm a little fed up about hearing about AJAX. It's not a cure for cancer people, it's a way of updating web pages without a page refresh! For the people that find it useful, great. I really like GMail, for example.
I see comments like "most sites that utilize these technologies seem to be incremental improvements, not revolutionary in
The biggest get always the best place (Score:1)