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…
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.
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.
I used to work in the healthcare sector, and was always amazed to see the amount of paperwork that was required. Literally paper work that is. The industry was full of drawers overflowing with paper.
I imagine that the legal profession has its fair share of this too, but one company Nextpoint, is trying to change that.
I had the opportunity to sit down with some members of the Nextpoint Lab, including Jim Halberg the Ajaxian, to get a tour and discuss their latest products. Below are a few questions about the Ajax implementation, and we finish up with a video showcasing the work.
What are the Nextpoint tools?
Nextpoint's flagship software product (marketing site, brochure), brings web 2.0 to the world of litigation software. We provide a powerful and easy to use way to manage the mountain of electronic information associated with any case.
What are some of the cool Ajax features?
The site has many small ajaxy features. Things like status bars for uploads or bulk operations, submitting small bits of data that shouldn't require traditional round-trips, or updating a small piece of the page with some results. The stuff we think Ajaxian readers would be more interested in mainly revolves around our work with images.
A real pain source for many years in trial litigation has been stamping documents. When you decide you want to use a document in court it must be stamped (i.e. "Defense Exhibit 1") and then communicated to the opposing team of lawyers. With most products today this means, locating the document in the management software; exporting it; printing it; physically stamping it; scanning it back in locally; uploading it back into the management software; and finally transmitting that electronic copy... it's not hard to see how this could get annoying after the 100th time you've had to do it this week. Nextpoint provides the ability to electronically add a customized stamp - these can be resized or repositioned as desired and because we're doing things electronically it's much easier to do things like "stamp these thousand documents as 'Defense Exhibits'". Believe it or not - the server normally can get this task done a bit quicker than a guy with a rubber stamp in his hand. When the machine is done stamping - they're already electronic copies - you're ready to go.
Our flashiest use of Ajax is in our presentation tool, "Theater". Many of our clients are using this tool to prepare document treatments before a trial, so that they're ready to call up at a moments notice in a pre-formatted state. It also may be used live in a courtroom to direct listeners attention to important points in a way that visually impresses. We'll show this off in the demo video we're going to provide.
What tools are used to create theater?
Theater is mostly a custom javascript application, using prototype and scriptaculous to simplify the Ajax communication and animation. The images are served from a Merb-based server, which uses the GD libraries to do scaling, rotating, cropping, and setting transparency on the fly. The transparency is especially important, so that HTML elements can be used as highlights behind the main image content, keeping the user interface very responsive.
What were the biggest challenges getting all of this Ajax stuff to work?
Even when using Ajax to keep the traffic between client and server light, the latency and server processing time can become quite apparent. Theater employs a few neat tricks to keep the application feeling responsive. The annotations on documents (mentioned above) are done with HTML elements, preventing the wait of a roundtrip to the server to get a new image. When loading new documents, a pre-generated medium-resolution image is loaded first, and then replaced with an exact-fit image once it's ready, which usually takes less than a second. Similarly, when creating callouts of an image section, the main document image is resized and cropped in a DIV in the browser as a low-resolution preview until the high-resolution version is available. The same thing happens when callouts get resized to make room on-screen for more callouts. Users feel more like they're working with an application when they can continue to work with the preview versions instead of waiting after each click.
Allowing users to resize and reposition a "stamp" on top of an image presented some challenges but most of the trouble in that interface emerged from making sure that the final position the user set with css/js was properly translated into coordinates that could be used for the actual image manipulation on the backend. Allowing a variety of stamp formats, variable amounts of text, and translating between entirely different measurement systems for fonts on the server vs. the browsers complicated things, as well as the oft-demanded rounded corners to make the stamps look "more natural".
Originally Theater was based around a tiled-image concept, like Google Maps. The images were pre-cropped into tiles at a few different "zoom" levels, and then further zoom levels were simulated by resizing in the browser. Unfortunately, storing 200+ images for each page of each document quickly became unmanageable. In addition, many browsers use a pretty low-quality algorithm for resizing images, leaving the in-between levels looking "chunky" or "distorted." Using the GD library, and a streamlined application server that doesn't load the entire Rails application, we were able to overcome this issue by generating images on the fly. That reduced the number of requests made to the server and creates pristine images of just the right size.
Demo
Below is a demo of the product. For a high quality version go here.
UPDATE: A new video showing the data stamping technique has been added. There is a normal version, and a high res one (must be a vimeo member for high res).
We've all seen variations on date selection components such as Marc Grabanski's UI DatePicker and the very unique DateJS library. So it's refreshing to see new ideas cropping up in this space.
...we present the sliding date-picker. This element enables you to pick dates with a simple slider bar. By dragging the bar over the time-line, the dates change instantly. Besides this, when the user decides to manually change the dates, the bar is automatically adjusted to the corresponding dates. As you are used to from us, the script is based on Prototype/Scriptaculous, but now combined with the very sexy DateJs library.
It's a mix of Prototype/Script.aculo.us for the cool slider effect coupled with DateJS' date string parsing capabilities. I think this is a novel method of choosing dates. One enhancement that would make it very cool would be to have the slider dynamically appear when an input field received focus or perhaps a user clicked on an icon next to the input field.
You can see the demo for the slider date picker here.
The site shows off the new easing code that Robert Penner contributed to Dojo:
A small change in the Animation system to accommodate
the inclusion of the entire set of Robert Penner's Flash easing functions to The Dojo Toolkit. They were contributed
under CLA to the Dojo Foundation, and ported to JavaScript (dojox.fx.easing) by Bryan Forbes,
a Dojo committer, and maff mastermind.
He had released them BSD some time ago, officially. This CLA only insures a clear
traceable licensing path: written permission from the author. Its a huge win for JavaScript, and
the toolkits using or wanting to use those functions (Dojo now included). A big personal Thank You is in order, from all the OpenWeb.
The dojo._Animation change is transparent, though these functions will not work
with the Dojo 1.0.x branch, basically because numbers were being clipped beyond "100%" of
the Line (like in the elastic easing functions, the "snap back" after overshooting the
target).
The moj.oe demo started out as a simple preview of this _Animation change, and the
fun easing functions. The gravity button uses the bounce transition to drop the circles
to the ground (and bounce), the snap-back when you drag the circles (or logo) uses
the elastic easing function, and the "Live Download" dialog uses the backIn easing method when
you click "hide", for that "little boost immediately before leaving" ...
NASA has relaunched their site tonight as NASA 5.0, in celebration of their 50th anniversary next year. It is the beginning of many web 2.0 features to come for NASA.
Sep Seyedi of Critical Mass told us that "of interest to you is the fact that the new interface fully uses the script.aculo.us and prototype Javascript frameworks for its implementation. It was a pretty challenging implementation but got through it."
The new site features:
Transitions: Lots of animations in drop downs and trees
Accordion: Rollover news items
New topic based navigation
Calendar component
Tag cloud (now that IS Web 2.0
Bookmarking: My NASA and support for Digg, Del.icio.us, and more
They cleaned up, and 1.6 is a really nice piece of work. A lot of little nit-picks are now solved, and you are left with the lean mean machine that you know and love.
Highlights
Ajax transport objects are now automatically wrapped in an Ajax.Response object.
Ajax.Response includes support for accessing JSON response bodies as JavaScript objects via the responseJSON property.
The class API now includes full support for inheritance and superclass method calls. (See Mislav’s tutorial for more info.)
Class objects now have an addMethods method for adding instance methods after creation.
Elements can be created easily with the new Element(...) syntax.
Element#insert provides a unified API to DOM element and HTML fragment insertion.
Element#select is an alias for getElementsBySelector and is now the preferred way to find elements by class name.
Element#wrap lets you easily wrap an element inside another element in place.
Enumerable methods on Array are now backed by native Array#forEach implementations when possible.
Enumerable now has aliases for equivalent JavaScript 1.6 Array methods, and support for JavaScript 1.6’s context parameter for automatic callback binding.
Enumerable#grep now calls the match method on its first argument, so you can use it to e.g. filter an array of DOM nodes by CSS selector.
Event objects are now automatically extended with instance methods, so you can write e.g. event.stop() instead of Event.stop(event).
Prototype’s event API now supports firing DOM-based custom events with Element#fire.
The new dom:loaded custom event fires when the entire document has loaded and is ready for manipulation.
Function#curry allows for partial application of function arguments.
Function#wrap facilitates simple aspect-oriented programming and provides the basis for Prototype’s superclass method call mechanism.
Function#delay delays invocation of the function by the given number of seconds.
Function#defer schedules the function to run as soon as the interpreter is idle.
The Hash API has changed, and you must now use Hash#get and Hash#set instead of directly accessing properties on Hash instances.
String#interpolate is a shortcut for instantiating a Template from the string and calling evaluate on it.
Object properties can now be used in template replacement strings.
Script.aculo.us 1.8
This is the last release before 2.0 comes out and features:
Complete rewrite of Ajax.InPlaceEditor and Ajax.InPlaceCollectionEditor
Full CSS inheritance in Effect.Morph
New core effect: Effect.Tween
Sound: play mp3 files for sound effects; uses native playback on IE and available plugins whereever possible
Duration and distance options for Effect.Shake
Performance improvements
Tons of bugfixes
The Book (Reviewed by Stu Halloway)
The skinny: If you develop with Prototype and Scriptaculous, you need
this book.
Prototype and script.aculo.us: You Never Knew JavaScript Could Do This! is a long book, by Pragmatic Press standards. At first glance,
this might seem doubly odd, since the libraries themselves are quite
small, totaling only in the 100s of KB. But before I even opened the
book, I hoped that the length might be justified, for two reasons:
Prototype and Scripty (hereafter P&S) are packed with dense,
expressive, beautiful code, and they can do far more than their size
might suggest.
Along with several other Ajax libraries, P&S embody a modern
JavaScript style that embraces functional programming. This new style
is not well covered in the JavaScript books currently in print (as of
November 2007), so to learn P&S you also have to learn to think about
JavaScript in a new way.
Once inside the book, I was delighted to find that both of my hopes
were addressed. Porteneuve dives straight into the deep end,
embracing JavaScript's functional style immediately in Chapter 2 and
never dumbing down the example code. (Don't worry, there are forward
and backward references to help you along. This is especially nice if
you are reading the electronic copy of the book.) You may need to
read some sections of this book multiple times, and that is a good
thing.
The coverage of both Prototype and Scriptaculous is thorough. Of
course the marquee features receive due attention: Prototype's
Ajax.Request and Scriptaculous's Effects each have their own
chapters. More interesting to me is the thorough coverage of the less
visible parts:
Prototype's functional capabilities are significantly enhanced for
the 1.6 release. Chapter 4 shows how to use curry, bind (including
multiple argument invocation), delay, and defer. You can even do some
lightweight Aspect-Oriented Programming (AOP) wi
, Prototype
