Mozilla Nederland LogoDe Nederlandse
Mozilla gemeenschap

Mozilla's $50 Firefox OS smartphones reportedly launching in India this month - Firstpost

Nieuws verzameld via Google - wo, 16/07/2014 - 12:08


Mozilla's $50 Firefox OS smartphones reportedly launching in India this month
Mozilla could partner with only one or two telecom operators in these countries which brought a relatively lukewarm response towards these ultra-cheap smartphones. However, it expects to meet a different fate in India as Mozilla is seeking cooperation ...
Mozilla To Launch World's Cheapest Firefox OS Smartphones in India This JulyGizbot
Firefox smartphones to be launched in India in July, says Mozilla COODigitimes
Mozilla to launch Firefox smartphones in India in JulyTelecompaper (subscription)
KpopStarz -MotoringCrunch
alle 11 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Mozilla To Launch World's Cheapest Firefox OS Smartphones in India This July - Gizbot

Nieuws verzameld via Google - wo, 16/07/2014 - 11:23


Mozilla To Launch World's Cheapest Firefox OS Smartphones in India This July
In a latest report by Digitimes, Mozilla Taiwan CEO and company COO Gong Li has confirmed that the company will launch inexpensive smartphones in India at a price of around $50 (Rs 3,000 approx.). As per the report, Gong Li also added that in India ...
Mozilla's $50 Firefox OS smartphones reportedly launching in India this monthFirstpost
Firefox smartphones to be launched in India in July, says Mozilla COODigitimes
Mozilla to launch Firefox smartphones in India in JulyTelecompaper (subscription)
KpopStarz -MotoringCrunch
alle 10 nieuwsartikelen »
Categorieën: Mozilla-nl planet

New Mozilla JPEG Encoder Trims File Size - Headlines & Global News

Nieuws verzameld via Google - wo, 16/07/2014 - 11:18

Headlines & Global News

New Mozilla JPEG Encoder Trims File Size
Headlines & Global News
"Facebook supports the work Mozilla has done in building a JPEG encoder that can create smaller JPEGs without compromising the visual quality of photos," Stacy Kerkela, software engineering manager at Facebook, said in a press statement. "We look ...

Google Nieuws
Categorieën: Mozilla-nl planet

Mozilla's advanced JPG encoder cuts file sizes by five per cent - HEXUS

Nieuws verzameld via Google - wo, 16/07/2014 - 11:16


Mozilla's advanced JPG encoder cuts file sizes by five per cent
Mozilla has announced the availability of mozjpeg 2.0 via its research blog. We previously heard about this project to refine a "production-quality JPEG encoder" to offer better optimised images in March this year. Now the v2.0 fruits of that labour ...

Google Nieuws
Categorieën: Mozilla-nl planet

Luis Villa: Designers and Creative Commons: Learning Through Wikipedia Redesigns

Mozilla planet - wo, 16/07/2014 - 08:31

tl;dr: Wikipedia redesigns mostly ignore attribution of Wikipedia authors, and none approach the problem creatively. This probably says as much or more about Creative Commons as it does about the designers.

disclaimer-y thing: so far, this is for fun, not work; haven’t discussed it at the office and have no particular plans to. Yes, I have a weird idea of fun.

Refresh variant from
A mild refresh from

It is no longer surprising when a new day brings a new redesign of Wikipedia. After seeing one this weekend with no licensing information, I started going back through seventeen of them (most of the ones listed on-wiki) to see how (if at all) they dealt with licensing, attribution, and history. Here’s a summary of what I found.

Completely missing

Perhaps not surprisingly, many designers completely remove attribution (i.e., history) and licensing information in their designs. Seven of the seventeen redesigns I surveyed were in this camp. Some of them were in response to a particular, non-licensing-related challenge, so it may not be fair to lump them into this camp, but good designers still deal with real design constraints, and licensing is one of them.

History survives – sometimes

