The Google Summer of Code 2013 project is about to get started: today the application submission period officially starts (and is open until May 3). Mozilla is again a participating org, and students can find a list of project ideas and application advice in our Summer of Code wiki page. It’s important to remember that the list on the wiki is for possible ideas, but students are not limited to those on the list: project proposals with your own ideas are also welcome. With this disclaimer in mind, I’d like to describe in a bit more details some of the projects that we from the Firefox team have included on the list, and to answer some of the more frequent questions that we have received through e-mail and IRC about them. If you’re a student interested in one of those, read on. I wrote a blog post for each of them:

To make a good proposal, it’s important to keep in mind the goals and non-goals of the project, to demonstrate that you’ve understood how to approach the implementation of the project, and that you’re capable of doing so. It’s also important to create a solid schedule of deliverables that are used both to guide the steps of the project and to validate the pace and the progress up until that point. I’ve already written enough about the specifics and there’s a lot of content out there explaining what makes a good candidate and a good proposal, so i’ll keep this post brief.

Just as a last note, if you’ve sent us e-mail or pinged us on IRC, please be patient because we’re not online all the time or available to immediately reply, and so far we have seen a lot of interest in GSoC, so it takes us a while to reply to everyone’s emails. We hope that these blog posts will help more students to clarify some common questions about our proposals. Good luck to everyone, and remember that you’re always welcome to contribute to Mozilla, during the Summer of Code and every other season too :D

This entry is part of a series of posts about some of our proposed GSoC projects. See here the introduction blog post.

about:memory for real people

What is it: about:memory is a tool that is used by Firefox developers to diagnose and understand the memory usage behaviors of the browsers. It has been immensely useful for us to find bugs in the MemShrink project and validate the fixes to those bugs. However, it is too focused on Firefox’s internals for the browser developers, but the available data there could be presented in different ways to also help web developers and regular users who wants to understand how each website consumes memory.

Example use case: User opens the new about:memory and sees that website A (tab 1) is taking 15mb and website B (tab 2) is taking 12mb. After 30min, the user opens the tool again, now to see website A still taking 17mb and website B taking now 30mb. They then can conclude that website B is consuming more memory as time passes, while website A is able to maintain its memory requirements steady.

What does it involve:

  • looking into the current about:memory and understanding the existing data available and its breakdowns
  • proposing various different ways to visually present that data and interact with it (e.g., sorting, time slicing, merging tabs from the same domain, animating data over time, etc.)
  • proposing an existing open-source JS dataviz graphics library to be used for the project
  • interact with the Firefox developers who work on memory optimization and provide feedback for more data that would be useful if it were available
  • should be done as an add-on using the Add-on SDK

Non-goals: This project will not remove the existing about:memory, but will create a new one. Also, you should not try to create your own graphics library as part of the project, as there’s not enough time available to do both things during the official schedule.

Where to start: You should start by looking into the current about:memory and its code and to understand how data is retrieved from the memory measurements code. You then need to analyze the available data to undestand its meaning and start thinking on how you want to present that in a more visually interactive way. The usage of the Add-on SDK will also be required but will be very limited to packaging and setting up the add-on, as the main code will be a simple html page that implements your new about:memory (along with its supporting CSS and JS files).

Skills needed: JavaScript and CSS skills, and experience with data visualization. Experience with one JS graphics library would be great.

What is expected in your project proposal: A great understanding of the project, its goals and non-goals, and a good idea on how to approach each of the features involved and how to time slice them. A proposal for at least 4 different ways to visualize the data, describing what type of graphs will be used and the possible interactions that it will provide. The selection of the graphics library to be used. Links to open-source code (e.g. a github profile) that you have produced (specially ones involving data visualization).

Posted by: felipe | April 22, 2013

Summer of Code project – Silverfox

This entry is part of a series of posts about some of our proposed GSoC projects. See here the introduction blog post.

Silverfox

What is it: Silverfox is the codename of a feature that we would like to have in Firefox. This feature changes the browser configuration options to focus on beginner users, in an attempt to prevent these users from mis-configuring the browser by accident, either by accidentally clicking on things, changing settings without understanding them, or by being directed by websites to change prefs or to install add-ons.

Example use case: Tech-savvy family member configures a new computer for relatives, installs Firefox and sets appropriate settings and add-ons to their liking, and installs Silverfox after to prevent less tech-savvy family member from breaking their browser.

