Confirmed users
525
edits
Firefox OS/Spark/Draft: Difference between revisions
m
no edit summary
(Created page with "='''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...") |
mNo edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 9: | Line 9: | ||
==Enter, Spark== | ==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. | ''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== | ==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: | Development and design of Spark v0.1 was marked by the following core tenets: | ||
| Line 28: | Line 38: | ||
* The product will be continuously tested on users, and be iterated on where needed. | * 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. | * 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= | =Phases= | ||
| Line 33: | Line 44: | ||
==User Research== | ==User Research== | ||
The focus during this phase will be on gathering and parsing data from | 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. | |||