The history link is important, because it is how we honor the people who wrote the article, and comply with our attribution obligations. Five of the seventeen redesigns lacked any licensing information, but at least kept a history link.

Several of this group included some legal information, such as links to the privacy policy, or in one case, to the Wikimedia Foundation trademark page. This suggests that our current licensing information may be presented in a worse way than some of our other legal information, since it seems to be getting cut out even by designers who are tolerant of some of our other legalese?

Same old, same old

Four of the seventeen designs keep the same old legalese, though one fails to comply by making it impossible to get to the attribution (history) page. Nothing wrong with keeping the existing language, but it could reflect a sad conclusion that licensing information isn’t worth the attention of designers; or (more generously) that they don’t understand the meaning/utility of the language, so it just gets cargo-culted around. (Credit to Hamza Erdoglu , who was the only mockup designer who specifically went out of his way to show the page footer in one of his mockups.)

A winner, sort of!

Of the seventeen sites I looked at, exactly one did something different: Wikiwand. It is pretty minimal, but it is something. The one thing: as part of the redesign, it adds a big header/splash image to the page, and then adds a new credit specifically for the author of the header/splash image down at the bottom of the page with the standard licensing information. Arguably it isn’t that creative, just complying with their obligations from adding a new image, but it’s at least a sign that not everyone is asleep at the wheel.


This is surely not a large or representative sample, so all my observations from this exercise should be taken with a grain of salt. (They’re also speculative since I haven’t talked to the designers.) That said, some thoughts besides the ones above:

  • Virtually all of the designers who wrote about why they did the redesign mentioned our public-edit-nature as one of their motivators. Given that, I expected history to be more frequently/consistently addressed. Not clear whether this should be chalked up to designers not caring about attribution, or the attribution role of history being very unclear to anyone who isn’t an expect. I suspect the latter.
  • It was evident that some of these designers had spent a great deal of time thinking about the site, and yet were unaware of licensing/attribution. This suggests that people who spend less time with the site (i.e., 99.9% of readers) are going to be even more ignorant.
  • None of the designers felt attribution and licensing was even important enough to experiment on or mention in their writeups. As I said above, this is understandable but sort of sad, and I wonder how to change it.

Postscript, added next morning:

I think it’s important to stress that I didn’t link to the individual sites here, because I don’t want to call out particular designers or focus on their failures/oversights. The important (and as I said, sad) thing to me is that designers are, historically, a culture concerned with licensing and attribution. If we can’t interest them in applying their design talents to our problem, in the context of the world’s most famously collaborative project, we (lawyers and other Commoners) need to look hard at what we’re doing, and how we can educate and engage designers to be on our side.

I should also add that the WMF design team has been a real pleasure to work with on this problem, and I look forward to doing more of it. Some stuff still hasn’t made it off the drawing board, but they’re engaged and interested in this challenge. Here is one example.

Categorieën: Mozilla-nl planet

Byron Jones: happy bmo push day!

Mozilla planet - wo, 16/07/2014 - 08:30

switching the default monospace font on bmo yesterday highlighted a few issues with the fira-mono typeface that we’d like to see addressed before we use it.  as a result comments are now displayed using their old font.

the following changes have been pushed to

discuss these changes on

Filed under: bmo, mozilla
Categorieën: Mozilla-nl planet

Mozilla mozjpeg 2.0 soll Bilder kleiner machen - Software und jede Menge Tipps & Tricks

Nieuws verzameld via Google - wo, 16/07/2014 - 07:01

Mozilla mozjpeg 2.0 soll Bilder kleiner machen
Software und jede Menge Tipps & Tricks
Um das Web schneller zu machen, braucht es keine neuen Bildformate. Dies behauptet zumindest Mozilla. Je schneller Bilder geladen werden, desto besser. Google hat für sich 2010 das Format WebP erdacht und eine stärkere Kompression bei ...
Mozilla will mit Facebook-Hilfe JPEGs verkleinernFuturezone
Mozilla stellt mozjpeg 2.0 fertig, Facebook investiert in
"Firefox-Hersteller Mozilla hat seinen JPEG-Encoder mozjpeg 2."Ad-Hoc-News (Pressemitteilung)

