mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Karl Dubost: Things I type (when working on webcompat.com)

Mozilla planet - do, 27/07/2017 - 02:17

There's always a sequence of things I do before working on a new branch for webcompat.com development.

# Probably one of the most used command for me. (See below) git status # back to the master branch git checkout master # webcompat is my origin git fetch webcompat # updating to the latest version git merge webcompat/master # opening a new branch where 1677 is the issue number and 1 is the first attempt. git checkout -b 1677/1 Most used git commands?

Let's see if my impression was correct.

grep -E '^git' ~/.bash_history | sort | uniq -c | sort -nr | head -n15 563 git status 383 git diff 211 git checkout master 131 git push origin master 124 git branch -a 117 git log 61 git fetch webcompat 51 git pull upstream master 49 git merge webcompat/master 45 git fetch upstream 41 git log --oneline 23 git fetch webcompat;git merge webcompat/master 20 git pull 20 git checkout master; git fetch upstream;git merge upstream/master 19 git fetch upstream;git merge upstream/master

This previous one is too specific because it includes the full line. Let's constraint it to the git option. git status is still the winner.

→ awk '{print $1, $2}' ~/.bash_history | grep -E '^git' | sort | uniq -c | sort -nr | head -n15 572 git status 543 git commit 509 git diff 501 git checkout 395 git push 238 git branch 193 git log 186 git fetch 136 git pull 116 git add 96 git merge 82 git clone 77 git rg 37 git rebase 31 git remote

If you are wondering what git rg is? It is coming from my ~/.gitconfig and is a courtesy of Anthony Ricaud.

[alias] rg = "grep --heading --break -i"

Very useful grep baked into git.

Otsukare!

Categorieën: Mozilla-nl planet

Firefox UX: Toward Making User Research More Open

Mozilla planet - wo, 26/07/2017 - 22:08

Firefox Test Pilot is an approach to experimenting with new browser features in the open. What this means is that we plan, design, build, and evaluate experimental features with as much transparency as possible, in line with Mozilla’s mission and values. In this second year of Test Pilot, we’re making a concerted effort to make our work even more public by sharing all of the user research we conduct on our experiments.

What we already do in the open

From the beginning, Test Pilot has strived to work in the open. For example, the majority of our meetings are open to the public. We publish our documentation in places like the Mozilla Wiki and Github. The latter has also been a place where people trying our experiments can suggest and vote on enhancements.

The Test Pilot team prioritizes enhancements to our Containers experiment based on up-votes on Github.

We also receive feedback on experiments via Twitter and the Discourse forum.

People using our Tab Center experiment reached out to us on Twitter when they heard that the experiment would no longer be supported starting with Firefox 56.

Whenever an experiment graduates, we publish — for anyone to see — what we learned from that experiment, including the metrics that informed those learnings.

Detail from our graduation report on the No More 404s experiment

Transparency beyond code

Even with these efforts, we realize that, historically, transparency in open source development has largely focused on code and the conversations that happen around that code. What that focus has neglected are other important parts of our process for creating the products we ship, including user research.

Test Pilot user research has not been shared widely in the past because of the extensive personally identifiable information (PII) contained in our qualitative research. In most cases, we have not removed PII from our research findings because, for the Test Pilot team, those details are often critical for helping us build greater empathy for people using our experiments and for internalizing insights from the research we conduct. For example, a grimace and silence captured on video from a research participant trying to use one of our experiments is generally much more affecting and memorable than a written, anonymized quote from a research participant about how an experiment was confusing.

The benefits of making user research more open

We will continue to leverage user research containing PII internally when the Test Pilot team can learn from it. However, we realize that there are benefits that we can reap by making our user research more shareable beyond our team. With a new commitment to sharing our user research in the form of blog posts here on Medium, links to our research reports, and embedding insights from user research in public conversations happening in other channels like Github, we aim to:

  • Possibly expand who can contribute to our work to include people who will share ideas and feedback on our research approaches
  • Increase accountability around how we leverage user research findings to inform the design and development of our experiments

Share ideas about open research

We welcome additional ideas about how we can make our user research more open while maintaining its rigor and integrity. If there are open research initiatives that you think we can learn from, let us know. We look forward to hearing your thoughts on the research we share moving forward.

Originally published at medium.com on July 26, 2017.

Toward Making User Research More Open was originally published in Firefox User Experience on Medium, where people are continuing the conversation by highlighting and responding to this story.

Categorieën: Mozilla-nl planet

Firefox Test Pilot: Toward Making User Research More Open

Mozilla planet - wo, 26/07/2017 - 22:08

Firefox Test Pilot is an approach to experimenting with new browser features in the open. What this means is that we plan, design, build, and evaluate experimental features with as much transparency as possible, in line with Mozilla’s mission and values. In this second year of Test Pilot, we’re making a concerted effort to make our work even more public by sharing all of the user research we conduct on our experiments.

What we already do in the open

From the beginning, Test Pilot has strived to work in the open. For example, the majority of our meetings are open to the public. We publish our documentation in places like the Mozilla Wiki and Github. The latter has also been a place where people trying our experiments can suggest and vote on enhancements.

The Test Pilot team prioritizes enhancements to our Containers experiment based on up-votes on Github.

We also receive feedback on experiments via Twitter and the Discourse forum.

Sad news folks, Tab Center won't be supported in FF 56+. Will still be available for Release and Beta through the summer.

 — @FxTestPilot

