mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Stormy Peters: 7 reasons asynchronous communication is better than synchronous communication in open source

Mozilla planet - ti, 27/01/2015 - 00:45

Traditionally, open source software has relied primarily on asynchronous communication. While there are probably quite a few synchronous conversations on irc, most project discussions and decisions will happen on asynchronous channels like mailing lists, bug tracking tools and blogs.

I think there’s another reason for this. Synchronous communication is difficult for an open source project. For any project where people are distributed. Synchronous conversations are:

  • Inconvenient. It’s hard to schedule synchronous meetings across time zones. Just try to pick a good time for Australia, Europe and California.
  • Logistically difficult. It’s hard to schedule a meeting for people that are working on a project at odd hours that might vary every day depending on when they can fit in their hobby or volunteer job.
  • Slower. If you have more than 2-3 people you need to get together every time you make a decision, things will move slower. I currently have a project right now that we are kicking off and the team wants to do everything in meetings. We had a several meeting last week and one this week. Asynchronously we could have had several rounds of discussion by now.
  • Expensive for many people. When I first started at GNOME, it was hard to get some of our board members on a phone call. They couldn’t call international numbers, or couldn’t afford an international call and they didn’t have enough bandwidth for an internet voice call. We ended up using a conference call line from one of our sponsor companies. Now it’s video.
  • Logistically difficult. Mozilla does most of our meetings as video meetings. Video is still really hard for many people. Even with my pretty expensive, supposedly high end internet in a developed country, I often have bandwidth problems when participating in video calls. Now imagine I’m a volunteer from Nigeria. My electricity might not work all the time, much less my high speed internet.
  • Language. Open source software projects work primarily in English and most of the world does not speak English as their first language. Asynchronous communication gives them a chance to compose their messages, look up words and communicate more effectively.
  • Confusing. Discussions and decisions are often made by a subset of the project and unless the team members are very diligent the decisions and rationale are often not communicated out broadly or effectively. You lose the history behind decisions that way too.

There are some major benefits to synchronous conversation:

  • Relationships. You build relationships faster. It’s much easier to get to know the person.
  • Understanding. Questions and answers happen much faster, especially if the question is hard to formulate or understand. You can quickly go back and forth and get clarity on both sides. They are also really good for difficult topics that might be easily misinterpreted or misunderstood over email where you don’t have tone and body language to help convey the message.
  • Quicker. If you only have 2-3 people, it’s faster to talk to them then to type it all out. Once you have more than 2-3, you lose that advantage.

I think as new technologies, both synchronous and asynchronous become main stream, open source software projects will have to figure out how to incorporate them. For example, at Mozilla, we’ve been working on how video can be a part of our projects. Unfortunately, they usually just add more synchronous conversations that are hard to share widely but we work on taking notes, sending notes to mailing lists and recording meetings to try to get the relationship and communication benefits of video meetings while maintaining good open source software project practices. I personally would like to see us use more asynchronous tools as I think video and synchronous tools benefit full time employees at the expense of volunteer involvement.

How does your open source software project use asynchronous and synchronous communication tools? How’s the balance working for you?

Related posts:

  1. Humanitarian projects bring more students to open source software
  2. Open source enables companies to collaborate
  3. 10 free apps I wish were open source

Categorieën: Mozilla-nl planet

Darrin Henein: Rapid Prototyping with Gulp, Framer.js and Sketch: Part One

Mozilla planet - mo, 26/01/2015 - 23:09

process

Rationale

The process of design is often thought of as being entirely generative–people who design things study a particular problem, pull out their sketchbooks, markers and laptops, and produce artifacts which slowly but surely progress towards some end result which then becomes “The Design” of “The Thing”. It is seen as an additive process, whereby each step builds upon the previous, sometimes with changes or modifications which solve issues brought to light by the earlier work.

Early in my career, I would sit at my desk and look with disdain at all the crumpled-paper that filled my trash bin and cherish that one special solution that made the cut. The bin was filled with all of my “bad ideas”. It was overflowing with “failed” attempts before I finally “got it right”. It took me some time, but I’ve slowly learned that the core of my design work is defined not by that shiny mockup or design spec I deliver, but more truly by the myriad of sketches and ideas that got me there. If your waste bin isn’t full by the end of a project, you may want to ask yourself if you’ve spent enough time exploring the solution space.