alle 4 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Mozilla and Facebook snip a further five per cent from all JPEGs - Register

Nieuws verzameld via Google - wo, 16/07/2014 - 05:34

Mozilla and Facebook snip a further five per cent from all JPEGs
Just four months after loosing the mozjpeg encoder on a waiting world, Mozilla has updated it to version 2.0, at the same time announcing that Facebook is testing the new iteration. The Social NetworkTM has also slung Mozilla $US60,000 towards the ...

Categorieën: Mozilla-nl planet

Mozilla and Facebook team up to make the JPEG leaner, meaner - TechRadar UK

Nieuws verzameld via Google - wo, 16/07/2014 - 02:11

Mozilla and Facebook team up to make the JPEG leaner, meaner
TechRadar UK
Two internet titans are joining forces to bring renewed life to those crusty old JPEG files by cutting them down to size. Mozilla announced that the decades-old JPEG file format is about to get a little more efficient when it comes to bandwidth ...

Categorieën: Mozilla-nl planet

Jess Klein: The first 6 weeks of Hive Labs

Mozilla planet - wo, 16/07/2014 - 00:05
Six weeks ago, Atul Varma, Chris Lawrence, Kat Baybrooke and I embarked on an experiment we call Hive Labs. Let me tell you about, Let me show you a little slideshow I made about our first 6 weeks to the tune of Josh Gad singing In Summer from the movie Frozen.

