There’s a Free and Open Source Software Track at Grace Hopper this year! Submit your proposal now and come join us.

Grace Hopper is the largest gathering of women technologists and it’s a super energizing conference. They are expecting 11,000 people this year – which I find kind of scary. But my experience at Grace Hopper has always been very welcoming – a place to see old friends and a great place to meet new people. I always see quite a few women from the industry that I know and I always meet a couple of more – usually a couple each time that I still remain in contact over the years. It’s how I met the HFOSS folks and where I met Corey Latislaw who is now a Kids on Computers volunteer. I also always see at least one speaker who makes a huge impact on me. One year a keynote speaker made me cry and laugh several times all in one talk. Another year, the President of Harvey Mudd College was on the imposter panel. She talked about how she felt like an imposter asking for a $25 million donation when the people all around her were much more successful and wealthy. GNOME owes part of its financial success that year to her. Because of her stories, I had no problem going and asking all of the advisory board member companies if they could double their contributions.

Heidi Ellis and I are co-chairing the Open Source track and we’re both excited to bring the new things happening in the open source world to a larger audience. We want to get more of the women at Grace Hopper involved in free and open source software. Or at least aware of the opportunity. Please consider submitting a proposal to the track. Formats include presentations, lightning talks, panels, workshops, and birds of a feather.

Men and women are welcome at Grace Hopper although I warn you (both men and women!), if you’ve never been, it feels very strange at first to be at a technical conference that is almost all women! There are also a lot of students at Grace Hopper and that too adds to the energy and the unique feel of Grace Hopper.

http://feedproxy.google.com/~r/StormysCornerMozilla/~3/RGY6Qd52lOM/join-the-open-source-track-at-grace-hopper-this-year.html

Last Thursday we had our weekly call about the Reps program, where we talk about what’s going on in the program and what Reps have been doing during the last week.

Summary

• Council AMA.
• GNUnify’15.
• Budget bug mandatory.
• FOSDEM 2015 recap.
• Community Education Call.
• Monday Meeting Ambassadors.

Detailed notes

AirMozilla video

Don’t forget to comment about this call on Discourse and we hope to see you next week!

https://blog.mozilla.org/mozillareps/2015/02/06/reps-weekly-call-february-5th-2015/

As a follow up to my FOSDEM15 post, here’s the link to the Hacks post on node-firefox: Introducing node-firefox. Or if you just want to jump to the code, here’s the project page.

It has got a really positive response and we’ve already got very good questions and ideas for using it in ways that we didn’t expect. Thanks all!

I have to step away from leading the project as my backlog of devrel tasks essentially grows by the day, but I leave node-firefox in the capable hands of my colleagues .DS_Storoz (also known as Brittany Storoz) and tofumatt (also known as tofumatt). Of course I’ll still be hovering around the project and maybe building the occasional module and whatnot! You can’t get rid of me that easily…

http://soledadpenades.com/2015/02/06/promise-resolvenode-firefox/

After setting up the Mozilla Foundation example app, a repository that has most of the build tools and automation in place to generate client-side apps based on React, using Nodejs, Gulp, Browserify, a JSX wrapper for JSLint, and a JSX wrapper for JSCS, I figured the best way to verify whether or not what we came up with was actually decent, was to use it for something completely unrelated.

It's definitely one of the more reliable ways to discover shortcomings or oddities with automation solutions like these (some issues were found, indeed), while at the same time giving things that can use a leg-up in the codebase department a productivity boost.

As such, I figured I'd Reactify some bits of Inkcyclopedia using the mofo-example-app as basis, and the result has allowed me to play with a few things. For instance, if you hit up http://mighty-lake-2303.herokuapp.com you can see the fountain pen inks arranged by colour, which is fairly standard, with ways to sort on other colour aspects (some useful, like ordering on hue, others kind of silly, like ordering on luma value), but the coolest bit is if you click on a colour... because then magic happens:

By using chroma-js and plotting colors at some distance-and-angle away from a reference color, where the distance is the Lab colour distances (the most accurate colour model we have right now for representing colours close together that the human eye experiences as close together) and the angle is simple colour hue, you can pick any colour, and then I can show you what the closest "sort of similar colours" are from a large set of known fountain pen inks. A simple shortest-distance heuristic search is enough to find visually similar colours, which means I can add in things like "if you show this code an image, it can do some rgb quantization and find you inks that should be similar to the colours in the image". That's pretty huge because it means zero-effort applications for things that would traditionally take forever, like "take a picture with your phone, and get a list of ink names back".