I really love how Facebook’s Product Design Director Julie Zhuo put it in her essay “Junior Designers vs. Senior Designers”, where she illustrates (in a very non-scientific, but effective way) the difference in process that experience begets. The key delta to me is the singularity of the Junior Designer’s process, compared to the exploratory, branching, subtractive process of the more seasoned designer. Note all the dead ends and occasions where the senior designer just abandons an idea or concept. They clearly have a full trash bin by the end of this journey. Through the process of evaluation and subtraction, a final result is reached. The breadth of ideas explored and abandoned is what defines the process, rather than the evolution of a single idea. It is important to achieve this breadth of ideation to ensure that the solution you commit to was not just a lucky one, but a solution that was vetted against a variety of alternatives.

The unfortunate part of this realization is that often it is just that – an idealized process which faces little conceptual opposition but (in my experience) is often sacrificed in the name of speed or deadlines. Generating multiple sketches is not a huge cost, and is one of the primary reasons so much exploration should take place at that fidelity. Interactions, behavioural design and animations, however, are much more costly to generate, and so the temptation there is to iterate on an idea until it feels right. While this is not inherently a bad thing, wouldn’t it be nice if we could iterate and explore things like animations with the same efficiency we experience with sketching?

As a designer with the ability to write some code, my first goal with any project is to eliminate any inefficiencies – let me focus on the design and not waste time elsewhere. I’m going to walk through a framework I’ve developed during a recent project, but the principle is universal – eliminate or automate the things you can, and maximize the time you spend actually problem-solving and designing.

Designing an Animation Using Framer.js and Sketch Get the Boilerplate Project on Github

User experience design has become a much more complex field as hardware and software have evolved to allow increasingly fluid, animated, and dynamic interfaces. When designing native applications (especially on mobile platforms such as Android or iOS) there is both an expectation and great value to leverage animation in our UI. Whether to bring attention to an element, educate the user about the hierarchy of the screens in an app, or just to add a moment of delight, animation can be a powerful tool when used correctly. As designers, we must now look beyond Photoshop and static PNG files to define our products, and leverage tools like Keynote or HTML to articulate how these interfaces should behave.

While I prefer to build tools and workflows with open-source software, it seems that the best design tools available are paid applications. Thankfully, Sketch is a fantastic application and easily worth it’s price.

My current tool of choice is a library called framer.js, which is an open-source framework for prototyping UI. For visual design I use Sketch. I’m going to show you how I combine these two tools to provide me with a fast, automated, and iterative process for designing animations.

I am also aware that Framer Studio exists, as well as Framer Generator. These are both amazing tools. However, I am looking for something as automated and low-friction as possible; both of these tools require some steps between modifying the design and seeing the results. Lets look at how I achieved a fully automated solution to this problem.

Automating Everything With Gulp

Here is the goal: let me work in my Sketch and/or CoffeeScript file, and just by saving, update my animated prototype with the new code and images without me having to do anything. Lofty, I know, but let’s see how it’s done.

Gulp is a Javascript-based build tool, the latest in a series of incredible node-powered command line build tools.

Some familiarity with build tools such as Gulp or Grunt will help here, but is not mandatory. Also, this will explain the mechanics of the tool, but you can still use this framework without understanding every line!

 The gulpfile is  just a list of tasks, or commands, that we can run in different orders or timings. Let’s breakdown my gulpfile.js:

var gulp = require('gulp'); var coffee = require('gulp-coffee'); var gutil = require('gulp-util'); var watch = require('gulp-watch'); var sketch = require('gulp-sketch'); var browserSync = require('browser-sync');

This section at the top just requires (imports) the external libraries I’m going to use. These include Gulp itself, CoffeeScript support (which for me is faster than writing Javascript), a watch utility to run code whenever a file changes, and a plugin which lets me parse and export from Sketch files.

gulp.task('build', ['copy', 'coffee', 'sketch']); gulp.task('default', ['build', 'watch']);

Next, I setup the tasks I’d like to be able to run. Notice that the build and default tasks are just sets of other tasks. This lets me maintain a separation of concern and have tasks that do only one thing.

gulp.task('watch', function(){ gulp.watch('./src/*.coffee', ['coffee']); gulp.watch('./src/*.sketch', ['sketch']); browserSync({ server: { baseDir: 'build' }, browser: 'google chrome', injectChanges: false, files: ['build/**/*.*'], notify: false }); });

This is the watch task. I tell Gulp to watch my src folder for CoffeeScript files and Sketch files; these are the only source files that define my prototype and will be the ones I change often. When a CoffeeScript or Sketch file changes, the coffee or sketch tasks are run, respectively.

Next, I set up browserSync to push any changed files within the build directory to my browser, which in this case is Chrome. This keeps my prototype in the browser up-to-date without having to hit refresh. Notice I’m also specifying a server: key, which essentially spins up a web server with the files in my build directory.