@FxTestPilot Please keep the project on hold. Don't abandon it. Let it adapt once things are set in stone with 57 & beyond!

 — @bull500

Whenever an experiment graduates, we publish — for anyone to see — what we learned from that experiment, including the metrics that informed those learnings.

Detail from our graduation report on the No More 404s experiment

Transparency beyond code

Even with these efforts, we realize that, historically, transparency in open source development has largely focused on code and the conversations that happen around that code. What that focus has neglected are other important parts of our process for creating the products we ship, including user research.

Test Pilot user research has not been shared widely in the past because of the extensive personally identifiable information (PII) contained in our qualitative research. In most cases, we have not removed PII from our research findings because, for the Test Pilot team, those details are often critical for helping us build greater empathy for people using our experiments and for internalizing insights from the research we conduct. For example, a grimace and silence captured on video from a research participant trying to use one of our experiments is generally much more affecting and memorable than a written, anonymized quote from a research participant about how an experiment was confusing.

The benefits of making user research more open

We will continue to leverage user research containing PII internally when the Test Pilot team can learn from it. However, we realize that there are benefits that we can reap by making our user research more shareable beyond our team. With a new commitment to sharing our user research in the form of blog posts here on Medium, links to our research reports, and embedding insights from user research in public conversations happening in other channels like Github, we aim to:

  • Possibly expand who can contribute to our work to include people who will share ideas and feedback on our research approaches
  • Increase accountability around how we leverage user research findings to inform the design and development of our experiments

Share ideas about open research

We welcome additional ideas about how we can make our user research more open while maintaining its rigor and integrity. If there are open research initiatives that you think we can learn from, let us know. We look forward to hearing your thoughts on the research we share moving forward.

Toward Making User Research More Open was originally published in Firefox Test Pilot on Medium, where people are continuing the conversation by highlighting and responding to this story.

Categorieën: Mozilla-nl planet

Sebastin Santy: GSoC Week 7 & 8: Style it like Github

Mozilla planet - wo, 26/07/2017 - 20:26

Hi everyone,

So these weeks some radical changes happened in terms of design. The new-bug design was looking uglier day-by-day, as we were shamelessly copying the bug modal design which is actually suited for show_bug.cgi. So it was planned we’ll go with re-organizing parts of the layout and also implementing keywords feature.

Work

After lots of discussion with my mentor, we decided to approach Kohei Yoshino (mozilla.org designer and UX expert) and his inputs were really valuable. He suggested us to go with the github issues styling and that was one good of a decision. Implementing keywords feature was easy, as selectize had a built in support for multiple tagging.

Conclusion

Here is how it looks now: Github Like New-Bug Image

At present, I am working on clearing attachments PR and also a new feature by which users will be able to give product names in the URL using hash, like this -
https://bugzilla.mozilla.org/new-bug#Core. This will be useful for power users of BMO.

Categorieën: Mozilla-nl planet

Hacks.Mozilla.Org: Inspect, Modify, and Debug React and Redux in Firefox with Add-ons

Mozilla planet - wo, 26/07/2017 - 19:42

React, along with Redux, is one of the fastest and most flexible UI frameworks on the web. It’s easy to write, easy to use and is great for teams. In fact, the Mozilla community uses React to build a lot of the Firefox DevTools UI and, famously, the Facebook UI is built with React. Despite its popularity, it’s still not easy to debug React in the browser. React Developer Tools by Facebook and Redux DevTools by Zalmoxisus however, let you inspect, modify, and debug your code right in the browser. And now they’re available for Firefox. These add-ons, and others like the Vue add-on will make debugging popular JavaScript frameworks easier. When combined with Mozilla’s Debugger.html tool, all these stand-alone tools will turn your browser into a full-featured debugger.

React

Get the latest version of the React DevTool add-on here. Once it’s installed, you’ll be able to examine React code on any site that uses it. When you visit a React-powered site, the add-on icon will appear to the right of the Firefox address bar:

Open your DevTools by hitting command-option-i (control-shift-i for Windows), clicking the button in the toolbar, or right-clicking on the page and selecting “inspect.” You’ll see the React panel alongside the basic DevTools panels. The main panel will now show you the React tree view:

The React tool works pretty much like every other DevTool. Use the arrow keys or hjkl keys to navigate the code, right-click components to examine them in the elements pane, show source, and so on. Expand or collapse items by clicking the arrows.

The side pane is a great place to store variables and see updates to the code.

There’s also an awesome search bar.

Inspect a React element on a page using the regular inspector, then switch to the React tab. The element will automatically be selected in the React tree.

You can also right-click an element and choose “Find the DOM node” to, well, find the DOM node of any element.

Redux

React and Redux go together like avocado and toast. Redux creates a predictable state container for your React library that lets it run reliably on virtually any system. It also lets you “time travel” to previous versions of your states. The Redux devtool for Firefox lets you inspect Redux actions and payloads, cancel actions, log action reducer errors, and automatically re-evaluate staged actions when you change reducer code.

The Redux devtool has extensive docs on its GitHub repository, including arguments, methods, and even a tutorial on how to create a Redux store for debugging. Check them out.

With Firefox Add-ons, you can have a complete React/Redux debugging toolset right in your browser.
Download Firefox Developer Edition and then check out all the add-ons available at addons.mozilla.org.

Categorieën: Mozilla-nl planet

