Editing Webmonkey.com in Thimble. Image: Screenshot/Webmonkey

Mozilla Thimble is a new web-based code editor, part of the company’s recently unveiled “Webmakers” project. Thimble is designed to give novice webmakers an easy-to-use online tool to quickly build and share webpages.

You can check out Thimble over at the new Mozilla Thimble website. Keep in mind that Mozilla hasn’t formally launched Thimble; the company is still testing, fixing bugs and iterating the app.

Thimble is slightly different than other online code editors you may have tried, putting the emphasis on teaching HTML to newcomers rather than catering to advanced users. Thimble offers side-by-side code editor and code output panels which help new users see immediate results. Type an <h1> and you’ll immediately see a headline. The instant feedback is not only helpful for spotting and fixing errors, but encouraging for those just starting out since you can see what you’ve created right away.

Thimble is very purposefully not aimed at veteran HTML junkies, but for those just learning how to write HTML — which is the focus of the Webmakers project — Thimble is one of the friendliest, easiest-to-use code editors we’ve seen.

Thimble can also load pre-made project templates to help users get started with some content that’s ready to build on. Currently the featured projects section of the Thimble homepage is still awaiting content, but among the coming projects is a tutorial on editing and creating your own Tumblr theme, as well as others from Mozilla’s various Webmaker partners.

To help new users get their Thimble-created projects on the web Mozilla has also bundled a publishing function directly into the editor. Once you’ve got your Thimble page looking the way you’d like it, just hit the “Publish” button and Thimble will output and host your page, offering up a URL to share with friends and another to edit your page if there’s something you need to change.

Mozilla Webmakers Summer Code Party, coming soon.

Mozilla has kicked off a new effort to do something that’s very near and dear to Webmonkey’s heart — helping people create cool stuff on the web. Mozilla Webmaker, as the new initiative is known, wants to create “a new generation of webmakers, and a more web literate world.”

Mark Surman, Mozilla’s Executive Director, calls web literacy “the world’s second language,” and goes on to say Mozilla believes web literacy is “a vital 21st century skill — as important as reading, writing and arithmetic.”

To help bring that literacy to more people around the world Mozilla’s Webmaker will offer a variety of different things to try, each aimed at different interests:

• 1) Tools. Authoring tools and software, designed and built with our community. From supercharging web video with Popcorn, to remixing with Hackasaurus, to making your own web pages with Thimble.
• 2) Projects. Practical starter projects, how-tos and recipes, designed to help people at all levels make something amazing with the web. From tweaking your blog template to building apps that change the world.
• 3) Community. Bringing people with diverse skills and backgrounds together. Teachers, filmmakers, journalists, youth. From web ninjas to newbies. All making and learning together at events, meet-ups and hack jams everywhere.

Webmaker isn’t just Mozilla, either; the company has partnered with the likes of Tumblr, Creative Commons, Code for America, and dozens of others.

To get things started, Mozilla will kick off what it calls a “Summer Code Party” on June 23. And yes, it sounds a lot like Google’s Summer of Code, but with a focus on building the open web. Head over to the Webmaker site to search for something near you or start your own event.

For more info about Summer Code Party and other aspects of the Webmaker initiative head over to the new site, or check out the intro video below.

[Update: Several readers have asked about Thimble, mentioned in the Mozilla quote above. A Mozilla spokeperson tells Webmonkey, "Mozilla Thimble is the name of a web app we're building that provides a live side-by-side code editor for webmakers -- code on the left, live preview on the right." Thimble will also provide error checking and code tips find and fix mistakes quickly. Mozilla says the goal is to "give webmakers a tool to build and share web pages and also allows them to load in our pre-made project templates with guided content." Mozilla Thimble will launch as a beta in early June, in time for the Summer Code Party campaign.]

A coalition of 30 technology companies hopes to turn the web into a competitive platform for building mobile applications. They have launched a Core Mobile Web Platform (coremob) community group through the W3C to provide a venue for collaborating on next-generation mobile web standards.

Facebook and Mozilla are among the leading members of the group. In an announcement today, Facebook discussed its motivations for participating. The social networking company says users who access Facebook through the mobile website outnumber the collective audience of all Facebook’s native mobile applications.