gulp.task('coffee', function(){ gulp.src('src/*.coffee') .pipe(coffee({bare: true}).on('error', gutil.log)) .pipe(gulp.dest('build/')) });

The second major task is coffee. This, as you may have guessed, simply transcompiles any *.coffee files in my src folder to Javascript, and places the resulting JS file in my build folder. Because we are containing our prototype in one app.coffee file, there is no need for concatenation or minification.

gulp.task('sketch', function(){ gulp.src('src/*.sketch') .pipe(sketch({ export: 'slices', format: 'png', saveForWeb: true, scales: 1.0, trimmed: false })) .pipe(gulp.dest('build/images')) });

The sketch task is also aptly named, as it is responsible for exporting the slices I have defined in my Sketch file to pngs, which can then be used in the prototype. In Sketch, you can mark a layer or group as “exportable”, and this task only looks for those assets.

gulp.task('copy', function(){ gulp.src('src/index.html') .pipe(gulp.dest('build')) gulp.src('src/lib/**/*.*') .pipe(gulp.dest('build/lib')) gulp.src('src/images/**/*.{png, jpg, svg}') .pipe(gulp.dest('build/images')); });

The last task is simply housekeeping. It is only run once, when you first start the Gulp process on the command line. It copies any HTML files, JS libraries, or other images I want available to my prototype. This let’s me keep everything in my src folder, which is a best practice. As a general rule of thumb for build systems, avoid placing anything in your output directory (in this case, build), as you jeopardize your ability to have repeatable builds.

Recall my default task was defined above, as:

gulp.task('default', ['build', 'watch']);

This means that by running $ gulp in this directory from the command line, my default task is kicked off. It won’t exit without ctrl-C, as watch will run indefinitely. This lets me run this command only once, and get to work.

$ gulp

So where are we now? If everything worked, you should see your prototype available at http://localhost:3000. Saving either app.coffee or app.sketch should trigger the watch we setup, and compile the appropriate assets to our build directory. This change of files in the build directory should trigger BrowserSync, which will then update our prototype in the browser. Voila! We can now work in either of 2 files (app.coffee or app.sketch), and just by saving them have our shareable, web-based prototype updated in place. And the best part is, I only had to set this up once! I can now use this framework with mynext project and immediately begin designing, with a hyper-fast iteration loop to facilitate that work.

The next step is to actually design the animation using Sketch and framer.js, which deserves it’s own post altogether and will be covered in Part Two of this series.

Follow me on twitter @darrinhenein to be notified when part two is available.

Categorieën: Mozilla-nl planet

Adam Okoye: Tests, Feedback Results, and a New Thank You

Mozilla planet - mo, 26/01/2015 - 20:14

As I’ve said in previous posts, my internship primarily revolves around creating a new “thank you” page that will be shown to people who leave negative (or “sad”) feedback on input.mozilla.org.

The current thank you page which the user gets directed to after giving any type of feedback, good or bad, looks like this:

current thank you page

As you can see it’s pretty basic. It does include a link to Support Mozilla (SUMO), which I think is very useful. It also has links a page that shows you how to download different builds of Firefox (beta, nightly, etc), a page with a lot of useful information on how to get involved with contributing to Mozilla, and links to Mozilla’s social networking profiles. While the links are interesting in their own right, they don’t do a lot in terms of quickly guiding someone a solution if they’re having a problem with Firefox. We want to change that in order to hopefully make the page more useful to people who are having trouble using Firefox. The new thank you page will end up being a different Django template that people will be redirected to.

Part of making the new page more useful will be including links to SUMO articles that are related to the feedback that people have given. Last week I wrote the code that redirects a specific segment of people to the new thank you page as well as a test for that code. The new thank you page will be rolled out via a Waffle flag which I made some weeks ago which made writing the test a tad more complex. Right now there are a few finishing touches that needed to be added to the test in order to close out the bug, but I’m hoping to finish those by the end of Tuesday, the 27th.

We’ll be using one of the three SUMO API endpoints to take the text from the feedback, search the knowledge base, and questions and return results. To figure out which endpoint to use I used a script that Will Kahn-Greene wrote to look at feedback taken from Input and results returned via SUMO’s endpoints and then rank which endpoint’s results were the best. I did that for 120 pieces of feedback.

Tomorrow I’m going to start sketching and mocking up the new thank you page which I’m really looking forward to. I’ll be using a white board for the sketching which will be a first for me I’m hoping that it’ll be easier for me than pencils/pen and paper. I’ll also be able to quickly and easily upload all of the pictures I take of the whiteboard to the my computer which I think will be useful.