Air Mozilla: The Joy of Coding - Episode 107

Mozilla planet - wo, 26/07/2017 - 19:00

The Joy of Coding - Episode 107 mconley livehacks on real Firefox bugs while thinking aloud.

Categorieën: Mozilla-nl planet

The Firefox Frontier: Why You Should Fly Under The Radar When Booking A Trip

Mozilla planet - wo, 26/07/2017 - 18:26

For our fellow denizens in the Northern Hemisphere, it’s the height of summer, the season of getaways. But if you live on the internet like we do, you probably notice … Read more

The post Why You Should Fly Under The Radar When Booking A Trip appeared first on The Firefox Frontier.

Categorieën: Mozilla-nl planet

Tarek Ziadé: Python Microservices Development

Mozilla planet - wo, 26/07/2017 - 18:22

My new book, Python Microservices Development is out!

The last time I wrote a book, I was pretty sure I would not write a new one -- or at least not about Python. Writing a book is a lot of work.

The hard part is mostly about not quitting. After a day of work and taking care of the kids, sitting down again at my desk for a couple of hours was just hard, in particular since I do other stuff like running. I stole time from my wife.

The topic, "microservices" was also not easy to come around. When I was first approached by Packt to write it, I said no because I could not see any value of writing yet another book on that trendy (if not buzzwordy) topic.

But the project grew on me. I realized that in the past seven years, I have been working on services at Mozilla, we did move from a monolithic model to a microservices model. It happened because we moved most of our services to a cloud vendor, and when you do this, your application consumes a lot of services, and you end up splitting your applications into smaller pieces.

While picking Python 3 was a given, I hesitated a lot about writing the book using an asynchronous framework. I ended up sticking with a synchronous framework (Flask). Synchronous programming still seems to be mainstream in Python land. If we do a 2nd edition in a couple of years, I would probably use aiohttp :)

The other challenge is English. It is not my native language, and while I used Grammarly and I was helped a lot by Packt (they improved their editing process a lot since my first book there) it's probably something you will notice if you read it.

Technically speaking, I think I have done a good job at explaining how I think microservices should be developed. It should be useful for people that are wondering how to build their applications. Although I wished I had more time to finish polishing some of the code that goes with the book, thankfully that's on GitHub, so I still have a bit of time to finish that.

Kudos to Wil Khane-Green, my technical reviewer, who did a fantastic work. The book content is much better, thanks to him.

If you buy the book, let me know what you think, and do not hesitate to interact with me on Github or by email.

Categorieën: Mozilla-nl planet

Air Mozilla: Weekly SUMO Community Meeting July 26, 2017

Mozilla planet - wo, 26/07/2017 - 18:00

Weekly SUMO Community Meeting July 26, 2017 This is the sumo weekly call

Categorieën: Mozilla-nl planet

Christian Heilmann: How can we make more people watch conference videos?

Mozilla planet - wo, 26/07/2017 - 10:51

It is incredible how far we’ve come in the coverage of events. In the past, I recorded my own talks as audio as not many conferences offered video recordings (and wrote about this as a good idea in the developer evangelism handbook). These days I find myself having not having to do this as most conferences and even meetups record talks. Faster upload speeds and simple, free hosting on YouTube and others made that possible.

And yet it is expensive and a lot of work to record and publish videos of your conference. And if you don’t make any money with them it is a bit of advertising for your event with a lot of overhead. That’s why it is a shame to see just how low the viewing numbers of some great conference videos are. When talking to conference organisers, I heard some astonishingly low numbers. The only thing to boost them seems to be to deliver them one after the other with dedicated social media promotion. Which, again, is a lot of extra effort.

In order to see what would make people watch more conference talks, I took a quick Twitter poll:

Poll time: what would make you watch more conference videos?

— Chris Heilmann (@codepo8) July 11, 2017

Here are the quick results of 344 votes:

  • 29% chose shorter videos without Q&A
  • 37% would like transcripts with timestamps
  • 22% would like to have videos offline
  • 12% wanted captions.

I love watching conference talk videos. I watch them offline, on an iPod in the gym or on planes and trains. Basically when I am not able to do anything else, they are a great way to spend your time and learn something. There are a few things to consider to make this worth my while though:

  • The talk needs to make sense to watch on a small screen. Lots of live code in a terminal with a 12px font isn’t. That is not to say these aren’t good talks. They are just not working as a video.
  • The talk needs to be available offline (I use YouTube DL to download YouTube videos, some publishers on Vimeo offer downloads, Channel 9 always has the videos to download)
  • The talk needs to be contained in itself – it is frustrating to hear references to things I should know or bits that happened at the same event I wasn’t part of. It is even more annoying to see a Q&A session where you wait for the mic to arrive for ages or the presenter answering without me knowing what the question is.

I’ve written about the Q&A part of videos in detail before and I strongly believe that cutting a standard Q&A will result in more viewers and happier presenters. For starters, the videos will be shorter and it feels like less of an effort to watch the talk when it is 25 minutes instead of 45-50.

At technical events I am OK with some of these annoyances. After all, it is more important to entertain the audience at the event. And it is amazing when presenters take the time and effort to see other talks and reference them. However, there is a lot of benefit to consider the quality and consumption of a recording, too.

Having recordings of conference talks is an amazing gift to the community. People who can’t afford to go to events or even can’t afford to travel can still stay up-to-date and learn about topics to deep dive into by watching videos. Easy to consume, short and to the point videos can be a great way to increase the diversity of our market.

