Tuesday, July 7th, 2009

Open Web Tools Directory

Category: Canvas, Mozilla, Utility

>

Over at the Mozilla Labs blog, we just launched an “Open Web Tools Directory”. Running Ajaxian for the past few years, we’ve discussed a legion of developer tools of all shapes and sizes, but there are so many we’ve quickly lost track of all that’s available.

With the Tools Directory, we hope to provide a central location where the community can track what’s happening in the tools space. At Mozilla, we release early and often in the open-source tradition, so what we’ve launched is the first step in the journey. We’d love to get your feedback in this early stage as we evolve the directory.

We’ve got nearly 70 tools in the database so far, but that’s just a small fraction of the hundreds of tools out there. Would you help us out and tell us about your favorite tool(s)? (We’re still working out infrastructure, but eventually we’ll have a way to own a tool and keep its metadata up-to-date. And our sincere thanks to Laura Thomson who worked very hard to help us get the infrastructure and back-end for the directory ready.)

Dion and I both have some corporate IT experience under the belt, and because of that we just couldn’t bring ourselves to write yet another typical table-based database CRUD app; hence, the space theme and gratuitous canvas-based UI. So the Tools Directory is our second canvas-centric web application released this year, but we promise to use the DOM API more for the next one. ;-)

Implementation Details

We knew we wanted to do some kind of space-themed design for the directory involving images for the tools flying around, but we weren’t sure how much performance we could get out of canvas. Some of our previous experiments have shown that we can repaint a large canvas many times per second, but how many individual images could we paint per frame full-screen and still get decent perf? This experiment, representative of several we whipped up, was somewhat promising: we’re able to draw and scale about 700 images about 20 times per second.

Based on these results, we thought we could get away with a “warp-in” effect flying in maybe one or two hundred images and get decent frame rates. To make the effect somewhat predictable, we based the animation effect on clock time with the result that it drops frames rather than alters the speed of animation when the browser can’t keep up with the requested workload.

Unfortunately, once we implemented the effect, we discovered that we started to get choppy performance with only forty or so images (all of our tests are using recent-model MacBook Pros running OS X and Firefox 3.5 or Safari 4). Our test images were 32×32, but once we switched to 128×128 images, performance suffered dramatically. We haven’t looked into it further, but the degradation may be linear according to image size.

We had always planned on caching aggressively, but these results indicated just how much caching we’d have to do: lots.

So we implemented the directory in such a way that at any time, we can cache the state of the canvas animation and exclude arbitrary elements from the cache. This is how we implement various features like selecting a subset of the items and moving them to the center of the screen when you search the directory, for example:

We also added a staged introductory fly-in effect where only a subset of the tools fly in and we cache the screen state and then fly in others, keeping the overall number of items to animate low–but the effect is presently disabled. Look for it in a future release as we expand the catalog of tools further. We’ll have to work something out because flying just 70 items at once produces choppy animations on the fastest hardware using the fastest browsers available.

For the time-based animations, we implemented a simple timing framework. We wanted to grab an off-the-shelf library, but of the half-dozen JS animation frameworks we analyzed, all of them assumed we were animating DOM nodes or changing single object properties, which made their use somewhat obtuse. We really just wanted a simple callback for each frame in the animation. (We also grabbed the GX framework‘s easy-to-grab ports of Robert Penner’s easing equations.) We’d love to replace our timing framework with something more sophisticated and actively maintained; let us know if you’ve got something we can use. In particular, we’d like a framework that intelligently reports the minimum resolution required by all currently scheduled timing jobs.

On that note, the other interesting bit for us was working out how often to repaint the canvas. After experimentation, we settled on using setInterval to repaint the scene every 20 ms. This has the unfortunate side effect of hitting the CPU rather hard during the animations and so forth.

Future

We’re really excited to add a bunch of community features to the directory. We want folks to vote on tools, comment on them, submit and maintain them, and so forth. But in addition to that, we want to enable sub-universes; e.g., we want to track plug-ins for tools like Prototype, jQuery or Firebug so you can explore those universes within the framework of the overall directory. And if there’s interest, we’d love to make it even more general and release the “universe browser” framework for anyone that wants to use this interface to explore taxonomies.

