On the back of the first Jetpack announcement, we see new version announced, 0.2 that adds slidebars, jetpack.future, and persistent storage.
Slidebar isn't a spelling mistake, but a slightly different take on the traditional sidebar. Check out Aza in his screencast to see them in action, and wait for the part where he sucks in a playing video and lets you continue to browse the Web elsewhere.
but you have to use another new feature of Jetpack 0.2.... future:
Jetpack is two things at once: it is a platform for experimentation and it is also a solid set of APIs that anyone to easily build new Firefox features. To enable Jetpack to be both stable and — at the same time — to experiment with not-quite-yet-ready features we’ve added the ability to import new features from the “future”.
Slidebars, for example, are still highly experimental. To use them, you need to import them from the future first.
Read more about future in the Jetpack enhancement proposal (JEP) for jetpack.future.
jetpack.future.import("slideBar")
Persistent Storage and Clipboard Support
One of the most requested features in the Jetpack development mailing list was for the ability to persistently store data across restarts.
We’ve added simple storage to the future module. The API is defined in the storage JEP. Using it as simple as:
jetpack.future.import("storage.simple");
var db = jetpack.storage.simple;
var data = {name: "Firefox", twitter: "@firefox"};
db.set( "friend", data );
Kevin Decker has released FireDiff a very cool Firebug extension that tracks changes to the page and CSS.
Firediff implements a change monitor that records all of the changes made by firebug and the application itself to CSS and the DOM. This provides insight into the functionality of the application as well as provide a record of the changes that were required to debug and tweak the page’s display.
The release, which you can find here uses recent features of the latest Firebug 1.4 code. Early days!
We’ve started to see more and more libraries being built to support use cases with Canvas in a 2D context but we really want to take things to the next level and start to allow people to use 3D capabilities as well. Accelerated 3D graphics with the super-fast next-generation JavaScript engines from nearly every web browser vendor means that we’re going to be able to start to see more and more advanced applications written using open web technologies. 3D is a huge part of that story and we’re happy to bring our proposal to the table.
The proposed spec (found in one of vlad’s post on 3D Canvas) is a pretty light wrapper on top of OpenGL ES 2.0, with some changes to support some JavaScript pleasantries. OpenGL ES is a decent starting point, which is why we picked it. OpenGL is supported as part of every major operating system and in it’s being picked up as a standard on mobile devices as well. Compared to the full OpenGL spec, the ES variant is a smaller subset that reflects the reality of what’s being used on the ground and most hardware and software vendors have actually been re-tooling to support OpenGL ES with support for older versions of full OpenGL emulated on top of OpenGL ES. Mixed with the fact that there’s a decent amount of knowledge out there in the industry of how to use OpenGL, we think that this smooths the integration between the current set of OpenGL users and larger web developer community.
And, there is the link back to Vladimir Vuki?evi?, the engineer who did the initial work (and who has been a huge help for Ben and I at Mozilla wrt Canvas and much more).
This is great stuff, and is it is important to clarify that this isn't about 3D virtual worlds, like some people think. This isn't VRML. The iPhone and the Mac are doing really nice 3D effects all the time these days. Close a window in OS X / Vista. Launch and quit Time Machine.
I am also glad to see OpenGL ES instead of yet another attempt at doing the 3D. There are a lot of tools and mindshare around this, and people will build great libraries on top of it I am sure for particular niches (apply some effects etc) and maybe we can get some uplift to CSS itself :) Oh, and i am really glad to see Google involved too!
I also saw Ryan Stewart weighing in and liked some of what he had to say, but was surprised by:
So it’s unfortunate to see that even the browser vendors have given up on moving the open web forward through standards. Whether it’s the WHATWG versus the W3C or the trials and tribulations of actually implementing HTML5, things are very broken and everyone is moving on regardless. I don’t blame any of them, but it doesn’t seem like it’s good for web developers.
Standards groups aren't the place to innovate. Browsers should be creating compelling features, other browsers should copy the good ones, and then we can standardize. XMLHttpRequest wasn't grown in the W3C. The cool CSS ideas that have been implemented in multiple browsers recently weren't either. Browsers need to push more, not less. And, then we need the standards groups to rally and try to turn the -vendor-bar-baz into bar-baz. Giving Web developers more APIs is good for Web developers!
Sometimes you find leftovers of old technology in browsers that blow your mind. One of these "ghost in the machine" problems exists in Firefox: if you use window.sun or function sun() in JavaScript you effectively start the Java VM.
There are a few "magic" properties on Mozilla's DOMWindow interface for supporting LiveConnect that will initialize the Java plugin and all the baggage that comes with it (which, with modern Java plugins, means launching java.exe as a subprocess). Looking up these properties on the window object is all it takes.
Ben and I are excited to be releasing the first concept out of the Mozilla Developer Lab. As you know, we are big believers in the Open Web. Chris Wilson mentioned that many people are still building Web applications on top of browser technology from yester year. What if we built on more leading edge browser technology? As a challenge, we wanted to take on an interesting project that you would normally thing of as a desktop application, and see if it would fly on the Web.
Being developers, why not develop something that we know and use every day. Our code editor. There are great editors out there, and we are partial to many. From Vi and Emacs, to Textmate and IntelliJ IDEA.
We have all seen enhanced textarea and div code editors, and while some have done a great job with them, they often seem to fall down in performance with large files and have strange bugs that make them more of a toy than you would like.
How could we change this? What if we used Canvas? That question lead to our Bespin announcement at Mozilla Labs today. What would our dream editor be like?
Let's get to the meat. To check out Bespin yourself, fire up a browser that supports Canvas, and the text rendering portion of Canvas. We have tested Bespin on Firefox 3+ and WebKit Nightly, which both support the feature. Link over to bespin.mozilla.com and signup.
Once logged in you will see a dashboard view of your projects, and a sample project will be sitting there waiting for you. Navigate into the project and open up one of the files via double click. You will be taken into the code editor itself. Tinker around. Try out the command line at the bottom (try the help command to see what is out there).
Even though this is a tech preview, where the goal was to share it with the community, we wanted to make the editor as solid as possible. It had to scale to a large number of lines and continue to remain very responsive.
Over in the dashboard, you will notice some interesting UI elements. Shrink the width of the file panes and the filenames will be truncated in the middle a la Mac OS X (e.g. Take a file "syntaxhighligher.js" that doesn't have room and becomes "syntax...r.js" instead of a simpler "...ghligher.js"). The open sessions tabs at the bottom can be moved around and as more space is made available, they offer more information and change font size. This is all part of Thunderhead, a very early fun experiment to create a Canvas GUI toolkit. We will blog more about that later.
To see this in action, please check out this video of us showing the tool in action:
It has been a lot of fun building the tool. A lightbulb went off when you see the power of having a tool written in the platform that you write code in all day. You can easily extend and tweak it to your whim. Extensibility has been a core guideline for us. The command line gives us an easy way to add functionality (Ubiquity showed us the way here). Bespin commands look like Ubiquity commands, and we want to fully integrate them. We also made a big use out of custom events as a way to loosely couple code to functionality.
This means that you can write code that listens to editor events and does something new. On the other side of the coin, you can fire of events and the editor will consume them and do the right thing.
If you wanted to add some functionality whenever a new file is loaded into the editor, you would listen for an open success event. Here is an example of us doing just that in our command line object, to tell the user that something has been opened:
We have a lot to share about our experience building Bespin, and we will be posting a lot about them in the future. For now though, we want to hear from you. What do you think? What would you like to see? Have some cool concepts and features? Want to join us hacking on your tool? Have a project that you would like to embed the Bespin editor in? Let us know!
More resources
Check out our main announcement post has a lot more details on the vision and why we are doing this.
If you do any web development, chances are you know checkboxes and radio buttons can have two states: checked and unchecked. But in the case of checkboxes, you may want to indicate to the user that they are half-way between those states, for example when you have a master checkbox above many other checkboxes of singular items. This is now possible on Trunk (Firefox 3.2) thanks to the implementation of the HTML5 "indeterminate" DOM property. All it takes is a bit of script:
Mozilla is big on tinkering--making things your own. They recently released a marketplace for their community to upload its own shirt designs. But because they based it on the Ajax-heavy Zazzle platform, consumers can customize the shirts in a variety of ways. We thought this made for a good opportunity to take a closer look at Zazzle.
Easy Zooming
In the overview page showing different shirt designs, simply mousing over a shirt lets you zoom in on it in a smooth, easy motion.
Clicking into a shirt gives more Ajax goodness, like an alternate zooming interface showing the full-view and the detail simultaneously:
And finally, it has a shirt manipulation interface, though most of the design manipulation occurs on the server, it is sent back without a page reload, as we would expect:
Zazzle is built on the UIZE (pronounced "you-eyes") Ajax framework which we covered briefly in 2006 and have yet to revisit. We're not sure if UIZE is used by anyone but Zazzle, but it's got a pretty nice website, docs, widgets, basic effects, an event system, and an inheritance system. We'll have to give it a closer look!
The event object contains two properties: .clientRects and .boundingClientRect, both of which refer to the result of the associated DOM methods.
In a nutshell, boundingClientRect gives you a single rectangle encompassing the entire area in which a paint operation could've taken place whereas clientRects gives you a number of rectangles, each encompassing an individual area that was drawn.
Today, we are really excited to be able to announce a big personal change. Ben and I are joining forces, full time, for the first time. What are we doing? We are joining Mozilla to create a new group with the charter to create developer tools for the Open Web.
Mozilla is placing a big bet, not only on us, but in the developer tools space.
Why are we doing this? Ben and I are passionate about a couple of things: compelling software and developers. In various roles in the past, we have built tools that attempt to make developers productive. We are huge advocates for the Open Web, yet we feel that tools are lacking on our collective platform. We want to help make a difference.
As we ramp up this new group, we will be looking at the problem and seeing where it makes sense to step in. We are going to be experimenting, and thinking about how to make developers lives better in different ways, so we aren't expecting to see traditional tools come out of this group. Also, we don't want to do this alone. We want to involve the entire community which is one reason that we are so excited to kick off this work at Mozilla. We believe that we have a unique opportunity to put developers first. We can build these tools in the open, with total transparency; the Mozilla way.
We respect the work being done by other vendors, and very much want to work together. We can't wait to reach out early-on in the process, involving companies that believe in the Open Web like we do. Together we can drastically improve productivity, allowing developers to build compelling user experiences.
We are just getting started. As soon as we come up with some ideas, we will be sharing then with you and asking for community participation in various forms. You, the Ajaxian community, have been phenomenal over the years, and we can't wait to do more together.
When I posted about using navigator.geolocation now the only support that I had was via Gears and the ClientLocation API. I wrote the shim to try to get you the W3C API no matter what, and today we have the first implementation in a browser, via Geode.
Geode is the latest project in Mozilla Labs that gives you that API in Firefox. Aza Raskin has a nice Food Finder application that ties it together with local search and maps.
Differences between Geode and Geolocation in Firefox 3.1
Geode and the Geolocation Services in Firefox 3.1 will use the same W3C API for Geolocation, meaning that the same Javascript code will work in both. The still-in-developement Firefox 3.1 version will allow the user to choose a geolocation service provider, which can either be a peripheral device like a GPS, or a web-based service provider like we’ve used in Geode. We’ll be using the feedback we get from Geode, as well as the feedback we see on the upcoming Firefox 3.1 Beta and Fennec Alpha releases, to refine the feature before shipping it in a future Mozilla product release. We’re particularly interested in ensuring that the final implementation is as sensitive to user privacy and choice as possible.
They also got some partners to start playing with this:
To kick off Geode, two other websites have started innovating with location. Both require accounts before you can try them out.
Pownce is a service that makes it easy to send stuff (music, photos, events, and messages) to your friends. Adding the power of location — where you are when you uploaded a photo or sent a message — paints a compelling picture that helps you discover friends and activities around you. Head there to see it in action (you’ll have to sign up for an account).
Yahoo! Fire Eagle is a service that acts as a broker for your location, creating a single place where any web service, from any device can get access to your last updated location. Fire Eagle integrates with Geode so that you’ll never have to manually enter your location again. Once you have a Fire Eagle account, you can see Geode working here.
There are a substantial number of iPhone apps that tie into the builtin native components such as the camera.
Brad Lassey has been hacking on Fennec (the Mozilla mobile browser) as well as Firefox itself to integrate with camera phones and Webcams alike:
I wrapped a video tag, image and a few buttons in xbl and bound it to <input type=”camera” />. When a user hits a website using this tag, he or she currently will see a live video preview and a “take photo” button. When the user clicks the button, the photo is grabbed from the camera and shown to the user in the image element. The image element and video element are in a deck element so only one is shown at a time. After the photo is taken, there is a button that reads “Take another photo,” in case the user doesn’t like the one they just took. Once the user is satisfied, this element works like any other form element and the file can be uploaded to a web service.
After talking to a few people this should actually be bound to <input type=”file” accept=”image/png”/>. Also, it needs some UI design both for what it looks like in content and for a configuration dialog. Finally, we’ll need to think about security and make sure no one can snap a photo of you when you’re not looking your best.
I kinda like having an input type="camera" myself, to be more explicit. It would be cool if you can get access to the image as data (e.g. the value is data:......). I love it.