“You are here to talk to the online audience”

When I spoke at some TEDx events, this was the advice of the speaking coaches and organisers. TED is a known brand to have high quality online content. And it is almost unaffordable to go to the main TED events. Which makes this advice kind of odd, but their success online shows that there are on to something.

TED talks are much shorter than the average conference talk. They are more performance than presentation. And they come with transcripts and are downloadable.

Now, we can’t have only these kind of talks at events. But maybe it is a good plan to do some editing on the recordings and turn them into more of an experience than a record of what happened on stage that gets delivered as soon as possible. This means extra work and is some overhead, for sure. But I wonder how much of it could be automated already.

In addition to the poll results there were some other good points in the comments on Twitter and Facebook.

Less of the speaker upper body and more of the slides. Or slides to download. Also, speakers who pace themselves to sound good at 1.5x speed.

It seems to be pretty common by people who spend time watching talks to speed them up. This is an interesting concept. Good editing between slides and presenter was a wish a lot of people had. It shouldn’t be hard to publish the slides along with the video, and something presenters should consider doing more.

Not on the list but “editing” plus a solid couple of paragraphs of what the talk covers and why I should or shouldn’t watch it.

This is another easy thing for presenters to do. We’re always asked to offer a description and title of the talk that should zing and get people excited. Providing a second one that is more descriptive to use with the video isn’t that much overhead.

For English spokers, most of the conferences, no problem. But for non English spokers, massive failure. Reading is really more easy trying to listen and understand. Some guys speaks really fast. So I can’t understand talks.

This is a common problem and a presenter skill to work on. Being understandable by non-native speakers is a huge opportunity. So, some pacing and avoiding slang references are always a good idea.

The possibility to download the videos on tablets, smartphones and laptops so I can see them during commuting time

Offering videos to download should be not too hard. If you’re not planning to sell them anyways, why not?

Also offline availabilty with chapter marks/timestamps. I’ll vote for transcripts for skim reading to get to the gold nuggets. But sometimes a good speaker is an enjoyable 50min experience. I’d rather read transcripts. I never get blocks of quiet. Links to slides to follow along, or (even better) closed captions so I can play them muted If they were shorter and had a PowerPoint with main points to download after

This, of course, is the big one. A lot of people asked for transcripts, chapters and time stamps. Either for accessibility reasons or just because it is easier to skim and jump to what is important to you. This costs time and effort.

And here we have a Catch-22: if not many people watch the recordings of an event, conference organisers and companies don’t want to spend that time and effort. Manual transcription, editing and captioning isn’t cheap.

The good news is that automated transcription has gone leaps and bounds in the last years. With the need to have voice commands on mobiles and home appliances a lot of companies concentrated on getting this much better than it used to be.

YouTube has automated captions with editing functionality for free. Most cloud providers offer video insights.

One service that blew me away is VideoIndexer.

Video Indexer Interface

(Yes, this is by the company I work for, but it came as a surprise to me that this offer brings together many machine learning APIs in a simple interface.)

Using VideoIndexer, you not only generate an editable time-stamped transcript, but you also get emotion recognition, image to text conversion of video content, speaker recognition and keyword extraction. That way you to offer an interface that allows people to jump where they want to without having to scrub through the video. I’d love to see more offers like these and I am sure there are quite a few out there already in use by big TV companies and sports broadcasters.

Summary

All in all I am grateful to have the opportunity to watch talks of events I couldn’t be at and I’m making an effort to be a better online citizen by providing better descriptions and be more aware of how what I am saying can be consumed as a video afterwards.

My favourite quote in the comments was from Tessa Mero:

Would be fun watching it with someone so we can discuss the content during/after the video. Need social engagement to make learning more fun.

Videos of talks are a great opportunity to learn something and have fun with your colleagues in the office. Pick a room, set up a machine connected to the beamer, get some snacks in, watch the talk and discuss how it applies to your work afterwards. Conference organisers spend a lot of effort to record talks, presenters put a lot in to make the talk exciting and educational. And you can benefit from all of that for free.

Also published on Medium

Categorieën: Mozilla-nl planet

Air Mozilla: NSF WINS Bay Area Meet-Up

Mozilla planet - wo, 26/07/2017 - 03:30

NSF WINS Bay Area Meet-Up Mozilla and the National Science Foundation are partnering to give away $2M in prizes for wireless solutions that help connect the unconnected, keep communities connected...

Categorieën: Mozilla-nl planet

Air Mozilla: Egencia Training: Canada site- Eastern Time

Mozilla planet - di, 25/07/2017 - 19:42

 Canada site- Eastern Time Training and demo of Egencia Canada site [EST time] with Katt Taylor, Mozilla's Travel Coordinator with Workplace Resources.

Categorieën: Mozilla-nl planet

Firefox Test Pilot: Welcome!

Mozilla planet - di, 25/07/2017 - 19:07

Well, we finally did it. After more than a year, we decided to bite the bullet and start a blog to better document the magical, chaotic ride that is Firefox Test Pilot.

Some background: Test Pilot is a process and a platform structured to let Firefox Design, Product, and Engineering teams research, prototype, test, and iterate on experimental features in the Firefox browser. Since launching, we’ve researched, sketched, prototyped, coded, surveyed, and analyzed data for a dozen experiments, and we’re still at it today. As a matter of fact, we’re gearing up for a new set of launches!

