Mozilla Prototypes: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(grr)
 
(22 intermediate revisions by 9 users not shown)
Line 1: Line 1:
== Goals ==
#REDIRECT [[http://labs.mozilla.com/]]
 
The goal of Mozilla "Prototypes" (MP) 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. MP 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.
 
MP will be mostly a web site and a brand of Mozilla where experimentation is valued.
 
 
hosting 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...
 
MP will offer Mozilla employees, community members and interested startup/corporate partners the ability to 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 Google Labs for external visibility and testing. Google presents the offerings in either alpha or beta state.
* Yahoo! offers Yahoo! Next to showcase beta offerings and Hack (Yahoo-Internal access only) for internal experiments.
* AOL has recently introduced Greenhouse for internally developed previews and prototypes.
 
There are the project sites such as MozDev and SourceForge and existing extensions sites such as  Mozilla AddOns.
 
We expect the model for Mozilla "Prototypes" 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 ==
 
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 simultaneously 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.
 
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 participation (e.g. Yahoo staffers)
* 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. This is a continuous process.
 
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, etc.... In any case, a clear yes/no or documented outcome needs to be stated for a project. Projects should not be "open ended".
 
'''''Stage 2: Launching and Running Projects'''''
 
MP 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 mconner on guidelines for how work on Firefox might flow:
* Form a small team - 2-3 hackers, 0.5 UI guy, 0.5 visual/graphics guy, 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.
 
== FAQ ==
'''Q. Why not use the Mozilla Addons site?'''
 
A. Not everything will necessarily be an extension. Some of the projects could be delivered as special builds, separate clients, documentation, visualizations, etc... Also, Addons are typically "completed" solutions for users. MP can be a hack or a partial solution and may have much less testing done than a widely distributed extension.
 
'''Q. Is Mozilla "Prototypes" the real name?'''
 
A. No, it's a placeholder. Candidate names include:
* Mozilla Labs - labs.mozilla.org
* Mozilla Research - research.mozilla.org
* Mozilla Invent - invent.mozilla.org
* Mozilla Make - has UNIX geek cred
* Mozilla <Keyword> where keywords (to get the juices flowing): ideas, seeds, new, create, discover, find, sow, experiment, study, test, fieldwork, nest, probe, explore, check out, design, define, forge, original, generate, produce, crystal, unearth, dig, root, investigate, conceive, demo, show, prototype, protos, pros, eggs, nuggets, jewels,
 
Definitely open to ideas on naming. Ideally, we want something reflective of innovation as well as has a reasonable sized URL.
 
== Got Suggestions? ==
* Add to the discussion page
 
== Stuff to Investigate ==
* Collab.net - http://www.collab.net
* P&G - IDEO Relationship
 
== Open Questions ==
 
* What is the name?
 
== 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

Latest revision as of 20:26, 26 June 2009

Redirect to:

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