Facebook consequently wants to ensure its mobile website matches the quality of the experience users get from the native applications. In order to make that possible, open web standards will have to evolve to offer tighter device integration.

Mozilla has been pursuing that goal with its WebAPI project. That has introduced new JavaScript APIs allowing web content to access underlying hardware components and platform functionality, such as the cameras and cellular radio. As we recently reported, Mozilla is using those new APIs in the Open Web Devices (OWD) platform, a mobile operating system that is based on the organization’s Boot2Gecko project.

Mozilla is also working through W3C to turn the APIs into open standards so they can be supported by other browser vendors. The coremob community group will provide a means for mobile web stakeholders to discuss their technical requirements and help shape the emerging standards.

Facebook also announced the release of Ringmark, a test suite for evaluating the capabilities of mobile web browsers. The tests will help developers make informed decisions about what features they can safely use in various mobile web environments. Facebook hopes such information will help developers contend with the highly fragmented mobile web browser landscape.

The Core Mobile Web Platform community group has announced Ringmark, a test suite for evaluating the capabilities of mobile Web browsers.

The tests consist of two separate “rings” which represent sets of standard web features. The inner ring focuses on fundamentals like support for HTML video, native JSON parsing, CSS animation, and the Canvas element. The second ring includes a broader feature set, such as fullscreen support, touch events, and the device orientation APIs. I ran the test suite on an iPhone 4S, which passed all of the tests in the first ring and 229 of the 306 tests in the second ring.

In addition to Mozilla and Facebook, the coremob community group also includes major mobile network operators, hardware manufacturers, mobile platform vendors, and other web companies. The lineup includes AT&T, Verizon, Samsung, HTC, Nokia, Intel, Microsoft, Opera, Adobe, Netflix, Zynga, Sencha, among others. Conspicuously absent from the list: Apple and Google.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Mozilla announced today that it has partnered with mobile network operator Telefónica to deliver a complete mobile operating system built around standards-based web technologies. They plan to bring the platform to market later this year on a prototype device that they are developing in collaboration with Qualcomm.

The new operating system, which is called the Open Web Devices (OWD) platform, is based on Mozilla’s Boot2Gecko project. Mozilla launched B2G last year with the aim of building a Linux-based mobile computing environment with an application stack that runs entirely in Gecko, the HTML rendering engine that is used in the Firefox web browser.

Photo illustration by Aurich Lawson/Ars Technica

According to a statement from Mozilla, Telefónica was already evaluating the feasibility of creating its own web-centric mobile platform when the B2G project was first announced. Telefónica subsequently decided to bring its ideas to B2G and join Mozilla in a cooperative development effort.

Their initial target is to produce devices with smartphone-like capabilities that can be built inexpensively and sold at the price of a common feature phone. Telefónica believes that the unique advantages of a platform built around web technologies will potentially reduce development and production costs, enabling the company to make devices that are a good fit for regions where smartphones have historically been too expensive for widespread adoption.

“From our experience in Latin America we know that a huge part of the market is not being catered for by current smartphones,” said Telefónica Digital product development director Carlos Domingo in a statement. “With new open web devices we will be able to offer a smartphone experience at the right price point for these customers.”

As we recently reported in our hands-on look at B2G, Mozilla is introducing a number of new JavaScript APIs that expose device functionality to web content. These include APIs for measuring device battery level and communicating with a device’s cellular radio.

Mozilla has been working with the W3C to turn its new APIs into open standards with the hope that the technology will be embraced by other browser vendors. In today’s announcement, Mozilla revealed that it plans to take this effort one step further by turning the whole OWD platform into an open standard.

“Because of this initiative’s commitment to openness, this reference implementation will be submitted for standardization to W3C,” Mozilla told us in an e-mail. “The objective is that there are no proprietary APIs within the device architecture, making phones developed using it the only truly open devices on the market.”

The initial OWD prototype device will be built around a Qualcomm chipset, but the exact specifications have not yet been disclosed. In light of the focus on low cost, it’s likely that the specs will be modest. Mozilla contends that OWD is lighter than some other mobile platforms because its simple HTML-on-Linux architecture eliminates the need for a lot of the intermediate layers that would otherwise be necessary.