Next month, we’re hitting another major milestone. We’ll be taking our first experiment from the nurturing embrace of our Test Pilot incubator and launching it in Firefox 55. The Page Shot experiment will soon become Firefox Screenshots. In making this transition, we’re scaling our audience by many, many, many orders of magnitude. This is exciting and a little bit scary at the same time. By the way, for our sophomore album we’re putting Activity Stream in Firefox later this fall.

The title slide of our first pitch deck

In a very short time, we’ve gone from conversations over beers to a team of more than 20 designers, researchers, and engineers spread across the globe building experiments to shape how Firefox works and what Firefox is. This blog represents our attempt to take stock of the things we’ve done in the last year: our successes, our failures, and what we’ve learned along the way. We’ll tackle design, research, and technical topics alike, but most of all we’ll just share the story of Test Pilot.

Ad astra!

Welcome! was originally published in Firefox Test Pilot on Medium, where people are continuing the conversation by highlighting and responding to this story.

Categorieën: Mozilla-nl planet

Hacks.Mozilla.Org: The MDN Redesign “Behind the Scenes”

Mozilla planet - di, 25/07/2017 - 17:20

Kuma, the code that produces the MDN site, is a weird mix of the old and the new. MDN turned ten in 2015 and there’s still code and content around from those very first days. When I sat down to start coding the current redesign, the first thing I did was remove the last few traces of the last redesign. In contrast, we have a cutting-edge audience: 92% of our users have a browser with CSS grid support! We enabled http2, and 98% of our users have seen benefits from that.

One of the ways we deal with old code in kuma is with the campsite rule: Always leave your campsite better than you found it. A redesign touches a lot of files, and this was a great opportunity to clean up and refactor — at least until the deadline started getting close.

A redesign is also a great time to change stuff you’re afraid of breaking. People are more understanding of you working the bugs out of something new than breaking something that’s worked for years. I removed 640 lines of stale code during the redesign. (And if I broke a six-year-old XPCOM tutorial you use daily by removing the custom list-style-type, please file a bug!)

One website with two looks

Rather than working on the CSS for the redesign in a separate “redesign” folder, we duplicated all the files and added “-old” to the file name of the old files, which means that all of our redesign work is happening in the “official” files. This preserves the git history and means we don’t have to move anything around after launch. Once we’re happy with the code, we can delete the “-old” files with confidence.

To serve the new styles to our beta testers and the “-old” ones to everyone else, we use Django Waffle. Waffle can also be used to serve different content but because there’s a strong separation of presentation and content on MDN, we’ve made very few changes to the HTML.

Bugs our beta testers found

MDN is huge, and we can’t test every page in every locale. We’re really lucky to have active beta testers. :) Some of the biggest things they turned up for us were:

Highlighting

Problems with Zilla Highlight in Vietnamese and when there's inline code examples.

We started out by replicating Mozilla’s brand “highlight” effect by using the Zilla Slab Highlight font, but we abandoned that pretty quickly when problems turned up in many of our locales and when used in combination with inline code.

The current approach puts a full-width black background on h3 and h4 headings by default, and then some JavaScript runs to add a <span> tag so that the black background hugs the heading text. Progressive enhancement at work.

We went back and forth about this for a while, wondering if the JavaScript and extra <span> was worth the effort. But we stuck with it because it makes the h3 and h4 headings much easier to spot when scanning the page.

What’s Taiwanese for Slab Serif?

Showing the difference between Zilla's thick strokes and the thin strokes of Taiwanese.

Previously we used Open Sans as our heading text. With the redesign, we switched to Zilla Slab. Open Sans was thin and an average height for a font. It didn’t look out of place next to the system fallbacks for Chinese or Japanese characters.

Zilla is big and thick, and we started getting feedback about the contrast with these system fallbacks. Additionally, the character set for Zilla is European Latin only at the moment, so Vietnamese, which uses Latin characters plus a couple Latin characters not used in Europe, displayed font fallbacks in the middles of words.

To address both these problems, we implemented a system that allowed us to override the site fonts on a per-locale basis. (Comment if you’d like a separate blog post about this).

Contrast

We received many complaints about the old design’s low-contrast display. We went a bit too far the other way with this design and received complaints about the high contrast. We’ve toned it down to the ever-popular #333 now.

What’s next

We’re moving on from this to make specific improvements to the article pages:

  • Putting code samples high on the page; our hard-working writers and volunteers are doing this, one page at a time.
  • A better approach to readable line-lengths and wide code examples, inspired by the Hacks Blog theme.
  • Compatibility tables that display desktop and mobile data side by side.
  • Code samples you can experiment with in the page.

See this early by signing up to be a beta tester.

Enjoyed beta testing MDN? You can also beta-test Firefox by downloading Nightly.

Who is “we”?

The MDN dev team is:

  • Stephanie Hobson, me, CSS-Pre-Pre-Processor
  • Schalk Neethling, who reviewed each of my 30+ pull requests in ALL THE BROWSERS, sometimes multiple times
  • John Whitlock, who did the awesome locale fallbacks
  • Ryan Johnson, who always asks “Why not?” when John and I say things can’t be done.

We blog sporadically on the Mozilla Marketing Engineering & Operations blog.

You should also read this blog post by our Product Manager, Kadir Topal, about The Future of MDN.

Categorieën: Mozilla-nl planet

