Mozilla Prototypes: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (add link to mozilla labs)
(really old, redirecting)
Line 1: Line 1:
== Goals ==
#REDIRECT [[http://labs.mozilla.com/]]
 
The goal of Mozilla Labs ("[[Labs]]" for short) is to augment the existing product development process by offering a low-barrier-to-entry environment for discussion, creation and proof-of-concept testing for Mozilla technologies. Labs will be operated as an advanced technology group with a heavy implementation and usability focus rather than a pure research laboratory. It will be a public showcase for some of the innovation emanating from Mozilla and the community.
 
Labs will be mostly a web site and a brand of Mozilla where experimentation is valued. It will host extensions, experimental builds, and potentially new packagings or new products, so that interested users can obtain and use them, and, just as important, a forum for collecting feedback, suggestions, etc. Mozilla Labs will be mostly virtual, in that there won't be a cadre of researchers here at Mozilla doing the work (at least not for now), and we'll be working with partners to do experiments that we think are relevant and warrant consideration for building into future product releases.
 
== Background ==
 
The Mozilla Foundation and Corporation have established goals of promoting choice and innovation on the Internet. The current set of products and technologies that Mozilla offers are incredible feats of engineering but are often encumbered by schedules and deadlines, backwards compatibility, time to market, feature design inertia, project and product risk, etc...
 
Labs will offer Mozilla employees, community members and interested startup/corporate partners the ability to suggest, experiment, innovate and try out new concepts in Internet technologies. This will be done "off" the current product development cycle and will not be tied to upcoming releases and their schedules.
 
== Model ==
 
