Archive for the ‘Mozilla Labs’ Category

As part of the process of converting the Jetpack project from a small Mozilla Labs effort building experimental prototypes to a full-scale Mozilla project making real products, project participants have begun to blog about releases, conferences, etc. in the Mozilla Add-ons Blog. Check out that blog for the latest news about the project!

Go to Source

One thing that has been requested over the years from Thunderbird users is the ability to mute an individual email thread, so that once you’ve decided you don’t care about a particular conversation, you don’t have to wade through more messages in it as they continue to arrive.

A Prototype

In order to provide relief to folks who don’t mind using something with rough edges, as well as to give interested developers a place to experiment, we’ve created a Mute Thread add-on prototype.

Mute Thread currently adds Ignore Thread and Ignore Sub-Thread menu entries to the Message menu for email messages, like Thunderbird already does with newsgroup messages.

Threads that have been ignored in the past can be reviewed using the View > Threads > Ignored Threads menu option.

What’s Next

We have ideas about how Mute Thread’s user-experience could evolve to be significantly better. But for that to happen, Mute Thread needs a developer or two to lead that charge. If you think this might be you, please let us know!

For installation, more information and a screen cast explaining the add-on, check out the Mute Thread project page.

Go to Source

Since Mozilla Labs launched the Concept Series with an open call for participation we’ve had thousands of people join in, share ideas and develop concepts around Firefox, the Mozilla projects and the Open Web as a whole.

In response to our open call Billy May, in early 2009, produced a throw-away concept for an “Open Web Concept Phone”. Working directly off of that community feedback, Billy has since finished the exploration with his concept “Seabird”.

The following write-up is by Billy May and explores what an Open Web phone might look like:

Concept Series: Seabird

Also available in 3D on YouTube (cross-eyed/red-cyan/etc):

Overview

The Mozilla Seabird, part of the Mozilla Labs’ Concept Series, is an experiment in how users might interact with their mobile content as devices and technology advances. Drawing on insights culled from the Mozilla community through the project’s blog, a focus quickly developed around frustrating physical interactions. While mobile CPUs, connectivity and development platforms begin approaching that of desktops, the lagging ability to efficiently input information has grown ever more pronounced.

Seabird Concept 1

Interaction

The Seabird, then, introduces a few possibilities into how user interaction might evolve with the advancing motion capture and projector driven innovation in the market. First out, the Seabird imagines how a multiple use dongle might augment the crowded gestural interface with greater precision and direct manipulation of content in 3D space.

Seabird Concept 2

Pico Projector

With mobile phone companies such as Samsung, LG and Motorola moving towards display applications for projectors, the technology remains open for expanding user interaction and input at the same time. The Seabird, on just a flat surface, enables netbook-quality interaction by working with the projector’s angular distortion to deliver interface, rather than content. With the benefit of a dock, each projector works independently and delivers laptop levels of efficiency.

Seabird Concept 3

Design

The form development took its cues from various aerodynamic, avian and decidedly feminine forms. Its erect posture intends a sense of poise while its supine conformity to the hand reconciles that with the user’s desire for digital control. The curvature of the back also serves a functional role in elevating the projector lens elements when lying flat.

Seabird Concept 4

Seabird is a community-driven exploration and does not mean that Mozilla has plans to produce an OS or hardware at the moment. Find out more about Mozilla Firefox for Mobile here.

Seabird Concept 5

Download pictures in high resolution.

FAQ

Who created this project?

Seabird was created by Billy May, a Mozilla Labs community member who in early 2009 created an initial vision of what an Open Web mobile phone could look like. Seabird is Billy’s followup project in which he incorporated the feedback he received from the wider community on his first throw-away concept. To learn more about Billy May, please visit his homepage.

How does this relate to Mozilla / Mozilla Labs?

Billy is a community member in the Mozilla Labs community and created Seabird in his spare time. Seabird is not a Mozilla or Mozilla Labs project but part of the Mozilla Labs Concept Series. The Concept Series provides a place for the wider community to create and collaborate on projects which push the boundaries of the Web and the browser.

