K Lars Lohn: Redneck Broadband - from 28Kbps to 28Mbps in an Afternoon |
http://www.twobraids.com/2014/02/redneck-broadband-from-28kbps-to-28mbps.html
|
|
Sean Bolton: Firefox Context Menu – Drag-and-Share Design Concepts |
After the research phase of the context menu, is the design phase. Myself along with a few other from the Firefox UX team met to do some ideation and brainstorming. We generated many ideas and then consolidated them into a few main themes. The first of these themes is what I call ‘drag-and-share.’
I noticed during my research that users would commonly drag content they wished to do something with (e.g. drag an image to their desktop). This habit is built in to how people use computers. Now that act of dragging content in and of itself was not the end goal, that content was often shared in some way. So we asked, why make the users go through multiple steps to drag to holding location, load a new page and drag to place they can share – what if dragging content triggered sharing options? That’s what drag-and-share is all about.
Below is a link to some slides of several design concepts for this feature. I welcome any and all feedback – do so by email, contact form or comment below. Thank you! Once the design of this feature is complete, I will build it as an add-on for people to try 
http://seanbolton.me/2014/02/25/firefox-context-menu-drag-and-share-design-concepts/
|
|
Andy McKay: Teachers |
And so it begins again. The BCTF and the BC Government go head to head over the teachers contract. Of one thing we can be certain, it will be long, slow, painful and plenty of muck will be thrown around in the public.
This is the Government that:
"unconstitutionally stripped from their contract in 2002"
In fact Christie Clark was the Education Minister in 2002 when this happened.
Fast forward to 2011 and the Supreme Court finds Ms Clarks bill unconstitutional. Following appeal, a recent ruling by the justice found that:
"One of the problems was that the government representatives were preoccupied by another strategy. Their strategy was to put such pressure on the union that it would provoke a strike by the union. The government representatives thought this would give government the opportunity to gain political support for imposing legislation on the union."
So what happened today? The BCTF decided to call strike vote and get out into the public the things that happened at the bargaining table. It was called a trial by media. I call it making it public.
As for the Government?
"I guess all I can say is our actions speak for themselves"
They do Mr. Fassbender.
|
|
Byron Jones: happy bmo push day! |
the following changes have been pushed to bugzilla.mozilla.org:
discuss these changes on mozilla.tools.bmo.
http://globau.wordpress.com/2014/02/25/happy-bmo-push-day-84/
|
|
Mike Hommey: Analyzing shared cache on try |
As mentioned in previous post, shared cache is now effective on try for linux and linux64, opt and debug builds, provided the push has changeset a62bde1d6efe in its history. The unknown in that equation was how long it takes for landings in mozilla-inbound or mozilla-central to propagate to try pushes.
So I took a period of about 8 days and observed, on a sliding 24-hours window, the percentage of pushes containing that changeset, and to see if the dev-tree-management post had an impact, I also looked at a random mozilla-central changeset, 339f0d450d46. This is what this looks like:
So it takes about 2 days and a half for a mozilla-central changeset to propagate to most try pushes, and it looks like my dev-tree-management post (which was cross-posted on dev-platform) didn’t have an impact, although 339f0d450d46 is close enough to the announcement that it could still be benefitting from it. I’ll revisit this with future unannounced changes.
The drop that can be seen on February 16 is due to there being less overall pushes over the week-end, and that somehow made pushes without changeset a62bde1d6efe more prominent. Maybe contributors pushing on the week-end are more likely to push old trees.
Now, let’s see what effect shared cache had on try build times. I took about the last two weeks of successful try build logs for linux and linux64, opt and debug, and analyzed them to extract the following data:
There sadly weren’t enough PGO builds to plot anything about them, so I just excluded them. Then, since the shared cache is only enabled on AWS builds, and since AWS and in-house build times are so different, I excluded in-house builds. Further looking at the build times for linux opt, linux64 opt, linux debug and linux64 debug, they all looked similar enough that they didn’t need to be split in different buckets.
Update: I should mention that I also excluded my own try pushes because I tended to do multiple rebuilds on them, with all of them getting near 100% cache hit and best build times.
Sorting all that data by build time, the following are graphs showing how many builds took less than a given build time.
For unified sources builds (1111 builds with ccache, 870 builds with shared cache):
For non-unified sources builds (332 builds with ccache, 302 builds with shared cache):
The first thing to note is that this does include the very first try pushes with shared cache, which probably skews the slowest builds. It should also be noted that linux debug builds are (still) currently non-unified by default for some reason.
With that being said, for unified sources builds, there are about 3.25% of the builds that end up slower with shared cache than with ccache, and 5.2% for non-unified builds. Most of that is on the best build times end, where builds with shared cache can spend twice the time we’d spend with ccache. I’m currently working on changes that should make the difference slimmer (more on that in a subsequent post). Anyways, that still leaves more than 90% builds faster with shared cache, and makes for a big improvement in build times on average:
| Unified | Non-unified | |||
|---|---|---|---|---|
| shared | ccache | shared | ccache | |
| Average | 17:11 | 29:19 | 30:58 | 57:08 |
| Median | 13:30 | 30:10 | 22:27 | 60:57 |
Interestingly, a few of the fastest non-unified builds with shared cache were significantly faster than the others, and it looks like what they have in common is that they were built on the US-East-1 region, instead of US-West-2 region. I haven’t looked into more details as to why those particular builds were much faster.
|
|
Mark Coggins: V'ictor Jos'e Cara Rodr'iguez demos his local app SurfTime at the... |
V'ictor Jos'e Cara Rodr'iguez demos his local app SurfTime at the Mozilla booth at 2014 Mobile World Congress (photo credit: Mozilla in Europe).
|
|
William Reynolds: Plans to improve the vouching process for mozillians.org |
As we grow to a Million Mozillians, we want to make sure tools like our community directory at mozillians.org can support that growth, and we’re working on some improvements based on feedback from many Mozillians.
During the last two months ideas for mozillians.org sign ups were shared on the community-building and mozillians mailing lists, and the Community Tools team has iterated on those original ideas based on the very useful feedback received. Specifically, we have identified ways to make vouching more meaningful with vouch descriptions and to set criteria for who can vouch others. We then received positive support at a recent Grow Mozilla meeting.
A simplified overview of what’s happening
The detailed plans are described on the wiki page about vouching.
The Community Tools team is getting started with implementing these changes, and we will make announcements to Mozillians with our progress and when these changes are made in the next few months. Our team is excited to help scale the number of people on mozillians.org, and we think these changes, while perhaps not a perfect solution, are a step in the right direction. If you have feedback to share, post it to on the Community Tools discussion forum.
http://dailycavalier.com/2014/02/plans-to-improve-the-vouching-process-for-mozillians-org/
|
|
Joel Maher: tracking talos alerts across branches |
A year without blogging and I am back. I figured there was some cool stuff to share, here is one tidbit.
In the last year I have picked up looking at talos results and filing regression bugs for results. This has been useful. What currently happens is when results are submitted to g.m.o (graph server) we detect a regression and send out an email to the original patch author (if we can determine it) and post to mozilla.dev.tree-management. I have been using dev.tree-management as a starting point for my hunting regressions. When things are busy it can eat up a couple hours in a day. Luckily many developers are responsible in taking action when they receive the emails.
Given that at least half of the regressions are not acted upon by the original developer, it is important to read the newsgroup. One of the things which makes it frustrating is that for a single regression we can get multiple alerts (regular builds vs pgo builds and as the patch merges between branches/projects).
To make my life easier, I have taken all the alerts on dev.tree-management and put them in a database (local right now). The final goal is a webUI that lets me easily annotate these alerts similar to tbpl for random test failures. One thing I wanted to do was help identify duplicate alerts. Today in my attempt I had a clear picture of what the lifecycle of a regression looks like:
mysql> select date,branch,percent,keyrevision from alerts where test=’Paint’ and platform=’WINNT 6.2 x64' order by date ASC;
+———————+————————-+———+————–+
| date | branch | percent | keyrevision |
+———————+————————-+———+————–+
| 2014-02-14 19:41:38 | Mozilla-Inbound-Non-PGO | 10.1% | c7802c9d6eec |
| 2014-02-15 01:03:54 | Fx-Team-Non-PGO | 9.53% | 7a3adc5aac28 |
| 2014-02-15 21:43:48 | Mozilla-Inbound | 10.6% | c7802c9d6eec |
| 2014-02-16 03:46:12 | Firefox-Non-PGO | 8.88% | 5d7caa093f4f |
| 2014-02-16 03:46:13 | B2g-Inbound-Non-PGO | 9.44% | 071885f79841 |
| 2014-02-16 14:22:38 | Fx-Team | 10.4% | 7a3adc5aac28 |
| 2014-02-17 04:42:57 | B2g-Inbound | 10.7% | 071885f79841 |
| 2014-02-18 11:43:54 | Firefox | 9.76% | eac89fb04bb9 |
+———————+————————-+———+————–+
8 rows in set (0.00 sec)
This is really cool to see how 1 change can generate alerts for 4 days.
Stay tuned for more information on this and other topics!
http://elvis314.wordpress.com/2014/02/24/tracking-talos-alerts-across-branches/
|
|
Benjamin Kerensa: Mozilla at Southern California Linux Expo |
From Wednesday through Sunday, I was in Los Angeles for the Southern California Linux Expo (Scale12x) held at the Hilton LAX. This was my first Scale12x and this was the second year that Mozilla had official presence.
To be honest, I’m not totally sure what I was expecting when going to Scale12x. I thought it was going to be a typical regional linux expo but Scale12x was a larger event then I could have imagined.
Thursday, I spent a lot of time meeting with Firefox Users and people from other open source projects. In the evening, I joined Brandon Burton (Mozilla), Chris Turra (Mozilla), Jordan Sissel (Elasticsearch) and Michael Stahnke (PuppetLabs) for a DevOps Dinner.
On Friday, I took the opportunity to visit a number of talks including Brandon Burton’s lightning talk during the DevOps track. I met up with Casey Becking, a fellow Mozilla Rep, and we hung out, visited some talks, and checked out the expo floor in advance of setup.
That evening myself, Casey Becking and Joanna Mazgaj went out for a Mozilla Group Dinner. We went to a place called Akbar in Marina Del Rey. The dinner was excellent and it was great to get together and spend time with fellow reps before the expo floor opened.
Saturday and Sunday were the days of the expo hall and I woke up about 6:00am and headed down to setup our booth early. By 9:00am we were starting to see the first attendees trickle in. I would estimate in the first few hours we saw close to five hundred attendees and by end of day closer to a thousand.
At one point, a group of students stopped by from L.A.’s Roosevelt High School and I gave them a short overview of Mozilla OpenBadges and discussed how their school could use the platform to recognize students for various achievements. The faculty the accompanied the students said they were very interested in the program.
There was a tremendous amount of interest surrounding Firefox OS I would say 90% or better of attendees that visited the booth demoed Firefox OS or asked questions. Many asked us when they could buy a device in North America.
To my knowledge we were only asked about Directory Tiles on two occasions. Both of those conversations were positive once we explained it some and pointed out Mitchell’s blog post.
Sunday was a bit slower since most attendees has visited the booth although some people who arrived last day for the expo did stop by and some attendees visited us again. All in all, the event was very positive and a lot of buzz was generated in addition to getting information out there about how to contribute to Firefox OS, where a device can be purchased, and the progress of the project.
|
|
Asa Dotzler: Tablet Contribution Program Applications are Open |
(Re-posted from the Mozilla Hacks Blog)
Last month, Mozilla announced the Tablet Contribution Program to help deliver Firefox OS to the tablet form factor. Today, we are excited to open the Application for Hardware Support to Mozillians all over the world who will sign up to contribute to Firefox OS coding, testing, localizing, and product planning.
The first device for this program is the 10'' InFocus tablet from Foxconn, with a 1.0GHz Quad-Core Cortex-A7 processor.
 |