What does it involve:

  • changing the preferences window by hiding or disabling advanced or dangerous features, and displaying an explanation to the user on why those are disabled,
  • disallowing changes in about:config
  • preventing changes to the homepage url and preventing other add-ons to be installed
  • preventing toolbars from being hidden or broken through customization
  • provide an API for new features to be supported by Silverfox without the need for changes in Silverfox itself
  • should be done as an add-on using the Add-on SDK

Non-goals: It is important to understand that Silverfox is *not* a security feature, and it should not try to prevent itself from being disabled or uninstalled. Quite the opposite, it should educate users on why it’s activated and why changing prefs is problematic. It should not try to disable existing add-ons or resetting prefs that have already been changed. It should also not prevent Lightweight themes from being changed, or blocking add-ons from being updated.

Where to start: Your main first step will definitely be to learn how to use the Add-on SDK and to generate add-ons using it. After that, you should familiarize yourself with the preferences.xul file and the other files from the same folder referenced inside it, and understand the XUL structure there (using the DOM Inspector add-on will also help you a lot). You’ll also need to see the about:config file, and others that can be learned as the project advances.

Skills needed: Great JavaScript and good CSS skills. Also having created add-ons and worked with the add-ons SDK will be very helpful.

What is expected in your project proposal: A great understanding of the project, its goals and non-goals, and a good idea on how to approach each of the features involved and how to time slice them. A proposal for good and non-intrusive UI that will be displayed for users of Silverfox, and how to handle the main interactions that will be created (but do not spend most of your proposal describing UI instead of the technical aspects of the project). Links to open-source code (e.g. a github profile) and/or add-ons that you have produced.

Posted by: felipe | April 22, 2013

Summer of Code project – Fullscreen mode

This entry is part of a series of posts about some of our proposed GSoC projects. See here the introduction blog post.

Fullscreen mode

What is it: Many users express the desire to have a more immersive mode where screen space is a very important aspect to maximize. This mode would have all the browser fundamental controls in a single row at the top of the screen, leaving everything else for the webpage. This means that the Back button, the URL bar, the tab strip and the new tab button would all be in the same row, along with some other important information that is useful to have when a software is running in fullscreen mode (like a clock). We have had a preliminary mock-up for a while and it is the starting point for this project.

What does it involve:

  • A curved and clipped back button at the left corner of the screen
  • A sliding forward button that works just like the existing one
  • A button to access Firefox’s menu, based on Australis
  • The address bar should be a fixed width. The tabs should flex to fit the remaining space.
  • A clock and possibly other indicators such as wi-fi signal that can be obtained using the WebAPIs
  • Interaction with the UX team to evolve the mockup into the final design
  • The work to be done by the student during this project should be an implementation of this feature in one of our 3 desktop platforms (Windows, Mac or Linux)
  • The patches produced should get at least to the point of having review started on them, and should provide a good basis for the implementation on the other 2 platforms
  • Should be done as patches to the Firefox codebase

Non-goals: This project will not implement the curved tabs that is seen in the mockup, as that is part of the Australis project. It will also not involve producing the background page shown in the screenshot, of course.

Where to start: You should start by learning how to download Firefox’s source code and to successfully compile it in your platform, and also learning how to generate a patch using Mercurial. After that you should get used to the important source files related to this project: The structure of the browser window, some structural CSS used in all platforms, and the platform-specific ones (Win + Win, Mac, Linux). A tool that will be immensely useful is an add-on called DOM Inspector, which we urge you to download and explore the structure and CSS of the main Firefox window (specially when in Fullscreen mode). You should also look into the Firefox UX branch to see what the current state of Australis is.

Skills needed: Amazing CSS skills and an understanding of the new CSS flexbox model will be useful.

What is expected in your project proposal: A great understanding of the project, its goals and non-goals, and a good idea on how to approach each of the features involved and how to time slice them. Mentions of the main XUL elements of Firefox’s toolbars (during fullscreen mode) and how they are displayed the way they are with the existing CSS, and suggestions on how to put them all in the same row and style them towards the look and feel of the mockup. Links to open-source code (e.g. a github profile) and/or add-ons that you have produced.

« Newer Posts - Older Posts »

Categories

Follow

Get every new post delivered to your Inbox.