For many some colours, the results are incredibly obvious. For others... not so much so, especially neutrals and darks!

Give it a whirl: head on over to http://mighty-lake-2303.herokuapp.com and start clicking on things O_O

http://pomax.github.io/#gh-weblog-1423203721895

Facebook gave all attendees of React Conf early access to the source code of React Native, a new way to write native mobile apps. The technology takes everything that's great about React.js and applies it to native apps. You write JavaScript components using a set of builtin primitives that are backed by actual native iOS or Android components.

First off, I know it sucks it's not completely public yet. Facebook isn't yet fully open-source, so it takes time to move projects into an open light. They are working on removing code specific to their environment and setting up a process to receive contributions. I think it's great they strive to be more open, and they care deeply about the React community. The project will be fully open-sourced soon.

I don't find anything fundamentally wrong with the slow release. I'm happy to discuss it with you if do. But let's please leave that for another discussion.

Because if you decide to get distracted by it, you might miss a huge shift in how we write native apps. The best part about this shift is that it's more like web apps.

I developed iOS apps for a few years, so I have experience with native development. After using React Native, I can only explain it like this:

We've all heard the promise of cross-platform native apps driven by JavaScript. Titanium, PhoneGap, and other projects allow various levels of hooking in with the native environment. All of them fall short. Either you're just wrapping a web app in a web view, or they try to mimick HTML & CSS which is hard to build apps with. With the latter, you're also interfacing directly with native objects all the time, which is doomed to fail performance-wise. React Native actually performs the layout on a separate thread, so the main thread is as free as it can possibly be to focus on smooth animations (it also provides flexbox for layout, which something that no other framework provides few other frameworks provide (ionic does, which is cool!)).

It only takes a few minutes playing with React Native to realize the potential it has. This works. It feels like I'm developing for the web. But I'm writing a real native app, and you seriously can't tell the difference. At the UI level, there is no difference; these are all native UIViews beautifully sliding around like normal.

This is solid engineering. And it completely reinforces the fact that React.js is the right way to build apps. I can write a native app using the same techniques as I would write web app. Let's start treating the DOM as an implementation detail, just like UIViews.

I love the web. But if we don't take a step and take a critical look at what's wrong, we might miss out on something big. The web is fundamentally weird to build apps on: the mess of HTML and CSS get in the way of frameworks instead of helping them. Perhaps React Native will finally drive this point home. I look forward to seeing how it will push the web to become a better platform for apps. Instead of thinking of it as moving away from the web, think of it as a prototype for a different direction of the web.

Are you feeling giddy yet?! I'll tell you how React Native works! You can learn more the videos from React Conf here and here.

React Native uses JavaScriptCore in iOS to run JavaScript (Android and other platforms will be supported in the future). The important part is that it runs JavaScript on a separate thread (other frameworks like Titanium do as well). You write your components in JavaScript just like you would with React.js, except instead of using div and a you use things like View and Text. You get all the benefits of React's composability for building UIs (which, safe to say, is awesome). And remember, JavaScript is not just a language but a platform, and there is large number of wonderful compile-to-JS languages to pick from.

React Native takes your UI and sends the minimal amount of data to the main thread to render it with native components. A View is a UIView, for example. The best part is, you don't have to worry about updating your UI; you declaratively render your UI based on some state, and React uses a diffing algorithm to send the smallest amount of changes necessary over the bridge.

Writing native UIs has never been easier, and additionally there is no performance impact on things like animations because JS is running on a separate thread. Smooth as butta.

An OpenGL App with React Native

My first React Native app is a non-traditional one: I wrote a 3d Wavefront obj model viewer. I've always been interested in game development, but I hated writing native UIs. React Native just gave me the web for game UIs.

I'm sure you'll see a lot of traditional app demos with native navigation and animation and all that. I thought it would be cool to show that it's just as easy to throw React Native on top of an OpenGL view.

All you have to do to integrate React Native is create an RCTRootView in your controller, tell it where your JS lives, and add it to the window. In my case, I first create an OpenGL view, and I add the RCTRootView as a subview on top of it. Integration was painless.

