As Adblock Plus is growing rapidly, we are constantly breaking new thresholds. Today, world’s most popular extension has achieved a new milestone that no one before us was able to reach: we have reached the 200th million download on Firefox. This makes Adblock Plus the first browser add-on ever to generate that many downloads on a single platform.

So how many is 200 million downloads exactly? Doing some basic calculations, this means that since the introduction in 2006, the Adblock Plus was downloaded on average approximately once every second… Consistently during the period of over 7 years!

We are constantly working hard to develop the extension further to ensure a flawless web experience on multiple platforms. We would like to take this opportunity to thank our users (each one of you!) for using Adblock Plus, our vast user base of tens of millions users have actively contributed to our success. A final shout out goes to our contributors, the beating heart of the ABP functionality. We thank you for all the voluntary hard work over the years — without you, we would have never achieved such a success.

It often happens that designers and web developers agree on the fact that they do not like the standard buttons or the styling capabilities of buttons in browsers. To work around this, they then resort to what’s called clickable text. It is in many cases a simple span or div element with some funky styling that makes it look like a button with some fancy twists. A JavaScript click handler then does the magic behind the scenes that happens if the user clicks on that particular styled text with the mouse.

Semantically, these styled text bits are totally meaningless to screen readers. The screen reader may or may not recognize that the text is clickable, but it can neither be tabbed to, nor is it known if this is a button, checkbox without a state that’s obvious, etc., etc.

Keyboard users also suffer from these, since these text bits are not tabable. Just adding an onclick handler does not automatically make these things focusable using the tab key.

Fortunately, there is WAI-ARIA. And with some simple additions to your markup, you can make these accessible and still profit from the fancy styling capabilities you get from using spans or divs instead of semantically correct buttons. Here’s the recipe:

Make it focusable

To do this, simply add the tabindex="0" bit to the span or div. Giving tabindex a value of 0 makes sure it fits into your tab order in the logical flow of your HTML code.

Make it a button

WAI-ARIA gives us the ability to tell assistive technologies such as screen readers for the blind that a certain element, or set of elements, actually means something that is not immediately obvious from the markup itself. In our case, even though the styling makes the span visually look like a button, the screen reader is not able to deduce that from the HTML and CSS instructions. To help it, you add role="button" to the element that receives the click. Ideally, this is the same that also already received the tabindex attribute above.

If it’s a graphic instead of text, also give it a label

Sometimes, you may end up with a clickable image instead of text. That’s fine, and both above parts of the recipe still apply, but in this case, and to be platform-independent, you should add aria-label="My button label" to the item. You can also do this with spans containing text if you want to be absolutely sure the screen reader speaks the right thing. aria-label takes a literal, and localizable, string as its value and translates that into the spoken label. Yes, for graphics, this even overrides the use of the alt attribute, if specified. And because some browser/screen reader combox like Safari and VoiceOver on the Mac have some problems with the alt attribute on occasion, aria-label puts you on the safe side.

Make Space and Enter activate the click handler

Yes, because this is no button in the original semantic sense, and browsers do not take into account WAI-ARIA markup except for when mapping stuff to the assistive technology APIs, you have to add a keypress handler that makes space and enter activate the onclick handler. In the regular desktop UI of most, if not all operating system, space is used to activate buttons, and enter is used to activate the default button of a dialog. But since in most cases we are not dealing with something that might have a default button except when it’s the submit button of a form, using enter in addition to space is OK here.

And that’s all there is to it! You need nothing more than that to make your fancy looking clickable buttons accessible on the basic level. Of course, if your button is a toggle and expands and collapses something, you may want to consider adding aria-expanded, as described in Easy ARIA Tip #5.

What about checkable clickables?

With a few tweaks, this will get you going as well:

• Instead of “button”, use “checkbox” as the role, or “radiobutton”, if only one should be checked at a given time.
• use aria/checked with a value of “true” for checked or “false” for non/checked items. In the same routine where you swap out the images to indicate the different states, also change the attribute or attributes accordingly. Make sure the attributes are never undefined, so are alwazs either checked or not.
• If dealing with radio buttons, enhance the onkeypress handler that reacts to the space bar and add support for arrows up and down to change focus to the next or previous radio buttons respectively. Tab should immediately jump to the next non-radio button outside that group of radio buttons..

These techniques can be used on both desktop and mobile. On mobile, you may want to react to touh events instead of click events, but I am sure you are already aware of that.

