Revision as of 20:19, 5 November 2015

FOR DISCUSSION: This document is currently a re-hash of the deliverables. It will most likely be updated after a discussion with the development team.

Vision

Serve feature compatibility information across multiple outlets and formats without data duplication

1. Introduction

The production vision document is about making a consensus about the features and limitations of the product. It should help us by providing a common vocabulary to help better communicate throughout the phases of the project.

Project Vision document defined by the Scrum Alliance and Agile Manifesto as a guideline to structuring work without overdoing it.

1.1. Related

Compatibility Data product vision (this document)
Functional dependencies analysis
High level feature prioritization worksheet

1.2. Preface

Compatibility data are one of the key feature of MDN. It allows users to know more about the reliability of any web standard features and to ease the use of web technologies.

Currently, the data are gather and maintain "by hand". Thanks to our awesome community we have some good data. However, this is hardly sustainable as the number of technologies is growing as well a the complexity of the implementation. We start to face some difficulties to stay up to date and to provide and improved content around those data.

For Web Developers, Who wants to know whether they should use a technique, The BrowserCompat system is a specialized web service, That provides compatibility data Unlike caniuse.com We'll be able to have a usable maintenance flow serving reports in multiple formats �

1.3. Production vision summary

An overview, summarizing this document

Target group	Needs	Product	Value
Software Developer who has an immediate need for information, and want to know about a User-Agent feature support, and standardization status Software Architect, or Blog Author, writing technical document about recent technologies and how to use Technical writer (“contributor”) and/or translator who work on improving web developer documentation and wants to get better tools Browser vendor representatives who want to update their product support data Third-party developer involved in a product who want to use compatibility data within their software (“Third party”)	Import data we currently host in Wikitext format Display up-to-date User-Agent feature details and support information, consistently Easing contribution, translation, and access to data Easing moderation of contributions (i.e. prevent spam)	Specialized web service serving feature support data in multiple languages (e.g. English, French, German, etc.) and formats (JSON, HTML) Dashboard that allows maintenance and moderation of the data being contributed Search engine to ease browsing feature based on various criterions such as Author, Feature, Feature Support, Spec. Maturity, Browser, Browser Version, etc. Contribution workflows to allow multiple third party contribution to the data.	Improve value of MDN by serving reusable utility to support Web Developer Industry Improve resiliency of MDN site infrastructure Simplify maintenance tasks related to feature support updates Support Mozilla mission by providing a canonical resource about cross compatibility of standards web technologies

Note: This table is purposefully rough-grained, giving an overview of what we’re building, what it’ll do, and for whom.

2. Business Opportunity/Problem Statement

Not finished yet, see Vision document in Google Docs

�

@@ Line 3: / Line 3: @@
 = Vision =