You can press Cmd+R to instantly refresh the UI and pick up any changes you made. Only the RCTRootView will update, so I can easily build out and refresh my UI without having to reload the OpenGL layer!

Here's an example component, ObjList, that lists available files and loads a mesh when an item is clicked. This uses a ListView which is a native scroll view that only renders the rows within view, like any native app does. Using it here is much simpler though.

var ObjList = React.createClass({
  // a few methods clipped....

  selectModel: function(file) {
    controller.loadMesh(file);
  },

  renderRow: function(file) {
    return View(
      null,
      TouchableHighlight(
        { onPress: () => this.selectModel(file),
          underlayColor: 'rgba(0, 0, 0, .6)' },
        Text({ style: { height: 30, color: 'white' }}, file)
      )
    );
  },

  render: function() {
    var source = this.getDataSource(this.props.files);

    return ListView({
      style: { flex: 1 },
      renderRow: this.renderRow,
      dataSource: source
    });
  }
});

In my App component I have a handleSearch method that fires when the text input changes. I just change the state, which rerenders the app and the ObjList component with the new state, showing only the new list of files.

handleSearch: function(e) {
  var text = e.nativeEvent.text;
  var files = allFiles.filter(x => x.indexOf(text.toLowerCase()) !== -1);
  this.setState({ files: files });
}

Notice the controller.loadMesh() call in the ObjList component. That is an Objective-C method that I've marked as exported, and the bridge will pick it up and make it available the JS. Working with the bridge was pretty easy, and it will only get better from here. Here's the implementation of loadMesh:

- (void)loadMesh:(NSString *)path {
    RCT_EXPORT();

    dispatch_async(dispatch_get_main_queue(), ^{
        teapotNode_.material.diffuse = [self randomColor];
        teapotNode_.wavefrontMeshA = [REMeshCache meshNamed:path];
        [self reset];
    });
}

RCT_EXPORT() marks it as a method to export (there's a little more work to actually instantiate the class somewhere else). These methods are invoked on a separate thread, but I need to load the mesh on the main thread (since it will load data into OpenGL), so I queue a block of code to be run on the main thread.

Here's a video going through it more detail:

The ability to declaratively construct my UI as components and respond to events by simply changing state is powerful. React.js has proven that. Suddenly, we get to do the exact same thing for native apps. "Learn once, write anywhere" as the React devs say. Also see: Facebook just taught us all how to build websites.

http://tracking.feedpress.it/link/9494/534359

The Community Education Working Group exists to merge ideas, opportunities, efforts and impact across the entire project through Education & Training.

https://air.mozilla.org/community-education-call/

https://udd.debian.org/dmd/?format=ics&email1=daniel%40pocock.pro

http://danielpocock.com/debian-maintainer-dashboard-now-provides-icalendar-feeds

The Grow Mozilla Community Building Forum

https://air.mozilla.org/community-building-forum-20150122-2/

Weekly Mozilla Reps call

https://air.mozilla.org/reps-weekly-20150205/

Like Clay Shirky, I think that over-optimising your setup and workflow for now can lead to long-term anachronism. He says:

[S]ince every tool switch involves a period of disorientation and sub-optimal use, I have to make myself be willing to bang around with things I don’t understand until I do understand them. This is the opposite of a dream setup; the thing I can least afford is to get things working so perfectly that I don’t notice what’s changing in the environment anymore.

In this screencast I show how I’m using Trello, Google Mail, and GitHub as part of my current workflow. This may change by next month – or even next week!

I’d love your comments and questions, particularly if you share your workflow or have any tips/tweaks for mine!

PS In 2015 I’m writing a book in my spare time called #uppingyourgame v2.0: a practical guide to personal productivity which you may find interesting…

http://dougbelshaw.com/blog/2015/02/05/my-current-workflow/

For a long time, Mozilla has required people gaining commit access to our core repos to sign a Committer’s Agreement. This is not a copyright assignment or a transfer of rights; it’s basically a commitment to good behaviour, and to making sure code which gets into the tree is allowed to be there and is correctly licensed.

However, the logistics of printing it out, signing it, scanning/photographing it back in etc. were always a barrier to participation. In consultation with our legal team, we have decided that people simply assenting to the document is just as good so, as of now, people are no longer required to go through the process of signing it.

However, all people with commit access to any Mozilla repository are still expected to abide by it :-) We may be adding CONTRIBUTING files referencing the document to our Github repos to make this point more clear.

