Meet the first edition

We are  very happy to announce the launch of the first edition of a global, annual study of designer and developer needs on the web: The MDN Web Developer Needs Assessment. With your participation, this report is intended to shape the future of the web platform.

The MDN Web DNA Report 2019.

On single-vendor platforms, a single entity is responsible for researching developer needs. A single organization gets to decide how to address needs and prioritize for the future. On the web, it’s not that straightforward. Multiple organizations must participate in feature decisions, from browser vendors to standards bodies and the industry overall. As a result, change can be slow to come. Therefore, pain points may take a long time to address.

In discussions with people involved in the standardization and implementation of web platform features, they told us: “We need to hear more from developers.”

And that is how the MDN Web Developer Needs Assessment came to be. We aspire to represent the voices of developers and designers working on the web. We’ve analyzed the data you provided, and identified 28 discrete needs. Then, we sorted them into 14 different themes. Four of the top 5 needs relate to browser compatibility, our #1 theme. Documentation, Debugging, Frameworks, Security and Privacy round out the top 10.

DNA survey fundamentals

Like the web community itself, this assessment is not owned by a single organization. The survey was not tailored to fit the priorities of participating browser vendors, nor to mirror other existing assessments. Our findings are published under the umbrella of the MDN Product Advisory Board (PAB). The survey used for data collection was designed with input from more than 30 stakeholders. They represented PAB member organizations, including browser vendors, the W3C, and industry colleagues.

This report would not exist without the input of more than 28,000 developers and designers from 173 countries. Thanks to the thousands of you who took the twenty minutes to complete the survey. Individual participants from around the world contributed more than 10,000 hours of insight. Your thoughtful responses are helping us understand the pain points, wants, and needs of people working to build the web.

Where do we go from here

The input provided by survey participants is already influencing how browser vendors prioritize feature development to address your needs, both on and off the web. By producing this report annually, we will have the means to track changing needs and pain points over time. In fact, we believe developers, designers, and all stakeholders should be able to see the impact of their efforts on the future of the web we share.

You can download the report in its entirety here:

MDN Web DNA Report

Want to learn more about MDN Web Docs? Join the MDN Web Docs community, subscribe to our weekly newsletter, or follow MozDevNet on Twitter, to stay in the know.

Got a specific question about the MDN DNA Survey? Please share your constructive feedback and questions here or tweet us under the #mdnWebDNA hashtag.

The post Presenting the MDN Web Developer Needs Assessment (Web DNA) Report appeared first on Mozilla Hacks - the Web developer blog.

https://hacks.mozilla.org/2019/12/presenting-the-mdn-web-developer-needs-assessment-web-dna-report/

Threema is an alternative to WhatsApp & friends, with a focus on privacy. It’s made in Switzerland, and it is on sale until December 31 for half the price.

Threema is a messenger alternative for smartphones and tablets, with a web version also available that connects through your installed app. All offerings are accessible to screen reader users. It is not a free app, and it is only partially open-source. But its privacy focus has won it several recognitions since it was started in 2012.

Threema offers text, voice messaging, voice calls, photo, video sharing, sharing of various other document types, you can send locations. It offers one-on-one as well as group chats. In group chats, it also offers polls so you can easily find common times or other agreement with friends without having to use any external services.

Unlike many other messengers, you don’t need to provide a phone number or e-mail address to use the service. You generate a completely anonymous ID on your device. You can share your phone number and/or e-mail address so others can find you, but you don’t have to. Likewise, you can share your contact info, and Threema will see if any of your other contacts are on Threema and have opted in to share their details.

Threema has three trust levels: Unverified, verified via e-mail or phone, and verified via personal contact and mutual scanning of QR codes. This verification also serves as a mechanism to guard against possible man-in-the-middle attacks. Threema have great documentation about all of this in their frequently asked questions.

I use Threema frequently as one of my main messengers now with friends, some colleagues, and in some grup chats. And if you like, you can drop me a line there as well.

https://marcozehe.de/2019/12/19/on-sale-until-december-31st-threema-seriously-secure-messaging/

If you're unfamiliar with it, DOSBox is an x86 emulator specializing in running PC DOS games (and, presumably, any PC DOS application). For many DOS-based titles, in fact, it may be the only way to run them on modern PCs, let alone Macs. Besides emulating old hardware like video cards and SoundBlasters sufficiently for games to run, one of its key features on supported platforms is dynamically recompiling x86 machine language for enhanced performance. Unfortunately, DOSBox on Power Macs, while it is still supported as of this writing (10.4 and up), runs x86 code strictly in an interpreter and as a result can be quite slow on low-spec systems. For certain games requiring 80486-level performance, only the G5 can realistically emulate those at any reasonable level, and even then uses a lot of CPU doing so or requires skipping some portion of frames to make the game at all playable.

Over on Vogons earlier this year one of the DOSBox contributors wrote up a PowerPC JIT for the dynrec core under Linux which was then ported to OS X. Like the TenFourFox JIT compiles JavaScript to PowerPC machine code, this patch compiles x86 machine code to PowerPC machine code and runs that instead of requiring labourious interpretation. There was briefly a build available on Dropbox with this JIT, which is currently not part of the DOSBox source tree, but that build can no longer be downloaded. So, I went ahead and reconstructed it against the current trunk (at the time I pulled it, r4301) along with a minor tweak and another of this developer's big-endian fixes, and have tidied it up for download.