Does Mozilla have plans to produce a mobile phone?

No. Mozilla produces Firefox for Mobile, the popular Firefox browser for mobile phone systems such as Nokia Maemo and Android. You can find out more about Mozilla Firefox for Mobile here.

Go to Source

There have been a number of questions about Zaphod and Narcissus.  Or perhaps just the one major question:

“Seems cool.  Why should I use this?”

For day to day browsing, Narcissus does not offer any real advantages over SpiderMonkey.  However, Narcissus is an ideal tool for developing new ideas for the JavaScript language itself.

What features should we add to JavaScript?  What should the syntax/semantics be?  What practical issues will come up that we have not considered so far?  With Narcissus and Zaphod, we can more easily answer these questions.

In programming language (PL) research, we like to write up fancy evaluation rules containing lots of Greek letters. Unfortunately, these rules tend to be inscrutable to anyone who isn’t a PL researcher. Even for PL researchers, there is something unsatisfying about seeing a bunch of rules on a piece of paper.

We want to be able to try our ideas out with a real implementation — kick the tires, so to speak. Also, we want to share our ideas as widely as we can.  This way, we can get feedback from programmers who experiment with our design.

Unfortunately, this usually means editing a sizable, constantly shifting C++ code base. Anyone who wants to test out our ideas has to build the browser from source, which can be a daunting task.

With Narcissus JavaScript, we have another alternative.  Narcissus is both a simpler code base, and also much less affected by the changing browser code base.  Once we have made our changes, we can easily distribute the JavaScript files and let others play around with the new feature.

But Narcissus does not by itself integrate smoothly with the browser. That is where Zaphod comes in.

Zaphod looks for scripts with a tag of “application/narcissus” (which SpiderMonkey will ignore) and parses those scripts with Narcissus.  This setup allows us to demonstrate a few examples using the new feature.  Here are a few simple pages using this technique. Using this, you can show some examples of how your new feature could be used.

But we might also want to see how the implementation would work on a pre-existing page. Click on the mozilla icon in the bottom right corner and Narcissus will be set as the default JavaScript interpreter. After experimenting, click on the icon again and SpiderMonkey will be reset as your JS implementation.

Zaphod/Narcissus cannot yet handle some of the more JavaScript-heavy pages, but it can handle enough to be a valuable research tool for JavaScript language hackers.  I hope you enjoy.  And if you use it for some cool experiments, let me know!

Go to Source

Today we are launching Zaphod, an addon for integrating the Narcissus JavaScript engine into Firefox 4.

Narcissus is neither as fast nor as feature-rich as SpiderMonkey, BUT it is substantially easier to read, understand, and (critically) modify.  If you have a new feature idea, Narcissus is an ideal tool.  With the Zaphod addon, you can also integrate Narcissus into the browser as your JS engine in order to do some real meaningful tests.  Also, since your changes will be separate from the browser code base, you can more easily share your ideas with others.

Zaphod will process any script tag with a type of “application/narcissus” using the Narcissus engine.  Since SpiderMonkey will ignore script tags of an unknown type, it won’t interfere with Narcissus.  Also, you can specify the script type of the page as Narcissus with a meta tag:

<meta http-equiv=”Content-Script-Type” content=”application/narcissus” />

Doing so will cause Narcissus to execute the various on* listeners specified for different elements.  (Unfortunately, SpiderMonkey will also execute them, which may or may not cause issues).

However, Zaphod also provides an additional alternative.  Click on the Mozilla icon in the bottom right of your browser window, and it will disable SpiderMonkey and use Narcissus for parsing all JavaScript on any page you visit.After you are done experimenting, click on the icon again and SpiderMonkey will be reset to your JavaScript engine.

At the moment, Zaphod does not work well with the more JavaScript-heavy sites like GMail, but we have several examples available for experimentation.  Enjoy!

Go to Source