http://feedproxy.google.com/~r/HackingForChrist/~3/bqVapz-Mx2c/

One question that came up more and more in recent months is how to create an accessible modal dialog with WAI-ARIA. So without further due, here’s my take on the subject!

An example

To lay the ground work for some terms we’ll be using, let’s look at an example. A dialog is basically a sub window of an application that asks a question, requires some input, or allows to set options etc. Desktop applications have dialogs of all shapes and sizes, but there are some unique properties that distinguish them from other windows. The primary one is that it usually cannot be moved out of the main application window. Another is that usually, when it is open, the application around it becomes inert, and you cannot do anything with it as long as the dialog is open. The dialog is what we call modal. Yes, there are also non-modal dialogs, but they are then more like different panels in the main application window rather than a dialog in the classic sense of the word.

Let’s look at a simple example: Open your favorite word processor, type in something or paste your lorem ipsum, and then just close the window. You’ll get a dialog that consists of the following:

• A title that contains the name of the application or some phrase like “Save the document”.
• Text that states that you haven’t saved the document and what you want to do now.
• A series of buttons like “Save”, “Don’t Save”, “Cancel” etc.

Screen readers will speak the title, the text, and the currently focused button automatically when you do the above steps with it running. This is important, so keep that in mind. It automatically reads the title and the text.

In the following example, we’ll call the title the “label”, and the text the “description”.

The simple Confirmation dialog

In HTML5 markup, this dialog could look something like this.

  
Save "untitled" document?
  
You have made changes to "untitled.txt" that have not been saved. What do you want to do?
  Save changes
  Discard changes
  Cancel

Let’s go through this step by step:

1. The first line declares a container that encompasses the whole dialog. Since HTML5 still doesn’t have a proper dialog element that is supported everywhere and gives us what we want, we will not use that element due to possible unpredictability of browser implementations. Instead, we’ll solely rely on WAI-ARIA to give us the semantics we need. The role is “dialog”.
2. The aria-labelledby references the ID of our title. This is important since that will give the accessible object for the dialog the proper title, or label, or accessible name, that is spoken first by the screen reader when focus moves into the dialog.
3. The aria-describedby associates the main dialog text with the dialog as well, which will turn it into the accessible description of the dialog object upon later translation. AccDescription is additional information that enhances the name and is spoken after name, role, and states. This concept goes back to the very old Windows days and is supported by all modern screen readers. If screen readers find an accDescription for a dialog accessible, they’ll speak it. Linux and OS X have adopted this concept later.
4. Below the actual divs that contain the title and description texts, there are three buttons. These are regular button elements with a type of “button” so they are considered valid even outside of a form element.

From this, there are some rules to be deduced:

1. If you use the role “dialog”, you must use aria-labelledby to point to the element containing the visible dialog title. The aria-labelledby attribute must be on the same HTML element as the role “dialog” attribute.
2. If your dialog has one main descriptive text, you must use aria-describedby to point to its element, also on the same element that has role “dialog”. You can also point to multiple text elements by separating their IDs with spaces.

One note about Safari on OS X: In my testing, I found that the dialog text would not immediately be read. Safari sometimes has the tendency to map aria-describedby in a funny way that makes the description end up as help text, spoken after a several second delay, or retrievable via Ctrl+Option+Shift+H. Apple should really change this to something that gets picked up as dialog text. The fact that VoiceOver reads dialogs correctly in, for example, TextEdit shows that it has principal provisions for that, it just needs to be mapped correctly from Safari.

The heavy-lifting

OK, that was the easy part. For the following, you must remember that WAI-ARIA merely provides semantic information. It tells the screen reader what the elements represent. It does not automatically introduce certain types of behavior. You have to use JavaScript to do that. The following sections describe what you need to do, and why.

Initial focus

When you open your dialog, for example by setting it from display: none; to display: block;, or by inserting its markup into the DOM, you have to give it keyboard focus. Focus should be on the first keyboard focusable element. In our example above, keyboard focus would go to the “Save changes” button. Opening the dialog will not cause the browser to set focus in there automatically, so you’ll have to do it manually in JS via the .focus() method. Setting focus will cause the screen reader to recognize the change of context and detect that focus is now inside a dialog, and will do its magic to read the title and description of the dialog automatically.