• #checkins-per-month: We had 6,433 checkins in March 2013. This is well past our previous record of 6,247 in Jan2013. Every working day was consistently busy (>200 checkins per working day) and load-per-day was busy across longer periods of each day.
  
  

• #checkins-per-day: On 18mar, we had 323 checkins – a new record for a single day, breaking our previous record of 307 checkins-per-day on 06jan2013. During March, 20-of-31 days had over 200 checkins-per-day – thats every working day except 28mar (because of Easter weekend?). 13-of-31 days had over 250 checkins-per-day (3-of-31 days had over 300 checkins-per-day!).
• #checkins-per-hour: Checkins are still mostly mid-day PT/afternoon ET, but the load has increased across the day. For 9 of every 24 hours, we sustained over 10 checkins per hour, the heaviest sustained use we’ve seen so far across our day. Heaviest load times this month were 2-3pm PT (13.22 checkins-per-hour).

As usual, our build pool handled the load well, with >95% of all builds consistently being started within 15mins.

Our test pool situation continues to improve, as we continue migrating any test jobs that do not *require* hardware to AWS. As before, any test suite which we can run on AWS means double goodness: the AWS-based test suites have great wait times on AWS, and the remaining physical-hardware-based test suites have slightly improved wait times because fewer jobs are being scheduled on our scarce hardware. Even so, its not yet as great as the situation with our builders. For the tests that *do* require hardware, it continues to be a slow process to bring those additional physical machines online. Meanwhile, RelEng, ATeam and devs continue the work of finding test suites which should (in theory!) be able to run on AWS, then fixing them to make them run green. Once a test suite runs green on AWS, RelEng stops scheduling that test suite on physical machines.

If you know of any test suites that no longer need to be run per-checkin, please let us know so we can immediately reduce the load a little. Also, if you know of any test suites which are perma-orange, and hidden on tbpl.m.o, please let us know – thats the worst of both worlds – using up scarce CPU time and not being displayed. Every little helps put scarce test CPU to better use.

mozilla-inbound, mozilla-central, fx-team:
Ratios of checkins across these branches remain fairly consistent. mozilla-inbound continues to be heavily used as an integration branch, with 27.9%% of all checkins, consistently far more then the other integration branches combined. As usual, fx-team has ~1% of checkins, mozilla-central has 1.6% of checkins.

The lure of sheriff assistance on mozilla-inbound continues to be consistently popular, and as usual, very few people land directly on mozilla-central these days.

mozilla-aurora, mozilla-beta, mozilla-b2g18, gaia-central:
Of our total monthly checkins:

• 2.4% landed into mozilla-aurora, very similar to last month.
• 1.6% landed into mozilla-beta, very similar to last month.
• 1.5% landed into mozilla-b2g18, very similar to last month.
• 4.8% landed into gaia-central, slightly higher then last month. gaia-central continues to be the third busiest branch overall, after try and mozilla-inbound. Obviously, these checkins are *only* for the B2G releases, so worth calling out here.

misc other details:

• Pushes per day
  • You can clearly see weekends through the month. Its worth noting that we had >200 checkins-per-day every working day in March except 28mar (because of Easter weekend?).
    

  • Pushes by hour of day
    Mid-morning PT is consistently the biggest spike of checkins, although this month the checkin load stayed high throughout the entire PT working day, and particularly spiked between 2-3pm PT, with 13.22 checkins-per-hour.

The following things didn’t really warrant a blog post in their own right, but I thought they were worth sharing somewhere on this blog.

1. Nesta ‘One Day Digital’ video

I ran a Mozilla Webmaker workshop in Edinburgh on Easter Saturday as part of  Nesta’s One Day Digital series of events. The video they produced afterwards is below and I make a brief appearance at around 1:00. Check out that beard!

One Day Digital events from Nesta UK on Vimeo.

2. Connected Learning TV

I’ve appeared on a number of these webinars and the archive is a CPD resource in its own right. This time I was standing in for Howard Rheingold as host. Interesting stuff about Liz Lawley’s attempts to add a ‘gaming layer’ on top of the university curriculum:

3. Open Badges presentations

I presented at SETT, the Swedish equivalent of BETT, last week. My presentation, along with one from PELeCON the week before can be found below. Unfortunately, the animated GIFs are not so animated on Slideshare, so click here if you want to see them in action!

Mozilla Open Badges: past, present and future from Doug Belshaw

 

A History of Open Badges through the medium of animated GIFs from Doug Belshaw

Image CC BY-NC-SA funadium