We are excited to present to you the latest initiative from Mozilla Labs: Gaming.  Mozilla Labs Gaming is all about games built, delivered and played on the Open Web and the browser.  We want to explore the wider set of technologies which make immersive gaming on the Open Web possible. We invite the wider community to play with cool, new tech and aim to help establish the Open Web as the platform for gaming across all your Internet connected devices.

Modern Open Web technologies introduced a complete stack of technologies such as Open Video, audio, WebGL, touch events, device orientation, geo location, and fast JavaScript engines which make it possible to build complex (and not so complex) games on the Web.  With these technologies being delivered through modern browsers today, the time is ripe for pushing the platform.  And what better way than through games?  Traditionally games and game developers have been at the forefront of technology, often pushing the boundaries of what was thought possible.

Game On 2010 Competition

To kick off this initiative in style Mozilla Labs Gaming is going to launch our first ever international gaming competition: Game On 2010. This competition will be open to all developers interested in creating awesome games using the latest in Open Web technologies. Stay tuned to the Mozilla Labs Gaming blog and follow us on Twitter for all the details!

Go to Source

In the realm of mailnews, there are a few parts of the code that don’t really get all the attention they deserve. One of them is the compose window.

> jcranmer: libmime and compose are pretty much the two areas that I refuse to do research in
> bwinton: jcranmer: That’s a pretty good policy

The compose window actually involves different pieces of software: one of them is responsible for assembling the message, and passing it to the sending logic. The other one is the actual composition UI, which includes a whole bunch of dialogs (e.g. inserting an image, inserting a link), as well as the central component, called the editor (the big blank area where you type your message). Different factors can explain the lack of activity in that part of the Thunderbird code:

  • editor is notoriously hard to grasp – this is a vast, ancient piece of software, that didn’t quite move on as the rest of the gecko core kept improving (although this has been changing recently, thanks to Ehsan’s work),
  • the assembling and sending logic is all-C++, which makes it hard for extension authors to interact with us, and for would-be contributors to help us,
  • the composition UI involves a lot of (very old) files, most of which we cannot maintain, because
  • Mozilla Messaging is extremely low on resources.

We’re currently exploring ways to relieve the pressure, and move on to a saner design for us. I’ve been working on an experiment that aims at tackling these pain points. It basically consists in replacing the standard XUL compose window with a tab written in XHTML that integrates CKEditor, and doing all the composition process in JS, upto the actual send that takes places in C++.

The potential benefits are as follows.

  • We’d be able to move to a more maintainable architecture. Having the compose code written in JS would certainly enable us to do much more, and be much more extensible.
  • We’d pave the way for having a pluggable editor. Right now, the code is assuming that the only part that sends messages is the compose window. Other people might want to send messages too (Thunderbird Air is one of them).
  • We’d defer the maintainance burden of the composition UI – the insert image dialog, for instance – to a third-party. This means more bugfixing, more active development, from a project that is Thunderbird-friendly to boot. We’re not doing any active development on these anyway…
  • We’ll certainly introduce tons of bugs. However, fixing bugs in CKEditor certainly sounds more doable than fixing bugs in the C++ editor components.
  • We’d be able to attract more contributors: unless you’re mentally insane, you don’t want to hack XUL and C++ components — however, fixing a whole bunch of Javascript sounds more reasonable.
  • We’d finally introduce the much-wanted “compose in a tab” feature.

This experiment has barely reached the point where it starts being actually usable. However, I figured out I might as well share it with the community so that we can gather initial feedback.

Some disclaimers apply.

  1. That extension actually requires Contacts for the autocomplete (a nice side-effect is that you can autocomplete more than two addresses for the same contact, ha!).
  2. This extension is an experiment. There’s a huge list of things it doesn’t do. Right now, it barely allows you to reply, forward, and edit/save drafts. It doesn’t take your preferences into account, it only sends html, not mixed mime emails. It has bugs. Lots of them.
  3. To make sure this works properly, you need to ensure in Tools > Accounts settings that for each of your accounts, in the “Composition and addressing” section, “Compose messages using HTML” is actually checked. Otherwise, you will send HTML markup as plain/text, which is usually a bad idea.
  4. This release targets Thunderbird 3.1. Because patches that enhance interaction between this new editor and the Thunderbird core will have to wait for 3.2, you will see a lot of errors in the Error Console.
  5. Support will be scarce. I am not a Mozilla Messaging employee, and I’m doing this on my spare time. So please be patient, check out the list of missing features on the GitHub Wiki, and don’t report a ton of bugs: I’m probably aware of them already :-) .