Trapping keyboard focus inside the dialog

Since your dialog is most likely modal, you will probably have something in place that ignores mouse clicks outside of it. You will have to do something similar for keyboard focus. The common way to move around controls is via the tab key. So you’ll have to make sure your keyboard focus never leaves the dialog. A few rules for this:

1. Create a natural tab order by arranging elements in the DOM in a logical order. That will cause the tab order to flow naturally without you having to do much. If you have to use the tabIndex attribute for anything, give it a value of 0 so the element fits into the natural tab order.
2. On the very last element of your dialog, add a special keyPress handler that traps the forward tab key to redirect it to the first element of the dialog. Otherwise, tab would jump outside the dialog into the surrounding document or to the browser UI, and we don’t want that.
3. Likewise, add a keyPress handler to the very first focusable element inside the dialog that traps the shift+tab key combination so the backwards tab order also doesn’t leave the dialog.

Provide an escape route

As is customary in dialogs, there is usually a way to escape out of it without making changes. Often, this does the same as whatever the Cancel button does. You’ll have to provide the same functionality to your dialog. So, make sure pressing Escape will close your dialog, and usually discard any changes.

Restoring focus after closing the dialog

Of course, Escape isn’t the only way to close your dialog. You would also provide a button to accept changes and execute on whatever functionality you desire. In any case, after you close the dialog, you must!!!, you absolutely must!!! then set focus back to the element that opened the dialog, or any other useful element from which the user of your app will most likely continue working. Never ever let keyboard focus go into Nowhere Land after the user dismisses a dialog you opened. In the worst case, it lands on the document or somewhere else far away from where the user’s context was before they opened the dialog. There is nothing more frustrating than to have to spend 10 or more seconds trying to find one’s last place again from where one left off.

Other dialog cases

Of course, your dialogs will most likely be more complex than what I showed above. Here are some more hints on what to do in certain situations.

A dialog with only a single button

Sometimes, you’ll create a dialog just to let users know that something completed successfully. Just follow the rules laid out above with focus on the single Close or OK button, and make sure the title and description are fully wired up via ARIA attributes as shown.

A dialog without descriptive text

If you don’t have general descriptive text, well then that’s that. Just make sure your form inputs are properly labeled as is customary for HTML forms, and if you group things together, use fieldset and legend elements to provide context. Also, of course, you can always use aria-describedby on individual inputs or other focusable elements to provide additional contextual information that you visually put outside the main label for that element or such. It all comes down to listening to your dialog and seeing if you can still understand what you’re asking of the user.

Multi-tabbed dialogs

Of course these are possible in HTML as well! You’ll probably not have general descriptive text, but yes, you can have a tablist/tabs/tabpanels construct inside a dialog just fine. You may then have aria-labelledby on the tabpanel pointed to its tab, and aria-describedby pointing to descriptive text within that panel that may give some context. Screen readers will pick that up when you move into the panel as well. Initial focus will then go to either the first tab in the tab list with the tab panel already opened, or the selected tab with its associated tab panel opened, if the dialog had been opened before and you want to preserve that when the user comes back. Your choice.

What about role “alertdialog”?

Hmm… Uhh… Don’t use it. Seriously, I’ve been working with ARIA for over seven years now, and I still haven’t figured out why role “alertdialog” was ever invented. It has all the properties of a “dialog”, and yet inherits the aria-live attribute with a value of “assertive”. That will cause its label, or title, to be spoken by a screen reader immediately upon its appearance, interupting everything else.

But a correctly marked up dialog will already speak all relevant information upon initial focus, and there should not be a reason not to give a dialog keyboard focus when it opens, so having a dialog yell at the screen reader user would only make sense if one would not initially set focus to it. And that is, from a usability standpoint, generally not a good thing to do in my opinion. I know opinions may differ on this, but since you’re on my blog and I can give you my advice, that is: Don’t use role “alertdialog”.

Other examples

Other fellow accessibility evangelists have created dialog examples that work similarly, but also have a few differences to what I discussed above. Lisa Seeman’s dialog example, for example, sets focus to the initial heading that contains the dialog title, and doesn’t associate the text above the fake login form to the dialog description. Also, in my testing, while shift+tab was trapped, tab was not, so I could move outside the dialog into the browser UI.