the following changes have been pushed to bugzilla.mozilla.org:

• [860723] Custom fields are shown twice in report axis selectors
• [861528] $user->can_enter_product() now returns the product object instead of 1
• [782210] If a custom field depends on a product, component or classification, the “mandatory” bit is ignored on bug creation
• [858911] Oracle fails with “ORA-04043: object T_GROUP_CONCAT does not exist” when installing Bugzilla for the first time
• [855549] Project Kickoff Form: Dependent bugs weren’t created from form
• [859315] lots of “Lock wait timeout exceeded” errors when updating cf_crash_signature
• [750170] switch from arecibo to sentry for error reporting
• [841633] Project Kickoff Form: CC sub-bug owners into main project tracker bug
• [841440] Project Kickoff Form: Remove Several Questions
• [864499] adding “due date” to the Marketing Product.
• [864200] use text/plain mime type for attachments with a .lang extension
• [828344] “contains all of the words” no longer looks for all words within the same comment or flag
• [864304] Requesting needinfo from more than one person is annoying
• [715148] Increase the attachment size limit to 10meg
• [859534] “Find product” field at BMO/describecomponents.cgi?full=1 can’t find “bugzilla.mozilla.org :: User Interface”
• [853483] Triage report times out on Firefox (Any) query

Filed under: bmo, mozilla

After IAccessible2 comparison to ATK text it'd be good to get a quick look at ATK / IAccessible2 APIs and UIA text. Firefox doesn't have UIA implementation yet and there's no nearest plans about it but it's worth to compare these API because one day UIA text might become a good alternative to IAccessible2 I think.

UIA text is closer to user actions since UIA has concept of range which can be moved like a cursor through the web page. You can move it (and extend it) by characters, words, lines the same way as the user would do. And then you can get a text the range is spanned to. This means you won't ever run into restrictions of accessible tree and embedded characters as you probably do in case of IAccesisble or ATK APIs. A couple examples might be good to explain what I mean.

Example #1
If accessible tree is DOM based i.e. it's close to DOM hierarchy then ATK / IA2 text interface implementation might be tricky. For example, the following HTML paragraph

<p>hello
  <aside style="position:absolute;top:0px;left:0px;">meine freund</aside>
my friend</p>

can have the accessible tree

paragraph (html:p)
  text leaf ('hello' text)
  section (html:aside)
    text leaf ('meine freund' text)
  text leaf ('my friend' text)

If the browser is not smart enough then it doesn't remove embedded character designating html:aside element from the text of parent html:p element. In other words if the paragraph text is "hello*my friend" (where * is an embedded character for html:aside) then a screen reader have to to deal with it and it should ignore out of flow content somehow. If the screen reader is not smart enough to ignore that then it will move the user through "meine freund" text when the user moves through the paragraph text.

Example #2
In case of Firefox implementation which tends to use embedded characters for everything you can observe another kind of weird behavior. Screen reader must be smart to move by words, etc because embedded characters are used for inline objects like anchors. For instance if you have

<p>hel<a>lo</a></p>

then screen reader must juggle offsets to detect that this paragraph technically consists of one word. You can get into similar troubles when an anchor is spanned through multiple lines. So if you move by lines then the end offset pointing after embedded character never says to you whether a line end is in the middle or after the embedded object. You need to look into embedded object to detect that. It makes a screen reader logic not performant and not trivial.

A summary 
In short UIA lets you to move through the page in correspondence to web page layout while ATK and IAccessible2 allow you to move in correspondence to the accessible tree. Sometimes it makes a difference. 

So accessible tree dependent approach makes the text implementation not trivial on certain platforms (granted, on Gecko). I'm sure that everything (or mostly everything) can be implemented right on the browser side or can be workarounded by screen readers but implementation in either case must be not seamless. Note, somebody told me that Webkit has a nice ATK text implementation (or nicer than Gecko's one? I don't recall). So it's an attestation it's doable, just can be not easy.

I should notice we didn't prototyped anything yet. Of course before making any judgements (did I?) we need to implement it and screen readers should adopt it. And only after that I have a right to say whether it was so good as it looks. On the other hand ATK appeared years ago, IAccessible2 just adopted and simplified ATK ideas so that Microsoft had enough time after MSAA to invent something nice. So I'm ready to believe they did it.

2013-04-19: the day the indieweb successfully federated a comment post.

The Test Note

It started with Laurent Eschenauer using Storytlr to post a simple note on his site that sent mention pingbacks to Barnaby Walters and Aaron Parecki:

