View source for Firefox OS/Spark/Draft

='''Overview'''=

==Why?==

As mobile platforms move closer to a strict "walled garden" ecosystem, ''Firefox OS'' strives to stand against this trend by bringing the open web to mobile.

There are several key advantages to the web. It is portable and standards-driven, thus it can run anywhere with the same experience. It is ubiquitous, thus there are many websites that already work on it, and almost every organization has a web presence already. It is open, thus anyone can publish to it.

==Enter, Spark==

''Spark'' is a set of tools, customizations, and features built on top of the next generation of the ''Firefox OS'' platform and is a subset of the ''Ignite'' initiative. ''Spark'' is intended to empower users to customize their experience, hack whatever they want to, and make their devices truly theirs. The intention is that we will leverage web technologies for real-time hacking, as other platforms rely on native binaries that are difficult to edit once compiled. Sharing web apps and hacks is also easier as they are more portable and standards-driven. We plan to iterate rapidly on the Spark feature set.

==Mission Statement==
We believe that web technologies empower mobile devices to be hackable and customizable in a way never seen before. 

==High-level goals==
Firefox OS in general is going to get back to the basics of great hackability, great privacy, and great experience. Spark is focused on the hackability aspect. We will:
* Empower customization of devices in whatever way our users desire.
* Make customization and hacking delightful.
* Leverage the power of the web to create an experience that native platforms can't.

==Spark v0.1 Retrospective==
<big>Main article: [[Firefox_OS/Spark/v0.1|Spark v0.1]]</big>

Development and design of Spark v0.1 was marked by the following core tenets:
* Product design was driven heavily by engineering. This was exacerbated by the lack of a dedicated product manager. It was posited that this was acceptable given that the traits of the target user for Firefox OS going forward, early adopters, theoretically have a lot in common with engineers.
* Breadth in features was favored over depth. The intention here was to try a series of flows and see what stuck with users.
* Spark and Foxfooding were tied together very intimately, which prevented the team from really focusing on Spark as the project got closer to release.
* When development began, there was no roadmap; just some ideas and very high-level goals. As a result, product design happened very rapidly and iteratively without a plan from the beginning.

==Spark v0.2 Core Themes==

The overall approach for Spark v0.2 will be a significant departure from that of Spark v0.1. We will keep the following tenets in mind:
* Product design will be driven by solving a problem for the end user. We will clearly state that the target user is the early adopter / tech enthusiast. We will take an empathic approach to this design, favoring user feedback over speculation.
* We will start with a user research phase where we interview our target users, propose solutions and gather feedback on them, then build paper prototypes. Only after this phase is complete will we begin engineering work.
* Product design will favor depth over breadth. We will be very focused on a small set of use cases, and solving them very well. Features will be cut ruthlessly if they are shown to be either unfeasible or not beneficial to the user.
* Interaction design will begin when a problem and potential solution have been identified. Engineering will begin only after the interaction design has reached a soft consensus.
* The product will be continuously tested on users, and be iterated on where needed.
* We will not constrain ourselves to past designs and engineering work unless there is a very compelling reason to do so, e.g. it makes sense for the future, it aligns well with what users want, or we determine that the trade-off of engineering work is worth a slightly worse user experience.
* Deadlines will be of relative, rather than absolute importance. We will focus on the long-term vision, and treat releases as check-ins.

=Phases=

==User Research==

The focus during this phase will be on gathering and parsing data from users. We will conduct interviews, the purpose of these being to figure out what exactly users want to be able to customize. We will be careful to be unbiased, and to help interviewees break free of the constraints of native platforms in their answers without directly mentioning this.

Here are some of the questions that we will ask:
* (If they know about Firefox OS) What do you think of Firefox OS?
* (If they know about Spark) What do you think of Spark?
* What is something about your phone that you wish was different?
* (If they're not foxfooding) What is something about Firefox OS that you wish was different?
* If you could customize your phone in some way, what would you do?
* What do you think of the web?

The goal of this phase is to come up with a problem, and 1-3 very specific use cases to build a solution for. We will also consider this phase a success if we come up with a potential high-level solution for this problem.

This phase will last 2 weeks.

===Contingencies===

This phase may not yield enough information for us to make an informed and well-thought out decision in our timeframe. If this happens, we will be prepared to field questions about [[#Task_Builder_Idea|the task builder idea]].

==Design==

The next phase will involve narrowing in on an actual solution for the identified problem and use cases. The goal will be to have a soft consensus, e.g. most people agree, on a path forward. We will build paper prototypes and test these on potential users, iterating as needed until we're satisfied that we're solving a real pain point.

We will not aim to have completed specs at the end of this phase. As long as everyone understands the path forward, we can begin on engineering work and discuss with UX and UI as needed.

This phase will take 2 weeks.

==Iteration==

This phase will involve actual building of the solution. It is called "iteration" and not "engineering" or "building", because it is more focused on getting the solution right, than on having a very concrete and specific design and end state envisioned right at the onset. As we build the solution out, we will test it out on users, and iterate further where needed. We will always favor cutting features over serving something to users that is subpar.

In keeping with the train model, we aim for the results of each sprint to be releasable. Thus, we will build the solution with l10n and tests from the get-go. However, we will abstain from heavy testing on the front-end, to keep us nimble and adaptable to changes from user testing.

This phase will take the remainder of the release.

===Contingencies===

We will evaluate progress half-way through this phase. If it we are not satisfied that it will be completed on-time and well, we will abandon it and pick up the Sharing app. We will then focus on writing tests for this app and adding l10n support, perhaps even squeezing in media sharing support.

=Appendix=

==Task Builder Idea==

We believe that Spark v0.1 was onto something with its customization potential, but that it didn't solve a real problem for the end user in an effective way.

The web is uniquely positioned to run arbitrary code on runtime in a way that other platforms can't. It's also well-positioned to establish client-server interactions, regardless of what the actual devices on each end of this relationship are.

Thus we propose iterating on the Customizer to make it a task-focused code builder. At a high level, it will allow modification of apps using simple prose, e.g. "<when I receive a call>, <send myself an email>". As alluded to, this could also operate on phones and other devices in the area.

These tasks and triggers would be backed by add-ons.