So, in summary (or if you aren't the musical slideshare type) the first 6 weeks have been great. We did a bunch of listening and research, including attending events and hackjams run by and for Hive members. Here's a neat worksheet from a Mouse run Webmaker training in New York. 

We did some research and design on tools and resources to support prototyping:

Sherpa is a codename for a tool that helps prototypers define a design opportunity and openly work through the process for designing a solution. We designed some mockups to see if this is a direction that we should pursue. Sherpa could be a back-end for the "Cupcake dashboard" or be a stand alone tool. We spun up an instance of the "Cupcakes" dashboard  designed by the Firefox UX team to help figure out if it is a useful tool to surface prototypes.

We also prototyped a snippet for Firefox to promote Maker Party, worked on an idea for self guided Webmaking and began work on a Net Neutrality Teaching Kit.

Finally, we've shipped some things:
The No-Fi, Lo-Fi Teaching Kit and the Mobile Design Teaching Kit
The No-Fi Lo-Fi Teaching Kit asks participants the question how can we empower educators to teach the web in settings where connectivity isn't guaranteed?
With the Mobile Design Teaching Kit, participants play with, break apart and modify mobile apps in order to understand how they work as systems. This teaching kit is designed to explore a few activities that can be mixed and mashed into workshops for teens or adults who want to design mobile apps. Participants will tinker with paper prototyping, design mindmaps and program apps while learning basic design and webmaking concepts.
A local and a global Hive Learning Network directory
... and a section on to help guide mentors through making Teaching Kits and Activities:

The first 6 weeks have been great, and we are going to continue to listen, create and deliver based on needs from the community. We have lots more to build. We want to do this incrementally, partly to release sooner, and partly to build momentum through repeated releases.

Categorieën: Mozilla-nl planet

Armen Zambrano Gasparnian: Developing with GitHub and remote branches

Mozilla planet - ti, 15/07/2014 - 23:04
I have recently started contributing using Git by using GitHub for the Firefox OS certification suite.

It has been interestting switching from Mercurial to Git. I honestly believed it would be more straight forward but I have to re-read again and again until the new ways sink in with me.

jgraham shared with me some notes (Thanks!) with regards what his workflow looks like and I want to document it for my own sake and perhaps yours:
git clone

# Time passes

# To develop something on master
# Pull in all the new commits from master

git fetch origin

# Create a new branch (this will track master from origin,
# which we don't really want, but that will be fixed later)

git checkout -b my_new_thing origin/master

# Edit some stuff

# Stage it and then commit the work

git add -p
git commit -m "New awesomeness"

# Push the work to a remote branch
git push --set-upstream origin HEAD:jgraham/my_new_thing

# Go to the GH UI and start a pull request

# Fix some review issues
git add -p
git commit -m "Fix review issues" # or use --fixup

# Push the new commits
git push

# Finally, the review is accepted
# We could rebase at this point, however,
# we tend to use the Merge button in the GH UI
# Working off a different branch is basically the same,
# but you replace "master" with the name of the branch you are working off.

Creative Commons License
This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
Categorieën: Mozilla-nl planet

Mozilla will mit Facebook-Hilfe JPEGs verkleinern - Futurezone

Nieuws verzameld via Google - ti, 15/07/2014 - 19:58

Mozilla will mit Facebook-Hilfe JPEGs verkleinern
Wie Mozilla in einem Blogeintrag bekanntgab, ist am Dienstag der JPEG-Encoder mozjpeg in der finalen Version 2.0 bereitgestellt worden. Das erst im März 2014 offiziell ins Leben gerufene Projekt, das eine hochwertige Komprimierung von Bilddateien bei ...
"Firefox-Hersteller Mozilla hat seinen JPEG-Encoder mozjpeg 2."Ad-Hoc-News (Pressemitteilung)

alle 2 nieuwsartikelen »Google Nieuws
Categorieën: Mozilla-nl planet

Alon Zakai: Massive, a new work-in-progress asm.js benchmark - feedback is welcome!

Mozilla planet - ti, 15/07/2014 - 19:26
Massive is a new benchmark for asm.js. While many JavaScript benchmarks already exist, asm.js - a strict subset of JavaScript, designed to be easy to optimize - poses some new challenges. In particular, asm.js is typically generated by compiling from another language, like C++, and people are using that approach to run large asm.js codebases, by porting existing large C++ codebases (for example, game engines like Unity and Unreal).

Very large codebases can be challenging to optimize for several reasons: Often they contain very large functions, for example, which stress register allocation and other compiler optimizations. Total code size can also cause pauses while the browser parses and prepares to execute a very large script. Existing JavaScript benchmarks typically focus on small programs, and tend to focus on throughput, ignoring things like how responsive the browser is (which matters a lot for the user experience). Massive does focus on those things, by running several large real-world codebases compiled to asm.js, and testing them on throughput, responsiveness, preparation time and variance. For more details, see the FAQ at the bottom of the benchmark page.

Massive is not finished yet, it is a work in progress - the results should not be taken seriously yet (bugs might cause some things to not be measured accurately, etc.). Massive is being developed as an open source project, so please test it and report your feedback. Any issues you find or suggestions for improvements are very welcome!

Categorieën: Mozilla-nl planet

Mozilla's new image encoder compresses images 5 percent more, Facebook ... - VentureBeat

Nieuws verzameld via Google - ti, 15/07/2014 - 19:21


Mozilla's new image encoder compresses images 5 percent more, Facebook ...
Mozilla says mozjpeg jand can compress both baseline and progressive JPEGs, reducing the size of either by an average 5 percent, with many images showing significantly larger reductions. Previous versions of mozjpeg only improved compression for ...

Categorieën: Mozilla-nl planet

Gregory Szorc: Python Packaging Do's and Don'ts

Mozilla planet - ti, 15/07/2014 - 19:20

Are you someone who casually interacts with Python but don't know the inner workings of Python? Then this post is for you. Read on to learn why some things are the way they are and how to avoid making some common mistakes.

Always use Virtualenvs

It is an easy trap to view virtualenvs as an obstacle, a distraction towards accomplishing something. People see me adding virtualenvs to build instructions and they say I don't use virtualenvs, they aren't necessary, why are you doing that?

A virtualenv is effectively an overlay on top of your system Python install. Creating a virtualenv can be thought of as copying your system Python environment into a local location. When you modify virtualenvs, you are modifying an isolated container. Modifying virtualenvs has no impact on your system Python.

A goal of a virtualenv is to isolate your system/global Python install from unwanted changes. When you accidentally make a change to a virtualenv, you can just delete the virtualenv and start over from scratch. When you accidentally make a change to your system Python, it can be much, much harder to recover from that.

Another goal of virtualenvs is to allow different versions of packages to exist. Say you are working on two different projects and each requires a specific version of Django. With virtualenvs, you install one version in one virtualenv and a different version in another virtualenv. Things happily coexist because the virtualenvs are independent. Contrast with trying to manage both versions of Django in your system Python installation. Trust me, it's not fun.

Casual Python users may not encounter scenarios where virtualenvs make their lives better... until they do, at which point they realize their system Python install is beyond saving. People who eat, breath, and die Python run into these scenarios all the time. We've learned how bad life without virtualenvs can be and so we use them everywhere.

Use of virtualenvs is a best practice. Not using virtualenvs will result in something unexpected happening. It's only a matter of time.

Please use virtualenvs.

Never use sudo

Do you use sudo to install a Python package? You are doing it wrong.

If you need to use sudo to install a Python package, that almost certainly means you are installing a Python package to your system/global Python install. And this means you are modifying your system Python instead of isolating it and keeping it pristine.

Instead of using sudo to install packages, create a virtualenv and install things into the virtualenv. There should never be permissions issues with virtualenvs - the user that creates a virtualenv has full realm over it.

Never modify the system Python environment

On some systems, such as OS X with Homebrew, you don't need sudo to install Python packages because the user has write access to the Python directory (/usr/local in Homebrew).

For the reasons given above, don't much around with the system Python environment. Instead, use a virtualenv.

Beware of the package manager

Your system's package manager (apt, yum, etc) is likely using root and/or installing Python packages into the system Python.

For the reasons given above, this is bad. Try to use a virtualenv, if possible. Try to not use the system package manager for installing Python packages.

Use pip for installing packages

Python packaging has historically been a mess. There are a handful of tools and APIs for installing Python packages. As a casual Python user, you only need to know of one of them: pip.

If someone says install a package, you should be thinking create a virtualenv, activate a virtualenv, pip install <package>. You should never run pip install outside of a virtualenv. (The exception is to install virtualenv and pip itself, which you almost certainly want in your system/global Python.)

Running pip install will install packages from PyPI, the Python Packaging Index by default. It's Python's official package repository.

There are a lot of old and outdated tutorials online about Python packaging. Beware of bad content. For example, if you see documentation that says use easy_install, you should be thinking, easy_install is a legacy package installer that has largely been replaced by pip, I should use pip instead. When in doubt, consult the Python packaging user guide and do what it recommends.

Don't trust the Python in your package manager

The more Python programming you do, the more you learn to not trust the Python package provided by your system / package manager.

Linux distributions such as Ubuntu that sit on the forward edge of versions are better than others. But I've run into enough problems with the OS or package manager maintained Python (especially on OS X), that I've learned to distrust them.

I use pyenv for installing and managing Python distributions from source. pyenv also installs virtualenv and pip for me, packages that I believe should be in all Python installs by default. As a more experienced Python programmer, I find pyenv just works.

If you are just a beginner with Python, it is probably safe to ignore this section. Just know that as soon as something weird happens, start suspecting your default Python install, especially if you are on OS X. If you suspect trouble, use something like pyenv to enforce a buffer so the system can have its Python and you can have yours.

Recovering from the past

Now that you know the preferred way to interact with Python, you are probably thinking oh crap, I've been wrong all these years - how do I fix it?

The goal is to get a Python install somewhere that is as pristine as possible. You have two approaches here: cleaning your existing Python or creating a new Python install.

To clean your existing Python, you'll want to purge it of pretty much all packages not installed by the core Python distribution. The exception is virtualenv, pip, and setuptools - you almost certainly want those installed globally. On Homebrew, you can uninstall everything related to Python and blow away your Python directory, typically /usr/local/lib/python*. Then, brew install python. On Linux distros, this is a bit harder, especially since most Linux distros rely on Python for OS features and thus they may have installed extra packages. You could try a similar approach on Linux, but I don't think it's worth it.

Cleaning your system Python and attempting to keep it pure are ongoing tasks that are very difficult to keep up with. All it takes is one dependency to get pulled in that trashes your system Python. Therefore, I shy away from this approach.

Instead, I install and run Python from my user directory. I use pyenv. I've also heard great things about Miniconda. With either solution, you get a Python in your home directory that starts clean and pure. Even better, it is completely independent from your system Python. So if your package manager does something funky, there is a buffer. And, if things go wrong with your userland Python install, you can always nuke it without fear of breaking something in system land. This seems to be the best of both worlds.

Please note that installing packages in the system Python shouldn't be evil. When you create virtualenvs, you can - and should - tell virtualenv to not use the system site-packages (i.e. don't use non-core packages from the system installation). This is the default behavior in virtualenv. It should provide an adequate buffer. But from my experience, things still manage to bleed through. My userland Python install is extra safety. If something wrong happens, I can only blame myself.