HeydonWork’s example shows the technique of using role “document” inside the dialog to make screen readers switch back to their reading mode. Cleverly used, this technique can help to work in application and browse mode automatically wherever appropriate.

And the most complete and comprehensive implementation I’ve seen, and which worked in a lot of combinations I tested, is this example by Greg Kraus called Incredible Accessible Modal Window. Thanks, Sina, for the pointer, as I didn’t even know about this one when I wrote the initial version of this post.

Conclusion

Creating a modal dialog that is fully accessible requires some work, but it is not rocket science or even magic. The important things to be aware of have been highlighted throughout this article, like associating both a label and descriptive text which screen readers will then pick up. It is also important to always control where focus goes inside the dialog, and when it closes.

I hope that this introduction to the topic of modal dialogs on the web helps you create more accessible experiences in the future! And of course, your questions and comments are always welcome!

happy hacking!

https://www.marcozehe.de/2015/02/05/advanced-aria-tip-2-accessible-modal-dialogs/

Social networks are today the main and often unique reason why people come online for the first time. Sometimes these people will discover the Web step-by-step through Facebook and WhatsApp, but sometimes they will also be blocked at a very limited use if there is no one to teach them. For these users, it is necessary to offer free learning opportunities, to allow them to discover the Web, but also to protect themselves online.

Here is a little annecdote from our recent trip in India, where we learn that there is a huge gap between using the Web (& social media) and understanding it, which can be heavy in consequences when it comes to privacy.

We interviewed a man doing Mehandi work in the streets of Delhi. This art is very popular for Indian women, and generally informally executed by men who wait for clients in market streets. One of the man we interviewed had a dual sim feature phone and a tablet where he kept pictures of his designs. When we asked him if he shared the pictures on the Web, he asserted yes, while pointing out the WhatsApp and Facebook icons from his tablet.

He then handed us his business card, for us to be able to find him on Facebook. He mentioned: “This is my Facebook, this email id”.

Business Card

As you can see on the card, he displayed his ‘email id’, which is in fact his phone number, along with the password to connect (Blurred for protection). We tried it.

This simple business card allows literally anyone to log into his personal profile and access all his conversations, friends, pictures and other private details.

Using is not understanding.

http://lauradereynal.com/2015/02/05/using-is-not-understanding/

Cross-post of Majken Conner’s invitation to participate in the first Mozilla Reps Council AMA.  Come ask us questions this Thursday!

This Thursday, launching during the Reps call, council will be doing a 24h AMA. They’ll be using Discourse, so you only need your Persona account, no need to sign up to Reddit to post. You won’t need to log in to read the AMA.

For those of you that haven’t done an AMA before, AMA stands for “Ask Me Anything.”, made popular by the SubReddit. It’s a way to get to know someone, usually a way to find out what it’s like to have a certain job. The AMA is your chance to get to know the individual council members as people, and also to understand what it’s like to actually be on council. Silly questions are OK, if you’ve always wanted to know what Emma’s favorite colour is, now’s your chance to ask!

Remember to be respectful though, don’t ask something that will probably make someone uncomfortable.

They’ll be keeping track of suggestions and discussions that should be continued outside of the AMA so that they aren’t lost when the event is over. Debates over problems with the program or changes to how it should be run will need more than 24 hours and deserve to be highlighted properly.

The AMA will take place here – https://discourse.mozilla-community.org/c/reps/council-ama

To ask a new question you should start a new topic. Discourse admins will be on-hand to help split out sub-conversations into new threads.

If you want to ask all of council a question, you can address them by typing @repscouncil – Discourse editor will substitute this text with their individual usernames.  You can also use @ to address a single council member, @emma_irwin will notify Emma that you’re addressing her specifically.

The entire council won’t be available at once, but we should have at least one council member available at any time over the full 24h to make sure responses come quickly.

You can also read an FAQ about AMA and how to use Discourse.

Image credit: Ed Schipul

https://blog.mozilla.org/mozillareps/2015/02/05/mozilla-reps-council-ama/

What’s wrong with this picture?

http://feedproxy.google.com/~r/HackingForChrist/~3/_yWwMOwIbbQ/

http://danielpocock.com/github-icalendar-issue-feed-now-scans-all-repositories