Brand/Model: Foxconn InFocus |
Today, we’re also excited to announce an upcoming addition to the program, a 7'' Vixen tablet from VIA, with a 1.2Ghz Dual core Cortex-A9 processor.
 |
Brand/Model: VIA Vixen |
We have limited quantities of these developer devices so we’re looking for dedicated contributors who can commit to regular testing and reporting of defects, identifying and documenting feature gaps with competitor tablets, triaging incoming bug reports, localizing and translating UI, prioritizing work and building roadmaps, hacking on existing features and bugs, defining new features and experiences, and more.
If that sounds exciting to you, and you’ve got time and skills to work with Mozilla to make a real difference in the tablet space, apply now for free developer tablet hardware from Mozilla.
|
|
Paul Rouget: Firefox OS: Tracking reflows and event loop lags |
Developer HUD: new tools in Firefox OS 1.4
In this article, I'm talking about Firefox OS apps, but this is true for any web pages, on any browser.
If you already have a good understanding of what the event loop is and what reflows are, just jump to the end of this article to see how to find janks in your Firefox OS app.
Any layout engine (Gecko, Webkit, …) is driven by an event loop.
This is how it works:
Think slow motion. At anytime, in the main thread, gecko holds a list of events to be processed. Events can be: "user clicked", "a XMLHttpRequest is done", "page has closed", "a setTimeout reached its delay", "painting the screen is needed", "mouse moved", "the user scrolled", …
Gecko will consume the oldest event and execute code. If there is a JS callback
to execute, like addEventListener("click", onClick), gecko will
run the callback onClick **to completion**.
When the JS code has fully completed being executed, gecko will consume the next event.
Maybe it's time to update the page on the screen. Gecko will then draw.
Operations are executed sequentially. One after the other. JavaScript functions don't run in parallel:
setTimeout(callback, 10); foobar(); If foobar takes 100ms, callback
will be only executed after these 100ms. Because foobar blocks the event loop. The timeout event can't be
treated.
If an operation takes more than 16 milliseconds (1000ms / 60), gecko won't be able to draw at 60FPS. A frame will be skipped. Ideally, no operations should take more than 16ms. It's not always possible (because the developer doesn't control all the things happening in the event loop, it's sometimes gecko's responsibility), but with a good understanding of the event loop, many slow operations can be avoided by the web developer.
JavaScript can be slow for many reasons. Because of a big loop, because of DOM operations, because of long synchronous calls like localStorage. Making sure these JS "run to completion" don't block the event loop for too long is important.
Each Firefox OS app runs in its own process. Each process has its own event loop. The event loop runs in the main thread. There are other threads running (for network requests, composition, media decoding, …), but the UI of the app is rendered in the main thread. So if the event loop is blocked, the UI of the app is frozen. This is barely noticeable on desktop browsers, but with Firefox OS (and on any mobile device in general) any slow operation in the event loop will make the app choppy.
Computing the layout of a page
A reflow is when the layout engine needs to calculate the position and/or the size of an element on the page. Reflows happen in the main thread, they block the event loop. And again, can make gecko skip frames.
There are various reasons why a reflow will be necessary: page is resized, a CSS property or a JS function change the size or position of a node, a node is added/removed from the page (DOM operations).
When CSS and JS change the layout, a reflow is not immediately triggered. The layout is flagged as "dirty" (invalid). BUT, at some point, gecko has to reflow: right before drawing the page, or if a JS code requests the size/position of a node.
Let's look at this code:
1 div1.style.margin = "200px";
2 var height1 = div1.clientHeight;
3 div2.classList.add("foobar");
4 var height2 = div2.clientHeight;
5 doSomething(height1, height2);
Line 1, layout is marked as invalid. Line 2, to get clientHeight,
gecko needs to compute the new size of div1. A reflow is triggered.
Line 3, layout is marked as invalid. Line 4, a reflow is triggered again.
It's possible to batch the invalidations to get only one reflow
by moving Line 3 right below Line 1.
These reflows are called uninterruptible reflows (they are absolutely necessary, because JS code needs to get the actual geometry of a node). Some reflows don't have to happen right away. Interruptible reflows can be delayed (usually to let the event loop run to not block the main thread, and draw early).
It's important to differentiate painting operations and reflows. Think about a code like this:
hiCSS1: .button:hover { border: 1px solid red; /* to compensate the new border: */ margin: -1px; } CSS2: .button { border: 1px solid transparent; } .button:hover { border-color: red; }
Using CSS1 or CSS2 will end up with the same result. But CSS1 will require the layout engine to compute the geometry of the button (and conclude that nothing needs to be moved), CSS2 will only require painting a red rectangle.
Painting is always cheaper than reflowing + painting.
This is why it's recommended to use CSS transforms instead
of regular CSS properties like top/left/margins to move elements.
For example, transform: translate(20px,40px)
will not require a reflow:
On slow CPUs, making sure the event loop doesn't get blocked for too long and reflows don't happen too often is critical.
Jan Keromnes, Vivien Nicolas and myself have been working on tools for Firefox OS to show when reflows happen in an app, and when the event loop gets blocked for too long.
To enable them, in recent versions of Firefox OS (1.4+):
Reflows and Jank
If you want to enable these tools for certified apps, you'll need to turn off this
preference (in prefs.js): devtools.debugger.forbid-certified-apps > false (this
won't be necessary in a near future).
Now, some squares should show up at bottom right of you app. The purple one is a reflow counter. The blue one shows the time of the latest event loop lag (only if it reaches the threshold set in the developer menu).
To get more details, I encourage you to
use the App Manager or simple use adb logcat | grep Widget (uninterruptible reflows
include a JS stack). We are working
on more tools to make hunting performance issues easier, but in the meantime the Firefox OS developer HUD
will help you track lags and reflows.
PS:
I said that JS functions don't run in parallel. It's not true for Web Workers, but workers don't interact with the DOM, layout or anything that could have an impact on the main thread. In some special scenarios, gecko (and only gecko) spins the event loop in the middle of a sync JS call (sync XHR and window.alert()), because Firefox Desktop has only one event loop.
I mentioned that drawing happens in the main thread. It's true, but compositing happens in a different thread, and soon, Firefox OS will also support scrolling in a different thread (async pan and zoom), which will make scrolling possible even if the event loop is blocked.
"Interruptible reflows" don't just get delayed, but also don't have to fully update the layout. When gecko paints, it tries to update the layout, but if it takes too long it will just give up and paint whatever we have so far.
|
|
John O'Duinn: Infrastructure load for December 2013 and January 2014 |
(Context: In case people missed this transition, my last day at Mozilla was Dec31, so obviously, I’m not going to be doing these monthly infrastructure load posts anymore. I started this series of posts in Jan2009, because the data, and analysis, gave important context for everyone in Mozilla engineering to step back and sanity-check the scale, usage patterns and overall health of Mozilla’s developer infrastructure. The data in these posts have shaped conversations and strategy within Mozilla over the years, so are important to continue. I want to give thanks to Armen for eagerly taking over this role from me during my transition out of Mozilla. Those of you who know Armen know that he’ll do this exceedingly well, in his own inimitable style, and I’m super happy he’s taken this on. I’ve already said this to Armen privately over the last few months of transition details, but am repeating here publicly for the record – thank you, Armen, for taking on the responsibility of this blog-post-series.)
December saw a big drop in overall load – 6,063 is our lowest load in almost half-a-year. However, this is no surprise given that all Mozilla employees were offline for 10-14 days out of the 31days – basically a 1/3rd of the month. At the rate people were doing checkins for the first 2/3rds of the month, December2013 was on track to be our first month ever over 8,000 checkins-per-month.
January saw people jump straight back into work full speed. 7,710 is our second heaviest load on record (slightly behind the current record 7,771 checkins in August2013).
Those are my quick highlights. For more details, you should go read Armen’s post for Dec2013 and post for Jan2014 yourself. He has changed the format a little, but the graphs, data and analysis are all there. And hey, Armen even makes the raw data available in html and json formats, so now you can generate your own reports and graphs if interested. A very nice touch, Armen.
John (still cheering from the sidelines).
http://oduinn.com/blog/2014/02/23/infrastructure-load-for-december-2013-and-january-2014/
|
|
Peter Bengtsson: What's the average number of domains a website depends on? |
tl;dr 36
For some time now, I've been running an experiment where I analyze how many different domains any website depends on. For example, you might have Google Analytics on your site (that's www.google-analytics.com) and you might have a Facebook Like button (that's platform.twitter.com and/or s-static.ak.facebook.com) and you might serve your images from a CDN (that's d1ac1bzf3lrf3c.cloudfront.net). That there is 3-4 distinct domains.
Independent of how many requests come from each domain, I wanted to measure how many distinct domains a website depends on so I wrote a script and started collecting random URLs across the web. Most of the time, to get a sample of different URLs I would take the RSS feed on Digg.com and the RSS feed on Hacker News on a periodic basis.
The results are amazing! Some websites depend on over 100 different domain names!
Take this page on The Toast for example, it depends on 143 different domains. Loading it causes your browser to make 391 requests, download 4.8Mb and takes 29 seconds (in total, not necessarily till you can start reading it). What were they thinking!?!
I think what this means is that website makers will probably continue to make websites like this. What we, as web software engineers, can not tell people it's a bad idea but instead to try to do something about it. It's quite far from my expertise but clearly if you want to make the Internet faster, DNS would be an area to focus on.
Test it out for yourself here: Number of Domains
|
|
Mark Coggins: Christian Heilmann at the Mozilla 2014 Mobile World Congress... |
Christian Heilmann at the Mozilla 2014 Mobile World Congress press event (photo credit: Mozilla in Europe).
|
|
Mark Coggins: Fr'ed'eric Harper at the Mozilla 2014 Mobile World Congress press... |
Fr'ed'eric Harper at the Mozilla 2014 Mobile World Congress press event (photo credit: Mozilla in Europe).
|
|
Marco Zehe: Accessibility in Firefox OS: An update |
After my introductory video, quite some things happened in the realm of Firefox OS accessibility, and although we’re still not quite ready yet to release builds to beta testers, we’re getting closer to a state where this will be the case.
In the interim, I’d like to share a few things that have happened over the past few months that may get you a bit excited! We certainly are! 
It recently became possible to toggle the screen reader and thus gain access to a Firefox OS device running the Feb 12 or later nightly builds of Firefox OS 1.4/Master. The way this works is as follows:
This even works in the Welcome wizard/First Time User experience screen. In essence, I can now setup a Firefox OS phone as a blind user.
Turning the screen reader off works in a similar fashion: Press the Power button three times in slow succession, confirm that you want to end it, and off it is switched.
Also, recently, speech controls were added to an Accessibility panel in the Settings app. You can control the screen reader on/off state itself, the speech rate and the volume.
The Accessibility panel is enabled when the screen reader is turned on, or it can be enabled from Developer settings, which in turn can be enabled from Device Info/More information. This, of course, is only interesting for sighted folks interested in trying things out, a blind user will most likely use the toggle. The important thing to note is that the screen reader setting has been moved out from the developer settings into the Accessibility panel in 1.4. So the occurrences that we had over the past couple of weeks where people turned on the screen reader accidentally and then didn’t know how to work their devices, should occur less.
When switching pages, bringing up an application or a website, the first element is now automatically focused after load. This is something Firefox for Android 30 and later will also do when a new web page loads. With that, speech response is much moe intuitive.
The Settings app in Firefox OS is the first to become fully accessible. It was the ground work laying app for us and turned out pretty well. We learned a lot about how to style, or not style, stuff, how to properly use techniques to only have items to swipe to that are actually relevant, and other details.
Oh yes, there are still a lot of problems, primarily in the user interface itself. The whole user interface of Firefox OS is written in HTML5, JavaScript and CSS, and when we started making it accessible, some of the code was pretty rough in terms of semantics. But Eitan and Yura sank their teeth into it, and despite several refactorings and such, we’re getting to a point where important work is being done that will make a lot of apps at once much more accessible. Along the way, we’re setting some rules for everyone on the Gaia team to follow, and implementing tests to make sure breakage occurs less often in the future. Some of these rules include things like “don’t use WAI-ARIA roles as parts of CSS selectors”, for example.
Everyone who has made a so far mostly inaccessible web app accessible knows how much tedious work this can be. And even more so with a dynamic project like Gaia, the Firefox OS user interface. But we’re getting a lot better, and seeing other team members pick up knowledge and attention on proper accessibility semantics. 
Gaia’s code is also improving a lot over-all, and that definitely helps, too!
In summary, we’re working hard, with me testing and other team members coding their butts off to give everyone the best possible user experience in Firefox OS in the near future! Stay tuned for more updates!
http://www.marcozehe.de/2014/02/23/accessibility-in-firefox-os-an-update/
|
|
Marco Zehe: Accessibility in Firefox for Android: Some more technical background, Part II |
A long while back, I wrote a post explaining some of the more technical details of the implementation of the accessibility in Firefox for Android. If you want to read the whole post, feel free to do so and then come back here, but for those of you who don’t, here is a short recap of the most important points:
After that last post, we had to make Explore By Touch work, for both Ice Cream Sandwich and, as it was released shortly after, the all-new Jelly Bean and beyond accessibility enhancements. For that, the JavaScript layer receives touch events from the Android side of things and queries the core engine for the element at the touch point. Also gestures like tapping, swiping, double-tapping and two-finger scrolling are received and processed accordingly.
For Jelly Bean and beyond, we had to do a special trick to make left and right swipes work. Because we’re implementing everything ourselves, we have to fake previous and next accessible elements, making TalkBack and others believe they have true native accessible elements to the left and right of the current element. TalkBack, in effect, only knows about three accessibles on the page. The currently spoken one is always the one in the middle of these three. When the user swipes right to go to the next element, the element to the right becomes the new middle one, gets spoken, and at the same time, the previous middle one becomes the one to the left, and the next regular page element is fetched and becomes the new right element. This particular logic sits in our Android accessibility code and queries the JavaScript portion for the relevant accessibles.
The fact that we have so much control over this stuff, in fact we have to do it this way or it wouldn’t work, allowed us to port the swiping back to Ice Cream Sandwich AKA Android 4.0, which doesn’t natively support that, and even Gingerbread AKA Android 2.3, which doesn’t have Explore By Touch support at all. But in the Firefox web views, it works! Including swiping and double-tapping, two-finger scrolling etc. Unfortunately, there was no way to make the rest of the browser UI accessible by touch on Gingerbread, too, so you’ll still have touse the keyboard for that.
On Jelly Bean and above, we are restricted a bit by what gestures Android supports. In effect, we cannot change the swiping, dluble-tapping, exploring, or two-finger scrolling behavior. We also cannot change what happens when the user swipes up and down. In those instances, Android expects a certain behavior, and we have to provide it. This is why, despite popular request, we currently cannot change the 3 finger swipes left and right to something more comfortable to execute quick navigation. Single-finger swipes left and right are strictly reserved for single object navigation. We’d love it to be different, but we’re bound in this case.
Some of the above techniques were used, in a slightly different fashion, to also implement BrailleBack support. As for TalkBack and friends, we have to implement everything ourselves. You have to implement two protocols: com.googlecode.eyes-free.selfbraille.SelfBrailleClient and com.googlecode.eyes-free.selfbraille.WriteData. This isn’t documented anywhere. Our summer intern Max Li did a terrific job dissecting the BrailleBack code and grabbing the relevant pieces from the GoogleCode project, and the result can be seen in Firefox for Android 25 and later. Max also added separate braille utterances, so the output isn’t as verbose as for speech, and follows better logic for braille readers. A few weeks ago, a review of using Android with braille was posted on Chris Hofstader’s blog by a deaf-blind user highlighting how well he could work with Firefox for Android in large part because of its excellent braille support. To reiterate: max was a summer intern at Mozilla last year. He is sighted and had never been in contact with braille before this as far as I know. He implemented this all by himself, occasionally asking me for feedback only. Imagine that, and then getting this review! I’m proud of you, Max!
And Max didn’t stop there: In Firefox 29 and above, an improvements to the way unordered and numbered lists are being presented in braille.
Because of the layered nature of our code, much of what has been implemented for Firefox for Android can be re-used in Firefox OS as well. The differences are mainly in what comes on top of the JavaScript/AccessFu layer. Talking to a synth directly instead of generating TalkBack events, of course using the new WebSpeech API, and in the future we’ll also “only” need to implement BrlTTY or something similar support and connectivity for braille displays. The abstraction allows us to then put the utterances to good use there as well. The main problem we’re having with Firefox OS right now is the actual UI written in HTML, JS, and CSS, code-named Gaia. Getting all the screens right so you cannot swipe to where you’re not supposed to at any given moment, making everything react to the proper activation events etc., and teaching the Gaia team a lot about accessibility along the way are the major tasks we’re working on for that right now. But thanks to the layering of the accessibility APIs and implementations, the transition from Firefox for Android was, though not trivial, not the biggest of our problems on Firefox OS.
The Android API documentation was not much help with all of this. As mentioned, the portion about SelfBrailleClient and friends wasn’t documented anywhere at all, at least I didn’t find anything but source-code references, among them that of Firefox for Android, in a Google search. But also the exact expectations of TalkBack aren’t retrievable just by studying the docs. Eitan had to dive into TalkBack’s source code to actually understand what it was expecting of us to deliver to make it all work.
Here’s to hoping that Google, despite its quest to close-source Android more and more, will keep BrailleBack and TalkBack open sourced so we can continue to read its source code in future updates to keep providing the good support our users have come to expect from us.
|
|
Erik Vold: My DevTools Work Week Hack |
I was just at the top secret Firefox DevTools Work Week in Portland. It was harsh, Dave Camp took our cellphones away from us on the first day, then locked us in a conference room with Heavy Metal music playing all day long, then he forced intravenous caffine injections on us every hour.
Some cool stuff got made though.
I was able to smuggle a video recording of my demo out in order to share it. I couldn't get ahold of Snowden, so I'll just have to post it here and hope that the people find it.
This video shows off how the devtools can open any restartless add-on (in this example I am using a native jetpack which is work in progress), edit it, press save and see the changes immediately. This is too powerful to be in the hands of the DevTools authorities it must be released as soon as possible for all of the peoples!
Please spread the word!
http://work.erikvold.com/devtools/2014/02/23/my-devtools-work-week-hack.html
|
|
Rob Hawkes: ViziCities release roundup |
Last Saturday evening, ViziCities was finally released to the public as an open-source project. Ever since then things have been absolutely crazy and incredibly hard to keep up with.
Have an idea for ViziCities, or just want to get in touch about it? Email us at hello@vizicities.com and we'll get back to you as soon as we can.
Let's start with a roundup of the raw statistics from the past week. They may not mean much to you but I think they're interesting and it can't hurt to share them and use them to track progress in the future.
On Tuesday evening, The Next Web posted an article about ViziCities on their Insider channel.
ViziCities is one to watch for sure.
Of all the coverage this week, The Next Web was the only one to trigger a huge influx of tweets related to the project.
Wednesday morning saw the Daily Mail run a piece about ViziCities on their website. For those who don't know, the Daily Mail website currently has a daily unique readership of around 11.8 million people. In other words, anything put there gets read by a shit-load of people.
A pair of developers from London used open source data to build an interactive 3D map of the tube network, complete with moving trains. The visualisation was built to showcase the ViziCities project. Its creators have made the code behind the project available for anyone to use.
We enjoyed a huge amount of traffic and interest from the Daily Mail audience, helped in part by ViziCities being featured as the headline article on the front page for most of the evening. I've no idea how we managed to get on the front page for so long, though I'm certainly not complaining!
Of all the coverage this week, the Daily Mail has been the most surreal and the one that has provided the most follow-ups. It's also been the only coverage this week that presented ViziCities in a way that the general public will be able to understand and take interest in.
The flip-side to being featured by the Daily Mail is that you have to endure a particular section of their readership, who provided an eloquent commentary on the project (displayed unedited for your pleasure); such as:
well that's 2 minutesof my life I'll never get back :(
And this thought-provoking statement…
My hardworked taxes towards yet another frivolous vanity project. How is thins gooing to benefit ME?!!? The only help I need I can get from the big brain between my ears.
I'm afraid we can't divulge where we spent all your hard-earned taxes, sorry. I wish we knew!
This was another…
WOW this is amazing, in actual 3D! trains are soooo interesting!! i could just watch them all day..... NOT
It really did seem like everyone loved ViziCities…
What a silly and pointless thing to create
It's a real eye-opener of a project…
Wow i just fell asleep there watching it. It's not very exciting is it?
And my personal favourite…
For a moment I thought wow that's interesting, but its passed now.
We aim to please. I'm just glad we were able to achieve that!
Seriously though, we're incredibly pleased to have been given the opportunity to be featured on the Daily Mail. 99.9% of the response has been positive and we've been absolutely astounded by it.
One of the weirdest moments from the Daily Mail coverage was when the daughter of a long-time family friend and old neighbour got in touch with me on Facebook for the first time ever, letting me know that her mum had seen the article and had phoned her about it. That alone proved to me the value of this coverage, that friends and members of the public who don't follow technology were finding it and actually reading it — all because it was on the Daily Mail. Insane!
On Thursday, ITV News ran a piece on ViziCities on their website.
It's a new and exciting way of looking at the London Underground. For the past year Peter Smart and Robin Hawkes have been working on a 3D map that brings cities to life using the power of open data and the Web.
We were hugely excited about being featured by ITV as they're a huge media organisation within the UK. Interestingly, we received next to no traffic as a result. This was likely because the article didn't have any links back to the project for a while, but even then it didn't seem to do much.
Our experience with the ITV coverage taught us that just because you're on a big website with a large audience doesn't mean anything. In a way it's analogous to the number of Twitter followers not being representative of how many people will click links in tweets you post.
For a good few days we were on top of the JavaScript sub-Reddit, and even enjoyed a good response in other sub-Reddits.
A WebGL-powered 3D city and data visualization platform. It’s flexible in its operation but can do things like let you visualize the London Underground train network in real time.
ViziCities is a 3D city and data visualisation platform, powered by WebGL. Its purpose is to change the way you look at cities and the data contained within them. It is the brainchild of Robin Hawkes and Peter Smart.
ViziCities is a 3D city and data visualization platform powered by WebGL. A fantastic project by Robin Hawkes and Peter Smart.
We've been overwhelmed with the amount of people who are excited about ViziCities and want to see it succeed. It's actually a little unbelievable.
Since launch there have been 3 merged pull requests from the community and a significant fork looking at adding physics to ViziCities. Seeing people actually want to help out is incredibly weird.
Another thing that's taken us by surprise is the amount of people sending in screenshots of ViziCities showing their local area.
View of Toronto within ViziCities
View of Amsterdam within ViziCities
View of NYC within ViziCities
View of Portland within ViziCitiesAlso, the number of organisations and data providers reaching out to us about visualising their data in the project has been amazing. We already have the future of some key features confirmed thanks to people like Plane Finder and Network Rail. We've so much more to catch up on!
I think it's safe to say that the first week of ViziCities going open-source has been amazing and overwhelming, but we're not going to stop there. Now that the project is finally out in the open we're able to focus on refining things and getting them working as best as we can, ideally with help from the community.
Even in the past 7 days I've been able to hack together experimental support for 3D terrain and live, 3D air traffic.
Watch this space…
Have an idea for ViziCities, or just want to get in touch about it? Email us at hello@vizicities.com and we'll get back to you as soon as we can.
http://feedproxy.google.com/~r/rawkes/~3/mETKFB5MgkQ/vizicities-release-roundup
|
|
Dave Townsend: An editable box model view in the devtools |
This week the whole devtools group has been sequestered in Mozilla’s Portland office having one of our regular meet-ups. As always it’s been a fantastically productive week with lots of demos to show for it. I’ll be writing a longer write-up later but I wanted to post about what I played with over the week.
My wife does the odd bit of web development on the side. For a long time she was a loyal Firebug user and a while ago I asked her what she thought of Firefox’s built in devtools. She quickly pointed out a couple of features that Firebug had that Firefox did not. As I was leaving for this week I mentioned I’d be with the devtools group and she asked whether her features had been fixed yet. It turns out that colour swatches had been but the box model still wasn’t editable. So I figured I could earn myself some brownie points by hacking on that this week.
The goal here is to be able to inspect an element on the page, pull up the box model and be able to quickly play with the margins, borders and padding to tweak the positioning until it looks right. Then armed with the right values you can go update your stylesheets. It saves a lot of trial and error with positioning.
It turned out to be relatively simple to implement a pretty full version. The feature allows you to click one of the box model values and type whatever value you like, in any CSS unit you prefer. If the size had been set in the stylesheet in some specific unit then that is what appears in the input box for you to change. Better yet as you type numbers the element updates in the page on the fly and you can use the arrow keys to increase/decrease the value until you’re happy. It’s a really natural way to play with the element’s position.
The changes made appear on the element so you can find them in the rule view pretty easily. This patch is based on an updated version of the box model view which is why it looks so different to existing Firefox, all my work does is make the numbers editable.
I actually completed this so quickly that I decided to take this one step further. One thing missing from the box model display is information about border colours. So I added some colour swatches for each border and made them editable with the regular devtools colour picker.
Both of these patches are pretty much complete but they’ll have to wait for the new box model highlighter to be complete before they can be reviewed and land.
http://www.oxymoronical.com/blog/2014/02/An-editable-box-model-view-in-the-devtools
|
|