-== Objective of this document ==
+<blockquote style="font-size:1.4em">Serve feature compatibility information across ''multiple'' '''outlets''' and '''formats''' ''without'' data duplication</blockquote>
-In order to help us structure the work and communicate better with other stakeholders, we may want to follow the '''[http://agilemanifesto.org/ Agile Manifesto] guidelines'''
+== 1. Introduction ==
-This document should be viewed as a summary of the project priorities to assist us in the decision process.
+The production vision document is about making a consensus about the features and limitations of the product. It should help us by providing a common vocabulary to help better communicate throughout the phases of the project.
-It is meant to follow the objectives of a Project Vision document defined by the Scrum Alliance.
+Project Vision document defined by the Scrum Alliance and Agile Manifesto as a guideline to structuring work without overdoing it.
-<blockquote>« Every Scrum project needs a product vision that acts as the project’s true north, sets the direction and guides the Scrum team. It is the overarching goal everyone must share – Product Owner, ScrumMaster, team, management, customers and other stakeholders. As Ken Schwaber puts it: “The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is.” (Schwaber 2004, p. 68) »</blockquote>
+=== 1.1. Related ===
-Please keep this document as short as possible to reflect the current project direction regardless of the phase we are in.
+* Compatibility Data product vision (this document)
+* [https://docs.google.com/document/d/1Nh7ktC1rQQyItBXRdCd7IHKLpdJceZ6LFmMTsbzaaJ8/ Functional dependencies analysis]
+* [https://docs.google.com/document/d/1ILwiPv5Wk3PwnKrD-sLmLBKhX6p6uEIj69gE3hr2MuI/ High level feature prioritization worksheet]
-== Vision Board ==
-=== Serve feature compatibility information across ''multiple'' '''outlets''' and '''formats''' ''without'' data duplication ===
+=== 1.2. Preface ===
+Compatibility data are one of the key feature of MDN. It allows users to know more about the reliability of any web standard features and to ease the use of web technologies.
+Currently, the data are gather and maintain "by hand". Thanks to our awesome community we have some good data. However, this is hardly sustainable as the number of technologies is growing as well a the complexity of the implementation. We start to face some difficulties to stay up to date and to provide and improved content around those data.
+'''For''' Web Developers,
+'''Who''' wants to know whether they should use a technique,
+The BrowserCompat system '''is a specialized web service''',
+That '''provides compatibility data'''
+'''Unlike''' caniuse.com
+'''We'll be able to have a usable maintenance flow''' serving reports in multiple formats
+�
+=== 1.3. Production vision summary ===
+An overview, summarizing this document
 {| class="wikitable" style="text-align:left; vertical-align: top; border: none;"
@@ Line 27: / Line 44: @@
 |-
 | style="vertical-align: top;" width="25%" |
-# People who make websites, are on MDN, and want to learn if a specific feature is supported ("''web developer''")
+# '''Software Developer''' who has an immediate need for information, and want to know about a User-Agent feature support, and standardization status
-# Browser vendor representatives who want to update their product’s support data ("''Vendor rep.''")
+# '''Software Architect''', or Blog Author, writing technical document about recent technologies and how to use
-# People who make contributions to MDN ("''contributor''")
+# '''Technical writer''' (“contributor”) and/or translator who work on improving web developer documentation and wants to get better tools
-# People who work on translating MDN content  ("''translator''")
+# '''Browser vendor representatives''' who want to update their product support data
-# People working on projects who want to use compatibility data in their app
+# '''Third-party developer''' involved in a product who want to use compatibility data within their software (“Third party”)
 | style="vertical-align: top;" width="25%" |
-* ''Display up to date feature support data consistently''
+# '''Import data''' we currently host in Wikitext format
-* Easy ''data entry'' process ("contribution")
+# '''Display up-to-date''' User-Agent feature details and ''support information'', consistently
-* Easy access to data
+# '''Easing contribution''', translation, and access to data
-* Easy moderation of the ''data entries''
+# '''Easing moderation''' of contributions (i.e. prevent spam)
-* Easy translation of notes and labels
 | style="vertical-align: top;" width="25%" |
 * Specialized web service serving feature support data in multiple languages (e.g. English, French, German, etc.) and formats (JSON, HTML)
 * Dashboard that allows maintenance and moderation of the data being contributed
-* Search engine to find features based on criteria such as author, feature, browser, etc.
+* Search engine to ease browsing feature based on various criterions such as Author, Feature, Feature Support, Spec. Maturity, Browser, Browser Version, etc.
+* Contribution workflows to allow multiple third party contribution to the data.
 | style="vertical-align: top;" width="25%" |
+* Improve value of MDN by serving reusable utility to support Web Developer Industry
 * Improve resiliency of MDN site infrastructure
 * Simplify maintenance tasks related to feature support updates
-* Help all browser vendors contribute to MDN
+* Support Mozilla mission by providing a canonical resource about cross compatibility of standards web technologies
 |}
-ref: [http://www.romanpichler.com/blog/the-product-vision-board/ The Product-Vision Board]
+'''Note''': This table is purposefully rough-grained, giving an overview of what we’re building, what it’ll do, and for whom.
-----
-== Expanded vision notes ==
-=== Which customer needs will the product address? ===
-Priorities are marked by a star (☆)
-* View up to date feature support tables embedded within MDN content ☆
-* Add/Edit a given feature entry using tools within MDN ☆
-* A way to input/import data
-** Scraping existing MDN compatibility tables ☆
-** Manual contribution by users using external tools
-** Bulk ''data entry'' that may span many features (both changing existing features and adding new ones)
-* A way to maintain the data (outside of MDN)
-** Search by feature, contributor, or specification
-** Individual contribution (i.e. contributor, time of contribution, contribution data) ''not clear what this means''
-** Bulk ''data entry'' that may span many features (some features may or may not exist)
-** Erase one or many contributions
-** Localization of labels in the UX and the tables so we can support displaying the data in multiple languages
-=== Which product attributes are critical to satisfying the needs selected, and therefore for the success of the product? ===
-* Seamless communication flow between separate web applications: the database, the API, and the MDN production content should always present the same data
-* Every translation of a given article should display the same compatibility data, just presented according to the user's locale
-* Erasing contributions should adjust internal data representation to the ''sum of data entries between an initial state and the entry events applied in an ordered manner'', modulo what's been erased
-* Import data should be structurally identical to the data Export output ''What does this mean??''
-* ''data entry'' format should be structurally identical for both bulk and individual contribution
-* Data should not store localized labels; these should be stored in a centralized manner which supports localization of those labels
-* Ability to snapshot the database ("export") into appropriate formats (json, HTML...?)
-* Ability to restore service quickly
-** Easy to maintain the service
-** Easy to restore backups of the data to roll back if a data irregularity occurs
-=== How does the product compare against existing products, both from competitors and the same company? What are the product’s unique selling points? ===
-No feature for feature equivalent found yet
-=== What is the target timeframe and budget to develop and launch the product? ===
-TODO
 ----
-== System properties ==
+== 2. Business Opportunity/Problem Statement ==
-=== Components ===
-(most likely incomplete)
-# Display data at most recent state
-# Search current data, by Feature, Author, Browser
-# Search ''data entry'' events, by Feature, Author, Browser
-# Compile data view as the ''sum of data entries between an initial state and the entry events applied in an ordered manner''
-# Render an HTML representation of the data (may or may not have more than one HTML format)
-# Accept writes only if authenticated to trusted authentication provider
-# Contribution data types:
-## Feature (e.g. ''border-radius'')
-### Supports (e.g. ''Basic Support'' of ''border-radius'')
-## Specification
-## Browser
-### Browser Version
-## Note
-# Frontend JavaScript client
-## add editing capabilities from MDN embed
-## Convert a given ''data entry'' into a "contribution packet" to send to the API
-=== Properties that have common attributes ===
-Common properties should indicate the system dependencies and, therefore, makes them critical to supporting other features of the system as a whole.
-==== Data entry events ====
-As stated in ''critical attributes'' above:
-<blockquote>Erasing contributions should adjust internal data representation as the ''sum of data entries between an initial state and the entry events applied in an ordered manner'', modulo what's been erased</blockquote>
-The following types of data are subject to edit events, and moderation may be required on a given event.
-In their respective contexts:
-* Bulk (i.e. event data adds/edits more than one data type)
-* Individual entry, triggered from MDN
-* Individual entry, triggered from external site
-* Initial import (''is this the first scraping of MDN? what about with the skateboard plan, where each change is a scraping? that needs to be taken into consideration'')
-It means we may want to focus on a system that helps us browse ''data entry'' events. This will allow rolling back to the point at which errors or other problems occurred, and should allow us to support undoing individual changes, even though others happened later, at least in many cases.
-==== Search ====
-Search capability is required for two different contexts: the current data set and the contribution event history/log.
+Not finished yet, see [https://docs.google.com/document/d/1oekQHEkiNSIxKSEhWSUArqMO517t3byoDWsq8Di-iB4/edit# Vision document in Google Docs]
-==== Compile a data view as the sum of data entries ====
-Each visualization of the data, regardless of its presentation format, is the result of changes that has been made on a given resource (e.g. Feature, Specification, Browser, Labels)
-In order to support moderation, and the underlying need to allow removal of unaccepted data, we must have a system that handles ways to apply changes in an ordered manner.
+�

MDN/Archives/Projects/Development/CompatibilityTables/Vision: Difference between revisions