Testing #indieweb federation with @waterpigs.co.uk, @aaronparecki.com and @indiewebcamp.com !

Laurent Eschenauer, 2013-04-19 The Prompt Reply

Less than 10 minutes later, Aaron Parecki used p3k to post a reply on his own site, which sent a pingback to Laurent's post and was automatically syndicated there as a comment on that post. Laurent's site automatically parsed Aaron's reply's h-entry microformat markup to retrieve its text, permalink, datetime of publication, and authorship information. The HTML+microformats of Aaron's reply literally acted as its own API. No separate meta tags or sidefiles in another syntax needed. No separate "api.***" URL. No API key. No TOS.

The Follow-up Commentary

Two days later, Christophe Ducamp used WordPress with some indieweb plugins to post a blog post commenting about Laurent's note, also pinging it and automatically being syndicated into its "Comments" section, again by Laurent's site parsing the microformats at the comment permalink.

One day after that, Barnaby Walters used Taproot to post a reply on his own site congratulating Laurent and also had his comment incorporated into the growing thread on Laurent's post.

Who will be next?

Four independents, from four different countries (Belgium, USA, France, England), on four personal sites, with four implementations.

Who will be the next to post an indieweb comment on Laurent's post?

Laurent's personal site running Storytlr is the first to accept indieweb comment pingbacks, parse the h-entry microformats at their permalinks, and automatically display them as full fledged comments, beautifully styled to look as good and as natural as any local comment.

Who will be the next to accept indieweb comment pingbacks (or preferably webmentions) and automatically display them on their posts?

The federated indieweb is here and growing.

Join us on IRC and in person at IndieWebCamp 2013 this June in Portland, Oregon.

Elsewhere

• Twitter
• Google+
• Hacker News

Translations

• Le Premier Fil de Discussion Fédéré de Commentaires #Indieweb by Christophe Ducamp

This is a PSA-style post on a couple of recent issues with Nightly builds of Firefox on Android:

• Pages aren’t rendered when you haven’t used Firefox for a while, the about:home content ‘sticks’ instead. This is bug 863803, present in builds from April 18th. The workaround is to close and restart Firefox. On ICS or higher you can swipe it away in the recent apps list, otherwise force close the app
• Nightly doesn’t update any more and is stuck on the build from April 10th (fixed for later builds by bug 860454). If you see ‘(2013-04-10)’ after loading about:firefox, then install a new copy of Nightly from nightly.mozilla.org

Talk of impostor syndrome is almost memetic at the moment. If you don’t know what it is, go look it up.  I’ll wait.

Like lots of other people, I struggle with this constantly. I’m not as smart as everybody else in the room. I’m not as good a coder. I’m not as good a manager. Sooner or later I will be found out for what I am: an impostor.

Thing is, I can rationally defeat many of those things by looking at objective evidence. I recite the evidence to myself. I am smart: my IQ is nearly 150. I wrote a programming book that some people really like - note I first wrote that as “great”, deleted it, wrote “best-selling”, deleted it, and settled for “some people really like”. I have worked on some interesting coding projects. I manage a successful team at an interesting company doing things that are technically difficult and that will hopefully make a difference in the world.

But in the back of my brain, a little voice says, that was just luck.

I recently realized that impostor syndrome is present in all parts of my life, not just in my career.  Everyone is better at riding horses than I am, even though I’ve been doing it since I was four. My fiction writing sucks, and my critique group will eject me once they figure it out.  My house is messier than everyone else’s, and I think I’m a terrible cook. I can’t co-ordinate my wardrobe.

The worst part is standing at the playground, thinking that every other parent there knows what they are doing except for me.

I have to remind myself these things aren’t true. Every day. I heard some good advice recently, which was to speak to yourself as if you were your best friend. You wouldn’t say to your best friend, “You’re an idiot”, now, would you? Even if your BFF did something objectively stupid, you might tell them, “You’re not stupid. We all do dumb things, sometimes.”

How about you? If you have strategies for overcoming impostor syndrome, share them in the comments.

When we embarked on our journey with Mozilla Reps almost two years ago we knew that the Mozilla Community was a vibrant and energetic ecosystem of contributors, full of activities and events. We set ourselves the goal to further empower the community, to help Reps grow their local communities, to raise visibility of activities and to document their achievements thoroughly.  

Last week we hit an important milestone. On 14th of April 2013 we hit the 1,000 mark.  One thousand events that Mozilla Reps organized or have participated in more than 80 countries.

 