According to Mozilla, this lack of overhead will allow OWD to run efficiently on less-expensive hardware than its rivals. But HTML rendering engines are hardly lightweight — it is still unclear whether a user experience built entirely with HTML and JavaScript will be able to fully match the performance and responsiveness of native code on a mobile device.

It does seems clear, however, that the extensive use of HTML will help accelerate OWD development and vastly simplify the sort of customizations that mobile network operators typically make. Mozilla was able to get its B2G home screen interface up and running very quickly due to the strengths of HTML as an environment for creating interactive user experiences.

Another question that is left unanswered is which handset manufacturer will actually build the launch device for Telefónica. A number of rumors that have circulated over the past few days suggest that LG will be involved in building the first handset based on the B2G project. It’s possible that LG is involved, but that hasn’t been confirmed yet.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Mozilla has unveiled a new distributed online identity system dubbed Mozilla Persona. The new Persona project is Mozilla’s latest effort to tackle online identity management by shifting the focus from individual websites to the web browser.

Mozilla has been playing with the idea of a browser-based identity manager for quite some time. In 2010 the company launched its Account Manager project, though it failed to gain much traction and was later scrapped.

More recently Mozilla has been working on Browser ID, a similar effort to move the process of managing passwords and online identities to the browser, rather than relying on any particular website’s login process. The Browser ID project offers developers a means of creating a browser-based login system for their sites. The code is available through GitHub and while using it is considerably simpler than similar efforts like OAuth, Browser ID has yet to catch on with many sites.

Mozilla Persona will build on Browser ID’s foundation (Browser ID will continue to be the name of the developer-facing aspect of the protocol), but add in more end user features like “an identity dashboard.” As with Browser ID, Persona will face a chicken and egg problem — why bother supporting Persona when few people are using it, and why bother using it when so few sites support it?

Thus far, aside from the proposed dashboard, Mozilla’s goals for Persona are only vaguely outlined. The closest Mozilla comes to giving it a concrete definition is to say that Persona will consist of “a collection of components and experiences we’re designing to manage the whole of a user’s online identity.”

If you’ve got ideas or opinions about what Persona ought to offer, you can let Mozilla know your thoughts via the mailing list or through Twitter using the #browserid or #mozpersona hash-tags.

For those wondering about the old Personas, the toolbar background images that can be applied to Firefox, fear not, they remain available and Mozilla is already on the hunt for a more fitting name.

Mozilla launched a new project last year called Boot2Gecko (B2G) with the aim of developing a mobile operating system. The platform’s user interface and application stack will be built entirely with standards-based web technologies and will run on top of Gecko, the HTML rendering engine used in the Firefox web browser. The B2G project has advanced at a rapid pace this year and the platform is beginning to take shape.

The B2G team at Mozilla is preparing to give a demo of the platform’s user experience at the upcoming Mobile World Congress (MWC) event. Mozilla’s Brendan Eich told us via Twitter that the B2G project has already attracted partners, including one that is developing its own custom home screen. This suggests that multiple parties, possibly hardware vendors, are interested in adopting the platform.

According to a roadmap recently published by Mozilla, the B2G project could potentially reach the product stage by the second quarter of 2012. That’s a highly ambitious target, but the project’s impressive rate of development suggests that it can be done. The pervasive use of HTML and JavaScript to build the user interface and application stack is no doubt speeding the project along. Web technologies are very conducive to rapid development.

The B2G platform consists of three main layers. The bottom layer, which is called Gonk, includes the Linux kernel, the hardware abstraction layer, the telephony stack, and other low-level system components. The middle layer is the Gecko rendering engine, which has been improved with new APIs that expose device capabilities. The top layer is Gaia, the B2G user interface, which is built entirely with HTML and JavaScript.

The Linux kernel that is used in Gonk is said to be “reasonably close” to upstream Linux. According to Mozilla’s documentation, Gonk uses some of the underlying bits of the Android open source project, including some minor kernel customizations, in order to make it easier for hardware vendors to get B2G running on Android hardware. B2G is not based on Android, however, and will not run Android applications. It’s currently possible to replace the Android environment on a Samsung Galaxy S II with a B2G build.

Much of the interaction between the Gecko and Gonk layers will be mediated by a B2G process that runs with a high privilege level and acts as a sort of Gecko server. The B2G process will paint to the framebuffer and interact with hardware components like a built-in GPS antenna or camera.