Python's long and complicated history of package management makes it very easy for you to shoot yourself in the foot. The long list of outdated tutorials on The Internet make this a near certainty for casual Python users. Using the guidelines in this post, you can adhere to best practices that will cut down on surprises and rage and keep your Python running smoothly.

Categorieën: Mozilla-nl planet

Mozilla introduceert efficiëntere jpeg-encoder - Tweakers

Nieuws verzameld via Google - ti, 15/07/2014 - 19:07

Mozilla introduceert efficiëntere jpeg-encoder
Mozilla heeft een efficiëntere encoder voor jpeg-afbeeldingen geïntroduceerd. De encoder is compatibel met bestaande decoders en zou afbeeldingen gemiddeld vijf procent kleiner kunnen maken. Facebook voert al proeven uit met de nieuwe encoder.

Categorieën: Mozilla-nl planet

Darrin Henein: Side Tabs: Prototyping An Unexpected Productivity Hack

Mozilla planet - ti, 15/07/2014 - 18:24

A few months ago, I came across an interesting Github repo authored by my (highly esteemed!) colleague Vlad Vukicevic called VerticalTabs. This is a Firefox add-on which moves your tabs, normally organized horizontally along the top of your browser, to a vertical list docked to either the left or right side of the window. Vlad’s add-on worked great, but I saw a few areas where a small amount of UX and visual design love could make this something I’d be willing to trial. So, I forked.