The increasing amount of Firefox OS related events organized by Reps in recent months  reflects the incredible momentum that the project is gaining. Reps are ready to play a critical role in our launch markets later this year, actively raising awareness about the project and inspiring new contributors to get involved.

Some “damned lies” for all the statistic lovers out there:

Total events: 1154

Rate of events so far: 1.93 events per day

Rate of events last 3 months: 3.18 events per day

Total Reps: 407

Special thanks to the previous and current council members for all their hard day to day work on the program, and their visionary inputs for the ways forward.

Onwards we go, Jedis!

 

photo credits: ashish0105, bobreyes, deimidis

In case anyone missed this during this morning’s Mozilla Foundation call – here’s a quick summary of all the invisible prep-work that helped make last week’s B2G workweek so awesome.

1) Nightly builds
* now generated for Arm (panda boards), Otoro, Unagi, Unagi-ENG, Inari, Hamachi, Leo
* for that set of devices, we generate “nightly” builds twice a day. Once for 8am PDT morning. Once for 8am Madrid CET morning.
* … on each of mozilla-central, mozilla-b2g18, mozilla-b2g18_v1_0_1

2) Stood up an extra 250 slaves. More importantly, created 22 masters in AWS so we now have 70 masters total (with 30 in AWS) and can quickly burst-grow-capacity to create more slaves if needed.
* Reimaged 80 in-house build & test machines to optimize for Firefox OS development, based on watching load and usage at the last workweek.

3) Set up an alternate “birch” branch to use mozilla-inbound; By having b2g workweek developers use “birch” instead of mozilla-inbound, this allowed b2g-workweek developers a faster, less crowded, branch to land on, and reduced risk of blocking whenever a non-b2g change blocked mozilla-inbound.

Did all that work help? By all accounts yes. But of course, the proof in the numbers. Last week, 1490 checkins were landed, and all systems held super-responsive (>95% of jobs handled on time throughout the week, with one dip down to >90%!). Impressive to see the infrastructure handle the load like that.

Please give a big hug and thanks to RelEng/ATeam/IT, especially the following:

catlee, rail, hwine, armenzg (RelEng)
ctalbert, jmaher, jgriffin, edmorley, ryanvm (ATeam)
dmoore, arr, fox2mike, vinh, jakem, solarce, sheeri, klibby, sal, van (IT)

Art by Dave Mottram. Found on G+.

Making It in Brooklyn: Webmaker Mentor Team Make Week in Brooklyn

This post penned by the entire team and cross posted at http://explorecreateshare.org

Last week we had Mozilla Mentor Community team members from Toronto, Germany and New York City together for whirlwind week of making, plotting, talking (some talking is OK!) and of course, etherpad spawning. Here’s the overview from Day 1.

DAY 2

A fun Mozilla NYC dinner (with special guest David Ascher) at Rucola followed by raucous debates and night caps at the Nu Hotel, we had renewed vigor for Wednesday. Early in the day we revisited our Task Board and giddily moved sticky notes to track our progress–from “Make” to “Making” and some to “Made!” We also set up our projects for the day and were joined by teammates Beatrice Chen (Hive NYC and Mentor team archivist extraordinaire) and Julia Vallera (Hive NYC and Mentor team educator/superhero).

We spent time exploring how sites and communities like Mentor Mob might make our Activity Kits and resources more visible and remixable. We honed in on MOOC and Maker Party plans and messaging. We also reviewed a mentor badge  assessment tool that Chloe Varelidi, Jess Klein and Atul Varma have been working on, and outlined the process and criteria by which mentors will earn badges and benefits on Webmaker.org. Leah and Kathryn led day two of a design charrette with Hive Toronto to gather input for Toronto’s RFP process. Through this facilitated process, they ended up with many a white board filled with thoughts and diagrams. By the end, they had articulated – in draft form – Hive Toronto’s core beliefs and had building blocks for the application process.

Guide to Wednesday’s Makes:

• Mentor Mob Webmaker playlists
• Julia prototyped building an Activity Kit in Thimble, Knowing Your Neighborhood
• We continued to hone our Maker Party 2013 messaging–it’s a global party to celebrate all the things we can make thanks to the collaborative power of the web!
• Met with Open Badges team to feedback and iterate on peer assessed badges
• Laura shipped a color version of the #teachtheweb MOOC user experience infographic 
• We shipped the job description for an open position in the UK to run webmaker events, build community and talent scout for Hive London (know anyone good?)
• Shipped our thoughts and messaging about the upcoming #teachtheweb MOOC–in short: Learn how to teach digital literacies, master webmaking tools, develop your own educational resources, and take what you learned back to your communities and classrooms.http://webmaker.org/teach
• Laura, Michelle and Matt shipped the Mentor badges brief

 

