mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla gemeenschap

Wladimir Palant: A systematic approach to MDN documentation?

Mozilla planet - fr, 05/12/2014 - 00:23

Note: This blog post started as a rant about MDN which is sadly not very useful for add-on authors way too often. I tried to reformulate it in a neutral way. The point definitely isn’t blaming the people working hard on keeping that documentation up to date.

MDN has some great content. However, as far as extension development goes, maybe somewhat less content and more structure/quality would be beneficial. Yes, there are a few well-written overview articles. But quite frankly, I’ve seen them for the first time today — because most of the time I’ll get to MDN via a search engine. And if you take this route, there is a good chance to hit an article that pre-dates Firefox 4.0.

Don’t believe me? Try searching for a guide to write XPCOM components. You are bound to hit this book written more than a decade ago. Not only is it horribly outdated, it explains how one would create such a component in C++ — something that is completely impracticable for extensions in current Firefox versions.

The next search hit is only marginally better. The examples here have been somewhat updated to work in recent Firefox versions. It starts by sending people to an extension which is compatible with Firefox 3.0. It then explains the scary details of defining your own interface — yet most developers simply want to implement an existing interface. And as if the original document wasn’t already crappy enough, somebody also added instructions on integrating the whole thing into the Mozilla build system — all that before the actually relevant stuff of course. You might also end up in this troubleshooting guide which used to be pretty helpful — five years ago.

In fact, XPCOM Changes in Gecko 2.0 seems to be the only piece of documentation with a complete explanation, starting with the code of the component itself and ending with the way it is registered via chrome.manifest. Not that this document is comprehensible, being primarily a list of changes. And of course, that’s a place where nobody will come looking.

Another example: JavaScript Debugger API. The old API (ugly but well-documented) has been removed from Firefox, taking a look at the new one is overdue. There is an easy to find JS Debugger API Guide, linking to a seemingly complete JS Debugger API Reference. Great, right? But it is incomplete and outdated. In particular, the most important piece of information for extensions is missing: how do I find the existing global objects?

And then there is a document called Debugger-API, confusingly placed under Firefox Developer Tools. It took a while for me to realize that it isn’t related to the debugger tool in Firefox, it’s rather an autogenerated documentation of the JavaScript Debugger API. And this one seems to be complete and current! “Autogenerated” here means that somebody from the SpiderMonkey team didn’t want to mess with the wiki syntax (cannot blame them) and put a bunch of Markdown files into the SpiderMonkey source tree instead — these were then imported into MDN.

This isn’t even about the long list of nice functionality that was implemented but never documented. Like the XPCOM iterator helpers introduced four years ago. Or a way to listen to all events. Or a way to apply user stylesheets to individual documents. Yes, the dev-doc-needed queue is very long and there is only so many people who contribute to MDN (besides, they would also need to understand the change).

So, how can this be solved? I see a few options:

  • Marking documents as deprecated or obsolete isn’t sufficient, documents that aren’t useful need huge and very visible warnings at the very least. But frankly, why still keep them around?
  • Mozilla has great technical writers but they clearly cannot keep up. That’s not really surprising given how much Mozilla has grown. Maybe developers who actually wrote the changes could help beyond setting the dev-doc-needed flag? Sure, not everybody is a great writer. However, some documentation is already something that can be improved.
  • Some documents like the ones on XPCOM components and JavaScript modules can be checked automatically — a script can verify that the documented interface matches the current source code. If they don’t they can be flagged as needing an update (maybe even visible to MDN users and editors).

Anything else that can be done?

Categorieën: Mozilla-nl planet

Doug Belshaw: [IDEA] Webmaker Clubs: three legs to the stool

Mozilla planet - to, 04/12/2014 - 20:33

Yesterday, during the Mozilla work week, some comments made by my colleagues made me think about Webmaker Clubs using a new metaphor. I tested it out in a few conversations and it didn’t get shot down, so I’m recording it here to come back to.

Three legs to the Webmaker Clubs stool?

I thought about there being ‘three legs to the stool’ for Webmaker Clubs (name TBC):

  • Web literacy
  • Facilitation
  • Pedagogy/ethos

The Web Literacy Map (currently v1.1 but soon v2.0) provides the basis for curriculum and learning pathways. We can build off this in a fairly straightforward way - and in fact Laura Hilliger has begun to do just that.

What I feel we need is some kind of 'map’ for the other two legs of the stool. What what this look like for facilitation skills? What about for pedagogy/ethos?

