Aza Raskin and the Mozilla Labs team have launched Ubiquity the command line tool that they have been talking about for awhile.
Ubiquity is "experiment into connecting the Web with language in an attempt to find new user interfaces that could make it possible for everyone to do common Web tasks more quickly and easily."
The overall goals of Ubiquity are to explore how best to:
Empower users to control the web browser with language-based instructions. (With search, users type what they want to find. With Ubiquity, they type what they want to do.)
Enable on-demand, user-generated mashups with existing open Web APIs. (In other words, allowing everyone–not just Web developers–to remix the Web so it fits their needs, no matter what page they are on, or what they are doing.)
Use Trust networks and social constructs to balance security with ease of extensibility.
Extend the browser functionality easily.
The screencast explains more:
What is cool about the system, is that it is a platform. If you fancy adding a new command, it is as easy as the following 'date' command:
John has announced the Firebug 1.2 final release. As well as just supporting Firefox 3, there are some quality improvements:
The Script panel (the JavaScript debugger), the Net panel (network monitoring), and Console panel have all seen considerable updates. They're all much more performant and have a huge number of bug fixes.
Specifically the Console panel has seen a number of security improvements. We'll be discussing the specific nature of these changes once everyone has had enough time to upgrade to Firebug 1.2.
Taking in to consideration the above performance points (namely the fact that enabling the Console, Script, or Net panels have the potential to incur a global overhead on all browser tabs) a feature was added to help you minimize your use of the panels in errant tabs.
If you position your mouse over the Firebug icon, in the Firefox tray, a tooltip will pop up telling you two things: The version of Firebug that you're using and which tabs have some Firebug panels enabled in them.
It should be noted that the Firebug will be a gray color if no tabs currently have a Firebug panel enabled at all.
Using the above tooltip you can now go in and selectively disable any panel usage that you are no longer utilizing.
Suspend/Resume Firebug.
Of course, when using the above tooltip (or seeing that the Firebug icon is lit up), you'll just want to suspend all use of Firebug panels straight out without having to poke-around each individual tab.
A new Suspend/Resume menu option has been added that will suspend/resume all active panels. This is a one-click way to keep Firebug in check.
Mozilla just letthecatout of the bag on their new TraceMonkey project. Brendan Eich, Mozilla's CTO, describes it thusly:
I'm extremely pleased to announce the launch of TraceMonkey, an evolution of Firefox's SpiderMonkey JavaScript engine for Firefox 3.1 that uses a new kind of Just-In-Time (JIT) compiler to boost JS performance by an order of magnitude or more. [Emphasis ours.]
There are charts and graphs all over the Web; here's one from Brendan's blog:
As Brendan points out, the benchmarks can be generally quite misleading; the best results are the demos. And, here's a link to Mike "schrep" Schroepfer's blog entry where he put one together in a screencast:
Brendan goes into significant detail on how all of this came about, and notes some key points:
* We have, right now, x86, x86-64, and ARM support in TraceMonkey. This means we are ready for mobile and desktop target platforms out of the box.
* As the performance keeps going up, people will write and transport code that was "too slow" to run in the browser as JS. This means the web can accomodate workloads that right now require a proprietary plugin.
* As we trace more of the DOM and our other native code, we increase the memory-safe codebase that must be trusted not to have an exploitable bug.
* Tracing follows only the hot paths, and builds a trace-tree cache. Cold code never gets traced or JITted, avoiding the memory bloat that whole-method JITs incur. Tracing is mobile-friendly.
The first phase of Ajax has been all about leveraging the existing platforms as much as we can. This announcement is a major signpost towards the second phase: improving the existing platforms. We couldn't be more excited.
Brendan puts it in his own understated way:
JS-driven <canvas> rendering, with toolkits, scene graphs, game logic, etc. all in JS, are one wave of the future that is about to crest.
[This] means that JavaScript is no longer confined by previously-challenging resource of processing power... I fully expect to see more massive projects being written in JavaScript...
The primary thing holding back most extensive Canvas development hasn't been rendering - but the processor limitations of the language (performing the challenging mathematical operations related to vectors, matrices, or collision detection). I expect this area to absolutely explode after the release of Firefox 3.1 as we start to see this work take hold.
Speaking of Canvas and JS, we've got our own little project we've been hacking this year that we can't wait to try this on... way to go, Mozilla!
The video above is a "concept" called Aurora, created by Jesse James Garrett of Adaptive Path. Give it a play and you will see his vision for a very visual immersive, space-age-like environment that is very social.
This isn't about these concepts though. The Mozila Labs folks have a call for participation:
Today we’re calling on industry, higher education and people from around the world to get involved and share their ideas and expertise as we collectively explore and design future directions for the Web.
You don’t have to be a software engineer to get involved, and you don’t have to program. Everyone is welcome to participate. We’re particularly interested in engaging with designers who have not typically been involved with open source projects. And we’re biasing towards broad participation, not finished implementations.
We’re hoping to lower the barrier to participation by providing a forum for surfacing, sharing, and collaborating on new ideas and concepts. Our goal is to bring even more people to the table and provoke thought, facilitate discussion, and inspire future design directions for Firefox, the Mozilla project, and the Web as a whole.
Time to get creative and put on your inventor hat. Maybe your idea can get into Firefox?
With the power of the underlying Mozilla Gecko engine, Pencil turns your excellent Firefox 3 browser into a sketching tool with just a 400-kilobyte installation package.
Pencil will always be free and can run on virtually all platforms that Firefox 3 supports.
Always good to see people using the power of XUL that still has features that I hope to see HTML get.
It has been a busy week for Mozilla. We have seen news across the board of their technology.
First we have the news that Firefox 3 should be available to download on June 17th. They are having a download party to kick things off.
Stuart Parmenter had a proxy post that delves into the world of fonts and text:
When Mozilla developers decided to incorporate the Cairo subsystem and build a new graphics layer from scratch, they also decided to completely rework the system that renders text in the browser.
Text is an incredibly important part of the Web. While graphics, audio, and video are increasingly common, we still spend the majority of our time on the Web just reading stuff. All the words you read in a web browser are rendered using a font which contains a set of glyphs used to form individual letters. For more simple written languages there may be a straightforward one-to-one mapping of characters to glyphs, but for more complex languages, one glyph may represent multiple characters.
Ben is a huge fan (a.k.a. anal) of this type of thing. Fonts and rendering can make a big difference, and the post goes into detail on what is going on in the new Firefox 3 engine. It discusses kerning, ligatures, hinting, font smoothing, anti-aliasing, and more. After reading this post you may want to watch Helvetica the movie!
Then we go to the mobile side, where Aza Raskin has posted concept video on the new touch screen interface that they will be building for Fennec. There is a ton of detail in Aza's writeup including design principles:
Touch. This concept prototype for Firefox mobile (code name Fennec) is being designed for a touch screen. Why not multitouch? Because Firefox should be able to run on the least common denominator of touch devices. Especially for touch-enabled interfaces direct manipulation is key. Along that line of thought, the interface should be operable with a finger. Switching between input methods is time-consuming and annoying, so the user shouldn’t have to switch to a stylus or other secondary form of input. Firefox will work on non-touchscreen devices, but that’s out of scope for this demo.
Large targets are good. The same fingertip that controls the interface takes up between 1/5th to 1/10th of the vertical/horizontal height/width of the mobile touch-screen. In other words, fingers are fat: hitting small targets is like trying to touch-type with your elbow. All actions should be represented by targets that are large enough to be fast, easy, and (at the very least) not aggravating to hit.
Visual Momentum and Physics are compelling. Nothing shouts “sexy!†like pretty animations and a physics engine. Beyond marketing appeal, there is a strong argument that such physicality helps the user build a mental model of the interface, and that interface physics yields consistency. We are wired to track the movement of things and to be able to remember where they’ve gone, as long as they don’t appear and disappear, which doesn’t happen in the real world. Of course, copying every physical metaphors blindly gets you interfaces like the multi-million dollar blunder that was Microsoft Bob, so we need to select our metaphors carefully.
Typing is difficult. This means we want to minimize the amount of keystrokes required to get anywhere or do anything.
Content is king. With restricted screen size, every pixel counts. As much of the screen as possible should always be dedicated to content, not controls or cruft.
Then we move to the server side with a Weave status update that should be shipping with Firefox 3. It includes new features around data types, bookmark sharing, and a Web client view. Check out the Wiki for more details.
CSS isn't really up to the task [of applying advanced visual effects to HTML]. One problem is that CSS isn't good at manipulating structured values like shapes and filter processing stacks; they're cumbersome to write in CSS expression syntax, or else they require new custom CSS syntax (e.g. @-rules), and there's no standard DOM to let scripts manipulate components of these structured values. Another issue is that we should try to avoid duplicating specification and implementation of complex features.
Contrast that with SVG, which long ago dealt with spec'ing out fancy-pants effects in mark-up and interfacing with JavaScript APIs. In fact, Rob ends his piece with a little snubby-snubby to Flash and Silverlight based both on SVG's status as a standard and its nice integration with page markup:
A nice side effect of providing better SVG-HTML integration is that it gives SVG a leg up on the Web. You can't do these effects using Flash or Silverlight, and since they're not standards they probably won't ever be invited to this party.
Kevin Yank has zoomed into the features in the new Firefox 3 RC 1, and explained two subtle ones that can help us as Web developers:
Soft Hyphens
Tucked away in the list of CSS improvements in Firefox 3 is this innocuous-looking feature: “HTML soft hyphens () are now supported.â€
Soft hyphens are one of those obscure gems that HTML has always supported on paper, but that no one has taken any notice of because browser support has been spotty. With the imminent release of Firefox 3, however, soft hyphens will be supported by all major browsers including Internet Explorer, Safari, and Opera.
So, what is a soft hyphen, anyway?
A soft hyphen is a character of text that is usually invisible. It signals a spot in the text (usually in the middle of a long word) where it would be acceptable to break the line with a hyphen.
Here you see it at work:
Inline Blocks
Another obscure-but-useful new feature making its way into Firefox 3 after all the other major browsers support it (mostly) is the inline block. When assigned to an element, a display type of inline-block causes the element to be positioned inline (like a span), but the element’s contents are laid out as if the element were a block.
This feature will come in handy in a number of situations in which the float property is currently being used for lack of a better option.
Firebug 1.2 beta is in the wild. The latest beta of the bug your FF3RC will love features:
Enablement UI
Disable always: when the Firebug UI is not active on any page, the debugger is disabled (minimal overhead)
Instant on: when the Firebug UI is active, HTML, CSS, DOM views activate (minimal overhead)
Script panel user-activation: initially disabled or enabled always
Net panel user-activiation: initially disabled or enabled always
Bug Icon gray unless some page has Script or Net panel activation
No Allowed-sites/Disable for Site: no longer needed. The UI for this feature is being refined; overhead tests have not been completed. We are interested in feedback on this UI change.
Javascript Debugging
Written/cleaned up eval support
Performance on eval better, easier to support. This feature is complete; Bug reports on javascript debugger welcome.
Net Panel
Net timing more accurate
Only real network requests displayed.
Limit for number of requests (configurable in preferences).
Additional columns for: request method, status response + text
Cache tab has expiration time in Net panel
Console
Redesigned to use events/attribute passing.
tests/console/joes-original/test.html mostly passes
Command Line
Redesigned to avoid using evalInSandbox.
tests/console/commandLineObjects.html mostly passes
commandLineAPI functions, ok.
DOM Panel
Works for FF3pre after about 2008041406 (https://bugzilla.mozilla.org/show_bug.cgi?id=425139)
Bug away!
Simon Willison also recently pointed out the command line API that lets you "set a breakpoint at the start of a function with “debug(fn)†and log all calls to it with “monitor(fn)â€."
David Mandelin has posted about Tracehydra, which is the idea that the traced based JIT engine that is being worked on as part of Tamarin could be hooked up to Spidermonkey.
Tracehydra would be the fluffy cloud that translates Spidermonkey bytecode to Tamarin IL (or possibly LIR-the details get confusing fast). (In the interest of reducing confusion slightly, I’ll say that IL stands for intermediate language, and is roughly a synonym for bytecode. TT people often refer to their IL as “Forth†because they based the design on Forth or something, but I know nothing more about Forth than that it involves stacks, so that doesn’t help me.)
Specifically, Tracehydra means using Treehydra to translate the Spidermonkey (SM hereafter) C code that interprets each bytecode into C++ that emits equivalent (to the C) Tamarin IL. So I guess it reduces the problem from translating SM bytecode TT IL to translating SM C cases to TT IL-building code. Put that way, it’s not clear this actually helps, but I think SM bytecode is believed to have complex semantics that would be difficult to code in TT IL by hand, and maybe the C in SM has fewer constructs that are easier to translate. Seems possible, anyway.
David then goes on to digg into Tamarin, which is weak on docs (according to him). He walks through the various pieces of Tamarin and explains the ABC bytecode vs. the IL etc. A very nice read, and maybe Tracehydra will be the first form that we see Tamarin in Firefox?
IE may be the dominant browser on the desktop, but the mobile wars are going strong. WebKit, Opera, and Pocket IE have a lot of users, but Mozilla has been a little weak in the past.
Now though, they have a new Fennec browser that takes the great performance gains in Firefox 3, and makes a mobile oriented version.
Sullivan explained that the Fennec project aims to bring the desktop Firefox user experience to handheld devices but will focus on meeting the unique requirements of mobile computing users. "Our goal on mobile is to embody the principles that have made Firefox so successful on the desktop, but with the recognition that mobile is different—not so much in that it presents some constraints, but in that it enables new types of experiences, and people's interaction with these devices are different than when they're sitting at their desks," he says. "Web compatibility, security, performance, support for rich internet apps will all be key."
I have been curious how it can scale down, just due to the XUL overhead, but it works great.
Much of the Firefox user interface is constructed with XUL, an XML-based user interface description language. This makes Firefox very easy to customize and extend. Mozilla hopes to leverage this advantage to encourage experimentation with new mobile user interface concepts. Developers can augment or reinvent the Fennec user interface by modifying the browser.xul file in the Fennec chrome directory and the associated browser.css file. Additional functionality can be implemented in JavaScript by modifying the browser.js file. Fennec will eventually support a complete extension system like Firefox 3 that developers will be able to use for modifying the browser's behavior and user interface.
"Another exciting thing is that we're providing full support for add-ons," Sullivan notes. "These will fall into three buckets: most add-ons will just work out of the box; some won't make much sense away from a PC; and a whole new class will be created that are going to be new for mobile."
There are other aspects of the Mozilla Mobile initiative that will appeal to developers as well. Mobile software development is hard, and Mozilla could potentially offer a novel approach to simplifying the process. The underlying XUL technology on which the Firefox interface is built can be used independently with a XULRunner runtime to create platform-neutral mobile applications with XML and JavaScript.