After cloning the repo, I spent a couple days modifying some of the layout, adding a new dark theme to the CSS, and replaced a handful of the images and icons with my own. Ultimately, it was probably a single-digit number of hours spent to get my code to a place that I was happy with. Certainly, there are some issues on certain operating systems, and things like Firefox’s pinned tabs don’t get the treatment I would love them to have, but that was not the point. The point of my experiment was to learn.

Learn? Learn what?

Let’s step back for a moment. Here at Mozilla, we like to experiment. Hack, Play, Make… whatever you’d like to call it. But we don’t like to waste time: we do things with purpose. If we build something, we try to make sure it’s worth the time and effort involved. As a Design Engineer on the UX team, I (along with others) work hard to bring and make clear the value of prototyping to my colleagues. What is the minimal thing we can make to test our assumptions? The reality is that when designing digital products, how it works is equally (arguably more) important than how it looks. Steve Jobs said it best:

Design is how it works.


Let’s bring it back to Side Tabs now (I’ll be using Side Tabs and VerticalTabs interchangeably). The hypothesis I was hoping to validate was that there was a subset of the Firefox user base that would find value in the layout that Side Tabs enabled. I wanted to bring this add-on to a level where users would find it delightful and usable enough to at least give it a fair shot.

It’s critically important that before you unleash your experiment and start learning from it, you mitigate (as much as possible) any sources of bias or false-negatives. Make (or fake) it to a point where the data you collect is not influenced by poor design, conflated features, or poor performance/usability. It turned out that this delta, from Vlad’s work to my own version, was a small amount of work. I went for it, pushed it a few steps in the right direction, and shared it with as many people as I could.

