One of the programs I am pleased to be associated with at the Google open source programs office is the Google Summer of Code where Google partners with open source projects and students to create bits not burgers.
If you are a student, how about making the Ajax world (and hence the web in general) a better place by working on open source projects?
There are some great ones. For example,
Alex Russell has put up great advice for students and the list of project ideas looks compelling. How about being the person to write an activeX CANVAS tag? or working on Dojo Offline? or the JS Linker? or gfx 3d? or Mobile Dojo? The list goes on and on… and don’t just consider this list, what would you like to work on at Dojo.
SilverStripe is excited to be part of the program. Sigurd Magnusson told us that “All of the resulting work will be released open source, for everyone to use, and the point is for it to be good enough to featured back on sites like Ajaxian later in the year :)”.
But look around and see. Is there some killer Ajax work that you would love to get out in open source this summer? Maybe on a project such as: BBC, Drupal, Joomla!, Mozilla, PHP, Plone, Ruby Central, Apache, WordPress, XWiki, Zope, or any others on the list.
He plays with a couple of potential architectures for building a simple blog admin interface, such as:
Old school: Normal Request/Response
RJS Ajax Updates
Client-Side App
Discussion
I have not considered degradation paths in details because I have not included the code in blogApp.js. Some users can cause real grief. For example, a user with Internet Explorer 6, JavaScript enabled but ActiveX disabled (and hence no Ajax) really throws a wrench in the works. The client-side app solution fairs much better in this situation then the RJS app.
You could argue that a solution like the second one presented, where all logic is on the server, should not return JavaScript but rather just data. This could be returned in the form of just the HTML to be inserted or XML or JSON. The client-side would know what to do with this data. I think that for the sake of this investigation the tradeoffs are the same for returning JavaScript remote procedure calls compared to HTML, XML or JSON data because the size of the requests and responses would be almost equal.
You could argue the user interface should be WYSIWYG like the FCKEditor. A WYSIWYG editor would fall in the full client-side app category. It is virtually the same for this discussion as the third solution presented above. The WYSIWYG editor would submit the HTML with bold tags that will be used for the blog article rather than form data with asterisks. As mentioned earlier, the client-side app presented in this article could also submit HTML generated for the preview rather than the form data.
Each of the three solutions presented is still appropriate today in particular situations. I am planning a big project that may use a full client-side app solution. There would still be times where I use a classic solution for a web page that isn’t commonly used and doesn’t need to be responsive. It all depends. What I have learned from this investigation is that RJS and similar solutions are probably too expensive for live previews. If the DRY principle is to be implemented and the logic must be on both the client and the server then some JavaScript should be used on the server.
Now is the time to push Adobe in directions that you want them to go. How native do you need Apollo to be (range: "nothing. Flash is just fine" to "let me write to my device drivers damn it")?
Adobe has the ear of the Flash world, but let's make sure they hear about our needs... from the Ajax world.
server independant or not ? server independant frameworks will help you in mashing-up server technologies and lowly ties your software architecture while server dependant frameworks may increase your productivity but makes difficult major changes to your projects.
structural Javascript enhancements ? Javascript can become a maze if your team does not share a common development methodology . There are so many ways of doing the same thing ( like creating objects of accessing the DOM ) in JS, that you must formalize the way to do it. Such a framework may help via on-demand Javascript, packaging abilities, enhanced OOP...
re-usability of your written components ? making use of it shall help you in re-using written components in your next projects.
framework current documentation level ? often low for most projects, you must take care of it
features you need ? you may look at your projects needs ( or near future needs ) and see if the Framework can handle them. Some are GUI oriented, special-effects oriented, Javascript centrics, communication only oriented. None will completely cover your requirements. What is the complexity degree in making the framework evolve ? can you add your own features in the framework ? will you help committers ? Can you mashup multiple Frameworks ?
How long will it last ? Most projects are companies own projet spin-off. The Framework evolution depends on their ability to maintain and make the project evolve. A good user community is important as well as talking to developers when needed further functionalities. Taking care of sponsors and the framework current uses in production web sites, is a good start in guessing if the Framework will last years or will be stopped in six months.
What sort of support ? Is there a community support ? commercial support ? test reactivity while testing it.
How steep is the learning curve for the framework? Can your team handle such a technology. Many developers are reluctant to Javascript . Can they handle such a change, is the Framework simple to understand ?
Who are my visitors ? It seems that a very light framework is required for a public site. If your visitors need to upload a large Javascript API, they may not visit further your website, depending on your page's download times. When working on intranets, or professionnal services, it may be acceptable that the first access to the application may be longer, moreover when the website is used daily. Also think about on-demand Javascript and Javascript compression.
It must be Friday. Web-O-Random is a new website I created to spend hours exploring random websites the Ajax way ;). A list of URLs is fetched from the server, placed into an animated carousel/slider component, and you can then navigate through the carousel to preview the websites.
Technologies:
Server is Rails-based, accessing URLs from the Open Directory Project (as Active Records). Uses the Prototype Carousel component by Sebastien Gruhier, in turn based on Yahoo!'s carousel Scriptaculous is used for some effects.
URLs are fetched via JSON calls.
As with WebWait, site is loaded into an IFrame with event handler to determine when it's been loaded (in Firefox).
Nich Tyrrell of InTime Games created a new Ajax site with a strange name indeed... Eat Poop U Cat.
The site uses a combination of Google Web Toolkit, Amazon S3, and Amazon EC2, along with an in browser drawing utility that uses the Canvas element to get it all working. Its an online version of a party game similar to the game of telephone only using pictures and sentences.
So, you can go online, put in a random sentence, and people will start drawing a cartoon off of it.
In my recent post on current concerns with Ajax, there was a comment about lack of documentation for Dojo and Prototype. In the comments (of the Ajaxian post and my blog post), project members asked what would you like to see wrt documentation?
Here's my wishlist for Ajax framework docs, in particular Dojo and Prototype:
Project/documentation portal A single page linking to all relevant documentation, with simple categories.
Task-based. Documentation based on typical tasks users (developers) need to perform, not just a walkthrough of the API. The Yahoo! UI docs is a good example of this. Dojo has a few tutorial-style articles that approach what I'm talking about, but not enough components are covered.
API reference Less important to me, but in an ideal world, there would be accessible documentation on every class/function.
User-commentable PHP leads the way here, with the official API docs allowing user comments at the bottom (example). No-one can anticipate all the issues that will arise, so why not open up docs to the developer community? Allowing user comments is also an easy way to help keep the docs up to date (if something of a compromise.) It could also be done as a wiki, if the wiki is managed well. (The Rails wiki is a good example of a well-maintained wiki that receives frequent contributions from people in the know.)
Up to date This one is more difficult for open-source projects, so realistically it has to be considered a nice-to-have at best.
SEO'd So I can google for a component name and easily find the official docs for it.
I believe we have some good examples of docs in the Yahoo! UI library, Scriptaculous (which includes Prototype sort of), and Mochikit, and probably many others too. Prototype also has the benefit of being included in many Rails books. Dojo is an excellent library, and would probably be used a lot more if some work was done on the documentation side.
Ryan Johnson has created unobtrusive JavaScript tabs called Control Tabs.
The project uses Prototype / Scriptaculous. You create the tabs using standard
anchors and named elements, so it's completely accessible to non JS
browsers.
This time, comScore has announced a new "visits" metric. "AJAX" is cited as one of the motivations.
comScore Media Metrix today released its monthly analysis of U.S. consumer activity at top online properties and categories for February 2007 and introduced a new suite of metrics based on site visits. The visits metric, defined as the number of times a unique person accesses content within a Web entity with breaks between access of at least 30 minutes, is a way of measuring the frequency with which a person views content, thereby illustrating a key component of user engagement. Included among the new suite of metrics are: total visits, average minutes per visit, average visits per visitor, and average visits per usage day.
As technologies like AJAX change the Internet landscape, certain measures of engagement, such as page views, are diminishing in significance for many Web properties, said Jack Flanagan, executive vice president of comScore Media Metrix. The introduction of these new metrics based on visits provides an alternative for measuring user engagement that tells us how frequently visitors are actually returning to the site to view more content.
We have been talking about how the desktop and web experiences are converging, and Jeff Atwood is asking Are Web Interfaces "Good Enough"?
His example is µTorrent, and how the new web UI is so similar to the downloadable version:
After spending about a year interacting with µTorrent exclusively through Remote Desktop, I was pleasantly surprised to discover how good the web UI is. It aggressively exploits the latest Ajax techniques to replicate most of the rich GUI functionality of µTorrent in a browser. But the web UI is still a pale shadow of the full-blown Windows UI. There are small but important details missing throughout, and part of the pleasure of using µTorrent was luxuriating in its intense attention to detail, its wealth of well-designed data readouts. Using the web UI is like drinking watered-down beer. It doesn't satisfy.
(Emphasis mine)
So he asks, does it matter? Does it matter if the attention to usability detail is no longer there in web apps, as long as we can "get the job done" and are still reasonably usable? This is a common theme in web apps...there are analogies with the online office apps and image editiors. The usability is actually decent in most of these apps...it's just that they miss some of the little details that help make users passionate.
He also has some comments on Flash versus Ajax. Where Bruce Eckel argues the future of many web apps is Flash, Attwood says:
I think Eckel is too quick to dismiss the utility of browser-based JavaScript applications. Yes, they're painful to create and debug, but they exploit the path of least resistance. And if I have learned anything in my entire life, it is this: never bet against the path of least resistance. You will lose. Every time. What Eckel neglects to consider is this:
The typical user only touches a fraction of the functionality in most applications. Switching to an online spreadsheet like EditGrid or WikiCalc is hardly a catastrophic loss when you only used 1 percent of Excel's functionality to begin with.
Online applications may be awkward, but they do one key thing that local applications can never do: embed snippets of live content in a web page. Instacalc may never be Excel, but so what? It's a completely different use case. Instacalc is ideal for embedding bite-sized, interactive nuggets of calculation next to a paragraph of text on a web page. It's the YouTube of spreadsheets.
Eckel sees a world of JavaScript and DHTML that's inappropriate for large applications. I see a world of large applications that are inappropriate for most users. It's high time we scaled down and scaled back. If anything, this is a beneficial side-effect of the limitations inherent to the platform.
UED is a tiny library that takes a hash and converts it into a URL. Instead of passing a JSON string, for example, you could just construct a URL containing the transfer object. Update: I should mention that this is more about the format than the library...UED is a proposal for a standard way to encode an object into a URL, in the same way that JSON is more a format than a library.
Since it assumes you are making GET calls, RESTful design would suggest only using UED for non-destructive calls (i.e. calls that don't change server state).
In Episode 20, we chat with Kevin Lynch, Brendan Eich, Alex Russell and others to find out more about
Project Tamarin, the high-speed JavaScript engine donated by Adobe to the Mozilla Foundation.