Here’s a screencast:

Compose in a tab from Mozilla Messaging on Vimeo.

Download now!

This project is tracked on GitHub, so you can follow me over there. I’ll be posting regular updates regarding this project and others on my personal blog.

I’m looking forward to hearing your thoughts on this!

Jonathan (:protz)

Go to Source

The Latest Study

While previous Test Pilot studies (e.g. the Firefox Main Window, Menu Item Usage, and Tab Switch studies) have largely focused on user experience and usage data, the Test Pilot extension is flexible enough to capture a wide range of other data related to the Firefox browser. The ‘About:Firefox’ Study is a 1-day study implemented to record configuration and performance information for our product and engineering teams.

The study will take a snapshot of memory use statistics, plug-in information, graphics card configuration, and modified preferences (information that can be viewed in ‘about:support’ and ‘about:memory’). As always, we are careful to avoid collecting any sensitive or personally identifiable information. The ‘About:Firefox’ Study will only capture information on a pre-defined set of preferences; we’ve made sure to blacklist any preferences that might contain sensitive data, such as homepage settings.

By submitting this data, you will help our product and engineering teams prioritize development efforts and create a more efficient browser!

Test Champion: Christopher Jung, Data Analyst, Mozilla Metrics.
Test Duration: 1 day.
Test Version: Firefox 3.6.x and Firefox 4 Beta

Privacy

Security and privacy are priorities for Mozilla, especially when dealing with user data. Test Pilot privacy settings give users control over their data – these privacy settings include:

  • Participants’ data will be transmitted to Mozilla only when they take all of the following actions:
    * Join the Firefox 4 Beta program by downloading the beta with the Feedback Add-On.
    * Submit data when the test is finished. Participants will be able to review all data before choosing whether or not to submit it.

  • Test data will be stored anonymously and in aggregate. None of it will be publicly associated with any personally identifiable information.
  • Participants can quit a Test Pilot study before they submit any test data.
  • Participants can opt-out from all user studies or disable the Feedback Add-On itself at any time. Learn more.

Get Involved!

  • If you are testing Firefox 4 Beta, the Feedback Add-On will notify you before the study starts, at which point you can view a detailed study description and choose to opt-out of the study if you wish. For more information on how Test Pilot in Firefox 4 beta works, please see the “How it Will Work” section here .
  • If you are not running Firefox 4 Beta, what are you waiting for? We invite you to get on the latest beta to participate in this study. Help test the future of Firefox by downloading the latest Firefox 4 Beta!
  • And of course, please share your questions and suggestions in the Test Pilot discussion group or on Twitter.

Go to Source

Today, we’re announcing that the Mozilla Labs project codenamed “Bespin” is now called Mozilla Skywriter. It remains a Labs experiment to see how great coding in the browser can be by making a powerful, customizable HTML5 text editor. We’re also announcing a move to GitHub.

We’ve had many compliments and complaints about the “Bespin” codename ever since we first introduced the project. You can’t please everyone, especially when it comes to naming. The Bespin codename, derived from the awesome “cloud city” in The Empire Strikes Back, was a fun name to use for an editor that enables “coding in the cloud”.

Since the initial release in February 2009, the Bespin has come a long way. The project has changed focus and expanded its reach. The “Bespin Embedded” releases have been showing up more and more including several entries in the recent “Node Knockout” competition: Nodify, Inflatable Churn, and Wrath. Other recent development environments on the web have also chosen to use Bespin, including ShiftEdit, jGate and Mozilla’s own Add-On Builder (aka FlightDeck).