Over the past few weeks, I’ve had lots of in-depth conversations with many people about the badges project. The conversations have been helpful in terms of clarifying the purpose and value of badges, as well as defining a product roadmap for the near term future.

I’d like to share a summary of where we are now.

PART 1: VALUE

First, a reminder of the value of badges to learners and mentors:

• Structure and self-tracking—badges provide clear pathways for learning and contribution
• Professional development, reputation, and career advancement—badges provide clear pathways for increasing skills and knowledge, are perceived as evidence of mastery and expertise, and are connected to specific projects of which the recipient is proud
• Recognition—badges provide a concrete way to recognize people’s contributions and accomplishments
• Motivation—badges can keep people engaged and desiring to progress through a pathway. Badges can  also be used to engage new/bashful learners
• Relevance—badges are connected to things people care about

And the reasons badges are important to the Webmaker program:

• Pathways—badges provide primary navigation for people entering the fold
• Proof of learning / metrics — badges provide a concrete way for us to measure learning in our on-the-ground programming and online trainings
• Partner strategy — when paired with a rigorous curriculum, badges provide a framework for certifying a learner’s digital literacy skills and competencies. This has significant appeal to many of our partners.
• Growing user base — badges provide a significant incentive for learners connected to a ground game effort (e.g. Maker Party, Club, or Hive) to join the broader community (and be made aware of the full range of our offerings)
• Recognizing local leaders – the “Mentor,” “Super Mentors,” “Club Captain,” and “Hive Community Member” badges convey social status and legitimacy

PART 2: BADGE OFFERINGS

As a team, the next thing to do is get on the same proverbial page about our canonical  badge offerings, as well as consider changes to our issuing scheme to allow us to scale. Based on input from many people, I’d like to  propose the following for our suite of Webmaker Contributor badges for 2015:

(Please note: this list is not finalized)

Contributor badges issued by staff:

• Event Host
• Teaching Kit Remixer
• Club Captain (New!)
• Hive Community Member
• Mentor
• Super Mentor

(At least a couple of the above might eventually be automatically awarded by the system based on a user’s activity on the site)

Contributor badges issued by Mentors, Super Mentors, and Club Captains:

• Mentor (issued by Super Mentors and staff only)
• Skill Sharer
• Participation badges (this is a collection of badges Club Captains may want to issue to their Club members to recognize participation and effort. We’ll be examining these requirements during the rest of Q1.)

We also need to finalize a canonical list of Web Literacy Badges. The current list needs refining, based on upcoming changes to the Web Literacy Map. More to come on this soon!

PART 3: PRODUCT ROADMAP

Thanks to these rich conversations with stakeholders, I’ve become familiar with the tooling we have around badges now, as well as some of the desired changes to the user experience and functionality.

A high-level version of the product roadmap for badges is as follows, though it’s unlikely we’ll build in the exact order presented below:

a) Clearly present our badge offerings and highlight learning pathways

Once we finalize the badge offerings, we’ll build a landing page that showcases and clearly differentiates the several types of badges we offer. The landing page will illustrate the progressive nature of our badge offerings, and serve as navigation through our program offerings.

b) Improve user experience for badge earners

We’ll make a few key improvements to the badge application workflow, including allowing applicants to view the status of their pending applications, and edit their submissions while they’re pending.

We’ll create a Badge Manager page for mentors and learners. From the Badge Manager page, people will be able to:

• see the badges they’ve earned, including the evidence that was provided
• share their earned badges, and invite or nominate others to also earn them
• see their pending applications, and respond to any questions from reviewers
• see recommended badges (based on previously earned badges and our pathways)

c) Improve user experience for badge issuers

We’ll also make some improvements to the badge issuing dashboard:

• Allow badge issuers option to receive notifications or emails about new badge applications
• Show counts of outstanding applications, and provide multiple views of outstanding applications (e.g. by submission date, by badge type)
• Provide search tool for issued badges, with criteria such as issue date, badge type, or reviewer (the search results will be exportable, enabling us to contact everyone who’s received a certain badge, for example)

We’ll improve the design of the application reviewer pane by including (in addition to the applicant-provided evidence):

• badge criteria
• information about the applicant, including other badges received/applied for

d) Let Club Captains issue badges to their Club members

With the launch of the Clubs program, we’ll have a need to grant badge-issuing privileges to Club Captains. The permissions may be limited in two ways:

• They’ll be able to grant badges only to members of their Club (this will require creating a connection between individuals and Clubs on the backend)
• They may only be able to grant Web Literacy and participation badges

All of the above is now reflected on the Badges wiki page. Would welcome feedback in the comments.

http://hannahgrams.com/2015/02/04/building-better-badge-tooling/

The last two days I spent at the waterfront conference center in Stockholm, Sweden attending Jfokus2015, Sweden’s biggest developer conference with 1,700 participants. To make this even scarier, I gave the opening keynote one day after joining a new company and a technical talk about HTML5 at a conference mostly frequented by Java developers.

Jfokus is a big, seven track event. Many of the other talks covered frameworks, out-of-the-box solutions or big topics like smart homes, self-aware drones and other IOT matters. The organisation was very smooth and as it is the case with all Nordic events, the catering excellent.

The keynote: you don’t need another hero app, you need one that survives the Thunderdome

I was very humbled to hear that I’ve been chosen to give the opening keynote and I put a talk together that covers the current state of the app space and what developers can do to stay relevant in a world of declining install numbers and OS functionality takeovers.

There’s a screencast of the keynote on YouTube.

You can also read the keynote slides are on Slideshare

Resources I used and mentioned in the keynote:

• Smartphone OS Market Share, Q3 2014
• Developer Economics Q3 2014: State of the Developer Nation
• The Guardian: Women taking the lead when it comes to mobile
• The undead app store
• Quartz: Most smartphone users download zero apps per month
• comScore’s U.S. Mobile App Report
• Why the web is dead | Christian Heilmann | TEDxThessaloniki
• Android Vs. iOS Start Experience
• Smartphone Outlook Remains Strong for 2014, Up 23.8%, Despite Slowing Growth in Mature Markets, According to IDC
• WebPageTest.org
• CSSconf EU 2014 | Addy Osmani: CSS Performance Tooling
• The ServiceWorker: The network layer is yours to own
• Jake Archibald: The ServiceWorker is coming, look busy | JSConf EU 2014
• The State of the Componentized Web
• Mattias-Petter-Johansson on Quora
• The Web is built to last

HTML5 beyond the hype

My second talk was about the current state of HTML5. My goal for this talk was not to dazzle and impress with great new technology and experimental features. Instead, I wanted to remind people how much we have available to us across browsers these days. A lot of very basic, but also very useful functionality of HTML5 and CSS3 is now safe to use. The hype around HTML5 at his inception and the subsequent disappointment when browsers didn’t support it immediately made us forget about these features. In this talk, I wanted to remind people of what can be used and how it could improve existing web solutions – even in the enterprise space.

There’s a screencast of the HTML5 session to YouTube.

Many people asked for the slide deck, so here it is on Slideshare

The resources I covered in the talk are listed here, in case you want to follow up with them:

• Semantic CSS with intelligent selectors
• Effortless Style
• Axiomatic CSS and lobotomized owls
• Playing with data attributes
• Conditional loading of resources with mediaqueries
• W3C media elements spec
• Phaser IO
• Pixi.js
• Illustrator in the browser
• Canvas, images and pixels
• Zoom and Pick
• Chris Heilmann, TEDx Linz: Put social back into social media
• Remove Photo Data
• FileSaver.js
• Makethumbnails.com
• JSZip
• Five array methods you can use today
• HTML5 Rocks: ES6 template strings
• MDN ES6 documentation
• LocalForage vs. XHR
• CSS Coverage in Firefox Devtools

All in all, I very much enjoyed my time at Jfokus. The organisation is very efficient, it was fun to talk to people and good to see that me joining a big company didn’t change much the way people approached me. I hope I managed to inspire some people to play with tech they have not before and to tell their bosses about things their companies should be doing.

http://christianheilmann.com/2015/02/04/jfokus2015-my-keynote-html5-talk-screencasts-slides-and-the-resources-i-mentioned/

Weekly coordination meeting for Firefox Desktop & Android product planning between Marketing/PR, Engineering, Release Scheduling, and Support.

https://air.mozilla.org/product-coordination-meeting-20150204/

Ethereum is a platform and a programming language that makes it possible for any developer to build and publish next-generation distributed applications.

https://air.mozilla.org/ethereum-paris-2/