The wireless modem functionality is implemented in a radio interface layer (RIL) daemon, which B2G will interact with through a simple proxy process. Actual web content and multimedia playback will be handled by separate processes that communicate with the B2G process.

Mozilla aims to build the entire B2G user interface and application stack with native HTML and JavaScript. In order to accomplish that, Mozilla launched the WebAPI project, which exposes device functionality to web content through JavaScript APIs. Mozilla has already previously introduced APIs for accessing certain device capabilities, such as the accelerometer and geolocation APIs that are supported in the mobile versions of Firefox.

The WebAPI project goes a step further and adds a great deal of additional functionality for tasks like taking pictures with the built-in camera, dialing the phone, accessing the device’s battery level and status, sending and managing SMS messages, accessing the user’s address book, and making a device vibrate. These capabilities are largely made accessible to web content through a set of JavaScript APIs. This means that the B2G dialer interface, for example, is just a web page that uses a JavaScript function to initiate a call.

Mozilla is working to standardize these APIs through the W3C Device APIs working group. In theory, the same underlying JavaScript APIs that are used to enable access to underlying platform features on B2G could eventually be supported natively in the default web browsers that ship with other platforms.

The standardization effort around device APIs is especially significant. If the APIs gain widespread adoption, it would make it possible for large portions of the B2G user experience and application stack (which are, essentially, just web content) to run in web browsers on other platforms. At that heart of Mozilla’s agenda for B2G is a vision of the future in which browser-based mobile applications, built with standards-based HTML and JavaScript, will be capable of doing everything that can be done today with the native mobile application development frameworks.

Because B2G’s Gaia user interface layer is implemented in HTML and JavaScript, it can technically run in a regular desktop web browser. Of course, the device-related capabilities will only work when the content is run in an environment that has WebAPI support.

We tested the Gaia home screen user interface and several of the platform’s applications in a Firefox nightly build. All we had to do to get it running was download the code from the relevant GitHub repository and then open the homescreen.html file in Firefox.

When the page loads, the user will see the B2G lock screen, which displays the current date and time. The home screen interface can be accessed by dragging the lock screen up. The home screen displays a grid of application launchers and has a notification bar at the top. You can drag a notification slider down from the bar, much like the equivalent user interface element in Android.

B2G lock screen

If you look at the source code of the homescreen.html page, you will see that the contents of the interface, including the lock screen, are created with HTML div tags with some JavaScript code to handle interaction and populate the values. It’s quite simple and predictable web content.

The B2G home screen

Individual applications run inside of a frame in the homescreen interface. We tested several applications, including a dialer, a web browser, and a map application. Like the home screen, these are all implemented in HTML and CSS. The web browser is basically a web page with an HTML input element for the URL bar and an embedded iframe element where the page content loads.

B2G sample map application

B2G's Web browser. It's practically begging for a Yo Dawg joke

The B2G dialer

The current implementation of the Gaia environment is still simplistic and incomplete, but it offers a compelling demonstration of how conventional web content can be used to create a smartphone user experience. It’s possible to do anything in the B2G user interface that can be done with HTML and CSS, so the possibilities for styling and theming are prodigiously extensive. Such intrinsic flexibility could help make B2G appealing to hardware vendors because it would make it easier for them to create custom user interfaces that differentiate their products.

Mozilla hasn’t created an HTML-based widget toolkit for application development. The applications currently included in Gaia are just straight markup with CSS for design. It’s theoretically possible to use existing HTML widget toolkits in B2G, however, such as jQuery Mobile and Sencha Touch.

The B2G project is off to an impressive start. The underlying concept of bringing native application capabilities to the standards-based web technology stack is also tremendously compelling. It hints at the possibility that the open web could someday provide a unified application platform for mobile devices.

It’s also worth noting that the project is entirely open. As Eich pointed out to us yesterday in response to our coverage of Open webOS, the B2G project has had open governance and public source code since its first day. B2G also benefits from Mozilla’s engineering talent and potential partners. The B2G platform has an opportunity to bring positive disruption to the mobile landscape and be a serious contender.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Just before the holiday weekend Mozilla announced that it had renewed its long-standing search revenue agreement with Google, which will reportedly net Mozilla $300 million a year (as part of a three-year contract). The renewed contract comprises the bulk of Mozilla’s funding and is unquestionably a good deal for Mozilla. What’s less immediately clear is why Google — which now has its own Chrome browser — would want to continue the deal.