To give you an idea of the improvement, I have a few DOS games I enjoy that were never ported to Mac (along with LucasArts' Dark Forces, shown here, which has an outstanding Mac port with up to double the resolution of the DOS version but only runs in Classic). On this Quad G5 set to Reduced performance, with interpreted mainline DOSBox I usually had to have it skip every other frame. This made games like Commander Keen in Goodbye, Galaxy!, Pinball Illusions and Extreme Pinball playable, but only just so, and also made the animation sadly a bit jerky. Even with this handicap some games were still unplayable unless I turned the machine to Maximum performance (and cooked the room), and even then Dark Forces and Death Rally usually ranged from stuttery to slideshow. With the JIT enabled, not only could I get rid of the frame skip entirely -- even in Reduced performance -- but all of the games became absolutely playable. In Maximum performance they run better than my real 486 DOS games box.

Explaining how DOSBox works is beyond the scope of this blog post, but fortunately there is excellent documentation. Once you've played with the official build, you can get a JIT-enabled build (there's an "all Power Macs" and a G5-specific version with different compiler settings) from the repository I set up at SourceForge. This uses a separate preferences file which is included with some default settings. Out of the box frameskipping is disabled, which is appropriate for pretty much any G5 system from 2GHz on up with most titles. If you're using a G4 or slower G5 system, edit this file and change frameskip=0 to frameskip=1 or frameskip=2 (my 1.25GHz iMac G4 needed frameskip=2 as a minimum, but an MDD or 7447 might be okay with a frameskip of 1). You should use OpenGL as your output if at all possible for maximal hardware assistance (which is the default in this file); rendering to a surface in software is rather slower. Copy it to ~/Library/Preferences and start playing your classic DOS games with Power.

No warranty for this build is expressed or implied and this may be the only build I ever offer. There are known bugs in this build which Mac builds from

The Rust team is happy to announce a new version of Rust, 1.40.0. Rust is a programming language that is empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, getting Rust 1.40.0 is as easy as:

rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.40.0 on GitHub.

What's in 1.40.0 stable

The highlights of Rust 1.40.0 include #[non_exhaustive] and improvements to macros!() and #[attribute]s. Finally, borrow-check migration warnings have become hard errors in Rust 2015. See the detailed release notes for additional information.

#[non_exhaustive] structs, enums, and variants

Suppose you're a library author of a crate alpha, that has a pub struct Foo. You would like to make alpha::Foo's fields pub as well, but you're not sure whether you might be adding more fields to Foo in future releases. So now you have a dilemma: either you make the fields private, with the drawbacks that follow, or you risk users depending on the exact fields, breaking their code when you add a new one. Rust 1.40.0 introduces a way to break the logjam: #[non_exhaustive].

The attribute #[non_exhaustive], when attached to a struct or the variant of an enum, will prevent code outside of the crate defining it from constructing said struct or variant. To avoid future breakage, other crates are also prevented from exhaustively matching on the fields. The following example illustrates errors in beta which depends on alpha:

// alpha/lib.rs:

#[non_exhaustive]
struct Foo {
    pub a: bool,
}

enum Bar {
    #[non_exhaustive]
    Variant { b: u8 }
}

fn make_foo() -> Foo { ... }
fn make_bar() -> Bar { ... }

// beta/lib.rs:

let x = Foo { a: true }; //~ ERROR
let Foo { a } = make_foo(); //~ ERROR

// `beta` will still compile when more fields are added.
let Foo { a, .. } = make_foo(); //~ OK


let x = Bar::Variant { b: 42 }; //~ ERROR
let Bar::Variant { b } = make_bar(); //~ ERROR
let Bar::Variant { b, .. } = make_bar(); //~ OK
                   // -- `beta` will still compile...

What happens behind the scenes is that the visibility of the constructors for a #[non_exhaustive] struct or enum variant is lowered to pub(crate), preventing access outside the crate defining it.

A perhaps more important aspect of #[non_exhaustive] is that it can also be attached to enums themselves. An example, taken from the standard library, is Ordering:

#[non_exhaustive]
pub enum Ordering { Relaxed, Release, Acquire, AcqRel, SeqCst }

The purpose of #[non_exhaustive] in this context is to ensure that more variants can be added over time. This is achieved by preventing other crates from exhaustively pattern match-ing on Ordering. That is, the compiler would reject:

match ordering {
    // This is an error, since if a new variant is added,
    // this would suddenly break on an upgrade of the compiler.
    Relaxed | Release | Acquire | AcqRel | SeqCst => {
        /* logic */
    }
}

Instead, other crates need to account for the possibility of more variants by adding a wildcard arm using e.g. _:

match ordering {
    Relaxed | Release | Acquire | AcqRel | SeqCst => { /* ... */ }
    // OK; if more variants are added, nothing will break.
    _ => { /* logic */ }
}

For more details on the #[non_exhaustive] attribute, see the stabilization report.

Macro and attribute

