Air Mozilla: Martes mozilleros |
Reuni'on bi-semanal para hablar sobre el estado de Mozilla, la comunidad y sus proyectos. Bi-weekly meeting to talk (in Spanish) about Mozilla status, community and...
|
|
Planet Mozilla Interns: Willie Cheong: Academics Complete |
I’ve written many last exams before. But today I finish writing my last, last exam; graduation awaits. Life is pretty exciting right now. School has been an amazing experience, but being done feels much better.
Goodbye Waterloo; Hello World!
|
|
Byron Jones: happy bmo push day! |
the following changes have been pushed to bugzilla.mozilla.org:
discuss these changes on mozilla.tools.bmo.
https://globau.wordpress.com/2015/04/14/happy-bmo-push-day-136/
|
|
Air Mozilla: Elasticsearch Meetup |
Join us as Mozilla hosts an ElasticSearch meetup, featuring a duo inviting you along on a whirlwind dive of the ElasticSearch .NET client
|
|
Jet Villegas: Gaia Tips and Tricks for Gecko Hackers |
I’m often assigned Firefox Rendering bugs in bugzilla. By the time a bug gets assigned to me, the reporter had usually exhausted other options and assumed (correctly) that I’m ultimately responsible for fixing Firefox rendering bugs. Of course, I often have to reassign most bugs to more capable individuals.
Some of the hardest bugs to assign are the ones reported by our own Gaia team: the team responsible for building the user experience in Firefox OS. The Gaia engineers take CSS and JavaScript and build powerful mobile apps like the phone dialer and SMS client. When they report bugs, it’s often found within lots of CSS and JS code. I wanted to learn how to effectively reduce the time it takes to resolve rendering issues reported by the Gaia team. It takes a long time to go from a Gaia bug like “scrolling in the gallery app is slow” to find the underlying Gecko bug, for example “rounding issue creates an invalidation rectangle that is too large.”
To do that, I became a Gaia developer for a few days at our Paris office. I reasoned that if I could learn how they work, then I can help my team boil down issues faster and become more responsive to their needs. We already recognize the value of having expert web application developers on staff, but we could do a better job with a better understanding of how they work. With that in mind, I spent the week without any C++ code to look at, and dived into the world of mobile web app development.
I wrote down the steps I took to set up a FirefoxOS build and test environment in an earlier post This time, I’ll list a few of the tips and tricks I learned while I was working with the Gaia developers.
The first and most important tip: You will brick the phone when working on the OS. In fact, you’re probably not trying hard enough if you don’t brick it 
Fastboot lets you connect ADB to the phone when it becomes unresponsive to flash the device with a known good system (like the base image.) Learn how to manually force fastboot on your phone.
Julien showed me how to maintain a Gaia developer profile on your desktop development environment. This set of commands will configure your B2G build to produce the desktop B2G runtime that’s a bit easier to debug than a device build:
# change value of the FIREFOX to point to the full path to the B2G desktop build export FIREFOX=/Volumes/firefoxos/B2G/build/dist/B2G.app/Contents/MacOS/b2g export PROFILE_FOLDER=gaia-profile DEBUG=1 DESKTOP=0 make
With a Gaia developer profile, you can switch between B2G desktop and a regular Firefox browser build for testing:
export FIREFOX=/full/path/to/desktop/browser $FIREFOX -profile gaia-profile --no-remote app://sms.gaiamobile.org
The Gaia profile lets you use URL’s like app://sms.gaiamobile.org to run the Gaia apps on the desktop browser. This trick alone was a huge time saver! Try it with other URL’s like app://communications.gaiamobile.org
For a first Gaia development project, I picked up the implementation of the new card view for gaia that is based on an asynchronous panning and zooming (APZC.) Etienne did the initial proof-of-concept and my goal is to rebase/finish/polish it and add some CSS Scroll Snapping features. My initial tests for this feature are very promising. CSS Scroll Snapping is much more responsive than the previous JavaScript-based implementation. I’m still working out some bugs but hope to land my first Gaia pull request soon.
I’ve already been able to apply what I’ve learned to triage bugs like this one. The bug started out described as a problem with how we launch GMail on B2G in Arabic language. Based on the testing tricks I learned from Gaia team, I was able to distill it to a root cause with scrollbar rendering on right-to-left (RTL) languages. I added a simplified test case to the bug that should greatly reduce debugging time, and assigned it to one of our RTL experts. That’s quite a bit better than assigning tough bugs to random developers with the entire OS as the test case!
Thanks to Julien and Ettiene for helping me get up to speed. I highly recommend that any Gecko engineer spend a few days as a Gaia hacker. I’m humbled by the ingenuity these developers have for building the entire OS user experience with only the capabilities offered by the Web. We could all learn a lot in the trenches with these hackers!
http://junglecode.net/gaia-tips-and-tricks-for-gecko-hackers/
|
|
John O'Duinn: “why work doesnt happen at work” by Jason Fried on TEDx |
While reading “Remote”, I accidentally found this TEDx talk by one of the authors, Jason Fried. Somehow I’d missed this when it first came out in 2010, so stopped to watch it. I’ve now watched this a few times in a row, found it just as relevant today as it was 4-5 years ago, so am writing this blogpost.
The main highlights for me were:
1) work, like sleep, needs solid uninterrupted time. However, most offices are designed to enable interrupts. Open plan layouts. Phones. Casual walk-by interrupts from managers asking for status. Unneeded meetings. They are not designed for uninterrupted focus time. No-one would intentionally plan to have frequently-interrupted-sleep every night and consider it “good”, so why set up our work environments like this?
2) Many people go into the office for the day, attempting to get a few hours uninterrupted work done, only to spend time reacting to interrupts all day, and then lament at the end of the day that “they didn’t get anything done”! Been there, lived through that. As a manager, he extols people to try things like “no-talking-Thursdays”, just to see if people can actually be more productive.
3) The “where do you go when you really want to get work done” part of his presentation nailed it for me. He’s been asking people this question for years, and the answers tend to fall into three categories:
… and he noted that no-one said “the office during office hours”!! The common theme is that people use locations where they can focus, knowing they will not get interrupted. When I need to focus, I know this is true for me also.
All of which leads to his premise that organizing how people work together, with most communication done in a less interruptive way is really important for productivity. Anyone who has been at one of my remoties sessions knows I strongly believe this is true – especially for remoties! He also asked why businesses spend so much money on these counter-productive offices.
Aside: I found his “Facebook and twitter are the modern day smoke breaks” comment quite funny! Maybe thats just my sense of humor. Overall, its a short 15min talk, so instead of your next “facebook/twitter/smokebreak”, grab a coffee and watch this. You’ll be glad you did.
http://oduinn.com/blog/2015/04/13/why-work-doesnt-happen-at-work-by-jason-fried/
|
|
Nick Cameron: Contributing to Rust |
http://featherweightmusings.blogspot.com/2015/04/contributing-to-rust.html
|
|
Matt Thompson: Mozilla Learning Networks: what’s next? |
What has the Mozilla Learning Networks accomplished so far this year? What’s coming next in Q2? This post includes a slide presentation, analysis and interview with Mozilla’s Chris Lawrence, Michelle Thorne and Lainie DeCoursy. It’s a summary of a more detailed report on the quarter here. Join the discussion on #teachtheweb.
Establish Mozilla as the best place to teach and learn the web.
Not only the technical aspects of the open web — but also its culture, citizenship and collaborative ethos.
How will we measure that? Through relationships and reach.
2015 goal: ongoing learning activity in 500 cities
In 2015, our key performance indicator (KPI) is to establish ongoing, on-the-ground activity in 500 cities around the world. The key word is ongoing — we’ve had big success in one-off events through programs like Maker Party. This year, we want to grow those tiny sparks into ongoing, year-round activity through clubs and lasting networks.
Maker Party events help active and on-board local contributors. Clubs give them something more lasting to do. Hive Networks grow further into city-wide impact. 
These key initiatives:
teach.mozilla.org will provide a new home for all our teaching offerings — including Maker Party.
What we did: developed the site, which will soft launch in late April.
What’s next: adding dynamic content like blogs, curriculum and community features. Then make it easier for our community to find and connect with each other.
We shipped the model and tested it in 24 cities. Next up: train 10 Regional Coordinators. And grow to 100 clubs.
This is a new initiative, evolved from the success of Maker Party. The goal: take the sparks of activation created through Maker Party and sustain them year-round, with local groups teaching the web on an ongoing basis — in their homes, schools, libraries, everywhere.
What we did:
What’s next:
What we did:
We added four new cities in Q1, bringing our total to 11. Next up: grow to 15.
What’s next:
A global kick-off from July 15 – 31, seeding local activity that runs year-round.
What we did: created a plan for Maker Party 2015, building off our previous success to create sustained local activity around teaching web literacy.
What’s next: this year Maker Party will start with a big two-week global kick-off campaign, July 15-31. We’ll encourage people to try out activities from the new Clubs curriculum.
This year’s MozFest will focus on leadership development and training
Mark your calendars: MozFest 2015 will take place November 6 – 8 in London.
A key focus this year is on leadership development; we’ll offer training to our Regional Co-ordinators and build skill development for all attendees. Plus run another Hive Global meet-up, following on last year’s success.
What’s next: refine the narrative arc leading up to MozFest. Communicate this year’s focus and outcomes.
What we did: In Q1 our focus was on planning and decision making.
What’s next: improve the user experience for badge issuers and earners.
The focus this year is on building partnerships that help us: 1) activate more mentors and 2) reach more cities. This builds on the success of partnerships like National Writing Project (NWP) and CoderDojo, and has sparked conversations with new potential partners like the Peace Corps.
|
|
Air Mozilla: Mozilla Weekly Project Meeting |
The Monday Project Meeting
https://air.mozilla.org/mozilla-weekly-project-meeting-20150413/
|
|
Mozilla Science Lab: Mozilla Science Lab Week in Review, April 6-12 |
The Week in Review is our weekly roundup of what’s new in open science from the past week. If you have news or announcements you’d like passed on to the community, be sure to share on Twitter with @mozillascience and @billdoesphysics, or join our mailing list and get in touch there.
http://mozillascience.org/mozilla-science-lab-week-in-review-april-6-12/
|
|
Chris Ilias: My Installed Add-ons – Keyword Search |
I love finding new extensions that do things I never even thought to search for. One of the best ways to find them is through word of mouth. In this case, I guess you can call it “word of blog”. I’m doing a series of blog posts about the extensions I use, and maybe you’ll see one that you want to use.
My previous posts have been about:
For this blog post, I’ll talk about Keyword Search.
In Firefox, whenever you do a web search from the location bar, it will use the same search engine as in the search bar. Keyword Search allows you to use a separate search engine for location bar web searches. This is really helpful to people like me who mainly use one search engine (for basic web searches) and others for content-specific use cases.
To set your location bar search engine, go to the add-ons manager.
You can install it via the Mozilla Add-ons site.
http://ilias.ca/blog/2015/04/my-installed-add-ons-keyword-search/
|
|
Cameron Kaiser: Darwin Nuke the Refrigerator, Wet Sprocket, etc. |
Two more security notes.
First, as a followup, a couple of you pointed out that there is a writeconfig on 10.4 through 10.6 (and actually earlier) in /System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources. Yes, there is, and it's even setuid root (I wish Apple wouldn't do that). However, it is not exploitable, at least not by systemsetupusthebomb or a similar notion, because it appears to lack the functionality required for that sort of attack. I should have mentioned this in my prior posting.
Second, Darwin Nuke is now making the rounds, similar to the old WinNuke which plagued early versions of Windows until it was corrected in the Windows 95 days in that you can send a specially crafted packet to an OS X machine and kernel panic it. It's not as easy as WinNuke was, though -- that was as simple as opening a TCP connection to port 139 on the victim machine and sending it nonsense data with the Urgent Pointer flag set in the TCP header. Anyone could do that with a modified Telnet client, for example, and there were many fire-and-forget tools that were even easier. Unless you specifically blocked such connections on ingress, and many home users and quite a few business networks didn't at the time, WinNuke was a great means to ruin someone's day. (I may or may not have done this from my Power Mac 7300 a couple times to kick annoying people off IRC. Maybe.)
Darwin Nuke, on the other hand, requires you to send a specially crafted invalid ICMP packet. This is somewhat harder to trigger remotely as many firewalls and routers will drop this sort of malformed network traffic, so it's more of a threat on an unprotected LAN. Nevertheless, an attacker with a raw socket interface can engineer and transmit such packets, and the technical knowledge required is relatively commonplace.
That said, even on my test network I'm having great difficulty triggering this against the Power Macs; I have not yet been able to do so. It is also not clear if the built-in firewall protects against this attack, though the level at which the attack exists suggests to me it does not. However, the faulty code is indeed in the 10.4 kernel source, so if it's there and in 10.10, it is undoubtedly in 10.5 and 10.6 as well. For that reason, I must conclude that Power Macs are vulnerable. If your hardware (or non-OS X) firewall or router supports it, blocking incoming ICMP will protect you from the very small risk of being hit at the cost of preventing pings and traceroutes into your network (but this is probably what you want anyway).
Even if you do get nailed, the good news (sort of) is that your computer can't be hacked by this method that anyone is aware of; it's a Denial of Service attack, you'll lose your work, you may need to repair the filesystem if it does so at a bad time and that sucks, but it doesn't compromise the machine otherwise. And, because this is in open source kernel code, it should be possible to design a fix and build a new kernel if the problem turns out to be easier to exploit than it appears currently. (Please note I'm not volunteering, at least, not yet.)
So, you can all get out of your fridges now, mmkay?
10.4Fx 38 and IonPower update: 50% of V8 passes and I'm about 20% into the test suite. Right now wrestling with a strange bug with return values in nested calls, but while IonPower progress is slow, it's progress!
http://tenfourfox.blogspot.com/2015/04/darwin-nuke-refrigerator-wet-sprocket.html
|
|
Mike Conley: Things I’ve Learned This Week (April 6 – April 10, 2015) |
For example, here is where we synthesize native mouse events for OS X. I think this is mostly used for testing when we want to simulate mouse activity.
Note that if you attempt to replay a queue of synthesized (or cached) native Cocoa events to trackSwipeEventWithOptions, those events might get coalesced and not behave the way you want. mstange and I ran into this while working on this bug to get some basic gesture support working with Nightly+e10s (Specifically, the history swiping gesture on OS X).
We were able to determine that OS X was coalescing the events because we grabbed the section of code that implements trackSwipeEventWithOptions, and used the Hopper Disassembler to decompile the assembly into some pseudocode. After reading it through, we found some logging messages in there referring to coalescing. We noticed that those log messages were only sent when NSDebugSwipeTrackingLogic was set to true, we executed this:
defaults write org.mozilla.nightlydebug NSDebugSwipeTrackingLogic -bool YES
In the console, and then re-ran our swiping test in a debug build of Nightly to see what messages came out. Sure enough, this is what we saw:
2015-04-09 15:11:55.395 firefox[5203:707] ___trackSwipeWithScrollEvent_block_invoke_0 coalescing scrollevents 2015-04-09 15:11:55.395 firefox[5203:707] ___trackSwipeWithScrollEvent_block_invoke_0 cumulativeDelta:-2.000 progress:-0.002 2015-04-09 15:11:55.395 firefox[5203:707] ___trackSwipeWithScrollEvent_block_invoke_0 cumulativeDelta:-2.000 progress:-0.002 adjusted:-0.002 2015-04-09 15:11:55.396 firefox[5203:707] ___trackSwipeWithScrollEvent_block_invoke_0 call trackingHandler(NSEventPhaseChanged, gestureAmount:-0.002)
This coalescing means that trackSwipeEventWithOptions is only getting a subset of the events that we’re sending, which is not what we had intended. It’s still not clear what triggers the coalescing – I suspect it might have to do with how rapidly we flush our native event queue, but mstange suspects it might be more sophisticated than that. Unfortunately, the pseudocode doesn’t make it too clear.
I’m not sure I “learned” this so much, but I saw it in passing this week in this bug. Apparently, there was some section of the Marionette testing framework that was doing request / response logging with toSource and some string templates, and this caused a 20MB regression on AWSY. Doing away with those in favour of old-school string concatenation and JSON.stringify seems to have addressed the issue.
I think I knew this a while back, but I’d forgotten it. I actually re-figured it out during the last episode of The Joy of Coding. When you change the remoteness of a , you can’t just flip the remote attribute and call it a day. You actually have to remove it from the DOM and re-add it in order for the change to manifest properly.
You also have to re-add any frame scripts you had specially loaded into the previous incarnation of the browser before you flipped the remoteness attribute.1
Suppose you got backed out, and want to reland your patch(es) with some small changes. Try this:
hg update -r tip hg graft --force BASEREV:ENDREV
This will re-land your changes on top of tip. Note that you need –force, otherwise Mercurial will skip over changes it notices have already landed in the commit ancestry.
These re-landed changes are in the draft stage, so you can update to them, and assuming you are using the evolve extension2, and commit –amend them before pushing. Voila!
Here’s the documentation for hg graft.
We sidestep this with browser tabs by putting those browsers into “groups”, and having any new browsers, remote or otherwise, immediately load a particular set of framescripts.
http://mikeconley.ca/blog/2015/04/12/things-ive-learned-this-week-april-6-april-10-2015/
|
|
Nick Cameron: New tutorial - arrays and vectors in Rust |
http://featherweightmusings.blogspot.com/2015/04/new-tutorial-arrays-and-vectors-in-rust.html
|
|
Erik Vold: JPM Mobile Beta |
I annouced the release of jpm beta nine months ago, and since then
we’ve most of the SDK modules compatible with jpm, figured out
how to run jpm on travis, and now I’d like to annouce the
beta release of jpm-mobile!
jpm-mobile provides a means for running Jetpacks (aka Add-on SDK add-ons) on Android devices.
This is achieved by communicating through adb, which is required by jpm-mobile.
Installing is easy with npm install jpm-mobile -g, then testing an add-on on Firefox for Android
(aka Fennec) is as simple as plugging the device in to your computer and running:
jpm-mobile run --adb /path/to/adb -b fennec
Note that the add-on’s package.json or install.rdf should be marked as supporting Fennec.
For the former, the package.json should include something like:
{
...
"engines": {
"fennec": "*"
}
...
}
http://work.erikvold.com/jetpack/2015/04/11/jpm-mobile-beta.html
|
|
Hannah Kane: User Testing the Teach Site |
We are soooooo close to releasing the new Teach site.
People seem to dig the bright colors and quirky illustrations throughout the site.
In advance of the release, I wanted to conduct some user tests to make sure we’re still on the right track. This week I conducted two user tests with members of the community (yay!). As is always the case with user testing, I learned a lot from observing users interact with the site.
You can see detailed notes here and read my recommendations below.
These recommendations are based on formal user tests with two users as well as feedback from people who’ve been involved or observing the process throughout. Also, please note that I wasn’t able to test the primary functionality on the site (adding a Club to the map), so these recommendations are more about IA and other content issues.
Findings and Recommendations
ACTIVITIES / CURRICULUM / RESOURCES
Findings:
Recommendations:
CLUBS
Findings:
Recommendations:
In short, I don’t think we’ve yet seen a reason to have the site serve a “selling” or persuasive function. I *do* think the Clubs page is a natural first stop for someone who is looking to understand how to start a Club. I think the changes recommended in the bullet points above address that.
EVENTS/MAKER PARTY
Findings:
Recommendations:
INFORMATION ARCHITECTURE
Findings:
Recommendation:
ADDITIONAL RECOMMENDATIONS
I’m going to keep banging this drum: We need to clarify our audience! I think we’ve made good progress in terms of clarifying that our “first line” audience includes educators and activists. But I think we have to take it a step further and clarify who those educators and activists are working with. There are at least two axes that I think are important to be clear about: first, the global nature of our work, and second, the specific age groups of what I’m calling the “end learners,” for lack of a better term.
I think we do a pretty decent job of conveying the global nature of the program through copy and imagery, though obviously implementing our l10n strategy is absolutely fundamental to this.
I think we are less clear when it comes to the age groups we’re targeting with our programs and materials. For example, I think we ought to specify the appropriate age level for each activity. (And the images, activity titles, and copy should reflect the target audience.)
Questions, comments, disagreements wholeheartedly welcomed!
http://hannahgrams.com/2015/04/10/user-testing-the-teach-site/
|
|
Mark Surman: Q1 Participation update |
I asked two questions about participation back in January: 1. what is radical participation? and 2. what practical steps can we take right now to bring more of it to Mozilla?. It’s been great to see people across Mozilla digging into these questions. I’m writing to offer an update on what I’ve seen happening.
First, we set ourselves a high bar when we started talking about radical participation at Mozilla late last year. I still believe it is the right bar. The Mozilla community needs more scale and impact than it has today if we want to confront the goliaths who would take the internet down a path of monopoly and control.
However, I don’t think we can invent ‘radical’ in the abstract, even if I sometimes say things that make it sound like I do :). We need to build it as we go, checking along the way to see if we’re getting better at aligning with core Mozilla principles like transparency, distributed leadership, interoperability and generativity. In particular, we need to be building new foundations and systems and ways of thinking that make more radical participation possible. Mitchell has laid out how we are thinking about this exploration in three areas (link).
When I look back at this past quarter, that’s what I see that we’ve done.
As context: we laid out a 2015 plan that included a number of first steps toward more radical participation at Mozilla. The immediate objectives in this plan were to a) invest more deeply in ReMo and our regional communities and b) better connect our volunteer communities to the work of product teams. At the same time, we committed to a longer term objective: c) create a Participation Lab (originally called a task force…more on that name change below) charged with looking for and testing new models of participation.
As a way to move the first part of this plan forward, the ReMo Council met in Paris a month or so back. There was a big theme on how to unleash the leadership potential of the Reps program in order to move Mozilla’s core goals forward in ways that take advantage of our community presence around the world. For example, combining the meteoric smartphone growth in India with the local insights of our Indian community to come up with fresh ideas on how to move Firefox for Android towards its growth goal.
We haven’t been as good as we need to be in recent years in encouraging and then actually integrating this sort of ‘well aligned and ambitious thinking from the edge’. Based on reports I’ve heard back, the Paris meeting set us up for more of this kind of thinking. Rosana Ardila and the Council, along with William Quiviger and Brian King, are working on a “ReMo2.0” plan that builds on this kind of approach, that seeks a deeper integration between our ReMo and Regional Community strategies, and that also adds a strong leadership development element to ReMo.
Reps Council and Peers at the 2015 Paris meet-up
On the second part of our plan, the Participation Team has talked to over 100 people in Mozilla product and functional groups in the past few months. The purpose of these conversations was to find immediate term initiatives that create the sort of ‘help us meet product goals’ and ’empower people to learn and do’ virtuous circle that we’ve been talking about in these discussions about radical participation.
Over 40 possible experiments came out of these conversations. They included everything from leveraging Firefox Hello to provide a new kind of support and mentoring; to taking a holistic, Mozilla-wide approach to community building in our African Firefox OS launch markets; to turning Mozilla.org into a hub that lets millions of people play small but active roles in moving our mission forward. I’m interested in these experiments, and how they will feed into our work over the coming quarters—many of them have real potential IMHO.
I’m even more excited about the fact that these conversations have started around very practical ideas about how volunteers and product teams can work more closely together again. It’s just a start, but I think the right questions are being asked by the right people.
The third part of our plan was to set up a ‘Task Force’ to help us unlock bold new thinking. The bold thinking part is still the right thing to aim for. However, as we thought about it, the phrase ‘task force’ seemed too talky. What we need is thoughtful and forceful action that gets us towards new models that we can expand. With that in mind we’ve replaced the task force idea with the concept of a Participation Lab. We’ve hired former Engineers Without Borders CEO George Roter to define and lead the Lab over the next six months. In George’s words:
“The lab is Mozilla, and participation is the topic.”
With this ethos in mind, we have just introduced the Lab as both a way to initiate focused experiments to test specific hypotheses about how participation brings value to Mozilla and Mozillians, and to support Mozillians who have already initiated similar experiments. The Lab will be an engine for learning about what works and what will get us leverage, via the experiments and relationships with people outside Mozilla. I believe this approach will move us more quickly towards our bold new plan—and will get more people participating more effectively along the way. You can learn more about this approach by reading George’s blog post.
There is a lot going on. More than I’ve summarized above. And, more importantly, hundreds of people from across the Mozilla community are involved in these efforts: each of them is taking a fresh look at how participation fits into their work. That’s a good sign of progress.
However, there is only a very small Participation Team staff contingent at the heart of these efforts. George has joined David Tenser (50% of his time on loan from User Success for six months) to help lead the team. Rosana Ardila is supporting the transformation of ReMo along with Rub'en and Konstantina. Emma Irwin is figuring out how we help volunteers learn the things they need to know to work effectively on Mozilla projects. Pierros Papadeas and a small team of developers (Nikos, Tasos and Nemo) are building pieces of tech under the hood. Brian King along with Gen and Guillermo are supporting our regional communities, while Francisco Picolini is helping develop a new approach to community events. William Quiviger is helping drive some of the experiments and invest across the teams in ensuring our communities are strong. As Mitchell and I worked out a plan to rebuild from the old community teams, these people stepped forward and said ‘yes, I want to help everyone across Mozilla be great at participation’. I’m glad they did.
The progress this Participation Team is making is evident not just in the activities I outlined above, but also in how they are working: they are taking a collaborative and holistic approach to connecting our products with our people.
One concrete example is the work they did over the last few months on Mozilla MarketPulse, an effort to get volunteers gathering information about on-the-street smartphone prices in FirefoxOS markets. The team not only worked closely with FirefoxOS product marketing team to identify what information was needed, they also worked incredibly well together to recruit volunteers, train them up with the info they needed on FirefoxOS, and build an app that they could use to collect data locally. This may not sound like a big deal, but it is: we often fail to do the kind of end to end business process design, education and technology deployment necessary to set volunteers up for success. We need to get better at this if we’re serious about participation as a form of leverage and impact. The new Participation Team is starting to show the way.
Looking at all of this, I’m hoping you’re thinking: this sounds like progress. Or: these things sound useful. I’m also hoping you’re saying: but this doesn’t sound radical yet!!! If you are, I agree. As I said above, I don’t think we can invent ‘radical’ in the abstract; we need to build it as we go.
It’s good to look back at the past quarter with this in mind. We could see the meeting in Paris as just another ReMo Council gathering. Or, we could think of it—and follow up on it—as if it was the first step towards a systematic way for Mozilla to empower people, pursue goals and create leaders on the ground in every part of the world. Similarly, we could look at MarketPulse as basic app for collecting phone prices. Or, we could see it as a first step towards building a community-driven market insights strategy that lets us outsee— and outsmart—our competitors. It all depends how we see what we’re doing and what we do next. I prefer to see this as the development of powerful levers for participation. What we need to do next is press on these levers and see what happens. That’s when we’ll get the chance to find out what ‘radical’ looks like.
PS. I still owe the world (and the people who responded to me) a post synthesizing people’s suggestions on radical participation. It’s still coming, I promise. :/
https://commonspace.wordpress.com/2015/04/10/q1-participation-update/
|
|
Aaron Thornburgh: Mobile Minded |
Imagining the future of New Tab for Firefox Android.
For over a year, the Content Services team has been busy evolving New Tab beyond a simple directory of recent, frequently visited sites. Once Firefox 39 lands on desktops later this summer, New Tab will include an updated interface, better page controls, and suggested content from our partners. With any luck, these and future products releases for the desktop browser will facilitate more direct, deeper relationships between brands and users. Most importantly (to me, anyway), richer controls on New Tab will also offer users more customization and better utility.
While this ongoing project work has certainly kept me busy, I can’t help but think about “the next big thing” whenever I have the chance. Lately, my mind has been preoccupied with a question that’s easy to ask, but much more difficult to answer:
How could Suggested Sites and more advanced controls work on mobile?
Providing Firefox Desktop users with more control over the sites they see on New Tab is relatively straightforward. The user is likely seated, focused entirely on the large screen in front of them, and is using a mouse pointer to activate hover states. These conditions are appropriate for linear, deliberate interactions. Therefore, New Tab on desktop can take advantage of the inherent screen real estate and mouse precision to support advanced actions like editing or adding sites. And since New Tab is literally one page, users can’t get really get “lost”.
Mobile is altogether different. The user may be standing, sitting, or on the move. Their attention is divided. Screens are physically smaller, yet still support resolutions comparable to larger desktop displays. More importantly, there aren’t any hover states, and mobile interactions are imprecise (which is maybe why we call them “gestures”). Because of this imprecision on handheld screens, a tap often launches another view or state that may the user to another destination – and after a few taps, the user may find themselves down a navigational rabbit hole that’s cumbersome to climb out of. Combined, these factors sometimes make it hard to perform complex actions on a mobile device. Likewise, any action made by the user should be minimal, simple to perform, and always contextual.
Taking all of the above into consideration, the following is an early peek at my vision for the New Tab experience on Firefox Android, with user control in mind.
+++++
New Tab on either desktop or mobile devices has always been about one thing: Helping users navigate the Web more efficiently.
Today, New Tab shows a two-column grid of rectangles depicting Websites they recently visited. While it may make the destination page easier to see, this is an inefficient use of space.
By shrinking the rectangles, more of them can fit onto the page; and by showing a logo instead of a Web page (when possible), identifying individual sites becomes easier too. These smaller “tiles” could even be grouped, just as the user would group apps on their device home screen.
Some folks may also be interested in discovering something entirely new on the Web. The future New Tab could serve suggested content for these users, based on their browsing history (and with permission, of course). But instead of commandeering a tile, suggestions could be delivered natively, and in line with the user’s history list.
Viewing suggested content in other applications typically launches a new app or another tab in the user’s browser. Yet it only takes a second or two for the user to decide if the content is actually interesting to them. Personally, I think it would be better to give users a preview of the content, and then give them the option of dismissing it or continuing on without leaving the page they’re on.
Shown above, I image that after tapping a suggested item, New Tab could slide away to the left, revealing a preview of the suggested content beneath. If the user scrolls to view more content, a button then slides into view at the bottom of the screen, taking them the destination page suggested on-tap. If they aren’t interested in reading further, they would simply tap the navigation bar (below the search bar) to return to New Tab. Meanwhile, they never actually “left” the original screen.
However, if the user does find the suggested content interesting, then they should be able to add the destination site directly to New Tab. One solution may be allowing users to drag-and-drop a Web address from the search bar and into New Tab. Perhaps by dragging the address onto another tile, users could even create a new group of related sites.
If a user doesn’t care for a particular suggestion, however, then deleting it – or any item on New Tab, for that matter – should be as easy as dragging it off either edge of the screen. Borrowing from another popular email application, swiping an item would reveal the word “delete” beneath, further reinforcing the action being performed. Naturally, this may sometimes happen by accident. As such, a temporary button could appear that allows the user to retrieve the item previously listed, then disappear after a few seconds.
Alternatively, a user could add a new site directly from New Tab. Tapping the “+” button would launch a native keyboard and other controls, allowing them to search for a URL, define the tile’s appearance, or opt-out of related content suggestions. For extra clarification – and a little fun – the user would literally “build” their tile in real-time. Selecting any URL from the search bar dropdown would update the example tile shown, displaying a logo by default. Or, the user may choose instead to show an image of the destination homepage, or the last page they visited.
What I’ve proposed should be taken with a few grains of salt. For one, I believe that limiting the need for new, fancy gestures encourages adoption and usage. Likewise, many of these interactions aren’t especially novel. In fact, most of them are intended to mimic native functions a user may find elsewhere on his or her Android device. My ultimate goal here was to introduce new features available on Firefox that won’t require a steep learning curve.
For another, the possibilities for New Tab on mobile devices are numerous, and exciting to think about – but any big changes are a long ways away. By the time a new big update for Firefox on Android lands, this post will probably to totally irrelevant. But in the meantime, I hope to plant a few seeds that will take root and develop further as my team, and many others at Mozilla, contemplate the future of Firefox for the mobile Web.
|
|
Mike Conley: The Joy of Coding (Ep. 9): More View Source Hacking! |
In this episode1, I continued the work we had started in Episode 8, by trying to make it so that we don’t hit the network when viewing the source of a page in multi-process Firefox.
It was a little bit of a slog – after some thinking, I decided to undo some of the work we had done in the previous episode, and then I set up the messaging infrastructure for talking to the remote browser in the view source window.
I also rebased and landed a patch that we had written in the previous episode, after fixing up some nits2.
Then, I (re)-learned that flipping the “remote” attribute of a browser is not enough in order for it to run out-of-process; I have to remove it from the DOM, and then re-add it. And once it’s been re-added, I have to reload any frame scripts that I had loaded in the previous incarnation of the browser.
Anyhow, by the end of the episode, we were able to view the source from a remote browser inside a remote view source browser!3 That’s a pretty big deal!
Bug 1025146 – [e10s] Never load the source off of the network when viewing source – Notes
A note that I also tried an experiment where I keep my camera running during the entire session, and place the feed into the bottom right-hand corner of the recording. It looks like there were some synchronization issues between audio and video, which are a bit irritating. Sorry about that! I’ll see what I can do about that.
http://mikeconley.ca/blog/2015/04/10/the-joy-of-coding-ep-9-more-view-source-hacking/
|
|
Air Mozilla: Webmaker Demos April 10 2015 |
Webmaker Demos April 10 2015
|
|