There are lots of different models for how R&D labs can be run.
* Google has the 20% time for engineers and selected projects make it to [http://labs.google.com Google Labs] for external visibility and testing. Google presents the offerings in either alpha or beta state.
* Yahoo! offers [http://next.yahoo.com/ Yahoo! Next] to showcase beta offerings, Idea Factory for idea submission, and Hack! (Yahoo-Internal access only) for internal experiments.
* AOL has recently introduced [http://greenhouse.aol.com/ Greenhouse] for internally developed previews and prototypes.
 
There are Mozilla-related project sites such as [http://mozdev.org/ MozDev] and [http://sourceforge.net/ SourceForge] and existing extensions sites such as [https://addons.mozilla.org/ Mozilla Add-ons].
 
We expect the model for Mozilla Labs to evolve over time but the current thinking is that it will be a hybrid of Google Labs & SourceForge. A limited set of focused projects (determined by Mozilla) with associated discussion and source code (when appropriate) available for review.
 
It will mostly be mostly a virtual "organization" and hosted online.
 
== Process ==
 
Ideas and projects can be thought of as being in a pipeline. Some can be at the concept or idea stage being formed, others are thought out enough that a mockup can be developed, others can be prototyped, while others are ready for user testing.
 
A set of tools will be introduced to facilitate the discussion of potential ideas and projects. Then, a small set of projects will be initiated and run for a fixed durations. After the fixed duration, an evaluation is conducted to determine if the project should be continued for another run, be modified with new directions for investigation, graduated as a candidate feature for Firefox (or other product), or documented, archived and terminated. Multiple projects can be run simultaneously but likely no more than 5 at any one time.
 
The scope of the projects can include a wide variety of interest areas for Mozilla. For example:
* Core Firefox features (e.g. Yahoo Frecency experiments, social and remote bookmarking experiments, microformat display/parsing)
* Services Integration (e.g. What does a eBay/Amazon-enabled browser look like?)
* Mozilla Web Services (e.g. online storage for extensions)
* Local Storage (e.g. experiments with SQL Lite - local AJAX)
* Visual Identity (e.g. What should the next generation of Firefox browser look like?)
* Non-PC Devices (e.g. Minimo, Firefox on TV/10-foot UI)
* Presence (e.g. how should online presence be reflected in the browser?)
* Platform technologies (e.g. Should Mozilla offer an API to XYZ?)
* User Privacy & Identity (e.g. Should Mozilla promote initiatives such as AttentionRecorder? OpenID?)
* Media Integration (Is there a new UI we can introduce for sharing, discovering videos, photos?)
* etc...
 
In this process, we expect to learn a lot from both the successful and unsuccessful projects. The feedback will be documented incorporated as lessons into the product development process. The proposed evaluation process will ensure that we do not over-invest in an area without a clear outcome.
 
== Tools ==
 
It is recommended that a separate operating environment be setup so as to not encumber existing production tools and codebases.
 
* Mini website (labs.mozilla.org) with overview, current projects, project pages, relevant links, downloads?
* Forum/newsgroup for discussion of new project ideas, proposals, current projects, etc...
* Wiki for project lists, project pages, permanent and evolving documentation
* Private CVS/Subversion tree for collaborative development
* Bugzilla instance for project-specific bug tracking, feature requests, etc...
 
 
== Timing & Staffing ==
 
The intention is to launch in time with the release of Firefox 2.0 and support the innovation and platform messaging.
 
For staffing:
* Basil Hashem for overall process management
* Startup/corporate fractional participation
* Fractional time from Mozilla engineers, IT, Release/Build, QA, marketing, executive
* Rely on existing shared IT services for Mozilla
* Potential engineering new hires
 
== Oversight & MetaWork ==
 
* Monthly and on-demand status reports will be generated for project tracking, highlighting accomplishments and documenting learnings
* Some PR & marketing needs to be done in order to drive traffic to the new site and get momentum
 
== Technical Process ==
 
'''''Stage 1: Sourcing ideas'''''
 
Mozilla "Prototypes" will be completely open for sourcing of ideas. They can come from anywhere including Mozilla employees, community contributors, startups/corporates, universities, marketing partners, research labs, the extended Mozilla circle, users, etc... The ideas will be documented and categorized onto a wiki or suggestion box application. This is a continuous process.
 
A rating system will be introduced in order to bubble up the most interesting ideas to the top.
 
Ideally, a project should be documented as a proposal that include a hypothesis that need to be tested, an idea that needs to be validated (or refuted), a technical feasibility, a design that need to be created, a comparison of alterate designs or approaches, or a question that needs to be answered. Projects should not be completely "open ended".
 
'''''Stage 2: Launching and Running Projects'''''
 
Labs will evaluate the project proposals and based on staffing and strategic interests select a handful of projects to be run simultaneously. The project proposal will be refined, staffing and duration will be set and necessary infrastructure (wiki, bugzilla, cvs, etc...) for each project will be created.
 
Here are some notes from mconnor on guidelines for how work on Firefox might flow:
* Form a small team - 2-3 hackers, 0.5 UI person, 0.5 visual/graphics person, and a triage/QA helper (optional)
* Firefox-related projects will not be run on the mainline or the trunk.
* Base work on most recent Firefox release branch, use build-config magic to replace Firefox pieces with forked bits.
* High risk/high reward work that doesn't belong on the main dev path (distracting from mainline development and testing)
* New features have a shelf life, either they are good enough for n+1 or they're not.  If they're not, they get dropped aggressively.
* Little to no build team resources needed (tinderbox/nightly builds, milestones are just nightlies)
* Focus on rapid iteration over clean code (we can reimplement cleanly if the idea pans out)
* Successful features get ported to the product by the mainline team at the appropriate times
 
For UI-focused projects:
* Build prototypes using tools
* Draw information models and user task/data flow diagrams
* Consider user testing in a focus group
 
 
'''''Stage 3: Project Evaluation'''''
 
At the end of a project, the evaluation will take place to determine the lessons learned and future fate of a project.
 
== Mantras & Cautions ==
* "Ideas are nice but code and working prototypes rock!"
* "Don't show unfinished prototypes to stupid people"
* How to deal with current business feasibility constraints for an experiment?
* How to ensure that we focus on building and testing the solution rather than how to package it, clean it up and sell it to the organization
 
__NOTOC__

Revision as of 20:05, 26 June 2009

Redirect to:

Retrieved from "https://wiki.mozilla.org/index.php?title=Mozilla_Prototypes&oldid=152163"