I want to restate: the majority of the credit for my particular version of VerticalTabs goes to those who published the work on top of which I built, namely Vlad and Philipp von Weitershausen. Furthermore, the incredibly talented Stephen Horlander has explored the idea of Side Tabs as well, and you will notice his work helped inspire the visual language I used in my implementation. This is how great things are built; rarely from scratch, but more commonly on the shoulders and brilliance of those who came before you.

My Github repo (at time of writing) has 13 stars and is part of a graph with 19 forks. Similarly, I’ve had colleagues fork my repo and take it further, adding improvements and refinements as they go (see my colleague Hayden’s work for one promising effort). I’ve had great response on Twitter from developers and users who love the add-on and who can’t wait to share their ideas and thoughts. It’s awesome to see ideas take shape and grow so organically like this. This is collaboration.

I’ve been using Side Tabs full-time in my default browser (Firefox Nightly) for 5 or 6 months now, and I’ve learned a ton. Aside from now preferring a horizontal layout (made possible by stacking tabs vertically) on a screen pressed for vertical space, I’ve discovered a use case that I never would have imagined had I simply mocked this idea up in Photoshop.

I use productivity tools heavily, from calendars to to-do lists and beyond. One common scenario is this: I click on a link, and it’s something I find interesting or valuable, but I don’t want to address it right now. I’ve experimented with Pocket (I still use this for longer form writing I wish to read later) but find that most of my Read Later lists are Should-but-Never-Actually-Read-Later lists. Out of sight, out of mind, right?

Saving for Later

The Firefox UX Team has actually done some great research on Save for Later behaviour. There is a great blog post here as well as a more detailed research summary here.

By a quite pleasant surprise, the vertical layout of Side Tabs surfaced a solution to me. I found myself appropriating my tab list into a priority-stack , always giving my focus to the tab at the bottom of the list. When I open something I want to keep around, I simply drag it in the list to a spot based on its relative importance; right to the top for ‘Someday’ items, 2nd or 3rd from the bottom if I want to take a peek once I’m done my task at hand (which is always the bottom tab). I’ve even moved to having two Firefox windows open, which essentially gives me two separate task lists: one for personal tabs/to-dos and one for work.


So where does this leave us? Quite clearly, it’s shown the immediate value of investing in an interactive prototype versus using only static mockups: people can use the design, see how it works, and in this case, expose a usage pattern I hadn’t seen before. The most common argument against prototyping is the cost involved (time, chiefly), and in my experience the value of building your designs (to varying levels of fidelity, based on the project/hypothesis) always outweighs the cost. Building the design sheds light on design problems and solutions that traditional, static mockups often fail to illuminate.

With regards to Side Tabs itself, I learned that in some cases, users treat their tabs as tasks to accomplish, and when a task is completed, it’s tab is closed. Increasingly so, our work and personal tasks exist online (email, banking, shopping, etc.), and are accessed through the browser. Some tasks (tabs) have higher priority or urgency than others, and whether visible or not, there is an implicit order by which a user will attend to their tabs. Helping users better organize their tabs made using the browser a more productive, delightful experience. And anything that can make an experience more delightful or useful is not only of great value and importance to the product or team I work with, but also to me as a designer.

Get the Add-on Side Tabs on Github

