I think it’s an interesting way to think about temporally organized data (I could see RSS feeds navigated through some similar mechanism, with the z-axis being time and the x- and y-axes being some kind of similarity measure), and further display that graphical presentation is not the sole domain of Flash.
By now, you’re almost certainly familiar with Ajax as a buzzword. Technically, it’s an acronym—Asynchronous JavaScript and XML — and refers specifically to JavaScript’s XmlHttpRequestobject,which lets a browser initiate an HTTP request outside the confines of the traditional page request.
Yawn. The technology isn’t the exciting part. Ajax is huge because it pushes the boundaries of what you can do with a web UI: it lets you reload part of a page without reloading the entire page. For a page-based medium like the Web, this is a seismic leap forward.
The chapter delves into the world of Ajax.Request, Ajax.Updater, Ajax.PeriodicalUpdater, by showing subtle examples of how to deal with timers, errors, and a lot more.
On the back of the iPhone 3G news at WWDC, the next biggest thing was the launch of Mobile Me, a compelling user experience to access Apple services using standard Open Web technology.
The application is written using the SproutCore framework, and I got to sit down with Charles Jolley, one of the founders.
We talked about the history of the project, how it differs from other frameworks that are out there, and where they are going. It is interesting that this podcast comes after the 280 North one, as they are both Cocoa inspired.
SproutCore is much more JavaScript focused though, and gives you MVC in the client in a simple and intuitive way. I found it interesting to see how the framework has developed, from its Rails plugin roots, to now (dispel myth: it has no dependency on Rails, just some build files are Ruby).
Charles talks about techniques that they use to give you fast applications (common global event dispatch seems key, and Prototype 2.0 is adding this) and how he feels that compelling rich browser applications will keep pushing the browser vendors to speed up, and shape up!
XMG Networks has thrown their hat into the on-line photo sharing ring with the launch of 72photos, an Ajax-heavy site which looks at least partially inspired by Apple’s iPhoto ‘08-generated web galleries.
We asked 72photos to tell us a bit about how they went about building the site and how it compares to competitors like Flickr and Smugmug; “Eric A” kindly replied with some details:
Building the Site
We do indeed use Prototype / Scriptaculous for our main Javascript frameworks and it’s been that combination from the very beginning. There’s always been a way to accomplish want we’ve needed PT and is due to the fact we tend to use more of the basic PT functions (selectors, event handers) and build our own “sub-frameworks” as we go along. Our functionality is fairly unique to the web and hasn’t been done in any sort of pre-packaged framework yet (as I know of). Thus, we found ourselves building a good portion of things in-house.
Features
We don’t do anything extremely new or groundbreaking in terms of features at the moment, somewhat of a reason for that is the fact our site appeals to a large percentage of novice users and we wanted to tune our functions to resemble something such as a desktop application which seems to be the familiar place for all users. However, as development continues, we’re constantly finding the balance between integrating professional features as well as fine-tuning the basic features that everyone is familiar with. There are a myriad of experimental features we have planned and developed, but opted to build a solid foundation incorporating those familiarities before implementing our more eccentric features which we’ll be looking to integrate over the next few months.
Compared to Other Photo Sharing Sites
1. Fully customizable photo galleries - Our gallery interface features drag & drop functionality to add and arrange photos in a gallery. Real time customization options let users customize the colors and fonts for the gallery and preview the changes real-time. Several preset gallery themes are also available. Here’s a sample screen:
2. Profile pages - All users get a full profile page displaying all their photos, tags and galleries elegantly:
3. Community Features - Our community features are also superior to that of other sites, such as the ability to track friends activity by seeing recent uploads or galleries by them and having the ability specify the type of friend they are (friend / family) then modify your photo/gallery/profile permissions accordingly.
4. Editing - Our editing features are all done in Ajax / Javascript which covers the basic cropping, effects, enhancing, constraining and will soon feature much more robust functions including step-by-step versioning (compared to our basic versioning features) and a greater array of editing effects and manipulation functions (batch editing, watermarking, etc).
5. Webspace - We always save users fullsize photos, no size caps on individual photos or monthly limits. Only an overall size limit per account type (free or pro).
6. Usability - All the backend functions are done “real-time” in lightbox windows, so there is minimal page reloading which is offers a considerable increase in efficiency when working with photos and galleries.
Eric also shared some of their plans for the future:
Currently, 72photos is just an evolved version of sites such as Smugmug, Flickr, and Zenfolio. Offering features to professionals and novice users in a carefully thought out and intuitive interface. In the near future we’ll be greatly expanding our community features to cover areas of what you do after the point of uploading and editing your photos. Such as offering areas for photographers and artists to sell their art and other areas such as a place allowing models to find photographers in their area, vice versa, and more.
I just wish the iPhone would follow other handset manufacturer’s lead and put a really nice camera in the phone. I know I’d pay extra money to have a 4 MP camera with a nice lens and a flash…
David Kees has written about Using Prototype to Load Javascript Files, which is an implementation of the general technique of loading functionality via scripts based on the availability of DOM elements.
He started using the technique to scratch an itch:
The calendar on this site only appears on pages that show blog-related information. That calendar is enhanced with Javascript allowing you to change the month displayed by the calendar without reloading the rest of the page. So, in order to ensure that these enhancements would be available everywhere the calendar is, I figured I had two options:
Code the inclusion of the Javascript file into every page which requires it. While a good solution, and one that has worked well in the past, sometimes it can be difficult to remember or realize that you've forgotten to include the file when you add new pages that require it.
Find a way to automatically include the file when it's needed. This would avoid the need to remember the need to include it when adding new pages that require it, but would result in a little more Javascript going on when the page loads.
We are having a special week at Ajaxian. Ben and I are giving an Ajax talk at JavaOne this week, and decided to put a little video from Ajax pioneers. As we worked out what we wanted to do, we asked the pioneers for a little time to do an interview. Although only a piece of the interview will be used in the live presentation, we wanted to get the full interviews for the community here.
During the week you will hear from:
Sam Stephenson of Prototype
Bruce Johnson of GWT
Alex Russell of Dojo
John Resig of jQuery
On Wednesday, we will have a special video that features Ben and I having some fun with a new type of Ajax application.
Let's cut to the chase, and listen in to Sam Stephenson. Although we couldn't get to him in person, he kindly recorded himself via his laptop. My voice quality is poor, but we are all hear to listen to his thoughts on:
The future of Prototype
What excites him about new versions of Prototype, and what problems are they trying to solve
Thoughts on the current crop of browsers, and what he wants to see
In the interview he discusses pdoc, a new inline documentation tool, Sprockets, a tool to help package Prototype, and new event delegation techniques.
Twistori is a fun little site created by Amy Hoy and Thomas Fuchs. As you would expect, design is a key part of the application, and the Prototype / Script.aculo.us combo pull off the work.
The site pulls in live data on various topics (love, hate, think, believe, feel, wish) via the real-time twitter search tool summize.
In related Twitter news, I created a Greasemonkey script Twitter Translate that auto-translates foreign text to your language inside Twitter.
Stephen Celis got tired of wiring together two date pickers for the common use case of grabbing a date range, so he created timeframe, which is "Click-draggable. Range-makeable. A better calendar."
Based on Prototype, you can whip up some code such as:
Sometimes you want Monday to be a Friday, so we have ProtoRPG, a role playing game written by Pierre Chassaing in JavaScript using Prototype and Script.aculo.us.
Walk around, add to your inventory, and feel like you are playing your first RPG many moons ago, on a Friday.
When I hear "email marketing" I can't help but think spam, but it is a legit tool too, and the latest tool in the pack is Mad Mimi.
Mad Mimi launched this week and consists of "state-of-the-art UI design makes for layouts that are easier to
create -– and easier to read – than emails generated by Constant Contact, Emma and others, who rely on rigid templates and cluttered,
dated layouts."
Mad Mimi's "modules-based" interface allows users to add picture and text fields, drag them around and add captions, links and dividers. Embedded constraints gently guide the layout, keeping the "designer" from getting into trouble, but providing more plasticity than templates.
The result: a fluid, flexible user interface, and clean, fashionable "Mimi-generated" promotions that represent a fresh approach to email marketing – at a subscription price that trumps the competition.
When I saw that Tobie Langel was on the team, I had to check it out. When you give it a spin you will be able to add images, and then use them to build out your email. There are some really nice subtle features such as the undo support.
Executed tests show that Prototype seems to be faster then jQuery, with the exception of the new insertion method, which performance should be improved. Although I like jQuery syntax more then Prototype, the performance is way more important then saving few lines of code. Of course tests that I made don’t show how these libraries act in a real application, which is my task for the next part(s) of this article. Despite the results I must admit that I’m very excited about jQuery, my general impression is that this library is more mature then Prototype.
In part two, Piotr uses a custom JavaScript-based testing environment instead of running tests using Firebug profiler. This allows the test suite to run in many browsers, and this time concludes:
Prototype was at least 2 times faster then jQuery in 15 cases, and jQuery was faster then Prototype in 8 cases. What library should I choose? In my case I will stick with Prototype, because it offers the same functionality as jQuery does + more and it’s faster. jQuery is probably better for projects where there’s a need for some fancy UI effects and that’s it, but it’s just an assumption, correct me if I’m wrong…
Sebastian Brink has developed a nice looking gallery application called qGallery
It is really simple to use you just have to upload your images in full resolution together with a simple xml file and include the script and a simple div into the webpage. Everything else is done automatically. The gallery is creating every used image on the fly with the help of some php scripts in the background.
It is developed on top of Prototype and a bunch of other libraries.
With so many new components being developed in a variety of different of JavaScript libraries, it's a natural expectation that sooner or later, you're going to want to mix and match these components within your application. Sometimes though, it's not that easy due to architectural conflicts between different libraries. John David Dalton set out to minimize this pain via his new project called ProtoSafe.
I started ProtoSafe in response to a couple of posts on the Prototype Core Mailing list written by developers frustrated with Prototype’s 3rd party compatibility issues. I did some digging and found a post my Mislav Marohnic (here) explaining an easy way to keep Prototype out of the global namespace by simply wrapping everything in a self-executing anonymous function.
I asked John to explain the best use case for Protosafe and how it helps:
Prototype extends native data type prototypes which makes it very convenient for the developer but when interacting with 3rd party code not written for Prototype, these prototype extensions can cause compatibility issues. The most common is the Array for-in loop issue where by doing a for in loop over an array you get its indexed values plus the method names of all the added helper methods.
The benefit that ProtoSafe provides is that it allows Prototype to be used alongside 3rd party code without causing these compatibility issues.
Also it can be run against multiple frameworks which is good in the widget environment.
The demo page shows MooTools,Prototype,Dojo,YUI,jQuery all running on the same page.
Some highlights of ProtoSafe are:
It allows Prototype to work with 3rd-party scripts (no Array for-in
loop pollution).
It works with Prototype 1.4-1.6.0.2.
Custom Packer3 that supports Prototype 1.6+/Scripty 1.8.1+
Only 3kb gzipped, less when compiled into the standalone js.