The Internet Museum translated to Swedish becomes “internetmuseum“. It is a digital, online-only, museum that collects Internet- and Web related historical information, especially focused on the Swedish angle to all of this. It collects stories from people who did the things. The pioneers, the ground breakers, the leaders, the early visionaries. Most of their documentation is done in the form of video interviews.

I was approached and asked to be part of this – as an Internet Pioneer. Me? Internet Pioneer, really?

Internetmuseum’s page about me.

I’m humbled and honored to be considered and I certainly had a lot of fun doing this interview. To all my friends not (yet) fluent in Swedish: here’s your grand opportunity to practice, because this is done entirely in this language of curl founders and muppet chefs.

Back in the morning of October 18th 2019, two guys showed up as planned at my door and I let them in. One of my guests was a photographer who set up his gear in my living room for the interview, and then me and and guest number two, interviewer J"orgen, sat down and talked for almost an hour straight while being recorded.

The result can be seen here below.

The Science museum was first

This is in fact the second Swedish museum to feature me.

I have already been honored with a display about me, at the Tekniska Museet in Stockholm, the “Science museum” which has an exhibition about past Polhem Prize award winners.

(Top image by just-pics from Pixabay)

https://daniel.haxx.se/blog/2019/12/18/internetmuseum/

We are very happy to announce the results of our Mozilla Research Grants for the second half of 2019. This was an extremely competitive process, and we selected proposals which address seven strategic priorities for the Internet and for Mozilla. This includes studies of privacy in India and Indonesia, proposals to rethink how we might manage personal data, and explorations of the future of voice interfaces. The Mozilla Research Grants program is part of our commitment to being a world-class example of using inclusive innovation to impact culture, and reflects Mozilla’s commitment to open innovation.

The post Keeping the Internet Open & Accessible To All As It Evolves: Mozilla Research Grants appeared first on The Mozilla Blog.

https://blog.mozilla.org/blog/2019/12/18/keeping-the-internet-open-accessible-to-all-as-it-evolves-mozilla-research-grants/

I thought we involved stakeholders in research pretty perfectly, here at Mozilla. Stakeholders come to research studies, listen attentively to research report-outs, and generally value the work our team does. Then I read “It’s Our Research”. I still think the Firefox User Research team has great buy-in across the organization, but after reading Tomer Sharon’s book, there are so many more things we could improve on! And what fun is a job, if there’s nothing to improve, right?

I’d like to call in some stakeholders to help me tell four short stories related to four pieces of advice Tomer Sharon provides in his book. (By the way, there are so many ideas in that book, it was hard to pick just four.)

This post is authored by Jennifer Davidson, with contributions from Julia Starkov, Jim Thomas, Marissa (Reese) Wood, and Michael Verdi

Let’s start with the “failures”. Failure is a big word, but they’re really two examples where I could’ve done better, as a user researcher.

Never skip a field debriefing

An artistic bridge in Salem, Oregon with a clear blue sky. The weather was just too nice to debrief.

Tomer Sharon recommends that we never skip a debrief. A debrief includes those precious moments immediately after interviewing a participant or visiting a participants’ home. They capture your first reactions after the experience. Sharon details that they’re important because it helps prepare for analysis, and helps stakeholders remember the sessions. On the Firefox UX team, we have a great debrief culture. We reserve time after interviews, even if they’re remote interviews to capture initial thoughts. This practice is more formal when we do field research — where we not only have an individual debrief form that we fill out immediately after each visit, but we also do group debriefs together after each interview to talk together about what we observed. I would say we always do debriefs after every interview or session with our users, but then I’d be lying. Let’s have Julia Starkov, a Mozilla IT UX designer talk about her experience when we skipped a debrief in the field.

The time we skipped a debrief, as told by Julia: 

We wrapped up our Salem user research on a Friday afternoon; we were staying in different cities and some of us had plans right after the interview. We were also parked outside of the participant’s house so we decided to skip the group debrief and get the weekend started. While this felt like a huge relief at the time, I regret not pushing for us to meet at a cafe and wrap up the research together. By the time the weekend came and went, and I flew back to California, it was hard to recall specific parts of that interview, but mainly, I felt we could have definitely benefited from starting synthesis right away as a group. Overall, I thought the research effort was a total success, but I feel like I would have retained more insights and memories from the experience with a bit more team-time at the end.

Always include an executive summary

An executive summary is a few sentences, maybe one slide (if it’s in slide format) that summarizes a research study. I’ll tell you — it is the hardest part of a research study. Let’s have Marissa (Reese) Wood, Firefox VP of Product, explain the importance of an executive summary.

The importance of an executive summary, as explained by Reese:

The purpose of an executive summary is to describe the main and important points of your document in such a way that it will engage the readers. The intent is to have them want to learn more and continue to read the document. This is important because the reader will pay greater attention to detail and read the doc all the way through if they are engaged.  In short, without a good executive summary, the document will likely not get the attention it deserves.