DAY 3
Our focus on Thursday was all about making connections and interacting directly with webmaker constituencies: Hive NYC members, Super Mentors and Parsons New School students investigating Webmaker futures.

We took a break from the Brooklyn office and made an excursion into the city, starting the day at one of the city’s most venerable institutions, The American Museum of Natural History (AMNH), for the April Hive NYC meet-up. We heard from Ruth Cohen, Oscar Pineda-Catalan and Barry Joseph about their previous Hive-supported projects, and learned about some of  their current youth programs that range from melding Minecraft with museum exhibits, creating next-gen audio guides, building virtual dioramas, recreating iconic artifacts using 3-D fabrication, and of course, assessing work using digital badges. Next, Vee Bravo from Tribeca Film Institute,  reflected  on some of the challenges and lessons learned while planning and implementing the Rikers Island Digital Media Lab, an Oct 2012 Hive Digital Media Learning Fund collaboration, with a focus on teaching digital storytelling to incarcerated young women using video editing, letter writing and other simple strategies.

Kathryn Meisner from Hive Toronto and Leah Gilliam from Hive NYC shared some quick updates from their design charette with Hive Toronto members earlier in the week. Stay tuned for a separate blog post with more details coming soon!

Then we officially kicked off Mozilla Open Online Collaborative (MOOC) planning with 40+ Super Mentors! It was such a thrill to have this engaged community of folks from Bank Street College of Education, Mozilla Reps, EPIK and others around the world, who are so enthusiastic about helping us and others teach the world the web. We took advantage of this unique opportunity to try to get to know one another’s interests and to discuss goals, logistics and roles for the MOOC. We’ll have another call this week and the official course begins next Thursday, May 2. We put together this Super Mentor Twitter list so you can follow these brilliant minds, and of course, if you haven’t yet, please sign up to participate at webmaker.org/teach. Full details about this will be coming to this very blog very (very!) soon.

We then headed downtown to Parsons The New School to provide feedback to students in the  Designing Webmaker Futures Collab taught by Hsing Wei and Lisa Grocott. All semester, they’ve been examining Webmaker.org and webmaking as a phenomenon, specifically thinking about products and communities, designing solutions and exploring areas of interest. Most importantly, they’ve been “futurecasting”—identifying what Mozilla does now and how they might improve upon it in the future. Our team paired off and met with each of the four groups of students discussing projects, ideas and providing feedback. We participated in activities ranging from card games to expand user concepts of problems and solutions, to making peanut butter and jelly sandwiches as a way to measure soft skills.

It made for a fun and lively discussion, and our team was pretty impressed by the group’s conversations—particularly in terms of the depth of their research and designs. We left the students with lots of feedback to consider and specifically requested that they look for connections between their projects and ways that they could help inform one another’s work. With over seven Mentor team members assembled, it was important to impress upon them how Mozillians work together while also working apart. We look forward to having them present on an upcoming Webmaker call! Until then, you can see some of the documentation from their course here.

That busy day called for a visit to Shake Shack! Then we had a mini-caravan to the Catskills complete with cross-caravan sms-based gaming. We reached a gorgeous lake house in Ferndale, NY, where we’d spend the next day and a half maintaining our momentum in mentor-making land. Needless to say, we brought our task board and scrum methods with us!

Guide to Thursdays Makes:

• Super Mentor Twitter List
• We created outreach text and partners for the MOOC, this outreach begins in earnest today (Tuesday, April 22)
• MOOC Topic 1 Content planning

DAY 4

Friday morning we woke up early so that we could do some emailing before speaking with Brett Gaylor of Product Management and Popcorn Maker fame. We then beamed his head onto a wall and discussed Mentor Community Team needs and wishes for the next iteration of Webmaker. org and the Webmaker tools. All in all it was a super productive conversation in which we had the opportunity to fully explain our vision for Mentor Makes and how it ties in with the development of the product.

We also had a meta discussion and breakthrough on the idea of Hackable Kits. Leah, Julia and Laura began the discussion of how they, as educators, create various types of learning plans, curriculum, activities, resources, etc. They confused each other with differing use of various words. So Laura and Julia went into a back room and focused on speaking the same language. In their session, they decided to ditch the use a bunch of different words and streamline the process for making a hackable kit. Then they decided to MAKE the mechanism that will allow Webmaker Mentors to easily create hackable kits. A series of templates was born.