On a technical note, we’re really keen to see how the DOM would perform relative to canvas, and how 3D approaches (e.g., using Mozilla Firefox and Google Chrome’s 3D support) work out. Oh, and we’re going to release an accessible, non-graphical version of the directory soon as well.

Please tell us what you think, and we hope all of us will be able to make use of this framework to help keep track of the exploding universe of web developer tools. Thanks!

Related Content:

15 Comments »

Comments feed TrackBack URI

if I resize the window, every icon disappears – Firefox 3.5
nice tool in any case

Comment by WebReflection — July 7, 2009

Yeah, yeah–I know. I need to fix that. :-)

Comment by Ben Galbraith — July 7, 2009

It’s a nice technology demo, but to me this demonstrates more why you shouldn’t use canvas to build something like this than why you should. The app would have been much more useful it it had been a plain old boring table-based business app. Not as cool, that’s true, but a lot more useful.

Comment by Joeri — July 7, 2009

Potentially: The place to go to when searching for an Open Web development tool. Great! I really hope this Mozilla initiative succeeds.

Comment by andysky — July 7, 2009

I can see the canvas becoming the new blink tag…

Were is the accessible version at least?

Comment by BenRowe — July 7, 2009

Great tool/collection indeed. However it looks like usability was not taken into account at all. Even text selection in the input box does not work. Not to say that the app is not usable without a mouse…
Is this something you could work on?

Comment by SergeyIlinsky — July 7, 2009

This is a fun experiment. I think some people miss the point of a beta/early releases which is to gather feedback and refine the product before you go live and waste a whole load of time prematurely optimizing and making something accessible when you don’t even know how people use it.

It would be great to see it emulate a heat map more, so similar tools are grouped together and their size is relative to the amount of attention they get…

Comment by simon000666 — July 7, 2009

Nice gadget, but honestly a simple HTML definition list of tools would load more quickly and would be easier to use.

Comment by WillPeavy — July 7, 2009

caused google chrome to spin the CPU at 100% with a blank screen for several minutes until I killed the tab.

Comment by JonathanLeech — July 7, 2009

Hey, we pushed out a simple HTML version here: http://tools.mozilla.com/simple.html

Comment by Ben Galbraith — July 7, 2009

Start again in Flash or O3D.

Comment by Darkimmortal — July 7, 2009

@Darkimmortal: Actually, we’d love to see other front-ends to the data.

Comment by Ben Galbraith — July 7, 2009

This looks awesome! Congrats on getting it out.

Comment by Brad Neuberg — July 7, 2009

Thue UI would be more obsfucated if you added Brownian motion. That was the goal, right? :)

Comment by thnkfstr — July 7, 2009

I agree with many of the commenters about problems with this site, with Joeri having the best synopsis, in my mind. This is a cute experiment with Canvas, but I hope you’ll move this experiment to something for which it is more deserving.

A directory, by its definition, is an ordering of items that exists to aid people in finding those items. This is not such a thing. This is more of a note pad. Perhaps you should call it the Open Web Tools Doodle? :)

It confounds me that, for example, I have no way of knowing what all these tools are simply by their logos. I have to hover on each one to see what the name, then click it to see what it does, then click elsewhere on the page to escape out. (How about at least an “escape” key to lose the lightbox?)

Imagine a phone book where you had to look at each and every name to see if that was the person you were trying to find, rather than knowing you could look up something alphabetically.

Worse yet: if I visit a project homepage, then hit the back button to go back to the “space”, everything is in a new place. I have no idea which items I’ve already looked at and which ones I haven’t, and need to start over. A huge waste of time.

I like the UI experiments, but it has taken a useful tool and turned it into an unnavigable demonstration of “Wheee! Look what I can do!” Hopefully future iterations will find a way to improve on these aspects, and maybe do away with it altogether for this particular use case.

Comment by kswartz — July 9, 2009

Leave a comment

You must be logged in to post a comment.