Reese puts it nicely, but I’ll reiterate, without an executive summary, people may not pay any attention to the study results (a researcher’s worst

If you’re waiting to switch to Firefox because you think that Google Docs or Hangouts won’t work as well, we’re happy to debunk this myth. You have nothing to worry … Read more

The post Think Google Docs, Hangouts and G Suite don’t work with Firefox? Think again appeared first on The Firefox Frontier.

https://blog.mozilla.org/firefox/google-docs-works-with-firefox/

The new WordPress block editor is also available in the WordPress app for iOS and Android. It uses the same basis as the editor on a self-hosted or hosted WordPress site, but is a bit simplified. And it is accessible. Here are a few quick tips to get around it.

Enable it first

You may first have to enable it. You’ll find the setting under each blog/site you have in the WordPress app. It is called “Use the new visual editor”. Check its checkbox, or turn on its toggle switch, to use it.

Now when you compose a new post, you have many of the features of Gutenberg available. With each release, new blog types are supported on mobile devices. If you are unsure of what blocks are, read my introduction to Gutenberg from recently.

Navigation

Initially, you will land in the title, as usual. Enter it and press Enter.

Pressing Enter will by default create a new paragraph block. Unlike on the desktop, there is no Slash command available here to change the block type on the fly. But usually, the first block you want is a paragraph block anyway, and if not, you can add one and simply move it up as you wish.

To add a new block, find the Add Block toolbar item that is located above the keyboard, or if you are using an external one, in the lower left corner of your screen. That will open a popover with all the blocks it currently knows about. Choose a More block, a Heading block, a List block, etc., whatever you prefer. It is an intelligent list that shows you your last used block types first.

Go ahead and choose a new heading block. You can then write a heading. By default, this is a heading level 2. With each block, there is a toolbar associated with it. The elements except the Add Block, undo, redo, and some other common actions, each block has a few specific items. The Heading block, for example, has a group of buttons where you can switch which level the heading should have. You can easily switch to a heading of levels 3 or 4 here. In a paragraph block, you’ll find items to bold, italicize, underline text, or insert a link.

Notice as you are now in the Heading block, as you swipe left, you will encounter the previous paragraph block and the title. To the right of the currently focused block, you have buttons to move the block up a position, down (if available), or remove it alltogether. Depending on some blocks, you may even have the ability to move blocks right or left a column.

Each block item speaks its type nicely along with the text that is in the block. The order is pretty efficient: Block type, maybe the level if available, position information, followed by the text. This is a feature that is currently being worked on for the desktop/browser version, too, so when in selection mode, the blocks are spoken more nicely by screen readers as well. The aim is to unify the experiences so they are consistent across platforms.

A few gotchas

Inserting a block is always relative to the current block, it does not insert a block at the end by default. So if you have 10 blocks already, and are focused on block 8, the next block you insert will be at position 9 of then 11 blocks, not at position 11. If you want to insert a new block at the end, pfocus the last existing block first, then either choose a new block from the Add Block popover, or go to the end of your text and press Enter to just insert a new paragraph block at the end.

Inserting a link can be a bit confusing. There is no OK button, you add the link, and just close the popover. The only explicit action there is to remove the linkage.

Conclusion

The mobile version of Gutenberg inside the WordPress apps is more consistent and less dynamic than the desktop counterpart currently is. There is work being done to better the situation there, too, and when the time comes, I will blog about it here. The mobile version is actually a great option to play around with blocks, move them, get a feel for what you can do with posts, see what happens in the preview, etc.

So if, after reading my introduction for the desktop, you find it daunting, this mobile option may be a way for you to familiarize yourself with blocks in a little more controlled environment. The toolbar buttons are always visible, regardless of whether text is selected in a block or not, for example. And with the mobile version being very touch friendly, there is also no mouse hover state that can do seemingly unpredictable things.

Have fun playing!

Hello everyone,

Please say hi to Joel Johnson who’s going to cover Rina Tambo Jensen while she’s away for her parental leave for the next 6 months. JR has an extensive background in starting and setting up support teams across different companies. We’re so excited to have him on our team.

Here is a short introduction from JR:

Hello Everyone! My Name is JoelRodney Johnson and I go by JR. I am from Dallas, Texas and have lived most of my life there. I spent several years in San Fransisco where I got started in Support and started a career in Tech. My guilty pleasure is reading Sci-Fi/Fantasy novels and if you were to take a look at my audible account you might be surprised at the amount of books I have in my library. I am so happy to be joining the Mozilla team as the Product Support Manager overseeing customer service for Mozilla products. I look forward to an exciting future here in Support.

Please join us to welcome him!

https://blog.mozilla.org/sumo/2019/12/18/introducing-joel-johnson/

“It’s a poor craftsman that blames his tools” is an old line, and it took me a long time to understand it.

A friend of mine sent me this talk. And while I want to like it a lot, it reminded me uncomfortably of Dabblers and Blowhards, the canon rebuttal to “Hackers And Painters”, an early entry in Paul Graham’s long-running oeuvre elaborating how special and magical it is to be just like Paul Graham.

It’s surprisingly hard to pin Paul Graham down on the nature of the special bond he thinks hobbyist programmers and painters share. In his essays he tends to flit from metaphor to metaphor like a butterfly, never pausing long enough to for a suspicious reader to catch up with his chloroform jar. […] You can safely replace “painters” in this response with “poets”, “composers”, “pastry chefs” or “auto mechanics” with no loss of meaning or insight. There’s nothing whatsoever distinctive about the analogy to painters, except that Paul Graham likes to paint, and would like to feel that his programming allows him a similar level of self-expression.

There’s an old story about Soundcloud (possibly Spotify? DDG tends to the literal these days and Google is just all chaff) that’s possibly apocryphal but too good not to turn into a metaphor, about how for a long time their offices were pindrop-quiet. About how during that rapid-growth phase they hired people in part for their love of and passion for music, and how that looked absolutely reasonable until they realized their people didn’t love music: they loved their music. Your music, obviously, sucks. So everyone there wears fantastic headphones, nobody actually talks to each other, and all you can hear is in their office is keyboard noise and the HVAC.

I frequently wonder if the people who love Lisp or Smalltalk fall into that same broad category: that they don’t “love Lisp” so much as they love their Lisp, the Howl’s Moving Memory Palaces they’ve built for themselves, tailored to the precise cut of their own idiosyncracies. That if you really dig in and ask them you’ll find that other people’s Lisp, obviously, sucks.

It seems like an easy trap to fall in to, but I suspect it means we collectively spend a lot of time genuflecting this magical yesteryear and its imagined perfect crystal tools when the fact of it is that we spend almost all of our time in other people’s code, not our own.

I feel similarly about Joel Spolsky’s notion of “leaky abstractions”; maybe those abstractions aren’t “leaking” or “failing”. Instead it’s that you’ve found the point where your goals, priorities or assumptions have diverged from those of the abstraction’s author, and that’s ultimately not a problem with the abstraction.

The more time I spend in front of a keyboard, the more I think my core skills here aren’t any more complicated than humility, empathy and patience; that if you understand its authors the code will reveal itself. I’ve mentioned before that programming is, a lot more than most people realize, inherently political. You’re making decisions about how to allocate scarce resources in ways that affect other people; there’s no other word for it. So when you’re building on other people’s code, you’re inevitably building on their assumptions and values as well, and if that’s true – that you spend most of your time as a programmer trying to work with other people’s values and decisions – then it’s guaranteed that it’s a lot more important to think about how to best spend that time, or optimize those tools and interactions, rather than championing tools that amount to applied reminiscence, a nostalgia with a grammar. In any other context we’d have a term for that, we’d recognize it for what it is, and it’s unflattering.

What does a programming language optimized for ease-of-collaboration or even ease-of-empathy look like, I wonder? What does that development environment do, and how many of our assumptions about best collaborative practices are just accidental emergent properties of the shortcomings of our tools? Maybe compiler pragmas up front as expressions of preferred optimizations, and therefore priorities?

Like holiday music, lists are a seasonal cliche. They pique our interest year after year because we want a tl;dr for the 12 months gone by. To summarize, Mozilla Hacks celebrated its 10th birthday this past June, and now in December, we come to the end of a decade. Today, however, we’ll focus on the year that’s ending.

Topics and patterns

In fact, we covered plenty of interesting territory on Mozilla Hacks in 2019. Some of our most popular posts introduced experiments and special projects like Pyodide, extending the web platform for the scientific community. Mozilla WebThings, which also featured as one of 2018’s most popular posts, continued to engage attention and adoption. People want a smart home solution that is private, secure, and interoperable.

Not surprisingly, interest in Firefox release posts is stronger than ever. Firefox continues to deliver new developer tools and new consumer experiences to increase user agency, privacy, security, and choice — and our readers want the details.

Also, we’ve made remarkable progress on WebAssembly, as it extends beyond the browser and off the Web, via WASI (WebAssembly interface types) and associated tooling. Mozilla is a founding member of the Bytecode Alliance. Announced last month, this open source initiative is dedicated to creating secure new software foundations, built on new standards such as WebAssembly and WebAssembly System Interface (WASI). Plus, readers can’t get enough code cartoons, especially for visualizing complex concepts in programming.

The 2019 list

Some of the most high-traffic posts of 2019 were written in earlier years, and continue to attract readers. These are not included here. Instead, we’ll focus on what was new this year. And here they are:

1. Pyodide: Bringing the scientific Python stack to the browser, by Michael Droettboom. On the heels of Project Iodide, this post describes Mozilla’s experimental project — a full Python data science stack that runs entirely in the browser.
2. Standardizing WASI: A system interface to run WebAssembly outside the web by Lin Clark. WebAssembly needed a system interface for a conceptual operating system, in order to be run across all different OSs. WASI was designed as a true companion to WebAssembly, upholding the key principles of portability and security while running outside the browser. Code cartoons included.
3. Introducing Mozilla WebThings. In this April post, Ben Francis announced the next phase of Mozilla’s work in IoT. The Mozilla WebThings platform for monitoring and controlling devices over the web consists of the WebThings Gateway, a software distribution for smart home gateways, and the WebThings Framework, a collection of reusable software components.
4. Firefox’s New WebSocket Inspector. Recently, Jan “Honza” Odvarko and Harald Kirschner introduced Firefox DevTool’s Websocket Inspector, a much requested feature for visualizing and debugging real-time data communication flows.
5. Implications of Rewriting a Browser Component in Rust. In the closing post of her Fearless Security series,

Let’s be real. Most of us don’t read the privacy policies when signing up to use a service. If you wanted to read all of the terms you’ve agreed to, … Read more

The post How much data are you sharing this holiday season? appeared first on The Firefox Frontier.

https://blog.mozilla.org/firefox/how-much-data-are-you-sharing/

I bought a cordless drill from DeWalt a few years before they standardized on their current 20 volt form factor. Today the drill part of the drill is still in good shape, but its batteries won’t hold a charge – don’t store your batteries in the shed over the winter, folks, that’s rookie mistake – and I can’t replace them; they just don’t make them anymore. Nobody does.

I was thoroughly prepared to be annoyed about this, but it turns out DeWalt makes an adapter that slots right into my old drill and lets me use their new standard batteries. I’ll likely get another decade out of it as a result, and if the drill gives up the ghost in the meantime I’ll be able to use those batteries in its replacement.

Does any computer manufacturer out there anywhere care about longevity like that, today? The Cadillac answer to that used to be “Thinkpad”, but those days are long gone and as far as I can tell there’s nothing else in this space. I don’t care about thin or light at all. I’m happy to carry a few extra pounds; these are my tools, and if that’s the price of durable, maintainable and resilient tools means a bit of extra weight in the bag I’ll pay it and smile. I just want to be able to fix it; I want something I can strip all the way down to standard parts with a standard screwdriver and replace piecemeal when it needs piecemeal replacing. Does anyone make anything like this anymore, a tradesman’s machine? The MNTRE people are giving it a shot. Is anyone else, anywhere?

http://exple.tive.org/blarg/2019/12/17/long-term-support/

Last week, I got my set of AirPods Pro. And after using them for a few days in various situations, can say: Best active noise cancelling headphones I’ve ever used!

Apple released AirPods Pro earlier this autumn, and I was very curious to get my hands on them. I have always been a fan of the AirPods, even though the first generation still had quite some lag with VoiceOver. But I was totally sold on Apple’s wireless future from early on. Unlike many other blind users, I was never sad to see the 3.5 mm headphone jack go.

The AirPods 2, released in the spring of 2019, did away with almost the whole lagging problem when using VoiceOver on a relatively modern iOS device. I used them with my iPhone 7 from 2016, the X from 2017, and the new 11 Pro Max I got in September, as well as an iPad Air 3rd generation. And I, for one, no longer notice a lag since I started using these new AirPods. The reason is, no doubt, the H1 chip that is in these. I also learned from a friend that his PowerBeats Pro behave the same way with VoiceOver. They also contain the H1 chip.

So I was very curious when Apple announced AirPods Pro. These are AirPods, but with active noise cancelling (ANC). For someone who travels frequently, either by plane or, as is common in Europe, by train, headphones with active noise cancelling are an absolute must if you don’t want to constantly stress out your ears when you don’t need to, especially as a blind person. And I’ve tried many of them. So far, my personally best results were with two Bose ones, the wired Quiet Control 20, and the wireless Quiet Control 30. Both of these are in-ear ANC headphones with three adjustable earpiece sizes. My ears are actually shaped in a way that I have to use the slightly larger one on one side. The most annoying about the QC-30 were the plastic strap around the neck that holds all of the electronics, and the lag experienced with the Bluetooth connection.

I had also tried some over-ear headphones over the years. But the weight of these often quickly made my neck ache. I also experienced an uncomfortable pressure on the ears stemming from the noise cancelling techniques. I tried the Bose QC-35, Sony WH1000-X3, and also the Apple Beats Studio 3 Wireless. The Beats were the best experience with Apple devices, but had the weakest ANC.

And then came AirPods Pro.

Oh people, am I sold on these! They are in-ear pieces, with three differently sized tips so one can make them fit one’s ears best. Apple even provide a fitting test within Bluetooth settings so these AirPods can test themselves if they fit and close off the ear canal properly. The way they do that is extremely clever. The ANC is done through a set of microphones that take the outside noise and produce an inverse wave form of these noises. The cancelled out signal is then sent to the ears. This is, as you correctly interject, how all these ANC headphones do it.

The clue, however, with Apple’s AirPods Pro is that they also have a microphone inside the ear that is able to pick up one’s own body noises such as breathing. Those are also used to test how much of the test music that is played can escape and thus is an indication how well the ear pieces fit and channel the sound to the inner ear rather than the outside. And of course, they are used to reduce the noises one makes while breathing, swallowing etc. That adds an extra level of comfort that I have not seen in any other noise cancelling headphones.

This is also what lessens the uncomfortable feeling of pressure on the ears once ANC is active. Because they reduce the noises from within, the whole impression is far more balanced. I could wear these for hours without feeling the least bit uncomfortable while on a train to my mom’s birthday party on Sunday.

The battery life on the AirPods Pro is also pretty impressive. On average, they hold about 45 minutes longer than projected by Apple. Music sounds great, and VoiceOver has no lag either, as these also come with the H1 chip.

Unlike the regular AirPods, you do not tap on these to play or pause, fast-forward or skip back, or call Siri. Instead, you take the longer piece of an AirPod Pro between two fingers and press. One short press pauses and plays, two skip forward, three skip backward. If you long-press, you can configure either side to either switch between ANC and transparency modes, or bring up Siri. But you can also use Hey Siri to invoke your personal assistant.

Transparency is when noise cancelling stays in effect, but some frequencies, like those in human voices, are let through so you can talk to someone and hear what they’re saying. Apple doesn’t offer several levels of transparency, as the Bose headphones do, for example. It’s either on or off. In my experience, the quality of sound is quite good, and sounds more natural than other transparency modes I have

https://blog.mozilla.org/blog/2019/12/17/firefox-announces-new-partner-in-delivering-private-and-secure-dns-services-to-users/

Today I've completed another semester of teaching open source, and wanted to write something about what happened, experiments I tried, and what I learned.

This fall I taught the first of our two open source classes, cross-listed in our degree and diploma programs as OSD600 and DPS909.  This course focuses on getting students engaged in open source development practices, and has them participate in half-a-dozen different open source projects, making an average of 10 pull requests over 14 weeks.  The emphasis is on learning git, GitHub, and how to cope in large open source projects, code bases, and communities.

This is the 15th year I've taught it, and I had one of my largest groups: 60 students spread across two sections.  I don't think I could cope with more than this, especially when I'm also teaching other courses at the same time.

Running the Numbers

I ran an analysis this morning, and here's some data on the work the students did:

• 665 Pull Requests (2,048 commits) to 266 GitHub Repositories
• 425 have already been merged (63%)
• +85,873/-25,510 lines changed in 2,049 files

They worked on all kinds of things, big and small.  I kept a list of projects and organizations I knew while I was marking this week, and some of what I saw included:

• Lots from Mozilla, including: mozilla/addons-code-manager, mozilla/hubs, mozilla/web-ext, mozilla/foundation.mozilla.org, mozilla-lockwise/lockwise-android, firefox-devtools/profiler
• All kinds of things with Micosoft (more than any other org), including microsoft/vscode, microsoft/vscode-vsce, microsoft/STL, microsoft/accessibility-insights-web, microsoft/calculator, microsoft/react-native-windows, microsoft/fast-dna, xtermjs/xterm.js, dotnet/winforms
• Google: google/blockly, google/coding-with-chrome, angular/angular
• ruby/www.ruby-lang.org
• Lots of localization with GatsbyJS: gatsbyjs/gatsby-vi, gatsbyjs/gatsby-es, gatsbyjs/gatsby-ru
• moment/moment
• bitcoin/bitcoin
• elastic/kibana, elastic/eui
• facebook/create-react-app
• Quite a few PRs to WordPress: wordpress-mobile/WordPress-iOS, WordPress/gutenberg
• nodejs/node
• A few to projects run by Nasa: nasa-gibs/worldview, nasa/PSP
• home-assistant/home-assistant, home-assistant/home-assistant-polymer

On the Firefox UX team, a human-centered design process and a “roll up your sleeves” attitude define our collaborative approach to shipping products and features that help further our mission. Over the past year, we’ve been piloting a Usability Mentorship program in an effort to train and empower designers to make regular research part of their design process, treating research as “a piece of the pie” rather than an extra slice on the side. What’s Mozilla’s Firefox UX team like? We have about twenty designers, a handful of user researchers, and a few content strategists.

This blog post is written by Holly (product designer, and mentee), and Jennifer (user researcher, and mentor).

photo: Holly Collier; A coozy gift from Gemma Petrie. Credit for the phrase goes to Leslie Reichelt at GDS.

Why should I, a designer, learn user research skills?

Let’s start with Holly’s perspective.

I’m an interaction designer — I’ve been designing apps and websites (with and without the help of user research) for over a decade now, first in agencies and then in-house at an e-commerce giant. Part of what drew me to Mozilla and the Firefox UX team a year ago was the value that Mozillians place on user research. When I learned that we had an official Usability Mentorship program on the Firefox UX team, I was really excited — I had gotten a taste of helping to plan and run user research during my last gig, but I wanted to expand my skill set and to feel more confident conducting studies independently.

I think it’s really important to make user research an ongoing part of the product design process, and I’m always amazed by the insights it produces. By building up my own user research skill set, it means that I’m in a better position to identify user problems for us to solve and to improve the quality of the products I work on.

How does the mentorship program work?

And now onto Jennifer. She’ll talk about how this all worked.

A little bit about me before we dive in. I’m a user researcher — I’ve been in the industry for 6 years now, and at Mozilla on the Firefox User Research team for 3 years. I’ve worked at a couple big tech companies (HP & Intel) before coming to Mozilla. Prior to that, I worked hard at internships and got a PhD in Computer Science, focused on Human Computer Interaction. I love working at Mozilla, especially with designers like Holly, who are passionate about user research informing product design!

At Mozilla, our research team conducts three types of research (as written by Raja Jacob and Gemma Petrie):

• Exploratory: Discovering and learning. Conducting research around a topic where a little is known. This type of research allows us to explore and learn about a problem space, challenge our assumptions on a topic, and more deeply understand the people we are designing for.
• Generative: Generative research can help us develop concepts through activities such as participatory design sessions or help us better understand user behavior and mental models related to a specific problem/solution space.
• Evaluative: Evaluative research is conducted to test a proposed solution to see if it meets people’s needs, is easy to use and understand, and creates a positive user experience. Usability testing falls under this category.

Like most organizations, we routinely have more designs that need usability testing than we have researchers. Gemma Petrie, our most senior User Researcher (a Principal User Researcher), started the mentorship program as a way to address this problem in her previous role as interim Director of User Research. By spreading usability testing abilities more broadly across the Firefox UX team, we could ensure that more designs got tested and ensure that our dedicated researchers could continue to do exploratory and generative research.

Because all of our designers and content strategists had different levels of

Our newest Friend of Add-ons is Jocelyn Li! Jocelyn has been an active code contributor to addons.mozilla.org (AMO) since May 2018, when she found a frontend issue that involved broken CSS. She had known that Mozilla welcomed code contributions from community members, but hadn’t been sure if she was qualified to participate. As she looked at the CSS bug, she thought, “This doesn’t look that hard; maybe I can fix it,” and submitted her first patch a few hours later. She has been an avid contributor ever since.

Jocelyn says that contributing to a large public project like Mozilla has helped her grow professionally, thanks in part to positive interactions with staff members during code review. “They always give constructive comments and guide contributors,” she says. “When I learn either technical or non-technical skills, I can apply them to my own job.”

Mozilla and contributors alike benefit from the open source model, Jocelyn believes. “Mozilla receives contributions from the community. Contributors are like seeds all over the world and promote Mozilla’s projects or languages and improve their own companies at the same time.”

One of Jocelyn’s passions is learning new languages. Currently, she is learning Rust for a work project that uses node.js in typescript with tp-ts and Japanese to acclimate to Tokyo, where she moved earlier this year. “Every language provides different perspectives to us,” she notes. “One language may have terms or syntaxes that another language doesn’t have. It’s like acquiring a new skill.”

In her spare time, she enjoys reading, cooking, traveling, and learning how to play the cello. “I always feel like 24 hours in a day is not enough for me,” she says.

Thank you for your contributions, Jocelyn!

If you are interested in getting involved with the add-ons community, please take a look at our wiki for some opportunities to contribute to the project.

The post Friend of Add-ons: Jocelyn Li appeared first on Mozilla Add-ons Blog.

https://blog.mozilla.org/addons/2019/12/16/friend-of-add-ons-jocelyn-li/

Over the weekend, this post by Dave Rupert made the rounds, and I totally agree with what he is saying.

In his post, Dave showcases a problem with the gap between intent and developer assumption about what a certain element or set of elements, are intended or should be used for, and what not to be used for. In this case, the details and summary elements being used as accordions, or not.

If you are running his example with Firefox and either NVDA or JAWS, you are actually very lucky, because all features of his accordion are supported, including the headings. Because unlike some other browsers, because h elements are allowed within summary elements, we do not nuke the heading semantics, and thus it is possible with both screen readers to navigate by heading even inside the summary elements, which get mapped to the button role. Since Firefox 70, both screen readers will even announce properly when you toggle the details open or closed.

However, this is not the case with all browser and screen reader combinations. And according to the spec, details and summary are not intended to be used as an accordion, even though the interaction model totally mimiks that. And here’s indeed one of the big problems I have encountered time and again when working with developers internally at Mozilla and on the outside: The specification does not always do a good job of explaining in an understandable form of English what an element is intended for or not. Especially if it mimiks a design pattern that fits the developers use case, but is for some reason not what the developer wants to use it for. This divide is made very obvious in Dave’s post. Even in accessibility land, there is this divide. For example, the spec allows for buttons or elements that map to buttons to have semantic children like headings. Why then do buttons, according to the accessibility specification, nuke their children’s semantics? Or should nuke them? Because traditional desktop buttons didn’t have headings?

The specifications have become a bit better in recent years to reflect current realities. But often enough, there is still this great divide between the HTML spec, the accessibility expectations which often enough stem from 25 year old concepts, such as “Buttons don’t have heading children”, and developer expectations when they see the visuals of what, for example, details/summary do, and think “hey cool, I combine a few of these and have an accessible accordion”! It is my hope that, in 2020 and beyond, we in the accessibility community will muster up some more courage to show some flexibility and not be afraid to adjust specifications to realities more, and give developers a bit more certainty. Yes, buttons can have semantic children. Firefox plus NVDA, and even the commercial JAWS, screen readers show that this is doable and the world doesn’t go to hell because of it. Sometimes things just work.

As we move into 2020, I also hope that each side, developers and spec authors and accessibility professionals, become more and more aligned on intent, reality of usage patterns, and implementation of richer building blocks for the web that are then specified in an understandable manner in HTML and accompanying specifications. We all want to move the web forward. Let’s do it in a more concerted manner and do more good together. The web needs it!

And Dave is right in demanding that more accessible HTML components get implemented by browsers and properly specified. We should move away from the “ARIA will fix it” mentality and put more effort into “Let’s give web authors more accessibility out of the box for richer components”, so those sad figures of 97% of inaccessible sites will hopefully drop to a much more satisfactory number in the next five years.

Let’s do it!

https://marcozehe.de/2019/12/16/call-to-action-html-needs-more-native-rich-widgets/