As we approach a 1.0 release, it was clear that it was time to shed Bespin’s code name and give it a real, lasting project name. We’re happy to announce that that name is Mozilla Skywriter. I think that Mozilla Skywriter fits the “coding in the cloud” theme very well indeed.

Skywriter is becoming an end-to-end JavaScript-based system. Camilo Aguilar, a new contributor to the project, has been working on porting “dryice”, our build tool, to node.js. Once that’s done, we’ll be creating a XULRunner-based desktop version of Skywriter and a new customizable server version based on node.js. It’s actually pretty amazing how many different uses for our editor we’ll be able to target with a single codebase.

Many people who have worked on Skywriter have expressed a desire to fork it on GitHub. There have been unofficial mirrors and plenty of people installing Mercurial just to use Bespin. In order to make things easier for our community, we’re moving the official repository for Skywriter over to GitHub: http://github.com/mozilla/skywriter.

A note about the repositories: that shiny new repository holds the “all JavaScript” version of Skywriter. As I write this, that repository needs a lot of work (in other words, it’s broken!). All of the “bespin” names have changed to “skywriter” and the build tooling is still in the process of being rebuilt. The existing bespinclient repository remains available for people wanting to work with something that works today. That repository is effectively a branch of the code prior to the start of the JavaScript work. For the most part, we should be able to migrate changes made to that repository over to the new Skywriter repository pretty easily. We’re just changing the tooling to JavaScript, we’re not really changing Bespin’s core plugins at all.

One final note about the Bespin to Skywriter transition: the Bespin name appears in many places and it will take some time to fully migrate over. The Mozilla Skywriter home page will always have up to date links to project resources and is the best place to look if you’re having trouble finding something.

You can follow the Skywriter project (MozSkywriter) on Twitter and ask us questions in #skywriter on irc.mozilla.org.

Finally, a big thanks to Julian Viereck who is off to university in Zürich. Julian has been a huge help to the Skywriter project since the beginning and we wish him good luck in the coming years!

Kevin Dangoor on behalf of the Mozilla Skywriter team

Go to Source


By Jan Dittrich, João Menezes, Ryan Bubinski, Zach Williams

Key Learnings – Status Quo and Gaps

Team 1 sent out a questionnaire form to all those who had participated in any Mozilla Labs Design Challenges. Thirty-seven past participants answered – thanks to all of them for supporting us!

Many of the participants had either a design (14) or Computer Science (10) academic background. In analyzing our outreach we had some interesting findings: The majority of participants found out about the Challenges through the Mozilla Labs website, others found out through blogs, news websites, or through their university. Though Twitter is supposed to be a popular and widely used service among designers or programmers, only 3 got to know about the challenge via twitter!

The majority of participants valued video as an efficient medium of explaining the Design Challenge brief, and almost everybody was satisfied with the information they found on the Mozilla Labs website concerning the Challenge.

93% felt they received good support from Mozilla. When asked about the evaluation of the submitted designs, 73% found the evaluation to be transparent and fair. Those who felt otherwise noted an inconsistency in judges providing feedback, while others expressed concerns on the voting system for submitted designs being gamed by participants recruiting friends to vote for particular submissions.

Since work in UX covers a lot of different topics we were interested if people worked in teams – less than a third did so which means that those who did the work alone are the majority but teamwork is nevertheless a common way of work that needs to be considered in our concepts.

As it would be great if people would carry on with their involvement in mozilla projects, we asked if they carried on with their work on the designs after the callenge. One third did this in one or the other way. Some tried to implement an extension while others said that the ideas they developed were integrated in other designs later.

When asked whether they would be interested in participating in future Design Challenges, 89% responded positively, and 84% responded they would recommend participation to their friends or colleagues.

The last point to talk about is a very important one: What were the motivations of the participants?
The most common answer (several could be given) was “furthering personal knowledge” (87%), followed by “Recognition” (56%). Analysing coherences in our data we found out that Resume-Building was more common among design students than among the ones with other academic backgrounds.

Go to Source

Special Offers
Blogroll
Categories
Pages
Tags