Categorieën: Mozilla-nl planet

Mark Surman: Mozilla Participation Plan (draft)

Mozilla planet - mo, 26/01/2015 - 20:02

Mozilla needs a more creative and radical approach to participation in order to succeed. That is clear. And, I think, pretty widely agreed upon across Mozilla at this stage. What’s less clear: what practical steps do we take to supercharge participation at Mozilla? And what does this more creative and radical approach to participation look like in the everyday work and lives of people involved Mozilla?

Mozilla and participation

This post outlines what we’ve done to begin answering these questions and, importantly, it’s a call to action for your involvement. So read on.

Over the past two months, we’ve written a first draft Mozilla Participation Plan. This plan is focused on increasing the impact of participation efforts already underway across Mozilla and on building new methods for involving people in Mozilla’s mission. It also calls for the creation of new infrastructure and ways of working that will help Mozilla scale its participation efforts. Importantly, this plan is meant to amplify, accelerate and complement the many great community-driven initiatives that already exist at Mozilla (e.g. SuMo, MDN, Webmaker, community marketing, etc.) — it’s not a replacement for any of these efforts.

At the core of the plan is the assumption that we need to build a virtuous circle between 1) participation that helps our products and programs succeed and 2) people getting value from participating in Mozilla. Something like this:

Virtuous circle of participation

This is a key point for me: we have to simultaneously pay attention to the value participation brings to our core work and to the value that participating provides to our community. Over the last couple of years, many of our efforts have looked at just one side or the other of this circle. We can only succeed if we’re constantly looking in both directions.

With this in mind, the first steps we will take in 2015 include: 1) investing in the ReMo platform and the success of our regional communities and 2) better connecting our volunteer communities to the goals and needs of product teams. At the same time, we will: 3) start a Task Force, with broad involvement from the community, to identify and test new approaches to participation for Mozilla.

Participation Plan

The belief is that these activities will inject the energy needed to strengthen the virtuous circle reasonably quickly. We’ll know we’re succeeding if a) participation activities are helping teams across Mozilla measurably advance product and program goals and b) volunteers are getting more value out of their participation out of Mozilla. These are key metrics we’re looking at for 2015.

Over the longer run, there are bigger ambitions: an approach to participation that is at once massive and diverse, local and global. There will be many more people working effectively and creatively on Mozilla activities than we can imagine today, without the need for centralized control. This will result in a different and better, more diverse and resilient Mozilla — an organization that can consistently have massive positive impact on the web and on people’s lives over the long haul.

Making this happen means involvement and creativity from people across Mozilla and our community. However, a core team is needed to drive this work. In order to get things rolling, we are creating a small set of dedicated Participation Teams:

  1. A newly formed Community Development Team that will focus on strengthening ReMo and tying regional communities into the work of product and program groups.
  2. A participation ‘task force’ that will drive a broad conversation and set of experiments on what new approaches could look like.
  3. And, eventually, a Participation Systems Team will build out new infrastructure and business processes that support these new approaches across the organization.

For the time being, these teams will report to Mitchell and me. We will likely create an executive level position later in the year to lead these teams.

As you’ll see in the plan itself, we’re taking very practical and action oriented steps, while also focusing on and experimenting with longer-term questions. The Community Development Team is working on initiatives that are concrete and can have impact soon. But overall we’re just at the beginning of figuring out ‘radical participation’.

This means there is still a great deal of scope for you to get involved — the plans  are still evolving and your insights will improve our process and the plan. We’ll come out with information soon on more structured ways to engage with what we’re calling the ‘task force’. In the meantime, we strongly encourage your ideas right away on ways the participation teams could be working with products and programs. Just comment here on this post or reach out to Mitchell or me.

PS. I promised a follow up on my What is radical participation? post, drawing on comments people made. This is not that. Follow up post on that topic still coming.


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

Air Mozilla: Mozilla Weekly Project Meeting

Mozilla planet - mo, 26/01/2015 - 20:00

Mozilla Weekly Project Meeting The Monday Project Meeting

Categorieën: Mozilla-nl planet

Mozilla Reps Community: Rep of the month: January 2015

Mozilla planet - mo, 26/01/2015 - 19:22

Irvin Chen has been an inspiring contributor last month and we want to recognize his great work as a Rep.

irvinIrvin has been organizing weekly MozTW Lab and also other events to spread Mozilla in the local community space in Taiwan, such as Spark meetup, d3.js meetup or Wikimedia mozcafe.

He also helped to run an l10n sprint for video subtitle/Mozilla links/SUMO and webmaker on transifex.