I was asked for clarity on pedagogy/ethos. It probably needs a better name, but all I mean here are the approaches to teaching and learning that work well in blended learning environments. What works well when you’re mentoring people both online and offline? Also, in terms of ethos, what do we mean by 'working open’?

If we went ahead with this approach we’d need to get the help of the community to help build it – as we do with the Web Literacy Map. The great thing is that if we did it right, we could provide a handbook that works in most situations. It would need to be generic enough to be applicable everywhere, but specific enough to guide new mentors.

Comments? Questions? Email me: doug@mozillafoundation.org

Categorieën: Mozilla-nl planet

Pomax: Blogging during MozAllHandWorkWeek

Mozilla planet - to, 04/12/2014 - 20:25

and I realised that I completely forgot to update gh-blog. Gah

Categorieën: Mozilla-nl planet

Calling All Beta Users: Help Test Simplified Calling in Firefox Hello

Mozilla Futurereleases - to, 04/12/2014 - 18:38

We have some exciting new updates to Hello, our communications feature in Firefox, and we could use your help testing them because we value your feedback. Hello focuses on making it easier to communicate with your friends and family who might not have the same video chat service, software or hardware as you.

Together with our long-term partner Telefónica, and leveraging TokBox technology, we’re looking to make it easier to communicate over the Web by providing people with the first global communications system built directly into a browser. Firefox Hello is free to use, allows you to connect with anyone who has a WebRTC-enabled browser such as Firefox, Chrome or Opera and doesn’t require you to sign up for an account.

Since we introduced Hello, we’ve been listening closely to user feedback and acting on it. We’ve heard from people who love not having to sign up for an account or download a plugin in order to use Hello. We’ve also heard that the call initiation process and call management could be simpler. As a result, in Firefox Beta we’ve made important changes to the account-less call mode that simplifies the call process by eliminating some steps. Now when you start a conversation a window opens showing a self-view until the person you have invited clicks on the link and joins you. When the person you have called joins the conversation, you’ll be notified with an audio alert and the Hello icon will turn blue.

Each conversation window has a shareable, unique URL for two people to communicate more easily over video or audio. You can create multiple conversations and name them for different topics, making it easier to go back to the people you speak to regularly without having to create a new link each time. For example, you might set one conversation up for your weekly catch up with your family and a different one for a daily meeting with your co-worker. And the best part is that you still don’t need to set up an account to benefit from this feature. Your saved conversations will always be there when you need them.

New conversation window in Firefox Hello

New conversation window in Firefox Hello

For those of you who still love direct calling – don’t worry, we’re not taking this away. You will still be able to call people directly if both parties have Firefox Accounts.

So why not start a conversation and at the end of your call let us know what you think. Your feedback will help us find and fix bugs and enable us to get ready to share rooms with more Firefox users. Here are the instructions on how to create a conversation using Hello.

More information:

Categorieën: Mozilla-nl planet

Ericsson Interops OpenWebRTC with Firefox

Mozilla Futurereleases - to, 04/12/2014 - 16:30

Recently, Ericsson announced successful interoperation of its OpenWebRTC client with Firefox. This is very exciting for us; it marks several important milestones, both for Firefox and for the WebRTC specification itself.

Ericsson’s Bowser, which is based on their OpenWebRTC implementation, represents not just a third interoperable browser in the WebRTC space, but the first totally independent implementation. While most of the code in Firefox and Chrome’s WebRTC stack comes from completely different teams, some of the media handling is shared between the two. This common heritage, however small, has led to doubts around whether the IETF and W3C specifications are sufficiently detailed to achieve interoperability. Ericsson’s work in this space serves the incredibly valuable role of proving out that WebRTC interoperability can be achieved independently, simply by following the standards as they are specified.

Ericsson

The timing is fortuitous: both the IETF and the W3C are now approaching the home stretch in their WebRTC-related work, and the final steps to publish the relevant specifications will begin in earnest in the next few months. Multiple independent codebases allow us to discover where the specifications are ambiguous, incomplete, or inaccurate: if two different teams believe that they have implemented a standard but still don’t work together, it’s probable that the specifications themselves need to be adjusted. These kinds of problems are orders of magnitude easier to fix before they’ve been published.

In addition to the basic WebRTC interoperability story, Ericsson’s work also represents a completely independent H.264 implementation that works with Cisco’s real-time OpenH264 stack, which is incorporated in Firefox’s WebRTC codebase. Although H.264 is a mature, well-tested technology, its incorporation in Firefox is done in a novel way – through the use of the new Gecko Media Plugin (GMP) architecture – that had previously been tested only with itself. Further, Firefox’s implementation of other aspects of its H.264 handling, such as RTP packetization, parameter negotiation, and packet loss handling, had similarly been only self-tested. Ericsson’s success in interoperating H.264 video demonstrates the viability of the OpenH264 codec, our associated media handling and signaling, and the GMP architecture.