Mozilla Reps Community: Council at the All Hands in San Francisco

Mozilla planet - di, 25/07/2017 - 13:05

The All Hands is a special time of the year where Mozilla employees along with core volunteers gather for a week of many meetings and brainstorming. The All Hands Wiki page has more information about the general setting. During the All Hands, the Reps Council participated in the Open Innovation meetings as well as had meetings about what we’ve accomplished in Q2 and the future of the program. One of our main topics was on how to get new developers involved as contributors in Mozilla projects.

Top topics

For that reason it was crucial to understand and discuss the mobilizers experiment and their outcomes with Srushtika, Daniele and Vigneshwer, in order to understand what are the issues and needs for Add-ons, Rust and WebVR and how we can create communities around those projects and attract new developers.

The idea “Open by Design” was discussed extensively while we’ve tried to understand how Reps program can contribute to the Strategy project. We also had a meeting with Patrick Finch to discuss a few strategy questions and to start the discussion on how the Reps program can help in the next few months.

Other meetings and sessions

We had other sessions as well. Also we did a lot of administrative tasks as well:

  • Participated in the Q&A Session with Chris Beard
  • Gave feedback on the World View project
  • We reviewed our Q2 OKRs and opened issues where necessary to continue in Q3
  • Updated the Wiki header of Reps pages with a link to the Leadership page
  • Moved the Council Chair from Konstantina to Flore
  • Started to document new criteria for Reps applications
  • Further documented the mobilizers initiative and discussed common topics that were raised around those
  • Had a meeting with Module Owner and Peers

MozActivate

Activate holds a special place at Reps activities. During the All Hands we held meetings about the website, the content of the activities and the future of the project. From the Council side Alex Lakatos with Michael Kohler are involved in the website building, while Konstantina Papadea and Ankit Gadgil are working with a focus on the content.

While in San Francisco we launched a new activity about Nightly which now is available on the website. Firefox Nightly is one of the most important projects happening right now in the Mozilla world and it’s crucial for us. We need to get new Firefox Nightly users.

We also joined discussions with the Rust and the Add-ons teams in order to better understand how the Reps Program can help to build their community or improve the promotion of those technologies.

On the feedback form front we are working on the dashboard to simplify the access to feedback of Activate events.

Categorieën: Mozilla-nl planet

Firefox Nightly: Stylo is ready for community testing on Nightly!

Mozilla planet - di, 25/07/2017 - 12:29

Quantum CSS, aka Stylo, aims to integrate Servo’s parallelized CSS style system written in Rust into Gecko.

Stylo is built with Firefox Nightly and is now ready for wider community testing. If you are using Firefox Nightly, you need to flip the pref layout.css.servo.enabled to true so as to use Stylo.

If you want to help test Stylo but haven’t yet installed Firefox Nightly, install it from nightly.mozilla.org and don’t hesitate to have a look at our community documentation about Nightly.

You can ask developers questions about Stylo in the #servo IRC channel (irc.mozilla.org/servo), if you find  a bug please file it in our Bug tracker, Bugzilla. The component to file your bugs  in is Core::CSS Parsing and Computation and start your summary field with Stylo:.

Here is a shortcut url to file bugs in this component:
New Stylo bug – Core::CSS Parsing and Computation

Stylo is making Firefox Nightly rendering of pages even faster and we are now working on chasing correctness and stability bugs so as to ship Stylo by default in Firefox 57, help us build this faster browser today, find and report bugs!

 

Categorieën: Mozilla-nl planet

Mozilla Future Releases Blog: Firefox Roadmap for Flash End-of-Life

Mozilla planet - di, 25/07/2017 - 11:00

This morning, Adobe announced its roadmap to stop supporting Flash at the end of 2020. Working with Adobe and other browser vendors, Mozilla has prepared a roadmap for Flash support in Firefox, and guides for site authors to make their final transition away from Flash technology. By managing this transition carefully, announcing it years in advance, and providing options for transition, Mozilla will help make the web faster, safer, and better for everyone.

To provide guidance for site authors and users that continue to rely on Flash, Mozilla has updated its ​published roadmap​ for Flash in Firefox. Starting next month, users will choose which websites are able to run the Flash plugin. Flash will be disabled by default for most users in 2019, and only users running the Firefox Extended Support Release (ESR) will be able to continue using Flash through the final end-of-life at the end of 2020. In order to preserve user security, once Flash is no longer supported by Adobe security patches, no version of Firefox will load the plugin.

As part of improving Firefox performance and security this year, Firefox users will choose which sites may run the Flash plugin. This choice will give users the ability to keep using legacy sites that require Flash, while letting modern sites shine with blazingly fast HTML speed. This change was announced ​last year​ and will ship in Firefox next month. Firefox users will still have the opportunity to enable Flash on specific sites that require it. It is possible to test this behavior today by ​downloading Firefox beta​ and ​changing the Flash setting in the Firefox Add-ons manager​. Because each browser implements this feature slightly differently, MDN Web Docs lists the ​differences in Flash activation​ among the major browsers as a guide for authors.

Screenshot of Spellstone on the Web

The Spellstone game has already migrated from Flash to HTML.