Congratulations Irvin for your awesome work!

Don’t forget to congratulate him on Discourse!

Categorieën: Mozilla-nl planet

Ben Kero: Attempts source large E-Ink screens for a laptop-like device

Mozilla planet - mo, 26/01/2015 - 19:11

One idea that’s been bouncing around in my head for the last few years has been a laptop with an E-Ink display. I would have thought this would be a niche that had been carved out already, but it doesn’t seem that any companies are interested in exploring it.

I use my laptop in some non-traditional environments, such as outdoors in direct sunlight. Almost all laptops are abysmal in a scenario like this. E-Ink screens are a natural response to this requirement. Unlike traditional TFT-LCD screens, E-Ink panels are meant to be viewed with an abundance of natural light. As a human, I too enjoy natural light.

Besides my fantasies of hacking on the beach, these would be very useful to combat the raster burn that seems to be so common among regular computer users. Since TFT-LCDs act as an artificial sunlight, they can have very negative side-effects on the eyes, and indirectly on the brain. Since E-Ink screens work without a backlight they are not susceptible to these problems. This has the potential to help me reclaim some of the time that I spend without a device before bedtime for health reasons.

The limitations of E-Ink panels are well known to anybody who has used one. The refresh rate is not nearly as good, the color saturation varies between abysmal to non-existent, and the available size are much more limited than LCD panels (smaller). Despite all these reasons, the panels do have advantages. They do not give the user raster burn like other backlit panels. They are cheap, standardized, and easy to replace. They are also useable in direct sunlight. Until recently they offered competitive DPI compared to laptop panels as well.

As a computer professional many of these downsides of LCD panels concern me. I spend a large amount of my work day staring at the displays. I fear this will have a lasting effect on me and many others who do the same.

The E-Ink manufacturer offerings are surprisingly sparse, with no devices that I can find targeted towards consumers or hobbyists. Traditional LCDs are available over a USB interface, able to be used as external displays on any embedded or workstation system. Interfaces for E-Ink displays are decidedly less advanced. The panels that Amazon sources use an undocumented DTO protocol/connector. The panels that everybody else seems to use also have a specific protocol/connector, but some controllers are available.

The one panel I’ve been able to source to try to integrate into a laptop-like object is PervasiveDisplay’s 9.7″ panel with SPI controller. This would allow a computer to speak SPI to the controller board, which would then translate the calls into operations to manage drawing to the panel. Although this is useful, availability is limited to a few component wholesale sites and Digikey. Likewise it’s not exactly cheap. Although the SPI controller board is only $28, the set of controller and 9.7″ panel is $310. Similar replacement Kindle DX panels cost around $85 elsewhere on the internet.

It would be cheaper to buy an entire Kindle DX, scrap the computer and salvage the panel than to buy the PervasiveDisplays evaluation kit on Digikey. To be fair this is comparing a used consumer device to a niche evaluation kit, so of course the former device is going to be cheaper.

To their credit, they’re also trying to be active in the Open Hardware community. They’ve launched RePaper.org, which is a site advocating freeing ePaper technology from the hands of the few companies and into the hands of open hardware enthusiasts and low-run product manufacturers.

From their site:

We recognize ePaper is a new technology and we’re asking your help in making it better known. Up till now, all industry players have kept the core technologies closed. We want to change this. If the history of the Internet has proven anything, it is that open technologies lead to unbounded innovation and unprecedented value added to the entire economy.

There are some panels listed up on SparkFun and Adafruit, although those are limited to 1.44 inch to 2.0 inch displays, which are useless for my use case. Likewise, these are geared towards Arduino compatibility, while I need something that is performant through a (relatively) fast and high bandwidth interface like exists on my laptop mainboard.

Bunnie/Xobs of the Kosagi Novena open laptop project clued me in to the fact that the iMX6 SoC present in the aforementioned device contains an EPD (Electronic Paper Display) controller. Although the pins on the chip likely aren’t broken out to the board, it gives me hope. My hope is that in the future devices such as the Raspberry Pi, CubieBoard, or other single-board computers will break out the controller to a header on the main board.

I think that making this literal stockpile of panels available to open hardware enthusiasts, we can empower them to create anything from innovations in the eBook reader market to creating an entirely new class of device.

Categorieën: Mozilla-nl planet

Mozilla busca llevar la realidad virtual a Firefox - InfoBAE.com

Nieuws verzameld via Google - mo, 26/01/2015 - 18:34

