Christian Heilmann: Creating a set of icons in various sizes in the browser |
Hooray, I did do some coding again for a change! One of the issues I had with submitting apps for the Firefox Marketplace is that the validator of the manifest always complains about me missing out on certain icon sizes. That’s why I thought it’d be sweet to have an in-browser tool to generate all of the icons one needs from an image. And here it is:
You can see a demo of it working on YouTube:
That’s all there is to it – it uses Canvas and the fileReader API to convert the images and create the files. JSZip, a neato library to create Zips was also in use.
For now your original image needs to be square and 512x512 pixels or the generator will just paste the first 512x512 pixels in. Images are automatically resized to 512 pixels and centered on a transparent background. A later version might allow you to move the image around. Let’s see when I get the time.
http://christianheilmann.com/2014/08/15/creating-a-set-of-icons-in-various-sizes-in-the-browser/
|
|
Soledad Penades: Audio for the masses |
The video above is from LXJS – the Lisbon JavaScript conference, which happened more than a month ago. I gave this talk past week again at VanJS, so I decided it was time for that belated write up on this talk.
If you want to follow along, or play with the examples, the slides are online and you can also check out the code for the slides.
As I’ve given this talk several times I keep changing bits of the content each time depending on what the audience seems more interested in, plus I also sometimes improvise stuff which I don’t remember when writing the final write up, so if you were at any of the talks and see that something’s missing or different now you know why! I’ve also added a section at the end with frequent questions I’ve been asked, hope that’s useful for you too.
I work at Mozilla (the above is a red panda, which we love), but that’s not what I want to talk about today. I want to talk about music instead.
|
|
Mozilla WebDev Community: Animating the Firefox Desktop Pages |
As you may have noticed, Firefox for desktop computers (Windows, Mac, and Linux) got a redesigned interface with the release of Firefox 29.0. This redesigned browser called for redesigned web pages to showcase the new interface (the tabs, icons, menus, etc., collectively called “browser chrome”) and new features (especially the new customization menu)
Naturally, the main audience for these pages are people using browsers that aren’t Firefox, so we wanted to illustrate the new Firefox design in a fun and compelling way that gives them a real sense of what it looks like, hopefully encouraging folks to download it and see it first hand. Another big target audience are Firefox users who haven’t yet updated, so we needed to give them an overview of what’s new.
This also gave us a chance to create some snazzy animations to show off some of the advances in CSS and SVG supported by the current generation of browsers, both on desktop computers and mobile devices. Here’s how we made it.
In order to demonstrate features of Firefox, we needed to simulate the way interface elements respond to user actions; opening and closing tabs, rearranging icons, adding a bookmark, and so on. This called for fairly complicated animation sequences that had to be quick and buttery smooth. The complex interplay of multiple elements moving both sequentially and in tandem really drove home the need for a CSS animation editor (vote it up!).
Each animation illustrating the browser chrome (One, Two, Three) is wrapped in a div element with a common class applied (animation-wrapper), along with an id we can use to target the specific element with JavaScript.
The first element inside the animation wrapper is a composite fallback image for browsers that don’t support CSS animations. This image has a common classname (fallback) for easy CSS targeting. We can conditionally hide this image by leveraging the cssanimations class Modernizr applies to the body. By first assuming that animation is not supported, we ensure a functional degradation for even the oldest and least capable browsers, and we can progressively enhance the page for more advanced browsers that support the more advanced features.
The next element inside the wrapper div is the stage for the entire animation –
cssanimations class from Modernizr, we’ll display the stage for browsers that can handle the animation.
/* for legacy browsers */ .fallback { display: block; } .stage { display: none; } /* for modern browsers */ .cssanimations { .fallback { display: none; } .stage { display: block; } } |
(We use Less to preprocess our CSS, so those nested rules are converted into separate rules with descendant selectors.)
The final task is to trigger the animations only when they come into view, as there’s no sense running an animation while it’s off screen. We used jQuery Waypoints to monitor the page’s scroll position, adding an animate class to each wrapper div when it comes into view. The addition of that class sets off the CSS animation sequence.
.animating-element { position: absolute; top: 10px; right: 40px; } /* animate class added via JavaScript/Waypoints based on scroll position */ .animate { .animating-element { animation: moveAround 0.7s ease 0s 1 normal forwards; } } |
This approach worked well and helped us keep each animation block self-contained and modular. It provided a common and easily customizable HTML & CSS structure for each animation, and less capable browsers still have access to all the content in a well styled page. Within that stage box we can add any other content or elements we need.
The browser chrome animations have multiple elements with multiple animations applied, so getting the timing just right became rather tedious. Because separate animations are completely independent in CSS, there’s no simple way to tell a browser to “start animationY 2.1 seconds after animationX completes.” Instead, you need to do the calculations yourself and hard code them into each animation declared in the CSS, liberally using animation-duration and animation-delay to fire off each step of the scene in sequence. The mental gymnastics go something like this:
Step 1 has a 0.7 second delay and runs for 1.5 seconds. Then Step 2 should start 1.4 seconds after Step 1 completes, so it should have a delay of… 3.6 seconds. Step 2 runs for 2 seconds, and Step 3 needs to begin a quarter of a second before Step 2 completes, so Step 3 needs a delay of 5.35 seconds…
As you can imagine, the more elements you animate and the more steps you have in the sequence, the harder the math becomes. Adjusting the timing of one step in the chain can mean adjusting all the subsequent steps to compensate.
Designer Ty Flanagan created video mockups in Adobe After Effects to serve as a guide for the CSS animation, which was an enormous help. There was still a fair amount of fine tuning to be done by hand, constantly refreshing the page and tweaking a few milliseconds until it just “felt right,” but that process could have taken much longer without the videos for reference.
Another way to do all of this would have been controlling the chained animations in JavaScript, relying on the animationend event to fire off the next step in the sequence. However, a bunch of event listeners and setTimeout calls in a script probably wouldn’t have been a faster or better approach.
Some of our favorite animations are the customize icons, mostly because the circular mask effect is so neat in its simplicity.
The key to achieving the circular mask is a bit of absolute positioning and the incredibly versatile border-radius. The markup isn’t too complex – a stage to contain everything, a div for the circular mask, and whatever elements need to be animated.
<div class="stage"> <div class="circle-mask"></div> <div class="animated" id="animated-block1"></div> <div class="animated" id="animated-block2"></div> </div> |
If you’d like to see an example and play around with the code before reading about the methodology, here’s a little demo on CodePen.
The stage has a set height and width with a hidden overflow and relative positioning. The background color of the stage fills the circular mask.
.stage { position: relative; width: 300px; height: 180px; overflow: hidden; background: #fff; } |
The circular mask is absolutely positioned at the center of the stage, calculated by (stage width - (mask width + mask border width))/2 (this equation could be simpler with box-sizing: border-box). The mask has a wide enough border to reach just past the furthest boundary of the stage. The border bumping up against the page background is what completes the illusion of the mask, so the mask’s border color matches that of the section’s background color (sadly, this means the technique only works with a solid colored background).
To make sure the mask covers the animated elements, it has a z-index at least one higher than the front-most animated element.
.circular-mask { position: absolute; width: 164px; height: 164px; border: 100px solid #ccc; border-radius: 50%; top: -100px; left: -32px; z-index: 2; } /* animated elements share absolute positioning and a z-index lower than .circular-mask */ .animated { position: absolute; z-index: 1; } |
The only requirement for the animated elements is that they reside inside the stage and have a z-index lower than the mask. Otherwise, anything goes.
Though purely flair (as opposed to the feature demonstrations provided by the browser chrome animations), these circular animations were fun to build and we’re very pleased with the result.
When we first watched a video mockup of the proposed intro animation for the new Firefox for Desktop landing page, we wondered if this was actually possible to pull off in a web browser. The animation involves a series of moving lines which fill in as the outlines fade onto the web page, creating an illustrated image of the Firefox browser. Definitely not a typical animation you see on the web every day!
The first step on the path of discovery was to choose an appropriate image format. SVG seemed like the most obvious choice, given that the images needed to scale. Nobody on the team had any prior experience with SVG animation but it seemed like a fun challenge! Ty came up with a rough demo showing how we might use SVG path strokes for the moving lines, which seemed like a perfect starting point. We could have chosen to use an SVG animation library such Raphael or SnapSVG, but we wanted to try to keep our dependencies as light as possible (we had plenty already; no reason to add any more if we can avoid it). The timing and intricacies of the animation made a strong case for trying to use CSS keyframe animations, and this would also be a good opportunity to show off their potential. It was then we recalled this really clever technique that could pull off the same line-drawn effect using CSS.
The trick to the line drawing effect is to animate the stroke-dashoffset of an SVG image path. The stroke-dasharray property allows you to apply a dashed border effect to the outline of an SVG image. The clever part is that if you set the length of the dash equal to the total length of the image path, you can then animate stroke-dashoffset to make it appear as if the line is being drawn one segment at a time. Magic!
Here’s an example of an SVG path:
|
And some CSS to animate it:
.circle { stroke-dasharray: 117; stroke-dashoffset: 117; animation: draw-circle 5s linear forwards; } @keyframes draw-circle { 100% { stroke-dashoffset: 0; } } |
You can find the required length of a path pretty easily using a bit of JavaScript:
var circle = document.querySelector('.circle'); var length = circle.getTotalLength(); |
The animation on the finished page is quite a bit more complicated than this example, but hopefully you can get the idea. We also animated fill-opacity and stroke-opacity to color in the browser panels and fade out the lines at the end of the animation, leaving a scalable vector drawing of the new Firefox.
As well as animating the line drawing, we also needed to scale the image as it zooms onto the page. From there, the icons also zoom into their appropriate places. This was all done using regular CSS transforms via translate and scale.
There are some notable cross-browser inconsistencies here when it comes to scaling SVG using this method. Both Chrome and Safari render a bitmap of an SVG prior to performing a CSS transform. This is presumably for performance reasons, but it does lead to blurry images when you blow them up. Firefox seems to weigh up performance and image quality a little differently, and renders sharper images when they scale. To get around the resizing issues, the best solution was to render icons at their largest size initially and then scale them down, as opposed to the other way around. It seems browsers still have some work to do in this area in order to improve SVG rendering under these circumstances.
Combining all the separate CSS keyframe animations together was probably the most time consuming task. We can also look forward to the day when we no longer need vendor prefixes for CSS keyframe animations, as the duplication of code required is still a bit undesirable. Aside from this, getting the timing right was once again the trickiest part. For a less-than-5-second animation, having to reload and run through the whole sequence over and over made the process pretty time consuming (here’s another vote for that CSS animation editor).
The final result of all this work is a set of pages that beautifully show off what the new desktop Firefox looks like while also showing off what it can do with open web technologies. If you haven’t yet, please do check it out. It’s all responsive, mobile-friendly, progressively enhanced, retina-ready, and still pretty light weight all things considered. And without a single byte of Flash.
This article was co-written by Jon Petto and Alex Gibson, with editorial assistance from Craig Cook.
https://blog.mozilla.org/webdev/2014/08/14/animating-firefox-desktop/
|
|
Nicholas Nethercote: The story of a tricky bug |
A few weeks ago I skimmed through /r/firefox and saw a post by a user named DeeDee_Z complaining about high memory usage in Firefox. Somebody helpfully suggested that DeeDee_Z look at about:memory, which revealed thousands of blank windows like this:
| | +----0.15 MB (00.01%) ++ top(about:blank, id=1001)
| | +----0.15 MB (00.01%) ++ top(about:blank, id=1003)
| | +----0.15 MB (00.01%) ++ top(about:blank, id=1005I filed bug 1041808 and asked DeeDee_Z to sign up to Bugzilla so s/he could join the discussion. What followed was several weeks of back and forth, involving suggestions from no fewer than seven Mozilla employees. DeeDee_Z patiently tried numerous diagnostic steps, such as running in safe mode, pasting info from about:support, getting GC/CC logs, and doing a malware scan. (Though s/he did draw the line at running wireshark to detect if any unusual network activity was happening, which I think is fair enough!)
But still there was no progress. Nobody else was able to reproduce the problem, and even DeeDee_Z had trouble making it happen reliably.
And then on August 12, more than three weeks after the bug report was filed, Peter Van der Beken commented that he had seen similar behaviour on his machine, and by adding some logging to Firefox’s guts he had a strong suspicion that it was related to having the “keep until” setting for cookies set to “ask me every time”. DeeDee_Z had the same setting, and quickly confirmed that changing it fixed the problem. Hooray!
I don’t know how Peter found the bug report — maybe he went to file a new bug report about this problem and Bugzilla’s duplicate detection identified the existing bug report — but it’s great that he did. Two days later he landed a simple patch to fix the problem. In Peter’s words:
The patch makes the dialog for allowing/denying cookies actually show up when a cookie is set through the DOM API. Without the patch the dialog is created, but never shown and so it sticks around forever.
This fix is on track to ship in Firefox 34, which is due to be released in late November.
There are a number of takeaway lessons from this story.
First, a determined bug reporter is enormously helpful. I often see vague complaints about Firefox on websites (or even in Bugzilla) with no responses to follow-up questions. In contrast, DeeDee_Z’s initial complaint was reasonably detailed. More importantly, s/he did all the follow-up steps that people asked her/him to do, both on Reddit and in Bugzilla. The about:memory data made it clear it was some kind of window leak, and although the follow-up diagnostic steps didn’t lead to the fix in this case, they did help rule out a number of possibilities. Also, DeeDee_Z was extremely quick to confirm that Peter’s suggestion about the cookie setting fixed the problem, which was very helpful.
Second, many (most?) problems don’t affect everyone. This was quite a nasty problem, but the “ask me every time” setting is not commonly used because causes lots of dialogs to pop up, which few users have the patience to deal with. It’s very common that people have a problem with Firefox (or any other piece of software), incorrectly assume that it affects everyone else equally, and conclude with “I can’t believe anybody uses this thing”. I call this “your experience is not universal“. This is particular true for web browsers, which unfortunately are enormously complicated and have many combinations of settings get little or no testing.
Third, and relatedly, it’s difficult to fix problems that you can’t reproduce. It’s only because Peter could reproduce the problem that he was able to do the logging that led him to the solution.
Fourth, it’s important to file bug reports in Bugzilla. Bugzilla is effectively the Mozilla project’s memory, and it’s monitored by many contributors. The visibility of a bug report in Bugzilla is vastly higher than a random complaint on some other website. If the bug report hadn’t been in Bugzilla, Peter wouldn’t have stumbled across it. So even if he had fixed it, DeeDee_Z wouldn’t have known and probably would have had been stuck with the problem until Firefox 34 came out. That’s assuming s/he didn’t switch to a different browser in the meantime.
Fifth, Mozilla does care about memory usage, particularly cases where memory usage balloons unreasonably. We’ve had a project called MemShrink running for more than three years now. We’ve fixed hundreds of problems, big and small, and continue to do so. Please use about:memory to start the diagnosis, and add the “[MemShrink]” tag to any bug reports in Bugzilla that relate to memory usage, and we will triage them in our fortnightly MemShrink meetings.
Finally, luck plays a part. I don’t often look at /r/firefox, and I could have easily missed DeeDee_Z’s complaint. Also, it was lucky that Peter found the bug in Bugzilla. Many tricky bugs don’t get resolved this quickly.
https://blog.mozilla.org/nnethercote/2014/08/15/the-story-of-a-tricky-bug/
|
|
William Lachance: A new meditation app |
I had some time on my hands two weekends ago and was feeling a bit of an itch to build something, so I decided to do a project I’ve had in the back of my head for a while: a meditation timer.
If you’ve been following this log, you’d know that meditation has been a pretty major interest of mine for the past year. The foundation of my practice is a daily round of seated meditation at home, where I have been attempting to follow the breath and generally try to connect with the world for a set period every day (usually varying between 10 and 30 minutes, depending on how much of a rush I’m in).
Clock watching is rather distracting while sitting so having a tool to notify you when a certain amount of time has elapsed is quite useful. Writing a smartphone app to do this is an obvious idea, and indeed approximately a zillion of these things have been written for Android and iOS. Unfortunately, most are not very good. Really, I just want something that does this:
Yes, meditation can get more complex than that. In Zen practice, for example, sometimes you have several periods of varying length, broken up with kinhin (walking meditation). However, that mostly happens in the context of a formal setting (e.g. a Zendo) where you leave your smartphone at the door. Trying to shoehorn all that into an app needlessly complicates what should be simple.
Even worse are the apps which “chart” your progress or have other gimmicks to connect you to a virtual “community” of meditators. I have to say I find that kind of stuff really turns me off. Meditation should be about connecting with reality in a more fundamental way, not charting gamified statistics or interacting online. We already have way too much of that going on elsewhere in our lives without adding even more to it.
So, you might ask why the alarm feature of most clock apps isn’t sufficient? Really, it is most of the time. A specialized app can make selecting the interval slightly more convenient and we can preselect an appropriate bell sound up front. It’s also nice to hear something to demarcate the start of a meditation session. But honestly I didn’t have much of a reason to write this other than the fact than I could. Outside of work, I’ve been in a bit of a creative rut lately and felt like I needed to build something, anything and put it out into the world (even if it’s tiny and only a very incremental improvement over what’s out there already). So here it is:
The app was written entirely in HTML5 so it should work fine on pretty much any reasonably modern device, desktop or mobile. I tested it on my Nexus 5 (Chrome, Firefox for Android)[1], FirefoxOS Flame, and on my laptop (Chrome, Firefox, Safari). It lives on a subdomain of this site or you can grab it from the Firefox Marketplace if you’re using some variant of Firefox (OS). The source, such as it is, can be found on github.
I should acknowledge taking some design inspiration from the Mind application for iOS, which has a similarly minimalistic take on things. Check that out too if you have an iPhone or iPad!
Happy meditating!
[1] Note that there isn’t a way to inhibit the screen/device from going to sleep with these browsers, which means that you might miss the ending bell. On FirefoxOS, I used the requestWakeLock API to make sure that doesn’t happen. I filed a bug to get this implemented on Firefox for Android.
|
|
Zack Weinberg: I Will File Bugs For You |
This post prompted by Aaron Klotz’s “Diffusion of Responsibility” and Sumana Harihareswara’s “Inessential Weirdnesses in Open Source.”
One of the most common ways to start interacting with a free software project, as opposed to just using the software produced by that project, is when you trip over a bug or a missing feature and now you need to go tell the developers about it. Unfortunately, that process is often incredibly off-putting. If there’s a bug tracking system, it is probably optimized for people who spend all day every day working with it, and may appear to demand all kinds of information you have no idea how to supply. If there isn’t, you’re probably looking at signing up for some sort of mailing list (mailing list! how retro!) Either way, it may not be easy to find, and there’s a nonzero chance that some neckbeard with a bad attitude is going to yell at you. It shouldn’t be so, but it is.
So, I make this offer to you, the general public, as I have been doing for close friends for many years: if you don’t want to deal with that shit, I will file bugs for you. I’ve been on the Internet since not quite the elder days, and I’ve been hacking free software almost as long; I know how to find these people and I know how to talk to them. We’ll have a conversation and we’ll figure out exactly what’s wrong and then I’ll take it from there. I’m best at compilers and Web browsers, but I’ll give anything a shot.
THE FINE PRINT: If you want to take me up on this, please do so only via email; my address is on the Contact page. Please allow up to one week for an initial response, as this service is provided in my copious free time.
Offer valid only for free software (also known as “open source”) (as opposed to software that you are not allowed to modify or redistribute, e.g. Microsoft Word). Offer also only valid for problems which I can personally reproduce; it’s not going to go well for anyone involved if I have to play telephone with you and the developers. Offer specifically not valid for operating system kernels or device drivers of any kind, both because those people are even less pleasant to work with than the usual run of neckbeards, and because that class of bugs tends to be hardware-dependent and therefore difficult for me to personally reproduce on account of I don’t have the exact same computer as you.
The management cannot guarantee this service will cause bugs to actually get fixed in any kind of timely fashion, or, in fact, ever.
|
|
Sean Martell: Mozilla ID Project: Wordmark exploration |
This is the first in a series of live streaming work sessions exploring a refresh of the Mozilla brand ID system.
Today’s session was exploring Fira Sans for our wordmark versus the current Meta Bold. Fira Sans is an open Web font whereas Meta is a closed commercial font. In the video I explore customizing certain characters to make a unique wordmark yet basing it on our Fira font. I also start to explore how we could show data visualization in a logo mark.
More to come! To follow along with this project, feel free to subscribe to the Youtube channel and follow me on twitter.
http://blog.seanmartell.com/2014/08/14/mozilla-id-project-wordmark-exploration/
|
|
Aaron Klotz: Diffusion of Responsibility |
Something that I’ve been noticing on numerous social media and discussion forum sites is that whenever Firefox comes up, inevitably there are comments in those threads about Firefox performance. Given my role at Mozilla, these comments are of particular interest to me.
The reaction to roc’s recent blog post has motivated me enough to respond to a specific subset of comments. These comments all exhibit a certain pattern: their authors are experiencing problems with Firefox, they are very dissatisfied, but they are not discussing them in a way that is actionable by Mozilla.
Mozilla encourages our contributors to run prerelease versions of Firefox, especially Nightly builds. This allows us to do some good old-fashioned dogfooding during the development of a Firefox release.
We also have many tools that run as part of our continuous integration infrastructure. Valgrind, Address Sanitizer, Leak Sanitizer, reference count tracking, deadlock detection, assertions, Talos performance tests, and xperf are some of the various tools that we apply to our builds. I do not claim that this list is exhaustive! :–)
We use numerous technologies to discover problems that occur while running on our users’ computers. We have a crash reporter that (with the user’s consent) reports data about the crash. We have Firefox Health Report and Telemetry that, when consented to, send us useful information for discovering problems.
Our ability to analyze crash report/FHR/telemetry data is limited to those users who consent to share it with us. As much as I am proud of the fact that we respect the privacy of our users, this means that we only receive data from a fraction of them; many users who are experiencing problems are not included in this data.
Despite the fact that we have all of these wonderful tools to help us deliver quality releases, the fact is that they cannot exhaustively catch every possible bug that is encountered out in the wild. There are too many combinations of extensions and configurations out there to possibly allow us to catch everything before release.
That’s where you, our users, come in!
Reddit, Hacker News, Slashdot and other similar sites are fantastic for ranting. I should know — I do it with the best of them! Having said that, they are also terrible for the purposes of bug reporting!
As users it’s easy for us to assume that somebody else will encounter our problems and report them. Unfortunately that is not always the case, especially with a browser that is as configurable as Firefox.
If you are experiencing a bug, the best way to ensure that something can be done about your bug is to report it in Bugzilla. This might seem a little bit intimidating for somebody who is new to bug reporting, but I assure you, Mozillians are really nice! As long as you follow the etiquette guidelines, you’ll be fine! One suggestion though: try to follow our bug writing guidelines. Doing so will maximize the likelihood of a contributor being able to reproduce your problem. In addition to these suggestions for bug filing, I also suggest including certain types of data for specific types of problems:
If you’re experiencing problems with Firefox’s memory use, open a tab, and
point your browser to about:memory. This nifty feature provides a breakdown
of Firefox memory consumption. Save that report and attach it to the bug that
you’ve filed.
If you want report a problem with Firefox being slow, the best way to help us is is to include data that has been generated by the Gecko Profiler. Unfortunately this is tool requires a bit of technical savvy, but attaching the URL of an uploaded profile to your performance bug can be very helpful.
As you can see in our crash report data, crashes reported to Mozilla are ranked by frequency. As you might expect, this implies that it’s often the squeaky wheels that get the grease.
If you have an easily reproducable crash and you are sending your reports to
Mozilla, you can help us by pointing Firefox to about:crashes. This page lists
all of the crash reports that have been generated on your computer. If the crash
that you are experiencing isn’t on our list of top crashers, you can still help
us to fix it: filing a bug that includes multiple crash report URLs from your
about:crashes screen will help tremendously.
If there is one idea that you can take away from this post (a TL;DR, if you will), it is this: Mozilla cannot fix 100% of the bugs that we do not know about.
Taking an active role in the Mozilla community by reporting your issues through the proper channels is the best way to ensure that your problems can be fixed.
EDIT: To be clear: What I am suggesting is that users who are enthusiastic enough to post a comment to Hacker News (for example) should also be savvy enough to be able to file a proper bug report. Please do not misconstrue this post as a demand that novice users start filing bugs.
EDIT August 15, 2014: Nick Nethercote just blogged about a tricky memory bug that couldn’t have been diagnosed without the help of a Redditor whose complaint we steered to Bugzilla.
http://dblohm7.ca/blog/2014/08/14/diffusion-of-responsibility/
|
|
Matt Thompson: What would a web literate school look like? |
As we think about what’s next for Webmaker, we’re conducting interviews to better understand our audience and develop user personas. What challenges do teachers in the classroom face, for example? How can we help them spread web literacy? Here’s what Phil Macoun, an educator from Nanaimo, B.C., had to tell us.
Notes from Phil’s blog
Phil’s been thinking a lot about what “digital literacy” might look like from kindergarten all the way to grade 12. As his school’s Technology Coordinator, he has the opportunity to implement a school-wide curriculum, influencing an entire staff of teachers and several hundred students.
He’s been surveying the landscape. Phil has researched various digital literacy offerings and approaches, including:
He’s familiar with Webmaker tools like Thimble, and has been following Webmaker’s Web Literacy Map.
“The whole maker movement thing is a big part of what I’m thinking about right now. [Mozilla's] web literacy map outlines things kids need to do, but there also need to be attitudes and approaches tied up into the learning. How to design and be creative.”
The biggest challenge for Phil is: how to help busy, time-strapped teachers get started teaching this stuff in their own classrooms. “In terms of implementation, this is where I get stuck,” Phil says. “[Webmaker] has got good ideas — but I don’t know how to scale them up for my school.”
“I can’t possibly do all this myself — I need other teachers to be responsible for implementing it. I need a framework.”
What has worked to help him solve this problem so far? The Common Sense Media “Digital Citizenship” curriculum. By sending his fellow teachers that one link, along with a bit of context and guidance, he was able to offer time-strapped colleagues something close to a turn-key solution. They loved it.
“It lowers the barrier to entry. They can quickly see the grade level, learning outcomes, download a lesson plan, get worksheets. There’s everything they need to get started.”
Phil likes that Common Sense Media also just published an e-book manual for teachers, and says that many other independent schools in BC are now adopting the Common Sense curriculum.
“I mostly get parents coming and saying: thank you for teaching my kids this stuff!” Phil says. “They like that I’m telling their kids how to search the Internet properly. They know that their kids are immersed in this online world, and they’re looking for help to manage it properly.”
How Phil explains digital literacy to parents
Mozilla’s Web Literacy Map is based around exploring, building and connecting. Phil says that parents and colleagues intuitively grasp the value of “Exploring” and “Building” — but less so with “Connecting,” the piece he actually thinks is the most valuable.
“Trying to get people to understand that piece is much harder,” he says. “‘Exploring’ is easy — people want kids to be able to search the internet better. The ‘building’ piece is easy as well — kids programming video games, printing stuff on a 3D printer. Parents love that stuff. Its harder to explain the connecting piece.”
“You want to get from ‘Help me to manage my kids online life’ to ‘help me teach my kids to leverage this tool to its full potential.”
We recently shipped a new series of pages that we think of as a “textbook for web literacy.” I invited Phil to tale a look at the “Privacy” page, from a teacher’s perspective.
“As a busy teacher what I’m looking for is: what’s the stuff that’s relevant to me.
If I was a teacher who didn’t know a lot about this topic, I’m looking for: ‘What am I teaching? What are my learning outcomes? How am I going to do it?’”
“I look at this page and go: I don’t have time to figure this out right now. I had to scroll right down to the very bottom of the page to know that there was stuff here for teachers.”
“If I had a teacher portal, like the Common Sense Media stuff, it could show me what the different elements of the Web Literacy thing might look like in primary school, vs middle school, vs high school, etc. When it’s all kinda jumbled up, I don’t have time to pick out the good stuff.”
“I’d love to use badges as a formative assessment tool in my classroom. A more fluid way students could celebrate their learning. Maybe I could find a way to loop badges into what my kids are already doing with Google Docs, or Scratch, or TinkerPad. That would be really cool.”
Google Apps recently became Aspengrove school’s go-to digital platform. They moved the whole school over to it. Every student from grade 8 and up now has a Google Apps email address.
“All our students are doing their writing in Google Docs now.”
In a way, Phil’s school is using Google Docs the same way Mozilla uses etherpads — for immediate web-based collaboration.
“The first thing teachers and students do is open up a Google Doc and start putting all their ideas in one document. In many cases, teachers have been writing alongside the kids, so that students can get comments from the teacher as they go. And teachers are doing most of their classroom presentations in Google Docs as well.”
I found this interview hugely insightful. I’m going to think some more about analysis, early conclusions and next steps. But in the mean time: what do you think? Please share your thoughts as comments on this post.
|
|
Sriram Ramasubramanian: Multiple Text Layout |
The pretty basic unit for developing UI in Android is a View. But if we look closely, View is a UI widget that provides user interaction. It comprises of Drawables and text Layouts. We see drawables everywhere — right from the background of a View. TextView has compound drawables too. However, TextView has only one layout. Is it possible to have more than one text layout in a View/TextView?
Let’s take an example. We have a simple ListView with each row having an image, text and some sub-text. Since TextView shows only one text Layout by default, we would need a LinearLayout with 2 or 3 views (2 TextViews in them) to achieve this layout. What if TextView can hold one more text layout? It’s just a private variable that can be created and drawn on the Even if it can hold and draw it, how would we be able to let TextView’s original layout account for this layout?
If we look at TextView’s onMeasure() closely, the available width for the layout accounts for the space occupied by the compound drawables. If we make TextView account for a larger compound drawable space on the right, the layout will constrain itself more. Now that the space is carved out, we can draw the layout in that space.
private Layout mSubTextLayout;
@Override
public int getCompoundPaddingRight() {
// Assumption: the layout has only one line.
return super.getCompoundPaddingRight() + mSubTextLayout.getLineWidth(0);
}
Now we need to create a layout for the sub-text and draw. Ideally it’s not good to create new objects inside onMeasure(). But if we take care of when and how we create the layouts, we don’t have to worry about this restriction. And what different kind of Layouts can we create? TextView allows creating a BoringLayout, a StaticLayout or a DynamicLayout. BoringLayout can be used if the text is only single line. StaticLayout is for multi-line layouts that cannot be changed after creation. DynamicLayout is for editable text, like in an EditText.
@Override
public void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
int width = MeasureSpec.getSize(widthMeasureSpec);
// Create a layout for sub-text.
mSubTextLayout = new StaticLayout(
mSubText,
mPaint,
width,
Alignment.ALIGN_NORMAL,
1.0f,
0.0f,
true);
// TextView doesn't know about mSubTextLayout.
// It calculates the space using compound drawables' sizes.
super.onMeasure(widthMeasureSpec, heightMeasureSpec);
}
The mPaint used here has all the attributes for the sub-text — like text color, shadow, text-size, etc. This is what determines the size used for a text layout.
@Override
public void onDraw(Canvas canvas) {
// Do the default draw.
super.onDraw(canvas);
// Calculate the place to show the sub-text
// using the padding, available width, height and
// the sub-text width and height.
// Note: The 'right' padding to use here is 'super.getCompoundPaddingRight()'
// as we have faked the actual value.
// Draw the sub-text.
mLayout.draw(canvas);
}
But hey, can’t we just use a Spannable text? Well… what if the name is really long and runs into multiple lines or need to be ellipsized?
By this, we use the same TextView to draw two layouts. And that has helped us remove 2 Views! Happy hacking! ;)
P.S: The icons are from: http://www.tutorial9.net/downloads/108-mono-icons-huge-set-of-minimal-icons/
http://sriramramani.wordpress.com/2014/08/14/multiple-text-layout/
|
|
Hub Figui`ere: I was at Guadec |
I was at Guadec in Strasbourg - thanks to all the volunteers who helped making this event possible.. For those who don't know Guadec is the annual Gnome User And Developer European Conference. I hadn't attended since 2008 — such is life — but I reconnected with people I hadn't seen in a while, as well as met awesome people that joined the project since. Attending this year made me regain a lot of motivation on why a Free Software desktop and why Gnome are really necessary. This is even more important as to why at Mozilla I use Fedora Linux rather than MacOS X like most of my team mates —*hint* at least on Fedora I don't have code signing break existing apps, and I have a real full screen browser to use to do presentation based on web technologies or even the risk that one day third party browser be barred like they are on iOS — and it is important to keep the alternatives alive. And Matthew Garrett gave us, during his keynote, good arguments on the importance of a Free Software desktop designed with users in mind.
I'll defintely try to figure out how I can make it to G"oteborg, Sweden next year ; this year was facilitated by having a work week in Paris just before Guadec. Maybe I'll even present something as I resumed working on my projects.
http://www.figuiere.net/hub/blog/?2014/08/13/852-i-was-at-guadec
|
|
Daniel Stenberg: I’m with Firefox OS! |
I have received a Firefox OS tablet as part of a development program. My plan is to use this device to try out stuff I work on and see how it behaves on Firefox OS “for real” instead of just in emulators or on other systems. While Firefox OS is a product of my employer Mozilla, I personally don’t work particularly much with Firefox OS specifically. I work on networking in general for Firefox, and large chunks of the networking stack is used in both the ordinary Firefox browser like on desktops as well as in Firefox OS. I hope to polish and improve networking on Firefox OS too over time.
The primary development device for Firefox OS is right now apparently the Flame phone, and I have one of these too now in my possession. I took a few photos when I unpacked it and crammed them into the same image, click it for higher res:
Firefox OS is an Android kernel (including drivers etc) and a bionic libc – simply the libc that Android uses. Linux-wise and slightly simplified, it runs a single application full-screen: Firefox, which then can run individual Firefox-apps that appears as apps on the phone. This means that the underlying fundamentals are shared with Android, while the layers over that are Firefox and then a world of HTML and javascript. Thus most of the network stack used for Firefox – that I work with – the http, ftp, dns, cookies and so forth is shared between Firefox for desktop and Firefox for Android and Firefox OS.
Firefox OS is made to use a small footprint to allow cheaper smartphones than Android itself can. Hence it is targeted to developing nations and continents.
Both my devices came with Firefox OS version 1.3 pre-installed.
The specs: Qualcomm Snapdragon 1.2GHZ dual-core processor, 4.5-inch 854x480 pixel screen, five-megapixel rear camera with auto-focus and flash, two-megapixel front-facing camera. Dual-SIM 3G, 8GB of onboard memory with a microSD slot, and a 1800 mAh capacity battery.
The Flame phone should be snappy enough although at times it seems to take a moment too long to populate a newly shown screen with icons etc. The screen surface is somehow not as smooth as my Nexus devices (we have the 4,5,7,10 nexuses in the house), leaving me with a constant feeling the screen isn’t cleaned.
Its dual-sim support is something that seems ideal for traveling etc to be able to use my home sim for incoming calls but use a local sim for data and outgoing calls… I’ve never had a phone featuring that before. I’ve purchased a prepaid SIM-card to use with this phone as my secondary device.
I like the feel of the tablet. It feels like a solid and sturdy 10'' tablet, just like it should. I think the design language of Firefox OS for a newbie such as myself is pleasing and good-looking. The quad-core 1GHz thing is certainly fast enough CPU-wise to eat most of what you can throw at it.
These are really good devices to do web browsing on as the browser is a highly capable and fast browser.
Mapping: while of course there’s Google maps app, using the openstreetmap map is great on the device and Google maps in the browser is also a perfectly decent way to view maps. Using openstreetmap also of course has the added bonus that it feels great to see your own edits in your own neck of the woods!
I really appreciate that Mozilla pushes for new, more and better standardized APIs to enable all of this to get done in web applications. To me, this is one of the major benefits with Firefox OS. It benefits all of us who use the web.
Firefox OS feels highly US-centric (which greatly surprised me, seeing the primary markets for Firefox OS are certainly not in the US). As a Swede, I of course want my calendar to show Monday as the first day of the week. No can do. I want my digital clock to show me the time using 24 hour format (the am/pm scheme only confuses me). No can do. Tiny teeny details in the grand scheme of things, yes, but annoying. Possibly I’m just stupid and didn’t find how to switch these settings, but I did look for them on both my devices.
The actual Firefox OS system feels like a scaled-down Android where all apps are simpler and less fancy than Android. There’s a Facebook “app” for it that shows Facebook looking much crappier than it usually does in a browser or in the Android app – although on the phone it looked much better than on the tablet for some reason that I don’t understand.
I managed to get the device to sync my contacts from Google (even with my google 2-factor auth activated) but trying to sync my Facebook contacts just gave me a very strange error window in spite of repeated attempts, but again that worked on my phone!
I really miss a proper back button! Without it, we end up in this handicapped iphone-like world where each app has to provide a back button in its own UI or I have to hit the home button – which doesn’t just go back one step.
The tablet supports a gesture, pull up from the button of the screen, to get to the home screen while the phone doesn’t support that but instead has a dedicated home button which if pressed a long time shows up cards with all currently running apps. I’m not even sure how to do that latter operation on the tablet as it doesn’t’ have a home button.
The gmail web interface and experience is not very good on either of the devices.
I’ve only just started this venture and dipped my toes in that water. All code is there in the open and you build it all with open tools. I might get back on this topic later if I get the urge to ventilate something from it… :-) I didn’t find any proper device specific setup for the tablet, but maybe I just don’t know its proper code word and I’ve only given it a quick glance so far. I’ll do my first builds and installs for the phone. Any day now!
My seven year old son immediately found at least one game on my dev phone (he actually found the market and downloaded it all by himself the first time he tried the device) that he really likes and now he wants to borrow this from time to time to play that game – in competition with the android phones and tablets we have here already. A pretty good sign I’d say.
Firefox OS is already a complete and competent phone operating system and app ecosystem. If you’re not coming from Android or Iphone it is a step up from everything else. If you do come from Android or Iphone I think you have to accept that this is meant for the lower end spectrum of smart-phones.
I think the smart-phone world can use more competition and Firefox OS brings exactly that.
|
|
Matt Brubeck: Let's build a browser engine! Part 3: CSS |
This is the third in a series of articles on building a toy browser rendering engine. Want to build your own? Start at the beginning to learn more:
- Part 1: Getting started
- Part 2: Parsing HTML
- Part 3: CSS
This article introduces code for reading Cascading Style Sheets (CSS). As usual, I won’t try to cover everything in the spec. Instead, I tried to implement just enough to illustrate some concepts and produce input for later stages in the rendering pipeline.
Here’s an example of CSS source code:
h1, h2, h3 { margin: auto; color: #cc0000; }
div.note { margin-bottom: 20px; padding: 10px; }
#answer { display: none; }
Next I’ll walk through the css module from my toy browser engine, robinson. The code is written in Rust, though the concepts should translate pretty easily into other programming languages. Reading the previous articles first might help you understand some the code below.
A CSS stylesheet is a series of rules. (In the example stylesheet above, each line contains one rule.)
struct Stylesheet {
rules: Vec<Rule>,
}
A rule includes one or more selectors separated by commas, followed by a series of declarations enclosed in braces.
struct Rule {
selectors: Vec<Selector>,
declarations: Vec<Declaration>,
}
A selector can be a simple selector, or it can be a chain of selectors joined by combinators. Robinson supports only simple selectors for now.
Note: Confusingly, the newer Selectors Level 3 standard uses the same terms to mean slightly different things. In this article I’ll mostly refer to CSS2.1. Although outdated, it’s a useful starting point because it’s smaller and more self-contained than CSS3 (which is split into myriad specs that reference both each other and CSS2.1).
In robinson, a simple selector can include a tag name, an ID prefixed by
'#', any number of class names prefixed by '.', or some combination of the
above. If the tag name is empty or '*' then it is a “universal selector” that
can match any tag.
There are many other types of selector (especially in CSS3), but this will do for now.
enum Selector {
Simple(SimpleSelector),
}
struct SimpleSelector {
tag_name: Option<String>,
id: Option<String>,
class: Vec<String>,
}
A declaration is just a name/value pair, separated by a colon and ending
with a semicolon. For example, "margin: auto;" is a declaration.
struct Declaration {
name: String,
value: Value,
}
My toy engine supports only a handful of CSS’s many value types.
enum Value {
Keyword(String),
Color(u8, u8, u8, u8), // RGBA
Length(f32, Unit),
// insert more values here
}
enum Unit { Px, /* insert more units here */ }
All other CSS syntax is unsupported, including @-rules, comments, and any selectors/values/units not mentioned above.
CSS has a regular grammar, making it easier to parse correctly than its quirky cousin HTML. When a standards-compliant CSS parser encounters a parse error, it discards the unrecognized part of the stylesheet but still processes the remaining portions. This is useful because it allows stylesheets to include new syntax but still produce well-defined output in older browsers.
Robinson uses a very simplistic (and totally not standards-compliant) parser, built the same way as the HTML parser from Part 2. Rather than go through the whole thing line-by-line again, I’ll just paste in a few snippets. For example, here is the code for parsing a single selector:
/// Parse one simple selector, e.g.: `type#id.class1.class2.class3`
fn parse_simple_selector(&mut self) -> SimpleSelector {
let mut result = SimpleSelector { tag_name: None, id: None, class: Vec::new() };
while !self.eof() {
match self.next_char() {
'#' => {
self.consume_char();
result.id = Some(self.parse_identifier());
}
'.' => {
self.consume_char();
result.class.push(self.parse_identifier());
}
'*' => {
// universal selector
self.consume_char();
}
c if valid_identifier_char(c) => {
result.tag_name = Some(self.parse_identifier());
}
_ => break
}
}
result
}
Note the lack of error checking. Some malformed input like ### or *foo*
will parse successfully and produce weird results. A real CSS parser would
discard these invalid selectors.
Specificity is one of the ways a rendering engine decides which style overrides the other in a conflict. If a stylesheet contains two rules that match an element, the rule with the matching selector of higher specificity can override values from the one with lower specificity.
The specificity of a selector is based on its components. An ID selector is more specific than a class selector, which is more specific than a tag selector. Within each of these “levels,” more selectors beats fewer.
pub type Specificity = (uint, uint, uint);
impl Selector {
pub fn specificity(&self) -> Specificity {
// http://www.w3.org/TR/selectors/#specificity
let Simple(ref simple) = *self;
let a = simple.id.iter().len();
let b = simple.class.len();
let c = simple.tag_name.iter().len();
(a, b, c)
}
}
(If we supported chained selectors, we could calculate the specificity of a chain just by adding up the specificities of its parts.)
The selectors for each rule are stored in a sorted vector, most-specific first. This will be important in matching, which I’ll cover in the next article.
/// Parse a rule set: ` { }`.
fn parse_rule(&mut self) -> Rule {
Rule {
selectors: self.parse_selectors(),
declarations: self.parse_declarations()
}
}
/// Parse a comma-separated list of selectors.
fn parse_selectors(&mut self) -> Vec<Selector> {
let mut selectors = Vec::new();
loop {
selectors.push(Simple(self.parse_simple_selector()));
self.consume_whitespace();
match self.next_char() {
',' => { self.consume_char(); }
'{' => break, // start of declarations
c => fail!("Unexpected character {} in selector list", c)
}
}
// Return selectors with highest specificity first, for use in matching.
selectors.sort_by(|a,b| b.specificity().cmp(&a.specificity()));
selectors
}
The rest of the CSS parser is fairly straightforward. You can read the whole thing on GitHub. And if you didn’t already do it for Part 2, this would be a great time to try out a parser generator. My hand-rolled parser gets the job done for simple example files, but it has a lot of hacky bits and will fail badly if you violate its assumptions. Eventually I hope to replace it with one built on rust-peg or similar.
As before, you should decide which of these exercises you want to do, and skip the rest:
Implement your own simplified CSS parser and specificity calculation.
Extend robinson’s CSS parser to support more values, or one or more selector combinators.
Extend the CSS parser to discard any declaration that contains a parse error, and follow the error handling rules to resume parsing after the end of the declaration.
Make the HTML parser pass the contents of any
http://limpet.net/mbrubeck/2014/08/13/toy-layout-engine-3-css.html
|
|
Mozilla Release Management Team: Firefox 32 beta5 to beta6 |
| Extension | Occurrences |
| cpp | 8 |
| js | 6 |
| h | 6 |
| html | 2 |
| build | 2 |
| xul | 1 |
| xml | 1 |
| sh | 1 |
| py | 1 |
| java | 1 |
| ini | 1 |
| in | 1 |
| c | 1 |
| Module | Occurrences |
| content | 9 |
| mobile | 4 |
| js | 4 |
| mozglue | 3 |
| browser | 3 |
| media | 2 |
| dom | 2 |
| toolkit | 1 |
| testing | 1 |
| netwerk | 1 |
| modules | 1 |
| build | 1 |
List of changesets:
| Matthew Gregan | Bug 992238 - Disable test_init_destroy_multiple_contexts_and_streams on Windows 7. r=padenot, a=test-only - 980f2d449ccb |
| Martijn Wargers | Bug 928678 - Hopeful fix for intermittent failure. r=jmaher, a=test-only - 04f540c59457 |
| Chris Pearce | Bug 1046003 - Ensure duplicate frames after a seek have an Image. r=kinetik, a=sledru - 91f078c385f8 |
| Mike Hommey | Bug 1036286 - Delay registration of the faulty.lib signal handler until when it's necessary. r=nfroyd, a=sledru - ec230387fad2 |
| Mike Hommey | Bug 1036286 - Ensure faulty.lib diverts libc's sigaction instead of a LD_PRELOADed one. r=nfroyd, a=sledru - 1f96d584763a |
| Bobby Holley | Bug 1042436 - Always enter the wrapper's compartment before invoking SilentFailure. r=gabor, a=sledru - 6037db66624b |
| Bobby Holley | Bug 1042436 - Lowercase the "reason" param to SilentFailure. a=sledru - 4cb373d9ce33 |
| Bobby Holley | Bug 1042436 - Warn once to the console when XrayWrappers deny access to an object. r=gabor, sr=smaug, a=sledru - 1cf7b5810eb5 |
| Ryan VanderMeulen | Backed out changesets 1cf7b5810eb5, 4cb373d9ce33, and 6037db66624b (Bug 1042436) for bustage. - 53c7aceaf1a8 |
| Bobby Holley | Bug 1042436 - Always enter the wrapper's compartment before invoking SilentFailure. r=gabor - 08c5b02a125e |
| Bobby Holley | Bug 1042436 - Lowercase the "reason" param to SilentFailure. r=me - 84bf42618416 |
| Bobby Holley | Bug 1042436 - Warn once to the console when XrayWrappers deny access to an object. r=gabor,sr=smaug a=sylvestre - c405f720f587 |
| Georg Fritzsche | Bug 1048793 - Skip CertUtils checks as we changed providers and PublicKeyPinningService already provides them. r=mmc, a=sledru - 7aa9781a3758 |
| Marco Bonardo | Bug 997970 - Add search suggest to Amazon for en-US. r=ttaubert, a=sledru - 3f7ae08da07f |
| Paul Adenot | Bug 1047831. r=ehsan, a=sledru - 0c488a1d2142 |
| Richard Newman | Bug 1050690. r=wesj, a=sledru - 6b9281a057b7 |
| Tim Taubert | Bug 1048133 - Check key algorithms before using them for encryption/signatures r=rbarnes a=abillings - 6a7e6708ded1 |
| Cosmin Malutan | Bug 1032255 - TPS has to exit with code != 0 in case of failures. r=aeftimie, dhunt a=testonly DONTBUILD - 1b581df81c9b |
| Mike Hommey | Bug 1048064 - Fix libstagefright build on GNU/kFreeBSD. r=ajones, a=NPOTB - 2e0eeb786e7d |
| Karl Tomlinson | Bug 995075 - Include update_filter() changes from upstream speexdsp. r=padenot, a=sledru - 92c3567e5a0c |
| Patrick McManus | Bug 1045640 - disable tls proxying Bug 378637 on gecko 32 r=backout a=lmandel r=hurley - c9dec07b4148 |
| Ryan VanderMeulen | Backed out changeset 551f71d3138f (Bug 1038243) - b8d426a326f5 |
| Richard Newman | Bug 936851 - Part 1: Remove VideoPlayer. r=mfinkle, a=lmandel - e9fc6b3efaf3 |
| Richard Newman | Bug 936851 - Part 2: Delegate to Fennec itself for YouTube video instead of VideoPlayer. r=mfinkle, a=lmandel - 086068fe1b98 |
| Wes Johnston | Bug 1046500 - Fix mediagroup parsing in feed parser. r=mak, a=sledru - f76498a1bcbd |
| Lawrence Mandel | Post Beta 4: disable EARLY_BETA_OR_EARLIER a=me - 8bf5700cb82e |
http://release.mozilla.org//statistics/32/2014/08/13/fx-32-b5-to-b6.html
|
|
Robert Nyman: Neurodiversity |
A couple of months ago I got invited by Maja Brisvall, who works at Stockholm Resilience Centre and Shift, for two sessions with Kathryn Myronuk and Brad Templeton from Singularity University.
They were very interesting, and delivered by two highly intelligent persons with great insight. One thing that stood out to me was something that Kathryn said, on discussing group dynamics, team work and learning (and I’m probably paraphrasing like hell now):
You got to respect the neurodiversity of the group. Some people will be loud and seem to be the most ambitious, where others can be quiet for 10 minutes and then ask just one question, but wow, what a question!
And this really struck me: having been, like most people, in so many different contexts for learning – in school, work, conferences, workshops and more, some of the most obvious faults – or lack of successes – have been forcing people to have an opinion or conclusion right away. If you don’t ask a question immediately, you’re not interested or have nothing to contribute.
Or in the name of inclusivity, do a round of the entire room where everyone immediately has to have and express an opinion, take or query. That’s not how it works and not how it has to work. Humans are so diverse in how they are analyzing facts and impressions, how they gain perspective and clarity.
And I think this applies not only to learning but also online conversations as well, like Twitter, Facebook, YouTube comments (*shivers*) and more. One of the only things we know for sure is that people are very different, and we need to keep that in mind in our communication. Make sure that everyone gets a chance to learn, grasp and take it all in. To express themselves.
So next time you believe someone is a slow learner, doesn’t get it, is just provoking or similar, take one step back. Give them a chance, engage in constructive conversation and give them the room they need.
Respect the neurodiversity.
|
|
Henrik Skupin: Firefox Automation report – week 27/28 2014 |
In this post you can find an overview about the work happened in the Firefox Automation team during week 27 and 28.
Henrik continued his work on our QA specific PuppetAgain setup. One of the blockers for us was bug 997721, which is the full proxy support on OS X and Linux. By week 27 we were finally able to get this finished. Further Henrik also got the manifest for installing Java done.
On TPS we also made progress. So Cosmin got the Pulse listener script implemented for the Coversheet CI, which triggers TPS tests whenever new nightly builds of Firefox have been made available. Further a couple of fixes for Mozrunner were necessary given that the 6.0 release caused a couple of regressions for TPS. As result we agreed on to pin Python package dependencies to specific versions of mozrunner and related packages.
One big thing for our team is also to assist people in the decision, if automated tests are possible for certain Firefox features. The questions mainly come up for tests, which cannot be implemented for any of our developer driven test frameworks due to limitations on buildbot (no network access allowed, restart of the application, and others…). To be more successful in the future, Henrik started a discussion on the dev-quality mailing list. We hope to get the proposed process established for bug verification.
For more granular updates of each individual team member please visit our weekly team etherpad for week 27 and week 28.
If you are interested in further details and discussions you might also want to have a look at the meeting agenda, the video recording, and notes from the Firefox Automation meetings of week 27 and week 28.
http://www.hskupin.info/2014/08/13/firefox-automation-report-week-27-28-2014/
|
|
Kat Braybrooke: Call for Artists, Technologists + Curators: Mozfest 2014, London |
Exciting news today — we’ve just launched a Public Call to bring artists, curators and creatives together in London for the first-ever “Art & Culture of the Web" track at the Mozilla Festival this October — and you are invited!
Each year, MozFest is built around a set of core tracks featuring topics that have the greatest potential for innovation and empowerment with the Web, bringing in 1,000+ innovators to the shores of the Thames to build and make together. And this year, my co-conspirator Paula le Dieu and I will be bringing together a brand new topic, “Art & Culture of the Web”, to explore the ways millions of users around the world are making the transition from consumers to creators, merging art, technology and networks to build new forms with unprecedented results.
We are especially interested in finding out what the combination of these experiments in theory, code and creativity — a practice we refer to as "networked art" — might mean for cultural heritage organizations, artists, technologists and curators? And how might creative works inform our understandings of the open web’s key challenges, from privacy to ownership, and from identity to governance?
From the launch of OPEN STUDIO, a groundbreaking site where participatory artworks will be created live, to a youth-led gallery curated by Hive Learning Networks, and from a global GLAM (Gallery, Library, Archive and Museum) skill-shares, this track is already shaping up to be the most creative experiment Mozfest has ever seen. And as you may have seen from my experience wrangling the Build and Teach the Web track at last year’s Mozfest, it will also be a massive — and very inspiring — party.
Come and make with us by submitting an idea to the Call for Artists, Technologists + Curators by August 22, 2014. We welcome your craziest and most audacious dreams and brainstorms. In return, we’ll leave you with hands covered in electronic paint. Already excited for the creative moments yet to come.
|
|
Matej Novak: Angry and sad… |
Depression has taken another person from the world. That he was funny and talented doesn’t make it any more or less upsetting. It just means more people know about it — but it happens to others every day.
I’ve never been suicidal, but I have struggled with depression. I know the hopelessness. I know how trapped and alone it can make you feel. I hope it never takes me to darker places than it already has.
All I can do is think about my son. How do I protect him? How do I keep him from feeling the way I have at my lowest? How I keep him from feeling the way I feel today?
The deeply unsatisfying answer is, of course, that I don’t. Not for sure, anyway. I can only do my best — love him, teach him and pick him up when he falls down. And hope that it’s enough.
|
|
Ben Hearsum: Upcoming changes to Mac package layout, signing |
Apple recently announced changes to how OS X applications must be packaged and signed in order for them to function correctly on OS X 10.9.5 and 10.10. The tl;dr version of this is “only mach-O binaries may live in .app/Contents/MacOS, and signing must be done on 10.9 or later”. Without any changes, future versions of Firefox will cease to function out-of-the-box on OS X 10.9.5 and 10.10. We do not have a release date for either of these OS X versions yet.
Changes required:
* Move all non-mach-O files out of .app/Contents/MacOS. Most of these will move to .app/Contents/Resources, but files that could legitimately change at runtime (eg: everything in defaults/) will move to .app/MozResources (which can be modified without breaking the signature): https://bugzilla.mozilla.org/showdependencytree.cgi?id=1046906&hide_resolved=1. This work is in progress, but no patches are ready yet.
* Add new features to the client side update code to allow partner repacks to continue to work. (https://bugzilla.mozilla.org/show_bug.cgi?id=1048921)
* Create and use 10.9 signing servers for these new-style apps. We still need to use our existing 10.6 signing servers for any builds without these changes. (https://bugzilla.mozilla.org/show_bug.cgi?id=1046749 and https://bugzilla.mozilla.org/show_bug.cgi?id=1049595)
* Update signing server code to support new v2 signatures.
Timeline:
We are intending to ship the required changes with Gecko 34, which ships on November 25th, 2014. The changes required are very invasive, and we don’t feel that they can be safely backported to any earlier version quickly enough without major risk of regressions. We are still looking at whether or not we’ll backport to ESR 31. To this end, we’ve asked that Apple whitelist Firefox and Thunderbird versions that will not have the necessary changes in them. We’re still working with them to confirm whether or not this can happen.
This has been cross posted a few places – please send all follow-ups to the mozilla.dev.platform newsgroup.
http://hearsum.ca/blog/upcoming-changes-to-mac-package-layout-signing/
|
|
Gervase Markham: Absence |
I will be away and without email from Thu 14th August to Friday 22nd August, and then mostly away from email for the following week as well (until Friday 29th August).
http://feedproxy.google.com/~r/HackingForChrist/~3/7IKmHotDuV4/
|
|