Over the years, Flash has helped bring the Web to greatness with innovations in media and animation, which ultimately have been added to the core web platform. The end of Flash offers an opportunity to bring legacy design and content in the Flash format into an new era using HTML and web technologies. If you are a site author currently using Flash to implement video, games, chat, file upload or clipboard access on your site, the web platform now has fast, secure, and reliable features which can do all of these tasks. Browser makers have prepared a guide to help website authors transition away from Flash to the open web. This transition guide​, published through MDN Web Docs, provides documentation and links to open web APIs, libraries, and frameworks to help make updating to the web platform a great experience.

 Kongregate shows that adoption of HTML games increased from zero in 2010 to 50% of all game updates this year.

HTML is being rapidly adopted for web games. Image provided courtesy of Kongregate.

Game developers that formerly built games for Flash are quickly switching to HTML and seeing great results. Last week, Kongregate published​ data about the transition to HTML and the trends in game technologies used on their web gaming platform. Mozilla works closely with games publishers and developers to ​advance the state​ of games on the Web, and ​continues to ​develop technologies such as WebAssembly which allow developers to achieve near-native performance. For more information about building great web games, see ​MDN Web Docs​.

This year, Firefox will become the fastest it has ever been. Reducing Flash usage now is an important part of making the web and Firefox better together, and will support the end of Flash in 2019 and 2020. The security and privacy features users have come to expect, combined with a new interface and added functionality, will streamline and modernize the browser experience for Firefox users.

 

The post Firefox Roadmap for Flash End-of-Life appeared first on Future Releases.

Categorieën: Mozilla-nl planet

This Week In Rust: This Week in Rust 192

Mozilla planet - di, 25/07/2017 - 06:00

Hello and welcome to another issue of This Week in Rust! Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR.

Updates from Rust Community News & Blog Posts Crate of the Week

This week's crate is cute, a crate containing a macro to allow Python (or Haskell) style comprehensions (e.g. c![x / 2, for x in 0..10, if (x & 1) == 0]). Thanks to Willi Kappler for the suggestion.

Submit your suggestions and votes for next week!

Call for Participation

Always wanted to contribute to open-source projects but didn't know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

If you are a Rust project owner and are looking for contributors, please submit tasks here.

Updates from Rust Core

110 pull requests were merged in the last week

New Contributors
  • Bruce Mitchener
  • Evan Cameron
  • Jacques-Henri Jourdan
  • Joe Ranweiler
  • Others
  • Perry Fraser
Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

Final Comment Period

Every week the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. This week's FCPs are:

New RFCs Style RFCs

Style RFCs are part of the process for deciding on style guidelines for the Rust community and defaults for Rustfmt. The process is similar to the RFC process, but we try to reach rough consensus on issues (including a final comment period) before progressing to PRs. Just like the RFC process, all users are welcome to comment and submit RFCs. If you want to help decide what Rust code should look like, come get involved!

The RFC style is now the default style in Rustfmt - try it out and let us know what you think!

Currently being discussed:

Upcoming Events

If you are running a Rust event please add it to the calendar to get it mentioned here. Email the Rust Community Team for access.

Rust Jobs

Tweet us at @ThisWeekInRust to get your job offers listed here!

Quote of the Week

No quote was selected for QotW.

Submit your quotes for next week!

This Week in Rust is edited by: nasa42, llogiq, and brson.

Categorieën: Mozilla-nl planet

Justin Dolske: Photon Engineering Newsletter #9

Mozilla planet - di, 25/07/2017 - 02:31

Well, here we go again with a big update for Newsletter #9! [Since the last update, I took a vacation and ever since have been getting caught up. So this update is terribly overdue. Sorry about that!]

Animations

Animations for toolbar icons are finally landing! Yaaaaay! :kermithands: The stop/reload and pin-to-overflow animations are in Nightly, and the Pocket, bookmarks, and downloads icons are next. I’d like to talk a little about the way these animations are implemented. The effect is simple, but there’s a lot of work behind the scenes.

As is often the case in engineering, we had a number of requirements that needed to be satisfied. The most important was performance – we’re making Firefox 57 blazing fast, and it wouldn’t do to have animations hurting that work. We worked closely with our Graphics and Platform teams to develop a technique (more on that in a second) that was efficient, and specifically could run entirely within the compositor process. This helps ensure the animation can smoothly run at 60fps without impacting (or being impacted by) all the other stuff running in the browser. The other big requirement was around UX. We wanted to minimize the platform technical constraints for our visual designers, so that their ideas were not bound by platform limitations. [For example, we had an old patch to convert the page-loading throbber from an APNG to a static image animated with a CSS transform (rotation). That’s nice, but then you’re limited to effects possible in pure CSS.] We also needed to use SVG in the animation, since the rest of Firefox’s icons are SVG now. This gives the best result when scaling to different display DPI settings, and allows us to dynamically adjust the icon colors based on system style.

The technique we’re using for Photon is based around an SVG “filmstrip” – each frame is pre-drawn separately within an SVG image. We then use CSS to crop it to a specific frame, and a CSS Animation to move the crop box for each frame. Since it’s all declarative, Gecko and the compositor process can handle the animation very efficiently.

filmstrip

A demo is worth 10,000 words, so check out Jared’s SVG Filmstrip Demo to see how this works in detail. (Since it’s all based on web technologies, you can view-source and see the same technique running in your browser that we use in chrome.)