Laura and Kathryn were the first to try out the paddle boat meeting format. Gliding around the lake, they figured out the basics of a train the trainer workshop happening for Toronto Hive members in mid-May. Their successful and productive meeting led to more paddle boat one-on-ones including a Hive Mega Mindmeld with Chris, Leah and Kathryn.

We also chatted with Erica Sackin about the job description for a Maker Party campaign manager (to come) and planning for yesterday’s White House Science Fair, where two teens from Hive NYC and Hive Pittsburgh showcased their projects, AND where we officially announced the Maker Party campaign!

Guide to Friday Makes:

• Hackable Kit Mostly Shipped!
• Concept pad
• Hackable Learning Goals Template
• Hackable Activity Template
• Profile Template
• Cheat Sheet Template
• Planned outline for Popcorn workshop in Hive Toronto with members – May 16th:

Day 5

While we were wrapping up the final day of our work week, Hive Toronto was in full pop-up mode running the NASA Youth Space Challenge at the ROM (Royal Ontario Museum.) This member-initiated pop-up brought together six Hive members to create interactive stations for over 100 youth. For a first peek at how the pop-up went down, check out Maker Kids’ blog post.

Guide to Saturday Makes:

• Shipped updated copy and thinking to webmaker.org/teach
• Shipped/filed bugs in regards to our Hackable Activity Kits and Badges
• Had some great car ride home conversations about Mozilla, Mentors, Hive and general world domination

Much of this will be iterated on and announced before and throughout the course of the Maker Party campaign. Until then, we look forward to seeing you at the Maker Party!