Finally, the simple existence of a second general-purpose, interoperable WebRTC toolkit (in addition to the WebRTC.org library) serves the critical role of growing diversity in library implementations, which helps avoid the rise of the kind of software monoculture that is so harmful to interoperable standards. In single-implementation ecosystems, having the same bug on two systems may result in a flaw being masked. Importantly, this makes it much harder for newcomers to the game to write software that works with the incumbent implementations. Additionally, the mere existence of more than one library keeps implementors “honest”: the temptation to implement proprietary or out-of-specification behavior is tempered by the knowledge that doing so will break their interoperability with many other implementations.

Mozilla would like to thank Ericsson for their important work in helping advance the WebRTC standard and in expanding the implementation ecosystem. We are proud that they chose Firefox as the reference implementation to use to test their interoperability, and look forward to seeing additional open-sourced projects based on their OpenWebRTC library.

Adam Roach, Principal Platform Engineer

Categorieën: Mozilla-nl planet

Yunier José Sosa Vázquez: Mozilla lanzará Firefox para iOS

Mozilla planet - to, 04/12/2014 - 16:28

Con el lanzamiento de iOS 8 y los primeros pasos para una apertura de Apple a los navegadores que no usan Webkit como motor de renderizado, y después de haber anunciado que no lanzarían una versión de Firefox para ese sistema, Mozilla ha cambiado su postura y entrará en iOS.

firefox-ios

La principal causa por la que Mozilla decidió no entrar a iOS fue porque Apple imponía una serie de restricciones a navegadores de terceros, como por ejemplo: no podían ser el navegador por defecto. Además, impedía que los desarrolladores pudieran incluir sus propios motores de Javascript, haciendo que susnavegadores fueran más lentos que Safari. Pero con el arribo de Javascript Nitro Engine en iOS 8 la situación ha cambiado para bien de todos y muestra una apertura de Apple con respecto al tema.

El anuncio fue realizado por Jonathan Nightingale VP de Firefox y compartido por Lukas Blakk, Jefe de lanzamientos de Firefox en su cuenta en Twitter mientras realizaban un evento interno. “Necesitamos estar donde nuestros usuarios están, por eso vamos a llevar a Firefox a iOS”

firefox-ios-anuncio-twitter

Hace poco fue anunciado oficialmente esa postura y han dicho:

En Mozilla, ponemos al usuario de primero y queremos ofrecer una opción independiente para ellos en cualquier plataforma. Estamos en las etapas iniciales de experimentación con algo que permita a los usuarios de iOS poder elegir Firefox.

Estamos experimentando con un par de conceptos diferentes y cuando tengamos más, lo compartiremos.

Ahora, todas aquellas personas que usen iOS podrán contar con las características que ofrece Firefox y acabarán ganando al poder elegir entre varios navegadores dentro del ecosistema.

Fuentes: Mac Rumor, Applesfera, Mozilla Press Center

Categorieën: Mozilla-nl planet

Naoki Hirata: Question on being Open…

Mozilla planet - to, 04/12/2014 - 14:00

One of the things I am grateful for in working for Mozilla is the opportunity to learn.

Recently through various channels, I’ve learned about values, trust and integrity.  (Side note: I highly recommend the book that I am currently reading : The Speed of Trust)

Values are highly important to people and the company/culture.  ( Side note: I also found that for those that throw away the very value that they are trying to protect at all cost will find themselves very miserable. )

Maybe I am dumb; I don’t understand a few things still though and I need help understanding it after even having worked 4 years at the company.  These are the top two things that still cause me to wonder:

1) How does one stay open about protecting privacy/IP and how can we protect privacy/IP and still be open?  And without being miserable?

2) How do we stay open in a fast moving environment where we’re constantly busy?  The context of this is that I had been talking to a few coworkers and when we were talking, I happened to tell them something they weren’t aware of.  The expression “oh I wish I knew that sooner” was stated.  Blogs and emails can be missed often, and in some people’s cases skipped from being read; miss a meeting and you won’t hear about it.  Asking around and trying to get the source of truth sometimes is hard and doesn’t scale, etc. etc.  Everyone has a different way of working it seems… how do you get the source of truth and maintain doing the work load of going faster?


Filed under: Planet, QMO Tagged: Planet, QMO
Categorieën: Mozilla-nl planet

Pages