Of course, nothing is ever simple! There’s a lot of work that goes into getting these assets ready. First, our visual designers prototype an animation in Adobe After Effects. It then goes through a process of design iteration and user testing. (Is is distracting? Does it communicate what we want? Too fast? Too slow?) The animation is then exported to an SVG file, but the markup from Adobe is usually not very good. So we use SVGO to optimize it, often further hand-tune the SVGO output, and finally tweak it to make use of the dynamic context-fill color specified from the browser’s CSS.

Phew! But thankfully, as a user, you can just enjoy the finished result. We’d like to refine the creation process, but overall it’s a pretty powerful and flexible technique that we’ll be using more and more.

Recent Changes

Menus/structure:

  • Lots of minor bugfixes to various aspects of the earlier changes we made. Thanks to contributors Jeongkyu Kim (bug 1376484) and Adolfo Jayme (bug 1376097) for their work!
  • Flexible spacers are now available in customize mode. This is the first step towards having the location field be centered in the navbar, as part of the Photon design.
  • Work on the Page Action panel is progressing. We gave a prototype sneak-peek at the All-Hands (see Photon Newsletter #8), but it’s not quite ready to land yet.
  • Made the Library button work correctly in the overflow panel.
  • Removed the Page Setup item from the hamburger menu, as it was a bit confusing and the functionality can be accessed elsewhere.

Animation:

  • The Pin to Overflow animation landed, try it now! Right-click on a toolbar button and use “Pin to Overflow Menu” to see the awesome animation!
    pintooverflow
  • The Stop/Reload animation also landed! We’ve got great feedback about speeding it up and making it less distracting, will be working on that soon. You may have noticed that, while animating, the icon looks thinner than the normal (static) icon… We’ll be updating all the toolbar icons to this new Photon style in a few weeks, which will make the transition between states feel smoother.
    stopreload
  • The Save to Pocket animation is going through review, once that’s landed we’ll start implementation of the new bookmarking animation.
  • The new arrow-panel animations landed… but bounced due to test failures. We’re working around the failures by disabling the animation in tests, which means we bumped up the priority of having the panel animations be controlled by the toolkit.cosmeticAnimations.enabled preference. Once this is all hooked up and tests are happy, the animation will reland.

Preferences:

  • The prefs reorg v2.0 has now landed! (Check out the design specs for the details of exactly what changed.) This had a rough time getting landed, as it encountered a string of tricky intermittent test failures and memory leaks. Kudos to the team for working through it all and getting it landed!
  • Improved display on small screens by fixing some wrapping issues that were causing scrolling.

Visual redesign:

  • On Windows 10, we will now use the system accent color in the title bar, when you’ve enabled this in your Windows settings.
    • You’ll first need to open the following OS dialog, by right-clicking on your Desktop, selecting Personalize, and then selecting the Colors section. Scroll down to “Show accent color on the following surfaces” and enable the “Title bars” checkbox.
      colorsUI
    • You can now select different colors here, and have them show up in Firefox. (Or use the setting at the top of that dialog to have Windows automatically pick a color that complements your desktop background)
      colors
  • Styling followups to the identity block (the leftmost button in the URL bar) when hovering/clicking it.
  • The UI Density control is now ordered by logical size, and we fixed an issue that made the text labels unreadable on Linux.
  • Search textbox widget styling has been updated to be common across the browser.
  • Slightly increased the size of the tab overflow indicator.
  • A number of followup bugfixes for the title bar on Windows 10.

Onboarding:

  • Turned off the compact newtab tiles. Originally we thought enabling the new style would be a good transition to the Activity Stream style, but on further reflection it felt too much like making 2 differing changes. So Firefox release users will continue to see the existing (old) newtab page in Firefox 56, until Activity Stream fully replaces it in 57. (Activity Stream is now enabled on Nightly, so all the changes here make it a little confusing to explain, sorry!)
  • The onboarding overlay will be hidden when browser is too narrow, as the current design/implementation requires a minimum width or else it overflows the window.
  • The tour notifications shown at the bottom of a new tabs and about:home are now suppressed for the first few minutes of using the browser, and will rotate to a different suggestion after a certain amount of time or number of impressions. Also, the slide-up animation was removed to make it less distracting.
  • The tour step to set your default browser will now show an alternative message if you’ve already made Firefox your default browser.
  • Our UITour support can now open the awesomebar with a search term pre-filled, which will be used for Firefox 57 Address Bar tour to demonstrate searching from the awesomebar.

Performance:

 

That’s all (!) for this update.


Categorieën: Mozilla-nl planet

Mozilla Marketing Engineering & Ops Blog: MozMEAO SRE Status Report - July 25, 2017

Mozilla planet - di, 25/07/2017 - 02:00

Here’s what happened on the MozMEAO SRE team from July 18th - July 25th.

Current work MDN

We started discussing hosting for the MDN Live Sample Code Editor using a strategy similar to what was used for IRLPodcast.

  • MDN discussion here.
  • Infrastructure discussion here.
Ireland Deis 1/Fleet cluster decommissioning

Now that our Frankfurt Kubernetes cluster is up and running, we’re getting ready to decommission our Ireland Deis 1/Fleet cluster.

Once the Ireland cluster has been shut down, we’ll continue on to our Portland cluster.

Virginia cluster decom

In order to decommission our Virginia Kubernetes cluster, we need to finish moving a few smaller apps to a different region or hosting:

Kubernetes
  • snippets and snippets-stats are now running in our Frankfurt cluster and have been added to each respective Route 53 traffic policy.
Links
Categorieën: Mozilla-nl planet

Pagina's