Scott Boyce wrote in with an interesting story about deckmyplace.com.
The site was originally designed as a Flash site, but when the mandate came from the top to use HTML instead of Flash, he had to see just how much of the original comps he could implement. And it turns out, pretty much everything.
We asked Scott to share some details on his experiences building the site:
When the mandate to drop Flash came, there wasn't time to redesign. My goal was to make it indistinguishable from Flash visually, but do so while employing valid markup, progressive enhancement, and Section 508 accessibility.
MooTools
I had previously used Mootools (and moo.fx prior to that) to add subtle animation to interface elements, but I had not built a site entirely around it (or any other JS library). I had also not created a site with such explicit positioning throughout, so there were CSS challenges as well.
I used a lot of Mootools' built-in assets: AJAX, tool tips, sliders.
Fancy Page Transitions
The page transitions are done with a combination of effects. Basically, there's three layers: the frame, the content, and the (ususally hidden) background. When the user navigates to a new page, the following occurs:
1. The background is switched to a blurred screenshot of the current page (instant; the image has been pre-loaded).
2. The opacity of the content area is reduced, revealing the blurred background image (300 ms).
3. New content is loaded via AJAX (each content page is about 1 KB; the lounge is about 4 KB).
4. The opacity of the content area is scaled back to 100% (300 ms).
The Development Process
The content was first laid out with HTML, using PHP includes to eliminate the need for any duplicate content. (Incidentally, the entry form and validation were also written in PHP.) The CSS was created alongside this framework, which resulted in the JS-disabled version of the site. Once we were satisfied there were no issues with the display or functionality in a few target browsers (Firefox, IE6, Safari, Opera, Lynx, IE6 + JAWS), I started writing event listeners.
Once the JavaScript was written, we tested again. In the end, I think the only thing we had to drop were the background music and some of the secondary animation (spinning knobs). Still, most people just assume it's Flash.
Firebug, YSlow, and the Web Developer toolbar for Firefox were invaluable tools during development
Stats
* Total JavaScript is 59 KB (51 KB for Mootools + 8 KB for the library)
* 30.9 KB of CSS (including 4.7 KB of CSS for MSIE loaded via conditional comments)
* 2.59 MB for the whole site (2.11 MB of images)
I love the legal disclaimer at the bottom:
The thought of a corporation owning a trademark on a given name... fascinating. I can only imagine the future litigation between the Dave Thomas' of the world.
Joining with the Web 2.0 "go-meta" business model that's so popular these days, iWidgets provides a service that lets you build widgets once and deploy them to various popular widget APIs and platforms.
At the heart of iWidgets is a "PowerPoint-like" widget builder that takes strong design cues from Yahoo! Pipes, but as Peter Yared (CEO of iWidgets) says:
then again Pipes looks a lot like Prograph (the original dataflow programming company, where I worked from 1992-1995)
The site transforms the widget you build into:
a native FBML or GoogleGadget/OpenSocial, which are two completely different architectures (serverside vs. clientside), and then call the destination-specific API's for things like persistence whenever possible.
The builder was constructed using jQuery and like Pipes renders the connection lines using <canvas>. Peter shared some of the back story behind building the application:
I wrote the initial builder in [another framework] and found it obtuse. After spending literally a week trying to turn the date picker into a color picker, I threw in the towel. A friend of mine turned me on to jQuery and I fell in love with how clean and fast it was, the way it separates the HTML from JavaScript is beautiful. So I rewrote the builder we had at the time in jQuery in a two week coding session! Soon after that I got funding from Opus Capital, and when I looked to hire people, I found 3 out of 4 of our engineers through the jQuery mailing list. It's funny how things like that work out; I ended up finding total rockstars because they were playing with a cool new library.
Peter also shared some details on the overall development process:
It took us 10 months to build the site, we have had one guy (Richard Hensel) full time on the builder UI with another guy (Jeremy Stanton) on it about 1/3 time, with the rest of his time on the overall site doing the wizards and getting things like the %#$# back button to work. Then there are two guys working on the backend, one on FBML and the other on Gadget/OpenSocial, and we just added a junior AJAX guy. We contribute back where we can, for example Jeremy contributed to the Selectable in jQuery UI. The iWidgets site itself is completely AJAX, data from the server is sent as JSON, and page fragments are rendered with Wicket. We persist the widgets you build as JSON and then transform them on the server into native Facebook, MySpace, iGoogle, etc.
The team has some future plans building on top of an already very cool site:
We have a bunch of features we are rolling out, such as calling JSON and piping the results into different components, repeating table, paging, cut/copy/paste, z-order control, live dataflows in the builder, a background process at amazon that sends out notifications like "joe just shot 2 over par at pebble beach" to newsfeeds to drive virality, more platforms such as the iPhone, etc.
I wonder if this should somehow integrate with Yahoo Widgets, Apple's Dashboard, and other desktop widget platforms... maybe emit a bundle you can download and install into these services?
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...
Obsurvey features a highly dynamic interface for building custom surveys; you can choose from a bunch of different survey elements and customize them in place using a technology the Obsurvey team calls "Active Rich Document" (ARD). Nicely done!
Dov Katz pointed us to Josh Bochner's labor of love, http://www.jigadig.com/. It's an Ajax-heavy jQuery-powered auction site aggregator. What really got our attention is the search results page, which among other things lets you view full item descriptions in-line without having to jump to a different page, infinitely scroll, and easily "pin" interesting items for later perusal. Nice job Josh, and definitely worth a look.
You can now tab over to the box on the top right, and filter your selections:
This tutorial shows you how to upgrade those plain vanilla pages to make getting around a little faster and along the way introduce you to some of the most useful bits of Dojo, and practical techniques for working with them. We’ll touch on: dojo.query, dojo.data, the dojo parser and dijit (specifically the FilteringSelect widget.)
This is a great look at how things work in Dojo land, including the interesting code embed technique:
Steve Souders has released a nice little tool called Cuzillion which has the tag line of ‘cuz there are zillion pages to check, although it could also be that there are a zillion ways to do Web development!
The tool lets you test out different techniques for optimizing performance in browsers, and these tests can be saved and shared by the community.
Steve explains how the tool came about:
I’m constantly thinking of or being asked about how browsers handle different sets of resources loaded in various ways. Before I would open an editor and build some test pages. Firing up a packet sniffer I would load these pages in different browsers to diagnose what was going on. I was starting my research on advanced techniques for loading scripts without blocking and realized the number of test pages needed to cover all the permutations was in the hundreds. That was the birth of Cuzillion.
Here Steve talks about some examples:
A great example of how Cuzillion is useful is looking at the impact inline scripts have when they follow a stylesheet in Internet Explorer. Typically, a stylesheet followed by any other resource results in both resources being downloaded in parallel in Internet Explorer. (In Firefox stylesheets block parallel downloads, so this performance optimization is only applicable to IE.) Here’s a Cuzillion page that shows this: stylesheet and image downloading in parallel. Both the stylesheet and image are configured to take 2 seconds to download. Since they download in parallel the page takes about 2 seconds to load as shown by the “page load timeâ€.
But look what happens if we put an innocent inline script between the stylesheet and image: stylesheet, inline script, and image. Now, in Internet Explorer the stylesheet and image are downloaded sequentially, which means the page load time goes from 2 seconds to 4 seconds. If the inline script is simply moved above the stylesheet the two resources are downloaded in parallel again, and the page load goes back down to 2 seconds: inline script, stylesheet, and image.
This was a great discovery. But immediately my officemate asked if inline style blocks had the same effect. No problem. With Cuzillion I just do some clicks and drag-and-drop, and can test it out: stylesheet, inline style block, image. It turns out inline style blocks don’t cause stylesheets to block downloads.
The findings from a tool like Cuzillion are really valuable. The lessons learned from poking at inline scripts and stylesheets can save hundreds of milliseconds on page load times. And it’s a common problem. eBay, MSN.com, MySpace, and Wikipedia all suffer from this problem.
Much thanks to Google for letting me release this code under Open Source. It’s not currently on Google Code but if you want to contribute let me know and I’ll do that. Try it out and send me your feedback. And share your insights with others. We all want the Internet to be faster!
Steve is talking at Web 2.0 Expo today at 1:30pm in room 2002. If you are in town, check it out and see Cuzillion in action!
In essence, his solution allows you to have custom events on application modules and listen to them independent of execution order or availability. Simply using custom events can get you in a pickle if you make yourself dependent on their order. With the decoupling solution proposed by Caridy this becomes one less issue to worry about.
var timer = YAHOO.lang.later(1000, foo, 'method', [{data:'bar', data2:'zeta'}], true);`
And then you have the need to merge. If you are used to Rails development you will get addicted to passing hashes around and using merge type operations to do your deed.
Jacob Seidelin went on a ( crazy :) ) mission to create a pure JavaScript video player that didn't use Flash:
My first thought was to read binary video files using a technique like the Andy Na posted about here, figuring that there must be some really simple to parse video formats around, but I soon changed directions and decided to make up a whole new video format. Enter.. JSONVid. Using a player like mplayer, it is easy to export all frames in a movie clip to individual jpeg files, and using whichever language you prefer it is also fairly trivial to collect these files, base64 encode the bunch of them and throw them all together in a nice JSON file (I used this PHP script).
The format uses good ole data: URLs, which are finally supported in IE with version 8:
{
frm : "JSVID", // format id tag
ver : 1, // version number of format
width : 320, // width of video
height : 240, // height of video
rate : 15, // framerate (frames per second)
frames : 495, // number of frames in file
data : {
video : [ // here comes 495 data:uris containing base64 encoded jpeg image frames
"data:image/jpeg;base64,/9j/4AAQSkZJRgABAgEASABIAAD/7gAOQWRv ... ",
"data:image/jpeg;base64,/9j/4AAQSkZJRgABAgEASABIAAD/7gAOQWRv ... ",
...
]
}
}
