MDN 2.2

Posted by groovecoder on 14 Feb 2012
  • BrowserID
    bug 721171 to draw Sign in buttons with progressive enhancement - should hopefully fix our search results snippets too! ><
    bug 719945 to link to browserid on the demo submit page
  • MindTouch wiki migration
    prepare for localized page migration (bug 717380)
    scripting architecture (bug 715253)
  • More

Kumascript Diagram

I'm excited about kumascript - lmorchard's prototype for implementing server-side scripting in kuma to replace DekiScript. I'm glad we're using JavaScript. I was a little surprised that MediaWiki chose Lua for their new scripting language (is it ironic that DekiWiki and its Lua-based DekiScript has roots close to MediaWiki and now MediaWiki is going to Lua-based scripting too?). JavaScript just makes sense for us - a community of web developers writing web developer docs.

MDN 2.2.5

MDN 2.3

MDN 2.1

Posted by groovecoder on 01 Feb 2012

We're doing better at keeping away from big new features while we try to work on the wiki migration, so there's no big item in today's release notes.

  • More BrowserID cleanup
    bug 715723 was really annoying - Sign in was broken from wiki pages
    bug 715811 should help users who've forgotten which email address they use on MDN
  • MindTouch wiki migration
    James did a thorough job on bug 710734 to expand the markup allowed in kuma
    Les did some more great working discovering all MindTouch namespace pages (bug 710753) and script template usage (bug 714804)
    Craig fixed up a bunch of CSS issues we've discovered as we migrate real content (bug 710737)
  • More

MDN 2.2

MDN 2.0

Posted by groovecoder on 31 Jan 2012

Wow, that's how much of a non-event a "2.0" product release is these days. I forgot to publish this when we pushed 2.0. Might as well publish before our 2.1 push today. :)

MDN 2.1

  • Set up 'master' and 'next' branches and corresponding stage servers on allizom.org (bug 710747)
  • Wiki content migration & work
  • Architecture for migrating MindTouch DekiScript templates into Django JavaScript templates (bug 715253)

Small sprint this time, but Les made some great progress on our wiki migration. I'm forcing myself to do a migration script bug this sprint so I learn enough of that code to follow his architecture and contribute what I can.

MDN 1.9

Posted by groovecoder on 05 Jan 2012

MDN 1.9

MDN 2.0

  • Set up 'master' and 'next' branches and corresponding stage servers on allizom.org
  • Wiki content migration & work

BrowserID

BrowserID Sign-inA few years ago I pushed hard for OpenID on SourceForge.net. OpenID was and is a noble project. But now I can tell some big advantages of BrowserID over OpenID:

  • It feels like an identity. I cognitively associate my online identity with my email, and BrowserID is a verified-email protocol. When I saw my email in the BrowserID login dialog on MDN, I already understand that I'm logging in - much more-so than an empty 'URL' input box.
  • No NASCAR effect. Because BrowserID is designed to be an open web standard, there's a single sign-in button that invokes a javascript API. It can be polyfilled with Mozilla's BrowserID service until platforms implement it, but even that will automatically be consumed by platform-native UI.
  • The site already knows you. As a site owner, we already have email addresses for our users. So when you sign in with BrowserID, we don't have to say "Now sign in with your existing account to merge your new identity with your existing" the way we did with OpenID. We know you own that email, so we log you into the account with that email address - simple.
  • Changing email is easy. Craig and I fretted for a whole hour or so over how to let users change their email address with BrowserID, but we were over-thinking it. Since BrowserID is effectively a streamlined "verify your email" dance, we simply point our "Change email" links to our sign-in page. If you're already signed in, and you sign in with a new verified email address, we simply update your email. BrowserID has already done the whole verify-your-email-address dance.
  • No lock-in. We get a verified email address from BrowserID, so we can register users in django with set_unusable_password(). But if we ever drop BrowserID (oh noes!), we have a verified email address. So we can initiate an email-based password reset flow for users. In addition, any site can run their own verification service so they don't need to call Mozilla's BrowserID at all.
  • Privacy. Finally, BrowserID is a user-centric identity system. This really hit me when I watched Ben's Deeper Look at BrowserID video. Especially when BrowserID is implemented in other platforms, Mozilla doesn't sit between you and the sites or services you use. A primary authority can issue identity certificates to your agent, and you present those certificates to other parties for authentication. "This triangle is never closed."

BrowserID Triangle

All-in-all, it was much simpler and much more intuitive to implement BrowserID on MDN than it was to implement OpenID on SourceForge. The Mozilla Identity team has built an awesome product, and Les integrated django-browserid with his trademark pace and effectiveness. BrowserID is great for the whole web - it will help us regain control of our online identities. It's worth repeating, "the people I work with are built of brains and heart" - it's another great day for Mozillians and for the web.

/me is so proud

MDN 1.8

Posted by groovecoder on 21 Dec 2011

MDN 1.8

MDN 1.9

BrowserID Flow

In Q1 2012 we are planning to sprint thru our wiki migration from MindTouch to django. Les has already started a migration script we will work on to import all the MindTouch wiki pages into django. That will be a big focus of 2.0. After that, the only big unknown is how to replace DekiScript with JavaScript.

Since Jay will be gone, John is re-joining us part-time to do some product management along with folks from the Developer Engagement team until we hire a dedicated PM. Until that happens, we're going to work hard on the wiki migration and we'll only add features if they are high priority - like Apps, BrowserID, mobile, etc.