Indeed, why fund the competition? M.G. Siegler speculates (based on AllThingsD’s report that there was a bidding war over Mozilla) that Google is willing to spend that kind of money just to keep Microsoft from starting a partnership with Mozilla.

That’s one theory. But it may well be that the truth is much more mundane. It may be that Mozilla is just one of a number of payouts that Google makes to help drive ad sales.

In fact, as Mozilla’s Asa Dotzler points out, Google pays out roughly 24 percent of its ad revenues to drive more traffic to its ads:

Not all traffic to Google ads is “organic” though. To help drive ad sales, Google pays for traffic to their ads. They paid out $2.21 billion, or 24% of their ad revenues in “Traffic Acquisition Costs”. That money goes to revenue shares with their AdSense partners and to “distribution partners” — presumably browser makers, PC OEMs, and mobile OEMs and operators.

As Dotzler goes on to point out Google pays out similar money to Opera and Apple, which both use Google as the default search engine in their respective browsers — again, driving eyeballs to Google ads. Dotzler’s point being that the Google-Mozilla deal is not a charitable arrangement, but a business deal built around driving eyeballs to Google ads. Firefox currently holds roughly 25 percent of the global browser market, which is certainly a healthy number of eyeballs..

Of course it’s possible that other factors may also influence Google’s decisions. Google Chrome developer Peter Kasting says that Google’s motivation for building Chrome is to “make the web advance as much and as quickly as possible.” That means, according to Kasting, that “it’s completely irrelevant to this goal whether Chrome actually gains tons of users or whether instead the web advances because the other browser vendors step up their game and produce far better browsers.” In other words, funding Firefox helps to further the same goal that drove the company to build Chrome in the first place — advancing the web.

That would be somewhat easier to swallow if other parts of the Google machine didn’t build so many experiments that only work in Chrome.

Regardless of Google’s motivation for building Chrome, or for funding Mozilla, both moves have proved great news for users. And in the end the precise motivation behind the Google-Mozilla deal are something only tech writers really care about. Users care about speed and there’s no question that Chrome has helped spawned a renaissance among web browsers and helped put speed back on top of every browser makers’ to-do list (the drive to adopt HTML5 has also done wonders to improve the average user’s experience on the web).

For most users the Mozilla-Google deal just means that there will continue to be a number of browsers to choose from and a number of browsers to help keep pushing the web, and each other, forward.

Google has announced a new set of APIs for its Chrome web browser, which are designed to connect applications and sites across the web. Web Intents, as Google is calling its new meta-website API, allows websites to pass data between each other — for example, to edit a photograph or share a URL with friends.

Developers at Mozilla have been working on a similar framework for Firefox, and now Google says it will work with Mozilla to develop a single API that works in both web browsers.

The Web Intents API was originally conceived by Paul Kinlan last year. Kinlan, who is a Chrome Developer Advocate at Google, borrowed the idea from the Android platform, which uses Android Intents to pass data between Android Apps.

So just what are Web Intents? Well, the easiest way to understand them is by example. Take the sometimes overwhelming proliferation of buttons on web pages that allow you to do something with the current page, whether it’s Like, Tweet, +1, Read Later, Add to Instapaper and so on. Rather than adding a dozen little badges to your site, Web Intents creates a bridge that connects your site to any website your visitor wants to use. Web Intents define an API for your site to use and another API for the receiving site to use. Plug them together and transferring data becomes a quick and easy process, both for users and developers.

That’s a huge step up from the situation today. Perhaps the biggest win is that Web Intents put your visitors in control — they can select which actions they’d like to perform and which external sites they’d like to handle those actions. Some might share your page on Facebook, others on Twitter, still others might save it to their Instapaper account and so on, all from the same three lines of code you added to your site.

That’s not, however, all that Web Intents can do. The broader goal of Web Intents is to provide a generic means of communication between websites for tasks as varied as editing photos, listening to music or shortening URLs.

The second half of the video below demonstrates Mozilla’s take on how Web Intents ("Web Activities" in Mozilla’s parlance) might work.