Side Tabs was built in Javascript, CSS and HTML. Knowing how to code, prototype and build the designs I create has been the advantage that has allowed me to excel as a UX designer.

For updates and access to my best content, blog posts and tutorials about designing with code, join my mailing list below!


No spam, unsubscribe whenever.

Categorieën: Mozilla-nl planet

Christian Heilmann: Maker Party 2014 – go and show off the web to the next makers

Mozilla planet - ti, 15/07/2014 - 17:56

Today is the start of this year’s Maker Party campaign. What’s that? Check out this video.


Maker Party is Mozilla’s annual campaign to teach the culture, mechanics and citizenship of the web through thousands of community-run events around the world from July 15-September 15, 2014.

This week, Maker Party events in places like Uganda, Taiwan, San Francisco and Mauritius mark the start of tens of thousands of educators, organizations and enthusiastic web users just like you getting together to teach and learn the web.

You can join Maker Party by finding an event in your area and learning more about how the web works in a fun, hands-on way with others. Events are open to everyone regardless of skill level, and almost all are free! Oh, and there will be kickoff events in all the Mozspaces this Thursday—join in!

No events in your area? Why not host one of your own? Maker Party Resources provides all the information you need to successfully throw an event of any size, from 50+ participants in a library or hackerspace to just you and your little sister sitting on the living room sofa.

Go teach the web, believe me, it is fun!

Categorieën: Mozilla-nl planet

We don't need new image formats: Mozilla works to build a better JPEG - Ars Technica

Nieuws verzameld via Google - ti, 15/07/2014 - 17:40

We don't need new image formats: Mozilla works to build a better JPEG
Ars Technica
Google has been promoting the use of WebP, the still image derivative of its WebM video codec. Mozilla has also been looking at the issue, but the open source browser organization has come up with a different conclusion: we don't need a new image ...

Categorieën: Mozilla-nl planet

Improving JPEG Image Encoding

Mozilla Blog - ti, 15/07/2014 - 17:32

Editor’s Note: Andreas Gal, Mozilla CTO, posted on his blog about Mozilla and the recent release of mozjpeg 2.0 and Facebook’s support for the JPEG encoder. This is reposted below:

Images are a big proportion of the data that browsers load when displaying a website, so better image compression goes a long way towards displaying content faster. Over the last few years there has been debate on whether a new image format is needed over the ubiquitous JPEG to provide better image data compression.

We published a study last year which compares JPEG with a number of more recent image formats, including WebP. Since then, we have expanded and updated that study. We did not find that WebP or any other royalty-free format we tested offers sufficient improvements over JPEG to justify the high maintenance cost of adding a new image format to the Web.

As an alternative we recently started an effort to improve the state of the art of JPEG encoders. Our research team released version 2.0 of this enhanced JPEG encoder, mozjpeg today. mozjpeg reduces the size of both baseline and progressive JPEGs by 5% on average, with many images showing significantly larger reductions.

Facebook announced today that they are testing mozjpeg 2.0 to improve the compression of images on It has also donated $60,000 to contribute to the ongoing development of the technology, including the next iteration, mozjpeg 3.0.

“Facebook supports the work Mozilla has done in building a JPEG encoder that can create smaller JPEGs without compromising the visual quality of photos,” said Stacy Kerkela, software engineering manager at Facebook. “We look forward to seeing the potential benefits mozjpeg 2.0 might bring in optimizing images and creating an improved experience for people to share and connect on Facebook.”

mozjpeg improves image encoding while maintaining full backwards compatibility with existing JPEG decoders. This is very significant because any browser can immediately benefit from these improvements without having to adopt new image formats, such as WebP.

The JPEG format continues to evolve along with the Web, and mozjpeg 2.0 will make it easier than ever for users to enjoy those images. Check out the Mozilla Research blog post for all the details.

Andreas Gal
Mozilla CTO

Categorieën: Mozilla-nl planet