sorted by: recent | see : popular

Content Tagged with front + Examples

Jacob Seidelin is up to more tricks, this time playing with the binary side of life and writing a library that can reading ID3 tags from MP3 files and such.

You can view a demo at work or download the code.

Of course, Jacob realises that this doesn't make sense for many use cases:

Of course, one big disadvantage of doing this on the client in JavaScript is that the you need to download the entire MP3 file before the tags are available, so it might be better to stick to server-side solutions in many cases if all you need is the tag info.

Inspired by the Gmail team and how they created well known Greasemonkey endpoints and the custom events work that I have been doing, I was lead to play with custom events as a way to tie into key bindings. This lead to the following post on my blog:

On the back of my example enjoying the Observer pattern with custom events I have started to play with a pet project also involving custom events.

I love keyboard shortcuts. I hate the mouse. I wish that Web applications would offer more keyboard shortcuts a la Gmail, and wondered if there could be a generic way to tie keys to actions in an app. There are things such as accessKey, but we need more.

If you start to follow the pattern of creating named events for public integration points, then how about tieing in keys? I implemented this on the quote example, where you can now use up and down arrows, and N and P, to move through the list of names.

To use the system you declare the keys and tie them to events:

This code ties the keys to the actions, and thus fires those actions when pressed. Next, you need to capture those events to do the work when the key is fired:

With a standardized way of annotating events, interesting side effects appear. You can hit the '?' key to bring down a heads up display sharing what keys do. You could imagine a Greasemonkey script, or browser plugin, that loads the keybindings.js code, and looks for the key binding definitions. The declaration could be done in HTML too, which could be found by the plugin and tied into the system. What do you think?

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.

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...

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.

I've been talking about event driven application design in JavaScript in January last year and inspired Caridy Patiño to write his Bubbling Library based on these ideas.

Caridy now upped the ante a bit by talking about decoupling using the bubbling library over on the YUI blog.

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.

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:

Then he created the player:

First strategy was to create an Image object for each frame and render it on a canvas element using drawImage(). That worked fine and performance was nice (although Opera used a lot of CPU), but I figured I'd try just using a regular image tag and just change the src property to another data:uri each frame. The change was barely noticeably in Firefox and Safari and it ran a bit better in Opera, so I lost the canvas and stuck with plain old images.

Now, it seems that Firefox will eat up all the memory in the world if you keep throwing new data:uris at the same image tag, which led to another change, so for each frame a new Image object was created and saved for later and as the video played, the previous frame Image was replaced by the new Image object. That seemed to work, but introduced an annoying delay as all these Image objects were created before playing, so I ended up moving the Image creation to actual render cycle where it simply checks if the frame Image has already been created, and if not, creates it.

You can now get going with HTML such as:

There are a couple of tests to play with. It was also pointed out that maybe an animated gif/png would be a choice (without controls), and of course, Flash is still the best choice here, until we get video support in most browsers.