Mozilla busca llevar la realidad virtual a Firefox
InfoBAE.com
Mientras Facebook ya adquirió Oculus VR y Microsoft se prepara para HoloLens, Mozilla (de Firefox) se suma al mundo de la realidad virtual, por lo que incorpora ahora a sus ediciones en desarrollo continuo (Nightly) y para desarrolladores (Developer ...

en meer »
Categorieën: Mozilla-nl planet

Adam Lofting: The week ahead: 26 Jan 2015

Mozilla planet - mo, 26/01/2015 - 17:09

unrelatedphoto

I should have started the week by writing this, but I’ll do it quickly now anyway.

My current todo list.
List status: Pretty good. Mostly organized near the top. Less so further down. Fine for now.

Objectives to call out for this week.

  • Bugzilla and Github clean-out / triage
  • Move my home office out to the shed (depending on a few things)

+ some things that carry over from last week

  • Write a daily working process
  • Work out a plan for aligning metrics work with dev team heartbeats
  • Don’t let the immediate todo list get in the way of planning long term processes
  • Invest time in working open
  • Wrestle with multiple todo list systems until they (or I) work together nicely
Categorieën: Mozilla-nl planet

Software-update: Mozilla Firefox 35.0.1 - Tweakers

Nieuws verzameld via Google - mo, 26/01/2015 - 16:48

Tweakers

Software-update: Mozilla Firefox 35.0.1
Tweakers
Mozilla Firefox 2013 logo (75 pix) Mozilla heeft een update voor versie 35 van zijn webbrowser Firefox uitgebracht. In versie 35 zijn onder meer verbeteringen aan de chat-client Firefox Hello aangebracht, heeft de OS X-versie nu ingebakken ...

Categorieën: Mozilla-nl planet

Mozilla veröffentlicht Firefox 35.0.1 und korrigiert Fehler - soeren-hentzschel.at

Nieuws verzameld via Google - mo, 26/01/2015 - 16:44

Mozilla veröffentlicht Firefox 35.0.1 und korrigiert Fehler
soeren-hentzschel.at
Mit dem Update auf Firefox 35.0.1 bessert Mozilla an mehreren Stellen aus. Die neue Version beinhaltet einen spekulativen Bugfix für eine mögliche Absturzursache bei Programmsart, behebt außerdem einen durch die Erweiterung Enhanced Steam ...

Google Nieuws
Categorieën: Mozilla-nl planet

Mozilla Fundraising: Should we put payment provider options directly on the snippet?

Mozilla planet - mo, 26/01/2015 - 14:57
While our End of Year (EOY) fundraising campaign is finished, we still have a few updates to share with you. This post documents one of the A/B tests we ran during the campaign. Should we put payment provider options directly … Continue reading
Categorieën: Mozilla-nl planet

Como desinstalar o Mozilla Firefox completamente do computador - Globo.com

Nieuws verzameld via Google - mo, 26/01/2015 - 13:22

Globo.com

Como desinstalar o Mozilla Firefox completamente do computador
Globo.com
Desinstalar o Firefox não remove todos os arquivos do navegador. Isso significa que, caso você esteja enfrentando algum problema, nem sempre a reinstalação resolve. O arquivo defeituoso pode continuar no computador e voltar a causar instabilidades no ...
Mozilla arrelia GoogleGazeta do Rossio
Google quer que utilizadores do Firefox deixem a pesquisa YahooPplware
Google quer atrair usuários do FirefoxKioskea

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

Mozilla aims to bring VR to the web - VR-Zone

Nieuws verzameld via Google - mo, 26/01/2015 - 13:06

VR-Zone

Mozilla aims to bring VR to the web
VR-Zone
Mozilla's Josh Carpented explained in a talk last summer that virtual reality is becoming a big deal also presents a great challange, and those are reasons enough to invest time developing virtual reality support. He stated that the challenge of making ...

Categorieën: Mozilla-nl planet

Firefox: Mozilla integriert Oculus-Rift-Unterstützung mit Web VR - PC Games Hardware

Nieuws verzameld via Google - mo, 26/01/2015 - 11:46

PC Games Hardware

Firefox: Mozilla integriert Oculus-Rift-Unterstützung mit Web VR
PC Games Hardware
Mozilla hat die Unterstützung der Oculus Rift in die neueste Version des Firefox Nightly Build eingebraut. Damit kann die Virtual-Reality-Brille von Oculus VR auch mit Webanwendungen genutzt werden, sofern diese denn die Kombination unterstützen.

Categorieën: Mozilla-nl planet

Mozilla, WebVR ile sanal gerçekliği tarayıcınıza getiriyor - Webrazzi

Nieuws verzameld via Google - mo, 26/01/2015 - 08:40

Webrazzi

Mozilla, WebVR ile sanal gerçekliği tarayıcınıza getiriyor
Webrazzi
Üstelik artık web tarayıcılar üzerinden hayatımızı değiştirmek üzere ve Mozilla bu konuda atağa kalkıyor. Geçen yaz web tabanlı sanal gerçeklik (WebVR) uygulamalarının geliştirilmesi için Chrome ve Mozilla ilk tanıtımlarını yapmıştı. Mozilla, Mozvr.com ...
Mozilla 'dan Sanal Gerçekliği Destekleyen Tarayıcı Geliyor!Silikon Vadisi TV

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

Mozilla na oči - Budoucnost prohlížení internetu se ukrývá ve virtuální realitě - CDR.cz

Nieuws verzameld via Google - mo, 26/01/2015 - 08:13

Mozilla na oči - Budoucnost prohlížení internetu se ukrývá ve virtuální realitě
CDR.cz
Sedíte v pohodlí domova, otáčíte hlavou, ale co se ve skutečnosti děje kolem vás netušíte. Procházíte se totiž po tajemných zákoutích virtuálního světa. Mozilla se nyní rozhodla prohlížení webu posunout na novou úroveň. Budeme se jím doslova procházet!

Categorieën: Mozilla-nl planet

Mozilla brings virtual reality app support to Firefox's Nightly versions - Firstpost

Nieuws verzameld via Google - mo, 26/01/2015 - 07:03

Firstpost

Mozilla brings virtual reality app support to Firefox's Nightly versions
Firstpost
Last year Mozilla had released a limited version of Firefox which could support web-based virtual reality apps which could be experienced through the Oculus Rift. Mozilla is now bringing this experience on the web albeit only on the Nightly or ...

Categorieën: Mozilla-nl planet

Nick Desaulniers: Writing my first technical book chapter

Mozilla planet - mo, 26/01/2015 - 05:50

It’s a feeling of immense satisfaction when we complete a major achievement. Being able to say “it’s done” is such a great stress relief. Recently, I completed work on my first publication, a chapter about Emscripten for the upcoming book WebGL Insights to be published by CRC Press in time for SIGGRAPH 2015.

One of the life goals I’ve had for a while is writing a book. A romantic idea it seems to have your ideas transcribed to a medium that will outlast your bones. It’s enamoring to hold books from long dead authors, and see that their ideas are still valid and powerful. Being able to write a book, in my eyes, provides some form of life after death. Though, one could imagine ancestors reading blog posts from long dead relatives via utilities like the Internet Archive’s WayBack Machine.

Writing about highly technical content places an upper limit on the usefulness of the content, and shows as “dated” quickly. A book I recently ordered was Scott Meyers’ Effective Modern C++. This title strikes me, because what exactly do we consider modern or contemporary? Those adjectives only make sense in a time limited context. When C++ undergoes another revolution, Scott’s book may become irrelevant, at which point the adjective modern becomes incorrect. Not that I think Scott’s book or my own is time-limited in usefulness; more that technical books’ duration of usefulness is significantly less than philosophical works like 1984 or Brave New World. Almost like having a record in a sport is a feather in one’s cap, until the next best thing comes along and you’re forgotten to time.

Somewhat short of my goal of writing an entire book, I only wrote a single chapter for a book. It’s interesting to see that a lot of graphics programming books seem to follow the format of one author per chapter or at least multiple authors. Such book series as GPU Gems, Shader X, and GPU Pro follow this pattern, which is interesting. After seeing how much work goes into one chapter, I think I’m content with not writing an entire book, though I may revisit that decision later in life.

How did this all get started? I had followed Graham Sellers on Twitter and saw a tweet from him about a call to authors for WebGL Insights. Explicitly in the linked to page under the call for authors was interest in proposals about Emscripten and asm.js.

Want to contribute to a book? @pjcozzi is calling for authors for the new #WebGL Insights. Go here: http://t.co/n7wrXVb4Vl.

— Graham Sellers (@grahamsellers) August 28, 2014

At the time, I was headlong into a project helping Disney port Where’s My Water from C++ to JavaScript using Emscripten. I was intimately familiar with Emscripten, having been trained by one of its most prolific contributors, Jukka Jylänki. Also, Emscripten’s creator, Alon Zakai, sat on the other side of the office from me, so I was constantly pestering him about how to do different things with Emscripten. The #emscripten irc channel on irc.mozilla.org is very active, but there’s no substitute for being able to have a second pair of eyes look over your shoulder when something is going wrong.

Knowing Emscripten’s strengths and limitations, seeing interest in the subject I knew a bit about (but wouldn’t consider myself an expert in), and having the goal of writing something to be published in book form, this was my opportunity to seize.

I wrote up a quick proposal with a few figures about why Emscripten was important and how it worked, and sent it off with fingers crossed. Initially, I was overjoyed to learn when my proposal was accepted, but then there was a slow realization that I had a lot of work to do. The editor, Patrick Cozzi, set up a GitHub repo for our additional code and figures, a mailing list, and sent us a chapter template document detailing the process. We had 6 weeks to write the rough draft, then 6 weeks to work with reviewers to get the chapter done. The chapter was written as a Google Doc, so that we could have explicit control over who we shared the document with, and what kinds of editing power they had over the document. I think this approach worked well.

I had most of the content written by week 2. This was surprising to me, because I’m a heavy procrastinator. The only issue was that the number of pages I wrote was double the allowed amount; way over page count. I was worried about the amount of content, but told myself to try not to be attached to the content, just as you shouldn’t stay attached with your code.

I took the additional 4 weeks I had left to finish the rough draft to invite some of my friends and coworkers to provide feedback. It’s useful to have a short list of people who have ever offered to help in this regard or owe you one. You’ll also want a diverse team of reviewers that are either close to the subject matter, or approaching it as new information. This allows you to stay technically correct, while not presuming your readers know everything that you do.

The strategy worked out well; some of the content I had initially written about how JavaScript VMs and JITs speculate types was straight up wrong. While it played nicely into the narrative I was weaving, someone more well versed in JavaScript virtual machines would be able to call BS on my work. The reviewers who weren’t as close to subject matter were able to point out when logical progressions did not follow.

Fear of being publicly corrected prevents a lot of people from blogging or contributing to open source. It’s important to not stay attached to your work, especially when you need to make cuts. When push came to shove, I did have difficulty removing sections.

Lets say you have three sequential sections: A, B, & C. If section A and section B both set up section C, and someone tells you section B has to go, it can be difficult to cut section B because as the author you may think it’s really important to include B for the lead into C. My recommendation is sum up the most important idea from section B and add it to the end of section A.

For the last six weeks, the editor, some invited third parties, and other authors reviewed my chapter. It was great that others even followed along and pointed out when I was making assumptions based on specific compiler or browser. Eric Haines even reviewed my chapter! That was definitely a highlight for me.

We used a Google Sheet to keep track of the state of reviews. Reviewers were able to comment on sections of the chapter. What was nice was that you were able to keep use the comment as a thread, being able to respond directly to a criticism. What didn’t work so well was then once you edited that line, the comment and thus the thread was lost.

Once everything was done, we zipped up the assets to be used as figures, submitted bios, and wrote a tips and tricks section. Now, it’s just a long waiting game until the book is published.

As far as dealing with the publisher, I didn’t have much interaction. Since the book was assembled by a dedicated editor, Patrick did most of the leg work. I only asked that what royalties I would receive be donated to Mozilla, which the publisher said would be too small (est $250) to be worth the paperwork. It would be against my advice if you were thinking of writing a technical book for the sole reason of monetary benefit. I’m excited to be receiving a hard cover copy of the book when it’s published. I’ll also have to see if I can find my way to SIGGRAPH this year; I’d love to meet my fellow authors in person and potential readers. Just seeing the list of authors was really a who’s-who of folks doing cool WebGL stuff.

If you’re interested in learning more about working with Emscripten, asm.js, and WebGL, I sugguest you pick up a copy of WebGL Insights in August when it’s published. A big thank you to my reviewers: Eric Haines, Havi Hoffman, Jukka Jylänki, Chris Mills, Traian Stanev, Luke Wagner, and Alon Zakai.

So that was a little bit about my first experience with authorship. I’d be happy to follow up with any further questions you might have for me. Let me know in the comments below, on Twitter, HN, or wherever and I’ll probably find it!

Categorieën: Mozilla-nl planet

Mozillaは、ブラウザーでVRをやりたがっている - TechCrunch

Nieuws verzameld via Google - snein, 25/01/2015 - 21:34

Mozillaは、ブラウザーでVRをやりたがっている
TechCrunch
昨年夏、MozillaはFirefoxの非常に実験的なバージョンを公開し、Oculus Riftを使ったウェブベースのバーチャルリアリティーアプリ(WebVR)をサポートした。今週、FirefoxのNighlyデベロッパー版でもWebVRがサポートされた。 ではなぜMozillaは、同社のミッションが「ウェブの ...

Categorieën: Mozilla-nl planet

Pages