For some sample code and working examples, head over to the new WebIntents.org site and check out the examples (the image example is particularly good at showing off the potential power of Web Intents).

For some more background on Web Intents, check out Paul Kinlan’s blog, particularly his overview post on the brief history of Web Intents. Tantek Çelik, the creator of microformats, also has a nice post on what he calls Web Actions (same thing, better name). Çelik breaks down the idea behind Web Intents and how they benefit not just developers, but users as well.

As Çelik writes, "web actions have the potential to change our very notions of what a web application is from a single site to loosely coupled interactions across multiple, distributed sites…. In that regard, web actions have the potential to become a building block for distributed web applications."

Image: Aidan Jones/CC/Flickr

See Also:

• Web Notifications API Hints at a Brave New Real-Time Web
• Speed Up Your WordPress Site With Google’s New Page Speed API
• Mozilla Shows Off Plans for an Open Web App Store

A few of the proposed privacy icons

Mozilla has taken the lead among browser vendors to make a site’s privacy settings more explicitly visible. It’s doing so by proposing visual cues in the browser that indicate what level of privacy you’re currently browsing at, and what pieces of your personal data the site you’re currently visiting is sharing with the rest of the web.

Earlier this year, Mozilla’s head user experience designer Aza Raskin proposed creating a set of icons to denote the privacy policy of a website. Now, after getting feedback from a wide range of interested groups — from the Electronic Frontier Foundation to the Federal Trade Commission — Raskin has drawn up a new and improved icon set.

The idea behind Raskin’s proposal is that the browser is the most logical place to display identity and privacy information to the user as they click around on the social web. The end goal is to produce a set for warnings similar to the way that Firefox (and other browsers) currently handle phishing attack warnings, using visual icons and simple language to explain what you’re getting into when you load a page with a different level of privacy or security.

For the active social web user, keeping track of which bits of your data are public and which are private on different sites is a chore. Some websites share your photos, status updates, your list of friends, who you’re following and other data default. Some share nothing. The rest are somewhere in the middle.

Part of the problem is the privacy policies themselves. They are complex, mind-numbingly long legal documents. We routinely ignore them, breezing past them by clicking “I agree.” Once clicked, your rights are compromised, and you may not be able to fully restore them.

A set of icons in the browser, to quickly and easily allow users to know what will happen to their data, means that users don’t need a law degree to know what’s happening to their images, status updates and other data.

The big difference between privacy icons and the phishing warnings your browser already offers, is that these icons are targeted at the websites themselves. The biggest counter-argument to Raskin’s proposal is that there’s nothing stopping a site from displaying these icons and then doing the opposite.

Raskin’s solution is to make the privacy icons supersede the written privacy policy. “When you add a Privacy Icon to your privacy policy,” writes Raskin, “it says the equivalent of ‘No matter what the rest of this privacy policy says, the following is true and preempts anything else in this document…’”

In other words, sites using the icons maliciously would face legal consequences. Of course differences in international laws mean enforcing such violations would be complex.

Still, as Raskin points out, privacy policies are fast becoming a selling point for many sites. Nearly every site we’ve tested lately has some sort of large, obvious banner that proudly proclaims the site will never share your data. Those are the kinds of sites, says Raskin, that would adopt privacy icons.

But it’s still unlikely any site would ever adopt the negative icons. If you’re sharing everything users give you with anyone who pays for it, you probably don’t want to advertise that. So the privacy icons actually become most useful when they aren’t present. Of course, as Raskin writes, “people don’t generally don’t notice an absence; just a presence.”

The solution to that problem is to make the privacy icons machine readable. The workflow would be something like this: You visit a website and decide to sign up. When Firefox encounters the sign-up form, it looks for the privacy icon. If it finds it, Firefox displays it. If Firefox doesn’t see an icon it warns you that your information may be shared using the negative icon. Either way, you know where you stand.

For now the privacy icons, good idea though they may be, are a long way from reality. Raskin calls the current mockups an “alpha” release and since Raskin is leaving Mozilla, the future of the project is unclear. If you’d like to get involved, head over the Mozilla Drumbeat Privacy Icons project page.

See Also:

• Warning: This Site May Be Sharing Your Data
• Mark Zuckerberg on Privacy and the Future of Facebook News Feeds
• Google Wants Global Privacy Rules