[Update: changed links so each shows events in the office's local timezone, rather than GMT.]

Mozilla’s wonderful Workplace Resources team are maintaining public calendars for the events going on at each Mozilla Space. If you live near one of these, you might want to keep an eye on it. Each has a .ics feed linked from the bottom corner. (Note that not all these calendars may be in use yet; they are proactively created for each space as it comes into existence.)

• Auckland
• Beijing
• Berlin
• Boston
• London
• Mountain View
• Paris
• Portland
• San Francisco
• Taipei
• Toronto
• Vancouver

Next time, we’ll explore more serious aspect of our programming language, but let’s have some fun for today finding expressions (programs) with strange properties, similar to what we did last time (but a bit more difficult today).

As usual, we’ll use only Q and R rules (described here).

Question 1: Find expressions x so that RQx names (resolves to) QRx.

Question 2: … RRx –> QQx

Question 3: … RQx –> RRx

(You can check how previous riddles were solved. This could help a lot in case you don’t know how to approach solving this.)

 

Solution To see the correct solution, click 'Show' button... SelectShow

Q1: x=QR

Q2: x=QQ

Q3: x=RR

By now you should be familiar with the programming language enough to verify the answers yourselves.

The post Programming Brain Teaser #5: More curiosities appeared first on Salsita Software.

All of us would prefer to work on code that we love. And all of us are faced with code code that we feel…well, not so warm and fuzzy about. Its the nature of our business. Legacy code is everywhere. From code that’s just been around a long time to code that was rushed to [...]

Hey Folks,

recently we have updated the Mozilla Plugincheck Page (so far en-US only, other locales ) with new Layout etc.

We are working on support of other Browsers (for those who are not using Firefox yet) so stay tuned. Also when you have ideas how to improve Plugincheck let me know.

Big thanks to Schalk Neethling for updating the Site!

- Tomcat

I’m delighted to announce that there’s going to be a Mozilla MOOC! The Massive Open Online Course starts on the May 2nd for 9 weeks with the focus being upon learning how to teach digital literacy and HTML/CSS/JavaScript skills. Happily you don’t have to know anything about the topic(s) before you start.

>>>SIGN UP HERE! <<<

While I’m not one of the organisers of the Mozilla MOOC I’m excited to be involved as a Super Mentor! Further details (kindly provided by my colleague Laura Hilliger) can be found below:

As part of our non-profit mission, Mozilla believes that web literacy—the understanding of how digital things work—is an essential life skill for the 21st century. We want to empower users of the web to become makers of the web.

So we’re kicking-off a free online course called Teach the Web: a Mozilla Open Online Collaboration, where we’ll explore new ways of teaching digital literacies through making and learning together.

The #teachtheweb course will run from May 2 – June 30. You can participate in weekly guided discussions, tackle hands-on activities, develop and remix teaching resources, and compare notes with a global community of makers, mentors and educators.

Find more details or sign up and get started at http://webmaker.org/teach

Participants will learn how to:

• teach digital literacies through making, remixing and sharing
• incorporate openness and online innovation into teaching practices
• adapt educational resources to meet your learners’ interests and needs
• receive feedback from peers on your own resources and lessons

We hope you’ll join us!

If you have any questions, please feel free to reach out via Twitter @mozteach or the G+ Webmaker community at mzl.la/gpluswebmaker.

Be sure to sign up and I look forward to learning together!

The Google Summer of Code 2013 project is about to get started: today the application submission period officially starts (and is open until May 3). Mozilla is again a participating org, and students can find a list of project ideas and application advice in our Summer of Code wiki page. It’s important to remember that the list on the wiki is for possible ideas, but students are not limited to those on the list: project proposals with your own ideas are also welcome. With this disclaimer in mind, I’d like to describe in a bit more details some of the projects that we from the Firefox team have included on the list, and to answer some of the more frequent questions that we have received through e-mail and IRC about them. If you’re a student interested in one of those, read on. I wrote a blog post for each of them:

• Silverfox
• Fullscreen mode
• Autosuggest search engines
• about:memory for real people

To make a good proposal, it’s important to keep in mind the goals and non-goals of the project, to demonstrate that you’ve understood how to approach the implementation of the project, and that you’re capable of doing so. It’s also important to create a solid schedule of deliverables that are used both to guide the steps of the project and to validate the pace and the progress up until that point. I’ve already written enough about the specifics and there’s a lot of content out there explaining what makes a good candidate and a good proposal, so i’ll keep this post brief.

Just as a last note, if you’ve sent us e-mail or pinged us on IRC, please be patient because we’re not online all the time or available to immediately reply, and so far we have seen a lot of interest in GSoC, so it takes us a while to reply to everyone’s emails. We hope that these blog posts will help more students to clarify some common questions about our proposals. Good luck to everyone, and remember that you’re always welcome to contribute to Mozilla, during the Summer of Code and every other season too

This entry is part of a series of posts about some of our proposed GSoC projects. See here the introduction blog post.

about:memory for real people

What is it: about:memory is a tool that is used by Firefox developers to diagnose and understand the memory usage behaviors of the browsers. It has been immensely useful for us to find bugs in the MemShrink project and validate the fixes to those bugs. However, it is too focused on Firefox’s internals for the browser developers, but the available data there could be presented in different ways to also help web developers and regular users who wants to understand how each website consumes memory.

Example use case: User opens the new about:memory and sees that website A (tab 1) is taking 15mb and website B (tab 2) is taking 12mb. After 30min, the user opens the tool again, now to see website A still taking 17mb and website B taking now 30mb. They then can conclude that website B is consuming more memory as time passes, while website A is able to maintain its memory requirements steady.

What does it involve:

• looking into the current about:memory and understanding the existing data available and its breakdowns
• proposing various different ways to visually present that data and interact with it (e.g., sorting, time slicing, merging tabs from the same domain, animating data over time, etc.)
• proposing an existing open-source JS dataviz graphics library to be used for the project
• interact with the Firefox developers who work on memory optimization and provide feedback for more data that would be useful if it were available
• should be done as an add-on using the Add-on SDK

Non-goals: This project will not remove the existing about:memory, but will create a new one. Also, you should not try to create your own graphics library as part of the project, as there’s not enough time available to do both things during the official schedule.

Where to start: You should start by looking into the current about:memory and its code and to understand how data is retrieved from the memory measurements code. You then need to analyze the available data to undestand its meaning and start thinking on how you want to present that in a more visually interactive way. The usage of the Add-on SDK will also be required but will be very limited to packaging and setting up the add-on, as the main code will be a simple html page that implements your new about:memory (along with its supporting CSS and JS files).

Skills needed: JavaScript and CSS skills, and experience with data visualization. Experience with one JS graphics library would be great.

What is expected in your project proposal: A great understanding of the project, its goals and non-goals, and a good idea on how to approach each of the features involved and how to time slice them. A proposal for at least 4 different ways to visualize the data, describing what type of graphs will be used and the possible interactions that it will provide. The selection of the graphics library to be used. Links to open-source code (e.g. a github profile) that you have produced (specially ones involving data visualization).